Open Source "U-Fabrik": UML Simulation, Prototyping and more

July 28, 2010

UML Simulation and Execution of a Workflow for Documents and Processes

Filed under: Executable UML, OOP, UML, UML Simulation — umlalmighty @ 4:35 pm


The next simulation shows part of a Process and Document Workflow for one of our customers.

Since this will be a proprietary application will not release the final simulation but an intermediate simulation.

The system aims to manage the process and documents of the company.

Each user (or role) can participate in more of a business process, and these user processes may belong to different projects.

The general idea is when a Role access the system he has the view of his proccesses, documents (MS Office) and events associated to both. For example: if a Role finished editing a document (now the document is in Revision state) and other Role has the permission to Aprove (for this document) then this Event must be listed in the Role Event list.  So each Role has a view of what is going on with his processes and documents.

General Rules

* Administrators (or project leaders) assign other Roles to different Processes.

* The Processes have different permissions for the Roles: Access, Resume, Stop and Terminate. Depending on the permissions of the Role, the available commands (buttons) in the web page for that Role in that Process.

*  Role documents depend on the Processes the Role is assigned, and permissions on these Documents.

* Document Permissions: Access, Approve, Edit, Publish, Review.

Benefits of Simulation

Since the system has some level of complexity, many failures (or omissions) in the design are not detected. Only when developers start implementing and these flaws are beginning to emerge.

The more complex the system more prone to design flaws. These failures have different characteristics, is very difficult to list all. A design can have minor flaws and major faults. Among the minor flaws can be found: omission of attributes of a class, an unspecified relationship between classes, classes that do not exist but are necessary, inconsistency between classes, and so on…

NO major faults can be detected (or at least very difficult to do it) until the implementation has started.

This is because the design is specified in static documentation, for example, word documents, classes diagrams, use cases, sequence diagrams, state diagrams, and so on. Although this documentation is essential in any project, we must also recognize that it is “dead letter”.

For “dead letter” must be understood that it is something static, and it is impossible for someone to consider all cases that may occur in a dynamic system from static documents (although we know that this documentation is essential).

This is the reason why all projects have several stages of design then develop, re-design then develop, re-disign then develop, and so on. This activity of “trial and error” between design and development is extremely expensive.

This is where the simulation is a fundamental step to ensure the quality of a design, with a simulation we can completely avoid (or at a large percentage), this seesaw between design and development.

The simulation gives a full picture of the problems with a design, and design errors are 100% specified in the simulation.

This simulation provides project stakeholders (and actors) with valuable information.

If we add to the simulation a prototype -> we are in great advantage over the traditional design.

Prototyping allows customers to have a better view of what will be his system, allowing the customer to better specify it’s requirements, this results in cost savings (which is generally very difficult to quantify).

Before describing the system we will show the final conclusion

With this simulation, our customer came to the stage of development 100% sure that the design works, and it works as expected and is what the customer wants. Because the customer participated in the simulation and the design of the prototype.

The cost saving is big because we avoid the eternal iteration between re-desing –> develop –> re-design –> develop ….

Class Diagram

Main classes: Role, Project, Document, DocVersion. The system has Projects, each Project has a set of Processes and each Process has a set of Documents. Each Document can have more that one DocVersion, where the last DocVersion is the current version. Each DocVersion has an MSOffice file attached.

Roles are assigned to Processes as follows: ProcessGroup are create for each Process, and each ProcessGroup has a set of Roles and a set of Permission for these Roles. For example: a Process named (Quality Test) can have a ProcessGroup named (Managers) where the permissions for the group are: Access, Resume, Stop, Terminate. All roles assigned to this process group will these permissions.

It is almost the same for Documents, a Role have access to it’s Documents through his Processes. But may be the Role has different permissions for different Documents, depending on the DocumentGroup configuration for that document. A DocumentGroup has set of Roles and a set of permissions for these Roles.

When a Process or a Document changes state, then we create a proper Event that is sent to all Roles that have some responsibility for this new state.

State Diagrams

Simulation and Prototype

The next picture shows the web page after a Role access the system. In this case a ProjectLeader.

The next picture shows the DocumentGroups of the current Role (admin). This Role (admin) has 3 DocumentGroups:

The next picture shows the DocumentGroup (“Administrator”) with it’s permissions:

In order to show the code of the Simulation we are going to use TerminateEdition operation, where a DocVersion goes from Editing state to Review state.

The next picture shows the web page for a DocVersion in Editing state.

The next picture shows how UML Almighty is capable of display these buttons to some Roles and hide it from others.

The “TerminateEdition:” button is NOT available to all Roles. In order to achieve this UML Almighty allows to associate a UML method that is executed in order to know if the button should be displayed or not.  If this “show/hide method” answer “true” then the button is displayed, otherwise the button is not displayed.

In this case the “TerminateEdition:” has the UML methodcanTerminateEdition:” as show/hide method, before generating the button for the command, UML Almighty executes #canTerminateEdition: (the argument is the current loged role).

The picture above shows that #terminateEdition: method is only executed if #canTerminateEdition: answer “true“.

The next picture shows the simulation code for #canTerminateEdition: UML method.

This UML method has aRole as argument, this role is the current loged user in the Web Application (the argument is sent automatically by UML Almighty).

The picture above show the UML ClassDocVersion– of the class diagram and the UML method #canTerminateEdition: of this class.

As we said the argument –aRole– is sent automatically by UML Almighty.

In order to Terminate a Edition there are several rules, as we can see in the simulation code:

* The –wordDocument– must be initialized.

* The –currentState– must be initialized.

* The –currentState– must be Editing. Otherwise the button has non sense.

* At least one of the DocumentGroup of the Document must includes aRole and must includes the Edit permission.

The next picture shows the simulation code to terminate the editing state of a DocVersion of a Document.


* We create the next state (check State Diagrams).

* We set this new state as the current state.

* We create and send an Event to relevant roles (roles with some permission on this new state)

The next picture shows the simulation code to set a new current state.

The UML method above is very simple. Assing the –DocVersion– and –aRole– to the new state –aDocumentState-. Adds the new state to the collection of states where the last element of the collection is the current state.

The next picture shows a UML method to send the Event to relevant roles, this method is more complex.


* We create a new DocumentEvent. We set the Document, DocVersion and Permission to the new DocumentEvent.

The following rules are a more complex and can be divided in two:

1. document in: DocumentGroup select: […..]

2. eachDocGroup any: DocumentPermission satisfy: […..]

The rule 1 iterate over all DocumentGroups of the document. And selects only the DocumentGroups that answer true to the second rule.

The second (2) rule iterate over the DocumentPermission of each DocumentGroup. And answer true only if ANY of it’s the DocumentPermission is equal to aPermission.

* The last rule only iterate over all roles of the selected collection of DocumentGroups and adds the new DocumentEvent.


With this simulation, our customer came to the stage of development 100% sure that the design works, and it works as expected and is what the customer wants. Because the customer participated in the simulation and the design of the prototype.

The cost saving is big because we avoid the eternal iteration between re-desing –> develop –> re-design –> develop ….


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: