Tcnica de Casos de Uso

Utilizada para capturar los requerimientos funcionales de ms alto nivel de un sistema. Mediante su aplicacin se pretende especificar el comportamiento del sistema. No puede ser utilizada provechosamente para capturar los requerimientos no funcionales del sistema. Es una tcnica de modelado informal e imprecisa.
1

Tcnica 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 propsito de realizar un seguimiento del proyecto y brindarle alguna estructura a la aplicacin. No capturan CMO 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

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.

Actor
Entidad externa al sistema que se modela y que puede interactuar con l. Puede ser una persona o un grupo de personas homogneas, otro sistema, o una mquina. 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).
3 4

Diagrama de Casos de Uso

Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los usuarios y/u otros sistemas.

Usuario vs. Actor

Para pensar

Diferencia entre usuario y actor:

Un actor es el rol o papel que juega un objeto externo en su relacin 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.

cul es la diferencia entre los conceptos USUARIO y ACTOR?

5 6

Nombre de un Caso de Uso

Sistema de Ventas

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.: Disear Reportes, Recibir Pedidos. b)- Haciendo uso del verbo gerundio + el objeto principal que est siendo afectado, por ej.: Diseando Reportes, Recibiendo Pedidos.
7 8

Sistema de Produccin

Las flechas pueden usarse para indicar el flujo de informacin.

Sistema de Ventas

Caractersticas de un Caso de Uso:

Est expresado desde el punto de vista del actor. Se documenta con texto informal.

Ingresando Pedido

Recibiendo Informacin de Pedidos

Describe tanto lo que hace el actor como lo que hace el sistema cuando interacta con l. Es iniciado por un nico actor. Est acotado a una determinada funcionalidad del sistema. Es independiente del mtodo de diseo que se utilice, y por lo tanto, del lenguaje de programacin.
10

Sistema de Produccin

Los Casos de Uso se representan grficamente con valos. Su nombre siempre se expresa desde el punto de vista del actor. 9

Tipos de Casos de Uso

De Trazo Grueso o Esenciales De Trazo Fino o de Implementacin Temporales Primarios Secundarios
11

Casos de Uso de Trazo Grueso

Se realiza una descripcin gruesa de todos los Casos de Uso. Primero se identifican todos los casos de uso del sistema, slo al nivel de su nombre. No se deben contemplar los detalles de la interaccin entre el actor y el sistema. Se deben incluir las alternativas ms relevantes, ignorando la mayora 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 interacta con l. 12

Casos de Uso de Trazo Fino

Se especifican una vez que se ha tomado la decisin 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 descripcin del caso. Especificaciones con ms 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 cul es el momento del tiempo en el que se inicia el caso.
14

Casos de Uso Temporales (cont.)

Cuando hacemos los casos de trazo fino, debemos precisar en qu momento del mes eso ocurre (el primer da hbil, el primer da calendario, el ltimo da hbil, etc.). De lo contrario, estamos dejando en los diseadores la decisin sobre cundo 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 smbolo representando un reloj en el grfico de Casos de Uso, o usar una lnea punteada en el borde del valo del caso. Es comn que se indiquen cosas como una vez al mes cuando se habla de casos iniciados por el paso del tiempo.
16

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.

Desarrollo del Modelo de Casos de Uso

La primer cuestin a tener en cuenta cuando realizamos un Modelo de Casos de
Uso es determinar POR QU estamos utilizando esa tcnica. El CMO hacerlo, a ese momento, es de importancia secundaria.

La tcnica de Casos de Uso ser relevante para la

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 quedaran bien.
17

formulacin de QU es lo que tiene que hacer el sistema en interaccin con distintos tipos de actores Modelo o Diagrama de Casos de Uso

18

Pasos a Seguir
Paso 1. Identificar quines utilizarn 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 quines es este sistema? Identificar a todos los actores es crtico para un buen anlisis 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 disea el sistema? Cules 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 informacin del sistema? (actores secundarios)

20

Paso 2. Tomar uno de esos actores para comenzar a trabajar.

Preguntas de ayuda para el Paso 3

Cules son las principales tareas de un actor? Qu informacin tiene el actor que consultar, actualizar, modificar? Cmo?

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.

Qu cambios del exterior debe informar el actor al sistema? Qu informacin debe informrsele al actor con respecto a los cambios del sistema?

21

22

Paso 5. Detallar ese bloque descriptivo de la actividad Paso 4. Para cada uno de esos Casos de Uso decidir de la manera ms usual (en lenguaje natural), cundo y para qu este Actor utiliza el sistema. Detallar qu ocurre normalmente. Esta es la forma ms fcil de describir la interaccin del actor con el sistema. en la descripcin del Caso de Uso. Se debe mantener dicha descripcin a un alto nivel. Se pueden describir las cosas que hace el sistema, de las que el actor est enterado y, recprocamente, se pueden describir tambin las cosas que hace el Actor, de las cuales el sistema est enterado.

