Transcript Los casos de uso definen las características requeridas por

Casos De Uso Del Sistema
Lic. César Alcántara Loayza
Diagramas de Casos de Uso

Elementos:





CAL/Fundamentos
Sistema
Actores
Casos de uso
Asociaciones
Dependencias
Diagrama de Casos de Uso
2
3
1
4
5
Actor_1
Case_2


1. Actor – Persona, sistema o dispositivo que participa en la operación
exitosa del sistema.
2. Sistema – Contexto del sistema con relación a los actores que usarán
las características que proveerá.
CAL/Fundamentos
Diagrama de Casos de Uso



CAL/Fundamentos
3. Caso de Uso – Identifica las
características clave del sistema. Sin estas
características el sistema no cumpliría con
los requerimientos del usuario/actor. Cada
caso de uso expresa una meta que el
sistema debe lograr.
4. Asociaciones - Identifica interacción
entre casos de uso y actores.
5. Dependencia – identifica interacción
entre casos de uso. (estereotipo).
Diagramas de Casos de Uso

En los diagramas de casos de uso tanto
a las personas, sistemas y dispositivos
se les refiere como actores. Un actor es
un rol que juega una entidad externa
con relación al sistema.

CAL/Fundamentos
Típicamente los actores son los sujetos
de la frase que describe como usará el
sistema.
Límites del Sistema

CAL/Fundamentos
Constituido principalmente por los
actores del sistema y sus casos de uso.
Identificando Actores

Si modelamos desde el Negocio, los
actores del sistema, serán:


CAL/Fundamentos
Los trabajadores del negocio cuyas tareas
sean soportadas por el sistema.
Los actores del negocio que tengan
soporte directo del sistema.
Identificando Actores








CAL/Fundamentos
¿quién usa el sistema?
¿quién instala el sistema?
¿quién arranca el sistema?
¿quién mantiene el sistema?
¿qué otros sistemas usan el sistema?
¿quién obtiene información del sistema?
¿quién provee información al sistema?
¿Ocurre algo automáticamente?
Identificando Casos de Uso




¿qué funciones necesitará el actor del sistema?
¿El sistema almacemará información?, ¿qué
actores la crean, leen, actualizan o borran aquella
información?.
El sistema necesita notificar a un actor acerca de
cambios en sus estados internos?.
¿Existe algún evento externo que el sistema deba
conocer?, ¿qué actor informa al sistema de
aquellos eventos?.
CAL/Fundamentos
Actores y Casos de Uso

Descripción de los actores de Procesamiento de
Ordenes:





CAL/Fundamentos
Cliente: una persona que ordena los productos a
National Widgets.
Representante de Cliente: Un empleado de National
Widgets quien procesa las solicitudes del cliente.
Compañía de despacho: DHL, FedEx, otras
Empleado: Un empleado de National Widgets quien
empaca, rotula y despacha ordenes.
Sistema de Inventario: Software que ratrea el
inventario de la Empresa.
Actores y Casos de Uso


CAL/Fundamentos
En el proceso de identificación y
definición de actores y casos de uso, se
puede determinar los límites del sistema
(fronteras) – lo que esta dentro del
sistema (casos de uso) y lo que está
fuera (actores). Se registra esta
información en un diagrama de casos de
uso.
Se refina a lo largo del proceso.
Actores – Rol - Tareas

Es frecuente modelar los roles en
función a las descripciones de trabajo y
flujos de trabajo, pero las
organizaciones de personas y tareas es
lo que mas cambia. Las cosas que una
persona hace deberían estar separadas
de las asignaciones de trabajo.
CAL/Fundamentos
Alcance del proyecto

Habiendo determinado los límites del
sistema, se puede establecer el alcance
del proyecto.


CAL/Fundamentos
Un proyecto tiene una fecha de inicio y un
final y dinero para gastos que cubran las
metas del proyecto.
Se debería priorizar los requerimientos.
Requerimientos MoSCoW





CAL/Fundamentos
Algunos requerimientos se deben satisfacer,
los procesos básicos del sistema. Requeridos ó
Must Have.
Otros son importantes pero no vitales –
Importantes o Should Have.
Otros podrían ser bonitos tenerlos – Bonitos o
Could Have.
El resto son sueños – Futuros ó Would Like to
Have.
MoSCoW
Requerimientos FURPS+
Existen muchas clases diferentes de requerimientos.
Una forma de categorizar es descrita por el modelo
FURPS+, Utilizando el acrónimo FURPS para
describir las categorías principales de requerimientos
con subcategorías como se muestra:
• Funcionality (funcionalidad)
• Usability (Facilidad de uso)
• Reliability (Confiabilidad)
• Performance, (Rendimiento) y
• Supportability (Soporte)
CAL/Fundamentos
Requerimientos FURP+
El "+" en FURPS+ le ayuda a recordar que también
incluye otros requerimientos como:
• Restricciones de diseño,
• Requerimientos de implementación,
• Requerimientos de interfase y
• Requerimientos físicos.
CAL/Fundamentos
Dibujando Diagramas CUS




CAL/Fundamentos
Comenzar dibujando el sistema;
provienen del contexto definido del
proceso (casos de uso del negocio)
Adicionar actores al diagrama para
representar los roles que los usuarios
humanos juegan en relación al sistema.
Adicionar el rotulo del nombre del actor
Adicionar otro actor, puede ser un
sistema.
Dibujando Diagramas CUS


Los casos de uso definen las características
requeridas por el sistema. Sin tales
características el sistema no podría tener éxito.
Denomine cada Caso de Uso con una frase con
Verbo que exprese el objetivo del sistema que
se debe cumplir, ejem. Depositar dinero,
prestar dinero, ajustar cuenta. Aunque cada
uno de ellos implica un proceso de soporte, el
enfoque está en el objetivo no en el proceso.
CAL/Fundamentos
Dibujando Diagramas CUS

CAL/Fundamentos
Al definir los CUS de esta forma, el
sistema es definido como un conjunto
de requerimientos en vez de una
solución. No se describe como hace el
sistema, se describe lo que el sistema
es capaz de hacer. Describe solo
aquellas características visibles y
significativas a los actores quienes
usarán el sistema.
Dibujando Diagramas CUS

Esto ayuda a evitar la descomposición
funcional, partir procedimientos y tareas
en procesos mas y mas pequeños hasta
tener descritos todo el comportamiento
interno del sistema.
CAL/Fundamentos
Asociaciones y Dependencias


CAL/Fundamentos
Una asociación se representa por una
línea que conecta a un actor con un
caso de uso. Con flecha o sin flecha.
Lo importante es identificar que casos
de uso necesita acceder el actor.
Asociaciones y Dependencias


CAL/Fundamentos
En ciertos casos un caso de uso necesita
de otro; para lo cual se usa una relación
de delegación a través de un estereotipo
<<include>>
Un estereotipo funciona como un
calificador sobre un elemento del modelo,
dando mas información acerca del
elemento sin ver su implementación.
Asociaciones y Dependencias


CAL/Fundamentos
<<include>> un caso de uso siempre
buscará la ayuda de otro caso de uso.
Ejecución incondicional.
<<extends>> un caso de uso buscará ayuda
de otro caso de uso si se encuentra una
condición específica. Ejecución condicional.
Descripción Narrativa de CUS


Los diagramas son muy concisos para
describir lo que el usuario espera.
La mayoría de descripciones narrativas
de Casos de Uso incluyen lo siguiente:

CAL/Fundamentos
Supuestos: condiciones que deben probar
ser ciertas para usar el caso de uso. Se
colocan normalmente en un documento de
overview en vez de incluirlos en cada CU.
Descripción Narrativa de CUS


