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

CASOS DE USO
Máquina de Café
Un diagrama de casos de uso muestra las distin-
Desarrollar el control de una máquina automáti- tas operaciones que se esperan de una aplicación
ca de entrega de café, con las siguientes caracte- o sistema y cómo se relaciona con su entorno
rísticas: (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 Cuando necesitemos conocer más detalles acer-
texto (hijos) son especializaciones de presentar ca del caso de use recurrimos a otros tipos de
información (padre). diagramas que estén más relacionados con el
enfoque orientado a objetos.
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»
relación «extend»
AI desarrollar un Diagrama de Casos de Uso a Una relación «extend» entre casos de use signi-
menudo nos encontramos con casos de uso que fica que se ejecuta el caso de uso base pero, bajo
son incluidos como parte de otro u otros casos ciertas condiciones, este caso de uso llama a
de uso, y es que algunos casos de use pueden otro caso de uso que extiende el comportamien-
compartir un comportamiento común. Este to del primero. Esto significa que el caso de
comportamiento común es "factorizado" en caso de uso base implícitamente incorpora el
versiones de casos de use especializados. comportamiento de otro caso de uso.

Una Relación «include» entre casos de uso Se debe utilizar para modelar la parte del caso
significa que el caso de uso base incorpora ex- de uso que tiene un comportamiento opcional,
plícitamente el comportamiento de otro caso de así podemos separar el comportamiento que
uso. El caso de uso base siempre utiliza al caso siempre ocurrirá del comportamiento que ocu-
de use incluido. El objetivo de la relación «in- rrirá bajo ciertas condiciones.
clude» es permitir invocar el mismo comporta-
miento muchas veces, colocando el comporta- Para encontrar las relaciones «extend», debemos
miento común en un caso de use que puede ser observar los casos de uso similares, pero que
invocado por otro a otros casos de uso. contengan alguna diferencia en cómo realizan
las operaciones y qué casos de uso redefinen la
De manera general una relación «include», es forma de realizar éstas operaciones dentro de
una relación de dependencia, puesto que su otro caso de uso. Se debe pensar en la conducta
ejecución depende siempre del caso de use base, normal en un caso y la conducta inusual en otro
pues es éste el que lo invoca. El caso de use caso, unidos por la relación «extend».
incluido no puede ejecutarse sin el caso de use
que lo incluye. De manera general una relación «extend», es
también una relación de dependencia, puesto
La relación «include» es también un ejemplo de que el caso de uso extendido entra en acción
delegación, pues tomamos un grupo de respon- dependiendo de las condiciones que se den al
sabilidades del sistema y los ubicamos en un efectuarse el caso de uso base. Recuerde que el
lugar (el caso de use incluido), el cual es "invo- caso de use extendido, sólo se utilizará bajo
cado" por otro caso de use cuando necesitamos ciertas condiciones.
usar esa funcionalidad.

Hasta antes de la versión 1.3 de UML, este tipo <<extend>>

de relación fue llamada Relación de Uso y se le Retirar dinero Exceder Limite
estereotipaba como «uses», pero la bibliografía
oficial del UML 1.3 ya no consigna este nom- Puntos de extensión de los casos de uso
bre, razón por la cual siempre nos referiremos a
ella como la relación «include». Una forma de extender la especificación de un
caso de uso se da dentro de la misma elipse que
Observe que la utilización de la relación «inclu- lo representa mediante una cabecera denomina-
de», esta más ligada al concepto de descompo- da Extension Point. Un caso de use puede tener
sición funcional (muy común en los modelos más de un punto de extensión. Dentro de las
estructurados) que a los conceptos orientados a elipses también se pueden mostrar comparti-
objetos. Esto es así, porque los casos de use mentos presentando atributos, operaciones y por
solamente nos sirven para averiguar lo que el supuesto puntos de extensión. La descripción de
usuario necesita del sistema y no cómo lo hace. la extensión normalmente se realiza en texto
Ingeniería de Sistemas 3
ordinario, pero también se puede especificar en En la relación «extend» los Actores siguen "co-
otras formas, como: un diagrama de estados, o nectados" con los casos de use extendidos. En la
mediante pre o postcondiciones. relación «include», es el caso de use base el que
se "conecta" con el caso de use incluido al invo-
Cobro en efectivo carlo.
<<extend>>
Si es efectivo Resumen

Realizar cobro Los casos de uso:

extension points ¾ Define el sistema.
Cuando el cliente paga
¾ Ayuda a enfocar el problema.
¾ Permita incremento y el desarrollo paralelo.
<<extend>> <<extend>> ¾ Mejore la estimación.
Sí es cheque Sí es tarjeta
¾ Es mejor tener un caso del uso extenso que
Cobro con tarjeta de credito varios pequeños.
Cobro con cheque
Ejemplo:
Cuando usar <<incluye>> y <<extend>> Sistema de matricula
En una universidad particular cada semestre los
Ambos tipos de relación implican la factoriza- estudiantes registran su matricula seleccionado
ción de comportamientos comunes de varios los cursos que van a llevar durante el semestre.
casos de uso; sin embargo, en la relación «in- De igual manera los profesores seleccionan los
clude» se trata de factorizar comportamiento cursos que van a enseñar en el semestre. Cada
comunes para no repetir la definición y los ca- vez que el estudiante se matricula esta informa-
sos de use factorizados pueden ser utilizados por ción se envía a tesorería ( considerado fuera del
otros casos de uso; mientras que en la delación sistema) para que se encargue del control de su
«extend» se tienen en cuenta los factores varian- cuenta corriente.
tes, esto es casos que ocurren bajo ciertas cir-
cunstancias, poniendo este comportamiento en El asistente es una persona que se encarga del
otro caso de use extendiendo al caso base. Se mantenimiento del sistema de matriculas, cuyas
debe organizar los casos de use extrayendo el funciones son: mantener el plan de estudios,
comportamiento común mediante relaciones actualizar la información del estudiante y actua-
«include» y distinguiendo las variaciones me- lizar la información del profesor. El asistente
diante relaciones «extend», con el objetivo de utiliza una PC para realizar sus funciones y para
crear un simple, balanceado y comprensible ello tiene asignado un nombre de usuario con
conjunto de casos de use para su sistema. los privilegios necesarios.

4 Análisis y diseño de sistemas

 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- Describe concretamente el proceso a partir de su
tantes. Por ejemplo, en un sistema de Ventas: diseño actual, sujeto a las tecnologías especifi-
Registrar ventas, comprar ventas, etc. cas de entrada y de salida, etc. Cuando se trata
Casos secundarios de uso de una interfaz de usuario se explica la interac-
ción del usuario con el sistema.
Representan procesos menores o raros. Por
ejemplo, en un sistema de Ventas: Estadística de FORMATOS DE CASO DE USO
ventas por producto.
Los formatos de caso de uso que se utilizan son:
Casos opcionales de uso
Formato caso de uso de alto nivel
Representan proceso que no pueden abordarse.
Por ejemplo en un sistema de ventas: compor- Hace una breve descripción del sistema, casi
tamiento del precio costo de un producto en siempre usando 2 ó 3 enunciados. Generalmente
particular. 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 las actividades y la terminación exitosa de un
importantes y de mayor influencia; en cambio proceso. No incluye las situaciones alternas.
los menos importantes pueden posponerse hasta
Curso alternos
el ciclo de desarrollo.
Curso normal de los eventos Describe las opciones o excepciones que pueden
presentarse en relación al curso normal. Sin son
Describe los detalles de la interacción de los complejas podemos expandirlas y convertirlas
actores con el sistema. Explica la secuencia más en otros diagramas de caso de uso.
común de los eventos: el desarrollo normal de

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.
ños perjudiciales. En este caso veremos como
SISTEMA DE ASESORÍA LEGAL EN TRANSFE- opera el sistema después de recibir al potencial
RENCIAS INMOBILIARIA. comprador, el cuál ya sabe que inmueble desea-
ría adquirir.
Tenemos en esta oportunidad un estudio jurídi-
co que realiza diversas tareas, pero nos circuns- Simplificando las funciones de este sistema y
cribimos estrictamente a las funciones relacio- concentrándonos sobre todo en los flujos de
nadas con el servicio de asesoría legal en trans- documentos podemos establecer las siguientes
ferencias inmobiliarias y las consideramos como relaciones (la letra corresponde al ente que se
un sistema, que encontramos relacionado con quiere establecer):
los siguientes entes:
A. Se pide al vendedor (que puede ser directa-
A. Vendedores mente el propietario o un representante) su
B. Registros públicos titulo de propiedad que lo acredita como
C. Municipios propietario del inmueble.
D. Notarias
B. Con los datos del inmueble, se solicita en los
Cuando una persona va a adquirir un inmueble Registros Públicos un Certificado de Gra-
es conveniente rodearse de la necesaria seguri- vámenes y una copia Literal del Dominio,
dad legal para evitar riesgos de estafas o enga- que son documentos necesarios para brindar
Ingeniería de Sistemas 9
 las seguridades legales del caso. Luego des- • Certificado de Gravámenes
pués de realizar lo indicado en ¨D¨ se envían • Copia Literal de Dominio
la minuta y otros documentos para obtener la
Escritura Pública. Al obtener todos los documentos, formamos
con ellos un expediente y pasamos a la si-
C. Se gestiona en el Municipio correspondiente guiente etapa.
una copia de la última declaración jurada de
autovalúo. 2. Revisar documentos; se verifican ciertos
aspectos relevantes desde el punto de vista
D. Se realiza un contrato privado de compra - legal y si todo esta conforme, pasamos a la
venta, el cuál luego de firmado se envía a al- siguiente etapa.
guna Notaría, para que lo transcriban en
forma de minuta. 3. Realizar contrato; que incluye la redacción
del mismo, la firma, la presentación en la
Nos referimos a las funciones que se dan en este Notaría y la recepción de la minuta.
sistema, las que se pueden dividir en las siguien-
tes. 4. Inscripción del Título; se acompaña a la
minuta otros documentos (básicamente los
1. Gestionar documentos; recordemos que mencionados en ¨1¨), y con estos se gestiona
debemos gestionar y obtener los siguientes en los Registros Públicos la inscripción del
documentos: Título para obtener así la Escritura Pública
correspondiente.
• Título de propiedad
• Declaración jurada de Autovalúo

Diagrama de casos de uso

Municipalidad

Vendedor Gestionar documentos

Registros publicos
Revisar documentos Comprador

Realizar contrato
Notario
Inscribir titulo

Documentación del diagrama de casos de uso

Flujo de eventos del caso de uso Gestionar documentos
Actor Vendedor, Municipalidad, Registros Públicos

CURSO NORMAL ALTERNATIVAS

Solicitar titulo de propiedad al vendedor

10 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 Revisar documentos

Actor Comprador, vendedor

CURSO NORMAL ALTERNATIVAS

Obtener todos los documentos solicitados
Evaluar aspectos legales de cada documento
Dar conformidad de los documentos Observar documentos

Flujo de eventos del caso de uso Realizar contrato

Actor Vendedor, comprador, notario

CURSO NORMAL ALTERNATIVAS

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 Inscribir titulo

Actor Registros públicos

CURSO NORMAL ALTERNATIVAS

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 Observar uno o más documentos
Entregar escritura pública al comprador

SISTEMA AUTO-MARKET biendo además la cantidad que requiere. Poste-

riormente un empleado recoge la hoja de pedi-
El Auto-Market es un sistema novedoso, único dos e ingresa con esta hoja al almacén. En este
en su género. Se trata de un mercado de aten- almacén se encuentran ubicados los productos
ción exclusiva de clientes en automóvil, los en el mismo orden en que figuran en la hoja de
cuales no descienden del mismo para hacer sus pedidos, con lo que se facilita la labor del em-
compras. El Auto-Market consiste en una playa pleado de ir llenando un coche con los pedidos
de estacionamiento cerrada con capacidad para del cliente. Cuando este empleado culmine su
60 autos, con 2 puertas de entrada y 4 de salida, labor retira los productos de almacén con una
además de un espacio que sirve de almacén de guía de salida, quedándose el almacén con la
mercadería. En cada una de las puertas de acce- hoja de pedidos. Luego el empleado lleva esta
so se ubica un especialista, el cual entrega al guía con los productos a sección caja que consta
cliente una hoja de pedidos, una tarjeta que de 4 empleados, una en cada puerta de salida y
contiene el número de estacionamiento desocu- avisa al cliente que su pedido está listo (mien-
pado en el cuál necesariamente deberá colocarse tras el cliente espera en el auto, otro empleado
y la puerta de salida que le corresponde. La hoja estaba limpiando su automóvil externamente, de
de pedidos es un formato previamente estable- forma gratuita). El cliente se dirige a la puerta
cido, impreso por ambos lados y que detalla las de salida que le corresponde donde se encontra-
aproximadamente los 240 productos que se rá su pedido y su factura; entrega su tarjeta
despachan en 4 columnas de 60 productos cada revisa su pedido y al estar conforme cancela con
una. En esta Hoja de Pedidos el cliente marca lo que se termina el servicio.
los productos y presentación que desea escri-

Ingeniería de Sistemas 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