¿Cómo utilizamos correctamente los casos de uso?

Los casos de uso, como parte importante de UML, a menudo aparecen en varios documentos de diseño y desarrollo de productos junto con diagramas de clases, diagramas de secuencia, diagramas de estado, diagramas de actividad, etc., pero los diagramas de casos de uso son reales. uso en la expresión de ilustración UML, parece incómodo. No sé si tiene esta sensación. Nuestros documentos de diseño a menudo solo tienen requisitos formales para casos de uso. O dibujan algunos finales de manera superficial o no los dibujan en absoluto. Entonces, ¿el caso de uso es realmente inútil?

En comparación con los casos de uso, los gerentes de producto prefieren utilizar prototipos de interfaz para expresar la interacción entre los usuarios y los productos. No es de extrañar, pensemos en el concepto de caso de uso más antiguo: Ivar Jacobson definió el sistema Ericsson AX en 1967. Se propuso por primera vez cuando se estaba construyendo. Después de todo, la interacción entre humanos y computadoras en ese momento todavía era muy incómoda y difícil de entender. Medio siglo después, el concepto de diseño actual aboga por un modelo WYSIWYG simple e intuitivo.

¿Les gustará a los arquitectos e ingenieros de desarrollo utilizar casos de uso? La respuesta es: No, prefieren usar métodos de diseño más detallados, sistemáticos y parametrizados, como diagramas de secuencia, diagramas de actividad y diagramas de estado para expresar el estado del sistema, los cambios de datos y los comportamientos, mientras usan diagramas de clases para expresar la estructura estática. de información.

¿Lo utilizarán los ingenieros de pruebas? No, escriben casos de prueba basados ​​​​directamente en el diseño funcional y el prototipo de interfaz. Los casos de prueba son diferentes de los casos de uso y enfatizan definiciones estrictas de entrada y salida.

Entonces, ¿quién utilizará el caso de uso? Jaja, después del análisis anterior, debes sentir que el caso de uso es inútil y puede descartarse por completo. No estés ocupado, aún no he terminado de hablar. Esto no es culpa de los personajes anteriores, ni tampoco es que el caso de uso sea completamente inútil. De hecho, a menudo usamos el caso de uso. El caso de uso es un proceso de análisis empresarial más que un proceso de diseño. Para ser precisos, el caso de uso es un proceso de vinculación entre el análisis empresarial y el diseño del sistema.

En ingeniería de software, normalmente dividimos el proceso de investigación y desarrollo de software en cuatro etapas: análisis, diseño, desarrollo y prueba. En el actual sistema de investigación y desarrollo de productos de Internet dominado por la economía del comercio electrónico, por ejemplo. De hecho, es fácil para nosotros ignorar el proceso de análisis de software. Esto no quiere decir que los sistemas de comercio electrónico no necesiten ser analizados, pero debido a que hay demasiados productos homogéneos en esta industria, la referencia y el plagio son más eficientes. ¿Quién está dispuesto a analizar seriamente la esencia del negocio?

Otra razón por la que se ignoran los casos de uso son algunos malentendidos sobre el desarrollo ágil que aboga por la entrega rápida, utilizando a los clientes para probar la calidad del diseño y utilizando el mercado para probar el éxito o el fracaso del producto. . Esto fácilmente nos lleva a malinterpretar que el análisis empresarial no es necesario para el software o la industria a la que sirve. De hecho, el proceso de análisis-diseño-desarrollo-prueba es como la estructura sujeto-predicado-objeto en el lenguaje. o velocidad que utilices. La estructura básica no cambiará a pesar de las sofisticadas técnicas retóricas.

El sistema ágil de I+D en realidad cambia la forma tradicional de entrar en la etapa de diseño y desarrollo después de completar todo el análisis del sistema: análisis de escenarios de procesos de negocio únicos, desde el diseño hasta el desarrollo y las pruebas. En cuanto a la granularidad de la división de escenarios de procesos de negocio únicos, puede consultar mi artículo anterior: "7 procesos en los que las empresas de comercio electrónico por primera vez deben centrarse en la prioridad (1)".

Si todos están de acuerdo con el punto de vista anterior, continuemos hablando sobre qué es el caso de uso y cómo usarlo. Este artículo no explica cómo dibujar diagramas de casos de uso UML, porque hay demasiadas introducciones gratuitas en esta área en Internet y puede entenderlas sin comprar un libro. En lo que nos centramos es en cómo utilizar los casos de uso para resaltar sus funciones.

