In this section we discuss the process of designing models for an additional view. For each view addition to nAOMi, there are three steps that should be performed. These steps only concern the modelling part of the implementation. The transformations of the additional view are discussed in Chapter 6. The following steps have been defined:
1. Design a metamodel for the additional view.
2. Design a customized DSL representation for the additional view. 3. Extend the SUM metamodel with the metamodel of the additional view.
We followed these steps during the implementation of our addition view. Each step will be described in detail, providing figures to show the results.
5.2.1 Metamodel design
During our view selection process we created a metamodel for a context view. However, during the develop- ment of our extension we noticed that this metamodel was not sufficient to model all the capabilities of the context view. Furthermore, we chose to support not only one system, but also multiple sub-systems. This allowed us to create more detailed models. Although some entities and connections have been added, the metamodel was still rather easy to define.
5.2. CONTEXT VIEW IMPLEMENTATION 39
Figure 5.7: The context metamodel
an attributenameto specify its name. Each system consists of several sub-systems, which are connected to
each other by aconsistOf relation. Besides, we defined an entity that specifies theactor, which also contains
an attributename. In order to specify the type of the actor, e.g., a human or another system, an attributetype
has been added. Between thesubSystemandactorthere are two different connections:relationshipFrom, to
specify the relation that originates from thesubSystemand points to theactor, andrelationshipTo, to specify
the relations going to thesubSystem and comming from the actor. Furthermore, an internal relationship
relationshipInternalspecifies relations among the subsystems themselves, and an external relationshiprela-
tionshipExternalspecifies the relations betweenactors. These relationship connections contain an attribute
description, which specifies the description of the relationship. The complete metamodel of a context view is shown in Figure 5.7.
Model instances
The metamodel in Figure 5.7 can be used to instantiate models. Figure 5.8 shows an example of a model
on level O1, which uses the instances of the O0 metamodel. In this model we see one system,MainSystem,
connected to two sub-systems, sub1and sub2, by the consistOf connection. Furthermore, there are two
actors, CustomerandAdmin. The sub-systems and actors are all connected to each other by the different
relationships. Because this model is represented in the default LML visualization of Melanee, the model does not look much like a context diagram, such as that of Figure 5.4.
5.2.2 DSL implementation
In order to achieve the same representation, we used the visualization editor of Melanee. This editor has several pre-made shapes that can be enhanced by using specific properties. For every entity or connection
in the metamodel, agraphical DSL visualizerhas been added. This visualizer determines how the instances
40 CHAPTER 5. CONTEXT VIEW DESIGN
Figure 5.8: Context model based on the metamodel.
shown in Figure 5.9, which shows the DSL representation for thesystementity.
During our view selection procedure we created a DSL customization. Although we added some new entities and connection, the basics of this customized DSL stayed the same. The system and sub-system entities should be represented as a circle, with their name shown in the center. This is achieved by applying
the visualization of Figure 5.9. This visualization consists of several specifications, such as thecircleand the
label expressionspecifying the shape and the text respectively. Thetable layoutandtable layout information
are used to determine the position of the label. The visualization of the actors and the relationships are defined in a similar way. By enabling the DSL representation option for every element at the instance level of the model, the visualization of the model, shown in Figure 5.10, is achieved.
The actors are shown as rectangles with the name specified in the center. Because we were unable to define a shape according to the value of an argument, the different types of the actors can not be displayed by different shapes. For example, human actors can not be represented by a stick figure, unless the other actors are also represented by the same figure. Therefore, we chose to visualize all actors as a rectangle. Relationships are
5.2. CONTEXT VIEW IMPLEMENTATION 41
Figure 5.9: DSL visualization editor for system entity
represented by an arrow, with the description of the relationship above it. Due to the graphical limitations regarding the lines between entities, these connections could not be shown as curved lines, but had to be displayed as straight angular lines. Although the visualization is not exactly as the original visualization of context diagrams, it is close enough because it allows one to distinguish the systems from the entities, and to recognize the relationships and their meaning.
Figure 5.10: DSL representation of the context model.
5.2.3 SUM metamodel extension
Figure 5.11 shows the original implementation of the SUM metamodel. This metamodel contains the entities
necessary to support a structural view and a behavioural view, divided by theStateContainmentconnection.
We extended this metamodel by adding our context metamodel (Figure 5.7) to the left side of the metamodel,
by connectingsubSystem tocomponent. By connecting the subSystemtocomponentwe can indicate that
thesubSystemconsists of one or multiple components, which is indeed the case. In order to implement this
connection, we introduced anincludesconnection, to connectsubSystemwithcomponent. This results into
a new SUM metamodel that supports a structural view, behavioural view and our context view, as shown in Figure 5.12.
Although the context view does not visualize the components connected to the system, it is necessary to specify this connection in the SUM metamodel. Without this connection we would be unable to determine which sub-system should be shown when a certain component is selected. Furthermore, it joins the structural view with the context view, which unites the system as a whole.
42 CHAPTER 5. CONTEXT VIEW DESIGN
Figure 5.11: The currently implemented SUM metamodel
Figure 5.12: The extended SUM metamodel
Helper view
The helper view is specially developed to connect thesubSystemswithcomponents. The view only contains
the entitiessubSystemandcomponent, together with the connectionincludes. Figure 5.13 illustrates how this
view looks like. This view does not use a DSL implementation and always shows all availablesubSystems
andcomponents.
5.2.4 Alternative representations
Besides the view shown in Figure 5.10, alternative representations of the context view are supported. With
theComplete overviewoption it is possible to show the complete system, instead of just one sub-system.
Depending on the selection of the encapsulation either the complete view is shown, including the sub-
systems, or only the system is shown, hiding the subsystems. The encapsulation provides two options,
namely therealization (white box)and thespecification (black box). Therealizationshows the system with
all sub-systems and actors, as shown in Figure 5.10, whereas thespecificationonly shows the system with