Desarrollo de software orientado a objetos

Unidad 3:Casos de Uso

Actores y casos de uso del Sistema

Especificación de casos de uso

Organización del modelo de casos de Uso

Agenda

Actores y casos de uso

Casos de Uso y Procesos de Negocios

EMPRESA SISTEMA ARTEFACTOS

¿Cuáles son los procesos de negocios?

Análisis de requerimientos

Casos de Uso del Negocio

Casos de Uso

Modelo de Casos de Uso Un modelo de casos de uso

describe las funciones a desarrollarse en el sistema y a los actores que las utilizan.

Es usado en los workflows de requerimientos, análisis y diseño y prueba.

Objetivo: Comunicar la funcionalidad y el comportamiento al cliente y al usuario

Workflows y Casos de Uso

Actor representa cualquier cosa que interactúa con el sistema (humano, SW o HW). Ejemplo: Cajero

Caso de Uso secuencia de acciones que obtienen resultados de valor para un actor Proceso del sistema

Casos de uso y Actores

¿Límites delSistema?

Sistema ATM

Cajero Bancario

Cliente

Sistema Bancario

Actores y ámbito del sistema

Definiendo los límites del sistema

SistemaHeredado

Comunicaciones

Usuarios

Reportes

Nuevo Sistema

Mantención

Otros Sistemas

• El análisis de los casos de uso incluye entender el dominio de los procesos y el medio externo ¿Cuáles son los actores que participan en los procesos?

Casos de Uso

Error común ...

Los casos de uso describen los procesos a automatizar.

Representar pasos

Casos de Uso

Actores

No son parte del sistema, son roles de un usuario.

Puede intercambiar información con el sistema (actor directo).

Puede ser un recipiente pasivo de información (actor indirecto).

Puede representar a un humano, una máquina o un SW.

¿Cómo encontrar los actores?Preguntas de ayuda ¿Quién está interesado en cierto

requerimiento (se beneficia o se ve afectado)?

¿Dónde en la organización es usado el sistema?

¿Quiénes usan, eliminan o suministran información?

¿Quién usa una determinada función?

¿Cómo encontrar los actores? ¿Quién soporta y mantiene el

sistema? ¿Usa el sistema un recurso externo? ¿Cuáles actores necesita el caso de

uso? ¿Un actor juega diferentes roles? o

¿Varios actores juegan el mismo rol (generalización /especialización)?

Instancias de Actores

1 2 34 5 67 8 9* 0 #

InserteTarjeta

Iván secomportacomo Actordel Sistema Tomás se

comportacomo Actordel Sistema

Actor Caso de Uso

Modelo de Caso de Uso

Un usuario puede desempeñar el rol de varios actores……

1 2 34 5 67 8 9* 0 #

Insert cardJimmy esOperador

Cliente

Operador

Jimmy tambiénes Cliente

Jimmy

Dos actores pueden realizar idénticas tareas

1 2 34 5 67 8 9* 0 #

InserteTarjetaIván es

un cliente

Jimmy es unoperador

• Tanto el cliente como el operador pueden efectuar transacciones en un cajero automático

• El cliente y el operador son usuarios del cajero automático.

• El usuario puede efectuar transacciones en un cajero automático

Cliente Operador

Usuario

Usuario EfectuarTransacciones

Identificación de los casos de uso Método basado en los Actores. Método basado en Eventos. Análisis del modelo de casos de

uso del negocio (business modeling).

Análisis de Requerimientos.

Método basado en los Actores Se relacionan los actores vinculados con un sistema o empresa.

Para cada actor, se identifican los procesos que ellos inician o en los que participan.

Método basado en los ActoresPreguntas clave: ¿Cuáles son las tareas de este actor? ¿Qué objetivos concretos necesita

alcanzar un actor? ¿Puede el actor crear, almacenar,

remover o leer información en el sistema?

El actor, ¿necesita estar informado acerca de las ocurrencias del sistema?

Método basado en Eventos

Se identifican los eventos externos a los que un sistema debe responder.

Se relacionan los eventos con los actores y con los casos de uso.

Es útil para este método establecer una tabla de eventos.

Tabla de Eventos

Evento Entrada Fuente Salida Destino

Se requiere registrar a un cliente

Datos del Cliente

Vendedor

Se requiere registrar una Venta

Datos de la Venta

Cajero Comprobante de Venta

Cliente

Se requiere emitir un EECC

Estado de Cuenta

Cliente

Análisis del modelo de casos de uso del negocio Exploración de los diagramas

Análisis del modelo de casos de uso del negocio Transición natural (AS IS)

Análisis del modelo de negocio Transición natural (AS IS)

Análisis del modelo de negocio Análisis del diagrama de actividades

Solicita revisión de l ista de precios

Aprueba?

Remite Nueva Lista a T iendas

Si

Consulta información del mercado

No

Realiza ajuste de precios de productos y ofertas

Es campaña

NoBusca productos a

ofertar

SI

Hay nuevos productos?

No

Define productos para la venta

Si

P1 : BE-Producto

PO : BE-PrecioEnvia l ista a Gerente de Ventas

AV : BW -Asistente VentasGV : BA-Gerente Ventas

Análisis del modelo de negocio Transición con mejora de procesos

Análisis del modelo de negocio Transición de los objetos de

negocio

Análisis del modelo de negocio Redefinición de los procesos

(TO BE)

Matriz de actividades y requerimientos

Al identificar los requerimientos se pueden enlazar con los casos de uso (fase 2)

Caso de uso de negocio

Activi-dades

Respon-sable

Requeri-mientos

Caso de uso

Actor

“Trazabilidad”: Enlace de requerimientos y casos de uso

Verifique que los requerimientos de menor nivel, sean consistentes con los

requerimientos estratégicos.

Documento de VisiónPR10:La máquina de reciclado deberá permitir que se agreguen nuevos tipos de botella.

[UC4: “Agregue nuevo Tipo de Botella”]Para agregar nuevos tipos de botella se debe activar el modo “aprendizaje” e insertar 5 ejemplos...

Característicadel Sistema

Caso de Uso

Especificación de casos de uso

Especificación de Casos de Uso La especificación de un caso de

uso es el documento narrativo que describe la secuencia de eventos que realiza un actor (agente externo) para completar un proceso, a través del uso de un sistema.

Tipos de Casos de Uso

Primario: Representan los casos mas importantes y comunes. Ej.: Alquiler de libros

Secundario: Representan procesos menores o raros. Ej.: Alquiler entre bibliotecas.

Opcional: Representan que pueden no abordarse. Ej.: Remate de libros

Niveles de especificación de casos de uso Existen tres niveles de

especificación de casos de uso dependiendo del nivel de identificación y desarrollo de los mismos. De Alto Nivel Esencial Real

Casos de uso de Alto Nivel

Describe el caso de uso muy brevemente, resumiendo la esencia del mismo en breves enunciados.

Son útiles durante el examen inicial de los requerimientos y del proyecto.

No influyen de manera determinante en las decisiones de diseño.

Casos de uso de Alto Nivel

Caso de Uso Realizar Préstamo

Actores Socio (indirecto, iniciador)Bibliotecario (directo)

Tipo Primario

Descripción Un socio elige los recursos de biblioteca que desea solicitar en préstamo, luego el bibliotecario los registra como “prestados” y el socio se los lleva por un plazo determinado.

Referencias Requerimientos R1, R2

Especificación Esencial

La especificación esencial de un caso de uso es el documento narrativo que describe la secuencia de eventos que realiza un actor (agente externo) para completar un proceso, a través del uso de un sistema.

Escenario de un Caso de Uso Un escenario es una instancia de un

caso de uso, en donde se dan un conjunto de factores.

Cada cada de uso tiene un conjunto de escenarios clasificados en: Primarios o de flujo de eventos normal

(describen cómo trabaja usualmente el sistema).

Alternativos, se producen de acuerdo a excepciones con el escenario primario.

Casos de uso esenciales

Entonces…muestran más detalle que uno de alto nivel.

Tiene una sección destinada al flujo normal de los eventos que los describe paso a paso.

Tiene muchas secciones destinadas a describir los flujos alternativos.

Se identifican las pre y post condiciones.

Se asocian los requerimientos especiales (No funcionales).

Casos de Uso y flujo de eventos Un caso de uso describe “que

hace” un sistema, pero no identifica “cómo”.

Un flujo de eventos describe el cómo (parcialmente) al interior de un caso de uso.

Cuando se modela, es importante que se conserve la separación de la vista interna y externa.

Caso de uso esencial: Encabezado

Nombre Realizar Préstamo de Libros

Actores Socio (Indirecto e iniciador)Bibliotecario (Directo)

Tipo Primario y Esencial

Propósito Capturar un préstamo y sus condiciones de devolución.

Descripción

Un socio elige los libros que desea llevarse en préstamo. El bibliotecario registra los libros y consigna su fecha de devolución. El socio se lleva los libros aceptando las condiciones que se le han indicado

Referencias

Requerimientos: R1, R2Anexos: A1, A2

Caso de uso esencial: Flujo normal de eventos

Acción del actor Respuesta del sistema

1. Comienza cuando el socio selecciona libros en calidad de préstamo y se identifica como socio

2. El bibliotecario registra al socio y los libros solicitados por el socio

3. Valida al socio y determina la fecha de devolución de los libros.

4. El bibliotecario termina el registro del préstamo.

5. Muestra aviso de registro del préstamo OK

6. El socio se lleva los libros solicitados.

Caso de uso esencial: Flujo alternativo de eventos

Acción del actor Respuesta del sistema

En el punto 2 del flujo normal

2. El bibliotecario registra al socio y los libros solicitados por el socio

3. Valida que el socio no existe o está con deudas

4. El bibliotecario avisa al socio que debe regularizar su situación y finaliza el préstamo.

Pueden ayudar a identificar las clases....después

