IIE ­ Instituto de Ingeniería Eléctrica.DesaSoft ­ Desarrollo de Software para Ingeniería Eléctrica.Guías de clase.   Parte II: Ingeniería de Software.

Casos de Uso

Índice de contenido

Casos de Uso.....................................................................................................................................1Casos de Uso...........................................................................................................................1Actores....................................................................................................................................1Formatos.................................................................................................................................2Secciones de la descripción completa......................................................................................4Objetivos y alcance de los casos de uso...................................................................................5Descubrimiento de los Casos de Uso........................................................................................5Escritura de los casos de uso....................................................................................................5Diagrama de Caso de Uso........................................................................................................5Casos de uso en el UP..............................................................................................................6Categorización de Casos de Uso..............................................................................................7Separación de Casos de Uso, inclusión y extensión..................................................................8Referencias y lecturas recomendadas.......................................................................................9

Lecturas recomendadas..................................................................................................9Referencias.....................................................................................................................9

Un Caso de Uso describe una interacción típica entre un Actor y el sistema. Un Actor es una persona cumpliendo un cierto rol o un sistema externo u otra organización capaz de interactuar con el sistema.

Un escenario es una secuencia específica de acciones e interacciones entre los actores y el sistema, de entre todas las posibles para un caso de uso. Un caso de uso suele tener un escenario de ejecución normal ("escenario de éxito") y varios escenarios alternativos (variantes o condiciones de error). Un escenario puede considerarse una instancia de caso de uso.

Un Caso de Uso es una descripción de un proceso relativamente largo, de inicio a fin, incluyendo varios pasos o transacciones. No es un paso individual o una actividad de un proceso.

Los casos de uso no son orientados a objetos. Pueden ser usados para capturar requerimientos cualquiera sea el paradigma de desarrollo elegido.

Casos de Uso.

Los casos de uso no describen el funcionamiento del sistema; enfatizan las responsabilidades del sistema,  las cosas que debe hacer. Por esta razón se llama, a los casos de uso descritos de este modo, casos de uso “de caja negra”. Los objetos tienen responsabilidades, y colaboran con otros objetos que también tienen responsabilidades.

Actores.

Un Actor es una entidad externa al sistema que participa en el relato del Caso de Uso. Un Actor estimula al sistema produciendo eventos de entrada, o recibe algo del sistema (una salida). Los actores representan roles cumplidos por personas, sistemas informáticos, dispositivos electromecánicos u organizaciones. Una misma persona física puede desempeñar varios roles (Cajero, Administrador, Vendedor); un actor representa un único rol. En cada Caso de Uso existe un Actor iniciador que produce el estímulo que arranca los eventos del caso, y posiblemente otros 

1 de 9

actores participantes. El propio sistema en desarrollo puede se un actor cuando solicita información a otros sistemas.

• Actor principal: tiene objetivos en su rol como usuario del sistema, propios de ese rol, denominados objetivos de usuario; es lo que el usuario quiere que el sistema haga (e.g. el cajero de un supermercado quiere usar el sistema para realizar la venta de mercancías). 

• Actores de apoyo: proporcionan un servicio al sistema (e.g. en una compra con tarjeta de crédito el sistema de consulta de saldo disponible interacciona con el sistema principal como un actor de apoyo). 

• Actores pasivos: no participan en el caso de uso, pero están interesados en él (e.g. en una venta al público, la Dirección Impositiva está interesada recibir la liquidación correcta del impuesto al valor agregado). 

Formatos.

Los Casos de Uso pueden describirse con diferentes grados de detalle y formalidad: • Breve: resumen conciso en un párrafo del escenario principal. • Informal: varios párrafos en lenguaje corriente, describiendo el escenario principal y los 

escenarios alternativos. • Completo: describe en detalle todos los pasos del escenario principal y los escenarios 

alternativos, con secciones de apoyo tales como precondiciones y postcondiciones. 

Ejemplo en formato breve:RegistrarVenta: un Cliente llega a la caja con mercancías extraídas de las góndolas. El Cajero ingresa cada artículo mediante el lector de código de barras. El Sistema muestra datos de cada ítem y el costo acumulado, y actualiza el stock. Al finalizar el ingreso de artículos el Cajero indica fin de la compra, el Sistema muestra el total y emite una boleta. El cliente paga y se retira con las mercancías y la boleta.

Ejemplo en formato informal:RegistrarVenta.Escenario principal: un Cliente llega a la caja con mercancías......Escenarios alternativos:El código de barras es ilegible: el Cajero digita el identificador de artículo en el teclado.El código de barras es ilegible y el identificador número de producto también, o no están disponibles: el Cajero consulta un listado ordenado por descripción del producto para obtener el identificador de producto y lo digita en el teclado....

