Comprenda los diagramas de casos de uso de UML en un artículo

Cuando tienes un caso de negocio en mente, ¿cómo se lo presentas a tu jefe? ¿Un gran párrafo de texto o empezar a escribir una demostración? El jefe está muy ocupado y es posible que no comprenda la tecnología de "alta gama" que usted llama. ¿Hay alguna manera de expresarlo que sea más económica pero que contenga más información? Sí, ¡hagamos un dibujo!

A partir de hoy abriremos otro tema para hablar sobre algunos métodos de modelado gráfico comúnmente utilizados en nuestro desarrollo. Al final del prefacio, partimos de la vista UML.

UML - Lenguaje de modelado unificado - El lenguaje de modelado unificado es la vista más utilizada e importante en la etapa de modelado de negocios. Debido a que es simple y fácil de entender, a menudo se usa en documentos interorganizacionales o instrucciones de presentación. Aquí, el llamado interorganización se refiere no solo al departamento de desarrollo, sino también al negocio en términos de productos, diseño, pruebas, departamentos de operación y mantenimiento, etc. En comunicación. En el diseño UML, el primer diagrama suele ser un diagrama de casos de uso: sí, el que tiene el "hombrecito".

El diagrama de casos de uso consta principalmente de tres partes: caso de uso (Caso de uso), actor (Actor) y su relación mutua (Relación) en la forma, utiliza óvalos, villanos y flechas para conectarse; combinación de líneas.

No entremos en detalles sobre el significado específico de elipses o flechas. Creo que es mejor comenzar con un caso de uso específico cuando se habla de diagramas de casos de uso. Intentamos diseñar una aplicación bancaria sencilla, que incluya registro, inicio de sesión, transacciones y otras operaciones. Desglosamos paso a paso el proceso de jugar con diagramas de casos de uso.

El primer paso para dibujar un diagrama de casos de uso suele ser arrastrar un enorme bloque rectangular y nombrarlo nuestro sistema de destino: Aplicación bancaria. Un diagrama de casos de uso generalmente solo tiene un Sistema. Luego colocaremos todas las funciones relacionadas con el sistema ("casos de uso") dentro del sistema, y ​​las partes relevantes del sistema ("participantes") en los lados izquierdo y derecho. el sistema.

El segundo elemento de dibujo es el actor, es decir, la parte interesada del sistema, que puede ser una persona, una organización, un dispositivo externo u otro sistema. En nuestro caso bancario, existen dos partes relevantes en la App: el cliente y el banco.

En términos generales, habrá dos o tres participantes en un diagrama de casos de uso. Colocaremos a los participantes principales en el lado izquierdo del sistema y a los participantes secundarios (respondedores de los participantes principales) en el lado derecho. lado; obviamente nuestra aplicación está principalmente orientada al cliente, por lo que colocamos a los clientes en el lado izquierdo.

El tercer paso es agregar casos de uso específicos en el sistema, es decir, las funciones o bloques de negocio proporcionados por el sistema. Nuestra APP bancaria es relativamente simple y solo brinda los siguientes servicios:

En el cuarto paso, conectamos a los participantes con casos de uso, que es lo que llamamos relaciones. En los diagramas de casos de uso, las relaciones se pueden subdividir aún más:

Finalmente, todas las vistas UML se pueden anotar. Los términos profesionales se denominan puntos de extensión y notas. Estas dos propiedades de anotación son las mismas, todas con fines ilustrativos. :

Bueno, eso es todo para los diagramas de casos de uso de UML. Revisemos los escenarios de uso de los diagramas de casos de uso. En la etapa de diseño del producto, podemos usar diagramas de casos de uso para establecer relaciones abstractas entre usuarios, sistemas y servicios funcionales para describir las características dinámicas externas del producto. En algunas empresas grandes, los gerentes de producto o diseñadores generalmente dibujan primero diagramas de casos de uso UML y luego los entregan al equipo de desarrollo para su implementación.

Dimos un ejemplo de una aplicación bancaria, que en realidad es un poco grande; en el desarrollo real, un diagrama de casos de uso generalmente solo corresponde a un flujo de negocios simple. Cuando escribimos diagramas de casos de uso nosotros mismos, también debemos prestar atención a abstraer módulos funcionales estrechamente relacionados en un Caso simple a nivel macro, y luego dibujar gradualmente diagramas de casos de uso que subdividan los Casos para estos módulos funcionales más grandes.