Casos de Uso

CASOS DE USO
WALTER MOLINA LOPEZ

DIAGRAMA DE
CASOS DE USO
• Son una técnica para capturar la

funcionalidad del sistema desde
el punto de vista del usuario.
• “Es una secuencia interacciones
entre un sistema y alguien o
algo que usa alguno de sus
servicios”
DIAGRAMA DE CASOS DE USO
• Propósito
• Especificar el contexto de un sistema
• Capturar los requerimientos del sistema
• Validar el arquitectura del sistema
• Manejar implementación y generar pruebas
• Historia
• Introducidos por Jacobson en 1992 con OOSE
DIAGRAMA DE
CASOS DE USO
DEFINICIONES BÁSICAS
• Es una secuencia de interacciones entre un sistema y algo o alguien (actor), que usa sus servicios
• Características:
• Es iniciado por un actor
• El nombre es expresado desde el punto de vista del actor
• Se documentan con un texto informal
• Describir tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él
• Están acotados a una determinada funcionalidad del sistema
• Notación:
• Su nombre es con verbo en infinitivo, seguido por el objeto o entidad del sistema que está afectado por el caso
• Se representa con un óvalo con el nombre del caso en su interior
DEFINICIONES
BÁSICAS
Regla: 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
• Agrupación uniforme de personas, sistemas o máquinas

que interactúan con el sistema que estamos construyendo
• Características:
• Son externos al sistema desarrollar
• Un actor es una clase de rol -> Un usuario asume un
rol
• Notación:
• Se representa con dibujos simplificados de
personas. Cuando los actores son sistemas se
pueden representar con otro icono.
• Asociación: representa la
participación del actor con un caso
de uso
• Notación: una línea sólida que une
al actor con el caso de uso
• Generalización: una generalización desde

un actor A un actor B indica que una
instancia de A puede comunicarse con los
mismos casos de uso que puede
comunicarse una instancia B
• Notación: una línea delgada que une al
actor A con el actor B, la herencia va de A
a B y termina con un triangulo vacío
• Los casos de uso se documentan contexto informal

• Se usa una lista enumerada de los pasos que sigue el actor para interactuar
con el sistema
• Alternativas:
• Representan un error o excepción en el curso normal de un caso de uso
• No tienen sentido por sí mismas fuera del contexto del caso de uso en que ocurren
DEFINICIONES
BÁSICAS
Basado en el Metodo RUP
• Relación de Extensión:
• La funcionalidad de un caso de uso puede ser
aumentada por un conjunto de pasos que ocurren
solo en algunas oportunidades (depende del
cumplimiento de una condición)
• Son un caso de uso en sí mismas
• No necesariamente proviene de un error o de una
excepción
• Notación:
• Se representa por una línea de trazos que va desde
el caso que “extiende” al caso que es “extendido”
• Relación Incluye:
• Define que un caso de uso con el comportamiento
definido de otro caso uso
• Son un caso de uso en sí mismos
• El caso (Ordenar Producto), es usado siempre que
el caso que lo usa es ejecutado (Ingresar Pedido)
• Notación:
• Se representa por una línea de trazos que va desde
el caso que “usa”, al caso que es “usado”
• Relaciones de generalización:
• De un caso de uso A hacia un caso de
uso B indica que A es una
especialización de B
• Notación:
• Se representa por una línea sólida que
va desde el caso que se especializa
hasta el caso de uso padre
LAS PRE Y POS CONDICIONES
• Una condición previa o precondición

es el estado del sistema y de sus
alrededores, y que se requieren para
que el caso de uso pueda ser
comenzado.
• Una pos condición son los estados que
el sistema puede obtener después de
que el caso de uso haya finalizado
• Los estados descritos por las pre o las pos condiciones deben ser los estados que el usuario puede observar. “El usuario ha
entrado al sistema” o “el usuario ha abierto el documento”, son ejemplos de estados observables.
• Una condición previa en restricción que indica cuando el caso de uso puede comenzar
• Una precondición para un caso de uso no es una precondición para un solo flujo, sin embargo se puede definir
precondiciones y pos condiciones para los diferentes flujos (Normal, Alternos y Excepciones) .
• Una post condición para un caso de uso debe ser verdad sin importar que flujos de alternativa fueron ejecutados; no debe
ser verdad solamente para el flujo principal
• Si algo pudiese fallar, esa falla se cubriría indicando en la postcondición la acción. Por ejemplo: “la acción es
completada, o si algo falla, la acción no será ejecutada”
• Ejemplo:
• Una precondición para el caso de uso Retirar Dinero de un Cajero Automático
sería: El Cliente tiene una tarjeta personal que quepan el lector de tarjetas, debe
habérsele asignado una clave de uso de la tarjeta, y debe estar incluidos sus datos en
el sistema bancario.
• Una poscondición para el caso de uso Retirar Dinero de un Cajero Automático
sería: Al Final del caso de uso, toda la cuenta y los registros de la transacción deben
ser balanceados, la comunicación con el sistema bancario debe ser reinicializada y se
le ha devuelto al cliente su tarjeta.
LOS FLUJOS DE EVENTOS
• El flujo de eventos. Contenido
• El flujo de eventos de un caso de uso debe describir el flujo del caso de uso es decir cómo fluyen
los eventos claramente, para que cualquiera lo entienda fácilmente
• El flujo de eventos debe presentar lo que hace el sistema, no como el sistema es diseñado para
realizar el comportamiento requerido
• El flujo de eventos. Contenido
• Las pautas para el contenido del flujo de eventos son :
• Describa cómo comienza el caso de uso
• Describa qué datos se intercambian entre el actor y el caso de uso
• No te escriba los detalles de la interfaz utilizada, a menos que sea necesario entender el comportamiento
del sistema
• Es bueno incluir términos de terminología web cuando la aplicación es de este tipo. Palabras como:
navegar, browser, hiperlink, página, enviar, son aceptadas, no use los términos frames o página web.
• Describe el flujo de eventos, no solamente la funcionalidad. para cumplir con esto, comience cada
acción con “Cuando el”
• Describa solamente los eventos que pertenecen al caso de uso, y no que sucede en los otros casos de uso
o exterior del sistema
El flujo de eventos. Estructura
• Las 2 partes principales del flujo de eventos son: flujo básico de eventos y flujos
alternativos de eventos
• El flujo básico de eventos debe cubrir que “normalmente” sucede cuando se realiza el
caso de uso
• los flujos alternativos de eventos cubren comportamientos del carácter opcional o

excepcional en lo referente al comportamiento normal, y también a las variaciones de
comportamiento normal.
• Algunos flujos alternativos vuelven al flujo básico de eventos, mientras que otras
terminan el caso del uso.
• El flujo básico de eventos y los eventos alternativos de los flujos se deben

estructurar más a fondo en pasos
• Cada paso debe ser el segmento del comportamiento dentro del caso del uso
que tiene un propósito claro
• Usted puede ilustrar la estructura del flujo de eventos con el diagrama de
actividad
• Para clarificar donde un flujo alternativo de eventos se origina, se necesita indicar la
desviación explícitamente en el flujo básico de eventos, de la siguiente manera:
1. Donde, en el flujo básico de eventos el comportamiento alternativo puede ser insertado

2. La condición que necesita ser satisfecha para que el comportamiento alternativo inicie
3. Cómo y donde el flujo básico de eventos es resumido, o como el caso de uso termina
• Hay también flujo alternativo de los eventos que se pueden insertar en más de una
localización, algunos se puede incluso insertar en cualquier localización en el flujo básico de
eventos
TIPOS DE CASO DE USO
• Trazo Grueso
• Ignoramos detalles sobre la forma de interacción entre el actor y el sistema
• Sólo incluimos las alternativas más relevantes
• No entramos en detalles sobre las acciones que realiza el sistema cuando el usuario
interactúa con él
• Trazo Fino
• A medida que se hacen los prototipos de la IU, incluimos detalles sobre la forma de la
interfaz en la descripción del caso
• Incluimos otras alternativas. Errores o excepciones requeridas por el usuario
• Especificamos con más detalle el comportamiento interno del sistema
EL PROCESO DE ANÁLISIS DE
REQUERIMIENTOS CON CASOS DE USO
• Identificar los actores
• Identificar los principales CU por cada actor
• Identificar los nuevos CU apartir de los existentes
• Variaciones significativas de los CU existentes
• CU opuestos
• CU que preceden a casos existentes
• CU que suceden a casos existentes
• Crear descripciones de los CU de Trazo Grueso

• Definir prioridades y seleccionar CU de la primera interación (imprescindible, importante y
deseable)
• Escribir los CU de Trazo Fino y crear los Prototipos de Interfaces
REGLAS PARA EL USO DE LOS CASOS DE
USO
1. Un grafico de CU no debe mostrar más de 15 casos
2. La partición de los gráficos puede realizarse por actor
3. Si las relaciones que INCLUYE y EXTENSIÓN entran en el diagrama
principal, (sin dejar de cumplir la regla 1), deben dejarse ahi
4. Si las relaciones de INCLUYE no entran en el diagrama principal, se deben
mostrar en un gráfico teniendo en cuenta todos los CU que se usan en dicho
caso
5. Cuando un CU es usado por gran parte de los CU existentes, no debe
mostrarse en el gráfico principal
LA DIFERENCIA ENTRE CASOS DE USO Y
FLUJO DE EVENTOS
Eventos Casos de uso
• Describen qué hace el • Describen el diálogo entre
sistema cuando el evento el sistema y el usuario
ocurre
• Se “prolongan a lo largo
• Son atómicos: reciben una del tiempo” mientras dure
entrada, la procesan y la interacción del usuario
generan una salida con el sistema
• Lo importante son los • La importancia del detalle

datos de entrada o salida de información que se
del sistema mientras intercambia en secundaria
ocurre el evento

Casos de Uso

Cargado por

Copyright:

Formatos disponibles

Casos de Uso

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Casos de Uso

Cargado por

Copyright:

Formatos disponibles

CASOS DE USO

WALTER MOLINA LOPEZ

• Son una técnica para capturar la

• Agrupación uniforme de personas, sistemas o máquinas

• Generalización: una generalización desde

• Los casos de uso se documentan contexto informal

• Una condición previa o precondición

• los flujos alternativos de eventos cubren comportamientos del carácter opcional o

• El flujo básico de eventos y los eventos alternativos de los flujos se deben

1. Donde, en el flujo básico de eventos el comportamiento alternativo puede ser insertado

• Crear descripciones de los CU de Trazo Grueso

• Lo importante son los • La importancia del detalle

También podría gustarte