Open Source "U-Fabrik": 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

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

July 5, 2010

UML Almighty new upgrade – The installer includes -Role based prototype-

Filed under: Executable UML, OOP, UML, UML Simulation — umlalmighty @ 7:27 pm

The new installer of UML Almighty includes -Role Based Prototype-

The constant simulation of a system along project’s life is critical for the success of the project. The simulation solves the esential problems of any IT project.  I mean communication between all project actors.

The Simulation promotes same view of the solution in all actor’s minds. This improves communication and understanding in the project.

The following picture depicts this problem in a very funny way…

June 30, 2010

UML Almighty now support “Rol Based Prototype”

Filed under: Executable UML, OOP, UML, UML Simulation — umlalmighty @ 7:38 pm

UML Almighty can customize a prototype in different ways. But once the prototype is customized, all users has the same view of the system.

Now UML Almighty support “Rol Based Prototype” that allows to define more than one view for the same UML class, depending on the loged user.

With this capability the UML Almighty can simulate any workflow of any UML system. The complexity of the workflow is not a problem, because it is simulated as behavior. To remember the prototype and simulation:

A web page that shows an UML object can:

  • Add/Remove simple aspects (integers, strings, dates, times, etc)
  • Add/Remove link aspects (for 1x relations- web links to other objetcts. The Account class Cuenta has a web link [link aspect] to it’s Bank).
  • Add/Remove collection aspects (for Nx relationsweb tabs with a collection of UML objects. . The Bank class has a web tab [collection aspect] with it’s Accounts)

As the aspects are based on behavior they are very flexible and powerful.

BUTfor the class Session in an ATM system, the GUI (web page) is the same for all users. This has changed with the new functionallity.

NOW UML Almighty can be customized to show different prototypes (for the same class) depending on the loged user.

Example with Session class:

The class Session

Attributes: lastMessage (char), number (char)

1x Relations: Rol, Card, ATM (each Session has a Rol, a Card and an ATM)

Nx Relations: Transaction (each Session has a collection of Transaction)

As you can see there are two different rols: User and Operator.

Now the class Session shows a GUI when the loged user is an Operator and shows another GUI when the loged user is an User.

The picture above shows the two Views for the same class Session. The command buttons also can be customized based on the loged user.

How UML Almighty ahieve this ?

Each GUI component can be associated to an UML show/hide method. When a component is about to be rendered then the UML Almighty executes the show/hide method sending the loged user as an argument.

Class: Session Method: [canDeposit:]

canDeposit: logedUser

“The [logedUser] is sent as an argument to the show/hide method. We ask to the loged user if it can deposit cash “

^logedUser canDeposit

Class: Operator Method: [canDeposit]


“The [Operator] can not Deposit


Class: User Method: [canDeposit]


“The [User]  can Deposit


The logic here is very simple (true or false) but it can be very complicated.

Class: User Method: [canDeposit]


“The [User]  can Deposi  if the [Card] not expired, and the [Bank] does not have the [Account] in the blak list

^session card notExpired and: [(session bank isAccountInBlackList: session card account) not]

June 17, 2010

UML Simulation Example with ATM Model – Prototype and Executable UML

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

In this example will see how to create a Simulation with UML Almighty using an ATM Model. (Check the Videos)

After installing the XMI file it take  10 minutes to finish the UML Almighty simulation (including the Prototype, the Executable UML and the UML Simulation itself).

The ATM Model is just a possible solution for this problem. The Simulation shows how different UML Diagrams fits with UML Almighty.

We will see two Use Cases in detail: ATM login and Perform a Deposit.

Use CaseATM Login

The User/Customer stars a new Session where the user name and password are entered.

If the entry data match the Card the Panel of Transactions is displayed.

Use Case: New Deposit

Here the Customer start a new Session (insert a card and type user name and password) in the ATM machine and then Deposit an amount of money to his Account.

UML Class Diagram – UML Model


ATM class represent the real ATM machines. Each User (actor) start a Session in an ATM machine. This relation is an association class ATMLogin.

The ATMLogin has the user name and password. After enter the user name a Session is created. With a Session the User can perform different Transactions.

Each Card belongs to an Account of a Bank. The Bank perform the different Transactions. To simulate the Card insertion a list of Cards is displayed to select one.

The ATM machine has Log of operations. The ATM bills are manage by the InnerCash handler.

Activity Diagram


The process starts when the User enter the user name and password. Then select a Card (to simulate Card insertion).

After login succed the User has the Panel of Transactions to perform different tasks.

In this panel the User can perform: a Deposit, a Transfer, a Query or a Withdrawal.

If confirmed the Transaction is performed and then Panel of Transactions is displayed again.

The User can perform another Transaction or logout. The transaction process will be shown in detail with Sequence Diagrams.

The following pictures shows the GUI: User and  Password which is the GUI for the instances of UML association class [ATMLogin].

This is the Web Page generated by UML Almighty for ATMLogin class, we named “GUI: User and Password” to the GUI of ATMLogin class.

From the GUI of ATMLogin the User can login into the ATM account.

Login Simulation Video

This is the Sequence Diagram for the Login process (check the video)

As we can see in the Sequence Diagram the login process returns (or starts) a new Session. From this Session the User can perform different operations.

Check the GUI: Panel of Transaction (picture above) to see the GUI for the instances of Session class.

The following is the Simulation Code for the UML Method [loginWith:] of Class ATMLogin

Method’s comments in green color.

As we can see in the Sequence Diagram the login process returns (or starts) a new Session.

When the user clicks Login button in the UML Almighty prompt a list of Cards (to simulate Card insertion).

When aCard is selected then [loginWith:] method is executed. This UML method belongs to ATMLogin class (check Sequence Diagram).

<aCard> argument is the Card selected by the User.

The method compares the password and user names of Card and ATMLogin (data entry in the web). If succed returns aSession (check simulation code).

This Session is displayed in other WebPage where the User can perform: Deposits, Transfers, and so on.

The following pictures shows the GUI: Panel of Transactions which is the GUI for the instances of UML class [Session].

New Deposit

The following picture shows the GUI for a Deposit. We named deposit GUI as GUI: Deposit Panel.

After data entry the User has to Confirm or Cancel the Deposit.

When the User click Save Object then the following page is displayed:

The following Sequence Diagram shows the Deposit process in the ATM system.

1. The User click NewDeposit in Panel of Transactions (SessionGUI)

2. A new Deposit is created and it is displayed in a Deposit Panel (DepositGUI). The User entry data (Deposit Panel 1).

3. The User Confirm or Cancel the Deposit (Deposit Panel 2)

4. The Bank perform the Transaction with Account (processDeposit:for: method).

5. The Panel of Transaction is displayed again with the result of last transaction. Now the User can perform other Transactions.

Simulation Code for the UML method #confirm in the Class Deposit

Simulation Code for the UML method #processDeposit:for: in the Class Bank

The following picture shows the Transaction result:

Simulation Video of a Deposit

Older Posts »

Blog at