ANÁLISIS Y DISEÑO DE SISTEMAS

RecibirDinero

Cliente

Pedir Azucar EscogerAzucarYTipo

PedirProducto
<<include>>

<<include>>

Cancelar
DarCambio

DIAGRAMA DE CASOS DE USO CONCEPTOS DE UN DIAGRAMA DE

Máquina de Café
Desarrollar el control de una máquina automáti-
ca de entrega de café, con las siguientes caracte-
rísticas:
CASOS DE USO
Un diagrama de casos de uso muestra las distin-
tas operaciones que se esperan de una aplicación
o sistema y cómo se relaciona con su entorno
(usuarios u otras aplicaciones).

La máquina debe permitir a una persona entre- Actor

gar una cantidad de dinero en monedas de: 100,
200 o 500; escoger uno de los productos de Los actores se representan
acuerdo a su precio (café negro, café claro, mediante "hombres de palo"
caldo), escoger (si es pertinente) un nivel de (stick man). También se
azúcar, entregar el producto y los cambios. El puede utilizar los mecanis-
Nombre actor
dinero que los usuarios introducen se guarda en mos de extensión previstos
un recipiente aparte disponible para los cam- en el UML para estereotipar un Actor prove-
bios, el cual se encuentra ordenado por denomi- yendo un icono diferente que pueda ofrecer
nación. mejor visibilidad para su propósito. Por ejemplo
puede representar un Actor mediante un rectán-
Existen estados de error de la máquina: cuando gulo con el estereotipo «actor».
detecta un mal funcionamiento, no existen mo- <<A ctor>>
Nombre actor
nedas para los cambios o no existen los ingre-
dientes.

El usuario puede en cualquier momento antes de Es un usuario del sistema, que necesita o usa
escoger el azúcar cancelar la operación, median- algunos de los casos de uso. Los actores repre-
te un botón existente para este objetivo. sentan a quien o al que interactúa con el siste-
Ingeniería de Sistemas 1
ma, es todo aquello que necesita intercambiar Relaciones en un diagrama de casos de
información con el sistema, el cual no se descri- uso
be con detalle. Asimismo, es el papel que el
usuario puede jugar en el sistema. En conclu- Entre los elementos de un diagrama de Casos de
sión, modela un objeto fuera del dominio del uso se pueden presentar tres tipos de relaciones,
sistema que interactúa con el sistema. representadas por líneas dirigidas entre ellos
(del elemento dependiente al independiente):
Buscando Actores
Comunicación (communicates)
Un actor puede ser: usuarios humanos, otros
sistemas, o máquinas. Una forma de determinar- Relación entre un actor y un caso de uso, denota
los es: la participación del actor en el caso de uso de-
¾ Identificar los usuarios del sistema. terminado.
¾ Identificar los roles que realizan estos usua-
rios desde el punto de vista del sistema.
¾ Identificar otros sistemas con los cuales
exista comunicación.
Recibir dinero
Caso de uso Cliente
Se representa en el
A esta relación también se le conoce como rela-
diagrama por una
ción de comunicación y suele estereotiparse
elipse, denota un re-
como «comunicates», aunque esto no es indis-
Nombre Caso querimiento solucio-
pensable pues es la única posible entre un actor
nado por el sistema.
de Uso Cada caso de uso es
y un caso de uso.
una operación completa desarrollada por los
actores y por el sistema en un diálogo. El con- Generalización
Trata de representar la relación entre dos objetos
junto de casos de uso representa la totalidad de
del mismo tipo en el cual uno de ellos se com-
operaciones desarrolladas por el sistema.
porta igual que otro pero que además contiene
características adicionales que lo diferencian. La
Nombrando Casos de Uso
generalización es una relación de herencia y en
los Diagramas Casos de Uso puede ocurrir entre
Es una descripción informal de los actores y
un actor y otro actor y, entre un caso de use y
transacciones de eventos.
otro caso de uso.
A menudo el nombre del caso de uso comienza
con un verbo; por ejemplo, para un banco: Iden-
tificar cuenta, preparar declaración, Auditar.

