CASOS DE USO

 Planificación y Especificación de Requisitos:

 Estudiar la especificación de requisitos para descubrir las
secuencias típicas de acciones desde la perspectiva del usuario.
Estas acciones son los denominados casos de uso.
 Un caso de uso es una secuencia típica de acciones en un
sistema, desde el punto de vista del usuario, que muestra cómo el
sistema interacciona con el exterior y que se obtiene como
resultado del uso del sistema.
 Los casos de uso son descritos en un documento en el que se
detallan los siguientes puntos de cada uno:
 Nombre del caso de uso
 Actores participantes
 Tipo de caso (importancia del mismo – primario, secundario)
 Descripción del caso de uso

 Análisis:
 Se intenta llegar a una buena comprensión del problema por parte del
equipo de desarrollo, sin entrar en cómo va a ser la solución en cuanto a detalles
de implementación.
 Trabajamos con los modelos de casos de uso construidos en la fase anterior,
ampliándolos y refinándolos.
 Se construye un Modelo de Objetos Conceptual o Modelo de Análisis
mediante un diagrama de clases, compuesto de clases y relaciones entre
las clases.
 En el Modelo de Objetos Conceptual se tiene una representación de
conceptos (objetos - clases) del mundo real, es una primera aproximación al
modelo de diseño.
 Se deberán identificar los conceptos más importantes del sistema
(objetos físicos, roles de una persona, etc.), los atributos de los mismos y
las relaciones existentes entre ellos. Por ejemplo, en un sistema bancario se
pueden identificar conceptos como cuenta, cliente, tarjeta de crédito, saldo,
recibo, etc.
 EL PROCESO DE DESARROLLO

MODELO DE CASOS DE USO MODELO DE ANÁLISIS

• Descrito en el lenguaje del cliente • Descrito en el lenguaje

del desarrollador
• Vista externa del sistema • Vista interna del sistema
DIFERENCIAS

• Utilizado fundamentalmente • Utilizado fundamentalmente por

como contrato entre el cliente y los desarrolladores para
los desarrolladores sobre qué comprender cómo debería darse
debería y que no debería hacer el forma al sistema, es decir, como
sistema debería ser diseñado e
implementado
• Captura la funcionalidad del • Esboza como llevar a cabo la
sistema desde el punto de vista funcionalidad dentro del
del usuario sistema, incluida la
funcionalidad significativa
para la arquitectura

CASO DE USO
Un caso de uso es una descripción de la secuencia de interacciones que se
producen entre un actor y el sistema, cuando el actor usa el sistema para llevar
a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y
se representa en el Diagrama de Casos de Uso mediante una elipse con el
nombre del caso de uso en su interior. El nombre del caso de uso debe
reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.
Relaciones entre Casos de Uso

Entre dos casos de uso puede haber las siguientes relaciones:

 Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad.
 Usa: Cuando un caso de uso utiliza a otro.
Se representan como una línea que une a los dos casos de uso relacionados,
con una flecha en forma de triángulo y con una etiqueta <<extiende>> o
<<usa>> según sea el tipo de relación.
En el diagrama de casos de uso se representa también el sistema como una
caja rectangular con el nombre en su interior. Los casos de uso están en el
interior de la caja del sistema, y los actores fuera, y cada actor está unido a los
casos de uso en los que participa mediante una línea. En la Figura 15 se
muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.

Cajero Automático

Realizar Reintegro

Cambiar PIN <<extiende>>

Realizar
Cliente Reintegro
con VISA
Obtener Últimos
Movimientos y Saldo

Agregar
Billetes

Empleado de
Sucursal

Figura 15 Diagrama de Casos de Uso

