Models are the keystones in model-driven systems development. They describe systems at di erent layers of abstraction and with a focus to di erent domains. For each domain, dedicated domain speci c visual modelling languages are used for model de nitions with the idea to separate concerns to di erent domain experts. This enables precise problem and requirement de nitions and should decrease e orts in developing and validating systems. We focus on multi-view models that are in relationship with source models by triple graph grammars. A multi-view model provides di erent views of the source model at different layers of abstraction but within the same DSL which is typically di erent from the DSL of the source model. In practice, elements in di erent views may overlap. We present an informal methodology for consistently propagating updates from one view to the other views and also to the source domain. We motivate our approach by multi-view models in a hospital scenario.
(source domain)
Room Number Capacity Person Name Date of Birth (DOB) Admission Date Assignment of person to room
Ward Name Patient Name Diagnosis (only for doctors) Assignment of patient to ward (target domain)
The running example is an example of a multi-view model in the target domain, that is in relationship with a model in the source domain. In practice, elements in di erent views may overlap. In the therapy domain multiview models exist in which all views share the same DSL. All views in the therapy domain are in relationship with the management domain. The management domain belongs to another DSL.
The research question which we want to answer informally in this paper is: If a model update in one view is performed, then how is it possible to consistently propagate this model update to all other views and also to the other domain?
This research question evolved during the work on an ongoing industrial applied research project with our industrial partner SES1 [GHE+13]. In this project, we apply triple graph grammars (TGGs) for translating source code of satellite control procedures to a visual model of the control ow of the same procedure. The visual model is an extended ow chart model that is extended to ful ll the needs of SES. The visualisation contains di erent abstraction layers leading to a multi-view visual model of the source code.
The hospital scenario in this paper illustrates the e ects of our approach, because it has seperate views for nurses and doctors. While this example can be alternatively implemented based on a central database with appropriate access rights, we like to emphasize that the approach can be used for much more complex scenarios like the industrial application for satellite operations described above.
The applied research project is a follow-up project of the large-scale industrial project [HGN+13], in which we successfully applied TGGs and also the model synchronisation framework based on TGGs [HEEO12, HGN+14].
Due to the success of the rst industrial project, we continued using triple graph grammars (TGGs) [SK08] as modelling technique in the second industrial project. The descision of using TGGs was made due to the following aspects: The formal framework of TGGs is comprehensive, well elaborated and it o ers di erent analysis techniques for correctness and completeness of the model transformation [HEGO14, HEO+15]. TGGs are speci ed by a set of triple graph rules that establish the relationship between a model in the source domain and a model in the target domain by simultaneously creating the elements of the source model and the elements of the target model with correspondences between them. In our case, the target model is the multiple-view model. Note that formally, we assume multiple views to be contained in one \big" model where user restrictions for accessing the views are left to the implementation details. Now, we introduce our running example based on TGGs in greater detail.
Example 1.1 (Hospital Scenario) Fig. 2 illustrates the detailed model of patients in a hospital and the correspondences between both. The model MManagement on the left depicts the occupancy of the hospital and is focused on the Management domain of the hospital. Patients are represented as persons that are assigned (asg) to rooms of speci c capacities. The model MT herapy on the right contains two views of the patients at di erent levels of abstraction and is focused to the Therapy domain. Nurses are able to access the names of the patients and the corresponding ward on which the patient is situated. Doctors have a more detailed view on the patients data. They can additionally access comments on the diagnosis of each patient. Moreover, dedicated nodes : PP de ne correspondences between the elements of the management model and elements of the therapy model. Each person corresponds to two patient nodes: One patient node in the nurses' view and one in the doctors' view. Rooms and wards are not related to each other in both domains. Furthermore, the doctors' view contains comments on the diagnosis of each patient that are neither contained in the nurses' view nor in the management model. The correspondences identify each patient in the nurses' view with a patient in the doctors' view and vice versa via a corresponding person node in the management model. The correspondences for a person are jointly created by applying a given triple graph rule. We assume that all elements that are jointly created by a rule, belong to each other.
t :asg
We informally introduce the derived propagation framework that is based on the model synchronisation framework using triple graph grammars [HEO+15], but rst, we review the underlying formal framework, i.e., the theory behind triple graph grammars in Sec. 2. Then, we informally present the consistent propagation framework of model updates in a given multi-view model using the running example in Sec. 3. Finally, we review future work and conclude the paper in Sec. 4 and present perspectives for future work in Sec. 5. 2
We review basic notions of the formal framework of our approach (cf. [EEPT06, EEGH15]) and address (multiview) models that are represented by typed attributed graphs [GLEO12] and triple graph grammars [SK08].
Typed attributed graphs are composed of nodes, edges between nodes, node attributes and types for nodes, edges and attributes. The typing is de ned by a type morphism between the typed graph (= instance graph) and a type meta-model, also called type graph.
A morphism M m! M 0 between two graphs M and M 0 is a structure preserving mapping from nodes, edges and attributes of M to nodes, edges and attributes of M 0. Structure preservation means that all edges in M are mapped to edges in M 0 such that the source and target nodes of the edge in M are mapped to the corresponding source and target nodes of the corresponding edge in M 0. The same for attributes. A morpism M m! M 0 between two typed graphs M and M 0 is additionally type preserving, i.e., nodes, edges and attributes are mapped to nodes, edges and attributes of the same type.
A triple graph M = (MD1 d1 MC d!2 MD2 ) [SK08, EEGH15] consists of graphs MD1 ; MD2 for domains D1; D2 and a correspondence graph MC with morphisms d1 : MC ! MD1 ; d2 : MC ! MD2 for de ning the correspondences between elements of MD1 and MD2 . In this paper, we use typed triple graphs, i.e., triple graphs typed over a triple type graph (cf. Ex. 2.1). (MAD1 tridp1leMgCrapdh!2 mMorDp2h)isamndMM 0 m!= (MM0D01betdw01 eeMn C0tridp!02le MgrD0a2p)hsis Mgive=n Mm= MDm1D1 d(1=)MmCC d2(=)MDm2D2 abnydmM=D2(mmDD!12; mMC D;0m2,Di2.e).,wmithcomnosrispthsisomf sthMreDe1mmorDp!1hisMmD0s1f;oMrCeacmh!Cof MthC0e M 0 = M D01 d01 M C0 d02 M D02 triples components. For morphisms m it holds that mD1 d1 = d01 mC and mD2 d2 = d02 mC , i.e., both parts of the diagram commute (annotated in the diagram with (=)), which means that correspondences between elements are preserved.
t
Example 2.2 (Triple Rules) The triple rules in Fig. 4 de ne how integrated models (triple graphs) of our hospital scenario are created. All elements that are enclosed by a NAC box are forbidden to exist in M so that the rule is applicable to M .
Rule 1 Ward creates a ward with name for the nurses' and doctors' view, but only if there does not already exist a ward of the same name (cf. NAC).
Rule 2 Diagnosis adds a diagnosis to an existing patient in the doctors' view.
Rule 3 Person-2-Patient assumes that there already exists a room in the management model and a ward with the given name in the nurses' and doctors' views of the therapy model. Then, the rule simoultaneously creates a
A graph transformation rule p : L l K !r R contains a left-hand side (LHS) graph L, a right-hand side (RHS) graph R, a context graph K and a span of inclusions l and r. Intuitively, l speci es the deletions and r the additions of the rule. An inclusion G !i G0 is a morphism with G G0.
ac p : L m M l (1) m0 l0
K MP r (2)
R tr : L tr R
m (3) M 0
M 0 ac M
A transformation step M =(=p=;m=)) M 0 is given by the application of p to a graph M via a match morphism m leading to the diagram on the right with commuting pushouts (1) and (2) and the result graph M 0. Intuitively, a pushout (1) over morphisms l; m0 is the gluing of graphs L and MP via common K resulting in graph M with morphisms m; l0. Rule p is applicable to M via match m, if pushouts (1) and (2) exist. Intuitively, the application of p to M via match m leads to M 0 which is obtained from M by deleting all elements M that are in L but not in K while preserving all elements of K in M leading to intermediate graph MP and nally, creating all elements that are in R but not in K.
A triple graph transformation rule L t!r R, in short triple rule, contains LHS triple graph L, RHS triple graph R and inclusion tr . From that it follows, that triple rules are only creating. The application of triple rules is analogue to general rules but restricted to a single pushout (3). Additionally, a (triple) rule may be equipped with negative (positive) nested application conditions, in short NACs (PACs), in order to restrict the application of the rule [HP09, EEGH15]. For a given rule and a match from the rule to a graph, a NAC (PAC) ac de nes a context for the matched graph part that is forbidden to exist (must exist) in order that the rule is applicable to the graph via the match.
Remark 2.1 (Short Visual Notation) In the remainder of the paper, we use the short notation of (triple) graph transformation rules. In detail, it means that elements, that will be added are marked with ++ and are annotated in green. Those elements are only contained in the RHS. All unmarked elements are contained in the LHS and RHS of the rule and will be preserved by the (triple) graph transformation rule. Elements that will be deleted are marked with and are annotated in red. Those elements are only contained in the LHS of the rule. Triple graph rules are non-deleting, i.e., the triple rules in Ex. 2.2 do not delete any element. Yet, we chose the same short notation for visualising the model update (which is deleting in our running example). 2:Diagnosis(d:String) C :Ward AN Name=n person with a name and its corresponding patient nodes with the same name in both views and its correspondences. Finally, the person node (and patient nodes) are assigned to a room (ward). The rule is only applicable, if there does not already exist a person of the same name in the management model.
Note that in order to create the graph of Fig. 2, additional rules are required that we implicitly assume but do not explicitly present. This comprises rules for creating rooms, DOB, and admission node attributes. 4
A triple graph grammar TGG = (MM ; ;; TR) over domains D1 and D2 consists of a triple type graph tMriMple=ru(lMesMTDR1 (cdf.1 FMigM.4C). dT!2heMlaMngDu2a)gfeorLd(TomGaGin)s=Df1Ma0njdtDhe2re(cefx. iFstisg.;3=)t=,r)theMe0mg ptthyatstiasrgtegnrearpathedanbdy aa sTeGtoGf is de ned by all triple graphs M 0 that are typed over MM and can be created by successively applying the rules tr 2 TR starting at the empty graph. The language L(TGG )D1 comprises all graphs of L(TGG ) but restricted to the graph component for domain D1. (And similar for L(TGG )D2 .) With L(MM ) (L(MM Di )) we de ne the set of graphs that are typed over type graph MM (MM Di for i = 1; 2). In general, L(TGG ) L(MM ), since, the graphs in L(TGG ) are additionally restricted by the rules of the TGG.
Example 2.3 (Languages of Triple Graph Grammars) Given the TGG = (MM ; ;; TR) over type graph MM of Fig. 3 and with rules TR of Ex. 2.2, then the triple graph of Fig. 2 is contained in L(TGG ). Therefore, graph MManagement is contained in language L(TGG )Management and graph MT herapy is contained in language L(TGG )T herapy. Furthermore, graph MManagement is also contained in L(MM Management) and graph MT herapy is also contained in L(MM T herapy). 4 3
We focus on consistent propagations of model updates. Therefore, we clarify the notion of consistency rst. Given a TGG over type graph MM = (MM D1 s MM C !t MM D2 ), then all graphs in L(TGG ) are called consistent integrated models. All graphs in L(TGG )D1 are called consistent models of domain D1 and all graphs in L(TGG )D2 are called consistent models of domain D2. A model update leads to state changes in models and is given by a span of inclusions u : M u1 MP u!2 M 0. All elements in M n u1(MP ) are deleted, all elements in MP are preserved and all elements in M 0 n u2(MP ) are created. An update is consistent, if M 0 is a consistent model. An update is called D1-update, if it leads to changes in models of domain D1 only and it is called D2-update, if it leads to changes in models of domain D2 only. If the model update is unknown, existing methods of di erence compution [EEGH15] can be used to obtain the update from the state-changes of models. De nition 3.1 ((Domain) Model Update) Given models M; M 0, then the update u = (u1; u2) between M and M 0 is given by a span of inclusions u : M u1 MP u!2 M 0. Given a TGG over triple type-graph MM = (MM D1 s MM C !t MM D2 ), then u is called a Di-domain update, short Di-update, if M; MP ; M 0 2 L(MM Di ) (i = 1; 2). A Di-update is consistent, if M 0 2 L(TGG )Di . With Di = fu j u is a Di-updateg we denote all updates in domain Di. 4 Example 3.1 ((Domain) Model Update) We consider the update illustrated in Fig. 5 (top) in the therapy domain of model M = MT herapy (cf. Fig. 2). Due to readability we present an extract of the model but implicitly u δu δu ...
:Patient Name=Mary Miller -Name=Marie Miller ++ ... :asg :asg :Ward -- Name=ENT :Patient Name=Mary Miller -Name=Marie Miller ++
:Patient Name=Marie Miller ++ assume the whole model. The update consists of the following steps: A nurse is correcting the name of patient Mary Miller to Marie Miller. Simultaneously, a doctor removes the assignment of this patient to ward ENT. Note that the update is not consistent w.r.t. the TGG of Ex. 2.3, i.e., M 0 62 L(TGG )T herapy. To be consistent, the name of Mary also needs to be updated to the same new name in the doctors' view and the assignment to the ward should not be deleted following rule 3 Person-2-Patient of Fig. 4. 4
The delta u of an update u speci es the update in mimimal context and is given by u restricted to those elements only that are touched by the update. This includes all elements that are created and deleted by u as well as the elements that are directly connected to them. The creating delta u of an update u is delta u but restricted to the created elements of u only.
Example 3.2 (Delta & Creating Delta) The delta u of update u Fig. 5 (middle) only contains those elements of u that are a ected by the update. The corresponding creating delta u of u is u but restricted to the created elements of u only. 4
The problem of propagating domain model updates according to a given TGG, is to extend them such that they t to the TGG, e.g., the update of Fig. 5 needs to be extended in order to also cover the change of Mary0s name in the doctors' view. The extension is performed by applying propagation operations. The propagation framework according to a given TGG is given by two total and deterministic propagation operations, one for each domain of the TGG. An operation is total, if for each valid input it leads to a result. An operation is determistic, if it has functional behaviour, i.e., it terminates and leads to a unique result for each valid input, and the operation does not require backtracking.
The propagation operation Ppg Di for one domain Di (i 2 f1; 2g) consists of the two steps Del and Add that are illustrated in Fig. 6. The following listing M = ( MD1 MC MD2 ) summarises the two steps of Ppg Di : ) Step Deletion (Del): Given a model M and a model update u, then the Del step deletes everything from M that is deleted by update u, rst.
Then, Del deletes everything that is related to the update in order to obtain a maximal consistent integrated sub-model (namely M 0) of M w.r.t. the given TGG. Thus, step Del propagates the deletion of elements along di erent views.
Step Addition (Add): The Add step works with two models: Model M (no deletion performed) and M 0 (the result of the Del step).
First of all, the Add step adds everything to M and M 0 that is created by update u. Then, markings are added to both models. Each element that is added by update u is marked with F (False, means: not translated). All other (untouched) elements are marked with T (True, means: translated). Afterwards, in the Ext sub-step, two special kinds of triple rules, are iteratively applied to M 0 and M , in order to change the F markers are to T. At the same time, elements M
M (a) uDel (b)
M uDel u Del (c) M D uDel u Del (d) uAdd uAdd M uDel u Del D (e)
M
uDel u Del
D uAdd (f) uExt may be reconstructed that were deleted during the Del step, but that are necessary to derive a consistent model. The special kinds of rules used are called shifted rules and consistency creating rules (CC rules). The latter are a special kind of shifted rules, which only change markers. The iteration stops when no F marker is available anymore (successful), or when no shifted (or CC) rule could be found that is applicable (abort). The derived propagation framework PPG (TGG ) returns the modi ed model M 0. If the derived propagation framework nishes successfully, then the returned model is consistent.
The derived propagation framework of model updates PPG (TGG ) summarises all propagation operations Ppg Di (i 2 f1; 2g). It is de ned as follows: De nition 3.2 (Propagation Problem & Framework) Let T GG = (MM ; ;; TR) be a triple graph grammar over triple type graph MM = (MM D1 s MM C !t MM D2 ) for domains D1; D2. A triple graph M = (MD1 MC ! MD2 ) 2 L(MM ) coincides with an update u : M MP ! M 0 2 Di , if M = MDi (i = 1; 2).
The Di-propagation problem is to construct an operation Ppg Di : UD ! Di from tuples UD = f(M; u; u) j u 2 Di ; M coincides with u; u is delta of ug of Di-updates Di on triple graphs with corresponding deltas to extended Di-updates (i = 1; 2).
The propagation framework PPG (T GG) = ( D1 ; D2 ; Ppg D1 ; Ppg D2 ) is given by all updates D1 ; D2 of domains D1 and D2 as well as total and deterministic propagation operations Ppg D1 ; Ppg D2 for both domains. 4
As illustrated in Fig. 7, intuitively, given a model M (a) and a model update u : M u1 MP u!2 M 0, then step Del rst deletes everything uDel = M n u1(MP ) from M that is deleted by u (b). Del additionally deletes everything u0Del from M that is related to uDel in order to obtain a maximal consistent integrated sub-model M nu0Del of M w.r.t. the given TGG (c). Thus, step Del propagates the deletion of elements along di erent views. In a rst sub-step of step Add those elements uAdd = R n (M n u0Del) are added to the model that are created by the update leading to model (M n u0Del) [ uAdd (d). Previously deleted elements D by Del may be recreated by this sub-step. Then, the models will be marked (e), which is used in the last sub-step, the extension sub-step. In applying shifted rules and CC rules, the model will be extended in order to derive a consistent integrated model (f ). We will review all steps in detail using the running exmaple.
Example 3.3 (Del Step) Applying the update in Fig. 5 to model M in Fig. 2 will delete the name of patient Mary Miller in the nurses' view as well as her assignment to ward ENT in the doctors' view of the therapy domain. The result of this rst sub-step is visualised in Fig. 8 (left). This completes sub-step Del in Fig. 7 (b).
Model I is a triple graph, where the Therapy domain is modi ed in the sense that the deletion part of the update u is performed on that domain, wheras the Management domain and the correspondence domain stay unchanged.
Afterwards, by following Rule 3 Person-2-Patient, Del additionally deletes the whole patient node of Mary Miller not only in the nurses' view but also in the doctors' view plus the corresponding : Person node in the management domain and the a ected correspondences : PP. This leads to the maximal consistent integrated sub-model M 2 (cf. Fig. 8) (right). (Note, the red elements marked with are deleted, i.e., they are not part of M 2 anymore. In Fig. 8) (right) they are visualised for better understanding of that step.)
Model M 2 can be created by a terminating sequence of rule applications with the triple rules in Fig. 4. Thus, the sub-model is consistent w.r.t. the given TGG (M 2 2 L(TGG )). This completes sub-step CCDel in Fig. 7 (c). 4
The Add step is divided into three sub-steps: The rst sub-step extends the model I (intermediate result from Del) and M 2 (result from Del) by the update delta u resulting in models M 0 and M R. This completes sub-step Add in Fig. 7 (d).
Afterwards, in the second sub-step, the extended models M R and M 0 will be marked via model M 2 (c.f. Fig. 10). This completes sub-step Marking in Fig. 7 (e).
In the third sub-step, the framework iteratively extends both models from the second sub-step according to the given set of triple rules T R in order to derive a consistent model satisfying the model update u and the corresponding TGG. Note that it may occur, that no consitent model can be derived. Then, the propagation will abort returning an inconsistent model. This completes sub-step Ext in Fig. 7 (f).
Example 3.4 (Add Step - Sub-Step 1) In detail, the update creates the attribute Name with updated value Marie Miller in the nurses' view (c.f. Fig. 9 (left)). As the corresponding : Patient node has been previously deleted by Del, the node together with the updated name attribute are added to the nurses' view. Therefore, the : Patient node is recreated. Furthermore, the deletion of the : asg edge is also applied to the nurses' view. The resulting model of the rst sub-step is shown in Fig. 9 (right). 4 Example 3.5 (Sub-step 2: Markings) Let us consider Fig. 10. Triple graphs M 0 and M R are marked via interface graph M 2 that is illustrated on the top. During marking, triple graph M 0 is enriched by the following markers: All elements that can be mapped by M 2 are marked with T, i.e., these are all elements that are not touched by update u. In detail, the : Person node of Polly Parker and the corresponding : Patient nodes including the correspondence nodes : PP of that person are marked with T. Additionally the : Room node and both : Ward nodes are marked with T. Furthermore, all attributes included by those nodes and all necessary : asg edges between those nodes and also from and to the corresponding : PP nodes are marked with T, too. All other elements of M 0 are marked with F, i.e., : Person and : Patient nodes of Mary Miller and the modi ed : Patient node of Marie Miller, including the contained attributes and the correspondence nodes : PP and the necessary : asg edges and edges between from and to the corresponding : PP.
Triple graph M R is enriched by the T and F markers accordingly. In detail, all nodes including the contained attributes concerning : Person or : Patient Polly Parker, respectievly, are marked with T. Beyond, all : Room and : Ward nodes and their attributes are marked with T and all edges between the mentioned nodes. In contrast, node : Patient and its attribute Name = Marie Miller get marker F. 4 I :PP :PP :PP :PP
Nurses View :Patient Name=Polly Parker :asg :Ward
:Patient Name=Mary Miller -- :asg Name=ENT
Doctors View :Patient Name=Polly Parker Diagnosis=Polyps
:Patient Name=Mary Mil er Diagnosis=Fraction :a-s-g :Ward :asg Name=ENT M D2
:Patient Name=Polly Parker :asg Diagnosis=Polyps
:Patient Name=Mary Miler Diagnosis=Fraction :PP :PP The third sub-step Ext extends the given domain update u such that the update ts to the given TGG. Therefore, Ext takes models MmRarked and M m0arked from the second sub-step of Add as input.
Sub-step Ext analyses the applicability of the triple rules tr 2 TR from the given TGG to MmRarked such that each application maximally overlaps with that part of MmRarked which is marked with F. From each overlapping triple rule that is applicable via a match, an operational rule, called shifted rule sr1, is derived which creates only those elements of the triple rule that do not overlap. Afterwards, Ext extends the maximal overlapping so that it \ ts" to M m0arked and consequently, a second shifted rule sr2 is derived. This will recreate necessary elements. With the help of the shifted rule sr2 and model MmRarked an intermediate model M Rmarked is derived. Finally, sr2 will be applied to M Rmarked and also to M m0arked leading to models MmRa0rked and M m00 arked, where the markings of overlapping elements will be changed from F to T ([F > T]). (For details, see Ex. 3.6). The markings T and F are introduced in order to control which part (elements) of an update already have been extended.
If such a shifted rule cannot be found, then the Ext step checks for complete overlappings, i.e., no elements will be created. In that case, a special kind of operational rule is applied which is called consistency creating rule (CC rule) [HEO+15]. Those rules only change markers from F to T.
Applications with empty overlappings are omitted unless they completely overlap with previously deleted elements. If the overlapping contains previously deleted elements, then the application is additionally maximally overlapped with previously deleted elements in order to guide the search for applicable matches. Therefore, previously deleted elements may be recreated in the extension process.
Then, models MmRa0rked and M m00 arked are taken as input for sub-step Ext again, as long as all elements are not marked with T or no rules are applicable any more. The successive application of shifted rules extends an update step-wise in the sense that the elements which are created by the update are complemented by those elements of the underlying triple rules which do not overlap with the update and therefore, could not be shifted but would also be created when applying the triple rules.
As, in all sub-steps of Add, previously deleted elements may be recreated, the proposed propagation framework prioritises creation over deletion. In contrast to propagating the deletion of elements by Del, step Add propagates the creation of elements along di erent views.
A shifted rule is derived from a triple rule by shifting elements from R to L resulting in new left- and righthand sides L and R. All elements of L in L and all elements of R are marked with T while the markings of the shifted elements is changed from F to T, i.e., K is L without F -markings. Shifted rules are a generalisation of consistency creating (CC) rules (c.f. Ex. 3.6). CC rules were de ned in the theory of model synchronisations to mark consistent integrated sub-models of possibly inconsistent models [HEO+15]. Given a triple rule tr : L ! R, the CC rule of tr is derived by shifting all elements from R to L. CC rules are used for applications (update extensions) based on complete overlappings of the underlying triple rule with previously deleted elements, i.e., CC rules only change markings from F (not translated) to T (translated). For update extensions, only shifted rules are of relevance where at least one element is shifted, i.e., the shifted rule is relevant. This omits applications of shifted rules which do not overlap with the elements that are created by the update and therefore are of no importance concerning the update. Furthermore, shifted rules have to be maximal in the sense that they should shift and match as much as possible elements such that the overlappings are maximal and only the non-existing (non-overlapping) elements of the underlying triple rules are created by their application. Example 3.6 (Relevant Maximal Shifted Rule & CC Rule) Given model MmRarked as illustrated in Fig. 10 (bottom, right), triple rule Person-2-Patient (Rule 3) from Fig. 4 and Fig. 11 (1), respectively, and a decomposition d of Rule Person-2-Patient. Intuitively, the shifted rule that results out of the decomposition d shall \ t" to triple graph MmRarked, i.e., additionally to all elements from the LHS of triple rule Person-2-Patient, it shall contain the : Patient node including the Name = Marie Miller attribute in the nurses' view. Technically, this is achieved in the following way: Let d : L ! L0 ! R be given by the LHS L of Rule Person-2-Patient and L0 which additionally contains node : Patient and its attribute Name = Marie Miller in the nurses' view. Therefore, decomposition d controls the shifting of elements from R towards L. The rule Person-2-Patientdtemp : L K ! R in Fig. 11 (3) is a relevant maximal shifted applicable rule of rule Person-2-Patient w.r.t. d and MmRarked. It is an operational rule derived from triple rule Person-2-Patient (cf. Fig. 11 (1)).
The application of the shifted rule updates the markings of the two shifted elements from F to T (F > T). The additional elements in the NAC are all marked with T. The shifted rule is relevant, as, two elements were shifted, i.e., L and L0 are not isomorphic (L 6= L0). Beyond, the rule is maximal shifted and applicable w.r.t. MmRarked, as, there exists an applicable match from L to MmRarked and no further elements can be shifted such that a new \extended" applicable match is obtained.
In Fig. 11 (4) a second shifted rule Person-2-Patientd : L K ! R is illustrated. It is a relevant maximal shifted rule w.r.t. OmRarked (c.f. Fig. 13). There, the following elements were shifted to L: 1. the two : Patient nodes, 2. the Name attribute with value nP of the nurses' view, 3. the : Person node, 4. the three : asg edges, 5. the two : PP nodes and 6. the four edges starting at the two : PP nodes.
Again, the RHS R of rule Person-2-Patientd is K, but extended by the Name attribute of node : Person of the
R O marked management model and the Name attribute of node : Patient in the doctors' view.
The rule Person-2-PatientCC in Fig. 11 (2) is the CC rule of rule Person-2-Patient. All elements are shifted from the RHS towards the LHS. Therefore, when applying a CC rule no elements are created but the markings of the shifted elements are updated from F to T. The markings of all other elements remain T. 4 Example 3.7 (Sub-step Ext of Add in Great Detail) The Ext sub-step uses the marked models from the second sub-step of Add as input. This initial situation is illustrated in Fig. 10.
1st iteration: First, Ext checks, if a shifted rule can be found with regard to the models M 0 marked (c.f. Fig. 10). This is not possible. A shifted rule can be found with match to M which is shifted rule Person-2-Patientdtemp (c.f. Fig. 11 (3)). This situation is shown in Fig. 12, where the match is explcitly illustrated with black dots. Based on this \small" shifted rule, an \extended" shifted rule Person-2-Patientd (c.f. Fig. 11 R marked and M
R marked (4)) is derived. Then, an intermediate model OmRarked (c.f. Fig. 13) is constructed. (For details: We create an e ective pushout (c.f. Def. 4.23 in [EEGH15]) via M m0arked, MmRarked and Person-2-Patientdtemp. Intuitively in sets, an e ective pushout E is the union of B and C over a common D, whereas D is the intersection of B and C over a common A.)
There, we can see that all elements are reconstructed that are necessary for the application of shifted rule Person-2-Patientd, i.e., elements that we want to restore. In detail, these elements are:
The : Person node and its assignement : asg to the correct : Room in the Management domain. The empty : Patient node in the doctors' view. Note, the assignement to the correct : Ward is not reconstructed, because the deletion of this edge is part of upadate u.
The correspondence nodes : PP between the : Person and both corresponding : Patient nodes in the Therapy domain.
Note, all reconstructed elements are marked with F. Now, shifted rule Person-2-Patientd will be applied resulting in triple graphs M m00 arked and MmRa0rked (c.f. Fig. 14). Both models are used as input for the next iteration of the Ext sub-step.
2nd iteration: Again, Ext checks successively, if a shifted rule can be found. DiagnosisCC(d:String) Now, this is not applicable. Instead, we can nd a CC rule that is applicable. Doctors View We consider CC rule DiagnosisCC shown on the right that is derived out of triple rOumRle0ar2kedDi(augsninosgise (ce.cftivFeigp.u4s)h.outA)gtahiant, iws eexctaelncdueladtebyantheinDteiramgneodsiaisteatttrriipbluetegrwaipthh [F>T[]TD]:iPaagntieonsits=d marker F. Then, CC rule DiagnosisCC will be applied to both models in Fig. 15 resulting in triple graphs M m000arked and MmRa00rked (c.f. Fig. 16). The latter models are used as input for the next iteration phase of the Ext sub-step.
Next iterations: We combine the next steps, because in our running example, they are similar to the 2nd iteration phase, because only CC rules are still applicable. They handle the following two attributes contained in node : Person of Marie Miller in the Management domain: a) DOB = 06 09 1988, nishes successfully and returns model MmRa4rked (c.f. Fig. 17 (right)). The other model M m5arked (left) will be discarded. The propagation ends successfully, because all translation markers are set to T, i.e., a consistent triple graph could be derived. As visualised in model MmRa4rked, the derived propagation framework PPG (TGG ) reconstructed all necessary elements that were deleted in the Del step, although deleting those items was not intended by the user. Note, that the : asg edge from the : Patient Marie Miller to the corresponding : Ward in the doctors' view is restored, too, even though the deletion of this edge was part of update u. This is an example for the priorisation of addition over deletion of the PPG (TGG ) framework. 4
Finally, in combining all steps that were informally introduced in this section, the derived propagation framework PPG (TGG ) can be de ned.
De nition 3.3 (Derived Propagation Framework) Given a TGG over domains D1 and D2, then each propagation operation (Ppg Di )i=1;2 of the derived propagation framework PPG (TGG ) is de ned by the sequence of steps according to Rem. 3.1. 4 Remark 3.1 (Derived Propagation Framework) Given a TGG = (M M; ;; T R) over type graph M M and with a set of triple rules T R. Furthermore, given a triple graph M and a consistent domain model update u.
Then, the derived propagation framework PPG (TGG ) applies update u on M and derives a consistent model M 0 in executiong the following steps: 1. Del step, 2. Add step consiting of sub-steps: (a) sub-step 1, rst addition, (b) sub-step 2, i.e., marking, (c) sub-step 3, extension Ext is executed iteratively. 4 4
The presented propagation framework assumes that the underlying TGG is deterministic. As TGGs are nondeterministic in general [HEO+15], we introduced a technique for obtaining deterministic sets of operational rules in previous work. The framework of concurrent model synchronisations [HEEO12, GHN+13] is equipped with an additional rst step for deriving consistent model updates from inconsistent ones. In contrast to the present paper, model synchronisations do not deal with propagating model updates across one model but propagating model updates between two models of typically di erent domains, called source and target domains. A consistency creating operation CCS (CCT) is used for converting inconsistent updates in the source (target) domain to consistent updates. However, in contrast to our approach, both operations simply neglect inconsistent model updates u without trying to propagate them across the model, i.e., both operations are not delta-preserving. We have motivated our approach by multi-view models but the approach can also be applied in other contexts where consistent model updates and models are requested and consistency is de ned in terms of the language L(TGG ) that is induced by a TGG. The theory of correct and complete model transformations [DXC+11, HEGO14] and model synchronisations [HEEO12, GHN+13, HEO+15] rely on consistent domain models and consistent model updates based on TGGs.
Independently from the present approach, another solution for multiple views based on the existing theory of model synchronisations [HEO+15, EEGH15] may be feasible. Assuming a separate model and TGG for each view, then model updates in one view may be propagated back to the source model at rst, followed by a forward propagation from the source model to the other view. This solution does not only di er in the assumption of separate models and TGGs for each view from the presented approach, but also rises questions concerning the con ict resolution of simoultaneous updates in several views. Furthermore, it is unclear how to deal with updates of elements that are only contained in the views but not re ected by the source model. The propagation of an update is performed over the source model and therefore, the update would be lost. Developing such a solution and relating it to the presented approach is topic of future work.
Another approach that is related to multi-view models are view triple graph grammars (ViewTGGs) [JKS06, JS08, ARDS14]. In our presented running example, the target domain can be interpreted as ViewTGG. The nurses' view is a view of the doctors' view. In order to apply the theory of ViewTGGs to our running example, we should divide the information in the target model in a second triple graph grammar: one domain contains the doctors' view, the other the nurses' view. Then, we can apply the model synchronisation techniques in [ARDS14]. However, the approach we presented in this paper is more exible and is also able to deal with models, where the concept of ViewTGGs cannot be applied, but where elements in one domain are still strongly interweaved with each other. 5
We presented a rst informal idea of a derived propagation framework for consistently propagation model updates along di erent views in multi-view models. This framework extends the existing TGG-based model synchronisation framework by propagating changes also between related elements within one domain. We plan to present a formal elaboration of this framework in future work. Furthermore, we want the framework to ful ll the following properties that we will prove using the formalization of the presented propagation framework. 1. The propagation shall preserve identity. 2. The propagation shall always yield consistent results. 3. If the given model update is consistent, then the propagation shall yield a consistent result. 4. The propagation shall always return a single result. 5. The propagation shall have functional behaviour, i.e., the propagation shall terminate and shall be deterministic [EEPT06]. Termination and determinism lead to functional behaviour, i.e., for the same model M , the propagation shall always produce the same result.
It is also desired, to implement the approach as an extension to the existing model transformation tool HenshinTGG [Hen15]. HenshinTGG allows the speci cation and execution of model transformations between source and target languages based on TGGs. It also provides an implementation of synchronising consistent model updates from source to target and vice versa based on the theory in [HEEO12, GHN+13, EEGH15]. Therefore, an implementation of the approach would enable the synchronisation (complete transformation) of inconsistent source and target updates (models) in HenshinTGG.
Furthermore, we plan an evaluation of the presented technique on the real world scenario which we introduced in Sec. 1 where source code of satellite procedures is transformed to multi-layered statecharts [GHE+13]. Each layer represents one view of the source code at a di erent level of abstraction. As views of adjacent levels of abstraction may contain overlapping elements, updates made in one view should be consistently propagated to adjacent views. This enables the synchronisation of the extended update back to the source code by using the implementation mentioned above.
Furthermore, the derived propagation framework, we introduced in this work, considers only model updates in the same domain and also in the same view at this stage. We want to investigate more complex updates in future work. There, it is also relevant to anaylse the propagation of con icting model updates. These con icts may lead to situations where no consistent model update can be obtained by the update propagation and a manual con ict resolution is required. This leads to the notion of con icting updates that may be forbidden for users as their propagation may yield side e ects that are not transparent to the user. For a given model transformation, we plan to provide a construction for obtaining a set of constraints that specify forbidden updates on consistent multi-view models. These constraints can be used directly in order to restrict the user's behaviour.
In addition, we plan to investigate to what extent an additional step for automatic con ict resolution [EET11] as used in concurrent model synchronisations [HEEO12] is bene cial for our approach.
Furthermore, the alternative approach for update propagation between views from Sec. 4 is promising enough to be investigated in future work.
Acknowledgments Supported by the Fonds National de la Recherche, Luxembourg (3968135, 4895603). [BBG05]
Sami Beydeda, Matthias Book, and Volker Gruhn. Model-Driven Software Development. Springer, 2005. [EET11] [Hen15]
HenshinTGG. https://github.com/de-tu-berlin-tfs/Henshin-Editor, 2015.