Identificando casos de uso

Para definir los casos de usa es necesario deter-

minar los requerimientos desde la perspectiva
de un actor. Una ayuda para encontrar los casos
de uso es contestar a las siguientes preguntas:
¾ ¿Cuáles son las principales tareas de un
actor? Los actores docente y administrativo (hijos) son
¾ ¿Que información tiene el actor que consul- especializaciones del actor personal (padre).
tar, actualizar, modificar y cómo?
¾ ¿Que cambios del exterior deben informar
los actores a nuestro sistema?
¾ ¿Qué información debe dar el sistema al
actor?
¾ ¿Piense en los eventos ante los cuales el
actor debe reaccionar?

2 Análisis y diseño de sistemas

Los casos de uso presentar video y presentar
texto (hijos) son especializaciones de presentar
información (padre).
El hijo hereda el comportamiento y significado
del padre, y eventualmente el hijo puede susti-
tuir al padre. Sin embargo, el hijo puede redefi-
nir algún comportamiento del padre, o definir
algún otro comportamiento que el padre no
presenta.
Relación «include»
AI desarrollar un Diagrama de Casos de Uso a
menudo nos encontramos con casos de uso que
son incluidos como parte de otro u otros casos
de uso, y es que algunos casos de use pueden
compartir un comportamiento común. Este
comportamiento común es "factorizado" en
versiones de casos de use especializados.
Una Relación «include» entre casos de uso
significa que el caso de uso base incorpora ex-
plícitamente el comportamiento de otro caso de
uso. El caso de uso base siempre utiliza al caso
de use incluido. El objetivo de la relación «in-
clude» es permitir invocar el mismo comporta-
miento muchas veces, colocando el comporta-
miento común en un caso de use que puede ser
invocado por otro a otros casos de uso.
De manera general una relación «include», es
una relación de dependencia, puesto que su
ejecución depende siempre del caso de use base,
pues es éste el que lo invoca. El caso de use
incluido no puede ejecutarse sin el caso de use
que lo incluye.
La relación «include» es también un ejemplo de
delegación, pues tomamos un grupo de respon-
sabilidades del sistema y los ubicamos en un
lugar (el caso de use incluido), el cual es "invo-
cado" por otro caso de use cuando necesitamos
usar esa funcionalidad.
Hasta antes de la versión 1.3 de UML, este tipo
de relación fue llamada Relación de Uso y se le
estereotipaba como «uses», pero la bibliografía
oficial del UML 1.3 ya no consigna este nom-
bre, razón por la cual siempre nos referiremos a
ella como la relación «include».
Observe que la utilización de la relación «inclu-
de», esta más ligada al concepto de descompo-
sición funcional (muy común en los modelos
estructurados) que a los conceptos orientados a
objetos. Esto es así, porque los casos de use
solamente nos sirven para averiguar lo que el
usuario necesita del sistema y no cómo lo hace.
Ingeniería de Sistemas
Cuando necesitemos conocer más detalles acer-
ca del caso de use recurrimos a otros tipos de
diagramas que estén más relacionados con el
enfoque orientado a objetos.
relación «extend»
Una relación «extend» entre casos de use signi-
fica que se ejecuta el caso de uso base pero, bajo
ciertas condiciones, este caso de uso llama a
otro caso de uso que extiende el comportamien-
to del primero. Esto significa que el caso de
caso de uso base implícitamente incorpora el
comportamiento de otro caso de uso.
Se debe utilizar para modelar la parte del caso
de uso que tiene un comportamiento opcional,
así podemos separar el comportamiento que
siempre ocurrirá del comportamiento que ocu-
rrirá bajo ciertas condiciones.
Para encontrar las relaciones «extend», debemos
observar los casos de uso similares, pero que
contengan alguna diferencia en cómo realizan
las operaciones y qué casos de uso redefinen la
forma de realizar éstas operaciones dentro de
otro caso de uso. Se debe pensar en la conducta
normal en un caso y la conducta inusual en otro
caso, unidos por la relación «extend».
De manera general una relación «extend», es
también una relación de dependencia, puesto
que el caso de uso extendido entra en acción
dependiendo de las condiciones que se den al
efectuarse el caso de uso base. Recuerde que el
caso de use extendido, sólo se utilizará bajo
ciertas condiciones.
<<extend>>
Retirar dinero Exceder Limite
Puntos de extensión de los casos de uso
Una forma de extender la especificación de un
caso de uso se da dentro de la misma elipse que
lo representa mediante una cabecera denomina-
da Extension Point. Un caso de use puede tener
más de un punto de extensión. Dentro de las
elipses también se pueden mostrar comparti-
mentos presentando atributos, operaciones y por
supuesto puntos de extensión. La descripción de
la extensión normalmente se realiza en texto
3
ordinario, pero también se puede especificar en
otras formas, como: un diagrama de estados, o
mediante pre o postcondiciones.
Cobro en efectivo
<<extend>>
Si es efectivo
Realizar cobro
extension points
Cuando el cliente paga
<<extend>> <<extend>>
Sí es cheque Sí es tarjeta
Cobro con tarjeta de credito
Cobro con cheque
Cuando usar <<incluye>> y <<extend>>
Ambos tipos de relación implican la factoriza-
ción de comportamientos comunes de varios
casos de uso; sin embargo, en la relación «in-
clude» se trata de factorizar comportamiento
comunes para no repetir la definición y los ca-
sos de use factorizados pueden ser utilizados por
otros casos de uso; mientras que en la delación
«extend» se tienen en cuenta los factores varian-
tes, esto es casos que ocurren bajo ciertas cir-
cunstancias, poniendo este comportamiento en
otro caso de use extendiendo al caso base. Se
debe organizar los casos de use extrayendo el
comportamiento común mediante relaciones
«include» y distinguiendo las variaciones me-
diante relaciones «extend», con el objetivo de
crear un simple, balanceado y comprensible
conjunto de casos de use para su sistema.
4 Análisis y diseño de sistemas
En la relación «extend» los Actores siguen "co-
nectados" con los casos de use extendidos. En la
relación «include», es el caso de use base el que
se "conecta" con el caso de use incluido al invo-
carlo.
Resumen
Los casos de uso:
¾ Define el sistema.
¾ Ayuda a enfocar el problema.
¾ Permita incremento y el desarrollo paralelo.
¾ Mejore la estimación.
¾ Es mejor tener un caso del uso extenso que
varios pequeños.
Ejemplo:
Sistema de matricula
En una universidad particular cada semestre los
estudiantes registran su matricula seleccionado
los cursos que van a llevar durante el semestre.
De igual manera los profesores seleccionan los
cursos que van a enseñar en el semestre. Cada
vez que el estudiante se matricula esta informa-
ción se envía a tesorería ( considerado fuera del
sistema) para que se encargue del control de su
cuenta corriente.
El asistente es una persona que se encarga del
mantenimiento del sistema de matriculas, cuyas
funciones son: mantener el plan de estudios,
actualizar la información del estudiante y actua-
lizar la información del profesor. El asistente
utiliza una PC para realizar sus funciones y para
ello tiene asignado un nombre de usuario con
los privilegios necesarios.
 Seleccionar Cursos a enseñar
