Introducción

Universidad de Valparaíso
Facultad de Ciencias Económicas y Administrativas Reflexión Inicial
Escuela de Ingeniería Comercial

“La parte más difícil de construir un sistema es precisamente saber qué

construir…

Ninguna otra parte del trabajo conceptual es tan difícil como establecer los
requerimientos técnicos detallados, incluyendo todas las interfaces con gente,
“UML: Casos de Uso” máquinas, y otros sistemas…

Ninguna otra parte del trabajo afecta tanto al sistema si es hecha mal…

Ninguna es tan difícil de corregir mas adelante...

Entonces, la tarea más importante que el ingeniero de software hace para el

Asignatura cliente es la extracción iterativa y el refinamiento de los requerimientos del
Gestión Tecnológica II producto”.
Profesor
Daniel Cabrera Paniagua [Brooks87] Frederik P. Brooks. “No Silver Bullet. Essence and Accidents in
Software Engineering”. IEEE Computer. Abril 1987.

EICO 314 – Gestión Tecnológica II

Introducción
Conceptos (1)
- Ningún sistema se encuentra aislado. Cualquier sistema interactúa con actores
humanos o mecánicos que lo utilizan con algún objetivo.
- Los Casos de Uso describen bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el punto de vista del usuario.
Introducción
Conceptos (2)
- Un caso de uso es una descripción de un conjunto de secuencias de
acciones, incluyendo variantes, que ejecuta un sistema para producir un
resultado observable de valor para un actor.
- Un caso de uso involucra la interacción de actores y el sistema u otros sujetos.

- Permiten definir los límites del sistema y las relaciones entre el sistema y el
entorno.
- Los Casos de Uso particionan el conjunto de necesidades atendiendo a la
categoría de usuarios que participan en el mismo.
- Están basado en el lenguaje natural, es decir, son entendibles por los
usuarios.
- Los casos de uso son independientes del método de diseño que se utilice.
- A nivel de sistemas, un caso de uso describe un conjunto de secuencias,
donde cada secuencia representa la interacción de los elementos externos al
sistema (sus actores) con el propio sistema.
- En realidad, estos comportamientos son funciones a nivel del sistema que se
utilizan durante la captura de requisitos y el análisis, para visualizar,
especificar, construir y documentar el comportamiento esperado del sistema.
- Un caso de uso representa un requisito funcional del sistema global.

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

 Conceptos Conceptos
Actores (1) Actores (2)
- Un actor representa un conjunto coherente de roles que los usuarios de los - En un sistema en ejecución, por ejemplo, una persona puede ser tanto
casos de uso desempeñan. ResponsablePrestamos como Cliente.

- Normalmente, un actor representa un rol que es desempeñado por una - Los actores se representan como “siluetas humanas” o también llamados
persona, un dispositivo hardware, o incluso, otro sistema al interactuar con el “monigotes”.
nuestro.

- Por ejemplo, si una persona trabaja para un banco, un rol podría ser Actor denominado
ResponsablePrestamos. "Cliente"

- Si tiene sus cuentas personales en ese banco, está desempeñando también el

rol de Cliente.

- Una instancia de un actor, por lo tanto, representa una interacción individual Cliente
con el sistema de una forma específica.

- Aunque se utilizan actores en los modelos, éstos no forman parte del sistema
(están fuera de la aplicación, en el entorno que lo rodea).

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

Conceptos Conceptos
Actores (3) Casos de Uso (1)
- Se pueden definir categorías generales de actores (como Cliente), y - Un caso de uso describe qué hace un sistema (o un subsistema), pero no
especializarlos (como ClienteComercial), a través de relaciones de especifica el cómo lo hace.
generalización.
- Cuando se modela, es importante tener clara la separación de intereses entre
las vistas externa e interna.

- Cada caso de uso debe tener un nombre que lo distinga del resto.
Actor Actor

- Un nombre es una cadena de texto, denominado nombre simple. Un nombre

Cliente calificado consta del nombre del caso de uso, precedido del nombre del
paquete en el que se encuentra.

- Normalmente, un caso de uso se dibuja mostrando sólo su nombre.

Generalización

Cliente Comercial

Realizar venta

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

 Conceptos Conceptos
Casos de Uso (2) Actores y Casos de Uso
- El nombre de un caso de uso puede constar de texto con cualquier número de - Los actores sólo se pueden conectar a los casos de uso a través de
letras, números, y la mayoría de los signos de puntuación (exceptuando los asociaciones.
dos puntos, utilizados para separar el nombre de un caso de uso del paquete
que lo contiene). - Una asociación entre un actor y un caso de uso indica que el actor y el caso de
uso se comunican entre sí, y cada uno puede enviar y recibir mensajes.
- En la práctica, los nombres de los casos de uso son expresiones verbales que
describen algún comportamiento del vocabulario del sistema que se está
modelando.
Actor Caso de Uso

Validar usuario Hacer pedido Sensores:: Calibrar localización

Solicitar servicio
Cliente
Nombre simple Nombre calificado

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

Conceptos
Casos de Uso y Flujo de Eventos (1)
- El comportamiento de un caso de uso se puede especificar describiendo un
flujo de eventos de forma textual, lo suficientemente claro para que alguien
ajeno al sistema lo entienda fácilmente.
- Cuando se escribe este flujo de eventos, se debe incluir cómo empieza,
cuándo empieza, y en qué instante el caso de uso, cuándo interactúa con los
actores, y qué objetos (variables) se intercambian.
- Se definen dos tipos de flujos: el flujo básico, y los flujos alternativos del
comportamiento.
- Por ejemplo, en el contexto de un cajero automático, se podría describir (de
manera narrativa) el caso de uso ValidarUsuario de la siguiente forma:
Conceptos
Casos de Uso y Flujo de Eventos (2)
- Flujo de eventos principal: El caso de uso comienza cuando el sistema pide
al Cliente un número de identificación personal (PIN). El Cliente puede
introducir un PIN a través del teclado. El Cliente acepta la entrada pulsando el
botón Enter. El sistema comprueba entonces este PIN para ver si es válido. Si
el PIN es válido, el sistema acepta la entrada, y así acaba el caso de uso.
- Flujo de eventos excepcional: El Cliente puede cancelar una transacción en
cualquier momento, pulsando el botón Cancelar, y de esta forma, reinicia el
caso de uso. No se efectúa ningún cambio a la cuenta del Cliente.
- Flujo de eventos excepcional: El Cliente puede borrar un PIN en cualquier
momento antes de introducirlo, y volver a teclear un nuevo PIN.
- Flujo de eventos excepcional: Si el Cliente introduce un PIN inválido, el caso
de uso vuelve a empezar. Si esto ocurre tres veces en una sesión, el sistema
cancela la transacción completa, lo que impide que el Cliente pueda realizar
algún tipo de operación.

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

 Conceptos Conceptos
Especificación Formal de Casos de Uso (1) Especificación Formal de Casos de Uso (2)
Caso de Uso Nombre del Caso de Uso
- El flujo de eventos de un caso de uso se puede especificar de muchas formas, Objetivo Se detalla el objetivo central de la realización del caso de uso.
incluyendo: Actor Primario Actor Principal del caso de uso.
Participantes e Intereses – El sistema opera como un contrato entre los participantes, cuyo detalle se
• Texto informal (como el presentado en el ejemplo anterior). define en un caso de uso.
– El caso de uso captura únicamente los comportamientos relacionados con
• Texto estructurado formal (con pre y postcondiciones). la satisfacción de los intereses de los participantes.
Precondiciones - Condiciones o aspectos que deben ser siempre ciertos antes de empezar
con el escenario.
• Máquinas de estados. - Eventualmente puede ser la realización previa de algún caso de uso.
Poscondiciones Condiciones que deben ser ciertas después de completado el caso de uso.
• Otros (Diagramas de Actividad, pseudocódigo).
Escenario Principal (Flujo básico) Describe la secuencia típica de sucesos, sin incluir desviaciones poco
frecuentes.
- Si bien la representación gráfica de casos de uso es necesaria, una Escenario Alternativo Describe cursos de acción alternativos a los existentes en el flujo básico. Luego
descripción textual es el único camino de determinar en términos concretos de finalizar, se retorna al punto que originó un escenario alternativo.
diversos elementos involucrados en ellos (indicar detalles…). Excepciones Denota problemas o eventualidades poco frecuentes ocurridas en el flujo
básico. Al ser detectada una anomalía en el flujo básico, se ejecuta alguna
secuencia de pasos en Excepciones. Luego de finalizar esto, se retorna al flujo
- Para ello, se utiliza una Especificación Formal de Caso de Uso, la que posee básico.
un formato definido. Requerimientos Especiales Indican requerimientos no funcionales, atributos de calidad o restricciones.
Aspectos Pendientes Elementos de interés sobre el caso de uso.
Frecuencia de Ocurrencia Frecuencia del caso de uso (frecuente, poco frecuente).

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

Conceptos Conceptos
Especificación Formal de Casos de Uso (3) Especificación Formal de Casos de Uso (4)
Caso de Uso Realizar Venta Escenario 7a. Cliente paga en efectivo
Alternativo 7a1. El Cajero ingresa el monto de efectivo entregado por el cliente.
Objetivo Permitir el concretar una venta en una sala de ventas.
7a2. Sistema presenta el monto de vuelto y abre la caja de dinero.
Actor Primario Cajero 7a3. El Cajero deposita el efectivo, extrae el vuelto y lo pasa al Cliente.
7a4. Sistema almacena el pago en efectivo
Participantes e Intereses - Cajero: preciso y rápido ingreso, pago sin errores, ya que estos se deducen de su salario.
7b. Cliente paga con Tarjeta de Crédito
- Cliente: compra rápida con mínimo esfuerzo, boleta para eventuales devoluciones.
7b1. El Cajero ingresa tarjeta de crédito en el sistema.
- Compañía: almacenamiento preciso de las transacciones, satisfacción del cliente, etc.
7b2. El sistema verifica internamente su validez, y entrega los recibos de la compra.
Precondiciones El Cajero ha sido identificado y autentificado como tal. 7b3. El Cliente entrega recibo firmado por el valor total de compra.
7b4. El Cajero ingresa el recibo firmado.
Poscondiciones - La venta es registrada.
7b5. El sistema almacena el pago con tarjeta de crédito.
- El impuesto es calculado.
- El sistema contable recibe la información de la operación. Excepciones 3a. Identificador inválido
- Se actualiza el inventario. 3a1. El Sistema indica error y rechaza el ingreso.
3b. Hay varios artículos del mismo producto (no existe una identificación individual del artículo)
Escenario 1. El Cliente llega a la caja con productos o servicios que desea comprar.
3b1. El Cajero puede ingresar el identificador y la cantidad
Principal (Flujo básico) 2. El Cajero empieza una nueva venta.
6a.Cliente solicita al Cajero sacar un artículo de la compra.
3. El Cajero ingresa el identificador del artículo.
6a1. El Cajero ingresa el identificador del artículo para su eliminación.
4. El Sistema almacena la línea de venta del artículo y presenta la descripción y el precio
6a2. Sistema muestra el total actualizado.
del artículo, y el total actualizado de la compra. El precio es calculado de acuerdo a un
6b.Cliente solicita al Cajero que cancele la Venta.
conjunto de reglas de precio. El Cajero repite pasos 3,4 hasta indicar el término.
6b1. El Cajero cancela la venta en el Sistema.
5. El Sistema presenta el total.
6. El Cajero comunica al Cliente el total y solicita su pago. Requerimientos - Interfaz de usuario desplegada en pantalla grande. Texto debe ser visible a 1 mt. de distancia.
7. El Cliente paga y sistema maneja su pago. Especiales - Las autorizaciones de tarjeta de crédito deben realizarse dentro de 30 segundos, el 90%
8. El Sistema almacena la venta terminada y envía la venta y la información del pago al de las veces.
sistema externo de contabilidad y al sistema de inventario.
Aspectos - Explorar la reiteración de fallas de servicios remotos (contabilidad, inventario, autorización
9. El sistema genera recibo.
Pendientes de crédito).
10. El Cliente se va con los productos y el recibo.
11. El Caso de uso termina. Frecuencia de Frecuente
Ocurrencia

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

 Conceptos
Organización de los Casos de Uso
- Los casos de uso pueden organizarse agrupándolos en paquetes.
- Los casos de uso también pueden organizarse expresando relaciones de
inclusión y extensión entre ellos.
- Estas relaciones se utilizan para factorizar el comportamiento común
(extrayendo ese comportamiento de los casos de uso en los que se incluye)
- Y además, se utilizan para factorizar variantes (poniendo ese comportamiento
en otros casos de uso que lo extienden).
Organización de los Casos de Uso
Inclusión (1)
- Una relación de inclusión entre casos de uso significa que un caso de uso
base incorpora explícitamente el comportamiento de otro caso de uso en el
lugar especificado en el caso base.
- El caso de uso incluido nunca se encuentra aislado, sino que es instanciado
sólo como parte de algún caso de uso base más amplio que lo incluye.
- La inclusión puede verse como una situación en donde el caso de uso base
“toma el comportamiento” del caso de uso “proveedor”.
- La relación de inclusión se usa para evitar describir el mismo flujo de eventos
repetidas veces, poniendo el comportamiento común en un caso de uso aparte

- Este caso de uso será incluido por un caso de uso base.

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

Organización de los Casos de Uso Organización de los Casos de Uso

Inclusión (2)
- La relación de inclusión es básicamente un ejemplo de delegación:
• Se toma un conjunto de responsabilidades del sistema y se capturan en un sitio
(el caso de uso a incluir en otros casos de uso).
• Luego, se permite que otras partes del sistema (otros casos de uso) incluyan la
nueva agregación de responsabilidades, siempre que se necesite utilizar esa
funcionalidad.
- Una relación de inclusión se representa como una dependencia, estereotipada
con include.
<<include>>
Hacer pedido
Extensión (1)
- Una relación de extensión entre casos de uso significa que un caso de uso
base incorpora implícitamente el comportamiento de otro caso de uso.
- El caso de uso base puede estar aislado, pero en algunas condiciones, su
comportamiento puede extenderse con el comportamiento de otro caso de uso.
- Este caso de uso puede extenderse sólo en ciertos puntos, llamados puntos
de extensión.
- La extensión puede verse como una situación en donde el caso de uso que
extiende incorpora su comportamiento en el caso de uso base.
- Una relación de extensión se utiliza para modelar parte de un caso de uso que
el usuario puede ver como comportamiento opcional del sistema.

Validar usuario
<<include>>

Seguir pedido

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

 Organización de los Casos de Uso Organización de los Casos de Uso
Extensión (2) Inclusión y extensión
- También se puede utilizar una relación de extensión para modelar un subflujo
separado que se ejecuta sólo bajo ciertas condiciones.
uc Requirements Model
- Una relación de extensión se representa como una dependencia,
estereotipada como extend. Hacer Pedido
Hacer Pedido
«extend» Urgente

«include»

<<extend>>

Hacer pedido Hacer pedido urgente

Seguir Pedido Validar
«include» Usuario

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

Diagramas de Casos de Uso Diagramas de Casos de Uso

Conceptos (1) Conceptos (2)
- Los Diagramas de Casos de Uso son uno de los tipos de diagramas en UML, - Los Diagramas de Casos de Uso es un diagrama que muestra un conjunto
que se realizan para modelar aspectos dinámicos de un sistema. de casos de uso, actores, y sus relaciones.

- Los diagramas de casos de uso se emplean para modelar la vista de casos de

uso de un sistema. uc Requirements Model

- La mayoría de las veces, esto implica modelar el contexto del sistema o Hacer Pedido
Hacer Pedido
subsistema, o el modelado de los requisitos de comportamiento de ellos. «extend» Urgente
Cliente

«include»
- Son importantes para visualizar, especificar y documentar el comportamiento.

- Presentan una vista de cómo pueden utilizarse los sistemas y subsistemas en

Validar
un contexto dado. Seguir Pedido
«include» Usuario
Cliente Comercial

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

 Casos de Uso Casos de Uso
Sugerencias y Consejos (1) Sugerencias y Consejos (2)
- Cuando se modelan los casos de uso en UML, cada caso de uso debe - Cuando se dibuje un caso de uso:
representar un comportamiento distinto e identificable del sistema o de una
parte de éste. • Hay que mostrar sólo aquellos casos de uso que sean importantes para
comprender el comportamiento del sistema o parte del sistema en su
contexto.
- Un caso de uso bien estructurado:
• Hay que mostrar sólo aquellos actores relacionados con ese caso de uso.
• Asigna un nombre a un comportamiento simple, identificable y razonablemente
atómico del sistema o parte del sistema. • Número mágico: 7 +- 2 casos de uso.
• Factoriza el comportamiento común, incorporando ese comportamiento desde otros
casos de uso que incluye.

• Factoriza las variantes, colocando ese comportamiento en otros casos de uso que
lo extienden.

• Describe el flujo de eventos de forma suficientemente clara para que

alguien externo al sistema lo entienda fácilmente

• Se describe por un conjunto mínimo de escenarios que especifican la semántica

normal y las variantes del caso de uso.

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

Casos de Uso Casos de Uso

Sugerencias y Consejos (3) Sugerencias y Consejos (4)
- No sólo describir las acciones del usuario, sino que es necesario también - No omitir texto en los cursos de acción alternativos y extensiones.
considerar las respuestas del sistema.
• Hay que describir cada uno de los cursos alternos de un Caso de Uso, no
• El sistema puede originar diversos tipos de respuestas, como mensajes de error o solamente el curso de acción básico (y posiblemente el que más será observado).
mensajes de validación.
• Si se hace esto, después a la hora de codificar la persona indicada seguirá el curso
• No entrar en demasiados detalles. Los casos de uso sólo deben describir la de acción más sencillo (curso de acción básico).
relación entre el usuario y el sistema.
- Las pre y postcondiciones son importantes, pero merecen hasta cierto punto
- No separarse de la interfaz de usuario: de atención.

• Una parte importante, es nunca perder la noción de que los casos de uso deben
de ser hechos desde el punto de vista del usuario.

• No es necesario discutir con el usuario ningún tipo de detalle técnico.

EICO 314 – Gestión Tecnológica II EICO 314 – Gestión Tecnológica II

Gracias !!!

EICO 314 – Gestión Tecnológica II