Ejemplo en formato completo:Caso de Uso: RegistrarVenta.Actor principal: Cajero.Personal involucrado e intereses:Cajero: lecturas de códigos rápidas y sin errores, listado de productos actualizado y fácil de consultar.Cliente: ver líneas de items y subtotales, ver costo total y monto del cambio.Supermercado: actualización del stock, concreción de la venta aunque no se lea el código de barras, atención rápida del cliente.Precondiciones: los servicios del sistema están activos, el terminal de caja tiene conexión establecida con el sistema principal, el Cajero ingresó al sistema y fue autenticado.Postcondiciones: la venta fue registrada en todos sus items, el inventario fue actualizado, se calcularon los impuestos, se emitió la boleta, se recibió el pago.

2 de 9

Flujo básico:

Acción del actor Responsabilidad del Sistema

1. El Cliente llega a la Caja con mercancías extraídas de las góndolas. El Cajero inicia una nueva venta.

2. El Cajero ingresa el identificador de cada mercancía mediante el lector de código de barras.Si hay varios ejemplares de la misma mercancía el Cajero puede ingresar la cantidad por teclado.

3. Determina precio de la mercancía y lo suma a la transacción en curso.Presenta la cantidad, descripción y  precio de la mercancía en proceso.Consulta el stock.

Se repiten los pasos 2 y 3 para todas las mercancías

4. Al completar el ingreso de todas las mercancías el Cajero indica al Sistema el fin del ingreso.

5. Calcula y presenta el total de la venta incluido impuestos.

6. El Cajero informa al Cliente el total.

7. El Cliente entrega dinero al Cajero, posiblemente más que el total de la compra.

8. El Cajero registra el dinero efectivo recibido.

9. Muestra el monto a devolver al Cliente.Genera un recibo impreso.Actualiza el stock.

10. El Cajero guarda el efectivo recibido y extrae el monto a devolver. El Cajero entrega al Cliente el recibo impreso y el vuelto.

11. Registra el fin de esta venta.

12. El Cliente se retira con las mercancías adquiridas, el vuelto y el recibo.

Flujos Alternativos:

Acción del actor Responsabilidad del Sistema

2a: Lector no lee código de barras.2a1: Ingresar por teclado el identificador de artículo.

­

2b: Lector no lee código de barras, identificador numérico de producto ilegible o desaparecido.

2b1: Consultar listado, ubicar mercancía, determinar identificador.2b2: Ingresar por teclado el identificador de artículo. 

­

7a: el Cliente no tiene suficiente efectivo.7a1: el Cajero pide cancelación de toda la transacción,

7a2: cancela toda la transacción.7a3: finaliza esta venta.

Requerimientos especiales:Texto en el monitor visible a 1 m de distancia.No usar más de 3 teclas de función.Disponer de listado actualizado de mercancías con sus identificadores de producto, ordenada por descripción de producto, fácil de consultar.Tecnología y variantes de datos:Identificador de artículo leído por código de barras o introducido por teclado.Monitores disponibles sólo de 15".

La descripción del flujo puede hacerse en una sola columna, en tanto se identifique siempre el actor o sistema que realiza la acción. La notación en columna única puede parecer menos clara al 

3 de 9

principio, pero es más concisa y facilita la renumeración automática:Flujo básico:

1. El Cliente llega a la Caja con mercancías extraídas de las góndolas. El Cajero inicia una nueva venta.

2. El Cajero ingresa el identificador de cada mercancía mediante el lector de código de barras. Si hay varios ejemplares de la misma mercancía el Cajero puede ingresar la cantidad.

3. El Sistema determina el precio de la mercancía y lo suma a la transacción en curso. Presenta la descripción y el precio de la mercancía en proceso.Consulta el stock. 

4. ... Extensiones:

2a: Lector no lee código de barras. 1. Ingresar código a mano.

2b: Lector no lee código de barras, identificador numérico de producto ilegible. 1. Consultar listado, ubicar mercancía, determinar identificador de producto.2. Ingresar identificador de producto por teclado.

Secciones de la descripción completa.

Caso de Uso: nombre del Caso de Uso.Actor principal: el actor que recurre al sistema para realizar una tarea. Es usual nombrar los 

actores con mayúscula para facilitar la identificación.Personal involucrado y lista de intereses: las personas, sistemas externos, organizaciones o 

