MMooddel-Beaseld sSoftwIarneEnsginiederineg(MBOSE) iusa tsoftware engineering approach that promotes models to first-class artefacts of the software development and maintenance lifecycle. In MBSE, rigorously defined - and often domain-specific - models are used to capture the essence of (parts of) the system under development at an appropriate level of abstraction, and are then used to reason about Alfa Yohannis, Dpirmopietrrtiiess oKf tohleosvysotesm, F(ei.og.nvaia mPoodlealcckhecking and simulation), and eventually to produce low-level Departmeinmtplementation artefacts (e.g. source code, configuration scripts) in an automated fashion. MBSE of Computer Science has demonstrated a strong potential to drastically improve productivity and consistency in software UndievveelrospimtyenotfbyYroedrkucing development time [1], cost [2] and the probability of human-induced errors York[3,].UTnhiitseids wKidinelgydreocmognised in industry where studies (e.g. [4, 5]) have shown that model-based development is used extensively. fary506, dimitris.kolovos, fiona.pollackg@york.ac.uk and we present a roadmap for further work in this direction•. Validaoterdgaangiasinasttioandaolmacihn-asrptecmificodcoenls.traWinth(ethnat tnhoeemvpalloiydeaetidoirnectclyomnastnraagienst more than
• Transfiotrmveedriinfitoesa ntuhmabteraolflemthprloeyeeeerempoprltos y(pelaeisn temxtafinleasg,eonefefowreearchtehmanploy7ee) through a model-to-text transformation. Eacthherepmorotsdheolu-tldo-ctoenxtatinttrhaennsafomremoaftthioenemtphleoynee, and the
other employees, and I. INTRODUCTION names of her direct subordinates.
produces three text files that correspond to the employees in To reap the benefits of Model-Based Software EngineeFriignugres 3thaend 4 are twoInconsecutive versions Fofiga.samptlheeorganisationalucphadrattmedodel. When the model. the sequel, in 2, model is to in the context of large and complex systems, the abilviatylidattoion constraint is evaluated against the first version of the model (Figure 3), it verifies that all three emploryeefleescmtatnhaagteafenweewrtheamnp7lootyheereehmapsloybeeeesn,ahnidrethde (mRoidcehl-mto-otenxdt)traunnsdfoer mration then process large models in an incremental fashion as they epvroodluvcees thtrheee tmexatnfilaegs ethmatecnotrreosfpoJnedn.to the employees in the model. is essential. Current incremental model processing techniques only deliver limited performance benefits due to slow and imprecise model change detection capabilities or are limited to a single-developer environment; not realistic for real-world software development projects.
The research introduced in this paper aims at enaKbolloivnogs FFiigg.u1re. 3I:nIintiitaiallvveerrssioionnoofPfatthhreetBoo2rrggaanniissaattiioonnaall cchhaarrtt mmooddeell. MODIO flexible and high-performance incremental model processing through change-based model persistence. That is, instea dIn othfe sequel, in Figure 4, the model is updated to reflect that a new employee has been hired (Richmond) under the management of Jen. persisting snapshots of the state of models, we propose turnAinngon-incremental model validation engine, would treat the model of Figure 4 as if it was a models inside out and persisting their change historyn.ewThmeodel and would evaluate the constraint above against every employee in the model. An inproposed approach has the potential to deliver step-cchraenmgeental model validation engine on the other hand would identify that the previously established 14 performance benefits in incremental model processing, as well as a wide range of other benefits and novel capabilities.
The rest of the paper is structured as follows. Section II reviews the key-challenge of incrementality in MBSE. Section III provides an overview of existing approaches for identifying changes in models. Section IV overviews our proposed approach and Section V discusses our prototype implementation
FFigigu.re2.4:MMooddiified version ooffththeeoorgrgaannisisaattioionnaallcchhaarrttmmooddeellofoFfiFgiugr.e13. on top of the Eclipse Modelling Framework. The potseantistifaacltion of Athencoonns-tirnaicnrtefomr eenmtpalolymeeosdMeolsvsaalniddaRtoioyncaennnogtinhaevewboeuelndpotrsesaibtlythcoempromised benefits and novel capabilities, as well as the challengbeystheofchanmgeosdmealdoe,faFndigw.o2uldasonilyf riet-ewvaalsuaate ntheewcomnsotrdaienlt faonrJdenwaonudlRdicehvmaolnudatinestead. change-based model persistence, are presented in Sect. VISaimndilarly, a non-incremental model-to-text transformation, would generate all employee reports from scratchth(eoverwriting any previous versions ofethveemry19)e.mOn the contrary, an incremental modelconstraint above against ployee in the model.
Sect. VII respectively. Section VIII presents our evalutoa-tteioxnttranAsfnor minactiroenm, wenoutaldl idmenotdifyelthvatailtidonaltyionneedesngtoingeen,eorante tahenewotrheeprorhtfaonr dth,e new emstrategy and Sect. IX concludes this paper. managing an additional employee)—but not the reports of Moss or Roy, as these cannot have been affected by the changes made to the model.
While the overhead of executing transformations and
validation constraints on small models like the one in Fig. 2 is
negligible, non-incremental execution can become a significant
bottleneck for large evolving models. As stressed in Selic’s
seminal work [
As demonstrated by the pioneering work of Egyed [
initial execution of the queries; 2) Identify new and deleted elements and modified model
element properties in the new version of the model; 3) Combine the information collected in the steps above to identify the subset of (potentially) affected rules/queries/templates that need to be re-executed.
Listing 1. OCL constraint requiring that no employee directly manages more than 7 other employees. 1 context Employee 2 inv NoMoreThan7: self.manages->size() <= 7
of Fig. 1, an incremental OCL engine would compute the property access trace displayed in Table I as a side-product. Now, when the model is updated (Fig. 2), the execution engine can identify that:
which the constraint has not been evaluated; The value of the manages property of Jen (e3) has changed, and as such, it needs to re-evaluate the constraint on this model-element.
Egyed has shown that the property-access recording
approach is applicable to queries of arbitrary complexity, as long
as they are deterministic. More recent work has shown that
variants of this approach can be used to achieve incrementality
in a wide range of model processing operations, including
model-to-model transformation [
Notifications. In this approach, the incremental execution
engine needs to hook into the notification facilities provided
by the modelling tool through which the developer edits the
model, so that the engine can directly receive notifications
as soon as changes happen (e.g. a new employee (e4) has
been added, the name property of employee e4 has been
changed to “Richmond”). This is an approach taken by the
IncQuery incremental pattern matching framework [
Model Differencing. This approach eliminates the coupling
between modelling tools and incremental execution engines.
Instead of depending on live notifications, in this approach
the developer in charge of automated model processing, needs
to have access to a copy of the last version of the model
that the model processing program (e.g. the model-to-text
transformation) was executed upon, so that it can be compared
against the current version of the model (e.g. using a
modeldifferencing framework such as SiDiff [
In summary, incremental model processing currently delivers significant performance benefits only in a single-developer environment where the modeller is also responsible for performing all the (incremental) model processing operations.
2http://wiki.eclipse.org/Xpand/New And Noteworthy#Incremental
Generation 1 <session id="s1"/> 2 <create eclass="Employee" epackage="employee" id="0"/> 3 <add-to-resource position="0"><value eobject="0"/></add-to-resource> 4 <set-eattribute name="name" target="0"><value literal="Roy"/></set-eattribute> 5 <create eclass="Employee" epackage="employee" id="1"/> 6 <add-to-resource position="1"><value eobject="1"/></add-to-resource> 7 <set-eattribute name="name" target="1"><value literal="Jen"/></set-eattribute> 8 <create eclass="Employee" epackage="employee" id="2"/> 9 <add-to-resource position="2"><value eobject="2"/></add-to-resource> 10 <set-eattribute name="name" target="1"><value literal="Moss"/></set-eattribute> 11 <remove-from-resource><value eobject="0"/></remove-from-resource> 12 <add-to-ereference name="manages" position="0" target="1"><value eobject="0"/></add-to-ereference> 13 <remove-from-resource><value eobject="2"/></remove-from-resource> 14 <add-to-ereference name="manages" position="1" target="1"><value eobject="2"/></add-to-ereference> 15 <session id="s2"/> 16 <create eclass="Employee" epackage="employee" id="3"/> 17 <add-to-resource position="1"><value eobject="3"/></add-to-resource> 18 <set-eattribute name="name" target="3"><value literal="Richmond"/></set-eattribute> 19 <remove-from-resource><value eobject="3"/></remove-from-resource> 20 <add-to-ereference name="manages" position="2" target="2"><value eobject="3"/></add-to-ereference> model, it can readily identify the changes that have been made to the model since then (i.e. in session s2 - lines 15-20) instead of having to rediscover them through (expensive) state-based model differencing.
velopers need to either forgo incremental model processing altogether or to work around this limitation by manually steering model processing programs to process only subsets of their models, which is cumbersome and error prone.
We have implemented a prototype3 of the change-based
The ambition of this research is to enable high-performance model persistence format using the notification facilities proincremental model management in collaborative software de- vided by the Eclipse Modelling Framework. In our implemenvelopment environments by challenging one of the funda- tation we use the ChangeEventAdapter class, a subclass of mental assumptions of contemporary modelling frameworks EMF’s EContentAdapter4, to receive and record Notification5 and tools: as opposed to persisting snapshots of the state events produced by the framework for every model-element of models (which is what virtually all modelling tools and level change. frameworks currently do), we propose turning models inside Since not all change events are relevant to change-based out and persisting their change history instead. persistence (e.g. EMF also produces change notifications when Listing 3. State-based representation of the model of Figure 2 in (simplified) listeners are added/removed from the model), we have defined XMI. a set of event classes to represent events of interest. The event 12 <E<mmpalnoaygeeesxxmmii::iidd==""ee21""nnaammee==""JReony"">/> classes are depicted in Fig. 3 as subclasses of the ChangeEvent 3 <manages xmi:id="e3" name="Moss"/> abstract class. 45 </E<mmapnlaogyeese>xmi:id="e4" name="Richmond"/> whTichhe cCahnanagcceoEmvemntodcalatessbhoaths asinmgulelt-iv-vaalulueedd(ev.agl.uesseta/attdrdib)uoter
To illustrate the proposed approach, List. 3 shows a state- mutli-valued events (e.g. addAll/removeAll). ChangeEvent can based representation of the model of Fig. 2 in (simplified) also accommodate different types of values, such as EObXMI, and List. 2 shows the proposed equivalent change-based jects for EReferenceEvents, and primitive values (e.g. Integer, representation of the same model. Instead of a snapshot of String) for EAttributeEvents. The ChangeEvent class also has the state of the model, the representation of List. 2 captures a position attribute to hold the index of an EObject or a literal the complete sequence of change events (create/set/add/re- when they are added to a Resource, EReference, or EAttribute move/delete) that were performed on the model since its with multiple values (Lst. 2, line 3, 6, 9, 12, 14, 17, 20). creation, organised in editing sessions (2 editing sessions in Every time an EObject is added to the model, a CreateEObthe case of this model). Replaying these changes produces jectEvent and an AddToResourceEvent are recorded (lines 2-3, the same state as the one captured in List. 3, so the proposed 5-6, 8-9, and 16-17 in Lst. 2). When an EObject is deleted, or representation carries at least as much information as the state- moved to a containment EReference deeper in the model (Lst. based representation.
Such a representation is particularly suitable for incremental 3The prototype is available under https://github.com/epsilonlabs/emf-cbp. model processing. For example, if the model-to-text trans- em4fh/ettcpo:r//ed/uotwiln/EloCaodn.etcelnitpAsed.aoprtge/rm.hotmdelling/emf/emf/javadoc/2.11/org/eclipse/ formation discussed above “remembers” that in its previous 5http://download.eclipse.org/modeling/emf/emf/javadoc/2.11/org/eclipse/ invocation it had processed up to editing session s1 of the emf/common/notify/Notification.html
11, 13, 19) is recorded.
The ChangeEventAdapter receives EMF change notifications in its notifyChanged() method and filters and transforms them into appropriate change events. As an example of how notifications are filtered and transformed, Listing 4 shows how we handle Notification.UNSET events based on the type of the changed feature i.e. an UnsetEAttributeEvent is instantiated if the feature of the notifier is an EAttribute, or an UnsetEReferenceEvent is created if the notifier is an EReference. The transformed instances are then stored into a list of events in ChangeEventAdapter (changeEvents) for persistence. encapsulate all change recording functionality while the role of its concrete subclasses is to implement serialisation and de-serialisation. For example, CBPXMLResourceImpl persists changes in a line-based format where every change is serialised as a single-line XML document. In this way, when a model changes, we can append the new changes to the end of the model file without needing to serialise the entire model again. We have also implemented a CBPXMLResourceFactory class that extends EMF’s ResourceFactoryImpl, as the factory class for change-based models. Figure 4 shows the relationships between these classes.
eventually support multiple concrete change-based serialisation formats (e.g. XML-formatted representation for readability and binary for performance/size), we have created the CBPResource abstract class, that extends EMF’s builtin ResourceImpl class. The role of the abstract class is to
representation also has the potential to deliver a wide range of benefits and novel capabilities, compared to the currently prevalent state-based representations, some of which are discussed below.
With appropriate tool support, modellers will be able to “replay” (part of) the change history of a model (e.g. to understand design decisions made by other developers, for training purposes). In state-based approaches, this can be partly achieved if models are stored in a versioncontrol repository (e.g. Git). However, the granularity would only be at the commit level.
By analysing models serialised in the proposed representation, modelling language and tool vendors will be able to develop deeper insights into how modellers actually use these languages/tools in practice and utilise this information to guide the evolution of the language/tool. By attaching additional information to each session (e.g. the id of the developer, references to external documents/URLs), sequences of changes can be traced back to the developer that made them, or to requirements/bug reports that triggered them.
Persisting changes to large models after an editing session will be significantly faster compared to serialising the entire state of the model, as only changes made during the session will need to be appended to the model file. The performance and precision of model comparison and merging can be substantially improved, particularly for large models with shared editing histories.
challenges that this research will need to overcome.
Loading Overhead. While, as discussed above, persisting changes to large models is expected to be much faster and resource-efficient compared to state-based approaches, loading models into memory by naively replaying the entire change history is expected to have a significant overhead. To address this challenge, we will develop dedicated algorithms and data structures that will reduce the cost of change-based model loading (e.g. by recording and ignoring events – events that are later overridden or cancelled out by other events).
Fast-Growing Model Files. Persisting models in a changebased format means that model files will keep growing in size during their evolution significantly faster than their statebased counterparts. To address this challenge, (1) we will propose sound change-compression operations (e.g. remove older/unused information) that can be used to reduce the size of a model in a controlled way. (2) We will develop a compact textual format that will minimise the amount of space required to record a change (a textual line-separated format is desirable to maintain compatibility with file-based version control systems). (3) We will propose a hybrid model persistence format which will be able to incorporate both change-based and state-based information.
The findings of the research will be evaluated in the small in the context of the tasks in which they will be developed, and in the large through industrial case studies. For the first type of evaluation (in the small), where there are existing approaches that the algorithms and tools developed in this research seek to outperform (e.g. change-based incremental validation vs. state-based incremental validation), comparative evaluation will be conducted to assess the benefits and limitations of our approaches. For algorithms and tools that have no direct competitors in the literature, their contributions will be assessed in comparison to the baseline they seek to improve (e.g. in this case, persisting full change histories).
Through turning models inside out and persisting their change history, this research aims at enabling highperformance incremental model processing in collaborative development settings. The proposed approach also has the potential to enable model analytics, more fine-grained tracing and to improve the precision and performance of model comparison and merging. A prototype implementation of a change-based persistence format has been presented, the main envisioned challenges have been listed and an evaluation strategy has been outlined.
managed by Lembaga Pengelola Dana Pendidikan Indonesia (Indonesia Endowment Fund for Education).