CASOS DE USO

Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que
usa alguno de los servicios de un sistema.
Un caso de uso es una forma de expresar cmo alguien o algo lo usa (no slo personas,
pueden ser otros sistemas).
Los CU son independientes del mtodo de diseo y el modelo de programacin.
Una funcin es un caso de uso si se debe indicar al sistema explcitamente que uno quiere
acceder a esa funcin.
Requerimientos formales con contexto y estructura que definen claramente el valor
resultante.
OBJETIVO: Transformar declaraciones deber de los requerimientos funcionales, en
grupos que provean valores y contextos observables, organizados desde la perspectiva del
usuario.
Los CU describen lo que el sistema debe hacer, no cmo debe ser (rpido, confiable,
seguro, etc.).
Sirven para explicarle a clientes y desarrolladores los requerimientos funcionales con
detalle suficiente para aprobar o utilizar los CU en el diseo.

DIFERENCIAS ENTRE CU Y EVENTOS

Eventos

Casos de uso

Centrados en describir qu hace el sistema

cuando el evento ocurre.
Atmicos: 1 entrada proceso salida
Alta importancia datos E/S (esenciales)

Centrados en describir dilogo entre usuario

y sistema
Pueden agrupar varios eventos
Detalle de informacin que se intercambia es
secundaria.

CARACTERSTICAS DE CU

Expresado desde punto de vista del actor.

Documentado con texto informal.
Describen lo que hace el actor y el sistema cuando interactan.
Iniciado por un nico actor.
Lista numerada de pasos que sigue el actor en su interaccin.
Acotado al uso de una determinada funcionalidad del sistema.

ACTOR

Agrupacin de personas o sistemas que interactan con el sistema en construccin.

Externos al sistema, al identificar actores, se delimita el sistema y se define su alcance.
Identificar a los actores es el primer paso en la tcnica de CU.
El actor humano es el ms importante porque representa las interacciones ms
interesantes y difciles.
No puede ejecutar flujos alternativos, slo ejecuta escenarios.
ESCENARIO: Caminos a travs de un CU, o serie de pasos y flujos que el actor puede
tomar, para lograr un resultado.

ALTERNATIVAS

Errores o excepciones durante la ejecucin del CU. EJ: Producto discontinuado.

Sin sentido por s mismas, fuera del contexto del CU.

RELACIONES DE EXTENSIN (A VECES)

(CU opcional) < - - - - - (CU Principal)

Conjunto de pasos que slo ocurren en algunas

oportunidades.
EJ: En funcin Ingresando pedido, una opcin
que permita presentar nuevos productos
disponibles. La excepcin es cuando se
interrumpe el CU y ejecuta el CU Presentando
nuevos productos.
En el ejemplo, el CU Presentando nuevos
productos EXTIENDE al CU Ingresando pedido.
El dibujo es (CU Ingresando) < - - - - - (CU

Presentando)
Representan parte de la funcionalidad del CU que no siempre ocurre.
Son un CU en s mismas.
No necesariamente provienen de un error o excepcin.
EJ: Tomar un caf EXTIENE a Cenar.
Regla general: Si algo opcional debe ser expresado con ms de un paso, es una extensin,
no una alternativa.

RELACIONES DE USO
(SIEMPRE)
(Caso que usa) - - - - - > (Caso que es
usado)

Una funcionalidad del sistema

es accedida por varios CU.
EJ: Buscando producto puede
ser accedida desde Ingresando
pedido o desde Consultando productos.
Concepto de subrutina.
Funcionalidad comn.
Los casos usados son CU en s mismos.
El caso es usado SIEMPRE que el caso que lo usa es ejecutado. Es la diferencia con los
opcionales.

ACTORES Y CASOS DE USO ABSTRACTOS

Un CU que nunca se ejecuta fuera del contexto

de otro CU, es abstracto.
EJ: Buscando producto del caso anterior.
No implementable por s mismo, slo tiene
sentido como parte de otros casos.
Un actor que participa de este caso, que rene
caractersticas comunes a todos los actores de
los casos de uso que los usan, es un actor abstracto.
Los actores abstractos, son necesarios para no dejar sin actores a los CU abstractos.
Los actores que ejecutan el caso Buscando
Datos heredan al actor abstracto.
La relacin de herencia puede ocurrir tambin si
un actor ejecuta los mismos casos que otro
actor, y algunos ms.
EJ: Supervisor puede hacer lo mismo que el
Vendedor, ms algunas cosas ms (Supervisor
hereda Vendedor).
Usar la herencia en el anlisis permite evitar redundancia y simplificar especificacin y
grficos.

TIPOS DE CASOS DE USO

ESENCIALES O DE TRAZO GRUESO

Identificando los CU slo a nivel del nombre, ignorando detalles sobre la forma de
interaccin.
Incluyendo slo las alternativas ms relevantes, ignorando errores.
Sin entrar en detalles sobre acciones de la interaccin. EJ: Si la empresa tiene
descuentos, no especificar cmo son.

Descripcin gruesa de los CU.

Permite tomar decisiones sobre qu casos de uso implementar en cada fase, permite
analizar los principales aspectos de todos los casos que afectan al diseo.

DE IMPLEMENTACIN O DE TRAZO FINO

Completando todos los detalles que se pasaron por alto en los de trazo grueso.

CASOS DE USO TEMPORALES

Casos que se disparan con el paso del tiempo. EJ: Reporte mensual automtico.
Se grafica haciendo el valo del caso con lnea punteada.
Se debe especificar cul es el momento en el tiempo en que se inicia el caso.

CASOS PRIMARIOS/SECUNDARIOS.

Si no son centrales del sistema, sino que son necesarios para que el sistema funcione sin
problemas, son casos secundarios.
EJ: Depuracin de pedidos de hace ms de 5 aos.

PROCESO DE ANLISIS
1) Identificar los actores: Para quines es el sistema?
2) Identificar los principales CU de cada actor: enunciar los nombres de los CU.
3) Identificar nuevos casos a partir de los existentes: aplicar tcnicas de anlisis
estructurado, segn 4 situaciones posibles:
- Variaciones significativas de CU existentes
Variaciones en los casos de uso en funcin del actor o del tipo de objeto. EJ: En el caso
del sistema que procesa pedidos, hacer las preguntas:
1. Existen distintos tipos de cliente? EJ: Clientes locales y del exterior, procesamiento
diferente para c/u.
2. Existen distintos tipos de pedido, que lleven a acciones distintas? EJ: Distinto tipo de
procesamiento segn el material del producto.
- CU opuestos
Buscar la funcin opuesta a la descrita. EJ: De realizar pedido, cancelar pedido.
Pensar en la negacin de la accin principal. EJ: Pagar pedido, NO pagar pedido.
- CU que preceden a casos existentes
Preguntar qu debe ocurrir antes de cierto CU. EJ: El cliente, debe ser cliente.
- CU que suceden a casos existentes
Preguntar qu ocurre despus de cierto CU.
4) Crear descripciones de CU de trazo grueso: Documentar los pasos principales, segn
definicin de trazo grueso.
5) Definir prioridades y seleccionar casos de la primera iteracin: Definir prioridades en 3
categoras:
- Imprescindibles: Si no se implementan el sistema no sirve.
- Importantes: Si no se implementan decepcionaran al usuario.
- Deseables: Se pueden implementar si hay tiempo disponible.
6) Escribir los CU de trazo fino y crear prototipos: Profundizar definiciones, preparar prototipo
para validar el estilo de interaccin (prototipos son descartables).

ORGANIZACIN DE LA ESPECIFICACIN
GRFICOS A UTILIZAR
Un grfico de CU no debe mostrar ms de 15 casos.
Se puede particionar grficos por actor. Separar casos principales de auxiliares.
Graficar las relaciones de uso y extensiones si entran en el diagrama principal. dem para actores
abstractos.
Si no entran, mostrarlas en otros grficos con todos los CU que usan a otro en un mismo
diagrama.
Si un CU es utilizado por gran parte de otros casos, evitar mostrarlo en el grfico principal, por la
cantidad de flechas.

SECCIONES (ORDEN SUGERIDO)

1)
2)
3)
4)

Propsito del sistema: Para qu se hace el sistema?

Grficos de CU.
Descripcin de los CU con sus alternativas.
Prototipos principales.

CONSEJOS PARA LA REDACCIN DE CU

Respetar el diagrama: representacin grfica + especificaciones textuales.

Los actores humanos son los ms importantes.
Mantener una tcnica estructural comn, con un nico flujo principal y mltiples flujos
alternativos.
Colocar referencias en los flujos alternativos: Sentencias simples que indiquen dnde se
inicia, y cmo y dnde termina.
Los escenarios deben contar la historia completa.
Cuidado con sentencias IF: Romper IF en mltiples requerimientos.
Especificar las elecciones (opciones) del actor.
Alejar el CRUD: Centrarse en lo que el actor realmente quiere hacer, evitar relacionarlo
con acciones de Crear, Leer, Actualizar y Borrar (CRUD, Create Read Update Delete).
Secuencia de eventos puede ser opcional: Considerar si el orden de los pasos es
realmente un requerimiento.
Nivel correcto de detalle: No referenciar elementos de la interfaz, por ejemplo clickear en
cierto botn.
Escribir los CU de una forma que el sistema sea lo ms simple posible para el usuario.

DIAGRAMA DE ACTIVIDAD

Muestra actividades, representando la realizacin de operaciones y las transiciones son

disparadas por la finalizacin de estas operaciones.
Enfocado en los flujos manejados por el procesamiento interno.
Usar en situaciones donde la mayora de los eventos representan la finalizacin de
acciones generadas internamente.
No adecuado en situaciones de eventos asincrnicos.

Caso de uso, centrado en interaccin entre actor y sistema. Diagrama de actividad,