entidades involucradas en el caso de uso, cada una con sus intereses u objetivos particulares, que deberán ser satisfechos por este caso de uso. Debe incluirse todo y sólo el comportamiento relacionado con la satisfacción de los intereses del personal involucrado.

Precondiciones: lo que siempre debe cumplirse antes de comenzar el escenario descrito en el caso de uso.

Postcondiciones (o "garantías de éxito"): lo que debe haberse cumplido al finalizar el caso de uso en su flujo básico (curso típico de eventos o escenario de éxito), o bien algún camino alternativo. Las postcondiciones deben satisfacer los intereses de todo el personal involucrado.

Flujo básico (o "escenario principal de éxito"): describe el curso típico de eventos que culmina en el cumplimiento de los objetivos del personal involucrado; posponer para el final, como Extensión, todo posible comportamiento diferente de este curso. Los eventos se numeran secuencialmente y se ordenan en una columna (indicando el actor o sistema en cada línea), o en dos columnas (acción del actor, responsabilidad del sistema).

Extensiones (o flujos alternativos): son escenarios de alternativas o excepciones respecto al flujo básico. Si son complejas se describen como casos de uso aparte. Debe indicarse la línea del flujo básico donde puede aparecer cada alternativa. Una extensión consta de una condición y un manejo; la condición debe expresarse como algo detectable por el sistema o un actor, el manejo puede ser un paso o una secuencia de pasos. Si la extensión no indica otra cosa, se retoma el flujo básico en el punto siguiente a donde se produjo la extensión, o donde se indique. Si las acciones no pueden continuar la extensión indicará la acción a tomar (finalizar el caso de uso, terminar la aplicación, cerrar sesión, bloquear el terminal). Las extensiones que pueden ocurrir en cualquier momento (e.g. corte de energía) pueden indicarse con un asterisco (*a. Desconexión del terminal) seguida de las acciones a tomar (*a1. El sistema anula toda la transacción; *a2. El Cajero deriva al Cliente y sus mercancías hacia otra caja).

Requerimientos especiales: requisitos no funcionales (restricciones), tales como atributos de calidad, rendimiento, fiabilidad, particularidades uso o ejecución, dispositivos de entrada / salida obligatorios, otros.

Tecnología y variantes de datos: características de medios tecnológicos impuestas, variantes en las entradas o salidas de datos. Idealmente, todo lo relativo a medios tecnológicos debería decidirse en el diseño, pero a veces las condiciones están impuestas desde el inicio (restricciones).

4 de 9

Objetivos y alcance de los casos de uso.

Un caso de uso debe representar un proceso elemental de negocio (EBP, “Elementary Business Process”): una tarea realizada por una persona en un lugar, en un instante, como respuesta a un evento del negocio, que añade un valor cuantificable a ese negocio y finaliza dejando los datos en un estado consistente. Ejemplos: Autorizar Crédito, Solicitar Precio.

• Un caso de uso no debe ser muy elemental, no debe ser un simple paso o algo concebible como una subtarea de una tarea significativa en el ámbito de la empresa. 

• Un caso de uso existe siempre para satisfacer un objetivo de un actor, no como subobjetivo o subtarea de un objetivo de un actor. 

• Un objetivo de subtarea o subfunción puede lícitamente expresarse como un caso de uso aparte cuando esa subfunción es reutilizada por varios casos de uso, o es precondición de varios casos de uso.

• Un caso de uso puede ser compuesto, cuando incluye objetivos intermedios cada uno de los cuales puede lícitamente constituir un caso de uso. En estas situaciones los casos de uso pueden escribirse a diferentes niveles, quedando un caso de uso compuesto por varios casos de uso más específicos.

Descubrimiento de los Casos de Uso.

1. Identificar los límites del sistema: qué entra, qué sale, quiénes lo utilizan. 2. Identificar los actores principales, aquellos con objetivos de usuario a satisfacer por el 

sistema. 3. Para cada actor, identificar sus objetivos de usuario, concebidos como un proceso elemental 

del negocio. 4. Definir los casos de uso de acuerdo a los objetivos de usuario: darles nombre según su 

objetivo, comenzando con un verbo en infinitivo. 

Escritura de los casos de uso.

Se denomina estilo de escritura esencial al que evita los detalles de interfaz de usuario, centrándose en la intención del actor. El estilo de escritura para caso de uso concreto incluye decisiones relativas a la interfaz de usuario; puede incluir modelos de ventanas, acción de los botones y otros similares.

Los casos de uso deben escribirse en estilo esencial. El estilo concreto puede usarse en etapas posteriores para el diseño de la interfaz de usuario.

Diagrama de Casos de Uso.

Un Diagrama de Caso de Uso ilustra un conjunto de casos de uso de un sistema, sus actores y la relación entre los Actores y Casos de Uso. Los Casos de Uso se ilustran como óvalos, los actores como figuras humanas de trazos. Las líneas de comunicación entre actores y casos de uso indican flujo de información o estímulo.

5 de 9

 

Diagrama de Casos de Uso para el sistema CajaSupermercado.

Los diagramas de casos de uso y las relaciones entre casos de uso son complementarias a la descripción textual de los casos de uso; no la sustituyen.

Los diagramas de casos de uso son buenos como diagrama de contexto, una muestra de las fronteras del sistema. La frontera del sistema permite identificar las responsabilidades propias del sistema. Los actores se encuentran en el exterior, los casos de uso en el interior del sistema. La frontera puede ser distinta según la perspectiva y objetivos del sistema. La frontera del sistema permite identificar las responsabilidades propias del sistema. Los actores se encuentran en el exterior, los casos de uso en el interior del sistema. La frontera puede ser distinta según la perspectiva y objetivos del sistema. Algunas fronteras típicas son: división hardware/software, un departamento u organización, la organización entera.

Casos de uso en el UP.

El Proceso Unificado (UP) es dirigido por los casos de uso:• los requerimientos se recogen esencialmente en casos de uso. Otras técnicas, como las listas 

de funciones de alto nivel (poco detalladas) son secundarias. • los casos de uso son esenciales para definir el trabajo de cada iteración: en una iteración se 

tratan algunos escenarios escogidos de un caso de uso, o un caso de uso completo. • los casos de uso determinan el diseño: en él se definen y caracterizan los objetos y 

subsistemas que realizan o colaboran en la realización de un caso de uso. 

6 de 9

• los casos de uso influyen en la organización de la documentación final del sistema, en particular los manuales de usuario. 

En la fase de Inicio:• de todos los casos de uso identificados, se escriben en formato breve todos los casos críticos 

y la mayoría de los más interesantes, con una media de 2 minutos de dedicación a cada uno. Las descripciones resultantes son superficiales, y posiblemente, imprecisas.

• de entre los casos descritos, se eligen los más complejos o arriesgados y se los describe en formato completo (entre un 10 y un 20% de los casos descritos). Las descripciones obtenidas son ya más confiables, atacan los puntos de mayor riesgo o complicación.

• analizar las descripciones obtenidas evaluando su viabilidad técnica, alcance, esfuerzo, relevancia para la empresa, u otros criterios pertinentes. 

• decisión: continuar hacia la fase de elaboración, descartar el proyecto, modificar el alcance y reconsiderar.

En la fase de Elaboración:• incluye varias iteraciones de duración fija. • en cada iteración se construyen en forma incremental partes del sistema caracterizadas por 

su alto riesgo, alta complejidad técnica, alto valor o alta significación en la arquitectura (organización estructural) del sistema. 

• la realimentación de los pasos concretos de programación influye en el refinamiento o revisión de los requerimientos. 

• una iteración puede incluir sesiones de estudio de requerimientos. • al final de la elaboración se han escrito en detalle del 80 al 90 % de los casos de uso. 

En la fase de construcción:• incluye varias iteraciones de duración fija. • se centra en completar el desarrollo del sistema. • los requerimientos se han estabilizado; pueden variar, pero en grado mucho menor.

Categorización de Casos de Uso.

Los Casos de Uso deben categorizarse para atacar primero los de mayor categoría. Se eligen para la primera categoría los Casos de Uso con mayor influencia en la arquitectura central del sistema.

Factores que aumentan la categoría de un Caso de Uso:• impacto en el diseño arquitectónico: agregan muchas clases, requieren persistencia, etc. • permiten obtener información y comprensión del diseño con poco esfuerzo. • involucran funciones de riesgo, críticas en tiempo o muy complejas. • implican investigación, o una tecnología nueva o desconocida. • representan procesos de primera línea en la empresa. • soportan directamente mayores beneficios o menores costos. 

Puede usarse una clasificación simple {alto, medio, bajo} o una escala ponderada basada en los factores determinantes anteriores. Ejemplo:

Categoría Caso de Uso Justificación

Alto RegistrarVenta Califica en varios factores que aumentan categoría

MedioAgregar nuevos usuariosIngresar al sistemaDevolver mercancías

Afecta subdominio de seguridadAfecta subdominio de seguridadProceso importante, afecta contabilidad

