Nombre
•Nombre las actividades con un verbo en infinitivo y un objeto.
•El nombre debe identificar claramente el objetivo de la actividad. Por ejemplo: “Crear solicitud”, “Autorizar solicitud”, “Notificar rechazo”, etc.
•Utilice la primera letra en mayúscula y las demás en minúscula. No utilice nombres cortos ni abreviaciones.
•Evite nombres largos. Usualmente denotan que ciertos detalles de la actividad inciden en su nombre.
Concéntrese en el objetivo y documente los detalles dentro de la actividad.
•Evite utilizar las “y” / “o” en los nombres de las actividades.
Este tipo de nombres compuestos puede significar que en realidad se trata de dos actividades diferentes.
Por ejemplo, si la actividad se llama “Revisar y aprobar solicitud”, debemos plantearnos cuál es la opción correcta:
Si el mismo participante realiza las dos acciones en el mismo momento, entonces debemos elegir la acción más relevante y usarla para nombrar la actividad. Por ejemplo, si decimos que la solicitud es revisada y aprobada, entonces podemos asumir que el objetivo primario es la aprobación y la revisión es una subtarea. El nombre correcto es “Aprobar solicitud”
Caso contrario, si consideramos que ambas acciones tienen la misma relevancia y son realizadas en diferente momento, entonces será conveniente separarlas “Revisar solicitud” y “Aprobar solicitud”.
Repetición de Actividades
•No diagrame múltiples instancias de la misma tarea para representar múltiples participantes.
•Utilice roles o agentes para que la asignación del participante sea realizada según corresponda, al ejecutar el proceso.
 |
 |
|
|
Tipificación de Actividades
•Procure indicar el tipo de cada actividad.
•Sea cuidadoso seleccionando el tipo adecuado, que permitirá una correcta interpretación del diagrama.
Tarea de Usuario
Este tipo de tarea es realizada por un humano.
Se trata de un usuario del sistema, que interactúa con el motor de workflow a través del portal de usuarios.
Típicamente el usuario recibe la asignación del trabajo a través de la lista de tareas de Deyel y utiliza el portal para realizarla.
Recomendamos utilizar esta notación para modelar todas las actividades en las cuales el usuario debe crear, modificar o consultar un formulario electrónico.
Tarea Manual
Este tipo de tarea es realizada por un humano, pero sin la intervención del motor de workflow.
Representa una tarea no automatizada, en la cual no se utilizan herramientas informáticas.
Recomendamos utilizar esta notación para modelar por ejemplo las actividades como:
- Llamar por teléfono al cliente.
- Instalar el sistema de audio.
Son tareas donde NO se define la “ejecución de la actividad” asistida por el motor de workflow.
No se crean ni modifican formularios.
Únicamente se interactúa con el motor para registrar el pasaje a la actividad siguiente.
Tarea de Servicio
Representa la ejecución de un servicio, de manera automática y sin intervención del usuario.
Por ejemplo, la invocación de un servicio web o de un componente de software automatizado o de una regla de integración.
Recomendamos utilizar esta notación para modelar la ejecución de componentes o reglas de los siguientes tipos:
JDBC Component, Java Component, Web Services Component, Wrapper Component.
Tarea de Regla de Negocios
Representa la ejecución de una regla de negocios.
Proporciona un mecanismo para que el proceso interactúe con el motor de reglas, solicitando la ejecución de una regla determinada.
Se contempla el pasaje de parámetros entre el proceso y la regla, sean estos de entrada o de salida.
En Deyel utilizamos este tipo de tareas para modelar la ejecución de una regla estándar.
Tarea de Envío
Es utilizada para el envío de un mensaje a un participante externo relativo al proceso.
Cuando el mensaje ha sido enviado, la tarea finaliza.
Para identificar esta tarea se utiliza un ícono de correo con una flecha de salida.
Este tipo de tareas son utilizadas para modelar las tareas automáticas de mail.
Tarea de Recepción
Es utilizada para la espera de un mensaje proveniente de un participante externo relativo al proceso.
Cuando el mensaje es recibido la tarea es finalizada y se puede continuar a la siguiente.
Para identificar esta tarea se utiliza un ícono de correo con una flecha de recepción.
En Deyel usamos tareas de este tipo cuando representamos que el proceso queda a la espera hasta la recepción de un mail.
Utilizamos un evento Boundary de tipo mail, asociado a una tarea de recepción.
Tarea de Scrips
Este tipo de tareas son ejecutadas por el motor de procesos de negocios.
Ejecuta scripts definidos en el lenguaje en el que el motor de workflow puede interpretarlos.
Cuando la tarea está lista puede ejecutar el script, y la misma es completada cuando finaliza el mismo.
La forma de representación es mediante un icono de “hoja de script”.
En Deyel este tipo de tareas está representada por las reglas automáticas del motor de workflow tales como direct movement, end case, etc.
Tareas Automáticas Vs. Acciones Automáticas
•Existen ciertas acciones, como el envío de un mail, la ejecución de una regla, etc., que pueden ser modeladas de diferente forma en Deyel:
a)Representándolas explícitamente en el modelo, mediante actividades de tipo envío, regla de negocios, servicios, etc.
b)Especificando acciones automáticas que se ejecutan al iniciar o al finalizar una actividad de usuario o una actividad manual.
•La recomendación aquí es que aquellas tareas cuya ejecución necesitemos hacer explícita visualmente, las modelemos como actividades y las tipifiquemos según corresponda.
•Aquellas otras que no necesitan ser explicitadas, como por ejemplo, una regla que recupera el valor inicial de un campo, antes de ejecutar la actividad de usuario, se modelan como acciones automáticas de la actividad de usuario.
•Es importante mantener un criterio uniforme en este sentido y considerar también que los diagramas extensos no son convenientes.
