Building Graphical Notations

Imagine you want to be able to draw the model depicted in Figure 7-5. The diagram shows two switches connected with a link; the link is attached to a port on each switch, where the port has a number. We can capture the conceptual entities in this model by constructing the metamodel shown in Figure 7-6.

Figure 7-5. A graphical representation of a network


Figure 7-6. Metamodel for network


Defining the metamodel is one thing; having a concrete syntax and notation to use in creating, editing, and maintaining the corresponding models is another. Stated another way, how can we create and edit diagrams like Figure 7-4 and create instances of the classes in the metamodel of Figure 7-6? "Meta-case" tools are one way of creating custom graphical notations for any kind of metamodel, but even they have to connect properly to the important MDA standards to be generally useful.

As it happens, we can draw a UML diagram that looks almost like Figure 7-5 using the existing graphical notation for UML. Figure 7-7 shows the resulting UML model. It uses the UML notation for an interface (called "lollipop" notation) with stereotype «Switch» to represent the switches, the graphical notation for an association to represent the link, and association ends to represent the connectors.

Figure 7-7. UML rendition of metamodel for network


Figure 7-8 shows the mappings we have used between the networking metamodel shown in Figure 7-6 and the UML rendition of Figure 7-5 shown in Figure 7-7. This sort of mapping to UML using stereotypes and tagged values can be applied to any metamodel defined in MOF. The general pattern is to find similar structures in UML, use stereotypes to avoid ambiguities, and, if nothing else helps, map the associations in your metamodel to UML dependencies and map attributes in your metamodel to attributes of stereotypes.

Figure 7-8. Mapping between network and UML metamodels


The same technique can be used to represent marks and marking models in UML. Typically, a set of mark definitions is mapped to a stereotype that defines an attribute for each mark definition in the set. The attribute's type and default value are set according to the mark definition. The stereotype is defined to apply to the types of model elements to which the set of mark definitions applies.

To ensure that the marks are available on all corresponding model elements, the stereotype can be made mandatory by adding a tag {required}, as shown in Figure 7-9. The resulting mapping is a representing mapping, as discussed in Chapter 5, which acts as an adapter between your metamodel defined in MOF and the UML metamodel.

Figure 7-9. Marking stereotype as mandatory


For the example, a mapping function can rely on MOF and its definitions for how the model can be accessed. It will hold a model element of type Switch and ask it for its connectors, simply by calling getConnectors() on that model element. The profile implementation will handle the navigation of the underlying UML model. (The function getConnectors() would be a user-defined function that retrieves all instances of the Connector class associated with the given instance of Switch.)

With this tool of UML profiles in hand, we're all set to metamodel away. As the profile implementation provides us with the true view of our concepts, we don't have to hassle with the details of how we represent the model in UML, which could change if the UML version changes. The mapping functions that are based on the underlying metamodel won't be affected by this.

This powerful way of combining MOF metamodels and UML profiles should be used if the metamodel uses substantially different concepts from those offered by the UML. Otherwise, mapping functions would have to concern themselves with stereotypes and tagged values instead of the concepts of the real metamodel. This would make the process of specifying a mapping function tedious and error-prone. Moreover, it would make the mapping function specific to the profile.

Note that this approach of bending a UML tool to build a graphical notation is something of a kludge. New meta-case tools are already starting to appear that provide domain-specific notation, though as we noted earlier, these tools will have more reach if they connect to the MDA tool chain.

MDA Distilled. Principles of Model-Driven Architecture
MDA Distilled. Principles of Model-Driven Architecture
ISBN: B00866PUN2
Year: 2003
Pages: 134 © 2008-2017.
If you may any questions please contact us: