2.8.

1 Ejemplo de un caso expandido de uso: Preparar Producto

Un caso expandido de uso muestra más detalles que uno de alto nivel; suelen
ser útiles para alcanzar un conocimiento más profundo de los procesos y de los
requerimientos. Se llevan a cabo en un estilo coloquial entre los actores y el sistema.
Ejemplo:

Caso de Uso: Preparar Producto.

Actores: Máquina

Propósito: Preparación del producto solicitado.

Resumen: Un usuario hace uso de la máquina introduciendo el dinero y

seleccionando el producto que desea. Si todo es correcto, la
máquina se encarga de preparar el producto para que el usuario lo
retire.

Tipo: Primario y esencial.

Referencias
Cruzadas: Funciones: R1, R2, R3

Curso normal de los eventos

Acción del actor Respuesta del sistema

1. Este caso de uso comienza cuando el 2. El sistema comprueba que exista el

operario introduce en la máquina el producto solicitado.
dinero e indica el producto que desea.
3. El usuario elige el nivel de azúcar que 4. La máquina inicia el proceso de
desee. preparación y el usuario espera hasta
que esta termina.

Cursos alternos:

 Línea 1: introducción de cantidad de dinero menor que el precio del producto.

Indicar error.

2.8.2 Explicación del formato expandido:

Caso de uso: Nombre del caso de uso.

Actores: Lista de actores(agentes externos), en la cual se indica quién
inicia el caso de uso.
Propósito: Intención del caso de uso.
Resumen: Repetición del caso de uso de alto nivel o alguna síntesis similar.
Tipo: 1. Primario, secundario u opcional.
2. Esencial o real.
Referencias Casos relacionados de uso y funciones también relacionadas del
cruzadas: sistema.
 La sección intermedia, curso normal de los eventos, es la parte principal del
formato expandido; describe los detalles de la conversión interactiva entre los actores y
el sistema. Explica la secuencia más común de los eventos: la historia normal de las
actividades y la terminación exitosa de un proceso. No incluye situaciones alternas.

Curso normal de los eventos:

Acción del actor Respuesta del sistema

Acciones numeradas de los actores. Descripciones numeradas de las respuestas
del sistema.

La última sección, curso alterno de los eventos, describe importantes opciones o

excepciones que pueden presentarse en relación con el curso normal. Si son complejas,
podemos expandirlas y convertirlas en nuestros casos de uso.

Cursos alternos:

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

Diagramas de casos de uso.

Un diagrama de casos de uso explica gráficamente un conjunto de casos de uso

de un sistema, los actores y la relación entre éstos y los casos de uso.

Los casos de uso se muestran en óvalos y los actores en figuras estilizadas. Hay
líneas de comunicaciones entre los casos y los actores; las flechas indican el flujo de la
información o el estímulo.

El objetivo del diagrama es ofrecer una clase de diagrama contextual que nos
permita conocer rápidamente los actores externos de un sistema y las formas básicas en
que lo utilizan.

Máquina de Preparar Producto

Café

Figura 2.3 Diagrama parcial de casos de uso

2.13 Formatos de los casos de uso.

Un mismo caso de uso puede escribirse en diferentes formatos y con diversos

niveles de detalle. Los podemos dividir en: casos con formato de alto nivel y
expandido.

2.13.1 Formato de alto nivel:

Un caso de uso de alto nivel describe un proceso muy brevemente, casi siempre
en dos o tres enunciados. Se aconseja su uso durante el examen inicial de los
requerimientos y del proyecto, para entender de forma rápida el grado de complejidad y
funcionalidad del sistema.

2.13.1 Formato expandido:

Un caso de uso expandido describe un proceso más a fondo que el de alto nivel.
Se diferencia con éste, en que tiene una sección destinada al curso normal de los
eventos, que los describe paso por paso. Durante la fase de especificación de requisitos,
es conveniente escribir en el formato expandido los casos más importantes y de mayor
influencia.

2.14 Los sistemas y sus fronteras.

 Un caso de uso describe la interacción con un sistema. Las fronteras del sistema
son:

 La frontera hardware/software de un dispositivo o sistema de cómputo.

 El departamento de una organización.
 La organización entera.

Caso de uso

Actor

Frontera de un caso de uso

Figura 2.4 Frontera de un caso de uso

Es importante definir la frontera del sistema para identificar lo que es interno o

externo, así como las responsabilidades del sistema. El ambiente externo está
representado únicamente por actores.

Estudiaremos un ejemplo de la influencia que tiene seleccionar la frontera del