Estudiante Profesor

Matricular cursos

Tesorería

Mantener plan de estudios <<include>>

<<include>>

Actualizar información del

Asistente estudiante Validar registro de ingreso
<<include>>

Actualizar información del profesor

Ejemplo: Sistema de negocio de valores

Corredor De TransarNegocio Negociador

Negocio
AnálisisMercadoPotencial

<<include>>

Proveedor Datos DitribuirNoticias

Mercado

DistribuirNoticiasMercado

En un sistema de negocio de valores, el negociador se encarga de evaluar el mercado potencial utilizando

los datos proporcionados por un “portal”, si el resultado del análisis es favorable se concluye el negocio a
favor del corredor del negocio. El corredor de negocio es un cliente que desea comprar valores y que
trabaja con uno o varios negociadores. El mantenimiento del portal esta a cargo del proveedor de datos
del mercado. El portal además de las noticias del mercado también proporciona información variada.

Ejemplo: Sistema de ventas al crédito

En este sistema el gerente comercial establece los limites de las ventas al crédito que se van a realizar y el
sistema de contabilidad es el encargado de mantener actualizado el estado de cuentas de todos los clien-
tes. Un cliente que desea hacer una compra puede analizar el riesgo de su inversión para lo cual utiliza
parte del sistema llamado valuación o puede negociar el precio con el agente de ventas que cuenta con el
apoyo del modulo valuación. Una vez fijado el precio el sistema captura el negocio, pero a veces es nece-
sario extender el limite del cliente antes de capturar el negocio.

