Modelado de casos de uso

Un diagrama de casos de uso de  UML   es la forma principal de requisitos de sistema/software para un nuevo programa de software en desarrollo. Los casos de uso especifican el comportamiento esperado (qué) de un sistema, y ​​no el método exacto para hacerlo realidad (cómo). Un conjunto completo de casos de uso especifica todas las diferentes formas de usar el sistema y, por lo tanto, define todo el comportamiento requerido del sistema que limita el alcance del sistema.

Un concepto clave del modelado de casos de uso es que nos ayuda a diseñar un sistema desde la perspectiva del usuario final. Es una técnica efectiva para comunicar el comportamiento del sistema en los términos del usuario al especificar todo el comportamiento del sistema visible externamente.

Diagrama de caso de uso de un vistazo

Una forma estándar de diagrama de casos de uso se define en el Lenguaje de modelado unificado como se muestra en el siguiente ejemplo de Diagrama de casos de uso:

¿Qué es un caso de uso?

• Un caso de uso es una colección de posibles secuencias de interacciones entre el sistema en discusión y sus actores externos relacionados con un objetivo particular.
• Cada caso de uso es un curso completo de eventos en el sistema desde la perspectiva del usuario.
• Los casos de uso, una vez especificados, se pueden denotar como representación textual y visual (es decir, diagrama de casos de uso).
• Los casos de uso son el método preferido por la comunidad de componentes y objetos para especificar requisitos y, de hecho, para impulsar todo el proceso de desarrollo de software.
• Los casos de uso generalmente se apegan a tareas bastante importantes; no es necesario escribirlos para cada acción que el usuario pueda realizar.

Beneficios del enfoque de casos de uso

Los casos de uso brindan muchos beneficios más allá de definir los requisitos del usuario. Los casos de uso se pueden utilizar para:

• Ayuda de casos de uso para capturar los requisitos funcionales de un sistema.
• Los casos de uso son rastreables.
• Los casos de uso pueden servir como base para el esfuerzo de estimación, programación y validación.
• El caso de uso puede evolucionar en cada iteración desde un método de captura de requisitos, a pautas de desarrollo para programadores, a un caso de prueba y finalmente a la documentación del usuario.
• Las rutas alternativas de casos de uso capturan un comportamiento adicional que puede mejorar la solidez del sistema.
• Los casos de uso han demostrado ser fácilmente comprensibles para los usuarios comerciales y, por lo tanto, han demostrado ser un excelente puente entre los desarrolladores de software y los usuarios finales.
• Identificar clases de dominio empresarial y sus asociados

Actor

• Alguien interactúa con el caso de uso (función del sistema).
• Nombrado por sustantivo.
• El actor juega un papel en el negocio.
• Similar al concepto de usuario, pero un usuario puede desempeñar diferentes roles
• Por ejemplo:
• un profe puede ser instructor y también investigador
• juega 2 roles con dos sistemas
• El actor activa los casos de uso.
• El actor tiene responsabilidad hacia el sistema (entradas) y el actor tiene expectativas del sistema (salidas).

Caso de uso

• Función del sistema (proceso — automatizado o manual)
• Nombrado por verbo + sustantivo (o frase nominal).
• es decir, haz algo
• Cada actor debe estar vinculado a un caso de uso, mientras que algunos casos de uso pueden no estar vinculados a actores.

Enlace de comunicación

• La participación de un actor en un caso de uso se muestra conectando un actor a un caso de uso mediante un enlace sólido.
• Los actores pueden conectarse a los casos de uso mediante asociaciones, lo que indica que el actor y el caso de uso se comunican entre sí mediante mensajes.

Límite del sistema

• El límite del sistema es potencialmente todo el sistema como se define en el documento de requisitos.
• Para sistemas grandes y complejos, cada módulo puede ser el límite del sistema.
• Por ejemplo, para un sistema ERP para una organización, cada uno de los módulos como personal, nómina, contabilidad, etc.
• puede formar un límite del sistema para casos de uso específicos de cada una de estas funciones comerciales.
• El sistema completo puede abarcar todos estos módulos que representan el límite general del sistema

Análisis de casos de uso en 6 pasos

Al desarrollar casos de uso, debe comenzar con una partición funcional: una lista de las principales categorías funcionales del sistema de destino. Esto ayudará a identificar en qué áreas deben enfocarse.

Paso 1: identifique a los actores: identifique quién va a usar el sistema directamente. Estos son los Actores.

• Uno de los principales componentes del desarrollo de casos de uso son los actores.
• Un actor es un rol específico que desempeña un usuario del sistema y representa una categoría de usuarios que muestran comportamientos similares al usar el sistema.
• Los actores pueden ser personas o sistemas informáticos.
• Un actor primario es aquel que tiene una meta que requiere la asistencia del sistema.
• Un actor secundario es aquel del que el sistema necesita asistencia para satisfacer su objetivo.
• Uno de los actores es designado como el sistema en discusión.
• Una persona puede desempeñar varios roles y, por lo tanto, representar a varios actores, como el operador del sistema informático o el usuario final.

Paso 2: elige uno de esos actores.

• Para identificar el caso de uso de un sistema de destino, identificamos los actores del sistema.
• Un buen punto de partida es verificar el diseño del sistema e identificar a quién se supone que debe ayudar.

Paso 3: Identifique los casos de uso: defina lo que ese actor quiere hacer con el sistema. Cada una de estas cosas que el actor quiere hacer con el sistema se convierte en un caso de uso.

• Las cosas que los actores quieren hacer con el sistema se convierten en objetivos.
• El objetivo es el resultado final de las acciones del usuario. Hay dos tipos de objetivos. El primer tipo es un objetivo rígido.
• Este objetivo debe cumplirse por completo y describe el requisito mínimo de un sistema de destino.
• Para identificar casos de uso, podemos leer la especificación de requisitos desde la perspectiva de un actor y llevar a cabo discusiones con aquellos usuarios que funcionarán como actores.
• Al definir todo lo que cada actor podrá hacer en interacción con el sistema, se define la funcionalidad completa del sistema.

Paso 4 — Identifique el escenario de caso de uso normal: para cada uno de esos casos de uso, decida el curso más habitual cuando ese actor está usando el sistema. Lo que normalmente sucede.

• Un caso de uso tiene un curso básico y varios cursos alternativos.
• El curso básico es el curso más sencillo, aquel en el que se entrega un pedido sin ninguna dificultad.
• Puede haber cursos alternativos que describan variantes del curso básico y los errores que pueden ocurrir.
• Estos se documentan como extensiones del caso de uso.

Paso 5: desarrollar la descripción del caso de uso: Describa ese curso básico en la descripción del caso de uso.

• El escenario de uso está escrito desde la perspectiva del usuario en un lenguaje fácil de entender.
• Se escriben los pasos necesarios para lograr el objetivo identificado, conocido como flujo de eventos.

Paso 6: desarrollar rutas alternativas de casos de uso: una vez que esté satisfecho con el curso básico, considere las alternativas y agréguelas como casos de uso extendidos.

Escenarios alternativos de un caso de uso

Un caso de uso también describe cómo debe responder el sistema cuando las cosas  no  salen bien o  salen bien , pero  no   de la manera que describimos en el escenario de éxito principal. A estas situaciones las llamamos  extensiones .

• Hay dos variedades:  excepciones  y  suplentes .
• Las excepciones son condiciones de falla (algo salió mal).
• Las alternativas son simplemente una forma diferente de que las cosas salgan bien.

Caso de uso Niveles de detalles

La granularidad de los casos de uso se refiere a la forma en que se organiza la información dentro de las especificaciones de los casos de uso y, en cierta medida, al nivel de detalle con el que se escriben. Lograr el nivel correcto de granularidad de casos de uso facilita la comunicación entre las partes interesadas y los desarrolladores y mejora la planificación del proyecto.

Alastair Cockburn en  Escribir casos de uso efectivo  nos brinda una manera fácil de visualizar diferentes niveles de nivel de meta al pensar en términos del mar:

Tenga en cuenta que:

• Si bien un caso de uso en sí mismo puede profundizar en muchos detalles sobre cada posibilidad, un diagrama de caso de uso a menudo se usa para una vista de nivel superior del sistema como planos.
• Es beneficioso escribir casos de uso en un nivel más bajo de granularidad con menos detalles cuando no es necesario.

Espero que pueda responder «qué es el diagrama de casos de uso» ahora y pueda aplicar el caso de uso en su proyecto. Si desea obtener más información sobre otros tipos de diagramas UML, consulte la guía UML:  Descripción general de los 14 tipos de diagramas UML .

Referencias

• Cómo dibujar un diagrama de casos de uso
• Tutorial de diagrama de caso de uso
• Descripción del caso de uso