casos de uso.pdf
TRANSCRIPT
1
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.
2
• 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.
Técnica y Modelo de Casos de Uso (cont.)
2
3
Caso de UsoUn 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 UsoLos 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.
4
ActorEntidad 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).
3
5
Usuario vs. Actor
…Para pensar…
¿cuál es la diferencia entre los conceptos
USUARIO y ACTOR?
6
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.
4
7
Las flechas pueden usarse para indicar el flujo de información.
Sistema de Ventas
Sistema deProducción
8
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.
5
9
Sistema de Ventas
Ingresando Pedido
Recibiendo Información de Pedidos
Los Casos de Uso se representan gráficamente con óvalos.Su nombre siempre se expresa desde el punto de vista del actor.
Sistema deProducción
10
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.
6
11
Tipos de Casos de Uso
• De Trazo Grueso o Esenciales
• De Trazo Fino o de Implementación
• Temporales
• Primarios
• Secundarios
12
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.
7
13
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.
14
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.
8
15
• 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.
Casos de Uso Temporales (cont.)
16
• 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.
Casos de Uso Temporales (cont.)
9
17
Casos de Uso PrimariosLos casos de uso primarios del sistema son aquellos
que son necesarios para el funcionamiento normal del sistema. Son los CUs esenciales.
Casos de Uso SecundariosLos casos de uso secundarios no son centrales al
sistema, no documentan las funcionalidades principales. Son los CUs útiles, deseables o que
“quedarían bien”.
18
Desarrollo del Modelo de Casos de UsoLa 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
10
19
Pasos a SeguirPaso 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.
20
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)
11
21
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.
22
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?
12
23
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.
24
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.
13
25
Cargando Orden de Venta
Vendedor
Chequeando crédito del
cliente
DescripciónEl 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.
DescripciónEl 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.
26
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).
14
27
• 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.
Comportamiento condicional en CUs
28
Cargando Orden de Venta
Vendedor
Chequeando crédito del
cliente
DescripciónEl 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.
DescripciónEl 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.
Registrando Cliente
DescripciónEn 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 de cliente.
<<extend>>
15
29
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.
30
Errores y excepcionesDurante 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.
16
31
¿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.
32Luciana C. Ballejos
CIDISI, Centro de I+D en Ingeniería en Sistemas de Información
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.
Vendedor
Chequeando crédito del
cliente
Registrando Cliente
<<extend>>
Condición: {cliente inexistente}Punto de Extensión: {mostrar detalles del cliente}
17
33
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.
34
• 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.
Comportamiento común en CUs
18
35
Cargando Orden de
Venta
Vendedor
Chequeando crédito del
clienteDescripciónEl 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.
DescripciónEl 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.
Registrando Cliente
DescripciónEn 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 de cliente.
Mostrando detalles del
cliente
<<extend>>
<<include>>
DescripciónEl vendedor ingresa el apellido del cliente. El vendedor selecciona uno y el sistema muestra los detalles del cliente.
<<include>>
36
• 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.
Características de las relaciones de uso
19
37
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.
38
• 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 “extendidos”.
Consideraciones de la Técnica de CUs
20
39
• 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.
40
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.
21
41
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.
42
Modelado GráficoLos 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.
22
43
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.
44
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.
23
45
DocumentaciónLos 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.
46
A través de una lista enumerada
Caso de Uso: Nombre del Caso de Uso
Actor: Nombre del Actor
1) Paso 12) Paso 2....n) Paso n
24
47
A través de una tabla...
48
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.
25
49
A través de una tabla (cuando hay Alternativas)
Caso de Uso: Nombre del Caso de UsoActor: Nombre del Actor
Curso Normal: Alternativas:1) Paso 1
2) Paso 2 2.1 Alternativa 1 del Paso 22.2 Alternativa 2 del Paso 2
.....
n) Paso n
50
A través de un gráfico
Funcionalidad 6
Funcionalidad 5Actor 2
Funcionalidad 1
Funcionalidad 3
Funcionalidad 2
Actor 1Funcionalidad 7
Funcionalidad 8
Funcionalidad 9
Funcionalidad 4
Actor 3
Nombre de la Asociación
26
51
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.
52
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.
27
53
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.
54
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?
28
55
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?
56
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.
29
57
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 PedidoNegación de la acción principal. Pagando vs. No Pagando
Pedido
58
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”.
30
59
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 términos generales.
60
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”.
31
61
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).
62
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.
32
63
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.
64
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
gráficas.
33
65
• 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.
66
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.
34
67
• 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.
68
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.
35
69
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 errores en los CU en momentos oportunos.
70
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 abstractos.
36
71
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.
72
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.
37
73
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 ReferenceManual”. Addison-Wesley Eds. 1999.– Apunte 3.5 - Capítulo 5 “Use Case View”