En ingeniería de software y sistemas , la frase caso de uso es un polisema con dos sentidos :
En este artículo se analiza este último sentido. (Para obtener más información sobre el otro sentido, consulte, por ejemplo, el concepto de persona de usuario ).
Un caso de uso es una lista de acciones o pasos de eventos que generalmente definen las interacciones entre un rol (conocido en el Lenguaje de Modelado Unificado (UML) como actor ) y un sistema para lograr un objetivo. El actor puede ser un ser humano u otro sistema externo. En ingeniería de sistemas, los casos de uso se utilizan a un nivel más alto que en la ingeniería de software , y a menudo representan misiones o metas de las partes interesadas . Los requisitos detallados pueden luego capturarse en el Lenguaje de Modelado de Sistemas (SysML) o como declaraciones contractuales.
En 1987, Ivar Jacobson presentó el primer artículo sobre casos de uso en la conferencia OOPSLA '87. [1] Describió cómo se utilizaba esta técnica en Ericsson para capturar y especificar los requisitos de un sistema utilizando técnicas de modelado textual, estructural y visual para impulsar el análisis y el diseño orientados a objetos. [2] Originalmente había utilizado los términos escenarios de uso y caso de uso (este último una traducción directa de su término sueco användningsfall ), pero descubrió que ninguno de estos términos sonaba natural en inglés y finalmente se decidió por caso de uso . [3]
En 1992 fue coautor del libro Object-Oriented Software Engineering - A Use Case Driven Approach , [4] que sentó las bases del método de ingeniería de sistemas OOSE y ayudó a popularizar los casos de uso para capturar requisitos funcionales , especialmente en el desarrollo de software . En 1994 publicó un libro sobre casos de uso y técnicas orientadas a objetos aplicadas a modelos de negocios y reingeniería de procesos de negocios . [5]
Al mismo tiempo, Grady Booch y James Rumbaugh trabajaron en la unificación de sus métodos de análisis y diseño orientados a objetos , el método Booch y la Técnica de Modelado de Objetos (OMT) respectivamente. En 1995, Ivar Jacobson se unió a ellos y juntos crearon el Lenguaje de Modelado Unificado (UML) , que incluye el modelado de casos de uso. UML fue estandarizado por el Object Management Group (OMG) en 1997. [6] Jacobson, Booch y Rumbaugh también trabajaron en un refinamiento del proceso de desarrollo de software Objectory . El Proceso Unificado resultante se publicó en 1999 y promovió un enfoque impulsado por los casos de uso. [7]
Desde entonces, muchos autores han contribuido al desarrollo de la técnica, en particular: Larry Constantine desarrolló en 1995, en el contexto del diseño centrado en el uso , los llamados "casos de uso esenciales" que tienen como objetivo describir las intenciones del usuario en lugar de secuencias de acciones o escenarios que podrían restringir o sesgar el diseño de la interfaz de usuario; [8] Alistair Cockburn publicó en 2000 una práctica de casos de uso orientada a objetivos basada en narrativas de texto y especificaciones tabulares; [9] Kurt Bittner e Ian Spence desarrollaron en 2002 prácticas avanzadas para analizar requisitos funcionales con casos de uso; [10] Dean Leffingwell y Don Widrig propusieron aplicar casos de uso a la gestión del cambio y a las actividades de comunicación con las partes interesadas; [11] Gunnar Overgaard propuso en 2004 extender los principios de los patrones de diseño a los casos de uso. [12]
En 2011, Jacobson publicó con Ian Spence y Kurt Bittner el libro electrónico Use Case 2.0 para adaptar la técnica a un contexto ágil, enriqueciéndolo con "fragmentos" incrementales de casos de uso, y promoviendo su uso a lo largo de todo el ciclo de vida del desarrollo [13] después de haber presentado el enfoque renovado en la conferencia anual de IIBA. [14] [15]
Los casos de uso son una técnica para capturar, modelar y especificar los requisitos de un sistema. [10] Un caso de uso corresponde a un conjunto de comportamientos que el sistema puede realizar en interacción con sus actores y que produce un resultado observable que contribuye a sus objetivos. Los actores representan el rol que los usuarios humanos u otros sistemas tienen en la interacción.
En el análisis de requerimientos , al identificar un caso de uso, se le asigna un nombre según el objetivo de usuario específico que representa para su actor principal. El caso se detalla con una descripción textual o con modelos gráficos adicionales que explican la secuencia general de actividades y eventos, así como variantes como condiciones especiales, excepciones o situaciones de error.
Según el Software Engineering Body of Knowledge (SWEBOK) , [16] los casos de uso pertenecen a las técnicas de obtención de requisitos basadas en escenarios , así como a las técnicas de análisis basadas en modelos . Pero los casos de uso también respaldan la recopilación de requisitos basada en narrativas, la adquisición incremental de requisitos, la documentación del sistema y las pruebas de aceptación. [1]
Existen diferentes tipos de casos de uso y variaciones en la técnica:
El alcance de un caso de uso puede definirse por un tema y por objetivos:
Se sabe que los casos de uso se aplican en los siguientes contextos:
Existen muchas formas de escribir un caso de uso en el texto, desde un resumen del caso de uso , un resumen informal , un esquema , hasta un caso de uso completo , etc., y con plantillas variadas. Escribir casos de uso en plantillas diseñadas por varios proveedores o expertos es una práctica común en la industria para obtener requisitos de sistemas funcionales de alta calidad.
La plantilla definida por Alistair Cockburn en su libro Writing Effective Use Cases ha sido uno de los estilos de redacción de casos de uso más utilizados. [ cita requerida ]
Cockburn sugiere anotar cada caso de uso con un símbolo para mostrar el "Alcance del diseño", que puede ser una caja negra (los detalles internos están ocultos) o una caja blanca (los detalles internos se muestran). Hay cinco símbolos disponibles: [20]
Otros autores a veces denominan a los casos de uso a nivel de organización "casos de uso de negocio". [21]
Cockburn sugiere anotar cada caso de uso con un símbolo para mostrar el "Nivel objetivo"; [22] el nivel preferido es "Objetivo del usuario" (o coloquialmente "nivel del mar" [23] : 101 ).
A veces, al escribir un texto, un nombre de caso de uso seguido de un símbolo de texto alternativo (! +, -, etc.) es una forma más concisa y conveniente de indicar niveles, por ejemplo, ¡ realizar un pedido!, ¡ iniciar sesión !.
Cockburn describe una estructura más detallada para un caso de uso, pero permite simplificarla cuando se necesitan menos detalles. Su plantilla de caso de uso completamente desarrollada enumera los siguientes campos: [24]
Además, Cockburn sugiere utilizar dos dispositivos para indicar la naturaleza de cada caso de uso: íconos para el alcance del diseño y el nivel del objetivo.
El enfoque de Cockburn ha influido en otros autores; por ejemplo, Alexander y Beus-Dukic generalizan la plantilla de "caso de uso completamente vestido" de Cockburn del software a sistemas de todo tipo, y los siguientes campos difieren de Cockburn: [26]
Cockburn reconoce que los proyectos no siempre necesitan casos de uso detallados y "completamente elaborados". Describe un caso de uso informal con los campos: [24]
Martin Fowler afirma: "No existe una forma estándar de escribir el contenido de un caso de uso, y diferentes formatos funcionan bien en diferentes casos". [23] : 100 Describe "un estilo común para usar" de la siguiente manera: [23] : 101
El estilo Fowler también puede considerarse una variante simplificada de la plantilla Cockburn. Esta variante se denomina historia de usuario .
Alistair Cockburn afirmó: [27]
Piense en una historia de usuario como un caso de uso con 2 bits de precisión. El bit 1 de precisión nombra el objetivo del caso de uso y el bit 2 agrega el escenario principal. El bit 3 agrega las condiciones de falla, el bit 4 agrega las acciones de falla. El bit 5 agrega una descripción de los datos de entrada/salida. Yo pondría a Catalysis en el sexto bit de precisión, ya que también incluye un modelo del destinatario del mensaje. En la familia CrystalMethodology, los proyectos con diferentes fundamentos utilizan casos de uso con diferentes niveles de precisión. Un proyecto metodológicamente liviano utiliza historias de usuario, un proyecto metodológicamente más pesado utiliza casos de uso con 4 bits de precisión y Catalysis utiliza 6 bits de precisión.
Martin Fowler afirmó: [27]
Todo se trata de cómo las personas usan los casos. He visto a muchas personas usar casos de una manera muy formalizada. Kent hace sus UserStories de una manera mucho más accesible. Yo hago casos de uso de la misma manera que Kent hace User Stories. Los invoco para que usen casos de uso para comunicarme mejor con otros desarrolladores e influenciarlos para que usen un enfoque más liviano.
Un caso de uso define las interacciones entre actores externos y el sistema en cuestión para lograr un objetivo. Los actores deben ser capaces de tomar decisiones, pero no necesariamente deben ser humanos: "Un actor puede ser una persona, una empresa u organización, un programa informático o un sistema informático (hardware, software o ambos)". [28] Los actores son siempre partes interesadas , pero no todas las partes interesadas son actores, ya que es posible que "nunca interactúen directamente con el sistema, aunque tengan derecho a preocuparse por cómo se comporta el sistema". [28] Por ejemplo, "los propietarios del sistema, la junta directiva de la empresa y los organismos reguladores como el Servicio de Impuestos Internos y el Departamento de Seguros" podrían ser partes interesadas, pero es poco probable que sean actores. [28]
De manera similar, una persona que utiliza un sistema puede ser representada como un actor diferente debido a que desempeña diferentes roles. Por ejemplo, el usuario "Joe" podría desempeñar el papel de un Cliente cuando utiliza un Cajero Automático para retirar efectivo de su propia cuenta o desempeñar el papel de un Cajero de Banco cuando utiliza el sistema para reponer el cajón de efectivo en nombre del banco.
Los actores suelen trabajar en nombre de otra persona. Cockburn escribe que "hoy en día escribo 'representante de ventas para el cliente' o 'empleado del departamento de marketing' para reflejar que el usuario del sistema está actuando en nombre de otra persona". Esto indica al proyecto que la "interfaz de usuario y las autorizaciones de seguridad" deben estar diseñadas para el representante de ventas y el empleado, pero que el cliente y el departamento de marketing son los roles que se preocupan por los resultados. [29]
Un actor puede desempeñar un papel tanto activo como inactivo: por ejemplo, un consumidor es a la vez un "comprador del mercado masivo" (que no interactúa con el sistema) y un usuario (un actor que interactúa activamente con el producto adquirido). [30] A su vez, un usuario es a la vez un "operador normal" (un actor que utiliza el sistema para su propósito previsto) y un "beneficiario funcional" (un actor que se beneficia del uso del sistema). [30] Por ejemplo, cuando el usuario "Joe" retira efectivo de su cuenta, está operando el cajero automático y obteniendo un resultado en su propio nombre.
Cockburn aconseja buscar actores entre las partes interesadas de un sistema, los actores primarios y secundarios de un caso de uso, el propio sistema bajo diseño (SuD) y, finalmente, entre los "actores internos", es decir, los componentes del sistema bajo diseño. [28]
De la misma manera que un caso de uso describe una serie de eventos e interacciones entre un usuario (u otros tipos de Actor) y un sistema, con el fin de producir un resultado de valor (objetivo), un caso de uso empresarial describe la interacción más general entre un sistema empresarial y los usuarios/actores de ese sistema para producir resultados empresariales de valor. La principal diferencia es que el sistema considerado en un modelo de caso de uso empresarial puede contener personas además de sistemas tecnológicos. Estas "personas en el sistema" se denominan trabajadores empresariales. En el ejemplo de un restaurante, se debe tomar una decisión sobre si tratar a cada persona como un actor (es decir, fuera del sistema) o un trabajador empresarial (dentro del sistema). Si se considera a un camarero como un actor, como se muestra en el ejemplo siguiente, entonces el sistema del restaurante no incluye al camarero, y el modelo expone la interacción entre el camarero y el restaurante. Una alternativa sería considerar al camarero como parte del sistema del restaurante (un trabajador empresarial) mientras que se considera al cliente como fuera del sistema (un actor). [31]
Los casos de uso no son solo textos, sino también diagramas, si es necesario. En el lenguaje de modelado unificado , las relaciones entre los casos de uso y los actores se representan en diagramas de casos de uso basados originalmente en la notación Objectory de Ivar Jacobson . SysML utiliza la misma notación a nivel de bloque del sistema.
Además, también se pueden utilizar otros diagramas UML de comportamiento , como diagramas de actividad , diagramas de secuencia , diagramas de comunicación y diagramas de máquina de estados , para visualizar los casos de uso en consecuencia. En concreto, un diagrama de secuencia del sistema (SSD) es un diagrama de secuencia que se utiliza a menudo para mostrar las interacciones entre los actores externos y el sistema en diseño (SuD), normalmente para visualizar un escenario particular de un caso de uso.
El análisis de casos de uso suele comenzar con la elaboración de diagramas de casos de uso. Para el desarrollo ágil, un modelo de requisitos de muchos diagramas UML que representen casos de uso más algunas descripciones textuales, notas o resúmenes de casos de uso sería muy liviano y suficiente para un uso en proyectos pequeños o sencillos. Como buenos complementos para los textos de casos de uso, las representaciones de diagramas visuales de casos de uso también son herramientas eficaces para facilitar la comprensión, la comunicación y el diseño de requisitos de comportamiento de sistemas complejos.
A continuación, se muestra un ejemplo de caso de uso escrito con una versión ligeramente modificada de la plantilla de estilo Cockburn. Tenga en cuenta que no hay botones, controles, formularios ni ningún otro elemento de la interfaz de usuario ni operaciones en la descripción del caso de uso básico, donde solo se expresan los objetivos, subobjetivos o intenciones del usuario en cada paso del flujo básico o las extensiones. Esta práctica hace que la especificación de requisitos sea más clara y maximiza la flexibilidad del diseño y la implementación.
Caso de uso : Editar un artículo
Actor principal : Miembro (Usuario registrado)
Alcance : un sistema Wiki
Nivel : ! (Objetivo del usuario o nivel del mar)
Brief : (equivalente a una historia de usuario o una epopeya)
Partes interesadas
...
Condiciones posteriores
Condiciones previas :
Desencadenantes :
Flujo básico :
Extensiones :
2–3.
4a. Tiempo de espera:
...
Desde el inicio del movimiento ágil, la técnica de historias de usuario de la Programación Extrema ha sido tan popular que muchos piensan que es la única y mejor solución para los requisitos ágiles de todos los proyectos. Alistair Cockburn enumera cinco razones por las que todavía escribe casos de uso en el desarrollo ágil . [32]
En resumen, especificar los requisitos del sistema en los casos de uso tiene estos beneficios aparentes en comparación con los enfoques tradicionales u otros:
Centrado en el usuario
Los casos de uso constituyen una herramienta poderosa y centrada en el usuario para el proceso de especificación de requisitos de software. [33] El modelado de casos de uso generalmente comienza con la identificación de los roles de las partes interesadas clave ( actores ) que interactúan con el sistema y sus metas u objetivos que el sistema debe cumplir (una perspectiva externa). Estos objetivos del usuario luego se convierten en los candidatos ideales para los nombres o títulos de los casos de uso que representan las características funcionales deseadas o los servicios proporcionados por el sistema. Este enfoque centrado en el usuario garantiza que se desarrolle lo que tiene un valor comercial real y el usuario realmente desea, no esas funciones triviales especuladas desde una perspectiva de desarrollador o sistema (interna).
La creación de casos de uso ha sido una herramienta de análisis importante y valiosa en el ámbito del diseño centrado en el usuario (UCD) durante años.
Mejor comunicación
Los casos de uso suelen escribirse en lenguajes naturales con plantillas estructuradas. Esta forma de texto narrativo (historias de requisitos legibles), comprensible para casi todo el mundo y complementada con diagramas UML visuales, fomenta una comunicación mejor y más profunda entre todas las partes interesadas, incluidos los clientes, los usuarios finales, los desarrolladores, los evaluadores y los gerentes. Una mejor comunicación da como resultado requisitos de calidad y, por lo tanto, sistemas de calidad entregados.
Requisitos de calidad mediante exploración estructurada
Una de las cosas más poderosas de los casos de uso reside en los formatos de las plantillas de casos de uso, especialmente el escenario de éxito principal (flujo básico) y los fragmentos de escenarios de extensión (extensiones, flujos excepcionales y alternativos). Analizar un caso de uso paso a paso desde las precondiciones hasta las poscondiciones, explorar e investigar cada paso de acción de los flujos de casos de uso, desde el básico hasta las extensiones, para identificar esos requisitos complicados, normalmente ocultos e ignorados, aparentemente triviales pero que, en realidad, suelen ser costosos (como mencionó Cockburn anteriormente), es una forma estructurada y beneficiosa de obtener requisitos claros, estables y de calidad de manera sistemática.
Minimizar y optimizar los pasos de acción de un caso de uso para lograr el objetivo del usuario también contribuye a un mejor diseño de interacción y experiencia de usuario del sistema.
Facilitar las pruebas y la documentación del usuario.
Con un contenido basado en una estructura de flujo de acciones o eventos, un modelo de casos de uso bien escritos también sirve como una base excelente y como una guía valiosa para el diseño de casos de prueba y manuales de usuario del sistema o producto, lo que supone una inversión inicial que vale la pena. Existen conexiones obvias entre las rutas de flujo de un caso de uso y sus casos de prueba. Derivar casos de prueba funcionales a partir de un caso de uso a través de sus escenarios (ejecutar instancias de un caso de uso) es sencillo. [34]
Las limitaciones de los casos de uso incluyen:
Los malentendidos más comunes sobre los casos de uso son:
Las historias de usuario son ágiles; los casos de uso no lo son.
Agile y Scrum son técnicas neutrales en cuanto a requisitos. Como afirma el Scrum Primer [39] ,
Los elementos del Product Backlog se articulan de una manera clara y sostenible. Contrariamente a la idea errónea popular, el Product Backlog no contiene "historias de usuario"; simplemente contiene elementos. Esos elementos se pueden expresar como historias de usuario, casos de uso o cualquier otro enfoque de requisitos que el grupo considere útil. Pero sea cual sea el enfoque, la mayoría de los elementos deben centrarse en brindar valor a los clientes.
Las técnicas de casos de uso han evolucionado para tener en cuenta los enfoques ágiles mediante el uso de fragmentos de casos de uso para enriquecer de forma incremental un caso de uso. [13]
Los casos de uso son principalmente diagramas.
Craig Larman subraya que "los casos de uso no son diagramas, son texto". [40]
Los casos de uso tienen demasiado contenido relacionado con la interfaz de usuario.
Como dicen algunos: [¿ quién? ]
Los casos de uso a menudo contienen un nivel de detalle (es decir, nombres de etiquetas y botones) que los hace poco adecuados para capturar los requisitos de un nuevo sistema desde cero.
Malentendidos de principiantes. Cada paso de un caso de uso bien escrito debe presentar los objetivos o las intenciones del actor (la esencia de los requisitos funcionales) y, normalmente, no debe contener ningún detalle de la interfaz de usuario, por ejemplo, nombres de etiquetas y botones, operaciones de la interfaz de usuario, etc., lo que es una mala práctica y complicará innecesariamente la redacción del caso de uso y limitará su implementación.
En cuanto a la captura de requisitos para un nuevo sistema desde cero, los diagramas de casos de uso más los resúmenes de casos de uso se utilizan a menudo como herramientas útiles y valiosas, al menos tan livianas como las historias de usuario. [ cita requerida ]
Escribir casos de uso para sistemas grandes es tedioso y una pérdida de tiempo.
Como dicen algunos: [¿ quién? ]
El formato del caso de uso hace que sea difícil describir un sistema grande (por ejemplo, un sistema CRM) en menos de unos cientos de páginas. Es una tarea que requiere mucho tiempo y que hará que pierdas tiempo haciendo una cantidad innecesaria de trabajo de repaso.
[ cita requerida ]
Pasar mucho tiempo escribiendo casos de uso tediosos que no agregan valor o que tienen poco valor y que resultan en mucho trabajo de repetición es un mal olor que indica que los escritores no están bien capacitados y tienen poco conocimiento sobre cómo escribir casos de uso de calidad de manera eficiente y eficaz. Los casos de uso deben redactarse de manera iterativa, incremental y evolutiva ( ágil ). La aplicación de plantillas de casos de uso no significa que todos los campos de una plantilla de caso de uso deban usarse y completarse de manera exhaustiva desde el principio o durante una etapa especial dedicada, es decir, la fase de requisitos en el modelo de desarrollo en cascada tradicional .
De hecho, los formatos de casos de uso formulados por esos estilos de plantilla populares, por ejemplo, el RUP y el Cockburn (también adoptado por el método OUM ), etc., han demostrado en la práctica ser herramientas valiosas y útiles para capturar, analizar y documentar requisitos complejos de sistemas grandes. La calidad de una buena documentación de casos de uso ( modelo ) no debe juzgarse en gran medida o solo por su tamaño. También es posible que un modelo de casos de uso de calidad y completo de un sistema grande pueda finalmente evolucionar a cientos de páginas principalmente debido a la complejidad inherente del problema en cuestión, no debido a las malas habilidades de redacción de sus autores. [ cita requerida ]
A menudo se utilizan editores de texto y/o procesadores de texto con soporte de plantillas para escribir casos de uso. Para requisitos de sistemas grandes y complejos, las herramientas de casos de uso dedicadas son útiles.
Algunas de las herramientas de casos de uso más conocidas incluyen:
La mayoría de las herramientas UML admiten tanto la escritura de texto como el modelado visual de casos de uso.