Pre y Post Condiciones

Describen los cambios de estado del sistema cuando se ejecuta un caso de uso.

Pre Condiciones

Son suposiciones sobre el estado del sistema al iniciarse una operación. Cosas que son importantes

probar en el SW en algún momento de la ejecución.

Cosas que no serán sometidas a pruebas pero de las cuáles depende el éxito de la operación.

Cambios (en pretérito) de estado

Post Condiciones Describen el estado de un sistema luego de ejecutarse

un caso de uso. No se refieren a las acciones a realizar en un futuro

inmediato. Se redactan con verbos en pasado.

Post Condiciones

Categorías de Post-Condiciones: Creación y eliminación de

objetos Modificación de atributos Asociaciones formadas y

canceladas

Ejemplo de Pre y Post-Condiciones

Pre-Condiciones: Se deben reconocer los ejemplares de

libros por código El sistema debe conocer el tiempo de

devolución estándar por tipo de socio.

Post-Condiciones: Se creó un objeto préstamo. Se asociaron ejemplares de libros al

préstamo. Se asoció un socio al préstamo

Requerimientos Especiales

En esta sección del caso de uso se asocian los requerimientos no funcionales de mayor impacto sobre el caso de uso.

Organización del modelo de casos de uso

Diagramas de casos de uso

Representa un conjunto de casos de uso para un sistema, los actores y la relación entre casos de uso y Actores

Similar a un Diagrama de Contexto

Devolver Libros

Realizar Préstam

o

Reservar Libros

Bibliotecario

Socio

BIBLIOTECA

Diagrama de casos de uso

Priorizar Casos de Uso

Se puede hacer sobre la base de la experiencia...

Seleccionar los que influyan profundamente en la arquitectura básica, dando soporte al dominio y a las capas de servicio de alto nivel o

Escoger los que presenten el máximo riesgo, funciones urgentes o complejas en las primeras iteraciones.

Priorizar Casos de Uso

Seleccionar.... Los que requieran investigación a

fondo o nueva tecnología. Aquellos que representen

procesos primarios o la línea de negocio.

Los que apoyen directamente el aumento de ingresos o la reducción de costos.

Priorizar casos de uso

Sobre la base de ponderaciones... Se definen valores a los atributos de

los requerimientos. Se aplican pesos a los diferentes

valores de los atributos. Se calcula el peso total de cada

requerimiento. Se priorizan los requerimientos de

mayor peso total.

Priorizar casos de uso

Debe haber un caso de uso de inicio o arranque

Un caso de uso puede abordarse en varias iteraciones incrementando su funcionalidad.

Organización del modelo de casos de uso Tareas:

Establecer relaciones de "inclusión" entre los casos de uso.

Establecer relaciones de "extensión" entre los casos de uso.

Establecer las "generalizaciones" entre los casos de uso.

Establecer las "generalizaciones" entre los actores.

Evaluar los resultados.

Relación de Generalización

La generalización entre casos de uso es como la generalización entre clases.

En concreto, significa que el caso de uso “hijo” adiciona o antepone el comportamiento del caso de uso “padre”

Relación de Inclusión

Significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso.

Se usan para evitar describir el mismo flujo de eventos varias veces.

También se usan para ocultar funcionalidad.

Es esencialmente un ejemplo de delegación.

Relación de Extensión

Significa que existe un caso de uso base que implícitamente incorpora el comportamiento de otro caso de uso.

El caso de uso base puede desarrollarse normalmente, pero ante ciertas condiciones sus operaciones pueden extenderse al comportamiento de otro caso de uso.

Las casos de uso de extensión se pueden encontrar en los flujos alternativos de eventos significativos.

Ejemplos de relaciones

ProgramarOrdenes

Efectuar seguimientode Ordenes Validar

Usuario

ColocarOrdenesurgentes

Validarpassword

Escaneode Fotochecks

generalización

«inclusión»

«inclusión»

«extensión»

Uso de Paquetes

Los paquetes se usan para agrupar casos de uso de acuerdo a grandes procesos o gestiones.

Los paquetes deben guardar relación con la estructura del menú de la aplicación y los casos de uso con las funciones/opciones del mismo.

Uso de Paquetes

Un primer diagrama debe organizar los grandes procesos en paquetes.

Cada paquete se puede descomponer en otro paquete o en casos de uso.

En un diagrama de paquetes no debe haber casos de uso.

La única relación entre paquetes es la dependencia.

La organización de paquetes en los casos de uso debe ser similar a la forma como se organiza el menú de la aplicación.

Uso de paquetes

Gestiónde

Pedidos

Gestiónde

Cobranza

Gestiónde

Ventas

Conclusiones El modelo de casos de uso sirve como

herramienta de comunicación con los usuarios y otros expertos.

Permite organizar los requerimientos del sistema.

Permite identificar interacciones de los actores con el sistema.

Permite identificar interfaces. Permite planificar iteraciones. Permite establecer el plan de pruebas del

sistema.