IV.1.1 Casos de Uso
Un Caso de Uso es un documento narrativo que describe la secuencia de
eventos de un actor (un agente externo) que usa un sistema para completar un
proceso [Jacobson92]. Es una historia o una forma particular de usar un
sistema. Los casos de uso no son exactamente requisitos ni especificaciones
funcionales, pero ilustran e implican requisitos en las historias que cuentan.
En la página 9 se definió la notación de UML para los Diagramas de Casos de
Uso. Nótese que UML no define un formato para describir un caso de uso.
Tan sólo define la manera de representar la relación entre actores y casos de
uso en un diagrama (Diagrama de Casos de Uso). El formato textual que se va
a usar en este texto para definir los caso de uso se va a definir a continuación,
mientras que la representación de los escenarios correspondientes a un caso
de uso por medio de Diagramas de Secuencia se verá más adelatnte.
En un primer momento interesa abordar un caso de uso desde un nivel de
abstracción alto, es lo que se denomina Caso de Uso de Alto Nivel.
IV.1.1.1 Casos de Uso de Alto Nivel

El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar

dinero cuando se está usando un cajero automático:
 Caso de Uso: Realizar Reintegro
 Actores: Cliente
 Tipo: primario
 Descripción: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y
solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el
dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero
y la tarjeta y se va.
En un caso de uso descrito a alto nivel la descripción es muy general,
normalmente se condensa en dos o tres frases. Es útil para comprender el
ámbito y el grado de complejidad del sistema.
IV.1.1.2 Casos de Uso Expandidos

Los casos de uso que se consideren los más importantes y que se considere
que son los que más influencian al resto, se describen a un nivel más
detallado: en el formato expandido.
La principal diferencia con un caso de uso de alto nivel está en que incluye un
apartado de Curso Típico de Eventos, pero también incluye otros apartados
como se ve en el siguiente ejemplo:
 Caso de Uso: Realizar Reintegro
 Actores: Cliente (iniciador)
 Propósito: Realizar una operación de reintegro de una cuenta del banco.
 Visión General: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y
solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el
dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero
 y la tarjeta y se va.
 Tipo: primario y esencial
 Referencias: Funciones: R1.3, R1.7
 Curso Típico de Eventos:
 Acción del Actor Respuesta del Sistema

1. Este caso de uso empieza cuando un Cliente

introduce una tarjeta en el cajero. 2. Pide la clave de identificación.
3. 4. Presenta las opciones de operaciones
Introduce la clave.
disponibl
es.
5. Selecciona la operación de Reintegro. 6. Pide la cantidad a retirar.

8. Procesa la petición y, eventualmente, da

7. Introduce la cantidad requerida. el dinero solicitado.
Devuelve la tarjeta y genera un recibo.

9. Recoge la tarjeta.

10. Recoge el recibo.

11. Recoge el dinero y se va.

Cursos Alternativos:
 Línea 4: La clave es incorrecta. Se indica el error y se cancela la operación.
 Línea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la
operación.
El significado de cada apartado de este formato es como sigue:
 Caso de Uso: Nombre del Caso de Uso
 Actores: Lista de actores (agentes externos), indicando quién inicia el caso de uso. Los
actores son normalmente roles que un ser humano desempeña, pero puede ser cualquier tipo
de sistema.
 Propósito: Intención del caso de uso.
 Visión General: Repetición del caso de uso de alto nivel, o un resumen similar.
 Tipo: 1. primario, secundario u opcional (descritos más adelante).
2. esencial o real (descritos más adelante).
 Referencias: Casos de uso relacionados y funciones del sistema que aparecen en los
requisitos.
 Curso Típico de Eventos: Descripción de la interacción entre los actores y el sistema
mediante las acciones numeradas de cada uno. Describe la secuencia más común de
eventos, cuando todo va bien y el proceso se completa satisfactoriamente. En caso de haber
alternativas con grado similar de probabilidad se pueden añadir secciones adicionales a la
sección principal, como se verá más adelante.
 Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con la
descripción de la excepción.
IV.1.1.3 Identificación de Casos de Uso

La identificación de casos de uso requiere un conocimiento medio acerca de

los requisitos, y se basa en la revisión de los documentos de requisitos
existentes, y en el uso de la técnica de brainstorming entre los miembros del
equipo de desarrollo.
Como guía para la identificación inicial de casos de uso hay dos métodos:

a) Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la organización.
2. Para cada actor, identificar los procesos que inicia o en los que participa.

b) Basado en Eventos
1. Identificar los eventos externos a los que el sistema va a tener que responder.
2. Relacionar los eventos con actores y casos de uso.