BajoRetirar el dinero de la cajaArranqueParada

Mínimo impacto en arquitecturaDefinición dependiente de otros Casos de UsoMínimo efecto en arquitectura

El caso de "arranque", presente en la mayoría de los sistemas, debe ser considerado al principio, aunque sea en versión simplificada, para proveer la inicialización asumida por los casos restantes.

7 de 9

Separación de Casos de Uso, inclusión y extensión.

Varios casos de uso pueden estar relacionados entre sí. Las relaciones más comunes son las de inclusión y extensión.

En la relación de inclusión un caso de uso es parte de otro (ej. ValidarUsuario). Se usa cuando un mismo conjunto de tareas se realiza reiteradamente en distintos casos de uso; separar estas tareas en un caso de uso propio evita duplicaciones. La inclusión se indica en los diagramas UML con una flecha caracterizada con el estereotipo <<include>> o <<uses>>; la punta de la flecha apunta desde el caso que usa hacia el caso usado (incluido).

En la relación de extensión un caso de uso representa una alternativa, condición de error o comportamiento diferenciado (Ej. Pago con Tarjeta, Pago contado, Pago con cheque). La extensión puede usarse también cuando se quiere agregar un comportamiento sin modificar el caso de uso existente, donde realmente debiera estar. La extensión se indica en los diagramas UML con una flecha con el estereotipo <<extends>>; la flecha apunta desde el caso alternativo (extensión) hacia el caso general. La extensión es como un caso particular, se "generaliza" en el caso hacia el que apunta.

El proceso de extraer de un conjunto de tareas un subconjunto de esas tareas para tratarlo como conjunto aparte se denomina  factorizar o refactorizar las tareas. Se aplica tanto a modelos como a código.

Se debe separar un conjunto de tareas en un Caso de Uso nuevo cuando: • esas tareas aparecen duplicadas en otros Casos de Uso (relación de inclusión). • esas tareas representan la respuesta a un evento asíncrono, algo que puede ocurrir en 

cualquier momento (relación de inclusión).• esas tareas son largas o complejas, y separarlas ayuda a factorizar los casos de uso en 

unidades manejables y comprensibles (relación de inclusión). • esas actividades representan situaciones anómalas o cursos de acción diferentes (relación de 

extensión). • se desea agregar comportamiento a un caso de uso ya definido pero no se lo quiere 

modificar (relación de extensión). Ejemplo de caso compuesto y refactorización:

Caso de Uso: RegistrarVenta....El Cliente elige el modo de pago:1. Si paga contado: Pago Contado2. Si paga a crédito: Pago con Tarjeta3. Si paga con cheque: Pago con Cheque...Caso de Uso: Pago contado....Caso de Uso: Pago con tarjeta....Caso de Uso: Pago con cheque....

Las figuras siguientes muestran los diagramas UML correspondientes a relaciones de inclusión y extensión. Los diagramas mostrados pueden ser descomposiciones más detalladas de partes del diagrama de casos de uso principal.

8 de 9

   

Relación <<uses>> Relación <<extends>>

Referencias y lecturas recomendadas.

El contenido de este documento está basado en las fuentes citadas a continuación, cuya lectura o consulta no pretenden sustituir.

Lecturas recomendadas.

• [Larman2003] Larman, Craig. UML y patrones. Una introducción al análisis y diseño orientado a objetos y al Proceso Unificado, 2a. edición. Madrid, 2003.ISBN 84­205­3438­2.

• [Fowler1997] Fowler, Martin y Scott, Kendall. UML distilled. Applying the Standard Object Modelling Language. Addison Wesley Longman, Inc., 1997. ISBN 0­201­32563­2.

• [Pfleeger2002] PFLEEGER, SHARI LAWRENCE. Ingeniería de software, teoría y práctica, 1a. edición. Buenos Aires, Pearson educación, 2002. ISBN: 987­9460­71­5.

Referencias.

• [Jacobson2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El proceso unificado de desarrollo de software. Pearson Educación, Madrid, 2000. ISBN: 84­7829­036­2.

• [Booch1999] Booch, Grady; Jacobson, Ivar; Rumbaugh, James. El lenguaje unificado de modelado. Pearson Educación, Madrid, 2000. ISBN: 84­7829­028­1.

Errores, omisiones, comentarios: Víctor González Barbone, vagonbar en fing.edu.uy

Desarrollo de Software para Ingeniería Eléctrica ­ Rev. 2009­05­09Instituto de Ingeniería Eléctrica    ­    Facultad de Ingeniería    ­ Universidad de la República, Uruguay.   

9 de 9