Programación de casos de uso·casos de uso
Entonces, ¿qué es un caso de uso? En el documento UML, la definición de Caso de Uso es: la definición y descripción de una unidad funcional coherente de un sistema o subsistema sin mostrar la estructura interna de un sistema o subsistema. Un poco bocado, ¿verdad? De hecho, un caso de uso es solo una descripción de la función del sistema, pero un caso de uso describe una parte de toda la función del sistema. Esta parte debe ser un proceso funcional relativamente completo en lógica. En el proceso de desarrollo utilizando UML, los requisitos se expresan mediante casos de uso, la interfaz se diseña con la ayuda de casos de uso, se descubren muchas clases en función de casos de uso y se generan instancias de prueba en función de casos de uso, incluida toda la gestión de desarrollo y La asignación de tareas también se organiza según el caso de uso.
Los diferentes actores necesitan utilizar ciertas funciones del sistema de manera diferente. Por lo tanto, al identificar y analizar los Casos de Uso, debemos hacerlo uno por uno para cada Actor. Para el usuario de tareas pendientes, podemos identificar fácilmente dos casos de uso: agregar tarea y eliminar tarea. ToDo User utiliza activamente las funciones del sistema descritas por estos dos Casos de Uso, por lo que en nuestro diagrama de Casos de Uso, la relación entre ToDo User y estos dos Casos de Uso está representada por flechas emitidas por ToDo User. Para FileSystem, identificamos los mismos dos casos de uso, pero esta vez la flecha apunta desde el caso de uso al sistema de archivos, lo que indica que FileSystem es pasivo.
El caso de uso se puede describir de muchas maneras. Podemos usar lenguaje natural (inglés, chino, lo que quieras), podemos usar lenguaje formal (¡Guau! ¡Qué genial!) o podemos usar varias ilustraciones. . En UML, se suelen utilizar dos tipos de diagramas para describir los casos de uso, que son el diagrama de secuencia y el diagrama de colaboración.
El caso de uso consta de los siguientes elementos:
Nombre
Breve descripción
Flujo de eventos
Relación
Diagrama de actividad y diagrama de estado
Diagrama de casos de uso
Requisitos especiales
Condiciones previas
Condiciones posteriores 1.1 Participantes y casos de uso Desde el punto de vista del usuario, no quieren comprender la estructura interna y el diseño del sistema. Lo que les preocupa son los servicios que el sistema puede proporcionar, es decir, cómo se utilizará el sistema desarrollado. Esta es la idea básica del método de casos de uso. El modelo de caso de uso se compone principalmente de los siguientes elementos del modelo: Actor Los participantes se refieren a personas u otros sistemas que existen fuera del sistema definido e interactúan con el sistema. Representan a los usuarios o el entorno de uso del sistema. El caso de uso (Caso de uso) se utiliza para representar los servicios proporcionados por el sistema. Define cómo los participantes utilizan el sistema. Describe las interacciones entre los participantes y el sistema para utilizar una función completa proporcionada por el sistema. . Asociación de comunicación (Asociación de comunicación) La asociación de comunicación se utiliza para representar la correspondencia entre los participantes y los casos de uso. Indica qué servicios (casos de uso) del sistema utilizan los participantes o qué servicios (casos de uso) proporcionados por el sistema participan. utilizado por. Tomando como ejemplo un cajero automático (ATM) de un banco, sus funciones principales se pueden representar mediante el siguiente diagrama de casos de uso. Los principales usuarios de los cajeros automáticos son los clientes bancarios, quienes utilizan principalmente los cajeros automáticos para realizar consultas de cuentas bancarias, retiros y transacciones de transferencias. La asociación de comunicación representa la relación entre los participantes y los casos de uso. La flecha indica qué parte es la iniciadora activa del diálogo en esta relación, y la parte señalada por la flecha es el destinatario pasivo del diálogo si no desea enfatizar la relación. activas y pasivas, puede utilizar líneas asociadas sólidas sin flechas. El flujo de información entre actores y casos de uso no está representado por asociaciones de comunicación. Este flujo de información existe de forma predeterminada (el caso de uso en sí describe el diálogo entre los actores y el sistema) y el flujo de información es bidireccional. es irrelevante.
1.2 Contenido de los casos de uso Los diagramas de casos de uso nos brindan una comprensión general de las funciones del sistema. Podemos saber qué participantes interactuarán con el sistema y qué necesita cada participante de dicho servicio. Los casos de uso describen el diálogo entre los participantes y el sistema, pero los detalles de este diálogo no se expresan en el diagrama de casos de uso. Para cada caso de uso, podemos usar el flujo de eventos para describir los detalles de este diálogo. Por ejemplo, el caso de uso de retiro en el sistema de cajero automático se puede expresar de la siguiente manera en el flujo de eventos:
1. El usuario inserta la tarjeta bancaria 2. Ingresa la contraseña 3. Ingresa el monto del retiro 4. Retira. efectivo 5. Sale del sistema y lo recupera. Tarjeta bancaria, pero esto solo describe la situación más sencilla en el caso de uso de retiro. Como sistema práctico, también debemos considerar otras situaciones que pueden ocurrir, como una tarjeta bancaria no válida o una contraseña incorrecta. entrada, efectivo en la cuenta del usuario Saldo insuficiente, etc., todas estas diversas situaciones que pueden ocurrir (incluidas las normales y anormales) se denominan escenarios de casos de uso (Escenario), y los escenarios también se denominan instancias de casos de uso (Instancia). Entre los diversos escenarios de casos de uso, el escenario más común se describe en Basic Flow y otros escenarios se describen en Alternative Flow. Para el caso de uso de retiro en el sistema de cajero automático, podemos obtener algunos flujos alternativos de la siguiente manera:
Flujo alternativo uno: el usuario puede elegir salir en cualquier paso del flujo básico e ir al paso 5 del flujo básico.
Flujo alternativo dos: en el paso 1 del flujo básico, el usuario inserta una tarjeta bancaria no válida, el sistema muestra un error y sale de la tarjeta bancaria, y el caso de uso finaliza.
Flujo alternativo tres: en el paso 2 del flujo básico, el usuario ingresa una contraseña incorrecta, el sistema muestra un error y solicita al usuario que vuelva a ingresar la contraseña, y regresa al paso 2 del flujo básico. flujo; después de ingresar la contraseña incorrecta tres veces, la tarjeta de crédito se bloquea. El sistema se confisca y el caso de uso finaliza. … Mediante la combinación de flujo básico y flujo alternativo, se pueden describir claramente todos los escenarios posibles del caso de uso. Cuando describimos el flujo de eventos de un caso de uso, debemos describir todos los escenarios posibles tanto como sea posible para garantizar la integridad de los requisitos.
1.3 Ventajas del método de casos de uso El método de casos de uso describe las funciones del sistema completamente desde la perspectiva del usuario (desde fuera del sistema). En el método de casos de uso, consideramos el sistema definido como una caja negra y no nos importa cómo realiza el sistema las funciones que proporciona. El método de casos de uso describe primero a los usuarios externos (abstraídos como Actores) del sistema definido que interactúan con el sistema definido para cada participante; el método de casos de uso también describe qué tipo de servicios proporciona el sistema para estos participantes. Caso de uso), o cómo estos participantes utilizan el sistema. Entonces, a partir del diagrama de casos de uso, podemos obtener una impresión general del sistema que se está definiendo. En comparación con el método tradicional de descomposición funcional, el método de casos de uso define completamente las funciones del sistema desde el exterior y separa completamente los requisitos del diseño. En el método de diseño y análisis orientado a objetos, el modelo de casos de uso se utiliza principalmente para expresar los requisitos funcionales del sistema, y el diseño del sistema se registra y expresa principalmente mediante el modelo de objetos. Además, los casos de uso definen el entorno de uso y el contexto de las funciones del sistema. Cada caso de uso describe un servicio completo del sistema. El método de casos de uso es más fácil de entender para los usuarios que el SRS tradicional y puede utilizarse como un medio eficaz para comunicar los requisitos del sistema entre desarrolladores y usuarios. En RUP, los casos de uso se utilizan como base de todo el proceso de desarrollo de software. Muchos tipos de actividades de desarrollo utilizan los casos de uso como artefacto de entrada principal (Artefacto), como la gestión de proyectos, el análisis y el diseño, las pruebas, etc. Para probar el sistema de destino según el caso de uso, se puede probar completamente un servicio del sistema de acuerdo con el entorno y el contexto descritos en el caso de uso. Se pueden diseñar casos de prueba de acuerdo con cada escenario (Escenario) del caso de uso. el caso de uso se puede probar completamente. Garantizar la integridad de las pruebas. Ivar Jacobson comenzó a escribir escenarios de uso en 1967 cuando definió la arquitectura del sistema Ericsson AX.
A mediados de la década de 1980, Jacobson dedicó mucha energía a pensar en los métodos de trabajo de los últimos diez años.
Acuñó el término anvendningsfall, que aproximadamente significa "situación de uso" o caso de uso. Pero cuando se publicó en inglés, descubrió que "useage case" no tenía sentido en inglés, por lo que escribió use case "use case Un caso de uso es un artículo breve.
Un caso de uso puede". Ser una escena, incluyendo acciones e interacciones.
Un caso de uso puede ser un conjunto de escenarios que describen el comportamiento en diferentes escenarios. Este formato de escritura puede describir comportamientos variantes en cualquier momento, como requisitos de caja negra, procesos comerciales y especificaciones de diseño del sistema.
Sin diseño de sistema en el caso de uso
Sin diseño de interfaz en el caso de uso
Sin lista de funciones en el caso de uso
No lista de características en la prueba de caso de uso
El caso de uso debe describir los requisitos de comportamiento
El escenario principal del caso de uso no debe exceder los nueve pasos. Los subobjetivos y las instrucciones de diseño de eliminación se pueden obtener en el nivel apropiado.
El mayor valor de un caso de uso no reside en el escenario principal, sino en los comportamientos alternativos. La escena principal puede ocupar sólo entre un cuarto y una décima parte de la duración del ejemplo. El caso de uso tiene un flujo de eventos básico (se puede llamar ruta ideal) y múltiples flujos de excepciones, que incluyen:
Cambios básicos
Casos especiales
Manejo de condiciones de error La especificación del caso de uso del flujo de eventos de excepción debe incluir lo siguiente:
Descripción de la función
Disponibilidad
Fiabilidad
Rendimiento
Soportabilidad
Las restricciones de diseño al intentar determinar el tamaño de un caso de uso son un tema interesante. Una forma de abordar esto es relacionar el tamaño del caso de uso con su intención y alcance. A gran escala, un caso de uso no trata tanto en un sistema, pero todos estos sistemas se utilizan en la misma área comercial, llamada caso de uso comercial, que trata a toda la empresa como una caja negra y a los actores sobre una declaración de objetivos de la empresa. Estos escenarios de casos de uso empresarial no permiten suposiciones sobre ninguna estructura interna de la empresa; un cliente realizaría un pedido a la empresa en lugar del departamento de servicio al cliente.
Para el desarrollo de sistemas, el alcance del caso de uso se limita a un solo sistema. Esta es la forma más común de casos de uso. Lo llamamos caso de uso del sistema, que trata a todo el sistema como una caja negra. , que no especifica ninguna estructura interna y se limita únicamente a una descripción lingüística del dominio del problema.
Otro alcance de los Casos de Uso es el diseño de subsistemas y componentes internos del sistema, llamados Casos de Uso de Implementación. Trata al componente como una caja negra, y estos Actores son los miembros que lo distinguen. Por ejemplo: Los casos de uso de implementación se pueden utilizar para describir los requisitos del componente de correo electrónico en el sistema de la aplicación.
Dadas estas categorías, el tema del tamaño de los casos de uso se vuelve más fácil, diseñando el alcance de estos elementos para ajustar el tamaño general. Para ayudar a los diseñadores de sistemas, cada caso de uso describe solo un hilo de comportamiento sin grandes ramas. En contra de esta regla, los casos de uso a menudo parecen inexactos o vagos, y son difíciles de utilizar como recurso y referencia para instrucciones de prueba. La ventaja de utilizar Casos es que algunas tramas se pueden describir en diferentes grados de texto formalizado. Cada gráfico implica una única ruta en los casos de uso, cuyos detalles son grupos de condiciones.
También se pueden utilizar descripciones de texto irregulares, pero son difíciles de seguir cuando hay muchas condiciones y posibles fallos. Un estilo narrativo informal también es muy útil cuando se intenta comprender inicialmente los requisitos. Sin embargo, a medida que avanzan los casos de uso, es útil utilizar un mecanismo más formal para describir los casos de uso.
El siguiente es un resumen aproximado del "pedido" del cliente para el caso de uso:
"Identifique al cliente, averigüe qué artículos se necesitan y aún están en el almacén, y verifique si el crédito del cliente es suficiente. El uso del "
formato narrativo estructurado ha demostrado ser muy eficaz. Lo que hace este formato es describir a los actores de cada trama: las oraciones objetivo describen la secuencia.
En esta secuencia, cada par actor:enunciado objetivo supone que el objetivo anterior fue exitoso. Aquí hay un ejemplo simple:
Los casos de uso suponen que el sistema que estamos diseñando es único. En una caja negra, no es interno. La estructura no se registra en absoluto, y se considera que es el propósito de una trama y corresponde a un solo actor. Estos casos de uso no indican nada sobre los aspectos internos del sistema, solo indican qué objetivos alcanzará el sistema y qué (personas u otros sistemas) operarán y serán responsables de ello. Los casos de uso se han utilizado cada vez más en comparación con otras técnicas de captura de requisitos, las razones de su éxito son:
1 Los casos de uso tratan el sistema como una caja negra
2 Uso. El caso facilita ver las decisiones de implementación en los requisitos.
El último punto es un complemento del primer punto. Un caso de uso no especifica ninguna estructura interna del sistema relacionada con estos requisitos, por lo que. Si este caso de uso establece enviar cambios a la base de datos de pedidos, mostrar resultados en una página web, etc., entonces la estructura interna es obvia y crea restricciones potenciales en el diseño.
La razón por la que estos requisitos no especifican la estructura interna es que la estructura interna especificada impone restricciones adicionales al diseñador. Sin estas restricciones, el diseñador es más libre para construir un sistema que implemente correctamente un comportamiento objetivamente observable. sistema, y existe la posibilidad de una solución revolucionaria. Aquí está la descripción de la notación gráfica de los casos de uso. Un solo símbolo Stick-Man en UML marca el rol (Actor), y el caso de uso está marcado con una elipse. Figuras como estas son para aquellos que desean ver el panorama general. cómo se relacionan los casos de uso y cómo obtiene el sistema una descripción general del contexto.
Los diagramas de Casos de Uso no muestran diferentes escenarios, su intención es mostrar la relación entre personajes y Casos de Uso. Por lo tanto, los diagramas de casos de uso deben complementarse con texto narrativo estructurado. UML proporciona algunos diagramas opcionales para mostrar diferentes escenarios. Estos diagramas convencionales incluyen diagramas de interacción, diagramas de actividad, diagramas de secuencia, diagramas de estado, etc. (este artículo no discutirá estos diagramas por el momento). La principal desventaja de utilizar estos diagramas es que no son tan densos como el texto, pero pueden usarse para dar una sensación general del caso de uso. ¿Cada caso de uso incluye al menos un actor?
¿Cada Caso de Uso es independiente de otros Casos de Uso?
¿Tiene cada caso de uso un comportamiento o flujo de eventos simple?
Si cada Caso de Uso tiene un nombre único, intuitivo y extensible para que no se confunda más adelante.
Si es fácil para los usuarios entender el nombre y la descripción del Caso de Uso. El modelo de Casos de Uso muestra los Casos de Uso y los Actores en el sistema y sus interrelaciones. Los criterios de evaluación son:
¿Es comprensible el modelo de Casos de Uso?
Si podemos tener un concepto claro del funcionamiento del sistema mediante el estudio del modelo de Casos de Uso.
¿Están todos los actores definidos? ¿Se cumplen todos los requisitos funcionales?
Caso de uso si el modelo tiene comportamiento redundante.
Si la división del modelo al paquete de Casos de Uso es apropiada. Debido a sus símbolos gráficos simples e instrucciones en lenguaje natural fáciles de entender, Use Case se ha convertido en una tecnología cada vez más popular en el campo de los sistemas de documentación y requisitos de software. Los casos de uso son extremadamente atractivos para los equipos de desarrollo, incluso si los miembros del equipo no tienen experiencia con documentos de requisitos formales, pero su simplicidad puede ser engañosa incluso si el equipo del proyecto no tiene problemas para comenzar a usar casos de uso, cuando los aplican a los más grandes. Muchos de los mismos problemas surgen a menudo cuando se trabaja en proyectos.
1 Diez principales malentendidos en el uso de casos de uso
1. El límite del sistema no está definido o cambia con frecuencia;
2. Definir el caso de uso desde una perspectiva del sistema en lugar de la perspectiva del actor;
3. Los nombres de los actores son inconsistentes;
4. El caso de uso tiene demasiadas definiciones;
5. La relación entre Caso de Uso y actor es tan intrincada como una telaraña;
6. La descripción del caso de uso es demasiado larga;
7. La descripción del caso de uso no está clara;
8. El caso de uso no describe correctamente los requisitos funcionales;
9. Los usuarios no pueden entender el caso de uso;
10. El caso de uso no se puede finalizar normalmente.
2 Cómo evitar los problemas anteriores
Determine claramente el límite del sistema.
En pocas palabras, el límite del sistema es como una etiqueta cuadro, actor Fuera del cuadro, mientras que Caso de uso está dentro del cuadro. ¿Qué es exactamente esta caja que llamamos sistema? ¿Un sistema informático? ¿Un sistema de aplicación? ¿O un negocio completo? …El caso de uso se puede utilizar para describir razonablemente cualquier sistema. Pero sólo se puede utilizar para describir un sistema a la vez. Si los actores y los casos de uso se definen correctamente en un sistema, se producirán errores si se utilizan en un sistema diferente.
Utilice plantillas estándar para escribir especificaciones de casos de uso
Los símbolos gráficos de casos de uso se han estandarizado y se han convertido en parte del UML del grupo de gestión de objetos, pero las especificaciones de casos de uso en lenguaje natural aún no se han estandarizado. . Para escribir con éxito instrucciones de casos de uso, necesitamos una plantilla estándar para garantizar la coherencia de los casos de uso.
Céntrese en el verdadero propósito del actor y nombre el caso de uso desde el punto de vista del actor en lugar del punto de vista del sistema.
La diferencia más significativa entre los requisitos orientados a casos de uso y requisitos funcionales tradicionales del sistema. Desde la perspectiva del actor, el sistema existe porque los actores quieren lograr ciertos objetivos a través del sistema. Los actores interactúan con el sistema para lograr sus objetivos. Definimos estas interacciones como casos de uso.
No confunda las especificaciones del caso de uso con el diseño de la interfaz de usuario
Existe una visión muy popular ahora: dado que el caso de uso es la interacción entre los actores y el sistema, todos los usuarios es un Es una buena idea poner el diagrama de diseño de la interfaz en el manual de casos de uso. A primera vista, esto es realmente útil porque representa la interacción entre actores/sistemas descritos en la especificación en forma de diagrama, lo cual es muy intuitivo. Pero los efectos negativos de esto superan con creces sus beneficios. El diseño de la interfaz de usuario puede cambiar con el tiempo. No debemos permitir que los requisitos del sistema dependan del diseño de la interfaz de usuario. Al contrario, el diseño de la interfaz de usuario debe cumplir con los requisitos del caso de uso. Si colocamos el diseño de la interfaz de usuario en una especificación de caso de uso, cuando es necesario reconocer y establecer una base de los requisitos, es natural que estos elementos de diseño aún puedan estar cambiando, lo que hace que el diseño de la interfaz de usuario sea incompleto, incorrecto y/o inconsistente.
Colocar el diseño de la interfaz de usuario en la especificación de casos de uso también presenta otro problema. Para establecer una comunicación uno a uno entre los casos de uso y las interfaces, elegiremos bloques de casos de uso que reflejen la interfaz de usuario. En lugar de utilizar bloques de casos de uso que reflejan los objetivos del usuario, para expresar un objetivo de usuario completo, utilizamos relaciones interactivas de casos de uso para conectar diferentes casos de uso basados en la interfaz de usuario. Como resultado, en el modelo de casos de uso, obtenemos un diagrama. de relaciones que se asemeja a una telaraña. De hecho, esta imagen es un diagrama de descripción de la interfaz de usuario. Aunque es una parte importante del documento del sistema, pertenece al documento de diseño de la interfaz de usuario, no al documento de requisitos de casos de uso.
Lograr un acoplamiento flexible entre la interfaz de usuario y la interacción del caso de uso
El acoplamiento flexible es más apropiado. Los diagramas de interfaz de usuario de baja fidelidad ayudan a comprender el caso de uso, pero tenga cuidado de no exagerar. vincular las interacciones básicas con la mecánica de la interfaz de usuario es probable que cambie. En la especificación funcional, preste atención a lo que hace el actor (como enviar una solicitud) en lugar de cómo se completa la interacción (como hacer doble clic en el botón enviar).
No establezca comunicación entre el caso de uso y la interfaz de usuario
Intentar establecer comunicación entre el caso de uso y la interfaz de usuario puede resultar en una operación funcional potencialmente incorrecta. Los casos de uso están asociados no solo con actores que solo tienen acceso a una interfaz, sino también con actores que pueden actualizar esa interfaz (que pueden ser flujos de excepción), lo que resulta en una funcionalidad incorrecta. Deberíamos dividir los casos de uso en función de los objetivos reales del usuario y las operaciones funcionales, en lugar de combinar los casos de uso en función de las interfaces de usuario. Solo así podemos obtener el modelo de caso de uso correcto.
Al revisar el modelo de caso de uso y la especificación del caso de uso, si no puede evitar todos los malentendidos, debe reconocer el problema y determinarlo lo antes posible.
Este punto de vista no es nuevo, con respecto a la inspección de código El algoritmo clásico existe desde hace unos 25 años, pero ¿cómo aplicarlo a los casos de uso? Primero, revise el modelo de caso de uso y revise la descripción simple del caso de uso (nombre del caso de uso, objetivo, breve descripción). Este trabajo debe realizarse lo antes posible mientras se dibuja y antes de escribir la especificación detallada del caso de uso. Lo siguiente es revisar el boceto del caso de uso para asegurarse de que el dibujo sea correcto y que las instrucciones detalladas del caso de uso estén completas. Finalmente, hay una revisión formal del diagrama de caso de uso final y de las instrucciones del caso de uso.
Descubrimos que esta revisión de tres etapas es más efectiva que una sola revisión de Big Bang. Se pueden descubrir muchos problemas sustanciales en el diagrama de casos de uso antes de que dediquemos mucho tiempo a escribir instrucciones. la duplicación del trabajo que debe realizarse cuando cambian los requisitos. No existe conexión entre el actor principal (Actor) y el Caso de Uso
En algunos casos, no existe conexión entre el actor (Actor) que toma el valor del Caso de Uso y el actor (Actor) quién participa activamente en este caso de uso. No existe un vínculo claro. Por ejemplo: el director financiero puede convertirse en el actor de la "confirmación de la factura", pero puede no ser él quien crea la factura. Esto no es un problema, el Caso de Uso sigue siendo correcto, ilustra la relación entre el valor del actor y la inicialización que ocurre fuera del alcance del Caso de Uso del sistema diseñado. El actor principal es útil porque desempeña el papel de la persona con la que necesita hablar al explicar el caso de uso.
Los pasos de la trama no necesitan ser consecutivos
El orden de los pasos en una trama está bien, existen mecanismos para resaltar posibles pasos paralelos. Los diagramas de actividad son el mecanismo preferido en UML. Al observar informalmente la trama de un Caso de Uso, puede observar posibles pasos paralelos; puede observar algunos pasos adyacentes dentro del Caso de Uso; también puede tener el mismo actor (Actor) para el. pasos responsables. En el ejemplo que dimos antes, la cantidad confirmada y el monto del crédito confirmado pueden ser paralelos. A veces resulta útil marcar estos posibles pasos paralelos en la documentación del caso de uso.
Dimensionamiento de los Casos de Uso
Existe un peligro evidente al empezar a crear Casos de Uso de que tendrá muchos pasos o muy pocos. Si hay más de 15 pasos en el caso de uso, puede contener algunos detalles de implementación. Si tiene muy pocos pasos, compruebe si su objetivo es llegar a un único hilo de actividad sin muchas ramas.
Menos actores humanos (Actors)
Si el Caso de Uso tiene menos actores humanos y la mayoría de los actores son otros sistemas, el enfoque habitual es modificar el Caso de Uso. Buscar eventos ante los cuales el sistema deba reaccionar o reconocer es mejor que encontrarse con estos actores.
Captura de requisitos y complejidad del sistema
En resumen, estos gráficos capturan los actores simultáneos de la complejidad del sistema: el par de declaraciones objetivo permite especificar sistemas grandes en un formato relativamente comprimido. La función del formato de caso de uso es que los usuarios y desarrolladores puedan identificar actores y luego confirmar los objetivos a los que corresponden (o no corresponden) las responsabilidades laborales de estos actores, en lugar de una especificación funcional grande y difícil de leer.
Solo así, los usuarios y desarrolladores estarán lo suficientemente interesados como para estudiar los detalles de esas tramas.
El sistema no solo tiene los requisitos funcionales que merece
Algunos casos de uso no capturan todos los requisitos objetivos, sino solo aquellos requisitos funcionales de cómo se utiliza el sistema. Sin embargo, todavía quedan muchos aspectos de los requisitos que deben capturarse. Algunos de los requisitos no funcionales están tan relacionados que también pueden pertenecer a casos de uso individuales, como los requisitos de rendimiento y los requisitos de capacidad del sistema. Otros, que no están relacionados pero deben capturarse por separado, son los siguientes requisitos:
Alcance del sistema
Objetivos del usuario del sistema
Prototipo de interfaz de usuario
· Reglas generales
· Restricciones
· Algoritmo
Comparación de requisitos durante el tiempo de ejecución y el período de establecimiento
Un factor importante Lo que hay que recordar es que los patrocinadores del sistema son más numerosos que la comunidad de usuarios. Hay muchos titulares de riesgos en el sistema y los casos de uso solo capturan las necesidades de algunos de ellos. Específicamente, los casos de uso solo capturan las necesidades del sistema durante el tiempo de ejecución e ignoran las necesidades de los titulares de riesgos como organización de desarrollo del sistema. organización Lo más interesante es la descripción de los requisitos durante el período de establecimiento.
Los requisitos de tiempo de ejecución incluyen: alcance del sistema, expectativas y objetivos de la organización de usuarios para el producto, casos de uso y otros requisitos no funcionales.
Los requisitos del período de establecimiento incluyen: costos de desarrollo reducidos, menos procesamiento de cambios y reutilización de componentes existentes.
Los requisitos durante el período de establecimiento pueden ser comprendidos parcialmente por Casos de Uso. Pero la organización de desarrollo debe abordar muchos aspectos.
· Alcance y objetivos del proyecto: Qué debe ofrecer el proyecto. (La diferencia con todo el sistema es que confirma elementos de todos los proyectos)
· Solicitudes de crecimiento y cambio: se pueden capturar como "Casos de cambio" en el formato de casos de uso normal
· Restricciones del líder de desarrollo: incluidos estándares, hábitos, herramientas, métricas de calidad, principios de garantía de calidad y hábitos de garantía de calidad. Los casos de uso se utilizan primero para sistemas que necesitan responder a eventos objetivos. Se pueden utilizar en un entorno que proporcione a un actor claro objetivos fácilmente comprensibles. Los casos de uso no se pueden utilizar cuando el resultado no es definible o no está claro. Esto significa que si el éxito o el fracaso del objetivo no se pueden definir claramente, entonces los casos de uso no se pueden utilizar para capturar los requisitos.
Sin embargo, cuando se trata de esto, la mayoría de los métodos de objetos ahora usan casos de uso. Porque los Casos de Uso han demostrado ser un mecanismo muy eficaz para capturar requisitos. El caso de uso es un bloque de funciones proporcionado por el sistema. En otras palabras, el caso de uso demuestra cómo las personas usan el sistema. La observación del sistema a través de casos de uso puede separar la implementación del sistema de los objetivos del sistema, lo que ayuda a comprender las partes más importantes que cumplen con los requisitos y expectativas del usuario sin sumergirse en los detalles de la implementación. A través de los casos de uso, los usuarios pueden ver las funciones proporcionadas por el sistema, primero determinar el alcance del sistema y luego llevar a cabo un trabajo de proyecto en profundidad.