sistema: la compra del producto en la máquina de café y en el supermercado. Si
elegimos como “el sistema” el supermercado, el único actor es el usuario y no la
máquina, porque este último es un recurso del supermercado que realiza las funciones.
Pero si escogemos como sistema el hardware y el software de la máquina de café, se
trata como actores al usuario y a la máquina.

Ambas situaciones se ilustran mejor a continuación:

Compra productos

Máquina
Usuario

Prepara producto

Entrega cambio

Puesto de máquina de café

 Compra productos

Usuario

Prepara producto

Entrega cambio

Supermercado

Figura 2.5 Casos de uso y actores cuando las fronteras son distintas

2.15 Casos de uso primarios, secundarios y opcionales.

Los casos de uso se clasifican en:

 Casos primarios de uso: representan los procesos comunes más

importantes, como Preparar Producto.
 Casos secundarios de uso: representan procesos menores o raros, por
ejemplo: Pedir Azúcar.
 Casos opcionales: representan procesos que pueden no abordarse.

2.16 Casos esenciales de uso comparados con los casos reales de uso.

2.16.1 Casos esenciales de uso:

Los casos esenciales de uso son casos expandidos que se expresan en una forma
teórica que contiene pocos detalles de implementación; las decisiones de diseño se
posponen, especialmente las de la interfaz para el usuario. Estos casos describen el
proceso a partir de sus actividades.

Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y
abstracción.

Como ejemplo vamos a ver, un caso de Retiro de efectivo en un cajero

automático, que se expresa de forma esencial.
Acción de los actores Respuesta del sistema
1. El cliente se identifica. 2. Presenta opciones.
3. y así sucesivamente. 4. y así sucesivamente.

La forma en que un cliente se identifica cambia con el tiempo(es una decisión de

diseño), pero forma parte del proceso esencial de que la identificación se realice de
alguna manera.

Conviene crear casos esenciales de uso al comenzar a investigar los

requerimientos, para entender mejor el alcance del problema y las funciones necesarias.
Este tipo de casos permiten captar la esencia del proceso y sus motivos fundamentales,
sin ahondar en detalles de diseño.

2.16.2 Casos reales de uso:

Un caso real de uso describe el proceso a partir de su diseño concreto actual,

sujeto a las tecnologías de entrada y de salida. Cuando se trata de la interfaz para el
usuario, ofrece presentaciones de pantalla y explica la interacción con los artefactos.
Por ejemplo, el caso Retiro de efectivo expresado en forma real:

Acción de los actores Respuesta del sistema

1. El cliente introduce su tarjeta.
3. Introduce el NIP con un teclado
numérico.
5. y así sucesivamente.
2. Pide el número de identificación
personal(NIP).
4. Muestra el menú de opciones.
6. y así sucesivamente.

Observe que la acción esencial del “Cliente se identifica a sí mismo”, se realizó

ahora en la serie de acciones comenzando con “El cliente introduce su tarjeta”.
Los casos reales de uso se crean durante la fase de diseño por ser un elemento de
éste. Sin embargo, en algunos proyectos las primeras decisiones de diseño con respecto
a la interfaz para el usuario, se discuten en la fase de elaboración, debido a esto, se
establecen casos reales en dicha fase.

2.17 Notación de los casos de uso.

2.17.1 Asignación de nombres a los casos de uso:

El nombre de un caso de uso debe comenzar con un verbo para especificar que
se trata de un proceso. Ejemplo:

 Preparar producto.
 Dar cambio.
 Recibir dinero.

2.17.2 Inicio de un caso expandido de uso:

Comience un caso expandido con el siguiente esquema:

1. Este caso comienza cuando <Actor><inicia un evento>
 Por ejemplo:
1. Este caso de uso comienza cuando la máquina recibe el dinero por parte del
usuario.

De esta manera, se identifica claramente el actor y el evento iniciadores.

2.17.3 Decisión de notación y ramificación:

Un caso de uso puede contener puntos de decisión. Si una de las trayectorias de

decisión es un caso muy representativo y las otras alternativas son raras, inusuales o
excepcionales, el caso típico debe ser el único acerca del cual se escribe en el Curso
normal de los eventos y las opciones deben de escribirse en la sección Alternativas.

Cuando el punto de decisión representa opciones cuya probabilidad es igual y

normal, se usa la siguiente forma de notación:

1. En la sección principal Curso normal de los eventos, indique las ramas de

las subsecciones.

2. Escriba una subsección en cada rama, usando otra vez Curso normal de los
eventos. Inicie el evento numerando en 1 cada sección.

3. Si las subsecciones tienen opciones, escríbalas en una sección de

alternativas de cada subsección.

