El documento describe la técnica de casos de uso para la captura de requerimientos funcionales de un sistema. Explica que los casos de uso especifican el comportamiento del sistema a través de la interacción con usuarios u otros sistemas, describiendo qué hará el sistema a un alto nivel desde la perspectiva del usuario. También describe conceptos clave como actores, casos de uso, diagramas de casos de uso, y las relaciones que pueden existir entre casos de uso.

1. Técnica de Casos de Uso
• Utilizada para capturar los requerimientos
funcionales de más alto nivel de un sistema.
• Mediante su aplicación se pretende especificar el
comportamiento del sistema.
• No puede ser utilizada provechosamente para
capturar los requerimientos no funcionales del
sistema.
• Es una técnica de modelado informal e imprecisa.
1
Técnica y Modelo de Casos de Uso (cont.)
• Trata sobre QUÉ hará nuestro sistema a un alto
nivel, y con un enfoque desde el usuario, con el
propósito de realizar un seguimiento del proyecto y
brindarle alguna estructura a la aplicación.
• No capturan CÓMO el sistema hará lo que tiene que
hacer.
• Describe al sistema desde el punto de vista de aquel
que lo va a usar, y no desde el punto de vista del que
lo va a construir.
2
1

2. Caso de Uso
Un caso de uso es una secuencia de transacciones que son
desarrolladas por un sistema en respuesta a un evento que
inicia un actor sobre el propio sistema.
Diagrama de Casos de Uso
Los diagramas de casos de uso sirven para especificar la
funcionalidad y el comportamiento de un sistema
mediante su interacción con los usuarios y/u otros
sistemas.
3
Actor
Entidad externa al sistema que se modela y que puede
interactuar con él.
•Puede ser una persona o un grupo de personas homogéneas,
otro sistema, o una máquina.
•Los actores son externos al sistema que vamos a desarrollar.
Por lo tanto, al identificarlos, estamos comenzando a
delimitar el sistema y a definir su alcance.
•Los actores se representan con dibujos llamados “stickman”
(hombres de palo).
4
2

3. Usuario vs. Actor
…Para pensar…
¿cuál es la diferencia entre los conceptos
USUARIO y ACTOR?
5
Diferencia entre usuario y actor:
• Un actor es el rol o papel que juega un objeto
externo en su relación con el sistema.
• Un usuario es una persona que, cuando usa el
sistema, asume un rol. Así, un usuario puede
acceder al sistema como distintos actores.
6
3

4. Sistema de Ventas
Sistema de
Producción
Las flechas pueden usarse para indicar el
flujo de información.
7
Nombre de un Caso de Uso
Los nombres de los Casos de Uso pueden ser expresados
de dos maneras:
a)- Haciendo uso del verbo en infinitivo + el objeto
que está siendo afectado, por ej.: Diseñar Reportes,
Recibir Pedidos.
b)- Haciendo uso del verbo gerundio + el objeto
principal que está siendo afectado, por ej.: Diseñando
Reportes, Recibiendo Pedidos.
8
4

5. Sistema de Ventas
Ingresando Pedido
Recibiendo
Información de Pedidos
Sistema de
Producción
Los Casos de Uso se representan gráficamente con óvalos.
Su nombre siempre se expresa desde el punto de vista del
actor.
9
Características de un Caso de Uso:
• Está expresado desde el punto de vista del actor.
• Se documenta con texto informal.
• Describe tanto lo que hace el actor como lo que hace el
sistema cuando interactúa con él.
• Es iniciado por un único actor.
• Está acotado a una determinada funcionalidad del
sistema.
• Es independiente del método de diseño que se utilice, y
por lo tanto, del lenguaje de programación.
10
5

6. Tipos de Casos de Uso
•
De Trazo Grueso o Esenciales
•
De Trazo Fino o de Implementación
•
Temporales
•
Primarios
•
Secundarios
11
Casos de Uso de Trazo Grueso
• Se realiza una descripción “gruesa” de todos los Casos
de Uso.
• Primero se identifican todos los casos de uso del
sistema, sólo al nivel de su nombre.
• No se deben contemplar los detalles de la interacción
entre el actor y el sistema.
• Se deben incluir las alternativas más relevantes,
ignorando la mayoría de los errores que pueden
aparecer en el uso del sistema.
• No se debe entrar en detalle sobre las acciones que
realiza el sistema internamente cuando el usuario
interactúa con él.
12
6

7. Casos de Uso de Trazo Fino
• Se especifican una vez que se ha tomado la decisión de
implementarlos.
• Se detalla todo aquello que no se detalló en los casos de
uso de trazo grueso, por lo tanto se pueden incluir:
– Datos a ser gestionados.
– Detalles sobre la forma de la interfaz en la descripción
del caso.
– Especificaciones con más detalle del comportamiento
interno del sistema.
13
Casos de Uso Temporales
• Cuando el inicio de una determinada funcionalidad
del sistema es provocado exclusivamente por el paso
del tiempo, entonces es el paso del tiempo el que
inicia el caso de uso.
• Es importante que cuando se especifican los casos de
uso de trazo fino, se exprese claramente cuál es el
momento del tiempo en el que se inicia el caso.
14
7

8. Casos de Uso Temporales (cont.)
• Cuando hacemos los casos de trazo fino, debemos
precisar en qué momento del mes eso ocurre (el primer
día hábil, el primer día calendario, el último día hábil,
etc.).
• De lo contrario, estamos dejando en los diseñadores la
decisión sobre cuándo generar esta salida, y esto no es
correcto, ya que la oportunidad de las salidas del
sistema debe ser definida por los usuarios.
15
Casos de Uso Temporales (cont.)
• Para expresar claramente que es el paso del tiempo el
que inicia el caso, podemos incluir un símbolo
representando un reloj en el gráfico de Casos de Uso, o
usar una línea punteada en el borde del óvalo del caso.
• Es común que se indiquen cosas como “una vez al
mes” cuando se habla de casos iniciados por el paso del
tiempo.
16
8

9. Casos de Uso Primarios
Los casos de uso primarios del sistema son aquellos
que son necesarios para el funcionamiento normal
del sistema. Son los CUs esenciales.
Casos de Uso Secundarios
Los casos de uso secundarios no son centrales al
sistema, no documentan las funcionalidades
principales. Son los CUs útiles, deseables o que
“quedarían bien”.
17
Desarrollo del Modelo de Casos de Uso
La primer cuestión a tener en cuenta cuando realizamos un Modelo de Casos de
Uso es determinar POR QUÉ estamos utilizando esa técnica. El CÓMO
hacerlo, a ese momento, es de importancia secundaria.
La técnica de Casos de Uso será relevante para la
formulación de QUÉ es lo que tiene que hacer el sistema
en interacción con distintos tipos de actores
Modelo o Diagrama de Casos de Uso
18
9

10. Pasos a Seguir
Paso 1. Identificar quiénes utilizarán el sistema en forma
directa. Estos son los Actores.
• La primer pregunta que el analista debe hacer a sus
usuarios es ¿Para qué es este sistema? y la segunda es
claramente: ¿Para quiénes es este sistema?
• Identificar a todos los actores es crítico para un buen
análisis de requerimientos.
• Se deben identificar todos los tipos de usuario
“diferentes” que tiene el sistema.
19
Preguntas de ayuda para el Paso 1
• ¿Por qué se diseña el sistema?
• ¿Cuáles son los actores a los cuales el sistema va a
beneficiar?
• ¿Qué actores van a interactuar directamente con el
sistema? (actores primarios)
• ¿Qué actores van a supervisar, mantener, recibir
información del sistema? (actores secundarios)
20
10

11. Paso 2. Tomar uno de esos actores para comenzar a
trabajar.
Paso 3. Definir qué quiere hacer ese Actor con el sistema.
Cada una de las cosas que el Actor desea realizar con el
mismo, se transforma en un Caso de Uso.
21
Preguntas de ayuda para el Paso 3
• ¿Cuáles son las principales tareas de un actor?
• ¿Qué información tiene el actor que consultar,
actualizar, modificar? ¿Cómo?
• ¿Qué cambios del exterior debe informar el actor al
sistema?
• ¿Qué información debe informársele al actor con
respecto a los cambios del sistema?
22
11

12. Paso 4. Para cada uno de esos Casos de Uso decidir
de la manera más usual (en lenguaje natural),
cuándo y para qué este Actor utiliza el sistema.
Detallar qué ocurre normalmente. Esta es la forma
más fácil de describir la interacción del actor con el
sistema.
23
Paso 5. Detallar ese bloque descriptivo de la actividad
en la descripción del Caso de Uso.
Se debe mantener dicha descripción a un alto nivel.
Se pueden describir las cosas que hace el sistema, de
las que el actor esté enterado y, recíprocamente, se
pueden describir también las cosas que hace el Actor,
de las cuales el sistema está enterado.
24
12

13. Cargando
Orden de Venta
Vendedor
Descripción
El vendedor ingresa el apellido del cliente. El
sistema muestra todos los clientes que
coinciden con el apellido. El vendedor
selecciona uno y el sistema muestra los
detalles del cliente.
Por cada ítem que el cliente desea ordenar el
vendedor carga la línea de detalle. Cuando se
cargaron todos los ítems el sistema confirma la
orden.
Descripción
El vendedor ingresa el apellido del
cliente. El sistema muestra todos los
clientes que coinciden con el apellido. El
vendedor selecciona uno y el sistema
muestra los detalles del cliente.
El sistema muestra el historial de pagos
para los últimos seis meses.
Chequeando
crédito del
cliente
25
Paso 6. Una vez que se esté conforme con la
descripción, se deben considerar extensiones, y
agregarlas como extensiones de los Casos de Uso
(A esto se le denomina “explosión” de los Casos de
Uso, donde se analiza el Comportamiento
Condicional).
26
13

14. Comportamiento condicional en CUs
• Puede ocurrir que la funcionalidad de un Caso de Uso
incluye un conjunto de pasos que ocurren sólo en
algunas oportunidades.
• Se produce una excepción dentro del Caso de Uso, que
consiste en interrumpirlo y pasar a ejecutar un nuevo
Caso de Uso.
• Se dice que el último CU “extiende” (relación de
extensión) al primero en donde se produjo la
excepción.
27
Descripción
El vendedor ingresa el apellido del
cliente. El sistema muestra todos los
clientes que coinciden con el apellido.
El vendedor selecciona uno y el sistema
muestra los detalles del cliente.
Por cada ítem que el cliente desea
ordenar el vendedor carga la línea de
detalle. Cuando se cargaron todos los
ítems el sistema confirma la orden.
Vendedor
Cargando Orden
de Venta
Descripción
El vendedor ingresa el
apellido del cliente. El sistema
muestra todos los clientes que
coinciden con el apellido. El
vendedor selecciona uno y el
Chequeando
sistema muestra los detalles
crédito del
del cliente.
cliente
El sistema muestra el historial
Descripción
de pagos para los últimos seis
En el CU Chequeando crédito del
meses.
Cliente si el sistema no encuentra
<<extend>>
ningún apellido que coincida,
muestra un mensaje de error y le
permite ingresar un nuevo apellido
de cliente.
Registrando
Cliente
28
14

15. Las extensiones tienen las siguientes características:
1) Representan una parte de la funcionalidad del
caso que no siempre ocurre.
2) Son un Caso de Uso en sí mismas.
3) No necesariamente provienen de un error o
excepción.
29
Errores y excepciones
Durante la ejecución de un caso de uso, suelen aparecer
“errores o excepciones”.
Estas desviaciones del curso normal del Caso de Uso
tienen las siguientes características:
1)- Representan un error o excepción en el curso
normal del Caso de Uso.
2)- No tienen sentido por sí mismas, fuera del
contexto del Caso de Uso en el que ocurren.
3)- No necesariamente son casos de uso en sí mismas.
30
15

16. ¿Cuál es la diferencia entre una extensión y
una excepción?
• Una extensión es un Caso de Uso en sí mismo,
mientras que una excepción no.
• Una extensión no es necesariamente un error o
excepción.
Regla: Si algo opcional debe ser expresado con más de
un paso, seguramente es una extensión.
31
CUs: Extensiones
•
El paso en el cual un caso de uso puede ser
extendido se define como punto de extensión.
•
Las condiciones para una Extensión pueden ser
especificadas adjuntando una nota a la relación de
extensión.
Condición: {cliente inexistente}
Chequeando
crédito del
cliente
Punto de Extensión: {mostrar
detalles del cliente}
<<extend>>
Vendedor
Registrando
Cliente 32
Luciana C. Ballejos
CIDISI, Centro de I+D en Ingeniería en Sistemas de Información
16

17. Paso 7. Revisar las descripciones de cada Caso de Uso
contra las descripciones de los otros Casos de Uso.
¿Se observa alguna notoria similitud? Si es así,
extraerlas e incluirlas en Casos de Uso “comunes”,
para evitar así la repetición de actividades en distintos
Casos de Uso.
33
Comportamiento común en CUs
• Es común que la misma funcionalidad del sistema
sea accedida a partir de varios casos de uso.
• Resolución: documentar la funcionalidad en un
nuevo Caso de Uso (“común”), que es usado por los
casos de los cuales fue extraído.
• Relación de uso: se representan por una línea
punteada desde el caso que “usa a” al caso que es
“usado”.
Nota: Este es el concepto de la subrutina o subprograma usado
en un nivel más alto de abstracción.
34
17

18. Descripción
El vendedor ingresa el apellido del
cliente. El sistema muestra todos
los clientes que coinciden con el
apellido. El vendedor selecciona
uno y el sistema muestra los
detalles del cliente.
Por cada ítem que el cliente
desea ordenar el vendedor carga
la línea de detalle. Cuando se
cargaron todos los ítems el
sistema confirma la orden.
Cargando
Orden de
Venta
Chequeando
crédito del
cliente
Descripción
El vendedor ingresa el
apellido del cliente. El
vendedor selecciona uno
y el sistema muestra
los detalles del cliente.
<<include>>
<<include>>
Descripción
Vendedor El vendedor ingresa el apellido del
cliente. El sistema muestra todos los
<<extend>>
clientes que coinciden con el
apellido. El vendedor selecciona
uno y el sistema muestra los
Registrando
detalles del cliente.
Cliente
El sistema muestra el historial de
pagos para los últimos seis meses.
Mostrando
detalles del
cliente
Descripción
En el CU Chequeando
crédito del Cliente si el
sistema no encuentra
ningún apellido que
coincida, muestra un
mensaje de error y le
permite ingresar un
nuevo apellido 35
de
cliente.
Características de las relaciones de uso
• Aparecen como funcionalidad común, luego de
haber especificado varios casos de uso.
• Los casos usados son casos de uso en sí mismos.
• El caso es usado siempre que el caso que lo usa es
ejecutado. Esto marca la diferencia con las
extensiones, que son opcionales.
36
18

19. Paso 8. Repetir pasos 2 al 7 para cada Actor de los
detectados en el Paso 1.
Primeramente debe realizarse con los Actores
primarios, y luego seguir con los secundarios.
37
Consideraciones de la Técnica de CUs
• Una vez que se está familiarizado con el proceso, el
paso siguiente es comenzar a entender los balances que
se pueden realizar.
• El primer tema a tratar está relacionado con qué no
poner, porque poner demasiado en el modelo y querer
abarcar mucho es el error más común en la realización de
este tipo de modelados.
• Se debe tener cuidado en la descomposición del Modelo
de Casos de Uso en Casos de Uso “comunes” y
38
“extendidos”.
19

20. • Sólo debe descomponerse tanto como sea útil para
alcanzar las metas del Modelado de Casos de Uso:
capturar los requerimientos funcionales de alto nivel
del usuario con el propósito de abarcar el proyecto y
servir como la unidad básica de estimación y la más
pequeña divisible.
39
Balances en el Modelado de Casos de Uso
Uno de los principales balances en este modelado se
da entre el modelo más grande en cuanto a
completitud y el modelo más simple, en el cual no se
detallan esas alternativas.
40
20

21. Reglas a aplicar...
• La primer regla a aplicar es: “si esto no es útil para el
modelo, entonces no modelarlo”. Esta regla sirve para
evitar prestar atención a cuestiones que no hacen al
objetivo primario de esta etapa.
• La regla asociada a la anterior es: “si es útil para el
modelo, entonces se debe modelar”.
• No se debe olvidar que no hay que incluir TODO en el
modelo. Para ello, existen otras técnicas de modelado.
41
Modelado Gráfico
Los modelos gráficos son para aclarar el texto, y no
para confundir. Si el gráfico de Casos de Uso es una
maraña indescifrable, no está cumpliendo su objetivo.
Por lo tanto, podemos usar las siguientes reglas:
• Si debo particionar mi gráfico, puedo hacerlo por
actor. La primera partición debe ser separar los casos
centrales de los casos auxiliares.
42
21

22. Modelado Gráfico
• Si las relaciones de uso y las extensiones entran en el
diagrama principal, debo dejarlas allí.
• Si las relaciones de uso no entran en el diagrama
principal, debo mostrarlas en gráficos teniendo en
cuenta que siempre debo mostrar todos los Casos de Uso
que usan a otro en un mismo diagrama.
• Si tengo un Caso de Uso que es usado por gran parte de
los otros casos, debo evitar mostrarlo en el gráfico
principal. Es probable que no haga falta mostrar esta
relación de uso en un gráfico.
43
Consideraciones
• Los Casos de Uso se utilizan siempre para capturar los
requerimientos de usuario de alto nivel.
• El modelado de Casos de Uso no debería llevar mucho
tiempo.
• Los Casos de uso no deberían faltar en el análisis de
cualquier sistema de información.
44
22

23. Documentación
Los Casos de Uso se documentan con texto informal. Si la
descripción del mismo es muy compleja, es conveniente
complementarla con notaciones gráficas, por ej. los
diagramas de actividad.
Algunas de las formas son:
A través de una lista enumerada.
A través de una tabla.
A través de una tabla cuando hay alternativas.
A través de un gráfico.
45
A través de una lista enumerada
Caso de Uso: Nombre del Caso de Uso
Actor: Nombre del Actor
1) Paso 1
2) Paso 2
....
n) Paso n
46
23

24. A través de una tabla...
47
Aclaraciones
Texto entre corchetes: debe ser sustituido de manera
consistente.
Texto entre llaves: indica que se debe escoger una
opción entre las que se presentan.
Texto entre símbolos <> indica comentario aclaratorio
al apartado de la plantilla a la que pertenece.
48
24

25. A través de una tabla
(cuando hay Alternativas)
Caso de Uso: Nombre del Caso de Uso
Actor: Nombre del Actor
Curso Normal:
Alternativas:
1) Paso 1
2) Paso 2
2.1 Alternativa 1 del Paso 2
2.2 Alternativa 2 del Paso 2
.....
n) Paso n
49
A través de un gráfico
Nombre de la Asociación
Funcionalidad 1
Actor 1
Actor 3
Funcionalidad 7
Funcionalidad 2
Funcionalidad 8
Funcionalidad 3
Funcionalidad 9
Funcionalidad 4
Actor 2
Funcionalidad 5
Funcionalidad 6
50
25

26. Aclaraciones...
• Las funcionalidades pueden ser expresadas de dos
maneras:
a)- Haciendo uso del verbo + el objeto que está
siendo afectado, por ej.: Diseñar Reportes.
b)- Haciendo uso del verbo gerundio + el objeto
principal que está siendo afectado, por ej.: Agregando
Procesos.
51
Aclaraciones... (cont.)
• Las funcionalidades o el Caso de Uso se representan
mediante óvalos.
• El “hombrecito” representa al actor.
• La interacción entre el actor y el Caso de Uso se establece
mediante una línea continua que une a ambos.
• La falta de flechas indica que la dirección de la asociación
es bidireccional. Si se desea mayor claridad, se puede
colocar el nombre de la asociación sobre la línea.
• Si se desea, puede especificarse en la asociación la dirección
del flujo de la información.
52
26

27. Especificación de Requerimientos con
Casos de Uso
Se sugiere el siguiente orden para una especificación de
requerimientos utilizando Casos de Uso:
1)- Propósito del sistema: un breve párrafo que responde a
la pregunta: ¿Para qué estamos haciendo este sistema?
2)- Gráfico(s) de Casos de Uso.
3)- Descripción de los casos con sus alternativas.
4)- Prototipos para los principales Casos de Uso.
53
Diez Preguntas...
Al intentar usar los Casos de Uso, se presentan algunas
dudas o dificultades. Estas son algunas:
1)- ¿ Cómo identifico todos los Casos de Uso?
2)- ¿ Cómo divido la funcionalidad del sistema en casos
distintos?
3)- ¿ Qué nivel de detalle debo adoptar en la
especificación? ¿Es el desarrollo de los Casos de Uso
una técnica de “refinamientos sucesivos”?
4)- ¿Los Casos de Uso, deben incluir aspectos
relacionados con la implementación física de la
interacción?
54
27

28. Diez Preguntas...
5)- ¿Cuál es la diferencia entre las extensiones y las
alternativas?
6)- ¿Cómo debo clasificar las relaciones de uso
opcionales, como usos o como extensiones?
7)- ¿Cuál es la forma más práctica de documentar
Casos de Uso?
8)- ¿Puedo usar los Casos de Uso para definir
prioridades de requerimientos?
9)- ¿Cuál es la relación entre los Casos de Uso y los
Casos de Test?
10)- ¿Cómo organizo una especificación de
requerimientos que incluye Casos de Uso?
55
Diez sugerencias prácticas...
Pregunta 1: ¿Cómo identifico los Casos de Uso?
1. Identificar actores: ¿Para qué es este sistema? ¿Para
quiénes es este sistema?. Se deben identificar todos los
tipos de usuario diferentes que tiene el sistema, cuáles de
las áreas afectadas usarán o actualizarán su información.
56
28

29. 2. Identificar los principales Casos de Uso de cada actor.
2.a- Identificar variaciones significativas de Casos de
Uso existentes: variaciones en función del actor que los
ejecuta, o del tipo de objeto sobre el que se apliquen.
Por ej.: 1. ¿Existen distintos tipos de clientes que hagan pedidos?
2. ¿Existen distintos tipos de pedidos?
2.b- Identificar Casos de Uso “opuestos”.
Función opuesta a la descripta por el Caso. Realizar vs.
Cancelar Pedido
Negación de la acción principal. Pagando vs. No Pagando
Pedido
57
2.c- Identificar Casos de Uso que preceden a casos
existentes.
¿Qué es lo que tiene que ocurrir antes de este caso de uso?
2.d- Buscar Casos de Uso que suceden a casos existentes.
¿Qué ocurre después de este Caso de uso?
2.e- Buscar Casos de Uso “temporales”.
58
29