Mencioné anteriormente que el caso de uso es un proceso continuo que conecta el análisis empresarial y el diseño del sistema. Actualmente, la definición comúnmente utilizada de caso de uso en ingeniería de software es: caso de uso es un método utilizado para desarrollar un nuevo sistema. o transformación de software para capturar necesidades latentes. De hecho, si comprende la definición con atención, podrá comprender que "captar necesidades potenciales" es en realidad un proceso de análisis sistemático. Los casos de uso son más adecuados para una mayor descomposición de actividades abstractas de procesos de negocio.

A continuación, comprenderemos el posicionamiento y el papel de los casos de uso a través de la discusión de la relación entre los casos de uso y los procesos de negocio, el prototipo de interfaz y el diseño del sistema.

1. La relación entre análisis de casos de uso y procesos de negocio:

Para hablar de casos de uso, primero debemos hablar de qué es un proceso de negocio (Business Process), porque se complementan entre sí. otro, Negocios La definición de proceso en Wikipedia es: un conjunto estructurado y relacionado de actividades o tareas que brindan un servicio o producto específico (cumplen un objetivo específico) para un cliente o grupo de clientes específico. Aquí se utiliza el proceso de negocio en lugar de Business Flowing para distinguirlo de workFlow. WorkFlow es una descripción de actividades más sistemática, rigurosa y técnica. El proceso de negocio no tiene nada que ver con los sistemas y la tecnología. A veces describe puramente los procesos de negocio manuales. Esta es una forma de describir verdaderamente las necesidades del negocio. El análisis de procesos de negocio y el análisis de casos de uso tienen cada uno su propio enfoque. El proceso de negocio utiliza un enfoque basado en procesos para expresar la continuidad y la direccionalidad del desarrollo empresarial, mientras que el caso de uso se centra en actividades comerciales individuales y lleva a cabo un análisis de deconstrucción orientado a objetos.

Por ejemplo: Lo que mencioné en "Los 7 procesos prioritarios para los establecimientos iniciales de comercio electrónico (1)": Lo que se dibuja en el proceso de Solicitud de respuesta (solicitud de respuesta):

El proceso de solicitud de respuesta es un proceso de negocios. Es uno de varios procesos de negocios en el sistema operativo empresarial. Porque satisface el principio de comenzar desde el cliente hasta satisfacer al cliente, de extremo a extremo. puede El proceso se puede analizar por separado, lo que también está en línea con los conceptos de respuesta rápida, análisis de circuito cerrado y desarrollo de valor mínimo de la teoría ágil.

La función del caso de uso es analizar los escenarios de entidad de estas actividades comerciales en el proceso comercial (por ejemplo: consulta en la imagen de arriba, juzgar perspectivas de ventas, combinar productos, proporcionar propuesta de ventas, etc.) para obtener requisitos funcionales detallados para la actividad. Sí, el caso de uso es la clave para formar requisitos funcionales, por lo que es una herramienta de análisis de requisitos/análisis del sistema. Entonces, si ya tiene las funciones del sistema y luego realiza el análisis de casos de uso, encontrará que el caso de uso es completamente redundante. Reitero aquí que el caso de uso no es una herramienta de diseño, sino una herramienta de análisis empresarial.

Para probar este punto, podemos echar un vistazo a la estructura principal de la leyenda UML:

En la figura anterior podemos ver que el caso de uso está compuesto por Actor , caso, relación, sistema / módulo La composición y las relaciones entre ellos se dividen principalmente en: inclusión, generalización, uso y expansión. ¿Qué tal? Cuando ve estas ilustraciones, piensa: ¿No se trata simplemente de utilizar el pensamiento sistémico orientado a objetos para analizar y explicar las actividades comerciales? Sí, cuando tratamos con requisitos o actividades comerciales desconocidos, debemos realizar un análisis de casos de uso para convertir requisitos y procesos comerciales puros en requisitos del sistema con pensamiento orientado a objetos. En este momento, no hay funciones específicas, ni modelos de clases ni modelos de datos. A lo sumo, solo hay sistemas o módulos aproximados.

2.? La relación entre el caso de uso y el prototipo de interfaz

Al realizar el análisis de casos de uso, tal vez ya tenga un prototipo de interfaz (porque la tendencia de diseño actual es abogar por prototipos de interfaz y El análisis de requisitos está sincronizado, el prototipo de interfaz también es una herramienta para confirmar las necesidades del cliente), pero nunca debe expresar los requisitos de la interfaz en el caso de uso ni utilizar los requisitos de la interfaz para derivar el caso de uso, porque el enfoque del análisis del uso El caso es analizar la ocurrencia del proceso de negocios. Esencialmente (usando el análisis 5W1H), algunos pueden tener interfaces, otros no, algunos son entidades abstractas y otros son entidades de instancia. El objetivo del prototipo de interfaz es utilizar métodos de expresión visual y explícitos para expresar los resultados del análisis de procesos de negocio.

?

Por ejemplo, en la imagen de arriba: el inicio de sesión del usuario se ha generalizado en dos casos (entidades) de inicio de sesión con apodo e inicio de sesión con número de teléfono móvil. En el diseño de la interfaz, puede ser una interfaz (interfaz de inicio de sesión universal). ), o tal vez Hay dos interfaces (los diseñadores de interacción tendrán muchas razones para decirle qué diseño es mejor, pero generalmente ninguno de ellos se analiza en función de las posibilidades comerciales del usuario, porque a los diseñadores de interacción no les gusta estudiar los procesos comerciales, jaja! Maestro del diseño de interacción, ¡no me pegues!). Si utilizamos el diseño de la interfaz para deducir el caso de uso a la inversa, será muy fácil limitar las posibilidades de nuestro desarrollo comercial. En el ejemplo anterior, de acuerdo con los resultados del análisis abstracto y generalizado del proceso comercial, también puede descubrir cómo. para iniciar sesión escaneando el código QR del caso. Por lo tanto, el caso de uso y el prototipo de interfaz están en una relación de verificación mutua, en lugar de reemplazarse entre sí. Otra función del caso de uso es analizar las posibilidades de negocio.

3. La relación entre el caso de uso y el diseño del sistema

El diseño del sistema mencionado aquí cubre procesos UML comunes como: diseño de módulos, diseño de clases, diseño de tiempos, diseño de actividades del sistema y campos Diseño de modelos de información en el diseño de controladores. Además de generar requisitos funcionales y proporcionar análisis de posibilidades de negocio, el análisis de casos de uso también puede proporcionar material de primera mano para el diseño estructural y el diseño de comportamiento para el diseño posterior del sistema, porque todo el proceso de análisis utiliza un método sistemático orientado a objetos.

Por lo tanto, el caso de uso proporciona la capacidad de traducir las necesidades del cliente en un lenguaje sistemático. La persona que escribe o dibuja el caso de uso debe ser una combinación de capacidad de análisis empresarial y capacidad de pensamiento sistemático. El caso de uso es un vínculo clave entre el análisis de procesos de negocio y el diseño del sistema. La calidad del caso de uso está directamente relacionada con la posibilidad de negocio y si puede reflejarse en las funciones del sistema.

Para hacer un buen caso de uso se requiere que los gerentes de producto tengan suficiente pensamiento sistemático y que los arquitectos tengan suficiente pensamiento de análisis de procesos de negocios, pero este es un eslabón relativamente débil en el actual sistema de I+D de Internet. En algunas grandes empresas de TI, en realidad existe un papel entre los gerentes de producto y los arquitectos: analistas de sistemas o arquitectos comerciales, simplemente porque el rol de los gerentes de producto está aumentando actualmente en la industria y existe una tendencia a reemplazarlos gradualmente. El contenido del trabajo es fácil de olvidar, por lo que si su empresa valora las capacidades de análisis de negocios, los gerentes de productos deben tener un pensamiento analítico sistemático, los arquitectos deben tener un pensamiento analítico de procesos de negocios o configurar el sistema Los roles de analistas y arquitectos de negocios son la única manera de descubrir, transformar y ampliar verdaderamente las necesidades comerciales de la industria en productos de alta calidad.

Determinar la granularidad del análisis del caso de uso es en realidad la parte más problemática de todo el proceso de análisis, y también es la parte más fácil de ignorar. El resultado de ser ignorado es que el caso de uso que elegimos es. ni representativo ni representativo No hay continuidad (realización de análisis de procesos de negocio), y mucho menos exhaustividad. Una vez que el caso de uso no puede proporcionar los requisitos funcionales detallados y completos y el análisis estructural y de comportamiento necesarios para el diseño del sistema, el caso de uso se vuelve tan inútil como una pieza. de documentación formal.

1. En primer lugar, es necesario determinar la granularidad de la expresión del caso de uso:

El caso de uso es un proceso continuo que conecta el análisis empresarial y el diseño del sistema, por lo que no debe Depender de la experiencia, configuraciones aisladas o Se define directamente en la cabeza. Debe seguir la continuidad del análisis de negocios. Esta es la continuidad desde el análisis de procesos de negocios hasta el análisis de casos de uso, y la definición granular de casos de uso se puede establecer en el negocio. actividades en el proceso de negocio. Nota: El punto base para establecer el caso de uso deben ser las actividades del proceso de negocio en lugar de la estructura de la interfaz.

Tome el pedido hasta la confirmación (orden hasta la confirmación) de "7 procesos que las empresas de comercio electrónico por primera vez deben priorizar (1)" como ejemplo de la granularidad del análisis del caso de uso que queremos. Para establecer debe comenzar desde el inicio de las actividades comerciales, lo que significa que debemos establecer descripciones de casos de uso para estas actividades: emisión de pedidos, cálculos de costos, desmantelamiento de pedidos, entrega de productos, evaluación y seguimiento, confirmación de finalización, etc.

Cabe señalar aquí que el pedido hasta la confirmación es solo un proceso comercial abstracto. Debido a las diferencias y la complejidad de la industria, una actividad comercial puede continuar desglosándose en más actividades. Por ejemplo: "Desarmar orden", se dividirá en tres categorías: "Descomponer orden de producto, descomponer orden de servicio y descomponer orden de recursos". Tenga en cuenta que las actividades comerciales aquí no se refieren a los pasos operativos específicos del sistema, por lo tanto, no descomponga las actividades comerciales finales en operaciones específicas del sistema, como agregar, eliminar, modificar, insertar, consultar, etc., porque estas operaciones son basado en la implementación del sistema, en lugar de en la base del análisis de negocios.

La razón por la que los casos de uso se basan en actividades comerciales es precisamente porque las actividades comerciales no tienen restricciones de sistema ni restricciones técnicas. Las actividades comerciales deben mostrar la posibilidad de desarrollo empresarial, en lugar de la implementación de un sistema específico, y lo mismo ocurre con la granularidad de los casos de uso.

2. En segundo lugar, con la granularidad de los casos de uso, ¿cómo generamos casos de uso? Presento un método para generar casos de uso.

Necesitamos proporcionar una descripción del script para cada caso de uso. La descripción debe ser concisa y significativa, y la estructura básica de la oración debe ajustarse a la oración: hora, lugar, quién, qué se hizo, cómo. hacerlo, y por qué se hizo, el modelo 5W1H y las variables que en última instancia afectan el caso de uso deben ser determinadas por analistas de sistemas, arquitectos de negocios o gerentes de productos en función de las características del negocio.

Tomamos la actividad empresarial "publicar pedido" en Pedido hasta confirmación como ejemplo y establecemos el siguiente modelo de análisis de casos de uso de la siguiente manera:

Este es el modelo más simple y herramienta eficaz de generación de casos de uso Primero, el arquitecto empresarial define y selecciona las dimensiones de las posibilidades comerciales que pueden afectar la actividad empresarial. Puede consultar el método 5W1H y el "intervalo de tiempo" mencionado en la figura. tipo de canal", "método de pedido", "tipo de producto" y "condiciones de activación" son solo las dimensiones que proporcioné como ejemplos. Puede definir sus propias dimensiones en función de las características comerciales de su industria. El punto clave al definir dimensiones es buscar diferencias en Case. Si no hay dimensiones diferentes, se pueden descartar directamente. Por ejemplo, si no hay diferencias entre las actividades de emitir pedidos por la mañana y por la tarde, simplemente ignórelas. . En segundo lugar, es necesario completar los parámetros de dimensión relevantes, tal vez un determinado tipo o instancia específica. Finalmente, el caso más directo se puede obtener realizando una operación de producto cartesiano en estos parámetros dimensionales.

Cuando la mayoría de nosotros generamos casos de uso, nos faltan métodos, ya sea utilizando la experiencia o mirando prototipos de interfaz, por lo que es difícil garantizar que las posibilidades de negocio que analizamos no se pierdan con solo darnos palmaditas en la cabeza. etc., por lo que le sugiero que pruebe el método anterior. Por supuesto que te volverás loco cuando veas 432 Casos ¿Qué, tantos? De hecho, estos 432 casos son solo casos de posibilidades comerciales. Puede utilizar el método de eliminación para eliminar fácilmente casos de uso imposibles, inválidos e indistinguibles según las características comerciales de su industria. Los casos utilizados reales se pueden controlar con 2 dígitos. .

Quizás lo que queda es: "Los nuevos clientes por la noche aceptaron los productos recomendados por la plataforma y ordenaron electrodomésticos a través de un análisis comparativo de productos a través de sus propios canales en línea". A partir de este script, podrá dibujar la leyenda del caso de uso y analizar los requisitos funcionales del negocio, el primer borrador del modelo estructural y del modelo de comportamiento, y las posibilidades de negocio. El proceso de elaboración de la leyenda UML del caso de uso no se describirá aquí. Puede consultar el documento del caso de uso de UML.

3. Finalmente, me gustaría aclarar otra disputa conceptual sobre los casos de uso en la industria.

Hay dos puntos de vista diferentes sobre los casos de uso en la industria. Uno es que el caso de uso es. una visión abstracta y, a menudo, no es necesario aportar parámetros comerciales específicos. Otra forma es pensar que el caso de uso es una instancia, que es una vista parametrizada.

Ambas afirmaciones son razonables. La premisa es si el análisis del proceso de negocio está incluido en el análisis de correlación con el caso de uso. Sabemos que el análisis del proceso de negocio en sí es un tipo de análisis abstracto, y el proceso de negocio en sí también tiene un análisis abstracto. proceso y un proceso de creación de instancias, el proceso abstracto se utiliza para el análisis del sistema, el proceso de creación de instancias se utiliza para el diseño del flujo de trabajo del sistema y el caso de uso emprende el proceso de abstracción, por lo que es necesario realizar un análisis de creación de instancias de las actividades comerciales abstraídas. De hecho, esta creación de instancias no es la creación de instancias final del sistema, porque en el proceso de creación de casos de uso, es necesario seleccionar un caso diferenciado para realizar un análisis de diferenciación de negocios, por lo que podemos pensar que la creación de instancias del caso de uso es una instancia limitada. cambiar.

Este artículo no se centra en el método de dibujo de casos de uso específico de UML, porque si va a Baidu, puede obtener muchos métodos relacionados. Me centré en si los casos de uso son útiles o no y en qué medida son los casos de uso. En términos de discusión, mis 14 años de experiencia en diseño y desarrollo de sistemas me dicen que si muchas herramientas y métodos no se utilizan en conjunto y no comprenden el significado de su existencia y sus propósitos comerciales reales, entonces lo que a menudo hacemos. terminar con un diseño formal, que es perjudicial para el producto y el sistema no será de mucha ayuda.

El caso de uso tiene ese problema. En primer lugar, debemos entender que es un proceso de análisis, no un proceso de diseño. Si no lo hacemos, es un proceso de vinculación. Comprenda este problema. Los casos de uso pueden ser inútiles para todos los roles en el desarrollo de productos.

En segundo lugar, necesitamos saber qué nos puede proporcionar exactamente el caso de uso. Puede ayudarnos a analizar los requisitos funcionales y las posibilidades de negocio. Esta es la parte más importante en mi opinión, es decir, si ya tenemos requisitos funcionales o limitamos el análisis de las posibilidades de negocio, entonces sentirás lo mismo al hacer el uso. caso completamente redundante.

Además, enfaticé que la selección granular de los casos de uso debe colocarse en las actividades comerciales en el análisis del proceso comercial. Sólo de esta manera el proceso de análisis puede tener la coherencia del diseño y la integridad del mismo. costo mínimo Esto también está en línea con el concepto de diseño ágil.

Finalmente, proporciono un conjunto de métodos para generar casos de uso, que pueden ayudarlo a generar rápidamente casos de instanciación limitada. Podemos generar requisitos funcionales y posibilidades comerciales a través del análisis de casos diferenciados y proporcionar el siguiente diseño estructural del sistema. y el diseño conductual proporcionan las referencias de diseño necesarias.

Bueno, eso es todo por hoy. Espero escribir otro artículo antes de fin de año. El título aún está por determinar. ¡Os deseo a todos un feliz año nuevo!