Anlisis y Diseo de Sistemas I

CASOS DE USO
 DEFINICIONES
Describe un conjunto de interacciones entre actores y
el sistema en consideracin orientadas a satisfacer un
objetivo de un actor .
[D. bredemeyer]

Es una coleccin de posibles Secuencias de

interacciones entre el sistema en discusin y sus actores
externos, relacionado con un objetivo particular.
[A. Cockburn]

Es una coleccin de escenarios de xito y fracaso

relacionados que describe a los actores que usan un
sistema para conseguir un objetivo.
[C. Larman]
 CARACTERISTICAS
Los Casos de Uso son un artefacto integrador de las
etapas del proceso de desarrollo
Tipos de formalismo (para el texto)
Resumido (Brief)
Casual
Formal (Fully Dressed)
Variante a 2 Columnnas

Tipo de escritura
Escencial: evita tratar la IU
Concreto: refiere Elementos de lU
PLANTILLAS PARA CU
[D. Coleman]
[A. Cockburn]
[Variante a dos columnas]
 Otros conceptos
Escenarios (scenarios): los escenarios representan
caminos de comportamientos posibles de un caso
de uso; dichos comportamientos son investigados
para elaborar requerimientos.

los escenarios pueden clasificarse en (1) escenario

normal, (2) escenarios alternativos y (3) escenarios
excepcionales
 Otros conceptos
Escenario normal: representa el comportamiento
normal y tpico del sistema.

Escenarios alternativos: representan

comportamientos normales pero atpicos del
sistema.

Escenarios excepcionales: representan

comportamientos anormales del sistema.
 Otros conceptos
Condiciones: las condiciones separan el xito de
las fallas (fracaso)Las condiciones dirigen a los
actores a un camino particular.

Meta (Goal): Objetivo o actividad de inters de un

actor.

Actor (Agente) primario: Aquel que tiene una meta

que requiere la asistencia del sistema
 Pasos a seguir
Identificar actores
Identificar Funcionalidades
Transformar funcionalidades en
caso de uso.
Asociar Actores a casos de uso
Asociar casos de uso o otros casos
de uso.
 Utilidad
Guan el desarrollo de la aplicacin
Guan el diseo de los casos de prueba del sistema
Se toman como insumo para el diagrama de
secuencias.
Guan la creacin de roles y asignacin de
permisos del sistema.
DIAGRAMAS DE CASOS
DE USO
 Actores
Los actores representan los roles que juegan los usuarios
de los casos de uso al interaccionar con el sistema.

Roles jugados por personas, dispositivos, u otros sistemas.

No forman parte del sistema sino de los procesos del

negocio.
 TIPO DE RELACIONES
Generalizacin
o Un caso de uso hereda el comportamiento y
significado de otro. Se utiliza para indicar
diferentes maneras de realizar una misma
funcin.
 TIPO DE RELACIONES
Inclusin
o Un caso de uso base incorpora explcitamente el
comportamiento de otro en algn lugar de su
secuencia. (Flujo Obligatorio).
o Permite factorizar un comportamiento en un
caso de uso aparte y evitar repetir un mismo flujo
en diferentes casos de uso.
 TIPO DE RELACIONES
Extensin
o Un caso de uso base puede incorporar el
comportamiento del caso uso del que extiende.
o Sirve para modelar la parte opcional de una funcionalidad
EJEMPLO 1
EJEMPLO 2
Ejemplo 3
 Ejemplo 4
Se requiere hacer un sistema de monitoreo de
compuertas para una represa con las siguientes
caractersticas, todos el das a las 11pm el sistema
monitorea el nivel del agua y si esta accede un
umbral determinado se genera una alerta, si por el
contrario todo est bien se genera un reporte para
el rea de gestin ambiental noticiando la hora, el
nivel del agua, la temperatura y la direccin del
viento.
PAQUETES Y CASOS DE USO
Los diagramas de paquetes no solo sirve para el
diseo, tambin para la vista lgica de la
arquitectura de un sistema.
Diagrama de paquetes de
casos de uso
 Diagramas de casos de
uso
Para abordar la complejidad, se puede construir uno
por cada paquete de la vista lgica.
 LISTA DE CHEQUEO
Los Casos de Uso
Est relacionado con, al menos, un actor u otro caso
de uso?

Est escrito en voz activa?

Describe qu ocurre y no cmo?

Resulta demasiado largo para ser legible o

demasiado corto para tener entidad propia?

Su nombre est orientado al punto de vista del actor y

no del sistema?
 LISTA DE CHEQUEO
Las Relaciones
La clasula extends se usa para describir
alternativas o extensiones opcionales del caso de
uso?

La clasula includes se usa para describir un

conjunto comn de pasos a varios casos de uso?

La excepcin se usa para expresar una situacin

excepcional o extraordinaria?
 LISTA DE CHEQUEO
Los Actores
Son entidades (humanas, organizaciones,
dispositivos o sistemas) externos al sistema?

Son abstracciones de roles, no una persona

particular?
 LISTA DE CHEQUEO
Los Diagramas
Define claramente los lmites del sistema?

Representa un conjunto cohesivo de casos de

uso?

Tienen un tamao apropiado o sera conveniente

dividirlo en paquetes?
 ANTIPATRONES EN LOS
CASOS DE USO

Tomado de
Antipatterns catalog to use when specifying functional requirements with use cases.
Juan Bernardo Quintero, Diana Mara Hernndez, Pamela Rucinque
 Categora 1: En los
conjuntos de casos de uso
Esta categora se centra en los antipatrones que se
presentan en un conjunto de casos de uso
relacionados, que se suelen diagramar en un mismo
modelo.
a) Punto de entrada
Se presenta cuando el actor principal se relaciona
con solo un caso de uso, el cual tiene relaciones de
dependencia con los dems casos de uso.
b) Modelo Desordenado
Se presenta cuando los diagramas quedan desordenados,
bien porque tienen muchos casos de uso o porque no se
pone el lmite del sistema o mdulo; esto dificulta su
comprensin, realizacin e implementacin.
 Categora 2: En los casos
de uso
Esta categora se centra en los antipatrones que se
presentan en cada caso de uso individualmente.
a) Nombre Confunso
Se presenta cuando los nombres de los casos de uso se
ponen desde la perspectiva del sistema y no del
usuario, o cuando no se utiliza voz activa para su
denominacin.

Ejemplo: Matrcula Estudiante en una institucin

educativa que permite a los estudiantes realizar la
matrcula en lnea por Internet.
- Su nombre se orienta ms al sistema que al actor.
- No est en voz activa y por ende no indica una accin
en s.
Lo correcto sera por ejemplo un caso de uso llamado
Realizar Matrcula.
b)Alcance Mezclado
Se presenta cuando los modeladores tratan de mostrar tanto
a los actores de la empresa como a los usuarios del sistema
informtico en el mismo modelo de casos de uso.
c) Granularidad Fuera de
Lugar
Se presenta cuando los casos de uso constituyen
procesos muy generales con granularidad muy
gruesa, en este caso corresponden ms a objetivos
en el modelado de negocio, que a requisitos en el
anlisis. Tambin se presenta cuando los casos de
uso constituyen operaciones muy puntuales con
granularidad muy fina, en este caso corresponden
ms a acciones incidentales en el diseo del
sistema, que a requisitos en el anlisis.
 Ejemplo de esta situacin en una institucin
educativa podra ser:
- Mejorar la Calidad de la Educacin como
objetivo de negocio.
- Seleccionar Curso como accin incidental en el
sistema.
- Matricular Estudiante como proceso elemental
de negocio, por tanto solo el ltimo caso
corresponde a un caso de uso de requisitos.
d) Caso de uso imperativo
Se presenta cuando los casos de uso se centran ms en
el Cmo que en el Qu. Los casos de uso hacen
parte fundamental del anlisis de requisitos, por tanto
son por naturaleza declarativos (se enfoca
mayoritariamente en el Qu o el espacio del
problema), mientras que el diseo es imperativo (se
enfoca mayoritariamente en el Cmo o el espacio de
la solucin), por tanto los modelos de casos de uso no
deben invadir el diseo.

Ejemplo: Incluyen los llamados casos de uso CRUD,

denominados as por representar las operaciones de
Create, Read, Update y Delete.
 Categora 3: En los
escenarios y pasos
Esta categora se centra en los antipatrones que se
presentan en la especificacin de los casos de uso,
cuando se describen sus escenarios y sus pasos.
a) Tipo de Flujo Indeterminados
Cuando se especifican los casos de uso, se hace
especial nfasis en la documentacin del flujo de
eventos principales, los cuales definen la coleccin de
escenarios que suceden regularmente (o como es
llamado en ocasiones: Happy Path); mientras que en
algunos casos los dems flujos no son trabajados con el
rigor debido. En otros casos los flujos alternativos y
excepcionales no se separan, por el desconocimiento
de la principal diferencia entre estos dos tipos de flujos:
Un flujo alternativo: Alcanza el objetivo planteado
para el caso de uso por un camino diferente al Happy
Path.
Un flujo excepcional: NO alcanzan el objetivo
planteado para el caso de uso.
b) Estilo de Escritura Indefinido
Existen varias caractersticas que pueden afectar la
redaccin de los flujos de trabajo, entre ellos se
destacan:
- Escenarios muy largos o con redaccin confusa.
- Diferencias en la granularidad de los escenarios.
- Mezcla de los estilos de escritura.
c) Desempoderamiento Funcional
Se presenta cuando un caso de uso que involucra
dos o ms actores, inicia su flujo preguntando
quien es el actor para definir que flujos o escenarios
puede utilizar. En estas situaciones ninguno de los
actores est verdaderamente empoderado del
caso de uso.
 Categoria 5: en las
relaciones
Esta categora se centra en los antipatrones que se
presentan en la especificacin de relaciones entre
los casos de uso, o entre estos y los actores.
a) Relaciones Enmaraadas
Muchos actores que se relacionan al tiempo con
muchos casos de uso en el mismo diagrama,
generan una complicada red de relaciones que
dificulta la comprensin del modelo.
b) Relaciones Redundantes
Se presenta cuando un caso de uso tiene
relaciones de dependencia con otro, y al actor
involucrado se le pone asociacin con ambos
casos de uso. En estas situaciones solo es necesario
que los actores estn relacionados con el caso de
uso base. Recordar nodos conexos
c) Relaciones Incorrectas
Se presenta cuando la direccin o la semntica de
las relaciones de inclusin o extensin son mal
utilizadas, al igual que la generalizacin entre casos
de uso.
 Ejercicio
Una fabrica recicladora requiere un sistema para gestionar su operacin diaria, la informacin que
suministra es la siguiente:
Los items que recicla la empresa son botellas y tarros.
El gestor de calidad en cualquier momento puede generar un reporte que incluya todos los
items reciclados hasta ese momento y la hora exacta en que fue reciclado.
Antes de que el operador deposite un item en la maquina recicladora se debe registrar la
informacin de este, la cual varia segn el tipo de item.
Al momento de realizar una impresin se debe generar una alarma solo si la impresora no tiene
papel.
El archivista puede imprimir documentos pero solo con menor calidad.
Al momento de registrar un deposito se debe imprimir un documento con la informacin
ingresada, agregando adems la hora de la impresin y el nombre de usuario que la genera.
Los reportes que genere el sistema deben de ser impresos.
El Gestor de calidad puede cambiar/modificar la informacin de un item registrado, pero
solo la informacin que es igual para todos los tipos de items.
Cuando se deposite un item a reciclar se debe generar una alarma si este se atora dentro de
la mquina recicladora.
Hay 2 tipos de operadores, aprendiz y avanzado, el aprendiz solo puede depositar tarros en la
mquina y el operador avanzado como es muy teso puede depositar cualquier tipo de item.
Si al momento de realizar un reporte la tinta de la impresora est por debajo del 8% se imprime
el documento con menor calidad.
 REFERENCIAS
Larman, Craig. Uml y Patrones: Introduccin al anlisis y diseo
orientado a objetos. 2 ed. s.l. : Prentice Hall, 2005.627 p.

Quintero, Juan Bernardo; Hernndez, Diana Mara; Rucinque,

Pamela. Catlogo de antipatrones al especificar requisitos
funcionales usando casos de uso. LATIN AMERICAN CONGRESS ON
REQUIREMENTS ENGINEERING & SOFTWARE TESTING LACREST
MEDELLN 2012. July 13-14, Medelln, Colombia.

Steve, A. et al. 2003. Patterns for Effective Use Cases (The Agile
Software Development Series). Addison-Wesley, Pearson Education,
Boston, MA.