Ingeniería de Sistemas 5
 EstablecerLimites ActualizaCuentas
Sistema De
Contabilidad
Gerente De
Comercio

<<include>>

AnalizaRiesgo Valuación

<<include>>

Comerciante NegociaPrecio Agente De

Ventas
<<extend>>

CapturaNegociación LimiteExcedido

DOCUMENTACIÓN DE LOS CASOS CASOS ESENCIALES DE USO Y

DE USO CASOS REALES DE USO
Casos esenciales de uso
MÉTODO 1
Son casos expandidos que se expresan en forma
CLASIFICACIÓN DE teórica que contiene poca tecnología y pocos
CASOS DE USO detalles de implementación.
Casos primarios de uso Casos reales de uso

Representan a los procesos comunes más impor-
tantes. Por ejemplo, en un sistema de Ventas:
Registrar ventas, comprar ventas, etc.
Casos secundarios de uso
Representan procesos menores o raros. Por
ejemplo, en un sistema de Ventas: Estadística de
ventas por producto.
Casos opcionales de uso
Representan proceso que no pueden abordarse.
Por ejemplo en un sistema de ventas: compor-
tamiento del precio costo de un producto en
particular.
Describe concretamente el proceso a partir de su
diseño actual, sujeto a las tecnologías especifi-
cas de entrada y de salida, etc. Cuando se trata
de una interfaz de usuario se explica la interac-
ción del usuario con el sistema.
FORMATOS DE CASO DE USO
Los formatos de caso de uso que se utilizan son:
Formato caso de uso de alto nivel
Hace una breve descripción del sistema, casi
siempre usando 2 ó 3 enunciados. Generalmente
usado en la fase inicial.

Formato caso expandido de uso

Describe con mayor detalle que el caso de uso

de alto nivel. Incluye una sección para la des-
cripción de los eventos de curso normal y otra
para los cursos alternos. Es recomendable escri-
6 Análisis y diseño de sistemas
bir el formato expandido para los casos más
importantes y de mayor influencia; en cambio
los menos importantes pueden posponerse hasta
el ciclo de desarrollo.
Curso normal de los eventos
Describe los detalles de la interacción de los
actores con el sistema. Explica la secuencia más
común de los eventos: el desarrollo normal de
las actividades y la terminación exitosa de un
proceso. No incluye las situaciones alternas.
Curso alternos
Describe las opciones o excepciones que pueden
presentarse en relación al curso normal. Sin son
complejas podemos expandirlas y convertirlas
en otros diagramas de caso de uso.

Formato caso de uso de alto nivel

Caso de uso Nombre del caso de uso
Actores Lista de actores.
Tipo Primario, secundario u opcional. Esencial o real.
Descripción Descripción del caso de uso.

Formato caso expandido de uso

Caso de uso Nombre del caso de uso
Actores Lista de actores.
Propósito Intención del caso de uso
Resumen Repetición del caso de uso de alto nivel o alguna síntesis similar.
Tipo Primario, secundario u opcional. Esencial o real.

