Introducción
En la siguiente simulación mostramos parte de un Workflow de Procesos y Documentos de uno de nuestros clientes.
Dado que esta será una aplicación propietaria no publicaremos la Simulación final sino una de las simulaciones intermedias.
Este sistema tiene como objetivo administrar los proceso y documentos de la empresa. Cada usuario (o Rol) puede participar en más de un proceso de la empresa, y estos procesos del usuario pueden pertenecer a diferentes proyectos.
La idea general es que cuando un Rol entre al sistema vea o tenga sus Proceso, sus Documentos (MS Office), y los eventos relacionados (con los Procesos y Documentos) en los que este Rol tiene los permisos necesarios. Por ejemplo: si se termina la edición de un documento (se paso a Revision), y el Rol tiene permiso de Aprobar –> este evento debe aparecer en la lista de eventos de este rol.
Reglas Generales
* Los administradores (o jefes de proyecto) asignan a los demás roles a los diferentes procesos.
* Los procesos tiene diferentes permisos para los roles: Entrada, Continuar, Detener, Finalizar. Dependiendo de los permisos del Rol, los comandos disponibles (botones) para este en la página web.
* Los documentos del Rol dependen de los procesos en los que este asignado este rol, y de los permisos sobre estos. Permisos de documentos: Acceder, Aprobar, Editar, Publicar, Revisar.
Beneficios de la Simulación
Como el sistema tiene cierto nivel de complejidad, muchas fallas (u omisiones) en el diseño no se detectan. Solo cuando los programadores empiezan la implementación y estas fallas empiezan a surgir.
Cuanto más complejo el sistema más propenso a fallas de diseño estará. Estas fallas tiene diferentes características, es muy difícil listar todas. Un diseño puede tener fallas menores y fallas mayores. Entre las fallas menores se pueden encontrar: omisión de atributos de una clase, una relación entre clases no especificada, clases que no existen pero son necesarias, incongruencia entre clases, etc.
Las fallas mayores NO pueden ser detectadas (o al menos es muy difícil hacerlo) hasta tanto no se comience con la implementación.
Esto es porque el diseño esta especificado en documentación estática, ejemplo, documentos Word, diagramas de clases, diagramas de casos de uso, diagramas de secuencia, máquinas de estado,etc. Es decir, si bien esta documentación es fundamental en todo proyecto, tambien hay que reconocer que es “letra muerta“.
Por “letra muerta” se tiene que entender que es algo estático, y es imposible para alguien tener en cuenta todos los casos que se puede dar en un sistema dinámico a partir de documentos estáticos (si bien sabemos que esta documentación es fundamental).
Este es el motivo por el cual todos los proyectos tienen varias etapas de diseño –> desarrollo –> diseño –> desarrollo, etc. Esta actividad de “prueba y error” entre el diseño y el desarrollo es extremadamente costosa.
En este punto es donde la simulación es un paso fundamental para asegurar la calidad de un diseño, y así evitar por completo o en un gran porcentaje, este vaivén entre el diseño y el desarrollo.
La simulación da una visión concreta de los problemas que tiene un diseño, y los errores en el diseño están 100% especificados en la simulación.
Esta simulación provee a los actores del proyecto con valiosa información.
Si a la simulación le sumamos el prototipado –> estamos en gran ventaja con respecto a la forma tradicional de diseño.
El prototipado permite al cliente tener una mejor visión de lo que será su sistema, permitiendo que este que pueda especificar mucho mejor sus requermientos, esto redunda en ahorro de costos (que generalmente es muy difícil de cuantificar).
Antes de describir el sistema adelanto la conclusión final…
Conclusión
Con esta simulación nuestro cliente llego a la etapa de desarrollo 100% seguro de que su diseño funciona, hace lo esperado y además es lo que quiere su cliente, ya que este participo de la simulación y el diseño del prototipo.
Diagrama de Clases