23

24

Cargando Orden de Venta

Descripcin 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 lnea de detalle. Cuando se cargaron todos los tems el sistema confirma la orden.

Paso 6. Una vez que se est conforme con la descripcin, se deben considerar extensiones, y agregarlas como extensiones de los Casos de Uso

Vendedor

(A esto se le denomina explosin de los Casos de Uso, donde se analiza el Comportamiento Condicional).

Descripcin 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 crdito del cliente

25

26

Comportamiento condicional en CUs

Puede ocurrir que la funcionalidad de un Caso de Uso incluye un conjunto de pasos que ocurren slo en algunas oportunidades. Se produce una excepcin 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 (relacin de extensin) al primero en donde se produjo la excepcin.
27

Descripcin 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 lnea de detalle. Cuando se cargaron todos los tems el sistema confirma la orden.

Cargando Orden de Venta

Vendedor

Descripcin 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 crdito del del cliente. cliente El sistema muestra el historial Descripcin de pagos para los ltimos seis En el CU Chequeando crdito del meses. Cliente si el sistema no encuentra <<extend>> ningn apellido que coincida, muestra un mensaje de error y le permite ingresar un nuevo apellido de cliente. Registrando

Cliente

28

Las extensiones tienen las siguientes caractersticas:

Errores y excepciones
Durante la ejecucin de un caso de uso, suelen aparecer errores o excepciones. Estas desviaciones del curso normal del Caso de Uso tienen las siguientes caractersticas: 1)- Representan un error o excepcin 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.
29 30

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 excepcin.

Cul es la diferencia entre una extensin y una excepcin?

CUs: Extensiones
El paso en el cual un caso de uso puede ser extendido se define como punto de extensin. Las condiciones para una Extensin pueden ser especificadas adjuntando una nota a la relacin de extensin.
Condicin: {cliente inexistente} Punto de Extensin: {mostrar detalles del cliente}

Una extensin es un Caso de Uso en s mismo, mientras que una excepcin no. Una extensin no es necesariamente un error o excepcin. Regla: Si algo opcional debe ser expresado con ms de un paso, seguramente es una extensin.
31

Chequeando crdito del cliente

Vendedor

<<extend>>

Registrando Cliente 32
Luciana C. Ballejos CIDISI, Centro de I+D en Ingeniera en Sistemas de Informacin

Paso 7. Revisar las descripciones de cada Caso de Uso contra las descripciones de los otros Casos de Uso.

Comportamiento comn en CUs

Es comn que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso. Resolucin: documentar la funcionalidad en un nuevo Caso de Uso (comn), que es usado por los casos de los cuales fue extrado. Relacin de uso: se representan por una lnea 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 ms alto de abstraccin. 34

Se observa alguna notoria similitud? Si es as, extraerlas e incluirlas en Casos de Uso comunes, para evitar as la repeticin de actividades en distintos Casos de Uso.
33

Descripcin 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 lnea de detalle. Cuando se cargaron todos los tems el sistema confirma la orden.

Cargando Orden de Venta Chequeando crdito del cliente

Descripcin El vendedor ingresa el apellido del cliente. El vendedor selecciona uno y el sistema muestra los detalles del cliente.
<<include>>

Caractersticas de las relaciones de uso

Aparecen como funcionalidad comn, 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.

<<include>>

Mostrando detalles del cliente

Descripcin 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.

Descripcin En el CU Chequeando crdito del Cliente si el sistema no encuentra ningn apellido que coincida, muestra un mensaje de error y le permite ingresar un nuevo apellido 35 de cliente.

36

Consideraciones de la Tcnica de CUs

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.

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 ms comn en la realizacin de este tipo de modelados. Se debe tener cuidado en la descomposicin del Modelo de Casos de Uso en Casos de Uso comunes y 38 extendidos.

37

Balances en el Modelado de Casos de Uso

Slo 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 propsito de abarcar el proyecto y servir como la unidad bsica de estimacin y la ms pequea divisible. Uno de los principales balances en este modelado se da entre el modelo ms grande en cuanto a completitud y el modelo ms simple, en el cual no se detallan esas alternativas.

39

40

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 atencin 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 tcnicas de modelado.
41

Modelado Grfico
Los modelos grficos son para aclarar el texto, y no para confundir. Si el grfico de Casos de Uso es una maraa indescifrable, no est cumpliendo su objetivo. Por lo tanto, podemos usar las siguientes reglas:

Si debo particionar mi grfico, puedo hacerlo por actor. La primera particin debe ser separar los casos centrales de los casos auxiliares.
42

Modelado Grfico
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 grficos 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 grfico principal. Es probable que no haga falta mostrar esta relacin de uso en un grfico.
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 debera llevar mucho tiempo. Los Casos de uso no deberan faltar en el anlisis de cualquier sistema de informacin.

44

Documentacin
Los Casos de Uso se documentan con texto informal. Si la descripcin del mismo es muy compleja, es conveniente complementarla con notaciones grficas, por ej. los diagramas de actividad. Algunas de las formas son:

A travs de una lista enumerada

Caso de Uso: Nombre del Caso de Uso Actor: Nombre del Actor

A travs de una lista enumerada. A travs de una tabla. A travs de una tabla cuando hay alternativas. A travs de un grfico.
45

1) Paso 1 2) Paso 2 .... n) Paso n

46

A travs de una tabla... Aclaraciones

Texto entre corchetes: debe ser sustituido de manera
consistente. Texto entre llaves: indica que se debe escoger una opcin entre las que se presentan. Texto entre smbolos <> indica comentario aclaratorio al apartado de la plantilla a la que pertenece.
47 48

A travs 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 ..... n) Paso n 2.1 Alternativa 1 del Paso 2 2.2 Alternativa 2 del Paso 2

A travs de un grfico
Nombre de la Asociacin Funcionalidad 1 Actor 1 Funcionalidad 2 Funcionalidad 8 Funcionalidad 3 Funcionalidad 9 Funcionalidad 4 Actor 3 Funcionalidad 7

Actor 2

Funcionalidad 5

Funcionalidad 6
49 50

Aclaraciones...
Las funcionalidades pueden ser expresadas de dos maneras: a)- Haciendo uso del verbo + el objeto que est siendo afectado, por ej.: Disear Reportes. b)- Haciendo uso del verbo gerundio + el objeto principal que est siendo afectado, por ej.: Agregando Procesos.

Aclaraciones... (cont.)
Las funcionalidades o el Caso de Uso se representan mediante valos. El hombrecito representa al actor. La interaccin entre el actor y el Caso de Uso se establece mediante una lnea continua que une a ambos. La falta de flechas indica que la direccin de la asociacin es bidireccional. Si se desea mayor claridad, se puede colocar el nombre de la asociacin sobre la lnea. Si se desea, puede especificarse en la asociacin la direccin del flujo de la informacin.
51 52

Especificacin de Requerimientos con Casos de Uso

Se sugiere el siguiente orden para una especificacin de requerimientos utilizando Casos de Uso: 1)- Propsito del sistema: un breve prrafo que responde a la pregunta: Para qu estamos haciendo este sistema? 2)- Grfico(s) de Casos de Uso. 3)- Descripcin 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)- Cmo identifico todos los Casos de Uso? 2)- Cmo divido la funcionalidad del sistema en casos distintos? 3)- Qu nivel de detalle debo adoptar en la especificacin? Es el desarrollo de los Casos de Uso una tcnica de refinamientos sucesivos? 4)- Los Casos de Uso, deben incluir aspectos relacionados con la implementacin fsica de la interaccin?

54

Diez Preguntas...
5)- Cul es la diferencia entre las extensiones y las alternativas? 6)- Cmo debo clasificar las relaciones de uso opcionales, como usos o como extensiones? 7)- Cul es la forma ms prctica de documentar Casos de Uso? 8)- Puedo usar los Casos de Uso para definir prioridades de requerimientos? 9)- Cul es la relacin entre los Casos de Uso y los Casos de Test? 10)- Cmo organizo una especificacin de requerimientos que incluye Casos de Uso?

Diez sugerencias prcticas...

Pregunta 1: Cmo identifico los Casos de Uso?
1. Identificar actores: Para qu es este sistema? Para quines es este sistema?. Se deben identificar todos los tipos de usuario diferentes que tiene el sistema, cules de las reas afectadas usarn o actualizarn su informacin.

55

56

2. Identificar los principales Casos de Uso de cada actor.

2.a- Identificar variaciones significativas de Casos de Uso existentes: variaciones en funcin 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.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 despus de este Caso de uso? 2.e- Buscar Casos de Uso temporales.

2.b- Identificar Casos de Uso opuestos.

Funcin opuesta a la descripta por el Caso. Realizar vs. Cancelar Pedido Negacin de la accin principal. Pagando vs. No Pagando Pedido
57

58

Diez sugerencias prcticas...(cont.)

Pregunta 2: Cmo divido la funcionalidad del sistema en casos distintos?
Una funcin del sistema es un Caso de Uso si se debe indicar explcitamente al sistema que uno quiere acceder a esa funcin.

Diez sugerencias prcticas...(cont.)