CAL/Fundamentos
Precondiciones: Condiciones que deben ser
ciertas para usar el caso de uso. A
diferencia de los supuestos estos deben ser
probados por el caso de uso antes de
hacer algo. Si la condición no es cierta no
se permite que el actor u otro caso de uso
lo ejecute.
Proceso: Descripción paso a paso del
dialogo entre el caso de uso (sistema) y el
usuario (actor u otro caso de uso). ....
Descripción Narrativa de CUS


CAL/Fundamentos
... Frecuentemente es útil modelar la
secuencia de eventos usando un diagrama
de actividad.
Post-Condiciones: Condiciones que deben
ser ciertas cuando el caso de uso finaliza.
Debe garantizar que el sistema es estable
cuando el caso de uso finaliza.
Descripción Narrativa de CUS

Una buena pregunta que debemos
hacer es:

CAL/Fundamentos
¿Cómo puedo usar el modelo de casos de
uso para determinar los requerimientos del
flujo de trabajo y las pantallas?.
Ejemplo






CAL/Fundamentos
Nombre
Retiro de Efectivo
Número
11.0
Autor
Joe
Ultima actualización 01/04/03
Supuestos
El usuario ha proporcionado
una tarjeta y password válidos.
Precondiciones: El usuario proporciona una
cantidad válida de retiro (notar que esta es la
primera prueba ejecutada por el dialogo).
Ejemplo

Descripción del Caso de Uso:


Inicialización: El caso de uso se inicia sobre
demanda.
Dialogo del Caso de Uso:



CAL/Fundamentos
El sistema pregunta por la cantidad de retiro.
El usuario proporciona el monto.
La maquina ATM (cajero) verifica que la cantidad esté
dentro de los límites permitidos y si es divisible por la
denominación definida, ej. Multiplos de $20. Si la
cantidad no cumple estos requerimientos, el usuario
recibe un mensaje de error.
Ejemplo




CAL/Fundamentos
De otro modo el ATM intenta conectarse con el
banco.
Si la conección no tiene éxito el usuario recibe
un mensaje de error.
Si se dispone de fondos, elt ATM le dá al
usaurio su dinero e imprime una boleta.
Si no se dispone de fondos, el usuario recibe
un mensaje de error.
Ejemplo

Finalización del caso de uso:

El caso de uso finaliza cuando:




CAL/Fundamentos
El sistema entrega el dinero e imprime la
boleta.
El sistema muestra el mensaje de error
indicando que el monto es inválido.
El sistema muestra el mensaje de error
indicando que no se puede conectar con el
banco.
El usuario cancela la transacción.
Ejemplo

Post_Condiciones:

Al termino éxitoso del retiro:

El sistema imprime el saldo final sobre la
boleta:




CAL/Fundamentos
La cuenta bancaria es actualizada.
La transacción es concluida
Bajo una condición de error, el ATM regresa a
su estado inicial.
Bajo una opción de cancelación, el ATM regresa
a su estado inicial.
Plantilla
CAL/Fundamentos
Guías


CAL/Fundamentos
Resista la tentación de tener mucho detalle,
se añadirá detalle mas adelante en el
proceso, estamos colectando requerimientos
no haciendo el análisis y diseño detallado.
El escenario necesita estar completo – se
debe ser claro en los puntos de inicio y
finalización - y estar seguro que la lista de
pasos cubre en general todo lo que necesita
para describir la funcionalidad del caso de
uso.
Guías



CAL/Fundamentos
Tendremos un gran porcentaje de casos de
uso que comienzan y terminan con un actor.
Pueden existir un número pequeño de casos
de uso que empiecen con el actor y terminen
internamente.
Los escenarios son escritos desde el punto de
vista del actor. Por lo tanto todos los pasos en
sus escenarios deberian ser visibles a /o por
el actor.
Guías