Curso normal de los eventos

Acción del actor Respuesta del sistema
Acciones enumeradas del actor Descripción numeradas de las respuestas del sistema

Curso alternos
Alternativas que puede ocurrir en el número de línea. Descripción de
excepciones.

Ejemplo: Cajero automático

Caso de uso de alto nivel: retiro en efectivo
Caso de uso Retiro de dinero en efectivo
Actores Cliente
Descripción Un cliente llega al cajero automático, ingresa el monto, recoge su
dinero en efectivo y el voucher. Luego se retira.
Tipo Primario y esencial
Caso de uso expandido: retiro en efectivo
Caso de uso Retiro de dinero en efectivo
Actores Cliente
Propósito Capturar un retiro y entregar dinero en efectivo
Resumen Un cliente llega al cajero automático, ingresa el monto, recoge su
dinero en efectivo y el voucher. Luego se retira.
Tipo Primario y esencial

Curso normal de los eventos

Acción del actor Respuesta del sistema
1. El cliente se identifica 2. Presenta opciones
3. El cliente elige opción retiro 4. Pide el monto a retirar
5. El cliente ingresa el monto 6. Registra el movimiento
7. Entrega el dinero
8. Presenta opciones
9. El cliente elige finalizar la transacción 10. Entrega el comprobante de retiro
11. El cliente recoge el comprobante y se retira

Ingeniería de Sistemas 7
 Curso alternos
Línea 1: Identificación invalida
Línea 5: El cliente no tiene suficiente dinero
Línea 9: Elige otra transacción

Utilizando caso real de uso

Caso de uso Retiro de dinero en efectivo
Actores Cliente
Propósito Capturar un retiro y entregar dinero en efectivo
Resumen Un cliente llega al cajero automático, ingresa el monto, recoge su
dinero en efectivo y el voucher. Luego se retira.
Tipo Primario y real

Curso normal de los eventos

Acción del actor Respuesta del sistema
1. El cliente introduce su tarjeta 2. Pide la contraseña
3. El cliente introduce la contraseña con un teclado numérico 4. Muestra el menú de opciones
5. Pulsa el botón de retiro 6. Pide el monto a retirar
7. Introduce el monto a retirar con un teclado numérico 8. Registra el movimiento
9. Entrega el dinero
10. Muestra el menú de opciones
11. Pulsa el botón de final de transacción 12. Entrega el voucher de retiro
13. El cliente recoge el voucher y se retira

Curso alternos
Línea 1: Identificación invalida
Línea 7: El cliente no tiene suficiente dinero
Línea 11: Elige otra transacción

MÉTODO 2

Un diagrama de caso de uso describe lo que hace el sistema, pero no describe cómo lo hace, al construir
los diagramas de casos de uso se debe tener bien en claro esta separación.

El comportamiento de un caso de uso, puede ser descrito de muchas maneras dependiendo de la conve-
niencia, a veces podemos usar pseudo código; sin embargo, comúnmente un caso de uso se documenta de
manera informal mediante una lista de pasos que sigue el actor durante su interacción con el sistema. A
esta lista se le denomina Flujo de Eventos (Flow of Events).

En muchas ocasiones no existe una única vía de ejecución de los casos de uso pues hay alternativas, apa-
recen errores o excepciones. Por ejemplo cuando se desea comprar un producto que no existe o esta des-
continuado, o tal vez cuando el comprador desea pagar con tarjeta de crédito, efectivo o cheque. Estas
desviaciones al curso normal de los casos de use se denominan alternativas, las cuales cuentan con algu-
nas características que no permiten definirlas como casos de uso, tales como:
• Representan un error o excepción en el curso normal del caso de uso.
• No tienen sentido por si mismas fuera del contexto del caso de uso en el que ocurren.
Una forma de describir el flujo de eventos, es mediante el siguiente cuadro:

