Casos de uso

Modelo: Descripción analógica (descripción simplificada) para ayudar a visualizar algo que no se puede observar directamente (por ser conceptos abstractos) y que se realiza con un propósito determinado y destinado a un publico.

"Los modelos no son los sistemas informáticos, sino su representación".

• Un mismo sistema puede tener varios modelos, que dependen del propósito y al publico al que se dirige.

¿Por qué el software necesita modelos?

• Para comunicar una idea abstracta, existente o no, o para describir un producto existente.

Casos de usos

• El caso de uso, es un concepto creado por Jacobson. Permite expresar la interacción típica entre una entidad externa a la aplicación, manejando una estructura de historia (narración) cuya principal ventaja es la facilidad de su entendimiento debido a que están basados en el lenguaje natural.
• Técnicamente un caso de uso representa una unidad funcional coherente de un sistema o sub-sistema a describir su secuencia de acciones incluyendo variantes y que produce un resultado observable de valor para algún actor.

¿Por qué casos de uso?

• Proporcionan un medio sistemático e intuitivo de capturar requerimientos funcionales centrándose en el valor añadido para el usuario.
• Dirigen todo el proceso de desarrollo debido a que la mayoría de actividades como el análisis, diseño y prueba se lleva a cabo partiendo los casos de uso.
• Ayudan al administrador de proyectos a planificar, asignar y controlar muchas de las tareas que los desarrolladores realizan.
• Son una entrada fundamental cuando se identifican clases, subsistemas e interfaces, cuando se identifican y especifican casos de prueba, y cuando se planifican las interacciones del desarrollo y la integración del sistema.

Beneficios:

Contribuciones paralelas con los participantes / clientes del proyecto que trabajan sobre:

-Flujo de proceso del negocio.

-Especificación de casos de uso o escenarios.

-Definición de reglas de negocio.

-Bosquejos de pantalla para UI prototipo.

-Diseño e implementación de modelos.

-Casos de pruebas.

Todos los involucrados en el proyecto contribuyen usando una comunicación básica o lenguajes de modelado que todos extienden.

Los involucrados en el proyecto comparten y encuentran información que enriquece:

-Las especificaciones de casos de uso.

-Los bosquejos de las pantallas.

-Las reglas del negocio.

-Los casos de prueba, etc.

Elementos del modelo de casos de uso:

En un caso de uso a una entidad externa se le denomina actor.

• El actor no necesariamente debe ser una persona puede ser un sistema, el tiempo, u otras organizaciones.
• Representan roles que un usuario puede jugar.
• Intercambian información con el sistema.
• Se nombran generalmente con sustantivos en singular..

Ejemplo: "Monigote".

Un caso de uso es:

• Una forma de usar el sistema o un uso que se le puede dar el sistema.
• Una secuencia de eventos útil con un principio y fin claros.
• Un conjunto de pasos e interacciones entre un usuario (actor) y el sistema para obtener algo de valor.

Pregunta clave para identificarlos (¿Para que puedo usar el sistema?).

Generalmente se nombra de manera corta y descriptiva comenzando con un verbo en infinitivo.

Ejemplo: "Caso de uso".

Los actores sólo pueden contener a los casos de uso através de asociaciones. Una asociación entre un actor y un caso de uso indican que el actor y el caso de uso se comunican entre si, y cada uno puede enviar y recibir mensajes.

Actores que proporcionan entradas a la izquierda y para los que se proporcionan salidas a la derecha.

Ciclo de vida de un caso de uso

Descripción Breve: Este caso de uso permite al secretario cerrar el proceso de registro. Los cursos ofrecidos que no tienen suficientes alumnos son cancelados. El sistema de facturación es notificado de cada estudiante en cada uno de los cursos ofrecidos que no fueron cancelados por lo que el estudiante puede ser facturado para el curso ofrecido.

*Cierre de Registro Resumen

-Flujo de eventos

-Paso a paso.

*Cierre de Registro Especificación del Caso de uso.

-Flujo de eventos detallado.

Requerimientos especiales.

-Pre/post condiciones.

Relación entre casos de uso.

• En ocasiones hay fragmentos de funcionalidad que varios casos de uso comparten, para evitar la repetición esta funcionalidad común la podemos factorizar en un caso de uso nuevo.
• Así los casos de uso que lo requieren, invocan al caso de uso factorizar.

Entre los casos de uso pueden darse dos tipos de relaciones:

-Dependencia: Implica que la funcionalidad engloba en un caso de uso depende de otro ya sea por que el primero (dependiente) incluye o extiende la funcionalidad definida por el segundo.

-Generalización: Implica que un caso de uso especializado reutilizado tanto el comportamiento como las relaciones que posee otro caso de uso más general.

Además, el caso de uso es especializado puede redifinir ciertas actividades definidas por el padre.

• Permite describir el mismo comportamiento múltiples veces.
• Simplifica la complejidad de flujo de eventos.
• El comportamiento no es parte del propósito principal.
• Representa un comportamiento que puede ser reutilizado en diferentes casos de uso base.

• La relación de inclusión se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento común en un caso de uso aparte (que será incluido por un caso de uso base).