30. Diez sugerencias prácticas...(cont.)
Pregunta 2: ¿Cómo divido la funcionalidad del
sistema en casos distintos?
Una función del sistema es un Caso de Uso si se debe
indicar explícitamente al sistema que uno quiere acceder
a esa función.
Pregunta 3: ¿Qué nivel de detalle debo adoptar en
la especificación?
No se pueden especificar en detalle TODOS los CUs:
debemos tener apenas el nivel de detalle suficiente para
poder definir sus prioridades y comprenderlos en
59
términos generales.
Diez sugerencias prácticas...(cont.)
Para aplicar los Casos de Uso a desarrollos incrementales,
se comienza por identificar todos los Casos de Uso del
sistema sólo por su nombre. Una vez identificados, se
expresan en “trazo grueso”.
Esto permite analizar los principales aspectos de todos los
casos que afectan al diseño.
Luego de tomar la decisión de implementar alguno, los
Casos de Uso deben expresarse en “trazo fino”.
60
30

31. Diez sugerencias prácticas...(cont.)
Pregunta 4:¿Los Casos de Uso deben incluir
aspectos relacionados con la implementación
física de la interacción?
Una vez seleccionados los Casos de Uso a implementar
en la primera etapa, se comienzan a profundizar sus
definiciones creando los casos de “trazo fino”.
Suele ser una buena idea crear un prototipo visual de la
interfaz de los casos, incluyendo detalles de la
implementación física de la interacción. (Ojo con esto).
61
Diez sugerencias prácticas...(cont.)
Pregunta 5:¿Cuál es la diferencia entre las
extensiones y las alternativas?
Como ya mencionamos:
Una extensión es un caso en sí mismo, mientras que
una alternativa no.
Regla: Si algo opcional debe ser expresado con varios pasos
-por ejemplo más de tres- seguramente será una extensión
y no una alternativa.
62
31

32. Diez sugerencias prácticas...(cont.)
Pregunta 6:¿Cómo debo clasificar las
relaciones de uso opcionales?
¿Qué pasa con la funcionalidad que es común a varios
casos de uso, pero al mismo tiempo es opcional?
Este tipo de situaciones deben especificarse como
extensiones, ya que de esta forma queda claro que la
relación es opcional, cosa que no pasaría si la
especificamos como un uso.
63
Diez sugerencias prácticas...(cont.)
Pregunta 7:¿Cuál es la forma más práctica de
documentar un Caso de Uso?
Los Casos de Uso se documentan con texto informal. En
general, se usa una lista enumerada de los pasos que sigue
el actor en su interacción con el sistema.
Surge un problema si queremos especificar el
comportamiento interno del sistema, y el mismo no es
trivial.
Se debe utilizar una nueva notación para especificar este
comportamiento interno, generalmente notaciones
64
gráficas.
32

33. • Otra de las limitaciones de los Casos de Uso es que no
hay una sintaxis clara para indicar, dentro de la
descripción del Caso, las decisiones e iteraciones.
• Es común que en las descripciones de los Casos se
deba recurrir a frases como “Se repite el paso X hasta
que ocurre C”, o “Si ocurre C, se va al paso X”.
• En estas situaciones lo importante no es la forma en la
que se expresan las condiciones o iteraciones, sino
hacerlo de una forma consistente. Si la descripción del
caso fuera muy compleja, es conveniente usar
notaciones gráficas.
65
Diez sugerencias prácticas...(cont.)
Pregunta 8:¿Puedo usar los Casos de Uso
para definir prioridades de requerimientos?
Una vez documentados los Casos de Uso de trazo
grueso, se deben definir las prioridades de los
distintos casos de uso. Es útil usar alguna categoría,
por ejemplo: imprescindible, importante y
deseable.
• Los casos de uso imprescindibles son aquellos que,
si no se implementan, hacen que el sistema no
tenga sentido.
66
33

