EspañolEl modelado de casos de uso es una herramienta útil para capturar requisitos. Proporciona una representación gráfica de los requisitos de un sistema de software.
Con la publicación del libro de Ivar Jacobson (1991) Ingeniería de software orientada a objetos, un enfoque basado en casos de uso, el modelado de casos de uso se convirtió efectivamente en una técnica de análisis práctica. Hoy en día, Jacobson continúa promoviendo este enfoque para el análisis de sistemas y lo ha actualizado a Use Case 2.0, que es oficialmente uno de los 14 tipos de diagramas UML .
Debido a que el modelo de caso de uso es simple en concepto y apariencia, es relativamente fácil discutir su corrección con personal no técnico (como los clientes).
Un caso de uso no es un procedimiento, proceso o función.
Los Elementos del Diagrama de Casos de Uso
Los elementos de un diagrama de casos de uso son los actores (entidades externas) y el caso de uso mismo. En términos generales, un caso de uso es una unidad funcional (requisito) o servicio en un sistema.
Actor
Un actor es cualquier entidad externa al sistema de diseño, ya sea una persona u otra entidad no humana. Un usuario de un sistema es un ejemplo típico de un actor. Otros tipos de actores incluyen sistemas de software que se están integrando con el sistema actual (por ejemplo, un sistema de base de datos), hardware externo como un sensor, etc.
Hay dos notaciones en la especificación UML :
Usar stickman para actores es más expresivo, pero puede generar confusión si el actor no es realmente una persona, sino una máquina o un dispositivo externo. El símbolo del rectángulo es la notación UML estándar para una clase .
Un actor es un papel en lugar de una persona real
Un actor representa el rol de la entidad que interactúa con el sistema actual, no una instancia. La notación de actor indica que la entidad es una clase en lugar de una instancia de lectura (es decir, un usuario real John o Mary). La razón por la que un actor es un tipo de clase es que no es el actor mismo, sino el papel que interpreta.
Por ejemplo, un actor puede representar a los clientes de un banco, en lugar de especificar un actor independiente para cada cliente. Asimismo, puede haber otro actor en representación del gerente del banco. Curiosamente, en el mundo real, el gerente de un banco también puede ser cliente del mismo banco. En otras palabras, la misma persona desempeña el papel de cliente y gerente.
Actores primarios vs secundarios
El actor principal de un caso de uso es la parte interesada que requiere que el sistema proporcione sus servicios. Tiene una meta asociada con el sistema, una meta que puede ser satisfecha por la operación del sistema. El actor principal suele ser, aunque no siempre, el actor que desencadena el caso de uso.
El actor secundario es utilizado por el sistema, pero no interactúa con el sistema por sí solo. En otras palabras, los actores secundarios no inician ningún caso de uso.
Los casos de uso generalmente son iniciados por los actores principales. El sistema utiliza un actor secundario como una base de datos a través de un conjunto de casos de uso. La asociación entre casos de uso y participantes representa una comunicación bidireccional.
Por lo tanto, para cada caso de uso iniciado por un actor principal, se debe responder al caso de uso conectado. De manera similar, para cada asociación entre un actor secundario y un caso de uso, la comunicación comienza con el caso de uso y el actor secundario debe responder al inicio.
Caso de uso
Los casos de uso representan las funciones (generalmente requisitos) que se espera que implemente el sistema. Los detalles del caso de uso, excepto su nombre único, no se expresan intuitivamente en el diagrama; Estos detalles se dan en la descripción del caso de uso.
Los casos de uso generalmente son iniciados por actores clave. El sistema utiliza la base de datos y otros participantes auxiliares a través de un conjunto de casos de uso.
La asociación entre casos de uso y actores representa una comunicación bidireccional. Por lo tanto, para cada caso de uso iniciado por el actor principal, se debe dar respuesta a este último. De manera similar, para cada asociación entre el actor secundario y el caso de uso, la comunicación comienza con el caso de uso y el actor secundario debe responder al inicio.
Límite del sistema
El límite del sistema define el sistema de interés en relación con el mundo que lo rodea.
Ejemplo de diagrama de caso de uso: sistema de reservas de aerolíneas
Los casos de uso definen las interacciones entre los actores externos y el sistema para lograr objetivos particulares. Un diagrama de caso de uso contiene cuatro componentes principales
En el diagrama de casos de uso de un sistema de reserva de boletos, el sistema está representado por cajas que contienen muchos casos de uso diferentes. El actor principal es el cliente y el actor secundario es el administrador. El cliente inicia los casos de uso, como reservar, navegar y cancelar vuelos, mientras que el administrador inicia los casos de uso, como actualizar los registros de vuelo, pero se considera un actor secundario en el caso de uso de cancelación de vuelo, ya que solo ayuda a completar los casos de uso iniciados por el cliente.
EDITE ESTE EJEMPLO DE DIAGRAMA DE CASOS DE USO DE UML
Estructuración de casos de uso
De acuerdo con el campo de aplicación y la elección del diseñador, un caso de uso se puede dividir en múltiples casos de uso, que están conectados a través de relaciones < <incluir>> o <<extender>>.
El vínculo de asociación representa una comunicación bidireccional entre un actor y un caso de uso y, por lo tanto, es una relación binaria. Dado que es una comunicación bidireccional, para cada caso de uso iniciado por un actor principal, ese actor debe obtener una respuesta del caso de uso.
De manera similar, para cada comunicación entre un caso de uso y un actor secundario (iniciada por el caso de uso), el actor secundario debe enviar una respuesta al caso de uso.
Generalización
La generalización representa la relación entre
- roles o
- casos de uso.
EDITE ESTA PLANTILLA DE DIAGRAMA DE CASOS DE USO DE UML
Si dos actores están conectados por esta relación, entonces el actor (o caso de uso) al final de la flecha (conectado a la parte inferior del triángulo) es una versión especializada del actor (o caso de uso) en el otro extremo.
Por lo general, el actor (o caso de uso) en el extremo inferior (conectado a la parte inferior del triángulo) se conoce como la versión especializada del actor (o caso de uso) en el otro extremo.
La generalización significa que la versión especializada tiene todas las características de la versión general y posiblemente más.
Incluir es un tipo especial de relación entre dos casos de uso. Si un caso de uso A incluye otro caso de uso B, entonces la implementación de A requiere la implementación de B para completar su tarea. Sin embargo, B es independiente de sí mismo. Es decir, B no necesita saber nada sobre A. B también se puede incluir en cualquier otro caso de uso.
EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO
Extend es otro tipo especial de relación entre dos casos de uso. Si un caso de uso B extiende otro caso de uso A, entonces la implementación de A puede incluir condicionalmente la implementación de B para completar su tarea. Es decir, en algunos casos, A puede completar su tarea sin B. Sin embargo, dependiendo de las condiciones descritas.
EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO
Notaciones del diagrama de casos de uso
EDITE ESTE EJEMPLO DE DIAGRAMA DE CASOS DE USO EN LÍNEA
9 pasos simples para realizar análisis de casos de uso
- Determine quién utilizará directamente el sistema. Estas personas son los actores.
- Elige a uno de estos actores.
- Defina lo que ese actor quiere hacer con el sistema. Cada cosa que el actor quiere hacer con el sistema se convierte en un caso de uso.
- Repita los pasos 2 y 3 para todos los demás casos de uso
. Identifique los roles secundarios y el soporte de roles no humanos para los casos de uso que ha identificado. - Dibuje la versión inicial del caso de uso, no complique demasiado las relaciones de casos de uso en este punto
- Discutir y revisar con los usuarios para validar los objetivos de cada caso de uso (beneficios de la funcionalidad propuesta) Después de las modificaciones, puede continuar detallando los casos de uso en los pasos 8 a 10
- Para cada caso de uso, decida el proceso más común que seguirá el actor al usar el sistema. Lo que sucedería normalmente.
- Describa este proceso básico en la descripción del caso de uso.
- Una vez que esté satisfecho con el proceso básico, considere escenarios alternativos y agréguelos como casos de uso extendido.
Modelo de caso de uso y especificación
No basta con mostrar el diagrama de casos de uso en notación UML. Cada caso de uso va acompañado de un texto que explica el propósito del caso de uso y la funcionalidad que se logra cuando se ejecuta el caso de uso.
Un caso de uso describe una tarea realizada por un actor que produce un resultado de valor comercial para la empresa. Un caso de uso se puede visualizar como un diagrama de caso de uso o en un formato de especificación de texto estructurado .
Escenarios de casos de uso
Un caso de uso consta de una serie de escenarios, cada uno de los cuales representa una instancia específica del caso de uso, correspondiente a entradas específicas del actor o condiciones específicas en el entorno. Cada escenario describe una forma alternativa de comportamiento del sistema, o puede describir fallas o excepciones.
Un caso de uso tiene:
- solo un gol
- Un único punto de partida
- Un único punto final
- Múltiples caminos para ir de principio a fin
- es decir, especificar el comportamiento para una variedad de condiciones posibles
- Cada condición puede requerir acción(es) específica(s)
Por ejemplo: el cliente paga la factura:
Hay múltiples caminos para lograr el objetivo :
- Pago telefónico
- Por correo
- En persona
- por cheque
- en efectivo, etc
Un camino que no conduce a la meta:
- Se rechaza la tarjeta de crédito
Agrupación de casos de uso con paquetes
También puede: Dibujar paquetes para la categorización lógica de casos de uso en subsistemas relacionados.
EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO
Especificación detallada del caso de uso
Un caso de uso detallado es una representación textual que describe un flujo de eventos y otra información relacionada con el caso de uso en un formato específico. Una plantilla de caso de uso estándar se usa a menudo para documentar los detalles de un caso de uso
¿Qué es una descripción de caso de uso?
Una descripción de caso de uso es una descripción escrita de la secuencia de pasos que realiza un analista para completar una transacción de sistema completa. Lo inicia un actor, proporciona valor a ese actor y es el objetivo de los actores que trabajan en el sistema.
Actor : cualquier persona o sistema externo al sistema que utiliza o interactúa con el sistema para lograr un objetivo. A cada actor se le asigna un rol para representar su interacción con la solución. Los actores de personas deben nombrarse en forma de roles y no se les deben asignar nombres reales. Los actores generalmente se clasifican como primarios, secundarios o partes interesadas.
Actor principal : el actor que inicia el caso de uso.
Actor secundario: el actor que reacciona o responde a las acciones realizadas por el actor principal.
Partes interesadas: actores fuera del escenario que no interactúan directamente con el caso de uso, pero tienen interés en el resultado del caso de uso.
Flujo de flujo de eventos (ruta) : la secuencia de pasos que los actores y las soluciones deben seguir para ejecutar un caso de uso. En general, un caso de uso consta de una ruta de éxito principal (también denominada básica o principal), una ruta alternativa y una ruta de excepción.
La ruta normal , la entrada del actor y la respuesta del sistema, representa la ruta de éxito más común para lograr los objetivos del actor.
Caminos alternativos : entradas del actor y respuestas del sistema, que representan los otros caminos menos comunes para lograr el objetivo del actor.
Rutas excepcionales : entradas del actor y respuesta del sistema, que representan rutas fallidas cuando no se puede lograr el objetivo del actor.
| Descripción del caso de uso | |
|---|---|
| Nombre del caso de uso: | Retirar dinero |
| Actor(es): | Cliente (primario), Sistema Bancario (secundario) |
| Descripción resumida: | Permite a cualquier cliente del banco retirar efectivo de su cuenta bancaria. |
| Prioridad: | Debe tener |
| Estado: | Nivel medio de detalles |
| Condición previa: | El cliente del banco tiene una tarjeta para insertar en el cajero automático El cajero automático está en línea correctamente |
| Condición(es) posterior(es): |
|
| Ruta básica: |
|
| Caminos alternativos: |
|
| Reglas del negocio: |
|
| Requerimientos no funcionales: |
|
enlaces relacionados
- ¿Qué es el lenguaje de modelado unificado?
- Diapositiva de caso de uso / Notas de clase
- El papel de los casos de uso en el modelado de requisitos y análisis
- Una lista de herramientas UML
- Prueba Visual Paradigm GRATIS
- Caso de uso: notas para el curso de capacitación
- ¿Cómo escribir casos de uso efectivos?
- Capítulo de libro – PDF – Modelo de caso de uso: requisitos de escritura en contexto
Español
English
简体中文
繁體中文
Deutsch
Français
العربية
Italiano
Português
日本語
Nederlands
Русский
Your posts in this blog really shine! Glad to gain some new insights, which I happen to also cover on my page. Feel free to visit my webpage QH8 about Car Purchase and any tip from you will be much apreciated.