DSM Core metamodel
Domain A metamodel Domain B metamodel
Domain A models Domain B models
{explicit}
(a) Types from Domain A are assigned explicitly to model elements in Domain B (either by the user or automatically using a mapping model).
DSM Core metamodel
Domain A metamodel Domain B metamodel
Domain A models Domain B models
{explicit}
(b) This mapping can be partial, because in most cases not all elements from Domain B are relevant in Domain A.
Figure 3.9: Model-level integration (multiple instantiation)
If models need to be corrected, such corrections can be solved by (simple) model transformations.
In contrast to an entirely model transformation-based integration scenario, the transformations re-quired here only performcorrectionson the models (instead of full translations).
3.4.1.1 Case study: Enterprise Security Policies and the UML Performance Profile
Figure 3.10 outlines the first demonstrating scenario, which targets to create and maintain two domain-specific views (ESPandUML-Perf) of the same instance modelsIM within the model store.
Light-weight metamodeling techniques will be used for demonstration. This scenario intends to show how a custom domain-specific language can be automatically projected to an analysis domain corresponding to the UML Performance Profile.
Example 6 (The Enterprise Security Policy (ESP) domain) The domain-specific modeling language is built from scratch by using a generic modeling environment. In this case, theEnterprise Security Policydomain (see Figure 3.11, which is an extended version of the example presented in [PW04] as a complex case study) describes a simple enterprise security and surveillance system installation and its security procedures (note: several classes have properties which are omitted in Figure 3.11 for the sake of simplicity).
3.4. DOMAIN INTEGRATION OVER THE VPM MODEL SPACE 45
Figure 3.10: Multidomain example
Figure 3.11 depicts the metamodel for the ESP domain in the textual VTML and a graphical syntax to ease understanding. As a highlight, thedomainandmodelkeywords are introduced here;domain declarations are used to indicate the classification of follow-up declarations in terms of the domain space, while themodelkeyword is used to give a name the particular model that is being defined.
The Enterprise Security Policy domain describes both deployment and procedural aspects of en-terprise surveillance systems. At the top of the containment hierarchy is theInstallationentity, to whichBuildings, aNetworkand severalProcessescan be assigned. A Building consists ofRooms, whereDevicescan be placed. Devices have deployment and operational cost properties which can be used for financial analysis and optimization. The buildings are connected to the network infrastruc-ture; individual devices can be assigned individual connection properties (not shown in Figure 3.11).
Security policyProcessesconsist ofActivities, which can make use of several devices.
Example 7 (UML Performance (UML-Perf) domain) Since the application domain is capable of de-scribing processes, it is a natural requirement to analyze the performance and throughput of the system in a production environment. For modeling performance related aspects, we use the standard UML Performance profile[Theg]. As a consequence, the modeling environment should be extended to allow the projection of security policy models into the UML Performance domain (Figure 3.12).
The UML Performance domain describesPerformance Contexts, which consist of Workloads, Per-formance Scenarios, and Performance Resources. A scenario is made up of multiple, ordered Per-formance Steps, which can make use of either Passive, or Processingresources. A scenario can be analyzed with eitherOpen, orClosedworkloads.
1 d o m a i n( ESP );
2 m o d e l( E S P _ M e t a );
3
4 e n t i t y( E n t e r p r i s e _ S e c u r i t y _ P o l i c y ) { 5 e n t i t y( I n s t a l l a t i o n ) {
6 e n t i t y( B u i l d i n g ) {
7 r e l a t i o n( network , B u i l d i n g , N e t w o r k );
8 e n t i t y( R o o m ) { 9 e n t i t y( D e v i c e );
10 e n t i t y( D o o r l o c k _ A c t u a t o r );
11 s u p e r t y p e O f( D o o r l o c k _ A c t u a t o r , D e v i c e );
12 e n t i t y( V i d e o _ C a m e r a );
13 s u p e r t y p e O f( V i d e o _ C a m e r a , D e v i c e );
14 e n t i t y( S e c u r i t y _ C a r d _ R e a d e r );
15 s u p e r t y p e O f( S e c u r i t y _ C a r d _ R e a d e r , D e v i c e );
16 e n t i t y( A p p l i c a t i o n _ S e r v e r );
17 s u p e r t y p e O f( A p p l i c a t i o n _ S e r v e r , D e v i c e );
18 e n t i t y( D a t a b a s e _ S e r v e r );
19 s u p e r t y p e O f( D a t a b a s e _ S e r v e r , D e v i c e );
20 e n t i t y( D i s k _ R e c o r d e r );
21 s u p e r t y p e O f( D i s k _ R e c o r d e r , D e v i c e );
22 }
23 }
24 e n t i t y( N e t w o r k ) {
25 r e l a t i o n( owner , Network , B u i l d i n g );
26 r e l a t i o n( c o n n e c t i o n , Network , D e v i c e );
27 }
28 e n t i t y( P r o c e s s ) { 29 e n t i t y( A c t i v i t y ) {
30 r e l a t i o n( next , A c t i v i t y , A c t i v i t y );
31 r e l a t i o n( prev , A c t i v i t y , A c t i v i t y );
32 r e l a t i o n( uses , A c t i v i t y , D e v i c e );
33 }
34 r e l a t i o n( start , Process , A c t i v i t y );
35 } } } }
Enterprise Security
Policy
Installation
Building
Device
Network Process
Room Activity
Doorlock Actuator
Video Camera
Security Card Reader
Application Server
Database Server
Disk Recorder
+connection
+uses
* *
*
*
* +prev
+next
*
+start
Figure 3.11: Enterprise Security Policy domain metamodel
3.4.1.2 Elaboration of the example
To solve the problems outlined in Example 6, we create amulti-view(in ViatraDSM) over the model space consisting oftwo domain-specific views(corresponding to the ESP and UML performance do-mains) and show how each present the contents of the same model space specifically to the domain context. Our goal is to enable the performance modeling expert to view the models created by the enterprise security experts directly from the native UML Performance view.
Since the domain metamodels are structurally similar, our approach is focused on the metamodel-level domain integration technique (simple transformations for ensuring well-formedness will only be outlined here, as they will be discussed later in detail: Chapter 4). One could also opt for a model-level integration approach, however, in this specific case primary system design is carried out in the ESP domain, and the UML Performance view is only used for the assignment of performance-specific model properties.
Example 8 (Metamodel-level integration between ViatraDSM’s domains) Figure 3.13 shows the metamodel-level integration mappings in VTML and also graphically. The ESP domain incorporates bothstructural(Building-Network-Room-Device) anddynamicviews (Processes) from UML-Perf. In this case, structural elements (Devices are mapped to (various types of)PResources, whileProcesses
3.4. DOMAIN INTEGRATION OVER THE VPM MODEL SPACE 47
1 d o m a i n( U M L P e r f );
2 m o d e l( U M L P e r f _ M e t a );
3
4 e n t i t y( P e r f o r m a n c e _ C o n t e x t ) { 5 e n t i t y( W o r k l o a d ){
6 e n t i t y( O p e n _ W o r k l o a d );
7 s u p e r t y p e O f( O p e n _ W o r k l o a d , W o r k l o a d );
8 e n t i t y( C l o s e d _ W o r k l o a d );
9 s u p e r t y p e O f( C l o s e d _ W o r k l o a d , W o r k l o a d );
10 r e l a t i o n( s c e n a r i o , W o r k l o a d , P S c e n a r i o );
11 }
12 e n t i t y( P S c e n a r i o ) { 13 e n t i t y( P S t e p ) {
14 r e l a t i o n( pred , PStep , P S t e p );
15 r e l a t i o n( succ , PStep , P S t e p );
16 }
17 s u p e r t y p e O f( PStep , P S c e n a r i o );
18 r e l a t i o n( root , P S c e n a r i o , P S t e p );
19 r e l a t i o n( host , P S c e n a r i o , P P r o c e s s i n g _ R e s o u r c e );
20 }
21 e n t i t y( P R e s o u r c e ) {
22 e n t i t y( P P r o c e s s i n g _ R e s o u r c e );
23 s u p e r t y p e O f( P P r o c e s s i n g _ R e s o u r c e , P R e s o u r c e );
24 e n t i t y( P P a s s i v e _ R e s o u r c e );
25 s u p e r t y p e O f( P P a s s i v e _ R e s o u r c e , P R e s o u r c e );
26 } 27 }
Performance Context
Workload PScenario PResource
Open Workload
Closed
Workload PStep PProcessing
Resource
PPassive Resource +resource
<<deploys>>
+host {ordered}
+root
+pred +succ
* * *
*
Figure 3.12: UML Performance domain metamodel (extract)
and theirActivitiescorrespond toPScenarios and theirPSteps.
The mappings are declared by supertypeOfclauses in VTML. The metamodel-level mapping ensures that every model instance constructed in the ESP domain will be visible in the UML Perfor-mance domain as well (naturally, this holds for the mapped model elements).
Notes on well-formedness It can be noted that the containment structure of the language meta-models is slightly different (see the green highlight in Figure 3.13). Thus, the containment tree struc-ture of the source domain is not strictly well-formed in the target domain:Deviceinstances associated to a givenInstallationcan be reached in three navigational steps in the ESP domain, however in the UML Performance ProfilePResourcesare directly contained byPerformance Contextinstances. This means that for already existing Device instances, such asLobbyCambeing contained as a valid PRe-sourceby theGroceryStoreperformance context, a new relation of typeresourcesmust be added at some point (marked by new keyword in Figure 3.13). This simple correction may be implemented e.g. by a model transformation using graph transformation rules (see Chapter 4 for more details).
Domain-specific views in ViatraDSM A rendering of the multi-view in the graphical user interface of ViatraDSM is shown in Figure 3.14. The screenshot extracts show the same physical model instance from two different perspectives. As the user is editing the model in the ESP domain, the changes are instantly visible in the UML Performance domain. However, these are domain-specific views, thus in each editor only those details are visible which are relevant for the given visual language.
1 d o m a i n( VPM );
2 m o d e l( U M L P e r f _ _ E S P );
3
4 /* m a p p i n g of s t r u c t u r a l n o t i o n s */
5 s u p e r t y p e O f(
6 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . I n s t a l l a t i o n , 7 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t );
8 s u p e r t y p e O f(
9 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . B u i l d i n g . R o o m . Device , 10 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P R e s o u r c e );
11 s u p e r t y p e O f(
12 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . B u i l d i n g . R o o m . D e v i c e . A p p l i c a t i o n _ S e r v e r , 13 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P R e s o u r c e . P P r o c e s s i n g R e s o u r c e );
14 s u p e r t y p e O f(
15 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . B u i l d i n g . R o o m . D e v i c e . D a t a b a s e _ S e r v e r , 16 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P R e s o u r c e . P P r o c e s s i n g R e s o u r c e );
17 s u p e r t y p e O f(
18 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . B u i l d i n g . R o o m . D e v i c e . D i s k _ R e c o r d e r , 19 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P R e s o u r c e . P P a s s i v e R e s o u r c e );
20 s u p e r t y p e O f(
21 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . B u i l d i n g . R o o m . D e v i c e . D o o r l o c k _ A c t u a t o r , 22 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P R e s o u r c e . P P a s s i v e R e s o u r c e );
23 s u p e r t y p e O f(
24 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . B u i l d i n g . R o o m . D e v i c e . S e c u r i t y _ C a r d _ R e a d e r , 25 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P R e s o u r c e . P P a s s i v e R e s o u r c e );
26 s u p e r t y p e O f(
27 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . B u i l d i n g . R o o m . D e v i c e . V i d e o _ C a m e r a , 28 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P R e s o u r c e . P P a s s i v e R e s o u r c e );
29
30 /* m a p p i n g of d y n a m i c n o t i o n s */
31 s u p e r t y p e O f(
32 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . Process , 33 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P S c e n a r i o ) 34 s u p e r t y p e O f(
35 ESP . E S P _ M e t a . E n t e r p r i s e _ S e c u r i t y _ P o l i c y . P r o c e s s . A c t i v i t y , 36 U M L P e r f . U M L P e r f _ M e t a . P e r f o r m a n c e _ C o n t e x t . P S c e n a r i o . P S t e p )
Performance Context
PResource
Installation
Building
Device Room
GroceryStore
Shop
Lobby
LobbyCam +buildings
+rooms
+devices +resources
:buildings
:rooms
:devices
{neg, new}
:resources
Video Camera
Figure 3.13: Mapping between the ESP domain and UML performance
3.4.2 Domain integration in language engineering
Multi-domain integration techniques are not only useful in modeling scenarios involving many dif-ferent languages, but also in designing advanced DSMLs. As mentioned in Section 3.2, such (com-plex) languages are defined by an interconnected hierarchy of metamodels (or, more precisely, their
3.4. DOMAIN INTEGRATION OVER THE VPM MODEL SPACE 49
(a) UML Performance (b) Enterprise Security Policy
Figure 3.14: Domain-specific editors: the same model element in two different domains
metamodel is constructed according to a multi-aspect design pattern, where each modeling aspect – sub-language – can be considered a complete metamodel on its own).
In graphical modeling languages, a core multi-aspect language design pattern is to separate the abstract and concrete syntax representations of the language (where, most typically, a single abstract syntax metamodel is accompanied by several concrete syntax metamodels corresponding to differ-ent diagram types the language might have). This modeling architecture allows for a high degree of flexibility, since abstract and concrete syntax models can be managed and manipulated according to different considerations: abstract models may be optimized for machine processing or standard compliance, while concrete models may be optimized for usability that relies on powerful abstrac-tions that hide unnecessary detail for conciseness. However, these sub-domains still represent the same logical model, so their consistency has to be ensured. The two crucial factors of enabling the complete, yet consistent separation of abstract and (several) concrete syntax models of DSMLs are (i) a flexible traceability modeling mechanism that allows complex correspondence mappings, and (ii) automated model synchronization that efficiently and transparently maintains all three models.
Figure 3.15 illustrates the modeling foundations of the ViatraDSM framework that implements the previously outlined design pattern. Here, abstract and concrete syntax models are handled as three subdomainsDSMAS,DSMCS andDSMT R, and each consists of an inheritance hierarchy (lattice) as follows:
• Core metamodelsCM MAS, CM MCS, CM MT R at the top of the lattice represent the set of basic notions that are common in all DSMLs of the framework. All domain metamodels are refinements of these, and all domain-specific instance models are (indirect) instances, which allows for reflectivefeatures, such as generic, tree view-based editors and generic graphical visualizations for diagrams.
• CM MCS and its subtypes define thestructureof diagrams, not their precise appearance, and are used to persist visualization information.
• CM MT R, and its subtypes describe (flexible)mapping rulesthat are to be followed by well-formed abstract and concrete syntax models. A subtype ofCM MT Ris thus a part of amapping
Figure 3.15: Domain integration between abstract-, concrete syntax and traceability models
librarythat describes how a certain concrete syntax element is to be connected to its abstract syntax counterparts. The information encoded in the instances of traceability models is used throughout the UI, for e.g. collecting both abstract syntax (structure) as well as concrete syntax (visualization) properties in theProperties view.
The mapping rules are enforced by interpretative transformations, which are discussed in de-tail in Chapter 6. The focus of the current section is to systematically describe the metamodeling foundations of the ViatraDSM framework.
3.4.2.1 Abstract and concrete syntax metamodels
Example 9 (Abstract syntax core metamodel) Figure 3.16 shows the core metamodel for abstract syntax (domain) model elements associated to aHierarchy. AHierarchyis a top-level model element that represents all instance models of the language. The core abstract syntax metamodel defines a directed, labeled graph withNodesandEdges; both Nodes and Edges can haveProperties. Nodes are organised into acontainmenthierarchy.
This abstract syntax core metamodel represents the top of the inheritance lattice of all domain-specific languages used by ViatraDSM’s plugins. It conceptually extends the VPM core metametamodel (Def. 5) by the explicit representation of user-specifiable property values that can be subtyped to define domain-specific property type systems. The core metamodel was designed so that any domain-specific language can be projected into this simple framework.
3.4. DOMAIN INTEGRATION OVER THE VPM MODEL SPACE 51
1 d o m a i n( DSM );
2 m o d e l( D S M _ A b s t r a c t S y n t a x _ C o r e M e t a );
3
4 e n t i t y( H i e r a r c h y ) {
5 r e l a t i o n( t o p N o d e s , H i e r a r c h y , N o d e );
6 i s A g g r e g a t i o n( t o p N o d e s ,t r u e);
7 e n t i t y( N o d e ) {
8 r e l a t i o n( p r o p e r t i e s , Node , P r o p e r t y );
9 m u l t i p l i c i t y( p r o p e r t i e s ,o n e _ t o _ m a n y);
10 r e l a t i o n( c o n t a i n s , Node , N o d e );
11 i s A g g r e g a t i o n( c o n t a i n s ,t r u e);
12 }
13 e n t i t y( E d g e ) {
14 r e l a t i o n( src , Edge , N o d e );
15 m u l t i p l i c i t y( src ,m a n y _ t o _ o n e);
16 r e l a t i o n( trg , Edge , N o d e );
17 m u l t i p l i c i t y( trg ,m a n y _ t o _ o n e);
18 r e l a t i o n( p r o p e r t i e s , Edge , P r o p e r t y );
19 m u l t i p l i c i t y( p r o p e r t i e s ,o n e _ t o _ m a n y);
20 }
21 e n t i t y( P r o p e r t y );
22 }
Figure 3.16: Core abstract syntax metamodel
Similarly to the abstract syntax metamodel, a concrete syntax (diagram) metamodel may be de-fined.
Example 10 (Concrete syntax core metamodel) Figure 3.17 shows the core metamodel for concrete syntax model elements associated to aDiagram. All elements of a diagram are eitherNodeFigures or EdgeFiguresthat can display (textual) Attributes in labels. Diagram elements are freely allowed to contain other diagram elements to express the hierarchical nature of diagrams (where graphical elements are contained by others).
Petri net examples We elaborate example projections of thePetri net domain (Example 1) to the core metamodels. In the graphical notation of the following figures, subtyping relationships are implicitly indicated by in brackets (where the supertype is written inside the brackets), for the sake of simplicity.
Example 11 (Petri net abstract syntax metamodel) In abstract syntax (shown in Figure 3.18), the topmost nodes that represent distinct instance models arePetri nets, which may containPlaces and Transitions. Places may, in turn, containTokens. ATokeninstance is only allowed to be added to a Placeinstance because of thetokensrelation which is a refinement of the corecontainsconcept. Out-Arcs andInArcs are derived from theArccore type. Two properties (Place capacityandArc weight) are explicitly metamodeled.
The VTML code corresponding to the metamodel of Example 11 is shown in Figure 3.19. Here, a top-levelsupertypeOf clause declares that PetriNet_AbstractSyntax_Metais a subtype of the core abstract syntax metamodel DSM_AbstractSyntax_CoreMeta(Figure 3.16). This top-level supertype relationship is explicitly elaborated in the rest of the code, as every element subtypes some base notion from the core metamodel.
1 d o m a i n( DSM );
2 m o d e l( D S M _ C o n c r e t e S y n t a x _ C o r e M e t a );
3
4 e n t i t y( D i a g r a m ) {
5 e n t i t y( D i a g r a m E l e m e n t ) {
6 r e l a t i o n( s u b E l e m e n t s , D i a g r a m E l e m e n t , D i a g r a m E l e m e n t );
7 e n t i t y( N o d e F i g u r e ) {
8 r e l a t i o n( f r o m E d g e s , N o d e f i g u r e , E d g e F i g u r e );
9 m u l t i p l i c i t y( f r o m E d g e s ,o n e _ t o _ m a n y);
10 r e l a t i o n( toEdges , N o d e f i g u r e , E d g e F i g u r e );
11 m u l t i p l i c i t y( toEdges ,o n e _ t o _ m a n y);
12 }
13 s u p e r t y p e O f( N o d e F i g u r e , D i a g r a m E l e m e n t );
14 e n t i t y( E d g e F i g u r e );
15 s u p e r t y p e O f( E d g e F i g u r e , D i a g r a m E l e m e n t );
16 e n t i t y( A t t r i b u t e );
17 r e l a t i o n( a t t r i b u t e s , D i a g r a m E l e m e n t , A t t r i b u t e );
18 m u l t i p l i c i t y( a t t r i b u t e s ,o n e _ t o _ m a n y);
19 i s A g g r e g a t i o n( a t t r i b u t e s ,t r u e);
20 } 21 }
Figure 3.17: Core concrete syntax metamodel
Petri net hierarchy [Hierarchy]
Petri net [Node]
Place
[Node] Transition
[Node]
Arc [Edge]
Place capacity [Property]
petriNets [topNodes]
places
[contains] transitions
[contains]
weight [properties]
capacity [properties]
Token [Node]
tokens [contains]
OutArc [Arc]
InArc [Arc]
plc [src] trn [trg]
plc [trg] trn [src]
Arc weight [Property]
Figure 3.18: Abstract syntax metamodel
3.4. DOMAIN INTEGRATION OVER THE VPM MODEL SPACE 53
1 d o m a i n( DSM . P e t r i N e t );
2 m o d e l( P e t r i N e t _ A b s t r a c t S y n t a x _ M e t a );
3 s u p e r t y p e O f( P e t r i N e t _ A b s t r a c t S y n t a x _ M e t a , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a );
4
5 e n t i t y( P e t r i _ n e t _ h i e r a r c h y ) {
6 r e l a t i o n( p e t r i N e t s , P e t r i _ n e t _ h i e r a r c h y , P e t r i _ n e t );
7 m u l t i p l i c i t y( p e t r i N e t s ,o n e _ t o _ m a n y);
8 s u p e r t y p e O f( p e t r i N e t s , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . H i e r a r c h y . t o p n o d e s );
9 e n t i t y( P e t r i _ n e t ) { 10 e n t i t y( P l a c e ) { 11 e n t i t y( T o k e n );
12 s u p e r t y p e O f( Token , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . N o d e );
13 e n t i t y( P l a c e _ c a p a c i t y );
14 s u p e r t y p e O f( P l a c e _ c a p a c i t y , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . P r o p e r t y );
15 r e l a t i o n( c a p a c i t y , Place , P l a c e _ c a p a t i t y );
16 s u p e r t y p e O f( c a p a c i t y , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . N o d e . p r o p e r t i e s );
17 }
18 s u p e r t y p e O f( Place , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . N o d e );
19 e n t i t y( T r a n s i t i o n );
20 s u p e r t y p e O f( T r a n s i t i o n , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . N o d e );
21 e n t i t y( Arc ) {
22 e n t i t y( A r c _ w e i g h t );
23 s u p e r t y p e O f( A r c _ w e i g h t , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . P r o p e r t y );
24 r e l a t i o n( weight , A r c _ w e i g h t );
25 s u p e r t y p e O f( weight , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . E d g e . p r o p e r t i e s );
26 r e l a t i o n( plc , Arc , P l a c e );
27 r e l a t i o n( trn , Arc , T r a n s i t i o n );
28 e n t i t y( I n A r c ) {
29 s u p e r t y p e O f( plc , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . E d g e . trg );
30 s u p e r t y p e O f( trn , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . E d g e . src );
31 }
32 s u p e r t y p e O f( InArc , Arc );
33 e n t i t y( O u t A r c ) {
34 s u p e r t y p e O f( plc , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . E d g e . src );
35 s u p e r t y p e O f( trn , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . E d g e . trg );
36 }
37 s u p e r t y p e O f( OutArc , Arc );
38 }
39 s u p e r t y p e O f( Arc , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . E d g e );
40 }
41 s u p e r t y p e O f( P e t r i _ n e t , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . N o d e );
42 }
43 s u p e r t y p e O f( P e t r i _ n e t _ h i e r a r c h y , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . H i e r a r c h y );
Figure 3.19: Petri net abstract syntax metamodel in VTML
We use the same principle for defining the metamodel for standard Petri net diagrams, which show Petri nets, places and transitions but omit tokens for the sake of visual clarity.
Example 12 (Petri net concrete syntax metamodel) Inconcrete syntax(shown in Figure 3.20), Petri nets,PlacesandTransitionsare mapped to separate visual graph nodes (Petri net root,PlaceFigureand TransitionFigure, respectively), whileOutArcsandInArcsare visualised as graph edges (OutArcFigure andInArcFigure). Note thatTokensare not included in the diagram metamodel. Instead of mapping them to separate visual nodes, this visualisation language uses an attribute (TokenCount) to indicate the number of tokens assigned to a place (this is the only label in this simple diagram).
The VTML for the metamodel in Figure 3.20 is defined analogously to Figure 3.19.
Figure 3.20: Concrete syntax metamodel
3.4.2.2 Traceability models between abstract and concrete syntaxes
To maintain a consistent mapping between instances of the abstract and concrete syntax metamod-els, we userepresentation traceability models(Section 2.6) conforming to a generic traceability meta-model, which is shown in Figure 3.21. It defines a containment hierarchy betweenTopMappings and MappingElements. A TopMappinginstance connects a concrete syntaxDiagram with an abstract syntaxHierarchy, so it serves as a top-level container for the rest of the trace metamodel elements.
EachDiagramElement(NodeFigures,EdgeFigures) may have multipleMappingElementassociations;
sinceMappingElementis abstract, two non-abstract subtypes (EdgeMappingElementand NodeMap-pingElement) are used to define trace bindings to abstract syntaxEdgesandNodes, respectively.
This way, a flexiblen-to-m(many-to-many) mapping can be defined, where a concrete syntax ele-ment may reference multiple abstract syntax eleele-ments by defining multipleMappingElements, or, an abstract syntax element may be connected to multipleMappingElementsin the reverse direction. It is important to note thatMappingElements are capable of persisting non-structural state information in their VPM values.
To specialize this generic mapping metamodel for the Petri net domain, we follow the design pattern laid out in Figure 3.15 to define a subtype metamodel to encode traceability relationships between the abstract syntax (Figure 3.18 and concrete syntax (Figure 3.20) representations of Petri nets.
Example 13 (Petri net representation traceability metamodel) The refinement of the core meta-model to the Petri net diagram domain is shown in Figure 3.22. In this case, we have constructed a partialone-to-one mapping between the metamodels in Figure 3.18 and 3.20. Note this is still a metamodel, thus it represents a domain-specific variant of the core mapping concepts; also, certain details, e.g. containment relations betweenPNTopMappingandNodeMappingElements have been omitted from Figure 3.22 for the sake of retaining visual clarity.
Instance model example Figure 3.23 demonstrates how abstract, concrete, and trace metamodels are instantiated to create an interconnected, domain-specific instance model. The VTML syntax is shown in Figure 3.24.
Example 14 (Domain-specific Petri net instance models) In Figure 3.23, the Petri net consists of a placeP0 with a token Tok0, connected by an outarcOA0 to a transitionT0. This abstract syntax model, as shown with orange, is presented to the user by a tree view (top right). On the diagrams, a
3.4. DOMAIN INTEGRATION OVER THE VPM MODEL SPACE 55
1 d o m a i n( DSM );
2 m o d e l( D S M _ A b s t r a c t 2 C o n c r e t e _ C o r e M e t a );
3
4 e n t i t y( T o p M a p p i n g ) {
5 r e l a t i o n( diagram , T o p M a p p i n g , DSM . D S M _ C o n c r e t e S y n t a x _ C o r e M e t a . D i a g r a m );
6 r e l a t i o n( h i e r a r c h y , T o p M a p p i n g , DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . H i e r a r c h y );
7 e n t i t y( M a p p i n g E l e m e n t ) {
8 r e l a t i o n( d i a g r a m E l e m e n t , M a p p i n g E l e m e n t ,
9 DSM . D S M _ C o n c r e t e S y n t a x _ C o r e M e t a . D i a g r a m . D i a g r a m E l e m e n t );
10 r e l a t i o n( m a p p i n g s ,
11 DSM . D S M _ C o n c r e t e S y n t a x _ C o r e M e t a . D i a g r a m . D i a g r a m E l e m e n t , M a p p i n g E l e m e n t );
12 m u l t i p l i c i t y( m a p p i n g s ,o n e _ t o _ m a n y);
13 e n t i t y( N o d e M a p p i n g E l e m e n t ) {
14 r e l a t i o n( n o d e M a p p i n g , N o d e M a p p i n g E l e m e n t ,
15 DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . H i e r a r c h y . N o d e );
16 m u l t i p l i c i t y( n o d e M a p p i n g ,o n e _ t o _ m a n y);
17 }
18 s u p e r t y p e O f( N o d e M a p p i n g E l e m e n t , M a p p i n g E l e m e n t );
19 e n t i t y( E d g e M a p p i n g E l e m e n t ) {
20 r e l a t i o n( e d g e M a p p i n g , E d g e M a p p i n g E l e m e n t ,
21 DSM . D S M _ A b s t r a c t S y n t a x _ C o r e M e t a . H i e r a r c h y . E d g e );
22 m u l t i p l i c i t y( e d g e M a p p i n g ,o n e _ t o _ m a n y);
23 }
24 s u p e r t y p e O f( E d g e M a p p i n g E l e m e n t , M a p p i n g E l e m e n t );
25 } 26 }
Figure 3.21: The core mapping metamodel
concrete syntax model (yellow) is rendered where the token count is shown both graphically (bottom right) and in the properties view (bottom left). Not directly visible to the user, the system main-tains the trace model (shown in white), which encodes the logical mapping between the two model representations.
Synchronization driven by traceability models The PlaceMapping instance stores a reference value of 1, which is used to store the mapped value of theTokenCountattribute. As the user changes this attribute value by entering the new value in the Properties view, the system is expected to react automatically and adjust the number of token instances assigned to P0 in the abstract model (con-crete→ abstract synchronization). Symmetrically, should the user perform editing directly in the abstract syntax model (through the tree view), e.g. by adding another token to P0, the system should
Figure 3.22: Example of a mapping metamodel (Petri net domain)
Figure 3.23: Model instances
keep track of this change and apply the necessary modification to the graphical view by updating the tokencount attribute value.
The implementation of this synchronization semantics using model transformations is elaborated in Chapter 6.