34. • Los requerimientos importantes son aquellos que
harían que el usuario se sienta decepcionado si no se
implementan.
• Los requerimientos deseables son aquellos que el
usuario querría tener, si hubiese tiempo disponible.
• La estrategia en este caso debería ser: “incluir” los
imprescindibles, “discutir” los importantes, y
“eliminar” los deseables
Esta regla es relativa, ya que al evaluar un
requerimiento debe analizar también su costo,
complejidad, factibilidad tecnológica y una cantidad
de otros factores.
67
Pregunta 9:¿Cuál es la relación entre los Caso
de Uso y los Casos de Test?
Los CUs son un excelente punto de partida para definir
Casos de Test, y en particular, los Casos de Test de
Aceptación de Usuarios.
1)- Se debe crear al menos un Caso de Test por CU. En
general, se tendrán al menos 4 o 5 Casos de Test de
Aceptación por cada CU.
2)- Se debe crear al menos un Caso de Test por cada
alternativa de un CU.
3)- Si hay una relación de extensión, se debe tener un
Caso de Test que la incluya y otro que no.
68
34

35. 4)- Si hay frases del tipo “si, entonces, si no” en el curso
principal de los CU, se debe hacer al menos un Caso de
Test en que la expresión lógica sea verdadera y uno en el
que sea falsa.
5)- Por cada CU, se debe incluir al menos un Caso de Test
con una acción inválida por parte del usuario.
6)- En todos los Casos de Test se debe especificar el
comportamiento esperado del sistema.
7)- Se deben crear los Casos de Test en el momento en que
finalizó la documentación de los CU, si es posible antes
de que los usuarios acepten los requerimientos y se de
por concluido el análisis. De esta forma, se encontrarán
69
errores en los CU en momentos oportunos.
Diez sugerencias prácticas...(cont.)
Pregunta 10:¿Cómo organizo una especificación de
requerimientos que incluye Casos de Uso?
Se pueden utilizar las siguientes reglas:
1)- Un gráfico de Casos de Uso no debe mostrar más de
15 casos.
2)- Si debo dividir mi gráfico, puedo hacerlo por actor o
por grupo de actores afines.
3)- Si las relaciones de uso y las extensiones entran en
el diagrama principal, sin dejar de cumplir con la regla
1), debo dejarlas allí. Lo mismo se aplica a los actores
70
abstractos.
35

36. 4)- Si las relaciones de uso no entran en el diagrama
principal, debo mostrarlas en gráficos teniendo en
cuenta que siempre debo mostrar todos los casos de
uso que usan a otro en un mismo diagrama.
5)- Si tengo un caso de uso que es usado por gran parte
de los otros casos, debo evitar mostrarlo en el gráfico
principal, ya que las flechas serán imposibles de
organizar.
71
Se sugiere el siguiente orden para una
especificación de requerimientos utilizando
Casos de Uso:
1)- Propósito del sistema: un breve párrafo, de 4 o 5 líneas,
que responde a la pregunta ¿Para qué estamos haciendo
este sistema?
2)- Lista de actores con su objetivo principal en el uso del
sistema.
3)- Gráfico(s) de Casos de Uso.
4)- Descripción de los casos con sus alternativas.
5)- Prototipos para la interfaz de los principales CUs.
Luego, debe agregarse la parte no referida a los Casos de
Uso, para completar la especificación de requerimientos.
72
36

37. Apuntes – Unidad III
• Apunte 3.1 “Resumen Metodología IDEF0”
• Rumbaugh, J., Jacobson, I. and Booch, G. “UML Reference
Manual”. Addison-Wesley Eds. 1999.
– Apunte 3.2: Capítulo 7 “Activity View”
• Kaplan, Hadad, Doorn y Ridao. “Ingeniería de Requisitos”
Apuntes Cátedra Ingeniería de Requisitos – UTN FRBA. 2003
– Apunte 3.3: “Módulo II: Léxico Extendido del Lenguaje” Págs. 7-15.
– Apunte 3.4: “Módulo III: Escenarios” – Págs. 16-46.
• Rumbaugh, J., Jacobson, I. and Booch, G. “UML Reference
Manual”. Addison-Wesley Eds. 1999.
– Apunte 3.5 - Capítulo 5 “Use Case View”
73
37