Flujo de eventos del caso de uso Nombre del caso de uso

Actor Lista de actores.

CURSO NORMAL ALTERNATIVAS

Un caso de uso se documenta generalmente con texto informal, por lo tanto si tenemos que especificar
formalmente un algoritmo, los casos de use no son los más adecuados, en su lugar debemos usar los dia-

8 Análisis y diseño de sistemas

gramas de actividad, el moderno heredero de los diagramas de flujo. También podemos utilizar los dia-
gramas de colaboración y los diagramas de estado.
Dado que los casos de uso son un elemento poderoso durante la etapa de requerimientos, esto es qué es lo
que hace o debe hacer el sistema, debe tener siempre presente que durante esta etapa no debería indicar
cómo lo hace, para que el análisis no sea influenciado por la implementación.

Documentación para los casos de uso con la relación <<incluye>>

Para especificar la ubicación en el Flujo de Eventos en el cual el caso de use incluye el comportamiento
de otro, usted simplemente debe escribir include seguido del nombre del caso de use a incluir, tal como se
muestra a continuación:
Flujo de eventos del caso de uso Nombre del caso de uso
Actor Lista de actores.

CURSO NORMAL ALTERNATIVAS

…..
Include (…)
…..

Dentro del paréntesis deberá escribir el nombre del caso de use a incluir, el cual será documentado con un
Flujo de Eventos propio en una tabla adicional.

Documentación para los casos de uso con la relación <<extend>>

Para documentar el Flujo de Eventos de un caso de use que contiene una relación extend, se puede hacer
tal como se muestra:
Flujo de eventos del caso de uso Nombre del caso de uso
Actor Lista de actores.

CURSO NORMAL ALTERNATIVAS

…..
(Punto de extensión) Si <condición> entonces extend (…)
…..
Debe indicar el punto de extensión tal como se muestra, mientras que dentro del paréntesis que sigue a
extend, deberá escribir el nombre del caso de uso que extiende la conducta del caso de use base. El caso
de use extendido será documentado con un Flujo de Eventos propio en una tabla adicional.

EJERCICIOS RESUELTOS
Elabore el diagrama de casos de uso para cada uno de los casos presentados a continuación. Identi-
fíquese cualquier detalle faltante que usted necesite para elaborar un modelo más completo.
SISTEMA DE ASESORÍA LEGAL EN TRANSFE-
RENCIAS INMOBILIARIA.
Tenemos en esta oportunidad un estudio jurídi-
co que realiza diversas tareas, pero nos circuns-
cribimos estrictamente a las funciones relacio-
nadas con el servicio de asesoría legal en trans-
ferencias inmobiliarias y las consideramos como
un sistema, que encontramos relacionado con
los siguientes entes:
A. Vendedores
B. Registros públicos
C. Municipios
D. Notarias
Cuando una persona va a adquirir un inmueble
es conveniente rodearse de la necesaria seguri-
dad legal para evitar riesgos de estafas o enga-
Ingeniería de Sistemas
ños perjudiciales. En este caso veremos como
opera el sistema después de recibir al potencial
comprador, el cuál ya sabe que inmueble desea-
ría adquirir.
Simplificando las funciones de este sistema y
concentrándonos sobre todo en los flujos de
documentos podemos establecer las siguientes
relaciones (la letra corresponde al ente que se
quiere establecer):
A. Se pide al vendedor (que puede ser directa-
mente el propietario o un representante) su
titulo de propiedad que lo acredita como
propietario del inmueble.
B. Con los datos del inmueble, se solicita en los
Registros Públicos un Certificado de Gra-
vámenes y una copia Literal del Dominio,
que son documentos necesarios para brindar
9
 las seguridades legales del caso. Luego des-