Para aplicar los Casos de Uso a desarrollos incrementales, se comienza por identificar todos los Casos de Uso del sistema slo por su nombre. Una vez identificados, se expresan en trazo grueso. Esto permite analizar los principales aspectos de todos los casos que afectan al diseo. Luego de tomar la decisin de implementar alguno, los Casos de Uso deben expresarse en trazo fino.
60

Pregunta 3: Qu nivel de detalle debo adoptar en la especificacin?

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 trminos generales.

10

Diez sugerencias prcticas...(cont.)

Pregunta 4:Los Casos de Uso deben incluir aspectos relacionados con la implementacin fsica de la interaccin?
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 implementacin fsica de la interaccin. (Ojo con esto).
61

Diez sugerencias prcticas...(cont.)

Pregunta 5:Cul es la diferencia entre las extensiones y las alternativas?
Como ya mencionamos: Una extensin es un caso en s mismo, mientras que una alternativa no.
Regla: Si algo opcional debe ser expresado con varios pasos -por ejemplo ms de tres- seguramente ser una extensin y no una alternativa.
62

Diez sugerencias prcticas...(cont.)

Pregunta 6:Cmo debo clasificar las relaciones de uso opcionales?
Qu pasa con la funcionalidad que es comn 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 relacin es opcional, cosa que no pasara si la especificamos como un uso.
63

Diez sugerencias prcticas...(cont.)

Pregunta 7:Cul es la forma ms prctica 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 interaccin 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 notacin para especificar este comportamiento interno, generalmente notaciones 64 grficas.

Diez sugerencias prcticas...(cont.)

Otra de las limitaciones de los Casos de Uso es que no hay una sintaxis clara para indicar, dentro de la descripcin del Caso, las decisiones e iteraciones. Es comn 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 descripcin del caso fuera muy compleja, es conveniente usar notaciones grficas.
65

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 categora, 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

11

 Los requerimientos importantes son aquellos que haran que el usuario se sienta decepcionado si no se implementan. Los requerimientos deseables son aquellos que el usuario querra tener, si hubiese tiempo disponible. La estrategia en este caso debera ser: incluir los imprescindibles, discutir los importantes, y eliminar los deseables Esta regla es relativa, ya que al evaluar un requerimiento debe analizar tambin su costo, complejidad, factibilidad tecnolgica y una cantidad de otros factores. 67

Pregunta 9:Cul es la relacin 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 Aceptacin de Usuarios. 1)- Se debe crear al menos un Caso de Test por CU. En general, se tendrn al menos 4 o 5 Casos de Test de Aceptacin por cada CU. 2)- Se debe crear al menos un Caso de Test por cada alternativa de un CU. 3)- Si hay una relacin de extensin, se debe tener un Caso de Test que la incluya y otro que no.
68

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 expresin lgica sea verdadera y uno en el que sea falsa. 5)- Por cada CU, se debe incluir al menos un Caso de Test con una accin invlida 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 documentacin de los CU, si es posible antes de que los usuarios acepten los requerimientos y se de por concluido el anlisis. De esta forma, se encontrarn 69 errores en los CU en momentos oportunos.

Diez sugerencias prcticas...(cont.)

Pregunta 10:Cmo organizo una especificacin de requerimientos que incluye Casos de Uso? Se pueden utilizar las siguientes reglas: 1)- Un grfico de Casos de Uso no debe mostrar ms de 15 casos. 2)- Si debo dividir mi grfico, 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.

4)- Si las relaciones de uso no entran en el diagrama principal, debo mostrarlas en grficos 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 grfico principal, ya que las flechas sern imposibles de organizar.

Se sugiere el siguiente orden para una especificacin de requerimientos utilizando Casos de Uso:
1)- Propsito del sistema: un breve prrafo, de 4 o 5 lneas, 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)- Grfico(s) de Casos de Uso. 4)- Descripcin 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 especificacin de requerimientos. 72

71

12

Apuntes Unidad III

Apunte 3.1 Resumen Metodologa IDEF0 Rumbaugh, J., Jacobson, I. and Booch, G. UML Reference Manual. Addison-Wesley Eds. 1999. Apunte 3.2: Captulo 7 Activity View Kaplan, Hadad, Doorn y Ridao. Ingeniera de Requisitos Apuntes Ctedra Ingeniera de Requisitos UTN FRBA. 2003 Apunte 3.3: Mdulo II: Lxico Extendido del Lenguaje Pgs. 7-15. Apunte 3.4: Mdulo III: Escenarios Pgs. 16-46. Rumbaugh, J., Jacobson, I. and Booch, G. UML Reference Manual. Addison-Wesley Eds. 1999. Apunte 3.5 - Captulo 5 Use Case View
73

13