DT Consulting Newsletter Issue 12; AMUSE
In this newsletter we provide an overview of a new Add-In called AMUSE for Enterprise Architect version 8.862.
An Overview of AMUSE
AMUSE (Advanced Modeling in UML with Simulation and Execution) is an Add-In for EA 8.0 Build 862 or EA 7.5 Build 850 or higher is required (EA Systems Engineering or Ultimate Edition) and extends the functionality of Enterprise Architect to provide the ability to execute workflows that have been modelled using UML State Machine Diagrams. This Add-In has been developed by LieberLieber (www.lieberlieber.com ) and is marketed as:
“Detecting issues early in the project lifecycle can save a lot of time and money. With AMUSE you can validate your Enterprise Architect UML Model to correct errors in your business workflow or application logic before your software engineers write a single line of code. You also can reuse the source code generated by AMUSE for your applications (C# supported in the standard package).
With AMUSE you can create models on any abstraction level and initiate testing in the very early project stages. By integrating mock-objects, existing applications and external hardware, even highly complex behaviors can be validated.“
A Worked Example
The most appropriate method to describe the functionality of AMUSE is to work through a simple example. Although AMUSE can integrate with .NET dll files, referred to a .NET Mocks, this example takes a somewhat language independent approach.
The example we will be using to illustrate AMUSE is the verification of a workflow designed to model the following situation:
A user is required to provide authentication details consisting of a User Name and a Password. These will be then validated against stored information and the user will be either authenticated or denied access.
Our first stage would be to consider the business rules surrounding this simple example. These are:
1) The user name is alphanumeric of no fixed length
2) The password again is alphanumeric, but must be of at least 8 characters in length
Analysing the above yields three possible error situations:
1) The user name is invalid (does not exist)
2) The password is of the incorrect length
3) The password is incorrect
Using this information we can construct a simple workflow, modelled as a UML State Machine diagram, The key points to bear in mind when modelling workflows as State Machines intending them to be simulated using AMUSE is to use the following:
1) The workflow itself is modelled as a UML Class element which has its language property set to C#
2) A State Machine is added to this class as an immediate child element, this State Machine element will have a child UML State Machine Diagram where the workflow can be modelled.
3) A UML State element is used for every step within the workflow
4) A Transition is used between states (as usual)
5) If a state is simulating a user input, then attach a trigger to the transition to model each possible response from the user. For example, if a User Dialog has two buttons “SUBMIT” and “CANCEL” then two triggers would be created and assigned to two corresponding transitions.
6) Any workflow state data (for example any data the user enters, and simulated stored system data) must be represented as public Attributes for the class created in step 1)
7) The action performed (if any) performed at each step within the workflow (for example a simple validation of user data), is represented as public Operations for the class created in step1)
8) These operations are then linked (as behaviour) to corresponding operations added to the appropriate State elements.
The above infers (somewhat incorrectly), that you would have to be a C# guru in order to use AMUSE effectively, whilst is certainly helps to have some C# programming knowledge; it is by no means essential. The tutorial that ships with AMUSE walks you through a simple example and introduces (as indeed does this newsletter) some very common repeatable code that you can use and modify for your own simulations.
The screen shot below shows the starting position, after a project has been created; the workflow class and associated State Machine have been created:
The Workflow Modelled
Using the business rules above, the following workflow as a UML State Machine Diagram can be created:
Note we have only a single state to display one of the three possible errors that could occur. This method is to be preferred over one state for each possible error.
We now add triggers for the two possible transitions fromDisplayLoginForm, these correspond to two buttons on the eventual Login Dialog
Next, we address the issue of what state data we need to add to the class, analysing the workflow requirements we need the following:
- StoredUserName – string
- StoredPassword – string
- EnteredUserName – string
- EnteredPassword – string
When adding these as attributes to the workflow class we will also need to:
1) Store a “hardcoded” value for the StoredUserName and StoredPassword
2) Initialise the EnteredUserName and EnteredPassword to an empty string
The nest task is to determine how the state machine will decide which of the two possible transitions from the stateValidateUser. We could use triggers, but a more “automated” approach would to be use a guard constraint on each transition. Each guard constraint is represented by an attribute (of type bool) within the workflow class.
After these additions we have:
Now for the “techie” part! We add the operations. A simple way to display the progress (on our workflow the states begin with “Display”), is to pop-up a simple message box. The C# command for this is:
Where <message> is a string (enclosed in double quotes) representing the message to be displayed, and <title> is the title of the message box.
For example, to simulate the Login Dialog we could use the following:
System.Windows.Forms.MessageBox.Show(“Please enter your user name and password”, “Login”);
This is entered as an operation / behaviour / initial code for the workflow class, as shown below:
This operation can be replicated in the corresponding state by adding an operation to the state and linking its behaviour as shown below:
Finally, our last step is to add an operation that will simulate the validation of the data entered by the user. This is an operation added to the workflow class and then linked to a corresponding operation in the state ValidateUser.
Which results is our final model:
Running the Simulation
To run the simulation, use the View menu and activate the Add-Ins window.
The current State Machine can then be added to the Add-Ins window as shown below:
Clicking the Green Triangle will compile the workflow (hopefully there will be no errors), and the simulation will begin. The simulation will execute the operation showLogin and the message box will display.
After clicking the OK button, simulation will continue and then halt, waiting the trigger to be fired (simulating the user clicking a button on the Login Form)
The simulation now offers the opportunity to “fire a trigger” and / or enter some user data.
The screen shot below, shows the effect of entering an unknown user name:
After clicking OK the workflow loops back to the initial state, at which point other combinations of data can be entered to verify all possible displays.
In this newsletter we have described how you add workflow simulation to your modelling by using a new Add-In for Enterprise Architect, namely AMUSE. If this has whetted your appetite why not give it a trial run?