Almost a year ago, as we embarked on what was to be the first of a series of lockdowns in the UK, I decided to learn some new skills that I could put into practice with Enterprise Architect (EA). I decided that I would like to learn how to create an MDG to assist not only my own modelling activities, but also those of the clients to which Dunstan Thomas provide consultancy services. Besides, with access to one of the best in the business (Phil “Chudders” Chudley) I had no excuse not to drink from an unending well of knowledge.
What is an MDG and what is a Meta Model?
An MDG, or Model Driven Generator Technology, to give it its official title, is the method in which Sparx Systems Enterprise Architect implements a Meta Model.
A Meta Model is the definition of symbols and relationships within a modelling notation. It also defines the rules to which those relationships must adhere.
Getting to it!
I set aside some time with Phil and followed him down the MDG rabbit hole, like my very own White Rabbit.
Over the course of a couple of days, I spent a lot of time with Phil absorbing his words of wisdom. It was then time to get practical as I, like many others, learn best by doing. Therefore, I set out to create what would become my first MDG. I wanted it to be something that would use again rather than it just be a learning aid, so I looked at my role within DT to see where I could make use of a tool not traditionally used to capture information via modelling. This led me looking into risk capture.
In addition to my role as Consultant, I also lend my hand to various other activities about the office (who remembers offices? I ‘member) and one such activity is performing the fire risk assessment for the office. This had me thinking, can I use EA with a custom MDG to model my risk assessments? The answer is of course yes…else, I would not be writing this article.
Unfortunately, COVID-19 threw a spanner in the works as we were very soon under lockdown conditions. This meant that with the office closed, I could not perform a test using the fire assessment documents, but as luck would have it, DT had to perform COVID-19 risk assessments for the office in the event that staff required access. I was able to use this data to test my ability to model a risk assessment.
This led to the creation of my first MDG, RiskResolve. It is a very simple MDG with a set purpose. Define a goal (e.g. use of the office during pandemic conditions), then identify the different activities that are required to achieve that goal and further narrow that down to the individual tasks that would make up such activities. From there, I could then identify the risks associated with any of these items. This formed the top level of my model as the Risk Identification Diagram (RID) and using abstraction, I could then drill-down into the identified risk elements to the next view, the Risk Resolution Diagram (RRD). In this view, our identified risk is comprised of elements called instigators and then we have our resolution elements, which detail how an instigator is addressed to alleviate risk. These are connected via association.
Here are the example patterns I have built into the MDG:
With the MDG working and me able to generate a document from it to form a risk assessment, I was very happy, but soon I got to thinking about using Shape Scripts to enhance the visuals of the model.
What is a Shape Script?
Sparx Systems talk about Shape Scripts as follows:
“As Shape Scripts are associated with stereotypes, you define them through the ‘Stereotypes’ tab of the ‘UML Types’ dialog; each stereotype can have one Shape Script.”
In plain terms, you can define how EA renders your elements by writing a Shape Script for each of them.
Not content with making things easy on myself for a first attempt at writing a Shape Script, I decided that I would like have my Associated Risk elements on the RID diagram rendered as triangles. This would overwrite the default visuals that the element is inheriting for the stereotype on which it is based.
Here is the Shape Script:
The Shape Script draws the shape by way of you plotting out how EA will draw the element within a given rectangular shape:
Here are the results:
As you can see, this is a less than ideal shape for what I need. The element name in this example simply cannot fit within this shape unless I were to attempt to position the name at the bottom of the shape, but even then I would still need space to render other information such as the associated tagged value to tell me who is at risk and display the composite link icon.
I also performed a similar experiment on the RRD, here are the results:
This is what that should look like:
Whilst you can create a Shape Script that displays the relevant compartments, it is very difficult to create the required subshapes for anything beyond a rectangle.
This is especially true given that we can just use the inherited appearance of the metaclass to which we have assigned our stereotypes. From there we can achieve the same by adding attributes such as ShowNotes=1; and ShowTags=1; our diagram profile to achieve the same:
In my example, I need only to publish particular compartments. However, should I need to display the attributes of an element, I cannot do this with a Shape Script and we are back to using the inherited appearance of the metaclass.
I guess through a combination of my experimentation and the visual examples above we can draw the following conclusions:
- EA provides us with an extremely useful and powerful functionality allowing us to create our own metamodels
- These meta models can be further customised through the use of Shape Scripts
- A Shape Script can be set to react to certain conditions e.g. Tagged Values and Properties (like Rectangle Notation and Composite)
- Creating these Shape Scripts can be time consuming and there are limitations to what they can do
From all of this I guess my advice would be to use a Shape Script if you are desperate to change the shape of your element stereotype, just beware of the time required to create some of the more wacky shapes and have them display your required data on the model.