4 EspecificacionCasosDeUso

Curso: "Análisis y Diseño Orientado a Objetos" 2011
“Casos de Uso, segunda parte“
Módulo 2
© Todos los logos y marcas utilizados

en este documento, están registrados y
pertenecen a sus respectivos dueños.
DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 1

LICENCIA: http://creativecommons.org/licenses/by-nc/2.5
Objetivos
Seguir tratando un compendio de conceptos y guías generales sobre el tema de los
Casos de Uso y cómo documentarlos más allá de los diagramas, colocando el foco en
intentar resolver las diferencias de diagramas vistos en la entrega de la tarea anterior.

Descripción de Casos de Uso

Los diagramas de casos de uso, como todo diagrama UML, están sujetos a
interpretación, y el gráfico por sí mismo no es información suficiente. Estos deben estar
acompañados de una documentación que los explique y describa.
Hay muchos estilos para documentar casos de uso. Se pueden describir formal o
informalmente, en forma textual o a través de diagramas.
El conjunto de casos de usos determina la completa funcionalidad del sistema.
Cada caso de uso tiene:
 Un curso básico, que es la secuencia más importante de eventos.
 Puede tener variantes del curso básico que son los cursos alternativos
 Puede tener varios cursos de excepción para el manejo de errores.
Veamos algunos ejemplos de descripción de casos de uso utilizando algunos de los

diferentes estilos:

Ejemplos
Caso de Uso Informal de un ATM (“cajero automático”)
1. Cuando el usuario inserta su tarjeta, el cajero lee el código y verifica con el

sistema central. Si la tarjeta es válida, le pide al usuario su PIN. Si no, la tarjeta
es devuelta.
2. Cuando el usuario ingresa el PIN, el cajero verifica si es correcto. Si lo es, el

cajero solicita la transacción que desea realizar.
3. Cuando el usuario selecciona “retiro de dinero”, el cajero le pide el monto
4. …

Caso de Uso – Diagrama de Secuencia

Caso de Uso Formal

Ejemplo de "Cursos Básicos" y "Cursos Alternativos"

Retiro de caja de ahorro
Curso Básico
1. El cliente busca la primera caja libre para realizar un retiro.
2. El cajero le solicita al cliente el nro. de cuenta y verifica si existe.
3. Posteriormente, el cajero solicita el monto del retiro
4. El cajero solicita al sector de cajas de ahorros el saldo
5. El cajero entrega el saldo al cliente
6. El cliente cuenta el dinero
7. El cliente se retira
Curso Alternativo
1. Si no existe una caja libre, espera o se retira del banco
2. Si el nro. de cuenta es incorrecto, se solicita un nuevo número
3. Si el monto del retiro supera el saldo, el cajero le comunica al cliente
4. etc.

Caso de Uso – "Conversacional"
Cajero Sistema
1. El cajero ingresa el nro. de cuenta
2. El sistema verifica el nro. de cuenta,

identificando al cliente, desplegando estos
datos en pantalla
3. El cajero selecciona retiro en

mostrador
4. El sistema solicita el monto a retirar
5. El cajero ingresa el monto
6.El sistema actual despliega el saldo

Plantillade Caso de Uso

Una posible forma de detallar cada caso de uso es completando la siguiente plantilla:
 Nombre del Caso de Uso

 Actores
 Tipo
 Descripción
 Pre-condición
 Curso Básico
 Cursos Alternativos
 Cursos de Excepción
 Post-condición
 Requerimientos no funcionales para el caso de uso
Explicación
 Tipo: indica si el caso de uso es:
o primario: caso de uso de un actor primario
o secundario: caso de uso de un actor secundario
 Pre y Post condición:
o Definen los valores de una serie de variables del sistema, antes y

después de la “ejecución” del caso de uso.
o La definición de las pre y pos condiciones normalmente se difieren

para la fase de diseño.
 Requerimientos no funcionales:
o Los requerimientos puedes dividirse en requerimientos funcionales y

requerimientos no funcionales. Los requerimientos funcionales definen
las funciones que el sistema será capaz de realizar. Describen las
transformaciones que el sistema realiza sobre las entradas para
producir salidas. Los requerimientos no funcionales tienen que ver con
características que de una u otra forma puedan limitar el sistema,
como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de

usuario, fiabilidad (robustez del sistema, disponibilidad de equipo),
mantenimiento, seguridad, portabilidad, estándares, etc.
Ejemplos
Caso de Uso: Asignar asiento en un vuelo
Pre-condición: el pasajero tiene una reservación en el vuelo
[…]
Post-condición: el pasajero o tiene un asiento asignado o está en espera para ser

asignado en orden de llegada.

Guías Generales
Los casos de uso bien estructurados denotan el comportamiento esencial del

sistema y no deben ser ni demasiado generales ni demasiado específicos. La falta de
detalle tiende hacia la ambigüedad y la mala interpretación, mientras que el excesivo
detalle suele hacerlos más difíciles de comprender.
Es recomendable emplearnombrespara los casos de uso que sean simples,

identificables y que representen comportamiento razonablemente atómico del sistema.
Una buena guía suele ser comenzar los nombres de los casos de uso con un verbo
(ej. Registrar Pedido), lo que denota acción y ayuda a identificar claramente el objetivo
del mismo. Se recomienda también utilizar terminología especifica del dominio de
negocios al escribir los casos de uso, ya que es la terminología común a todos los
participantes del proyecto.
Generalmente ayuda mostrar sólo aquellos casos de uso que son importantes para
comprender el comportamiento del sistema, y solo aquellos actores que están
relacionados con el caso de uso.
Uno de los elementos que ayuda a decidir el nivel de detalle con el que se debe
especificar un caso de uso es el riesgo asociado al mismo. Cuanto más alto sea el
riesgo o la importancia del caso de uso, más nivel de detalle se deberá utilizar para
especificarlo. Generalmente se suele documentar al máximo nivel de detalle durante la
elaboración del documento en solo algunos casos de uso. Luego, conformeavanzan las
iteraciones del proyecto, es posible agregar más detalle según sea necesario para la
implementación.

Técnicas Comunes de Modelado

Dado un sistema, cualquier sistema, algunas cosas viven "dentro" y otras "fuera".
Supongamos un sistema de validación de tarjetas, para modelar el contexto de un

sistema, debemos:
1. Identificar a los actores (alrededor del sistema)
2. Organizar a los actores (aquellos que sean similares)
3. Colocar los diagramas de Casos de Uso y proveer los caminos de comunicación

con los actores del sistema.
Ejemplo

Guía de Procedimiento
1. Establezca el contexto del sistema identificando los actores que lo rodean

2. Para cada actor considere el comportamiento que requiere el sistema
3. Nombre ese comportamiento común como mediante casos de uso
4. "Factoree" (*) los casos de uso
5. Modele los casos de uso, actores y sus relaciones mediante el diagrama
6. Adorne los casos de uso mediante notas sobre los requerimientos No

Funcionales
(*) Se usa en matemáticas
Definición:Factorizar o factorear una expresión algebraica es convertirlo o

descomponerlo en un producto de expresiones algebraicas más simples.
Por ejemplo, si vemos uno de los primeros ejemplos donde existía un solo caso de uso
"sistema de...", deberíamos "factorearlo" en varios casos de uso más simples, ya que la
abstracción era demasiado alta.

Especificación de Casos de Uso

Una especificación de casos de uso debería responder a las siguientes preguntas
elementales:
 ¿Quién? (el actor)
 ¿Por qué? (la meta y/o contexto)
 ¿Cuando? (el evento que lo genera)
 ¿Qué? (el flujo normal)
 ¿Qué más? (los flujos alternativos y/o excepciones)
Un caso de uso debe describir, sin ambigüedad, un comportamiento requerido, ni

más, ni menos.Desde el punto de vista de la descripción surge la siguiente pregunta:
¿Cuándo es suficiente detalle?

Ejemplo
Caso de Uso: Retirar Fondos (curso principal)
1. El caso de uso comienza cuando el cliente inserta la tarjeta bancaria
2. El sistema lee la tarjeta y solicita el número de PIN
3. El sistema presenta un menú con opciones
4. El cliente indica que desea retirar efectivo
5. El sistema solicita el monto a ser retirado y el cliente lo ingresa
6. El sistema retorna el monto deseado, imprime el recibo y expulsa la tarjeta
7. El cliente toma el efectivo, el recibo y la tarjeta.
Suficientemente simple, ¿verdad?
Sí, en realidad, demasiado…
Observe que existe un conjunto de información relevante que no se encuentra:
 ¿Qué información lee el sistema de la tarjeta bancaria?
 ¿Qué hace el sistema para verificar que el número de PIN sea correcto?
El analista que deba procesar estos casos de uso, seguramente, estará odiando al
autor de esta especificación al carecer de tanta información importante.

Agreguemos entonces esa información en la descripción:
Caso de Uso: Retirar Fondos (curso principal)
1. El caso de uso comienza cuando el cliente inserta la tarjeta bancaria
2. El sistema lee la tarjeta y solicita el número de PIN
a. El PIN es un número de 6 dígitos que no puede contener números

repetidos
3. Si el número de PIN es válido, el sistema presenta un menú con opciones de

transacciones:
a. Retirar Fondos
b. Depositar Fondos
c. Transferir Fondos
d. Consultar el estado de la cuenta
4. El cliente indica que desea retirar efectivo
5. El sistema verifica que existan fondos suficientes, que el valor ingresado

sea múltiplo de 5 y que no exceda los $ 10.000.
6. El sistema se conecta al Banco del Cliente para determinar si el retiro

puede ser efectuado satisfactoriamente.
7. El sistema solicita el monto a ser retirado y el cliente lo ingresa
8. El sistema retorna el monto deseado, imprime el recibo y expulsa la tarjeta. El

recibo muestra la siguiente información:
a. Fecha y hora de la transacción
b. Ubicación del ATM (cajero)
c. Número de Banco del Cliente
d. Tipo de Transacción
e. Monto de la Transacción

f. Identificación de la Transacción
9. El cliente toma el efectivo, el recibo y la tarjeta.
10. Fin del Caso de Uso
Observaciones generales
Notar que ninguno de los detalles dicta cómo el sistema será diseñado, solo documenta
lo que debería hacer (recordar que siempre describe "qué" sin decir "cómo")
Nota: Aquí es importante ver el detalle que tiene una descripción de un caso de
uso, ya que es muy común que suceda que alguien que haga el rol de "analista" (por
falta de experiencia, conocimientos, tiempo, etc.) solo se apoye en los diagramas
(gráficos), y como requieren detallar toda esta información, los casos de uso se
terminan distorsionando y creciendo exponencialmente. Por esa razón un caso de
uso es siempre un diagrama + documento especificando todos estos detalles en
una redacción (especificación), y el gráfico debe ser la base para tener una "visión
rápida de bosque", y la profundidad se encuentra en el resto del documento.

"Caso de Uso Simple" versus "Caso de Uso Complejo"

Una vez agregados todos estos detalles en el ejemplo anterior podríamos pensar "son
demasiados detalles" y eso que este es un caso de uso "simple" … ¿qué hacer cuando
el caso de uso sea "complejo"?
Estrategia 1 – Crear un Glosario

La creación de un glosario de términos es una forma de presentar información de
manera de no distraer al lector de nuestra documentación.
Notar que, además, lo más natural será que otros Casos de Uso empleen los mismos
términos ya definidos en el glosario.
Por ejemplo, el glosario podría contener todos los detalles de:
 Menú de Transacciones
 Recibo
 Monto Dispensado
y marcar en el desarrollo del caso de uso estas palabras en color "negro".
Al reescribir el caso de uso empleando dichas claves, la documentación retorna a una

claridad y precisión que permiten mejorar el entendimiento.
Ejemplo de un detalle en el glosario
Recibo
Impresión física de una (o varias) transacciones.
Un recibo presenta la siguiente información:
1. Fecha y hora de la transacción

2. Ubicación del ATM (cajero)
3. Número de Banco del Cliente
4. Tipo de Transacción
5. Monto de la Transacción
6. Identificación de la Transacción

Pregunta: ¿y si existieran múltiples referencias cruzadas en el Glosario que dificultaran
comprender la relación, por ejemplo, estructural entre los elementos?
Ejemplo
Orden
Contrato entre una compañía y un cliente para proveer un conjunto de productos para
un cliente en particular. Una orden incluye un conjunto de ítems y una lista de
información de productos.
Línea de Ítem
Un número o una combinación alfanumérica que identifica un producto en particular

(…)
Necesitaríamos pensar en una estrategia adicional…

Estrategia 2: Modelo de Dominio

Use el modelo para ayudar a definir, no para diseñar. Muestra los elementos que se
identifican del dominio que se desea modelar y como se relacionan. Se utiliza un
diagrama de clases de UML, ya que los mismos permiten comunicar estructuras. Es
importante aclarar que si bien se usa un diagrama de clases para comunicar un
modelo, el modelo que se muestra es conceptual y no un diseño de clases para la
aplicación.

Guías: nombres de los casos de uso
 Emplear un nombre simple, identificable y que represente un comportamiento

razonablemente atómico del sistema
 Cada caso de uso debe tener un nombre que indique valor (o la meta) que es
lograda por la interacción del actor hacia el sistema ("regla de oro").
 Use la forma activa para nombrar los actos de uso
 La "regla de oro" es llevada a cabo en mejor forma si se colocan nombres de

casos de uso que comiencen con un verbo, por ej: "transferir fondos".
o Mantiene la consistencia de nombres a lo largo del proyecto

(principalmente cuando los casos de uso pueden ser escritos por
diferentes personas).
o Ayuda a evitar la ambigüedad
 No emplear la jerga informática en los nombres de los casos de uso.
Si aún esto resulta complejo, entonces emplee como nombre de caso de uso las
mejores palabras que encuentre para promover la mejor comunicación con el cliente
(tal vez términos que use el propio cliente).
Una pregunta que ayuda a determinar el nombre y, por ende, cumplir con la regla, es:
"¿Por qué desearía el actor iniciar esta interacción con el sistema?"

Los casos de uso de la figura denotan lo que el sistema necesita hacer, pero, al
mismo tiempo representa lo que el usuario necesita hacer en el sistema… "agregar una
orden", pero todo lo restante son flujos alternativos de un caso de uso.
Regla: cuando exista una sola cosa útil para hacer, debe existir un solo caso de uso.

Mantenga la simpleza
No hay que perder el foco en el enfoque conceptual y simple, combinar las funciones
para representar el valor real para el actor.
En el diagrama anterior pudimos apreciar un ejemplo de "descomposición

funcional". Generalmente tenemos la tendencia "natural" a descomponer los
problemas en partes más pequeñas, pero algo que es adecuado en otras etapas (como
en el diseño o implementación) no es conveniente en el relevamiento a través de casos
de uso.
Casos de Uso – Errores Comunes
1. Fronteras del sistema mal especificadas
2. Los casos de uso son escritos desde el punto de vista del sistema y no de
los actores
3. Los nombres de los actores son inconsistentes
4. Hay demasiados casos de uso
5. Las relaciones entre los casos de uso forman una tela de araña
6. Las especificaciones de los casos de uso son demasiado largas
7. Las especificaciones de los casos de uso son confusas
8. El caso de uso no describe correctamente el requerimiento funcional
9. El cliente no entiende los casos de uso
10. Los casos de uso no son finalizados nunca

Casos de Uso & Ciclo de Vida

Temas importantes a tener en cuenta de los casos de uso y su evolución durante el
ciclo de vida.
Durante la etapa de análisis se deben identificar, priorizar y desarrollar aquellos casos

de uso que:
 Pertenecen a actores primarios.
 Representan mayor riesgo porque el usuario no los tiene claros
 Representan riesgos tecnológicos
 Tiene impacto en el diseño de la solución
 etc.
Los demás casos de uso se deberán tratar en las siguientes iteraciones del ciclo de
vida.
Si bien los casos de uso suelen identificarse durante la etapa de análisis, son una
herramienta que se utiliza durante todas las etapas del proyecto. En una primera
etapa se utilizan para capturar y especificar los requerimientos. Son un insumo
indispensable para la etapa de diseño, ya que el objetivo es diseñar una solución para
cumplir con esos requerimientos.
Los casos de uso permiten además validar una arquitectura y un diseño, respondiendo
la pregunta de cómo se solucionan los requerimientos con un diseño especifico.
Son útilesademás para organizar el trabajo, y mediante su agrupamiento, definir

iteraciones con límites claros.
Sirven además para los probadores (testing), a la hora de definir los casos de
prueba.
Su gran utilidad radica fundamentalmente en el ofrecer una herramienta o lenguaje

común para especificar los requerimientos de forma simple a lo largo de todo el
proyecto y para audiencias muy diferentes.