Los escenarios son herramientas de
comunicación – Son efectivos solo cuando
pueden comunicar información acerca del
trabajo del sistema.
Importante considerar quien leerá los escenarios
– si no los entiende deberían rehacerse.
Verificar en cada escenario primario uno por uno
y preguntarse para cada paso ¿qué es lo mas
probable que ocurra aquí? – esto es que debería
escribir para este paso particular.
CAL/Fundamentos
Guías

CAL/Fundamentos
Incluir suficiente información en los
escenarios para ser capaz de determar
si un caso de uso particular maneja una
funcionalidad particular.
Escenarios de Casos de Uso


CAL/Fundamentos
Los casos de uso identifican objetivos
primarios del sistema. Cuando un actor
intenta alcanzar un objetivo usando el
sistema, existen decisiones o reglas que
podrían variar el resultado
Cada posible resultado de un intento de
alcanzar un objetivo es llamado escenario. Un
escenario es una única ruta lógica através de
un dialogo de un caso de uso.
Escenarios de Casos de Uso


CAL/Fundamentos
Generalmente es preferible utilizar los
diagramas de actividad para definir los
escenarios. Es ejecutar el caso de uso.
Un escenario es la ejecución particular
de un caso de uso, frecuentemente
usado como un caso de prueba
Ejercicio

Para el ejercicio Realizar Ordenes



Hacer la Realización de CUN.
Derivar CUS a partir del modelo CUN.
preparar descripciones narrativas de cada
CUS, usando los cuatro elementos básicos:



CAL/Fundamentos
Precondiciones
Diálogo y
Postcondiciones
Ejercicio Realizar Ordenes

Declaración del problema:

Recepción


Almacenes

CAL/Fundamentos
El empleado de recepción recibe los embarques
que ingresan emparejando las ordenes de
compra contra el stock del embarque. Ellos
informan al departamento de cuentas por pagar
cuando los artículos de la orden de compra se
han recibido.
El stock puede provenir de ordenes canceladas,
ordenes regresadas y embarques recibidos. El
Ejercicio


Ejecución de la orden

CAL/Fundamentos
..stock es colocado en el almacen en ubicaciones
predefinidas. El empleado de stock busca la ubicación
correcta para el nuevo stock, coloca el stock en la ubicación
y actualiza el inventario con la ubicación y cantidad.
Otros empleados cubren ordenes localizando el stock
necesario para la orden. A medida que cubren la orden
actualizan el inventario para reflejar el hecho que ellos han
tomado stock. Ellos también notifican al departamento de
procesamiento de ordenes que la orden ha sido completada.
Ejercicio

Despacho

CAL/Fundamentos
Cuando las ordenes se han completado son
empacadas y preparadas para el despacho. Los
empleados de despacho contactan a
despachadores para realizar las entregas y
actualizan el inventario para regostrar el hecho
de que los ya se han despachado los
productos. Ellos también notifican al
departamento de procesamiento de ordenes
que la orden fue despachada.
Business Systems
CAL/Fundamentos
Actores




CAL/Fundamentos
Cliente : es el comprador
Proveedor : quien suministra mercaderías a
la empresa através de embarques.
Cuentas por Pagar: es a quien se notifica
cuando los artículos han llegado al
almacén.
Despachador: en el caso de tratarse de
terceros subcontratados para hacer el
reparto de la mercadería.
Trabajadores



CAL/Fundamentos
Empleado de stock
Empleado de recepción
Empleador de despacho
Diagrama De CUN
CAL/Fundamentos
Especificación CUN

Despacho de Ordenes
El Cun empieza cuando los empleados
atienden las ordenes del cliente
localizando el stock necesario.
2. El negocio actualiza el stock y notifica al
departamento de procesamiento de
ordenes que la orden está completa.
3. Se empaca y despacha la orden y se
notifica que la orden está despachada.
1.
CAL/Fundamentos
Especificación CUN

Flujos Excepcionales (alternativos)
1.
2.
3.
CAL/Fundamentos
No se localiza stock.
Demora en la actualización de stock
Demora en el empaque y despacho.