pués de realizar lo indicado en ¨D¨ se envían
la minuta y otros documentos para obtener la
Escritura Pública.
C. Se gestiona en el Municipio correspondiente
una copia de la última declaración jurada de
autovalúo.
D. Se realiza un contrato privado de compra -
venta, el cuál luego de firmado se envía a al-
guna Notaría, para que lo transcriban en
forma de minuta.
Nos referimos a las funciones que se dan en este
sistema, las que se pueden dividir en las siguien-
tes.
1. Gestionar documentos; recordemos que
debemos gestionar y obtener los siguientes
documentos:
• Título de propiedad
• Declaración jurada de Autovalúo
Diagrama de casos de uso
Vendedor Gestionar documentos
Revisar documentos
Realizar contrato
Notario
Documentación del diagrama de casos de uso
Flujo de eventos del caso de uso
Actor
CURSO NORMAL
Solicitar titulo de propiedad al vendedor
10
• Certificado de Gravámenes
• Copia Literal de Dominio
Al obtener todos los documentos, formamos
con ellos un expediente y pasamos a la si-
guiente etapa.
2. Revisar documentos; se verifican ciertos
aspectos relevantes desde el punto de vista
legal y si todo esta conforme, pasamos a la
siguiente etapa.
3. Realizar contrato; que incluye la redacción
del mismo, la firma, la presentación en la
Notaría y la recepción de la minuta.
4. Inscripción del Título; se acompaña a la
minuta otros documentos (básicamente los
mencionados en ¨1¨), y con estos se gestiona
en los Registros Públicos la inscripción del
Título para obtener así la Escritura Pública
correspondiente.
Municipalidad
Registros publicos
Comprador
Inscribir titulo
Gestionar documentos
Vendedor, Municipalidad, Registros Públicos
ALTERNATIVAS
Análisis y diseño de sistemas
Solicitar declaración jurada de autoevaluó al mu-
nicipio
Solicitar certificado de gravámenes y copia literal
de dominio al registro públicos
Recabar los documentos solicitados
Flujo de eventos del caso de uso
Actor
CURSO NORMAL
Obtener todos los documentos solicitados
Evaluar aspectos legales de cada documento
Dar conformidad de los documentos
Flujo de eventos del caso de uso
Actor
CURSO NORMAL
Redactar términos del contrato
Presentar contrato en la notaria
Elaboración de la minuta
Firmar contrato y minuta en la notaria
Recibe la minuta el comprador y se archiva
una copia en la notaria
Flujo de eventos del caso de uso
Actor
CURSO NORMAL
Presentar minuta acompañado de los documentos obteni-
dos en el caso de uso gestionar documentos a registros
públicos
Recoger escritura publica de registros públicos
Entregar escritura pública al comprador
SISTEMA AUTO-MARKET
El Auto-Market es un sistema novedoso, único
en su género. Se trata de un mercado de aten-
ción exclusiva de clientes en automóvil, los
cuales no descienden del mismo para hacer sus
compras. El Auto-Market consiste en una playa
de estacionamiento cerrada con capacidad para
60 autos, con 2 puertas de entrada y 4 de salida,
además de un espacio que sirve de almacén de
mercadería. En cada una de las puertas de acce-
so se ubica un especialista, el cual entrega al
cliente una hoja de pedidos, una tarjeta que
contiene el número de estacionamiento desocu-
pado en el cuál necesariamente deberá colocarse
y la puerta de salida que le corresponde. La hoja
de pedidos es un formato previamente estable-
cido, impreso por ambos lados y que detalla las
aproximadamente los 240 productos que se
despachan en 4 columnas de 60 productos cada
una. En esta Hoja de Pedidos el cliente marca
los productos y presentación que desea escri-
Ingeniería de Sistemas
Revisar documentos
Comprador, vendedor
ALTERNATIVAS
Observar documentos
Realizar contrato
Vendedor, comprador, notario
ALTERNATIVAS
Inscribir titulo
Registros públicos
ALTERNATIVAS
Observar uno o más documentos
biendo además la cantidad que requiere. Poste-
riormente un empleado recoge la hoja de pedi-
dos e ingresa con esta hoja al almacén. En este
almacén se encuentran ubicados los productos
en el mismo orden en que figuran en la hoja de
pedidos, con lo que se facilita la labor del em-
pleado de ir llenando un coche con los pedidos
del cliente. Cuando este empleado culmine su
labor retira los productos de almacén con una
guía de salida, quedándose el almacén con la
hoja de pedidos. Luego el empleado lleva esta
guía con los productos a sección caja que consta
de 4 empleados, una en cada puerta de salida y
avisa al cliente que su pedido está listo (mien-
tras el cliente espera en el auto, otro empleado
estaba limpiando su automóvil externamente, de
forma gratuita). El cliente se dirige a la puerta
de salida que le corresponde donde se encontra-
rá su pedido y su factura; entrega su tarjeta
revisa su pedido y al estar conforme cancela con
lo que se termina el servicio.
11
Diagrama de casos de uso

Especialista Entregar tarjetas

Dependiente

Hacer pedidos
Cliente <<include>>

Elaborar guía de salida

Surtir pedido

<<include>>
Almacen

Entregar pedido
Pagar por productos
<<extend>>
Caja

Pagar con tarjeta de credito

Documentación del diagrama de casos de uso

Flujo de eventos del caso de uso Entregar tarjetas
Actor Especialista, cliente

CURSO NORMAL ALTERNATIVAS

Entregar hoja de pedido al cliente
Determinar número de estacionamiento No hay disponible estacionamiento
disponible
Entregar tarjeta de estacionamiento al
cliente, con número de estacionamiento y
puerta de salida que le corresponde

Flujo de eventos del caso de uso Hacer pedidos

Actor Cliente, dependiente

CURSO NORMAL ALTERNATIVAS

El cliente para cada producto: marca el

12 Análisis y diseño de sistemas

producto, su presentación y escribe la can-
tidad en la hoja de pedidos
El cliente entrega la hoja de pedidos al
dependiente
El dependiente verifica la hoja de pedidos

Flujo de eventos del caso de uso Surtir pedido

Actor Dependiente, almacén

CURSO NORMAL ALTERNATIVAS

Para cada producto marcado:
• Ubicar producto
• Seleccionar el producto con la pre- No hay en stock el producto solicitado
sentación y cantidad solicitada.
• Llenar el coche con el producto
Elaborar guía de salida
Entregar tarjeta de pedido al almacén
Retirar productos y guía de salida
Include (Elaborar guía de salida)

Flujo de eventos del caso de uso Elaborar guía de salida

Actor Dependiente, almacén

CURSO NORMAL ALTERNATIVAS

El dependiente transcribe los datos de la
tarjeta de pedido
El dependiente transcribe los datos del
cliente
El dependiente para cada producto rellena
el código del producto y la cantidad.
El almacén verifica la guía de salida y da su El almacén observa la guía de salida
conformidad

Flujo de eventos del caso de uso Entregar pedido

Actor Cliente

CURSO NORMAL ALTERNATIVAS

Entrega su tarjeta de estacionamiento
Confronta su pedido con los productos
Paga por los productos
Recoge sus productos y se retira
Include (Pagar por productos)

Flujo de eventos del caso de uso Pagar por productos

Actor Caja, cliente

CURSO NORMAL ALTERNATIVAS

La caja calcula el monto a pagar
El cliente paga por los productos
La caja imprime su factura
El cliente recoge su factura
(Punto de extensión) Si paga con tarjeta de crédito entonces extend
(Pagar con tarjeta de crédito)

Flujo de eventos del caso de uso Pagar con tarjeta de crédito

Actor Cliente, caja

Ingeniería de Sistemas 13
 CURSO NORMAL ALTERNATIVAS
El cliente entrega su tarjeta de crédito
La caja verifica la tarjeta de crédito
La caja elabora el voucher
El cliente firma el voucher
La caja archiva una copia del voucher y
una copia entrega al cliente

14 Análisis y diseño de sistemas