Integrating Decision Tables and Executable Statemachines

Enterprise Architect provides extensive modelling of decision tables via the DMN 1.2 MDG. Decsion Tables can be used to model business rules of any complexity in a concise and understandable way. These decsion table models can be simulated using mutple input data sets to ttes the business rules. Once tested program code, such as Java, can be generated for use in applications.

Enterprise Architect also provdes modelling and simulation of state machines. State machines model the dynamic behaviour of applications. 

At the recent EA User Group 2022 meeting held in Reading UK, I presented how decision tables can be integrated with state machines to provide a simulated model of the dynamic behaviour invoking business rules. The example used was for the application for a car insuarbnce quotation. The business rules for determining the insurance premium based upon certain inputs were modelled as a decsion table, and the dynamic process of applying for a quotation was modelled using a UML executable state machine. The language used for code generation in both cases was Java.

To supplement this presentation I have created a comprehensive step-by-step tutorial which is far too long to reproduce here, therefore this step-by-step guide is provided as a download.

I hope you find the step-by-step guide a useful aid to using this very useful feature of Enterprise Architect. The example has been implemented and tested in EA v 15.2 and EA v 16.

Phil Chudley

Dunstan Thomas

This email address is being protected from spambots. You need JavaScript enabled to view it.

How to Set the Default Language for a New Model Repository

Overview

written by Phil Chudley, Principle Consultant at Dunstan Thomas Consulting

A question I am asked quite often is "how can set the default language to a new repository, other than Java".

As far as I know there is no global EA prefernce to acheive this, so most EA users would

1. Create a new local repository
2. Make the Code Engineering toolbar visible if not already visible
3. Change the language to <none>, or some language other than Java

I tend to use the language setting of <none>, this article describes a method of acheiving the objective of having a default language other than Java preset for all future new local repositories.

Method

EA iis installed by default into the directory C:\Program Files (x86)\Sparx Systems and in this folder are three repositories all named EABase. Theses three repositories are for *.eap,*.eapx and *.feap repositories. When a new local repository is created one of these EABase repositoriesis copied into the user folder and renamed according to the name entered by the user.

To set a default language, we siimply:

1. Open a EABase repository in EA
2. Change the Code Engineering language to your preference
3. Close EA

Sounds simple? But there's a catch, since the EABase repositories are located C:\Program Files (x86)\Sparx Systems they cannot be opend for writing in EA!

No problem:

1. Copy all three EABase repositories to a directory of your choice
2. Open one of these repositories in EA
3. Set the Code Engineering language to your preference
4. Repeat steps 2 and 3 for the remaining 2 EABase repositories
5. Copy the three EABase repositories back to C:\Program Files (x86)\Sparx Systems Please note, you will need to have Adminstrator privilege to do this

Now, whenever a new local repository is created it will have the Code Engineering language that you set in the steps above.

Summary

I hope you find the above a useful trick, but there is more you can do with this trick. As the EABase repositories are copied to form your new local repository, then here are some additional changes that you might like to make to the EABase repositories:

1. Modify any General Types like Status, Priority
2. Create a default structure other than just a Model Root Node
3. Import useful resources such as scripts, documentation templates

In fact anyhthing that is repository based that you wish to include as standard in all your new local repositories.

Yes, the only condition of this working is that you must have Adminstrator privilege to achieve the copy back to C:\Program Files (x86)\Sparx Systems (or know someone who has got Adminstrator privilege for your workstation / lapto), but it is a useful trick to know,

Phil Chudley

Principle Consultant

Dunstan Thomas Consulting

follow me on Twiter @SparxEAGuru

Creating Navigable Models for HTML Publication

By Phil Chudley, Prinicipal Consultant at Dunstan Thomas Consulting

Background

Once a model has been developed in Enterprise Architect, it can be shared to users who do not have Enterprise Architect by publishing the model to HTML where the model can be viewed in a browser.

However, out of the box, this common method of publication to HTML suffers from the following problems:

1. Unless the model is organised very logically, the non-Enterprise Architect user can struggle to find their way around the model.
2. The presence of the Project Browser tree in the Web Page(s), can be confusing to the non-Enterprise Architect user where too much information is provided.

In reality, the non-Enterprise Architect user is most interested in the diagrams, and ideally would wish to navigate the model using these diagrams.

Navigation techniques are already built-in to Enterprise Architect, namely:

• Composite Elements.
• Hyperlinks.
• Navigation Cells.

If a model is built so that it can be navigated purely via diagrams using the techniques above, then the presence of the project browser tree in the HTML publication is rather irrelevant. The question is how can this project browser tree be removed from the web pages? The answer can be found in this article.

Creating a Model that can be Navigable via Diagrams

This section uses built-in features of Enterprise Architect. For an example, let us consider the following model that has been built already in Enterprise Architect:

This model is a “typical” UML model supplemented with Requirements, User Interface Screens and a Dashboard. As its stands it is quite difficult to navigate for the non-Enterprise Architect user, therefore we add to the model the following:

• Table of Contents diagrams that contain Navigation Cells to other diagrams.

A navigation cell is created very easily by:

1. Creating a diagram (I use the EA Extended Custom diagram type) in a Package.
2. Navigate to a diagram.
3. Drag and drop this diagram to the diagram created in step 1) and choose Navigation Cell from the list of options.
4. Choose an appropriate image.

For the model illustrated above, we begin by:

1. Adding a View named TOC (or Table of Contents) to the model root.
2. Move this to be the first view in the model.
3. Add to this View a diagram (for example an EA Extended Custom diagram type).

This is illustrated below:

The next step is to add navigation cells to this newly created diagram and there are two basic approaches:

1. Add a navigation cell for each diagram within the model to the diagram named TOC.
2. Create “TOC” diagrams for each view / package and created navigation cells for these lower level TOC diagrams.

Which option you use depends upon the complexity of the model, in this example I used option 2) which resulted in the TOC diagram being populated with navigation cells as shown below:

As an example of a lower level TOC diagram, consider the package named User Interface which is shown expanded below:

Each of the packages inside User Interface has a User Interface diagram. Generally I place one diagram in one package.

Creating navigation cells for these diagrams yields the TOC diagram for the User Interface package as shown below:

This process is repeated for other Views and Packages.

We now have a model that is navigable entirely via diagrams commencing with the top level TOC diagram.

In this example I created a “back link” to the level above, using a hyperlink and setting the Behavior property Printable to be false.

The final step is to ensure that when the model opens, the TOC diagram is displayed by default. This is achieved by:

1. Opening the TOC diagram.
2. Select the Layout Ribbon.
3. Select Manage → Set as Model Default.

Publishing to HTML

The result of selecting the Model Root node and using the Publish to HTML function, out of the box is as shown below:

The modifications we are going to make are as follows:

1. Change the header image.
2. Remove the Project and Advanced information from the bottom of the diagram.
3. Remove the Project Browser Navigation tree.

Making the Modifications

Changing the Header Image

This is very easy to do, as there is an option on the HTML generation dialog to navigate to and select an alternate image. However, there is a “gottcha”. So that the chosen image will fit in the frame at the top of the HTML page, it must be less than or equal to 60px in height.

In this section, I will show you how to customize the HTML output so that the frame resizes to fit the height of your image.

The following steps are used:

1. Discover the height of your image (this can be achieved with Windows File Explorer by positioning the mouse on the image file and examining the tool tip that displays). The image that I am going to use has a height of 56px.
2. Using the Resources View, open the section named Web Style Templates, right-click and select Create New HTML Template.
3. Enter a suitable name and click OK.
4. In the dialog that displays the list of Templates, select the template named CSS – Main.
5. Scroll down to line 248 as shown below:
   
6. Change line 252 to be the height of your image + 1, in my example this is 57.
7. Similarly, change line 259 to be the height of your image, in my example this is 56:
   
8. Click Save.

Remove the Project and Advanced information from the bottom of the diagram

The following steps are used, assuming that the dialog showing the HTML Templates is still visible, if not, right click your Web Style Template in the resources and select Modify HTML Template:

1. Select the Template named Body – Diagram:
   
2. Delete lines 13 through 32 inclusive:
   
3. Click Save.