Por ejemplo, supongamos que un solicitante de pedidos puede modificar la cantidad a pedir,
pero siempre por debajo de la cantidad máxima. Esto puede dar origen a dos modos distintos
de realizar un pedido, automático o manual. En el modo automático no se podrá modificar la
cantidad a pedir, mientras que en el modo manual sí. En el modo manual, el actor deberá
confirmar el pedido, para indicar así que no va a realizar más modificaciones.

Sección: principal

Curso normal de los eventos

Acción del actor Respuesta del sistema

1.Este caso de uso comienza cuando el

solicitante de pedido indica el producto para
el que se va a realizar el pedido.
2. El solicitante, puede hacer el pedido de
dos formas:
a) Si lo hace de manera manual, consúltese
la sección Realizar pedido manual.
b) Si lo realiza de forma automática,
consulte la sección Realizar pedido
automático.
3. Comprueba que no exista un pedido
para ese mismo producto.
4. Calcula la cantidad a pedir.
5. Registra el pedido.

Sección: Realizar pedido manual

Curso normal de los eventos

Acción del actor Respuesta del sistema

1. El solicitante realiza el pedido de forma

manual.
2. Comprueba que no exista un pedido
para ese producto.
3. Calcula la cantidad a pedir.
4. Modifica la cantidad a pedir.
5. Confirma el pedido.
6. Registra el pedido.

Cursos alternativos:

Línea 2: Existe un pedido para el producto. Indica error. Finaliza caso de uso.
Línea 4: Cantidad introducida no está dentro de los límites. No permite la modificación.
Sección: Realizar pedido automático.

Curso normal de los eventos

Curso normal de la historia con solicitud manual, exceptuando las líneas 4 y 5.

Cursos alternativos:
Línea 2: Existe un pedido para el producto. Indica error. Finaliza caso de uso.

2.18 Casos de uso dentro de un proceso de desarrollo.

2.18.1 Pasos de la fase de planeación y elaboración:

1. Después de haber listado las funciones del sistema, defina la frontera e

identifique los actores y casos de uso.
2. Escriba todos los casos de uso en el formato de alto nivel. Clasifíquelos en
primarios, secundarios u opcionales.
3. Dibuje el diagrama de casos de uso.
4. Relacione los casos de uso y dé ejemplo de las relaciones en el diagrama
correspondiente.
 5. Escriba en el formato esencial expandido los casos de uso más importantes,
para entender mejor el problema.
6. Los casos reales deberían posponerse hasta una fase de diseño, porque su
creación conlleva decisiones de diseño. Sin embargo, a veces es necesario
crear casos reales de uso durante la etapa de los requerimientos si:

 Las descripciones facilitan la comprensión.

 Los clientes exigen especificar sus procesos en esta forma.

2.18.2 Identifique los actores y casos de uso:

Defina la frontera del sistema que será el sistema de hardware/software. Un

ejemplo de lista de los actores y procesos relevantes son los siguientes:

 El usuario de la máquina.
 Introduce las monedas en la máquina.
 Si lo desea, pide el nivel de azúcar.
 La máquina
 Recibe el dinero.
 Prepara el producto.
 Si es necesario, prepara el cambio.
 Si es necesario, cancela la operación.

2.18.3 Escriba los casos de uso en el formato de alto nivel:

Una muestra de casos de uso de alto nivel comprende:

Caso de uso: Recibir Dinero

Actores: Máquina

Tipo: Primario

Descripción: Antes de realizar cualquier otra operación, la máquina espera el

dinero para almacenarlo y luego brindar el servicio.

2.18.4 Dibuje un diagrama de casos de uso:

Se presenta a continuación el diagrama de nuestro ejemplo:

Recibir dinero

Pedir azúcar
 Figura 2.6 Diagrama de casos de uso de la máquina de café

2.18.5 Relacione los casos de uso:

Este tema se abordará posteriormente.

2.18.6 Escriba algunos casos esenciales expandidos de uso:

Entre los casos primarios de uso realmente significativos figuran:

 Preparar producto.
Escribirlo en una forma esencial expandida suministrará una mayor información
y claridad de los requerimientos. A continuación se presenta el caso de uso Preparar
producto en su forma esencial expandida completa:

Caso de Uso: Preparar Producto.

Actores: Máquina

Propósito: Preparación del producto solicitado.

Resumen: Un usuario hace uso de la máquina introduciendo el dinero y

seleccionando el producto que desea. Si todo es correcto, la
máquina se encarga de preparar el producto para que el usuario lo
retire.

Tipo: Primario y esencial.

Referencias
Cruzadas: Funciones: R1, R2, R3
Curso normal de los eventos

Acción del actor Respuesta del sistema

1. Este caso de uso comienza cuando el 2. El sistema comprueba que exista el

