Identificar casos de uso a partir del proceso de negocio

Los equipos de desarrollo pueden utilizar el modelo de proceso de negocio para documentar visualmente los flujos de trabajo del negocio, y asociar casos de uso con esos procesos de negocio para modelar las características deseadas que el sistema debe alcanzar. En este tutorial, explicaremos en detalle cómo utilizar la función de transitor de modelos para establecer trazabilidad entre casos de uso y procesos de negocio.

¿Qué son BPMN y BPD?

BPMN proporciona a los analistas de negocios un conjunto de notaciones gráficas para modelar procesos de negocio. Fue inicialmente desarrollado por el Iniciativa de Gestión de Procesos de Negocio (BPMI) y actualmente es mantenido por el Grupo de Gestión de Objetos (OMG). Una de las motivaciones para desarrollar BPMN es proporcionar un lenguaje gráfico común para personas en diferentes roles, procedentes de diferentes países y/o con diferentes idiomas hablados, para que puedan entender el mismo proceso de negocio sin barreras.

BPD, abreviatura de Diagrama de Proceso de Negocio, es donde se modela el proceso de negocio utilizando BPMN. Es un diagrama similar a un flujo, que representa el flujo del proceso, los participantes involucrados y los intercambios de mensajes entre ellos. Los analistas de negocios dibujan BPD(s) para modelar cómo diferentes participantes colaboran para alcanzar un objetivo de negocio. Una vez validado el modelo de negocio completado con los usuarios finales, el analista de sistemas puede comenzar a planificar el sistema.

Lo siguiente es un BPD simple de un proceso de registro para una organización. Cubre la mayoría de las notaciones típicas que verías. Veámoslo.

Notación	Descripción
	Pool – Representa un participante dentro de un proceso. En BPMN, tanto los pools como las líneas se utilizan para representar participantes. Una línea está contenida por un pool para modelar una subpartición del pool principal.
	Evento de inicio – El inicio de un proceso. Se pueden definir desencadenantes para informar a los lectores en qué situación se activará el proceso. Por ejemplo, cuando se recibe un correo electrónico/cuando es lunes por la mañana/cuando ocurre un error.
	Tarea – Una actividad atómica que los participantes designados (modelados por pool/línea) podrían realizar. Las tareas y otros objetos de flujo se conectan entre sí para formar un flujo de trabajo de negocio completo.
	Evento final – El final de un proceso. Se puede definir un resultado para informar a los lectores qué ocurrirá cuando finalice el proceso. Por ejemplo, emitir una señal/producir un error, etc.

En este tutorial no nos centraremos en exceso en BPD ni en el modelado de procesos de negocio. Si desea aprender más sobre BPMN, BPD o modelado de procesos de negocio, lea el tutorial Introducción a BPMN Parte I a IV.

¿Qué es el diagrama de casos de uso?

El modelado de casos de uso se refiere a la técnica de capturar los requisitos de alto nivel del usuario utilizando el diagrama de casos de uso de UML. El modelo de casos de uso está diseñado para diseñadores de software o sistemas, no para personas del negocio.

Hay tres elementos principales en un diagrama de casos de uso.

Notación	Descripción
	Casos de uso – Cada caso de uso representa un objetivo del usuario, que es un objetivo que el usuario del sistema desea alcanzar. Tenga en cuenta que los casos de uso solo se pueden utilizar para mostrar lo que el usuario desea hacer en lugar de lo que el desarrollador necesita desarrollar, aunque en algunos casos puedan ser iguales. Si desea documentar o modelar las funciones involucradas en un caso de uso, puede utilizar la herramienta de flujo de eventos, o elaborar un caso de uso condiagrama de secuencia/diagrama de actividad. Solo tenga en cuenta que el modelado de casos de uso tiene como objetivo modelar lo que el usuario desea lograr.
	Actor – Usuario del sistema. La palabra ‘usuario’ aquí no se limita a seres humanos. Puede ser un sistema que interactúa con nuestro sistema para cumplir un objetivo empresarial determinado.
	Enlace de comunicación/Asociación – Conecta entre actor y caso de uso para indicar el acceso del sistema por parte del actor. Cada enlace de comunicación implica una secuencia de transacciones entre el actor y el sistema.

Transición desde el BPD y el diagrama de casos de uso

Aunque el BPD y el diagrama de casos de uso no necesariamente deben depender uno del otro, podrían relacionarse de alguna manera de forma complementaria. Normalmente, desarrollamos software para automatizar o optimizar ciertos flujos de trabajo de procesos empresariales. Con el BPD, puedes comprender cómo colaboran los participantes y quién es responsable de qué, y así identificar qué funciones necesitan que el sistema apoye. Esas funciones del sistema (flujo de trabajo o proceso empresarial) que el usuario desea podrían modelarse mediante casos de uso y posteriormente desarrollarse por el equipo. En consecuencia, podemos decir que el BPD te ayuda a identificar casos de uso para un sistema en desarrollo.

Visual Paradigm es una herramienta de modelado visual que apoya desde la realización de procesos empresariales hasta el modelado de casos de uso (desde los requisitos empresariales hasta los requisitos de aplicación) al establecer enlaces de trazabilidad entre los dos modelos mediante la función de transitor de modelos. Necesitamos la trazabilidad por las siguientes razones:

• Podemos asegurarnos de que el sistema se adapte al uso real del mundo al estudiar la parte del flujo de proceso que involucra un caso de uso.
• Para responder preguntas como ‘¿Por qué necesitamos esta función (del sistema)?’ al rastrear la parte del proceso desde la cual se originó un caso de uso.
• Para responder preguntas como ‘¿Ya se ha implementado una operación específica?’ al rastrear desde el BPD hasta el diagrama de casos de uso.

BPD frente al diagrama de casos de uso

Cuando transitas un BPD a un diagrama de casos de uso, puedes generar un actor a partir de una celda/piscina, y producir un caso de uso a partir de una tarea/subproceso. La siguiente tabla te muestra las características de piscina, celda, actor, tarea, subproceso y caso de uso, en términos de transición de modelos.

Desde	Hacia	Descripción
		Piscina/Celda a Actor En el BPD, una piscina representa un participante del proceso empresarial, mientras que una celda es una subpartición de la piscina. Cualquier persona que tenga una actividad que realizar, relacionada con el proceso, se considera un participante. En el diagrama de casos de uso, un actor representa un usuario del sistema. Tenga en cuenta que cualquier persona o rol que no sea un usuario del sistema no debe considerarse como actor.
		Tarea/Subproceso a Caso de uso En el BPD, una tarea/subproceso (actividad) se refiere a cualquier acción que un participante podría realizar para completar un proceso empresarial. En el diagrama de casos de uso, un caso de uso presenta un objetivo que el usuario desea alcanzar al utilizar el sistema. Tenga en cuenta que una actividad no necesita estar relacionada con ninguna función del sistema, y un caso de uso puede satisfacer múltiples actividades.

Algunas personas podrían pensar que un diagrama de casos de uso es similar a un BPD, pero muy diferente en notaciones y propósitos. Recuerde el hecho de que BPMN está diseñado para personas del negocio, mientras que el diagrama de casos de uso está destinado a analistas de sistemas o desarrolladores de sistemas. Tienen propósitos diferentes y leen el negocio desde dos perspectivas distintas. Por eso, en la sección anterior he resumido la relación entre el BPD y el diagrama de casos de uso diciendo ‘el BPD te ayuda a identificar casos de uso’. El BPD solo puede darte pistas al identificar casos de uso. No existe ninguna regla que establezca que cada tarea existente en un BPD sea equivalente a un caso de uso. Pero podríamos elaborar un proceso empresarial mediante un caso de uso para la automatización de una característica por parte del sistema objetivo.

En el estudio de caso, te daré algunas ideas sobre lo que debes tener en cuenta al transitar un BPD a un diagrama de casos de uso. Entonces comprenderás cuán diferentes son.

Estudio de caso: La empresa True Aqua de agua destilada

La empresa True Aqua de agua destilada es un proveedor joven de agua destilada en la ciudad. Venden agua destilada para uso comercial y doméstico. A continuación se presenta una descripción textual de su proceso de entrega de agua.

Se ha creado un modelo de proceso empresarial basado en la descripción. Ahora se te pide que desarrolles un sistema informático para optimizar todo el proceso. Lo primero que debes hacer es desarrollar un modelo de casos de uso. Con la ayuda del BPD, intenta desarrollar un diagrama de casos de uso.

1. DescargarDistilled Water Delivery.vpp. También puedes encontrar este archivo al final de este tutorial.
2. Abra el archivo .vpp descargado en Visual Paradigm. Para abrir un proyecto, seleccione Proyecto > Abrir desde la barra de herramientas de la aplicación.
3. Abra el BPD Proceso de pedido de agua destilada. Estudie con cuidado el flujo del proceso.
   
