Towards Collaborative Modeling Using a Concern-Driven Version Control System Omar Alam Vasco Sousa and Eugene Syriani Trent University University of Montreal Peterborough, ON, Canada Montreal, QC, Canada omaralam@trentu.ca {dasilvav, syriani}@iro.umontreal.ca Abstract— This paper presents an approach for collaboration reuse unit, called concern, that enables broad-scale model in modeling that builds on ideas of Concern-Oriented Reuse reuse. Whereas developers in existing collaborative environ- (CORE). CORE is a novel reuse paradigm that supports ments collaborate to develop classes of a code/model base, in broad-based model reuse. We leverage the ideas of CORE and version control systems to support collaborative modeling of our approach, modelers collaborate to incrementally model reusable concerns. We capture our ideas in a metamodel and the features belonging to a CORE concern. We capture our demonstrate our approach by collaboratively modeling a drone ideas in a metamodel and demonstrate our approach through system concern. modeling an autonomous drone system collaboratively. We believe that our reuse-focused, feature-driven, collaborative I. I NTRODUCTION and incremental modeling approach allows modelers to better Nowadays, software developers extensively use version distribute development effort among themselves, manage control systems (VCS), such as the Git [1] repositories, development life-cycle activities, and increase productivity to collaborate and track development activities throughout and time to market. their projects. These systems allow developers to organize In the following section, we provide background infor- and distribute the development effort among themselves, mation on CORE and introduces our running example. In keep track of issues and bugs, and schedule the delivery Section III, we present how we support versioning in CORE. of releases. In addition, the success of reuse in software In Section IV, we discuss the lessons learnt in modeling the development as exemplified by, e.g., class libraries, services, drone concern. In Section V, we present related work and and components facilitated collaboration and coordination conclude in Section VI. during software development activities. A developer now can reuse the artifacts developed by other developers through II. BACKGROUND ON CORE the reuse interfaces of these artifacts. Together with VCS CORE [4], [6] is a new software development paradigm and repositories, advances in reuse allowed software devel- inspired by the ideas of multi-dimensional separation of con- opment activities to be more organized and collaborative. For cerns [7]. CORE builds on the disciplines of MDE, software example, a group of developers can use a Git repository to product lines (SPL) [8], goal modeling [9], and advanced collaborate in coding the classes of a software program, and modularization techniques offered by aspect-orientation [10] another developer can reuse these coded classes. to define flexible software modules that enable broad-scale However, despite these advances in the programming model-based software reuse. CORE introduces a modular world, application of VCS in model-driven engineering unit of reuse called concern which encapsulates a set of (MDE) is still in its infancy. For MDE practitioners, a VCS software development artifacts, i.e., models and code, de- is mostly used to keep track and collaborate in the develop- scribing all properties of a domain of interest during software ment of models [2]. However, unlike VCS repositories for development in a versatile, generic way [4]. The models programs, reuse of models in repositories through VCS is within a concern can span multiple phases of software still a challenge in MDE [3]. Enforcing consistent reuse is development and levels of abstraction (from requirements, necessary to cope with the growing complexity of software analysis, architecture, and design models to code). Concerns systems. Nevertheless, modelers usually create models from decompose software into reusable units according to some scratch because modeling languages offer limited support to points of interest [11], [12] and may have varying scopes, reuse existing models and modeling tools in general are not e.g., encapsulating several authentication choices, commu- shipped with a library of reusable models. Lack of support nication protocols, or design patterns. The main premise for reuse limits the potential of VCS in MDE, as checking of CORE is that recurring development concerns are made out, committing, and updating models that cannot be reused available in a concern library, which eventually should cover will not be very useful for collaborative environments. most recurring software development needs. Similar to class This paper tackles the aforementioned issues by leveraging libraries in modern programming languages, this library the ideas of Concern-Oriented Reuse (CORE) [4], [5] and should grow as new development concerns emerge, and VCS to support collaborative modeling. CORE defines a new existing concerns should continuously evolve as alternative E0 System Behavior E2 E3 E2 E1 E6 FlyingMinimum FlightPath FlyHome BatteryWarning ForcedLanding Altitude E7 E6 E6 Unobstructed SShapeFlight MinimumBattery Takeoff Fig. 1. Drone product line feature model architectural, algorithmic, and technological solutions be- Figure 1 is the starting point of the incremental modeling come available. Applications are built by reusing existing effort. After that, we modeled other features incrementally concerns from the library whenever possible, following a in a process detailed in the next section. Each feature is well-defined reuse process supported by clear interfaces. The realized by a realization model modeled as a state machine. same idea is applied to the development of concerns as well: When the user of a concern makes a feature selection (i.e. high-level/more specific concerns can reuse low-level/more configures the concern), a customized concern is generated generic concerns to realize the functionalities they encap- by composing its realization models [5]. sulate. In the end, the architecture of a software developed The state machine shown in Figure 2 realizes the root with CORE takes the form of a concern hierarchy (directed, feature by modeling the basic behavior of a drone system. acyclic graph), thus supporting hierarchical modularity [13]. This state machine consists of a sequence of states that define CORE advocates a three-part interface [5] to describe each the different stages of a drone’s operation. For example, the concern and enable its reuse: the variation interface for state TakeOff provides the minimum behavior required to exposing decisions (using a feature model [14]) and their take off, which will be further refined to include additional impact on system qualities (using an impact model [15]); behavior. A realization model can extend another realization the customization interface to adapt the chosen variation to model [4] to have a complete excess to the structure and the a specific reuse context (customization is here used with a behavior of the extended model. different meaning than in the SPL [14] paradigm); and the The realization model for the feature FlyHome shown in usage interface to trigger the functionality encapsulated by Figure 3 refines the base realization model of the root feature the customized concern. In CORE, models are built for the (Figure 2) to define the behavior of the Descend state. When root phase and all follow-up phases using the most appro- we specify that FlyHome extends SystemBehavior, FlyHome priate modeling formalisms to express the properties of the will have complete access to the states and transitions defined concern that are relevant during each phase. Consequently, a in SystemBehavior, hence, there is no need to re-define them concern is typically described by many modeling notations, again. Realization models in CORE often extend each other (e.g., based on the Unified Modeling Language (UML) [16]), and produce a complex extension hierarchy [17]. Realization but can also offer other language mechanisms (e.g., aspect- models in the upper levels of the extension hierarchy often oriented features). also designate the concern-partial elements [4] that must be concretized within the concern. These elements are noted A. Running example: drone system with a disjoint bar symbol preceding the element name, To illustrate the ideas of CORE, we use the example of such as states Fly and Descend as shown in Figure 3. developing a drone concern. This concern is part of a larger Their role is to define generic properties shared by a set surveillance system. It describes the behavior of different of realization models, but require to be completed with variants of a drone system with surveillance purposes. We additional properties in order to function correctly. modeled this concern following the ideas of incremental Breaking down the concern into small realization models modeling in CORE. A concern is built by adding small that are modeled incrementally allows adding the incre- model increments to some base models. In other words, ment when the knowledge required to model it becomes instead of creating large monolithic models of a concern for available. It also allows multiple modelers to collaborate each variation, the model is decomposed into many small when developing the concern, with each modeler being realization models. The feature model [14] of this concern responsible to model a particular set of increments. Further- is shown in Figure 1 which presents the common and varying more, incremental modeling in CORE allows the concerns features to make the drone system work properly. This to continuously evolve by adding features as needed by the feature model is part of the concern interface and is modeled reusing concern/application. incrementally. The root feature DroneSystemBehavior in In the next section, we discuss how we leverage the CORE model SystemBehavior realizes SystemBehavior Variables: toTakeoff startPos Operational on toTakeoff toFly toLand landed Off Start Take Off ¦ Fly ¦ Descend Landed e: startup() e: startPos = getGPS() rise() off Shutdown e: shutdown() Fig. 2. Base drone behavior Statechart model FlyHome realizes FlyHome extends SystemBehavior Variables: min on startPos Off Start Shutdown dir toTakeoff off e: startup() e: shutdown() Operational Descend Take Off ¦ Fly toFly toLand e: startPos = getGPS() Align rise() e: rotate(1) dir = 1 landed Landed [isAligned(startPos)] Descend getGPS() = startPos GoForward e: descend() e: goForward() dir *= -1 toTakeoff Fig. 3. Realization model of the FlyHome feature concepts to support collaborative modeling. We show how mechanisms of the modeling language are responsible to multiple modelers participate in incrementally modeling an derive the common model for a particular feature selection example drone concern. [17]. Since a concern is designed in a modular way, the relationships between features and the dependencies between III. S UPPORT FOR V ERSIONING IN CORE realization models set the course for collaboration: easing the In this section, we present how we leverage the concepts of process of assigning tasks to collaborators. CORE, such as reuse, incremental modeling, interfaces (es- pecially the variation interface) to support collaborative mod- A. Extension of CORE metamodel eling. We present an approach that allows multiple modelers The concepts of CORE are captured by a metamodel to participate in developing a concern through the support of and supported by a reference implementation [4] that allow a concern-driven VCS. In the example discussed later in this different modeling languages to support concern-orientation. section, each modeler is responsible to model a particular We extend this metamodel with new concepts to support feature of a concern after discussing with the development versioning and collaborative modeling. Figure 4 presents team. The feature tree of the concern is built incrementally a simplified view of the extended CORE metamodel. The by extending the realization models, and collaboratively by shaded classes depict the new concepts that are added to assigning features to different modelers. The CORE com- CORE to support versioning, while the others are the existing position algorithms, along with the composition/refinement CORE concepts related to incremental modeling, reuse, and COREModelElementComposition comps COREModelComposition 0..* mR 0..* reuse 1 COREMapping COREModelExtension COREModelReuse COREConfiguration COREReuse 0..* mE 1 reuses 0..* mR 0..* selConf 1 from 1 to COREModelElement source 1 rC modelElements COREModel visibility: COREVisibilityType 1 1..* 1 COREConcern 0..* partiality: COREPartialityType models concern 0..* models 0..* realizedBy realizes 0..* 1 0..* selected /features COREFeatureModel COREFeature 0..* featureModel 0..* reexposed {subsets} timeline 1 <> COREVisibilityType COREEvent events COREBranch branches CORETimeline concern -id: String public 0..* 1..* -author: String to 1 to 1 CORERelease COREFork CORECommit COREMerge -releaseNo: String Fig. 4. A simplified CORE metamodel. composition. As shown in Figure 4, a COREConcern con- B. Development timeline tains a timeline (CORETimeline) which is the development The extension to the CORE metamodel allows us to timeline maintained by the VCS. The timeline has branches develop our DroneSystem concern incrementally and retain a (COREBranch) which contain events (COREEvent). An event trace of its development. Figure 5 illustrates the development can be a merge (COREMerge), fork (COREFork), commit timeline of the concern that we, the three authors of this (CORECommit), or release (CORERelease). These concepts paper, followed. It shows the branches used to organize and are closely related to the concepts of VCS, such as Git [1]. divide the development effort. Figure 5 also includes the Each versioning event is linked with the set of features of sequence of events we created. The numbers in Figure 1 the concern that the modeler modified or added. COREEvent illustrate the order of the events in which the features were has a link to COREFeature to allow the versioning event modeled during the development timeline. to be associated with the concern’s features. This link is In the beginning, we discussed and collaborated to model derived from the link between COREEvent and COREModel, the root feature DroneSystemBehavior (i.e., the base realiza- which allows an event can be associated with any kind of tion model shown in Figure 2), which depicts the minimum model in CORE (including feature models, impact models, behavior of the drone system. After the feature DroneSys- and models of the CORE-based modeling languages). These temBehavior was developed, we did the first commit in the events follow the standard semantics as in common VCS. A concern’s timeline at event E0 as shown in Figure 5. After developer can create a release if (1) all generated customized that, we added features that add details to the behavior of the concerns correctly satisfy the constraints of the feature model root feature. The modelers collaborated in adding an optional and (2) all concern-partial elements are concretized in at least feature FlyingMinimumAltitude, which guarantees that a drone one generated customized concern. only operates at a minimum safety altitude. This feature As discussed in [4], [17], COREFeatures realize a set of refines the TakeOff state in DroneSystemBehavior. realization models. The realization models are linked with di- At this point, we decided to work separately in different rected extension dependencies (COREModelExtension). The branches to speed up the development time. Therefore, we association realizedBy/realizes between COREFeature and forked two additional branches were created at event E1 , COREModel encodes which realization model belongs to and the modelers decided to model a separate feature in which feature. A CORE-based modeling language will sub- each branch. In one branch, the BatteryWarning feature was class from COREModel, and in our case, COREStatechart- modeled, which monitors whether the drone has enough Model (not shown in Figure 4) subclasses COREModel so battery to operate, and issues a warning if it reaches bellow that all the fine-grained changes in the statecharts are still in 20% of capacity. In another branch, FlightPath was modeled CORE. as mandatory feature that defines the flight path procedure FlyHome E4 UnobstructedTakeOff + ForcedLanding E8 System FlyingMinimum Behavior E0 Altitude E1 BatteryWarning E3 E5 MinimumBattery + ForcedLanding E6 E2 E7 FlightPath FlightPathSShapeCoverage - Commit - Release - Fork - Merge Fig. 5. Development timeline to cover a particular area. In the third branch, FlyHome was several factors that should be taken into account when also modeled as a mandatory feature to specify the behavior creating a new branch or assigning modelers to a branch. of returning back to the starting coordinates when the drone Usually, a branch is created to distribute the modeling effort is asked to land. by assigning modelers to branches, hence, speeding up the When modeling of these features were completed, they development. Furthermore, a new branch can be created to were merged with each other. First, the FlightPath branch assign the expert(s) for modeling particular feature(s) to that was merged onto BatteryWarning branch at event E2 . Then, branch. Therefore, branches can be used to organize the the FlightHome branch was merged onto the BatteryWarning development team, i.e., modelers can be assigned according branch at event E3 . It is important to note that we could to their specialization and expertise, and their authorship designate one of the three branches as the main branch of the changes such as commit and merge can be traced and the two other as secondary branches as the way it is (COREEvent has an author attribute as shown in Fig. 4). done in Git. In that case the BatteryWarning branch could Modelers can also be assigned based on their experience be designated as the main branch that other branches merge in the concerns that are going to be reused by features of a onto. After the merge at E3 , the modelers decided that there branch. For example, if a feature or group of features should the current features of the concern are sufficient to make a reuse a security concern, then a branch can be created to release. model those features and modelers who are expert in security The concern is now released at E4 with five features: can be assigned to that branch. DroneSystemBehavior, FlyingMinimumAltitude, FlightHome, In addition, branches can be created to partially model BatteryWarning and FlightPath. After that, we forked a feature, i.e., a branch can be created to model some branches again to model three additional features, Unob- realization models of a feature, but not all of them. This will structedTakeOff, MinimumBattery and SShapeFlight. Unob- be particularly useful for concerns that encapsulate models structedTakeOff ensures the drone only operates if it can created using different modeling notations. For example, in reach its minimum operation altitude without obstructions. a concern that encapsulates requirement and design models, The MinimumBattery feature ensures the drone only stays a branch can be created to model the requirements models airborne if it has enough battery to operate and return to its of the concern and can be merged with other branches that origin point. Finally, SShapeFlight directs the drone to fly are also modeling requirements. Then new branches can repeatedly in a specific S shape to cover an area. be created to model the design models. In this situation, When we merged the branches that modeled Unobstruct- branching is helpful for planning the development activities edTakeOff with MinimumBattery, we discovered that there is according to software process that is being followed by the a conflict that occurred as a result of a particular behavior development team. However, modelers need to careful not to (ForcedLanding) in both models. We discuss how we re- branch or merge when there are invalid feature or realization solved this conflict in the next section. After all branches models. Automatic verification and validation methods can were merged, we had a feature model that contains all be used verify the consistency and correctness of the models the features that we intended the drone system to have. in a branch [18]. Therefore, we released a second release for this concern at E8 . B. Evolution of the feature model In the previous section, the features of the drone system IV. D ISCUSSION are added incrementally through the collaboration of three We discuss some of the benefits and reasons for collabo- modelers. Initially, all three modelers participated in mod- rative modeling using our approach. eling the root feature, which was committed at E0 . Then, each modeler modeled a separate subfeature of the root in A. Reasons for branching the branches created at E1 . Since concerns are modeled The example in the previous section assigns one modeler incrementally, either by adding realization models or by per branch to model one feature. This is not a constraint reusing other concerns [17], [4], it is not unusual that more in our approach. Depending on the context and the nature than one modeler participates in adding the increments. In of the concern, any number of modelers can be assigned some cases, all participants can collaborate on modeling a to a branch to model any number of features. There are single feature as in the case of modeling the root feature model MinimumBattery realizes MinimumBattery, ForcedLanding extends SystemBehavior Variables: charge on min Off Start Shutdown startPos toTakeoff off e: startup() e: shutdown() Operational toLand landed Take Off toFly ¦ Fly toLand ¦ Descend Landed e: startPos = getGPS() rise() SendWarning Broadcast e: warning( ) [ charge>=10% ] [ charge<10% ] / toLand Battery after 15s [ charge<20% ] e: charge = getCharge() toTakeoff Fig. 6. Realization model of the MinimumBattery feature. The transition toLand is removed after the merge to resolve a conflict. as explained in the previous section. By doing so, they are C. Conflict management able to discuss, plan, and set the course for adding additional Similarly to VCS such as Git [1], our approach maintains a features. All participants share a common understanding of remote copy of the concern and local copies for each branch. the root feature before adding additional variants. The feature When creating a new branch, a copy of the concern will be model grows incrementally by adding features through col- created for local use in that branch. The user can push her laboration and branching. Modelers discuss before branching changes to the remote copy and conflicts can be resolved which features they are going to model and the consistency when they arise during commit or merge, similarly to how of the feature model can be checked during merging. systems such as Git do. However, in our approach, only It is also possible to model the entire feature model only features that are changed need be checked for conflicts when (without the realization models) before creating any branch merging branches. Furthermore, since CORE models are in the timeline, apart from the main branch. In this case, added incrementally (preserving the consistency of existing modelers have the opportunity to collaborate in planning all models [4]), only changes in the realization models need the possible variants that they want to model upfront. In the to be examined for conflicts during merge operations. This branches, they model the realization model for the planned saves time as feature and realization models tend to grow in features. size when reusing other concerns [17], [19]. In addition, since a CORE concern groups models of dif- Features and models that are not changed and are not in ferent modeling notations belonging to multiple development conflict with the changed features/models can be automati- phases, our approach allows to use heterogeneous modeling cally merged. However, in case of a conflict, the extension languages collaboratively in a single project, allowing for hierarchy of the realization models along with the constraints better development life-cycle management. of the feature model will allow for dependency analysis to In summary, our approach allows for different ways to resolve the conflict [17]. When a conflict occurs between two plan the feature model, modelers can collaborate in modeling or more realization models, a conflict resolution model can the feature model before realizing the individual features, or be introduced to resolve this conflict. For example, during the they can opt for starting with a root feature and branching merge operation at E6 , we found that both MinimumBattery to collaboratively add features and realizing them. (Fig. 6) and UnobstructedTakeoff (Fig. 7) has a transition model UnobstructedTakeOff realizes UnobstructedTakeOff, ForcedLanding extends SystemBehavior Variables: min on startPos Off Start Shutdown toTakeoff off e: startup() e: shutdown() Operational Take Off landed ¦ Fly ¦ Descend Landed Climb Hover toFly toLand [getAlt() > min] /toFly e: hover() toLand Abort cancel/toLand e: startPos = getGPS() rise() Sensor Canceling obstacleDetected / cancel toTakeoff Fig. 7. Realization model of the UnobstructedTakeOff feature. The transition toLand is removed after the merge to resolve a conflict. called (toLand) from TakeOff to Descend. This transition Despite the efforts from modelers to resolve conflicts as allows the system to land before the drone starts flying, they arise, there are conflicts that are unresolvable or are too i.e., the drone system takes off and lands immediately. When difficult/costly to resolve. When such conflicts occur during features MinimumBattery and UnobstructedTakeoff are se- a merge or commit event, the concern designers can express lected, two transitions with the name toLand will appear in them using excludes relationship in the feature model [14]. In the model, resulting a conflict. The system does not know some cases, a conflict can be resolved by selecting additional which toLand transition to fire. We resolve this conflict by feature(s), as we discuss in the next subsection. In these first removing the toLand transition from both MinimumBat- cases, the concern designers can explicitly express these tery and UnobstructedTakeoff, then introducing a model that additional features to be selected. The advantage of using defines this transition, and make both MinimumBattery and our approach over how concerns are currently designed, is UnobstructedTakeoff extend that new model. We call the new that the concern designers can “revert” back when none of model ForcedLanding, shown in Fig. 8. ForcedLanding has a these solutions work, i.e., discard the features/models that pointcut that detects the occurrence of TakeOff and Descend introduced the conflict during the merge, and branch again states and replaces them with the advice part which adds to re-model them in a way that resolves the conflict. the toLand transition between those two states. There are D. Re-modeling of features other ways to resolve conflicts, some are discussed in [17]. In cases where conflicts occur because of reusing a particular As discussed in the previous subsection, we resolved concern (e.g., a feature from the reused concern conflicts the conflict between the models in Fig. 6 and Fig. 7 by with a feature from the reusing concern), then the conflict can introducing a new model called ForcedLanding shown in be resolved either by using a conflict resolution model or by Fig. 8. Here, we discuss a different way for resolving this making a different feature selection from the reused concern. conflict. We notice that even if the two toLand transitions are However, it is possible that some conflicts cannot be resolved syntactically the same, they may get triggered by different using resolution models or by choosing an alternative variant situations. Therefore, these are domain-specific transitions from the reused concern (or the conflicting variant of the that cause a semantic conflict. The merge operation could reused concern provides important functionality that cannot be parameterized by a semantic conflict detection function. be replaced). We resolve the conflict by introducing a new feature in the feature model that realizes this shared behavior. During the model ForcedLanding realizes ForcedLanding Pointcut Advice Take Off Descend Take Off Descend e: startPos = getGPS() e: startPos = getGPS() toLand rise() rise() Fig. 8. Aspect pointcut and advice for ForcedLanding merge operation, we decided to introduce a new optional Rhapsody [21], Visual Paradigm [22], MagicDraw [23], feature called ForcedLanding (see Figure 1) that realizes the and Enterprise Architect [24] are modeling tools that are point-cut advice model that we initially introduced to resolve used in industry and support collaborative modeling. Some the conflict discussed previously. We make both realization technologies such as MagicDraw, Eclipse CDO [25] and models, shown in Figure 6 and Figure 7, realize the newly EMFStore [26] provide some support for VCS. Rocco et al. introduced feature ForcedLanding in addition to their re- provide an overview these tools and discuss their potentials spective features, UnobstructedTakeoff and MinimumBattery. and shortcomings [2]. They acknowledge that support for Both features require the feature ForcedLanding, using the reuse and discovering reusable artifacts is limited, increas- require constrain of feature models. ing the upfront development cost for many model-based It is also possible to re-model a set of features as a projects. Therefore, the potential benefits of collaborative separate concern. For example, during the merge operation at modeling in these approaches is limited. In addition, their E6 , we can extract the battery features (BatteryWarning and ad-hoc architectures make it difficult for domain-specific MinimumBattery) from the DroneSystem and include them collaboration and version control, and their simplistic use of in a new concern which encapsulates all battery related fea- locking/conflict management slows down productivity [27]. tures. For example, the new concern encapsulates additional However, a concern in our approach is modeled incremen- features that allow the user to specify whether the battery tally and collaboratively through reusing existing models. could be recharged or should be disposed. When battery Since different modeling languages can be integrated under is separated from DroneSystem as a reusable concern of its the CORE umbrella [4], our approach has the potential own, we have to identify the features in DroneSystem that to be language-independent, allowing different modeling are affected by this re-modeling. In particular, we have to languages and tools (including domain-specific languages) reuse the battery concern in those features and adapt their to adopt our ideas. Furthermore, our approach proposes an realization models accordingly. The same process should be explicit task-assignment mechanism based on the feature and followed when a new release of the battery concern comes realization models of a concern. Lastly, our approach allows out and we would like to reuse the new upgraded battery. for releasing versions of a concern, we are not aware of any We have to identify the features that reuse the old battery modeling approach that supports gradual releasing of models. concern, remove the old reuse, and establish new reuse for VI. C ONCLUSION the upgraded version of the battery concern. Finally, for successful reuse of the battery concern, we have to check This paper introduces a novel approach for collaboration for any conflict between the reused features in the battery in modeling CORE concerns. A concern groups related het- concern and the reusing features of the DroneSystem concern erogeneous models and provide interfaces to facilitate reuse. [17]. We build on ideas of CORE such as reuse and incremental modeling to support collaborative modeling using a VCS. V. R ELATED W ORK We capture the ideas of our approach in a metamodel and demonstrate the effectiveness of our approach using a an Although CORE comes with a library of reusable con- example drone concern. In future, we plan to conduct larger cerns, currently there is no support for VCS in CORE. case studies using multiple modeling languages to evaluate Therefore, support for collaboration is limited in CORE. our approach. We also plan to integrate our approach with TouchCORE [20], which is a touch-based modeling tool some existing based modeling tools. for CORE-based design modeling, allows multiple modelers We expect that this feature-driven, concern-oriented, col- to collaborate in modeling through a touch-based screen. laborative modeling approach will make collaborative mod- However, it does not support tracking development activities, eling easier, faster, and simpler with modular ways to resolve branching, merging provided the VCS discussed in this conflicts. paper. Other modeling technologies provide some support for R EFERENCES collaborative modeling. Commercial tools such as Rational [1] “Git,” Last accessed: 2017. [Online]. Available: https://git-scm.com/ [2] J. D. Rocco, D. D. Ruscio, L. Iovino, and A. Pierantonio, “Collabora- tive repositories in model-driven engineering [software technology],” IEEE Software, vol. 32, no. 3, pp. 28–34, 2015. [3] J. Whittle, “The truth about model-driven development in industry - and why researchers should care,” 2012. [Online]. Available: http://www.slideshare.net/jonathw/whittle-modeling-wizards-2012/ [4] O. Alam, “Concern-oriented reuse: A software reuse paradigm,” Ph.D. dissertation, McGill University, 2016. [5] O. Alam, J. Kienzle, and G. Mussbacher, “Concern-oriented software design,” in Proceedings of the 16th International Conference on Model-Driven Engineering Languages and Systems - MODELS 2013, ser. Lecture Notes in Computer Science, vol. 8107. Springer Berlin Heidelberg, 2013, pp. 604–621. [6] W. Al Abed and J. Kienzle, “Information Hiding and Aspect-Oriented Modeling,” in 14th Aspect-Oriented Modeling Workshop, Denver, CO, USA, Oct. 4th, 2009, October 2009, pp. 1–6. [7] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton, “N degrees of separation: Multi-dimensional separation of concerns,” 1999, pp. 107– 119. [8] K. Pohl and A. Metzger, “Variability management in software product line engineering,” in Proceedings of the 28th international conference on Software engineering (ICSE ’06). ACM, 2006, pp. 1049–1050. [9] International Telecommunication Union (ITU-T), “Recommendation Z.151 (10/12): User Requirements Notation (URN) - Language Defi- nition,” approved October 2012. [10] R. Filman, T. Elrad, S. Clarke, M. Akşit, Aspect-Oriented Software Development. Addison-Wesley, 2004. [11] E. W. Dijkstra, A Discipline of Programming, 1st ed. Upper Saddle River, NJ, USA: Prentice Hall PTR, 1997. [12] D. L. Parnas, “A technique for software module specification with ex- amples,” Communications of the Association of Computing Machinery, vol. 15, no. 5, pp. 330–336, May 1972. [13] M. Blume and A. W. Appel, “Hierarchical modularity,” ACM Trans. Program. Lang. Syst., vol. 21, no. 4, pp. 813–847, Jul. 1999. [14] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson, “Feature- oriented domain analysis (FODA) feasibility study,” Software Engi- neering Institute, Carnegie Mellon University, Tech. Rep. CMU/SEI- 90-TR-21, November 1990. [15] G. Mussbacher, J. Araújo, A. Moreira, and D. Amyot, “Aourn-based modeling and analysis of software product lines,” Software Quality Journal, vol. 20, no. 3-4, pp. 645–687, 2012. [16] O. M. Group, Unified Modeling Language: Superstructure (v 2.4.1). [17] J. Kienzle, G. Mussbacher, P. Collet, and O. Alam, “Delaying decisions in variable concern hierarchies,” in GPCE 2016, 2016, p. to be published. [18] M. Schöttle, N. Thimmegowda, O. Alam, J. Kienzle, and G. Muss- bacher, “Feature modelling and traceability for concern-driven soft- ware development with touchcore,” in Companion Proceedings of the 14th International Conference on Modularity, MODULARITY 2015, Fort Collins, CO, USA, March 16 - 19, 2015, 2015, pp. 11–14. [19] O. Alam, J. Kienzle, and G. Mussbacher, “Modelling a family of systems for crisis management with concern-oriented reuse,” Softw., Pract. Exper., vol. 47, no. 7, pp. 985–999, 2017. [20] W. Al Abed, M. Schöttle, A. Ayed, and J. Kienzle, “Concern-oriented behaviour modelling with sequence diagrams and protocol models,” in Behavior Modeling - Foundations and Applications, ser. LNCS. Springer, 2015, vol. 6368, pp. 250 – 279. [21] “Rational rhapsody designer manager,” Last accessed: 2017, www- 03.ibm.com /software/products/en /ibmratirhapdesimana. [22] “Visual paradigm,” Last accessed: 2017, https://www.visual- paradigm.com/. [23] “Magicdraw,” Last accessed: 2017, https://www.nomagic.com/. [24] “Enterprise architect,” Last accessed: 2017, http://www.sparxsystems.com/products/ea/. [25] “Cdo model repository,” Last accessed: 2017, http://www.eclipse.org/cdo/. [26] “Emfstore,” Last accessed: 2017, http://www.eclipse.org/emfstore/. [27] D. S. Kolovos, L. M. Rose, N. Matragkas, R. F. Paige, E. Guerra, J. S. Cuadrado, J. De Lara, I. Ráth, D. Varró, M. Tisi, and J. Cabot, “A research roadmap towards achieving scalability in model driven engineering,” in Proceedings of the Workshop on Scalability in Model Driven Engineering, ser. BigMDE ’13. New York, NY, USA: ACM, 2013, pp. 2:1–2:10.