Displaying items by tag: meta models

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:

MDG Quicklink Definitions

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:

MDG Quicklink Definitions

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.

    MDG Quicklink Definitions
  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

MDG Quicklink Definitions

Example; Custom Diagram

MDG Quicklink Definitions

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:

MDG Quicklink Definitions

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:

MDG Quicklink Definitions

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

Published in Tutorials