=Paper=
{{Paper
|id=Vol-2019/commitmde_4
|storemode=property
|title=Towards Collaborative Modeling Using a Concern-driven Version Control System
|pdfUrl=https://ceur-ws.org/Vol-2019/commitmde_4.pdf
|volume=Vol-2019
|authors=Omar Alam,Vasco Sousa,Eugene Syriani
|dblpUrl=https://dblp.org/rec/conf/models/AlamSS17
}}
==Towards Collaborative Modeling Using a Concern-driven Version Control System==
https://ceur-ws.org/Vol-2019/commitmde_4.pdf
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.