4. El proceso comienza cuando un cliente realiza un pedido. Aquí podemos considerar un caso de uso: Realizar pedido. El caso de uso ayudará a automatizar el proceso al proporcionar una interfaz para que el cliente realice el pedido sin la asistencia del asistente de servicio al cliente, ayudar a verificar la identidad del cliente y crear una cuenta si el cliente no existe. Haga clic derecho en Realizar pedido y seleccione Elementos relacionados > Transitar a nuevo caso de uso… desde el menú emergente.
   
5. Esto muestra la ventana Transitar elemento del modeloventana, donde puede seleccionar el modelo para colocar el caso de uso y el actor, y renombrarlos. En este caso estamos satisfechos con los nombres del caso de uso y del actor. Mantengámoslos sin cambios. Haga clic en Aceptar.
   
   Esto crea un nuevo diagrama de casos de uso en UeXceler.
   
6. Vuelva al BPD.
7. Consideremos la tarea Crear cuenta de cliente. En el proceso empresarial, el asistente de servicio al cliente necesita crear una cuenta para cada cliente nuevo. En el nuevo sistema, esto puede ser parte del caso de uso Realizar pedidoo ser un caso de uso independiente activado manualmente por el asistente de servicio al cliente. En una situación real, debería aclarar este tipo de duda con el interesado, porque un modelo de caso de uso incorrecto llevará al desarrollo de funciones que no coincidan con las expectativas del usuario. En este ejemplo, supongamos que el usuario desea que la tarea Crear cuenta de clientese realice por el asistente de servicio al cliente. Creemos un caso de uso a partir de ella. Haga clic derecho en Crear cuenta de cliente y seleccione Elementos relacionados > Transitar a nuevo caso de uso… desde el menú emergente.
   
8. Nuevamente, estamos satisfechos con el nombre del caso de uso y del actor. Mantenga todo en la ventana Transitar elemento del modelosin cambios. Haga clic en Aceptar. El diagrama de casos de uso se actualiza con un nuevo caso de uso y actor. Veamos.
   
9. Vuelva al BPD. Pasemos al subprocesoOrganizar la entrega. El gerente del Departamento de Logística puede usar el sistema para realizar programaciones y notificar a los trabajadores para entregar agua. Por lo tanto, este también es un caso de uso del sistema. Haga clic derecho sobre el subprocesoOrganizar la entrega y seleccioneElementos relacionados > Transitar a nuevo caso de uso… del menú emergente.
10. Verifique al actor Gerente en elventana de Transición de elemento de modelo ventana. Si mantenemos el nombre del actor comoGerente, esto es ambiguo en el modelo de casos de uso porque puede haber muchos departamentos con muchos gerentes diferentes en la empresa. Por lo tanto, cambie el nombre del actor aGerente del Departamento de Logística.
    
11. Haga clic enAceptar. El diagrama de casos de uso se actualiza.
    
12. Vuelva al BPD. La tarea finalEntregar aguaes un trabajo que solo puede realizarse por humanos y no tiene nada que ver con la interacción del sistema. Por lo tanto, no necesitamos crear un caso de uso para él.
13. Supongamos que el gerente regional desea que el sistema apoye una nueva función que pueda generar un informe para mostrar las estadísticas sobre pedidos. Esta función puede ayudarlo a revisar y perfeccionar la estrategia de marketing. Aunque esta función no se había modelado en el modelo de proceso de negocio, podemos dibujarla directamente en el diagrama de casos de uso. Abra el diagrama de casos de uso. Dibuje un actorGerente regional. Cree un caso de usoGenerar informe estadísticoa partir de él con una asociación entre ambos.
    
14. Digamos que el cliente desea permitir al cliente ver los estados de facturación y cancelar pedidos. Además, el cliente desea permitir al gerente del departamento de logística imprimir informes de logística. Dibuje los casos de uso respectivamente.
    
15. Organice el diagrama.
    
16. La relación de transición le permite rastrear el modelo de proceso de negocio desde el modelo de casos de uso (y viceversa). Probémoslo. Coloque el puntero del mouse sobre elColocar Pedido caso de uso.
    
17. Haga clic en el Modelo Transitor recurso en la esquina inferior derecha de la forma. Seleccione Transitar Desde > Proceso de Pedido de Agua Destilada<.Colocar Pedido del menú emergente.
    
    Esto abre el BPD con la tarea Colocar Pedido seleccionada.