centrado en el procesamiento interno del sistema durante el CU.
Un CU puede estar acompaado por cero, uno, o ms diagramas de actividad.
Se puede construir diagramas de actividad jerrquicos, donde una actividad sea
descompuesta en actividades menores.

ACCIN
Representacin de un estado con una accin
interna y una o ms transiciones salientes
(eventos de finalizacin).
El uso normal de una accin es modelar un paso
o un conjunto de pasos en la ejecucin.
Puede ser escrita en lenguaje natural o
pseudocdigo.

DECISIN
Cuando una condicin es usada para indicar
diferentes transiciones posibles que depende un
valor booleano.

ANDARIVEL
Usados para organizar las responsabilidades de
las actividades.

TRANSICIN SIMPLE
Una actividad sigue a otra, se las considera de duracin 0 y no tienen efectos laterales.

TRANSICIONES CONCURRENTES (FORK Y JOIN)

Sincronizacin o bifurcacin en ejecuciones
concurrentes.
Un Join se habilita cuando todas las acciones origen han
finalizado.
Cuando un Fork se inicia todas las acciones son
disparadas en simultneo.

DIAGRAMAS DE SECUENCIA
Muestran objetos o clases y mensajes entre ellos.
Lnea de vida: representa la existencia de un objeto a lo largo de un perodo de tiempo.
Foco de control: representa el perodo de tiempo durante el cual el objeto ejecuta una
accin.
Mensajes a self: un mensaje que se enva de un objeto a l mismo se grafica mediante
una caja de activacin anidada.
Destruccin de objeto: cuando un objeto deja de existir, se marca su fin con una cruz
donde termina su foco de control.
Condicionales: se grafica con una flecha para cada opcin.

TRAZABILIDAD: MATRICES DE INCIDENCIA

REQUERIMIENTOS / CASOS DE USOS
Dado que los casos de usos fueron determinados en relacin uno a uno con los requerimientos.
Cada uno de estos ltimos queda cubierto por un caso de uso. Con esto corroboramos que todas
las funcionalidades requeridas son tenidas en cuenta.

REQUERIMIENTOS / CLASES
En este caso se determina que las clases con mayores incidencias en el sistema son Reserva,
laboratorio y aquellas que derivan de Usuario (sobre todo docente). Cualquier cambio que se
realice sobre ellas provocara un gran impacto en el proyecto, ya que adems estn en asociacin
con muchas otras clases.

CASOS DE USOS / CLASES

Por ltimo dado que como fue mencionado anteriormente, los casos de usos y los requerimientos
estn en relacin 1 a 1, entonces la matriz de incidencia entre casos de usos/clases es idntica a
la de requerimientos/clases. Por lo que en realidad no se aporta ningn dato nuevo.

HERRAMIENTAS DE GESTIN DE REQUISITOS

La gestin de requisitos es un componente vital, provee la direccin y el alcance del proyecto.
Las herramientas CASE (Computer Arded Software Engineering) facilitan el trabajo de la
especificacin, organizacin, almacenamiento y gestin de requisitos. A travs de la gestin de
trazas, estas herramientas ayudan a evaluar el posible impacto de los cambios.

REQUISITEPRO
Centrada en documentos, almacena los requisitos asocindolos a documentos.
Auxilia especialmente en el control de cambio de requisitos con trazabilidad para
especificaciones.
Partner de MS.

IRQA
Diseada para soportar el proceso completo de ingeniera de requisitos.
El ciclo de especificacin incluye captura de requisitos, anlisis, especificacin de sistema y
validacin.

CALIBERRM
Para sistemas grandes y complejos.
Proporciona DB de requisitos con trazabilidad.
Requisitos como parte del proceso de gestin de calidad.
Basado en Internet.
Maneja referencia de documentos, responsabilidad de usuario, trazabilidad, prioridad y estado
entre otras.

DOORS
Considera requisitos como objetos y documentos como mdulos.
Orientacin a objetos.
Para organizaciones grandes con complejos conjuntos de usuarios y requisitos.

UML (LENGUAJE UNIFICADO DE MODELADO)

PAQUETES

Mecanismo general para organizacin de

modelos, agrupando elementos.
Cada paquete corresponde a un subconjunto
del modelo y contiene clases, objetos,
relaciones, componentes, diagramas
asociados.
Un paquete puede contener otros paquetes.
Una clase de un paquete puede aparecer en
otro paquete por la importacin a travs de
una relacin de dependencia entre paquetes.
Un paquete encapsula a la vez que agrupa.

DIAGRAMAS DE CU

CU es una tcnica para capturar informacin de cmo

trabaja un sistema.
No pertenece estrictamente al enfoque orientado a
objetos, es una tcnica de captura de requisitos.

DIAGRAMAS DE CLASES Y OBJETOS

Diagrama principal para el anlisis y diseo, presenta las clases y objetos del sistema con
sus relaciones estructurales y de herencia.
La definicin de clase y objeto incluye definiciones para atributos y operaciones.
El modelo de CU aporta informacin para establecer las clases, objetos, atributos y
operaciones.