Ejemplos de casos de uso:

 Pedir un producto.
 Matricularse en un curso de la facultad.
 Comprobar la ortografía de un documento en un procesador de textos.
 Realizar una llamada telefónica.

IV.1.1.4 Identificación de los Límites del Sistema

En la descripción de un caso de uso se hace referencia en todo momento al

“sistema”. Para que los casos de uso tengan un significado completo es
necesario que el sistema esté definido con precisión.
Al definir los límites del sistema se establece una diferenciación entre lo que
es interno y lo que es externo al sistema. El entorno exterior se representa
mediante los actores.
Ejemplos de sistemas son:
 El hardware y software de un sistema informático.
 Un departamento de una organización.
 Una organización entera.
Si no se está haciendo reingeniería del proceso de negocio lo más normal es
escoger como sistema el primero de los ejemplos: el hardware y el software
del sistema que se quiere construir.
IV.1.1.5 Tipos de Casos de Uso

a) Según Importancia

Para poder priorizar los casos de uso que identifiquemos los vamos a distinguir entre:
 Primarios: Representan los procesos principales, los más comunes, como Realizar
Reintegro en el caso del cajero automático.
 Secundarios: Representan casos de uso menores, que van a necesitarse raramente, tales
como Añadir Nueva Operación.
 Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto.

b) Según el Grado de Compromiso con el Diseño

En las descripciones que se han visto anteriormente no se han hecho apenas

compromisos con la solución, se han descrito los casos de uso a un nivel
abstracto, independiente de la tecnología y de la implementación. Un caso de
uso definido a nivel abstracto se denomina esencial. Los casos de uso
definidos a alto nivel son siempre esenciales por naturaleza, debido a su
brevedad y abstracción.
Por el contrario, un caso de uso real describe concretamente el proceso en
términos del diseño real, de la solución específica que se va a llevar a cabo. Se
ajusta a un tipo de interfaz específica, y se baja a detalles como pantallas y
objetos en las mismas.
Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro
en un cajero automático tenemos la siguiente descripción del Curso Típico de
Eventos:

Acción del Actor Respuesta del Sistema

1. Este caso de uso empieza cuando un

Cliente introduce una tarjeta en la ranura 2. Pide el PIN (Personal Identification
para tarjetas. Number).

3. Introduce el PIN a través del 4. Presenta las opciones de operaciones

teclado numérico. disponibles.

5. etc. 6. etc.

En principio, los casos de uso reales deberían ser creados en la fase de Diseño
y no antes, puesto que se trata de elementos de diseño. Sin embargo, en
algunos proyectos se plantea la definición de interfaces en fases tempranas del
ciclo de desarrollo, en base a que son parte del contrato. En este caso se
pueden definir algunos o todos los casos de uso reales, a pesar de que
suponen tomar decisiones de diseño muy pronto en el ciclo de vida.
No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el
grado de compromiso con el Diseño es un continuo, y una descripción
específica de un caso de uso estará situada en algún punto de la línea entre
Casos de Uso Esenciales y Reales, normalmente más cercano a un extremo
que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales puros.
IV.1.1.6 Consejos Relativos a Casos de Uso

a) Nombre
El nombre de un Caso de Uso debería ser un verbo, para enfatizar que se trata de un
proceso, por ejemplo: Comprar Artículos o Realizar Pedido.
 b) Alternativas equiprobables

Cuando se tiene una alternativa que ocurre de manera relativamente ocasional,

se indica en el apartado Cursos Alternativos. Pero cuando se tienen distintas
opciones, todas ellas consideradas normales se puede completar el Curso
Típico de Eventos con secciones adicionales.
Así, si en un determinado número de línea hay una bifurcación se pueden
poner opciones que dirigen el caso de uso a una sección que se detalla al final
del Curso Típico de Eventos, en la siguiente forma:
 Curso Típico de Eventos:
 Sección: Principal

Acción del Actor Respuesta del Sistema

1. Este caso de uso empieza cuando

Actor 2. Pide la operación a realizar.
llega al sistema.

3. Escoge la operación A. 4. Presenta las opciones de pago.

5. Selecciona el tipo de pago:

a. Si se paga al contado ver
sección Pago al Contado. 6. Genera recibo.
b. Si se paga con tarjeta ver
sección Pago con Tarjeta.

7. Recoge el recibo y se va.

Cursos Alternativos:
 Líneas 3 y 5: Selecciona Cancelar. Se cancela la operación.
 Sección: Pago al Contado

Acción del Actor Respuesta del Sistema

1. 2. Coge los billetes y sigue pidiendo dinero

Mete los billetes correspondientes hasta que la cantidad está
satisfecha
3. Devuelve el cambio.

Cursos Alternativos:
 Línea 3: No hay cambio suficiente. Se cancela la operación.

 Sección: Pago con Tarjeta

...
IV.1.2 Construcción del Modelo de Casos de Uso

Para construir el Modelo de Casos de Uso en la fase de Planificación y

Especificación de Requisitos se siguen los siguientes pasos:
1. Después de listar las funciones del sistema, se definen los límites del sistema y se
identifican los actores y los casos de uso.
2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como
primarios, secundarios u opcionales.
3. Se dibuja el Diagrama de Casos de Uso.
4. Se relacionan los casos de uso y se ilustran las relaciones en el Diagrama de Casos de Uso
(<<extiende>> y <<usa>>).
5. Los casos de uso más críticos, importantes y que conllevan un mayor riesgo, se describen en
el formato expandido esencial. Se deja la definición en formato expandido esencial del resto
de casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar
toda la complejidad del problema de una sola vez.
6. Se crean casos de uso reales sólo cuando:
 Descripciones más detalladas ayudan significativamente a incrementar la comprensión
del problema.
 El cliente pide que los procesos se describan de esta forma.
7. Ordenar según prioridad los casos de uso (este paso se va a ver a continuación).

IV.1.3 Planificación de Casos de Uso según Ciclos de Desarrollo

La decisión de qué partes del sistema abordar en cada ciclo de desarrollo se va
a tomar basándose en los casos de uso. Esto es, a cada ciclo de desarrollo se le
va a asignar la implementación de uno o más casos de uso, o versiones
simplificadas de casos de uso. Se asigna una versión simplificada cuando el
caso de uso completo es demasiado complejo para ser tratado en un solo
ciclo (ver Figura 35).

Ciclo de Desarrollo Ciclo de Desarrollo Ciclo de Desarrollo

Caso de Uso A Caso de Uso A Caso de Uso B

Versión Versión
Simplificada Completa --------

Caso de Uso C

Figura 35 Planificación de Ciclos de Desarrollo según Casos de Uso

Para tomar la decisión de qué casos de uso se van a tratar primero es necesario
ordenarlos según prioridad. Las características de un caso de uso específico
que van a hacer que un caso de uso tenga una prioridad alta son las siguientes:
a. Impacto significativo en el diseño de la arquitectura. Por ejemplo, si aporta muchas clases al
modelo del dominio o requiere persistencia en los datos.
b. Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo relativamente bajo.
c. Incluye funciones complejas, críticas en el tiempo o de nivel elevado de riesgo.
d. Implica bien un trabajo de investigación significante, o bien el uso de una
tecnología nueva o arriesgada.
e. Representa un proceso de gran importancia en la línea de negocio.
f. Supone directamente un aumento de beneficios o una disminución de costes.
Para realizar la clasificación se puede asignar a cada caso de uso una
valoración numérica de cada uno de estos puntos, para conseguir una
puntuación total aplicando pesos a cada apartado. En la siguiente
tabla se muestra un ejemplo de tal tipo de clasificación:

Peso 3 2 4 1 3 4
Caso de Uso a b c d e f Suma

Reintegro 5 4 1 0 5 2 5
0
...

IV.1.3.1 Caso de Uso Inicialización

Prácticamente todos los sistemas van a tener un caso de uso

Inicialización. Aunque puede ser que no tenga una prioridad alta en
la clasificación realizada según el punto anterior, normalmente va a
interesar que sea desarrollado desde el principio. Inicialmente se
desarrolla una versión simplificada, que se va completando en cada
ciclo de desarrollo para satisfacer las necesidades de inicialización
de los casos de uso que se tratan en dicho ciclo. Así se tiene un
sistema en cada ciclo de desarrollo que puede funcionar.