operario introduce en la máquina el producto solicitado.
dinero e indica el producto que desea.
3. El usuario elige el nivel de azúcar que 4. La máquina inicia el proceso de
desee. preparación y el usuario espera hasta que
esta termina.

2.18.7 Si es necesario, escriba algunos casos reales de uso:

Esto se realizará en temas posteriores.

Modelos conceptuales.

El modelo conceptual es el elemento más importante a crear durante el análisis

orientado a objetos1. El paso esencial de un análisis orientados a objetos es
descomponer el problema en conceptos u objetos individuales. Un modelo conceptual
es una representación de conceptos en un dominio del problema. En UML, se ilustra
con un grupo de diagramas de estructura estática donde no se define ninguna
operación. Una cualidad esencial que debe tener un modelo conceptual es que
representa cosas del mundo real, no componentes del software.

Puede mostrarnos:

 Conceptos.
 Asociaciones entre conceptos.
Atributos de conceptos.

2.20.1 Obtención de conceptos a partir de una lista de categorías de conceptos:

Al crear un modelo conceptual, debemos comenzar preparando una lista de

conceptos idóneos a partir de la siguiente lista. Contiene muchas categorías comunes
que se debe tener en cuenta, sin importar el orden de importancia.

Categoría del concepto Ejemplos

Objetos físicos o tangibles Producto
Especificaciones, diseño o descripciones de Catálogo de libros
cosas
Lugares Centro de almacenamiento
Transacciones Venta
Línea o renglón de elemento de Descripción
transacciones
Papel de las personas Bibliotecario, Vendedor.
Contenedores de otras cosas Catálogo
Cosas dentro de un contenedor Producto
Otros sistemas de cómputo o Fax
electromecánicos externos al sistema
Conceptos de nombres abstractos Stock
Organizaciones Universidad
Eventos Robo, incendio
Procesos(a menudo no están representados SolicitarPedido
como conceptos, pero pueden estarlo)
Reglas y políticas TramitarPedidoEspecial
Catálogos CatalogodeProductos
Registros de finanzas, de trabajo, de ContratoProveedor
contratos de asuntos legales
Instrumentos y servicios financieros
Manuales, libros

1
Los casos de uso son importantes en el análisis de requerimientos, pero no están orientados a objetos.
 Identificación de las asociaciones: lista de asociaciones comunes.

Agregue las asociaciones utilizando la lista que se presenta a continuación. El

ejemplo corresponde al dominio de una universidad.

Categoría
A es una parte física de B
A es una parte lógica de B
A está físicamente contenido en B
A está contenido lógicamente en B
A es una descripción de B
A es un elemento de línea en una
transacción o reporte B
A se conoce/introduce/registra/presen-
ta/captura en B
A es miembro de B
A es una subunidad organizacional de B
A usa o dirige a B
A se comunica con B
A se relaciona con una transacción B
A es una transacción relacionada con otra
transacción de B
A es propiedad de B
2.26.1 Asociaciones de alta prioridad:
Ejemplo
Edificio – Universidad
CalificacionesSemestrales –
CalificacionesAnuales
Estudiante – Edificio
Asignatura – Programa de asignatura
Objetivo de asignatura – Asignatura
Nota de Estudiante – Reporte de
Estudiante
Matrícula – Lista de estudiantes
Profesor – Departamento
Secretaría – Departamento
Director – Secretaria
Profesor – Estudiante
Estudiante – Inscripción de curso
Inscripción – Cancelación
Auditorio – Universidad

Las siguientes, son algunas categorías de alta prioridad que siempre conviene
incluir en un modelo conceptual:

 A es una parte física o lógica de B.

 A está física o lógicamente contenido en B.
 A está registrado en B.

2.27 Directrices de las asociaciones.

Es necesario identificar las asociaciones de los conceptos que se requieren para

satisfacer los requerimientos de información de los casos de uso en cuestión y los que
contribuyen a entender el modelo conceptual. Para identificar dichas asociaciones se
deben tomar en cuenta las siguientes directrices:

 Concentrarse en las asociaciones en que el conocimiento de la relación ha de

preservarse durante algún tiempo.
 Es más importante identificar los conceptos que las asociaciones.
 Muchas asociaciones tienden a confundir el modelo conceptual en vez de
aclararlo. A veces se requiere mucho tiempo para descubrirlas, y los
beneficios son escasos.
 No incluir las asociaciones redundantes ni las derivables.
2.28 Papeles.

A los extremos de una asociación se les llama papeles. Estos pueden tener:

 nombre
 expresión de multiplicidad
 navegabilidad

2.28.1 Multiplicidad:

La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una

instancia del tipo B en determinado momento. En el UML, el valor de multiplicidad
depende del contexto. Por ejemplo: