Open Source "UML Almighty": Executable UML, Simulation, Prototyping and more

February 19, 2013

Mapping Web users with UML users

Filed under: Executable UML, OOP, UML, UML Simulation — Tags: — umlalmighty @ 1:00 pm

In order to map the users of my UML class diagram with the UML Almighty Web Server we have to follow the next steps:
1. Create users of my UML application. It will be something like:
security wokspace 01
Rememver that User class has to be defined as the Login Manager Class.

2. Now we have to Map (or replicate) the User “John” with  in the UML Almighty Web Server.
2.1. Login with User: admin password: password.
2.2. Go to security settings
security 01

3. In the Security Settings add a New User (John), fill the data and press Save button

security 02
security 03

4. Goto Access Rights for John User
security 04

5. Now select UMLInstanceApp which is the Site Server for UML Almighty
security 05

6. Now we are in the UMLInstanceApp permissions for John
security 06

7. The last step is to Click in “Yes” to enable all grants to John. The user created in step 1.
security 07

February 13, 2013

System Reflection: New Virtual Machine class

Filed under: Uncategorized — Tags: — umlalmighty @ 1:27 pm

The Virtual Machine now has a new class named ParsedMethod. It can be used as follow:
ParsedMethod #for:in: where (#for:) is the message to parser and (#in:) is the class of the message, in this case: ParseMethod for: ‘archivar:’ in: Notificacion.

With the instance of the ParsedMethod we can get reflexive information about that message.
The following picture shows all reflexive methods of ParseMethod class.




UML Almighty now support Transaction Log

Filed under: Uncategorized — umlalmighty @ 1:04 pm

The new feature of UML Almighty is the new Transaction Log. The Transaction Log when enabled stores all messages sent by the Virtual Machine.
The Log is very usefull and can be used with the breakpoints when developing complex simulations. Now errors can be tracked by breakpoints (halt message) and the log.
The transaction log can be used to measure the complexibility of a Simulation by the number of messages sent.
The following picture shows a pane with a disable transacion log.
Information stored in the transaction log:
* Receiver of the message
* Executed Method
* Time Stamp
* Parameters of the message
The following picture shows the enabled Transaction Log:

July 13, 2012

UML Almighty Manuals

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

What is UML Almighty?

UML Almighty is a tool that significantly extends the capabilities of the regular UML modeling tool such as Enterprise Architect®, Visual Paradigm®, and so on.

UML modeling tool build UML models and capture a static view (diagrams) of a system in order to understand the domain and define a solution.

To understand big systems from a static view is very difficult and make the design proper to misunderstanding and errors.

UML Almighty provides a dynamic view of an UML Model, simulating an entire UML model with desktop and web prototyping.

The use of UML Almighty simulation and prototyping capabilities in any stage of software development it makes the domain model much reliable, enhance communication capabilities between project’s actors, provide ways to detect early design mistakes, the documentation generation is much more accurate and has others benefit derived from systems simulation.

Usually a XMI 2.1 file version is exported from your preferred UML case tool (such as Enterprise Architect®, Visual Paradigm®, and so on) and imported into UML Almighty where the simulation and prototyping begins.

Here are the links to UML Almighty Documentation:

UML Architecture Manual

UML Development Environment Manual

UML Application Customization Manual

February 26, 2011

UML Almighty Source Code ready for Download – Open Source UML Simulation

Filed under: Executable UML, OOP, UML, UML Simulation — umlalmighty @ 10:32 pm

We have published the source code of UML Almighty for Dolphin
Professional version. Download it here

The Application (without source) installer is already for download at:
This is the Full Version of UML Almighty without any restriction.

We will wait until the release of Dolphin 6.2 Community Edition to publish
the Source Code for this version of Dolphin programming environment.

To login in the Web Simulation:
user: admin
password: password

There are two UML Models already installed in the UML Virtual Machine, both can be removed.

These models are examples on how to simulate UML applications.


February 9, 2011

Open Source License: The PostgreSQL Licence (TPL)

Filed under: Uncategorized — umlalmighty @ 11:13 pm

Finally we choose  The PostgreSQL Licence (TPL) for UML Almighty.

The PostgreSQL Licence (TPL)

[OSI Approved License]This is a template license. The body of the license starts at the end of this paragraph. To use it, say that it is The PostgreSQL License, and then substitute the copyright year and name of the copyright holder into the body of the licnese. Then put the license into a file called “LICENSE” in your software distribution.

Copyright (c) $YEAR, $ORGANIZATION

Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.



UML Almighty Web Site Update

In the following days we are going to update the web site with the new installer and the source code. To publish the source code is going to take a little more time because we have to remove the entire security license framework from the application.

To edit UML Almighty source code you need Dolphin Programming Environment (, the Dolphin Community Edition is free and you have the source code of the development environment itself.

UML Almighty Functionality

* It generates a Web/Desktop customizable application from a Class Diagram (imported through XMI file).

* Behavior can be programmed to each class in the diagram. So Sequence Diagrams can be executed.

* The generated application it is a Simulation (with customizable GUI prototype) and execution of the UML design.

* Ensure that 100% of the design can be implemented as designed.


February 6, 2011

Open Source Licence for UML Almighty

Filed under: Executable UML, OOP, UML, UML Simulation — umlalmighty @ 6:00 pm

We are analyzing which Open Source Licence suite better for UML Almighty. There are a lot of licence and some of them are not clear at all. For now we are choosing  The PostgreSQL Licence (TPL). Is not defined yet.

Main Goals

* Open source code (for future versions and modified versions)

* Modified versions and others distributions must have the same licence.

* Can NOT charge for the source code or the installer (for any version or modified version) .

* Can charge for services  (SaaS – software as a service).


* Programmers, Analyst, Software Engineer using UML in its projects.

* Companies that use UML in its projects.

* Universities to teach OPP.

* Software researchers of  (Virtual machines and meta programming).

What it does

* It generates a Web/Desktop customizable application from a Class Diagram (imported through XMI file).

* Behavior can be programmed to each class in the diagram. So Sequence Diagrams can be executed.

* The generated application it is a Simulation (with customizable GUI prototype) and execution of the UML design.

* Ensure that 100% of the design can be implemented as designed.



February 3, 2011

In the comming weeks UML Almighty is going to be open source

Filed under: Executable UML, OOP, UML, UML Simulation — umlalmighty @ 8:59 pm

Great News

In the comming weeks UML Almighty is going to be open source.

We are in the formal process to open source UML Almighty.
You are going to able to use it without any kind of restriction, in
any kind of project.

The UML Almighty it will be maintained economically through donations
and advertisement.

Wait for the official publication here and in the UML Almighty page.



September 30, 2010

Now UML Almighty supports SASE events framework

Filed under: Executable UML, UML, UML Simulation — umlalmighty @ 2:51 pm

Now UML Almighty supports SASE (self-addressed stamped envelope) events framework.

SASE is like Observer pattern with some differences.

In SASE a subscriber requests of a specific publisher that is should notify that subscriber by sending it  a specific message when an individual event occurs.

SASE facilitates the construiction of loosely coupled system in which the publishers of events need have no prior knowledge of the subcribers, and can have any number of subcribers.

In UML Almighty there are publishers and subscribers. Any UML object inside UML Almighty can be a publisher or a subscriber, this depend on the event configuration that we need.


Is an UML object that publish events and it has a collection of subscribers. Each time a publisher trigger and event then all subsribers are nottified with a specific message (the events can have arguements).


Is an UML object that has subscribed to an event of some publisher.


In the following image a Process change it’s state to [Running] state and the triggers an event [processResume:] to it’s subscribers with the argument [Date today]. All subscribers objects to this event will receive a notification of the event with the argument [Date today]. The publisher use one of the following messages to trigger events: [trigger:], [trigger:with:], [trigger:withArguments:], in this case we use [trigger:with:].

In the message [trigger:with:] the first arguments is the name of the event and the second is the argument of the event.

[self trigger: ‘eventNamewith: eventArgument].

In the following UML Script we can see how an object can subscribe to [processResume:] event. This is an example so we use a Script to show how it works, but the subscription code is always embebed in the application code.

In this case we have 1 publisher [cmmiProcess] and three subscribers [developer, projectLeader and processAdminsitrator].

The subscriber use the message [subscribeTo:eventHanlder:publisher:]  in order to subscribe to an event of a publisher.

The name of the event (in subscribeTo:eventHanlder:publisher:) must be equal to the name of [trigger:] message, see picture above.

When a publisher sends: [self trigger: ‘myUniqueEvent‘] then the subscriber must subscribe to ‘myUniqueEvent‘ using the same name.

[anObject subscribeTo: ‘myUniqueEventeventHandler: ‘processUniqueEventpublisher: anObject].

In the message [subscribeTo:eventHanlder:publisher:] the first argument is the name of the event (same as trigger: message), the second argument is the method of the subscriber that is executed when the event occurs and the last argument is the publisher object.

The events configuration can be changed while the simulation is running !

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 ….

Older Posts »

Blog at