Remove the Project Browser Navigation tree

Saving the best for last, our final modification is to remove the Project Browser Tree. To achieve this the Javascript Template needs modification as follows:

1. Select the Template named Javascript:
   
2. Scroll down to line 520 which should be the function named resizePage().
3. Scroll down to line 549 and replace this line with the following lines of Javascript:
   
4. Scroll back to line 85 which should be the function named initLoad(src, toc, home).
5. Insert the following line of Javascript between lines 128 and 129:
   
6. As a check the modification above should be as shown below:
   
7. Click Save and then Click Close.

The Result

To view the effect of the changes, re-publish the model to HTML this time selecting your Web Style Template and navigating to your Image:

The result as shown in the Browser is as shown below:

Conclusion

The next step would be to modify the HTML templates such that when the user clicks an element which does not link to a diagram, nothing happens rather than the default behavior of displaying an element properties screen. Alternatively, the element properties screen could be modified to display just name and notes for example. Once I have worked out how to do this, I will share this in another tutorial.

Phil Chudley
Principal Consultant
Dunstan Thomas Consulting
Follow me on Twitter @SparxEAGuru

Using Stereotyped Relationships to Define Quicklink rules

by Phillip Chudley, Principal Consultant at Dunstan Thomas Consulting

Background

One of my favourite features of Enterprise Architect (EA) is the ability to define your own meta-models using MDG technology, and over the many years I have used Enterprise Architect, I have developed many such MDGs and have shared my experiences in their development at numerous EA User Group meetings.

However there has always been a “sting in the tail” with developing an MDG in the respect of defining Quicklink rules. These were (and can still be) defined using a spreadsheet where each row defined a connector between two elements for a specific diagram. Not only was this tedious, but also prone to error and not that intuitive.

With the arrival of EA version 14 and in particularEnterprise Architect version 14.1 a new method of defining Quicklink rules was introduced. This new method uses Meta-relationship, Stereotyped relationship and metaconstraint.

In this article I will explain through a simple example MDG how to use Stereotyped relationships to define Quicklink rules.

Example Meta-model

For this example a simple three element meta-model will be used and this is illustrated below together with the relationships that are defined between these three elements:

Plan of Attack

To experiment with the new features of MDGs, the following steps were used:

1. Create a locally hosted model repository for the MDG model.
2. Using the MDG Builder structure, model the profile, (including any Tagged Values and Shapescripts), model the custom toolbox(es) and model custom diagram(s) connecting them with the appropriate toolboxes.
3. Generate the MDG.
4. Test the MDG.
5. Using a separate diagram model the view specifications.
6. Regenerate the MDG.
7. Test the view specifications.
8. Using a separate diagram model Quicklink definitions using Meta-relationships / Stereotyped relationships.
9. Regenerate the MDG.
10. Test the Quicklink definitions.

Steps 1) through 4) are pretty much standard for the development of an MDG and hence will not be described in detail, however some important inclusions and “gotchas” will be described.

The complete EA Model and the MDG XML file are available for download.

The MDG Profile Model

The diagram below illustrates the profile model for the elements and relationships defined in the meta-model shown previously:

Notes

The following should be noted:

1. The attribute named _HideUmlLinks of type Boolean and default value of True is necessary so as to prevent all the UML Quicklinks from the metaclass (in this case Class) being listed with your defined Quicklink definitions. This will have no effect until such Quicklink definitions have been included in the profile model. This attribute is added manually to the metaclass.
2. The attributes named _MeaningForwards and _MeaningBackwoods for the metaclasses Association, Generalization and Composition are used to provide names for the Quicklink definitions. That is the names that will appear in the Quicklink menu. _MeaningForwards is the Quicklink name for Source to Target, whereas _MeaningBackwards is the Quicklink name for Target to Source. These values, along with the attributes named _linestyle and _direction can be defined using the Profile Helpers.
3. Tagged Values named DateIndentified (type Date) and CauseDetails (type Memo) have been defined and added to the stereotypes Problem and Cause.
4. All three elements have a basic Shapescript (shown in the table below in case you would like to create the MDG from scratch), and have Toolbox / Project Browser icons defined. These icons are optional, but are included in the MDG XML file available for download, however if you use the EA model, then you will have to exclude the icons in the stereotyped elements and toolbox prior to generating the MDG.
   
   
5. EA version 14.0 moved many of the familiar right-click menu options to the Ribbons, and generating profiles for packages and diagrams is no exception. To generate a profile from a package or diagram:
   • For a Profile Package:
     • Select the Package containing the profile in the Project Browser.
     • Select Publish → Publish Package as UML Profile from the Technologies section of the SPECIALIZE ribbon.
   • For a Diagram that models a custom diagram, or custom toolbox:
     • Open the diagram containing the model of the custom diagram or custom toolbox.
     • Select Publish → Publish Diagram as UML Profile from the Technologies section of the SPECIALIZE ribbon.
     • When the dialog opens, there is no value in the Version text field. Due to an issue in EA 14.1, this must have a value (I usually set this to the same value as the version used when generating the MDG). Failure to enter a value for the version, will result in the XML files for the diagram profiles to be missing from the MDG generation dialogs.

The following diagrams illustrate the models for a single custom toolbox and a custom diagram provided for reference for the MDG example used in this article.

Example; Custom Toolbox

Example; Custom Diagram

The attributes in the Diagam_Custom metaclass are:

• Show Qualifiers & Visibility Indicators – False
• Show Tagged Values Compartment – True
• Hide Attributes Compartment – True
• Hide Operations Compartment – True
• Hide Connector Stereotype Labels – True

NOTE: Due to the simple Shapescript used for the elements within the profile, the attributes for the compartment visibility will have no effect.

Using Stereotyped relationships to Define Quicklink Rules

In Enterprise Architect version 14, two new items were added to the development of MDGs, these are:

• Meta-relationship – used to define a Quicklink rule between stereotyped elements defined in an MDG using UML Connectors.
• Stereotyped relationship - used to define a Quicklink rule between stereotyped elements defined in an MDG using Stereotyped Connectors defined in the MDG

In my experiments with these new items, I discovered that Meta-relationships worked when used to defined Quicklink rules between different MDG stereotypes, but did not appear to work when used to define Quicklink rules between the same MDG stereotype (that is a self-relationship). Hence the reason why in this example I have defined MDG stereotypes for Composition and Generalization and used Stereotyped relationships exclusively to defined Quicklink rules.

Defining the Quicklink Rules

Using a new Profile diagram with the same package as where the MDG Profile is defined, simply:

• • Re-use the MDG Stereotype element (or elements) for which a relationships is required.
  • Using the Metamodel section of the Profile Toolbox create a relationship for each valid connection between these MDG Stereotyped elements, including any self-relationships.
  • Set a tagged value named stereotype to the name of the MDG stereotyped relationship that is valid in this context.

The diagram for the Meta-model used in this diagram is as shown below:

The profile package is then saved as a UML Profile and the MDG re-generated. Upon testing, and using the Quicklink the result is as shown in the example below:

If, when using the Quicklink an attempt is made to create a connection between any two elements that do not have a Stereotyped-relationship defined (as between Cause and Solution), no connector will be allowed.

NOTE: The rules defined using Stereotyped-relationships only apply when using the Quicklinker, these rules can be broken by using any relationships visible in the toolbox.

Therefore, to fully enforce relationship rules, define all relationships using Stereotyped-relationships and do not provide any relationships in the diagram toolbox.

Conclusion

Does using Stereotyped-relationships ease the pain of Quicklink defintions? In my opinion, most definitely yes!

Accompanying this tutorial, is a zip file containing:

• The model used to define the example used in this tutorial. This is an .eapx file.
• The MDG XML file as generated from the model.

I hope this example is useful to all those of you who develop MDGs for Enterprise Architect and I welcome your feedback.

My next article will explore the other new features for MDGs, namely:

• View Specifications
• Metaconstraints

Follow me on Twitter @SparxEAGuru

Using Keyboard Shortcuts with Enterprise Architect Extension Menus

by Phil Chudley, Principal Consultant at Dunstan Thomas Consulting

Background

Extensions written for Enterprise Architect often define menus to invoke functionality, and although a short cut of the form Alt+character can be defined by prefixing the character in the menu option with &, this does not work as a keyboard shortcut.

After digging around a bit, I have discovered a work-around so that defined keyboard shortcuts can invoke menu options.

In this article I will explain through a simple example how to use this work-around in your EA Extension. This example has been tested on EA version 13.5 and EA version 14.

Plan of Attack

The logic behind this workaround is summarised as follows:

• Encapsulate all functionality that is invoked from the menu options in a Manager class, with public methods. This allows the functionality to be invoked from the menu and from the keyboard shortcut.
• Define your keyboard shortcut, ideally selecting combinations that are not already in use by EA. These are of the form of:
  • Modifier(s) + key – for example Alt+1 or Ctrl+Alt+D
• All these keyboard shortcuts are registered with a keyboard Hook class associated with a Windows Form class.
• A key pressed event handler is added to the keyboard Hook class.
• The Windows Form class is never displayed, but catches the key pressed event. The event can be tested against the keyboard shortcut keys that have been registered and the corresponding menu function invoked using the Menu Manager class.

Overview of the Classes Defined in the Example

The workaround uses several classes to provide the keyboard shortcut functionality:

• Main – the central class that is always required for all EA Extensions
• MenuManager – a C# class that provides the functionality for all menu options
• AboutBox – a standard Windows AboutBox Form class
• HotKeyForm – a Windows Form class defining an empty window, which is never displayed, but whose sole purpose is to catch the keyboard event raised when pressing the keyboard shortkey combination, and to invoke the Extension’s menu functionality.
• KeyBoardHook – a C# class which registers the keyboard shortcuts, and raises the keyboard event when the keyboard shortcut keys are pressed.
• KeyPressedEventArgs – a C# class that encapsulates the event after the keyboard shortcut keys have been pressed. (Defined within KeyBoardHook)

The following class diagram illustrates the design of the example:

Detail & Code of the Classes

Main

Description

This class provides the entry point to all EA Extensions and is where the developer will define:

• Menu text for the extensions menus
• Global references to other classes, including EA.Repository
• Handle the appropriate EA broadcast events for;
  • the initial connection to the Extension made by EA
  • the menu contents
  • menu enable / disable check / uncheck
  • menu click
  • EA disconnecting from the Extension
• Helper methods to provide functionality such as if a model repository is loaded.
• Code to handle any events broadcast by EA.

In this example, there are four menu options which provide very basic functionality:

• Option 1 – displays a Message Box
• Option 2 – displays a Message Box
• Option 3 – displays a Message Box
• About – displays the About Box

This functionality is available whether or not a model repository has been loaded and can be invoked via the menu, or by pressing the defined keyboard shortcut key combination.

Code

In the method EA_Connect, the instantiation of HotKeyForm, registers the keyboard shortcuts and creates the form, its event and listener. An instantiation of the MenuManager class is also created.

MenuManager

Description

This class defines a public method for each menu option so that these can be invoked from the class Main (as shown above), and also from with the HotKeyForm (shown later).

Code

AboutBox

Description

For the purposes of this example, the class is the standard class that is provided by the C# .NET framework.

HotKeyForm

Description

This class is a Windows Form class and instantiates an instance of the KeyBoardHook class, adds an EventHandler for the KeyPressedEvent and registers each keyboard shortcut key combination with the KeyBoardHook instance.

Code

KeyBoardHook

Description

This class provides all the “wiring” between the registered keyboard shortcuts, and the keypressed event.

Code

Does it Work?

Absolutely! The only way to see that it works is to create the Extension and try it out. This could be achieved by adding the code above to you own extension, or using the attached zip file which contains:

• Visual Studio solution for classes used in the example
• MSI installer for the example

Please note that this example was built using Visual Studio 2017 and the .NET framework version 4.6.1

Next Steps

This simple example assumes all Extension menu options are enabled all of the time, I am working on a variation of this example to provide keyboard shortcuts which are active only if a menu option is enabled or checked, and not active when a menu option is disabled or unchecked.

I hope this example is useful to all those of you who develop extensions for EA and I welcome your feedback.

Follow me on Twitter @SparxEAGuru