Recently there has been a lot on the forums about MDG. This seems to coincide with my need to develop an MDG to support my current project. To date my experiences of MDGs have been somewhat limited, however when used have been a very valuable resource to enhance EA modelling. For my current project my use is somewhat different in that I am using the MDG as a means for users to provide inputs to on which my AddIn will respond.
Previous MDG developments have been somewhat difficult, not least as its a task that is done infrequently, there is a lot to remember and it’s pretty easy to do something silly. So I was pleased to use the new Profile Helper to get the basic MDG developed pretty quickly. However the Profile Helper doesn’t do everything and has some limitations which I thought worth sharing. I will also take this opportunity to share some other notes that I took during this phase of the development.
Please note: This is not meant to be an exhaustive list as I am sure there are further limitations that I have yet to discover. Also any suggestions at making edits to existing or your own MDG’s should be taken with care and knowledge; it’s pretty easy to get something wrong. Backup your work, test with test data that can be destroyed and convince yourself that you have fully tested before deploying.
Using the EA Profile Helpers
For an overview here are the basic steps for building a MDG with the Profile Helpers.
- Start with “Add a new model using wizard” – select the “MDG Technology Builder” and then select the “Basic Template” which includes both a pattern and examples. If you are familiar then the “Simple Template” is fine.
- Then in turn build and save the following profiles:
- Stereotype profile
- Diagram profile
- Toolbox profile
- Use the “Tools | Generate MDG Technology File” to create the MDG (XML file) that can be imported/loaded as required.
- Import the “Tools | MDG Technology Import” to import the file – this places the file in your “C:\Users\YOURNAME\AppData\Roaming\Sparx Systems\EA\MDGTechnologies” folder – EA looks into this folder every time it startsup and will load file present.
That is the basic process. There is a lot of information in the EA User Guide – in fact too much to keep in your mind at anyone time so unless you are doing MDG’s frequently a lot will be forgotten.
There are several online tutorial examples which provide some useful background:
- http://www.tigerteam.dk/2011/how-to-develop-mdgs-for-enterprise-architect-part-1 – Henrik Wivel – 3 posts on how to develop MDG’s for EA
- http://community.sparxsystems.com/tutorials/552-24intro-to-creating-a-mdg-file – Thomas Killian has posted a useful paper on the community forum.
And of course searching through the forum (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?board=Automation) can be a useful source of information – and a great place to post questions.
Now for some of the items that weren’t covered.
In my MDG I have several elements extending a single metaclass with their own set of tagged values and I wanted to present the tags in their own groupings. It wasn’t clear to me at first, but obvious when pointed out, that to support the different groupings you need to duplicate the metaclass that is being extended – so an element with the same name, one for each different set of tags/tagGroupins. Once aware it was easy to resolve and the tagged values appeared as I wanted.
Set a shape script.
I found that the basic elements without a shape script was a bit messy. It is is possible to do some pretty amazing things by defining your own shape scripts for a stereotype. I didn’t do much but would suggest making the element look clean, for example, the following script provides a rectangle with just the name of the element.
noshadow = “true”;
h_align = “center”;
editablefield = “name”;
Modifying the XML
I mentioned that there were several posts on the Sparx forum recently, many of which were from users keen to get access to the source of an MDG. I understand why MDG owners don’t want to release their source, not least if they want to maintain control so that they are responsible for the updates etc. So if a user wishes to make changes they are not responsible for supporting them!
In trying to resolve some of my issues I spent some time looking into the XML and I found this relatively straightforward – reason for XML is the structure. The MDG file provides building blocks and most of them can be modified or moved around; of course some elements such as the scripts cannot be decompile but I don’t see any reason they can be moved around if needed. However, my main reason was to manipulate the tags, in part to understand why things were working (such as the tagGroupings above). In doing this I also discovered some really useful information and would recommend checking out the “Special Attributes” section in the user guide. Here are some notes on some of the tags I have looked at are:
This allows for the use of submenus each time an element is added from the toolbox. So for an existing MDG if you want to change the menu selected or remove completely this can be achieved by modifying the relevant XML. For example, in the BPMN MDG if you want to change the menu for an activity from the standard taskType then the line
<Property name=”_subtypeProperty” value=”BPMN2.0::Activity::taskType”/>
could be modified to
<Property name=”_subtypeProperty” value=”BPMN2.0::Activity::whatevertagyouwant/>
If you want to set the default value that is used by the submenu then as an example when the _subtypeProperty default for “taskType” is set as “Abstract” as below:
“<Tag name=”taskType” type=”enumeration” description=”” unit=”” values=”BusinessRule,Manual,Receive,Service,Send,Script,User,Abstract” default=”Abstract”/>”
you can change the default value to one of the other VALID items
Modifying and updating the MDG tagged values within your models
Of course, if you change the MDG for example add more tagged values, and you have existing models can you apply the MDG retrospectively. Well yes but..
If you modify an MDG profile you can apply a “global sync” by selecting the relevant element in the MDG toolbox, right click to get the context menu and select Synchronize Stereotype. This will update all the relevant stereotyped elements however it doesn’t put any newly added tagged values into their relevant tagGroup.
If you want to have the tagged values grouped correctly I have observed that if you “apply type” by dragging the relevant toolbox item onto an existing element it will perform the update and ensure that the tagGroupings are set correctly. For more information see “Synchronize Tagged Values and Constraints” in the user guide.
MDG related events
Now the main reason for my MDG was to support users input, with changes to MDG tagged values initiating actions within my AddIn.
My plan was to use a range of predefined tagged values (Settings | UML Types | Tagged Value Types) e.g. Boolean, Color, Enum as well as Addin Broadcast type.
For the “AddIn Broadcast” types my AddIn would respond to the EA_OnElementTagEdit events’ whilst for other changes my EA_OnNotifyContextItemModified method would be called. One of the unfortunate differences is that for EA_OnNotifyContextItemModified there is no indication of the value that has been modified, hence it is necessary to check what had changed and take the appropriate action. So I have my plan and started coding, however, all was not as I expected. Here are a few of my observations which may help you avoid some issues.
When using Predefined taggedvalues you need to be very careful to check the type of the values that are provided. I’m not sure whether this is an EA issue or a language issues, but, for example, when using “Type=color” the user guide states tat it returns an integer. However when experiencing problems I checked the type that was return and it was identified as Type “String”. Well I can cope with that until I discover that sometimes it returns an integer string whilst at other times it returns a hex string. Not sure how to resolve that and with that inconsistency I decided the solution was to provide my own color picker and use the “Type=AddinBroadcast;”. In fact for anything other than the basic value types I found this a more reliable means to get correct values. Furthermore, by handling the tags myself I had the advantage that I what item I had changed.
For the “normal tags” I did use the EA supplied types and these were handled by the EA_OnNotifyContextItemModified.
In both cases having captured the tagged value changes I may respond with some updated values either directly or indirectly. What is disconcerting is when I know the changes have been made in the data structures and the tagged value window does not update. So remember to execute the “Repository.AdviseElementChange” method to ensure the update to the EA UI.
Finally, when adding a new MDG element programmatically don’t forget that you do NOT add the tagged values but use the “element.SynchTaggedValues” method – see user guide for more information.
By using the Profile Helpers I felt more comfortable in coming back to working with MDG’s. Although the helpers help by providing a quick start, there is still a lot of information you may need to consider when developing an MDG, so don’t expect it to be a quick task.
I have found it useful to become familiar with the XML that is produced, and a place to make quick edits before going back into the model to “do it properly”.
So my MDG seems to be working fine. It took longer than expected to produce due to some if the issues I’ve detailed above, however the result is that I now have a user interface with which most users will be familiar, and therefore easier to use – my primary aim.