Clases principales: Rol, Proyecto, Proceso, Documento, Version. Básicamente: en el sistema existen Proyectos, cada Proyecto tiene un conjunto de Procesos, y cada Proceso tiene un conjunto de Documentos. A su vez cada Documento tiene un conjunto de Versiones, la cual la última versión del conjunto es la actual.
Los Roles se asigna a los Procesos de la siguiente manera: se debe crear uno o varios GrupoProceso para cada Proceso. Luego a cada GrupoProceso se le asignan los Roles y los Permisos sobre los procesos. De esta forma un Proceso(P1) puede tener el GrupoProceso(adm), este GrupoProceso(adm) contiene los roles que serán administradores del proceso, y los permisos correspondientes de administración (Entrada, Continuar, Detener, Finalizar).
Los mismo sucede para los documentos, si bien como usuario estoy en varios procesos, pero no tengo los mismos permisos para todos los documentos de mis procesos. Al igual que los procesos, los documentos tienen GrupoDocumento, donde se configuran los roles y los permisos para estos roles.
Cuando un proceso o un documento cambia de estado, entonces se crea un evento que es enviado a todos los roles que tenga alguna responsabilidad sobre este nuevo estado.
Diagramas de Estado

Simulación y Prototipo
Esta es la ventana que le aparece el Rol luego de acceder al sistema.

La siguiente muestra los GrupoDocumento que tiene asignado este Rol.

La siguiente imagen muestra el GrupoDocumento “Administrar Documentos”.

Para mostrar parte del código de la simulación usaremos el ejemplo de Publicar una nueva Versión de un Documento. La siguiente imagen muestra una Version a punto de ser publicada.
Ahora veremos el código que se encarga de mostrar o no el botón de “Publicar” al usuario actual del sistema. En el UML Almighty a cada método se le puede asignar otro método que indica si el primero puede ser ejecutado o no por el usuario actual del sistema.
En la siguiente imagen se muestra el ambiente de desarrollo del UML Almighty, y los métodos “publicar” y “puedePublicar:” de la clase Version.

Aquí se esta indicando que el botón ”Publicar” (que ejecuta el método #publicar:) será dibujado en la página web solamente si el método #puedePublicarVersion: devuelve “true“ cuando se ejecute.
Estamos en la clase Version que es la responsable de publicar la nueva Version del Documento. El argumento unRol es pasado como parámetro por el UML Almighty a la hora de ejecutar el método. Para poder publicar la versión, esta tiene que estar en estado “Aprobada” y ademas el usuario actual unRol debe tener permisos para realizar esta operación, de lo contrario el botón no aparece.
Reglas:
* Si la Version no tiene estado actual no se puede publicar.
* Si la Version esta en un estado diferente al de “Aprobacion” no se puede publicar.
- Se obtienen los GrupoDocumento (de este documento) en los que participa unRol.
* Si algún GrupoDocumento de unRol incluye el permiso Publicar –> el botón se dibuja en la página.
Este código se ejecuta cada vez que algún usuario entra en la página de alguna Version.
Ahora veremos el código para publicar una Versión
Reglas:
* Se crea la nueva la instancia del nuevo estado “Publicado”.
* Se pone este nuevo estado como el actual (es decir, se agrega a la colección de estados en la última posicion).
* Se envían los eventos a los usuarios correspondientes.
Código de como se cambia el estado actual

Este método es bastante sencillo, asigna la Version y Rol al nuevo EstadoDocumento. Agrega el estado a la colección de estados en la última posición, de esta forma el nuevo estado queda como actual.
Código de como se envían los eventos
Este método es un poco más complicado que el anterior.
Reglas:
* Se crea el Evento y se inicializa. Se le asigna al Evento el documento y version correspondiente, así como el estado y el permiso.
* La reglas siguientes son más complejas. Se separan en:
+ documento in: GrupoDocumento select: []. “[] – bloque de código”
+ eachGrupoDoc any: PermisoDocumento satisfy: []. “[] – bloque de código”
El primer mensaje itera sobre todos los GrupoDocumento de la Version, y selecciona solamente los GrupoDocumento que devuelvan “true” cuando se evalúa el bloque interno.
El bloque interno en este caso es el segundo mensaje #any:satisfy:, y devuelve “true” cuando al menos una de sus evaluaciones internas devuelve “true” (diferente de #all:satisfy:, donde todas tienen que ser true).
Por lo que [gruposConPermisos] son todos los GrupoDocumento que el tienen un permiso igual al permiso pasado por parametro <unPermiso>.
* Por último se agrega el Evento a todos los usuarios de los GrupoDocumento anteriores.
Conclusión
Con esta simulación nuestro cliente llego a la etapa de desarrollo 100% seguro de que su diseño funciona, hace lo esperado y además es lo que quiere su cliente, ya que este participo de la simulación y el diseño del prototipo.