Resumen sobre el tema Casos de Uso
Los Casos de Uso se han convertido en una técnica popular para documentar los
requerimientos de un sistema de software dada su simple notación gráfica y sus
especificaciones en lenguaje natural, sin embargo, parece ser claro que la simplicidad
puede ser engañosa.
Los Casos de Uso describen qué hace el sistema a nivel conceptual y descomponer el
sistema en pequeños casos de uso dificulta la comprensión del propósito real del
sistema.
Los Casos de Uso nos deben focalizar en lo que realmente es importante, las cosas
que realmente tiene un valor real y nos permiten definir el sistema sobre esos
elementos.
Si podemos definir las especificaciones que muestren el valor que el usuario espera
obtener del sistema y luego, crear un caso de uso que represente ese valor, el
sistema cumplirá mejor con las expectativas de ese usuario.
Si como resultado obtenemos una documentación con un conjunto enorme de

comportamientos aislados, no podremos decir qué es lo que el sistema debe hacer.
Fin.
Envía tus consultas a los foros!

Aquí es cuando debes sacarte todas
las dudas haciendo consultas en los
foros correspondientes

Bibliografía
 Ingeniería de Software – Sommerville
 Wikipedia
 "Use and Abuse Cases", M. Fowler
 "UML Gota a Gota" – M. Fowler
 "Object-oriented Analysis and Design with Applications" - Booch
Envía tus consultas a los foros!

Aquí es cuando debes sacarte todas
las dudas haciendo consultas en los
foros correspondientes


4 EspecificacionCasosDeUso

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

4 EspecificacionCasosDeUso

Загружено:

Авторское право:

Доступные форматы

Curso: "Análisis y Diseño Orientado a Objetos" 2011

“Casos de Uso, segunda parte“

© Todos los logos y marcas utilizados

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 1

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 2

Descripción de Casos de Uso

El conjunto de casos de usos determina la completa funcionalidad del sistema.

Cada caso de uso tiene:

 Un curso básico, que es la secuencia más importante de eventos.

 Puede tener varios cursos de excepción para el manejo de errores.

Veamos algunos ejemplos de descripción de casos de uso utilizando algunos de los

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 3

1. Cuando el usuario inserta su tarjeta, el cajero lee el código y verifica con el

2. Cuando el usuario ingresa el PIN, el cajero verifica si es correcto. Si lo es, el

3. Cuando el usuario selecciona “retiro de dinero”, el cajero le pide el monto

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 4

Caso de Uso – Diagrama de Secuencia

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 5

Caso de Uso Formal

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 6

Ejemplo de "Cursos Básicos" y "Cursos Alternativos"

1. El cliente busca la primera caja libre para realizar un retiro.

2. El cajero le solicita al cliente el nro. de cuenta y verifica si existe.

3. Posteriormente, el cajero solicita el monto del retiro

4. El cajero solicita al sector de cajas de ahorros el saldo

5. El cajero entrega el saldo al cliente

6. El cliente cuenta el dinero

1. Si no existe una caja libre, espera o se retira del banco

2. Si el nro. de cuenta es incorrecto, se solicita un nuevo número

3. Si el monto del retiro supera el saldo, el cajero le comunica al cliente

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 7

Caso de Uso – "Conversacional"

1. El cajero ingresa el nro. de cuenta

2. El sistema verifica el nro. de cuenta,

3. El cajero selecciona retiro en

5. El cajero ingresa el monto

6.El sistema actual despliega el saldo

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 8

Plantillade Caso de Uso

 Nombre del Caso de Uso

 Tipo: indica si el caso de uso es:

o primario: caso de uso de un actor primario

o secundario: caso de uso de un actor secundario

 Pre y Post condición:

o Definen los valores de una serie de variables del sistema, antes y

o La definición de las pre y pos condiciones normalmente se difieren

o Los requerimientos puedes dividirse en requerimientos funcionales y

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 9

Pre-condición: el pasajero tiene una reservación en el vuelo

Post-condición: el pasajero o tiene un asiento asignado o está en espera para ser

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 10

Los casos de uso bien estructurados denotan el comportamiento esencial del

Es recomendable emplearnombrespara los casos de uso que sean simples,

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 11

Técnicas Comunes de Modelado

Supongamos un sistema de validación de tarjetas, para modelar el contexto de un

1. Identificar a los actores (alrededor del sistema)

2. Organizar a los actores (aquellos que sean similares)

3. Colocar los diagramas de Casos de Uso y proveer los caminos de comunicación

DOCENTE:nfornaro@gmail.com | enriqueplace@gmail.com WEB: http://formacion.surforce.com 12

1. Establezca el contexto del sistema identificando los actores que lo rodean

3. Nombre ese comportamiento común como mediante casos de uso

4. "Factoree" (*) los casos de uso