Caso de uso , caso de uso, caso de uso ( eng. caso de uso ): en desarrollo de software y diseño de sistemas, esta es una descripción del comportamiento de un sistema cuando interactúa con alguien (o algo) del entorno externo. El sistema puede responder a solicitudes externas del Actor ( actor inglés , en ruso el acento está en la primera sílaba; se puede usar el término Actant [1] ), él mismo puede actuar como un iniciador de la interacción. En otras palabras, el guiónel uso describe "quién" y "qué" pueden hacer con el sistema en cuestión, o qué puede hacer el sistema con "quién" o "qué". La metodología de casos de uso se utiliza para identificar los requisitos de comportamiento del sistema , también conocidos como requisitos de usuario y funcionales.
En ingeniería de sistemas, los casos de uso se aplican a un nivel más alto que en el desarrollo de software, y a menudo representan objetivos o misiones de las partes interesadas. Durante la etapa de análisis de requisitos , los casos de uso pueden convertirse en un conjunto de requisitos detallados y documentarse utilizando diagramas de requisitos SysML u otros mecanismos similares.
En 1986, Ivar Jakobson , más tarde coinventor de Unified Modeling Language (UML) y Rational Unified Process (RUP), formuló por primera vez una técnica de modelado visual para describir casos de uso. Inicialmente, usó términos ligeramente diferentes: ing. escenarios de uso y caso de uso , pero ninguno de ellos era natural para el idioma inglés. Y finalmente se decidió por el término caso de uso - caso de uso. Desde que se desarrolló la metodología de modelado de casos de uso de Jakobson, muchos ingenieros de software han contribuido a la mejora de la metodología, incluidos Kurt Bittner, Alistair Coburn , Gunner Overgaard y Jerry Schneider.
Durante la década de 1990, los casos de uso se convirtieron en una de las técnicas más comunes para documentar requisitos funcionales, especialmente en el entorno orientado a objetos en el que se originaron. Pero su uso no se limita a los sistemas orientados a objetos porque los casos de uso no son de naturaleza orientada a objetos.
“Cada caso de uso se enfoca en describir cómo lograr una meta u objetivo. Para la mayoría de los proyectos de software, esto significa que se necesitarán muchos casos de uso para determinar el conjunto deseado de propiedades para el nuevo sistema. El grado de formalidad de un proyecto de software y su etapa influirán en el nivel de detalle requerido para cada caso de uso”.
Los casos de uso no deben confundirse con el concepto de propiedades del sistema ( característica en inglés ). Un caso de uso puede estar asociado con una o más propiedades del sistema, y una propiedad puede estar asociada con uno o más casos de uso.
El caso de uso define las interacciones entre los agentes externos y el sistema dirigidos a lograr el objetivo. Un actor es un papel que desempeña una persona o cosa al interactuar con un sistema. La misma persona que usa el sistema puede ser representada como diferentes actores porque juegan diferentes roles. Por ejemplo, "Jack" puede desempeñar el papel de un cliente que utiliza el cajero automático para retirar efectivo, o desempeñar el papel de un empleado del banco que utiliza el sistema para recargar el cajero automático con billetes.
Los casos de uso tratan al sistema como una "caja negra" y las interacciones con el sistema, incluidas las respuestas del sistema, se describen desde la perspectiva de un observador externo. Esta es una política deliberada porque obliga al autor a centrarse en lo que debe hacer el sistema en lugar de cómo debe hacerse, y evita hacer suposiciones sobre cómo se implementará la funcionalidad.
Los casos de uso se pueden describir en un nivel abstracto que describe un subdominio (caso de uso comercial, a veces denominado caso de uso clave) o a nivel de sistema (caso de uso del sistema). Las diferencias entre ellos radican en los detalles.
El caso de uso debe:
Alistair Coburn, en su libro Escribir casos de uso efectivos, identificó tres niveles de detalle en los casos de uso:
Para algunos procesos de desarrollo de software, un caso de uso simple es suficiente para determinar los requisitos del sistema. Otros necesitan muchos casos de uso detallados. En general, cuanto más grande y complejo sea el proyecto, más probable es que se necesiten utilizar muchos escenarios detallados.
El nivel de detalle en un caso de uso a menudo depende de la etapa del proyecto. Los escenarios iniciales pueden ser breves, pero a medida que avanza el proyecto, se vuelven más detallados. Esto refleja diferentes requisitos para los casos de uso. Inicialmente, solo deben ser breves, ya que se utilizan para obtener requisitos comerciales generales desde el punto de vista del usuario. Sin embargo, más adelante en el proceso de construcción de un sistema, los desarrolladores necesitan una guía mucho más específica y detallada.
Rational Unified Process (RUP) anima a los desarrolladores a usar una descripción breve de los casos de uso en un diagrama de casos de uso, con el nivel habitual de detalle como comentario y descripción detallada en el análisis de texto. Los scripts se pueden documentar con herramientas especiales (p. ej ., UML Tool , SysML Tool) o se pueden escribir en un editor de texto normal.
En el lenguaje de modelado unificado, las relaciones entre todos o parte de los casos de uso y los actores se representan en forma de diagrama de casos de uso, o en diagramas originalmente basados en la notación de objetos de Ivar Jakobson. SysML usa la misma representación a nivel del sistema.
En los diagramas de casos de uso de UML , un escenario se muestra como una elipse . Dentro o debajo de la elipse está el nombre del elemento.
Los siguientes tipos de relaciones se aplican a los casos de uso en UML:
Incluyendo entre precedentes:
Las opciones para usar scripts en el proceso de desarrollo dependen de la metodología de desarrollo utilizada. En algunas metodologías de desarrollo, todo lo que se requiere es una breve descripción general del escenario. Otros casos de uso se vuelven más complejos y cambian durante el desarrollo. En algunas metodologías, pueden comenzar como casos de negocios breves, convertirse en casos de uso de sistemas detallados y luego convertirse en pruebas extremadamente detalladas y exhaustivas.
No existe una plantilla estándar para documentar casos de uso detallados. Hay muchos esquemas en competencia, pero es mejor usar las plantillas que mejor se adapten al proyecto. Sin embargo, tiene sentido mencionar los puntos principales a los que vale la pena prestar atención.
Nombre del guión El nombre del guión debe escribirse en formato verbo-sustantivo (p. ej., Pedir libros prestados, Tomar dinero en efectivo). Debe describir un objetivo alcanzable (por ejemplo, Registrar un usuario es mejor que Registrar un usuario) y debe explicar el significado del caso de uso. Es una buena idea utilizar el nombre del guión, el objetivo del actor, asegurando así que se tengan en cuenta las necesidades del usuario. Dos o tres palabras es lo mejor. Si hay más palabras en el nombre, generalmente hay un nombre más corto y más informativo. Objetivo Sin un objetivo, el guión es inútil. No hay necesidad de un caso de uso cuando no hay necesidad de ningún actor para lograr el objetivo. El objetivo describe brevemente lo que el usuario pretende lograr con este escenario. Actores (actriz) Un actor es alguien o algo fuera del sistema que influye o es influenciado por el sistema. Un actor puede ser una persona, un dispositivo, otro sistema o subsistema, o el tiempo. Una persona en el mundo real puede estar representada por varios actores si tienen varios roles y objetivos diferentes en relación con el sistema. Interactúan con el sistema y realizan algunas acciones en él. Partes interesadas ( Partes interesadas ) Parte interesada: la persona o departamento que se ve afectado por el caso de uso. Por lo general, estos son empleados de la organización o departamento para el que se crea el escenario. Se puede pedir a una parte interesada que proporcione información, comentarios o permiso para un caso de uso. condiciones previas Vale la pena definir todas las condiciones que deben ser verdaderas (es decir, describir el estado del sistema) bajo las cuales tiene sentido la ejecución del script. Por lo tanto, si el sistema no está en el estado descrito en los requisitos previos, el comportamiento del script no está definido. Tenga en cuenta también que las condiciones previas no son "activadores" (ver más abajo). Porque las condiciones previas correctas NO activarán la ejecución del script. Activadores Un activador es un evento que desencadena la ejecución de un script. Este evento puede ser externo, temporal o interno. Si el activador no es un evento real (por ejemplo, el cliente presiona un botón), sino una serie de condiciones complejas, entonces vale la pena describir el proceso de activación. Este proceso debe verificar periódica o continuamente las condiciones de activación e iniciar el script.Hay varias formas de describir la situación en la que se produce una activación pero no se cumplen las condiciones previas.