=Paper=
{{Paper
|id=None
|storemode=property
|title=Staged Evolution with Quality Gates for Model Libraries
|pdfUrl=https://ceur-ws.org/Vol-1008/paper7.pdf
|volume=Vol-1008
|dblpUrl=https://dblp.org/rec/conf/doceng/RothGLR13
}}
==Staged Evolution with Quality Gates for Model Libraries==
https://ceur-ws.org/Vol-1008/paper7.pdf
Staged Evolution with Quality Gates
for Model Libraries
Alexander Roth Andreas Ganser
RWTH Aachen University RWTH Aachen University
Ahornstr. 55 Ahornstr. 55
52074 Aachen, Germany 52074 Aachen, Germany
roth@se.rwth- ganser@swc.rwth-
aachen.de aachen.de
Horst Lichter Bernhard Rumpe
RWTH Aachen University RWTH Aachen University
Ahornstr. 55 Ahornstr. 55
52074 Aachen, Germany 52074 Aachen, Germany
lichter@swc.rwth- rumpe@se.rwth-
aachen.de aachen.de
ABSTRACT results of mapping objects from the real world to a higher
Model evolution is widely considered as a subject under re- level of abstraction [25].
search. Despite its role in research, common purpose con- These models are often formulated in UML for two rea-
cepts, approaches, solutions, and methodologies are missing. sons. First, because “for larger and distributed projects,
Limiting the scope to model libraries makes model evolution UML modeling is believed to contribute to shared under-
and related quality concerns manageable, as we show below. standing of the system and more effective communication” [5].
In this paper, we put forward our quality staged model Second, UML models frequently serve as inputs for code gen-
evolution theory for model libraries. It is founded on evo- eration, which helps prototyping, speeds up development,
lution graphs, which offer a structure for model evolution and supports generation of parts of the final system. This
in model libraries through evolution steps. These evolution reduces the risks of working at an inappropriate level of ab-
steps eventually form a sequence, which can be partitioned straction or to get lost in details.
into stages by quality gates. Each quality gate is defined by Since models are such essential assets in MDD, it is widely
a lightweight quality model and respective characteristics proposed to reuse models. This would decrease develop-
fostering reusability. ment time and increase software quality [22, 16]. Conse-
quently, models should be stored in model libraries, which
enable model management and allow for model reuse. A
Categories and Subject Descriptors challenge regarding model libraries is to provide models of
D.2.13 [Software Engineering]: Reusable Software—Do- high quality, since model quality is a matter of subjectivity
main engineering, Reusable libraries, Reuse models and hard to measure precisely [24]. Additionally, models in
libraries undergo changes over time. Altogether this puts an
Keywords extra burden on maintaining reusable models at high qual-
ity, which we investigate subsequently.
Model Evolution, Model Quality, Quality Gates, Model Li- We believe that evolution and quality in model libraries is
braries insufficiently supported and, to the best of our knowledge,
we could not find an approach enabling guided model evo-
1. INTRODUCTION lution. This is surprising, since model quality and evolution
Omnipresent computers have lead to increasing complex- have been a subject under research for a long time already
ity of programs and their development. In order to stay on (sec. 2). Most importantly, model evolution is generally un-
top of things, numerous approaches were proposed and one derstood as a goal that is achieved only if the model has
among them is Model-Driven Development (MDD). It en- been adapted guaranteeing the system’s integrity (sec. 2).
ables designing software by means of models, which are the In contrast, we believe that the understanding of quality
and evolution needs to shift, when considered for model li-
braries (sec. 3). But this requires a more formal approach
that supports evolution for model libraries (sec. 3.4) and
helps to partition model states into stages according to their
reusability (sec. 3.5). In this approach, each stage is sepa-
This work is licensed under the Creative Commons Attribution- rated by a gate, which is derived from a quality model and
ShareAlike 3.0 Unported License (CC BY-SA 3.0). To view a copy
of the license, visit http://creativecommons.org/licenses/by-sa/3.0/. respective characteristics focusing on reusability (sec. 4).
All in all, we contribute a stage model enhanced with qual-
DChanges 2013, September 10th, 2013, Florence, Italy. ity gates, which are defined by aspects of a quality model.
ceur-ws.org Volume 1008, http://ceur-ws.org/Vol-1008/paper7.pdf .
2. RELATED WORK model metrics and reviews.
Model evolution, as we will present, can be discussed Supporting quality dimensions, we employ the results by
closely related to model libraries and quality of models. In Lindland et al. [19]. They define syntactic, semantic, and
the following, we present the current understanding of model pragmatic quality as the cornerstones of their quality di-
evolution, model repositories, and model quality. However, mensions. Bansiya et al. describe that all of these quality
we intend to look at model evolution in model libraries and dimensions can influence each other [3]. We extended Lind-
will point out differences to the current understanding of land’s approach to take into account emotional quality.
model evolution. Multiple approaches exist to define UML model quality.
Evolution of models is often considered as a goal one is The most suitable for us is by Lange et al. [17]. They de-
trying to achieve automatically. A tool providing support for scribe model quality as a set of dimensions and identified two
that is MoDisco [6] (cf. AM3 [1]), which aims at support- primary use cases of models: maintenance and development.
ing evolution of legacy systems by model-driven approaches. For each of these, model characteristics, which can influence
That means, MoDisco is for re-engineering legacy software multiple model purposes, are derived from the proposed set
by means of models and starting a model driven development of dimensions. The characteristics have to be measured to
from gleaned models. In addition, issues of co-evolution are draw conclusions about the model’s quality. However, Mo-
discussed. However, we keep to plain model evolution and hagheghi et al. point out that measuring the presented char-
propose that it is aimless and cannot be achieved. Conse- acteristics is challenging [23]. These challenges are reduced
quently, it has to be guided in the right direction. when model evolution is considered for model libraries, since
Another tool providing support for model evolution and model quality can be limited to general quality.
co-evolution is COPE. It monitors evolution in an operation-
based manner and applies traced changes to other mod- 3. MODEL EVOLUTION
els [12]. Moreover, these traces can be stored in a library Evolution has been a subject under research for decades.
so they can be forwarded or applied to other models as In contrast to its roots in biology, evolution theories are
well. This is important as co-evolution is the focus of this rather new to computer science. While Lehman summarized
project. Our approach differs slightly, since we do not need observations on software evolution in the eighties [18], it is
to monitor changes in the long run and focus on quality questionable if these observations hold true for state-of-the-
aspects and stages that depend on the actions performed art software development. For example, Model Driven De-
on the models. But, some similarities between COPE and velopment (MDD) changed software development in a way
our approach can be found in regard of the stages underly- that some assumptions might need to be reconsidered. Con-
ing the approach. In the end, we need more formally defined sequently, we investigated interdisciplinarily and analyzed
stages, while COPE needs more formally defined operations. potential influences, bearing in mind that our area is model
These operations are derived from oodb-schema experience evolution in model libraries. We did so, to define this evo-
and object-oriented source code experience, i.e., refactoring, lution, its characteristics, and the underlying formalism.
and are overview over high-level operations or others. All
together, operations are seen as structural or non-structural 3.1 Influences of Model Libraries
primitives. For example, specialization, generalization, dele- Existing research in model evolution assumes that model
gation, or inheritance are such primitive operations. Others evolution happens within software systems and addresses ba-
are replacement and merge-split [13]. sically two concerns. On the one hand, collaboration is seen
Since we study evolution in model libraries, we need to as one cause initiating model evolution. This is due to dif-
discuss model management. Such systems offer mechanism ferent developers and modelers working on the same model
to query for models, resolve conflicts, and manage version- without a shared repository. As a consequence, these mod-
ing. As a consequence, aspects of co-evolution are usually els are less frequently reviewed leading to declining model
out of scope. For example, MOOGLE is a model search en- quality. On the other hand, integrity is seen to hamper
gine with advanced querying functionality and user-friendly model evolution, since adapted models need to preserve cer-
user interface support [20]. Second, ReMoDD aims at doc- tain constraints. One of these constraints might be that
umentary purpose by offering models to the modeling com- system’s integrity has to be preserved. In conclusion, these
munity [9]. Third, the “Model Repository” manages models two concerns define model evolution as a goal.
in a graph structure, holding, e.g., classes as vertices and as- Looking at model evolution in a context of model libraries
sociations as edges [28]. Fourth, AMOR is a model library and model reuse, the properties of model evolution change.
providing advanced conflict resolution and versioning sup- This is due to models examined by different modelers dis-
port [2]. None of these model libraries take model evolution regarding any environment and purely focusing on reusabil-
into consideration. Consequently, we have implemented our ity. Hence, the models are meant to provide solutions for
own model library, which offers model evolution support. problems preserving experience while ignoring any other in-
But evolution support, compared to versioning, makes tegrity. As a result, the models are supposed to not contain
sense only if a common understanding of model quality is technical details and maintain high quality. (cf. figure 1 left)
maintained. In conceptual modeling, quality is seen as a sub-
jective and rather social than a formally definable property 3.2 Lehman Laws in Model Evolution
lacking a common understanding and standards [24]. Moody The Lehman laws [18] offer four aspects which can be
explains that the main challenge in defining model quality is adapted to model evolution. First, model evolution is trig-
the absence of measurable dimensions. Fortunately, model gered, if a model needs to be changed. This might be due to
libraries limit the scope noticeably, so we can present an ap- changing requirements or bugs. Second, if no attempts are
proach to measure model quality in model libraries. It is undertaken to decrease model complexity, it will be less often
based on measurable quality dimensions and backed up by reused. The reason for that is mostly because the purpose of
the model is hazed. Third, model evolution is feedback reg- ing faults, adapting, improving a model, and preserving in-
ulated; hence, evolution happens after the model has been tegrity between models and source code [14]. Still, adaption
reviewed and deployed. Last, except for adaptions that are is one major influence on model evolution, even if model
necessary keep the mapping between a particular range of evolution is understood as undirected, infinite, and unpre-
the real world and the model itself, the quality of a model dictable [4, 7, 21]. Taking a closer look at this kind of evo-
is not influenced by a constant need for adaption. For in- lution, Judson et al. define three types [14]. Adaptive evo-
stance, models that provide a suitable solution might not be lution happens due to changes in requirements, and perfec-
changed but just reused. tive evolution comprises enhancements in the models design
As a consequence, models in a model library should fo- quality; corrective evolution summarizes error corrections.
cus on problem solving omitting technical aspects. In this These model evolution types characterize the reasons for
regard, the size of a model is of vital importance for its evolution rather than describing activities as in maintenance.
reusability. We basically consider the size of a model as the It is important to understand that model evolution is not
number of classes, attributes, and methods. To that end, maintenance, since maintenance changes models and thereby
large models are harder to reuse than small models. More- influences model evolution. In addition, maintenance is not
over, models that changed over time require reviews by other the only reason for model evolution. A model can evolve
modelers to maintain reusability. Finally, model evolution due to structural changes that are forced by, e.g., successive
does not inherit hidden evolution, i.e., changes in size always development and not sustainment.
impact the systems visibly [29]. Another important aspect is that model evolution rarely
happens without conflicts. Mens et al. subdivide these con-
3.3 Model Evolution in Model Libraries flicts into two types: evolutionary and composition con-
Since we limit model evolution to model libraries, we limit flicts [22]. Evolutionary conflicts are conflicts describing the
its start to the moment the model is added to a model li- change of the model’s behavior. This means, a property that
brary. Consequently, Lehman’s definition of evolution as “a holds in a model snapshot does not hold for its successor.
progressive and beneficial process of changes in evolving at- Composition conflicts result from co-evolution of referenced
tributes of an entity” [18] needs refinement. This means, models. In other words, if a model holds references to an-
progressive changes need to be considered as add, delete, other model, these references need to be verified.
rename, and retype operations with the semantics defined
in [12]. This correlates with Keienburg et al., who define 3.4 Model Evolution Graph
evolution as “proceeding an ordered list of model change A first step in formalizing model evolution in model li-
primitives on an existing component model and finally create braries is through structuring its progress. This can be
a new model version” [15]. Adapting this to model evolution achieved by adapting version graphs known from version
means that model evolution needs a definition of model ver- control systems to model evolution. Eventually, this suits
sions, we call model snapshots. Each time a model is changed as the foundation for tool support and a methodology.
in a model library, the model has evolved and has formed a Derived from version control graphs, a model evolution
new snapshot. We define two consecutive model snapshots graph represents a sequence of pairwise connected model
of the same model as an evolution step. A sequence of model snapshots. Each snapshot is contained in a vertex repre-
snapshots represents model evolution, in our terms. senting a model at a certain point in time as defined above.
An example for model evolution is depicted in figure 1. These vertices are labeled with unique version ids as known
It shows a class diagram modeling a jukebox. Starting in from version control systems. Moreover, each vertex has at
snapshot 1 the model is changed by applying rename, re- least two adjacent edges, which are labeled with transition
type, delete, or add operations. This results in a snapshot ids. A simple excerpt of a model evolution graph is depicted
2. Further changes then might lead to several more snap- in figure 1. It shows that a model starts in a snapshot labeled
shots and eventually the model will be in snapshot n. In this with a version id 1 and progresses to snapshot n. Usually,
example, some technical details, as the suffix DAO indicates, each transition is labeled as well, e.g., with σ1 .
spoiled snapshot 1 and should be removed first. Each edge in a model evolution graph represents a se-
quence of primitive operations applied to a model while pro-
gressing to the next snapshot. In more detail, these primitive
Jukebox operations are defined as τadd , τdelete , τrename , and τretype .
JukeboxDAO
discs play() credits They form a sequence of primitive operations through σi
pay()
discs: MediaSet being a word defined as σi ∈ {τadd , τdelete , τrename , τretype }∗ ,
credits[]: Credit where i ∈ N.
...
play() Now, formally defining the entire model evolution graph,
Medium Credit
pay() it comprises a tuple (EGmodel , s, t), where EGmodel = (V, E)
titles[]: String processPay()
is a graph with a vertex set V and an edge set E and s, t are
costs[]: Credit convertInput()
labeling functions. s : V → S is a function for some domain
S labeling each vertex. Each edge is labeled by the func-
Snapshot 1 Snapshot n
tion t : E → T , where T = {τadd , τdelete , τrename , τretype }∗ .
Altogether, this enables a definition of model evolution in
Figure 1: Model Evolution Example model libraries, which we define as a sequence of evolution
steps, which, in turn, are transitions in our model evolution
It is important to understand that model evolution is not graph. This means, model evolution in model libraries is a
solely based on adaptations and it is to be distinguished sequence of model snapshots; i.e., the evolution in figure 1
from maintenance, because maintenance focuses on correct- is the sequence (1, ..., n).
3.5 Model Evolution Stages τi τj
We conduced a small field study with an exemplary model
evolution, and participants said that model evolution graphs
should contain status information for each snapshot. Con-
sequently, a model evolution graph can be partitioned into start vague idM decent
idM
sequences of evolution steps with equal status information.
For example, the excerpt from figure 1 could show how a id
M
id
M M
model evolves by going through the snapshot 1 with status id
“vague” and being in snapshot n with status “decent”. fine
Rooting qualitative evaluations on “traffic lights” seemed
most reasonable to our participants. As a result, the number
of stages was chosen to be three, as it is intuitively obvious
what a model in “red”, “yellow” or “green” condition means τk
in terms of reusability. As a nice side effect, the cognitive
load of these three stages is negligible, since the number is
small and the semantics of the colors is obvious. We choose Figure 2: Model Evolution Stages
the names to be vague, decent, and fine.
A vaguely reusable model is indetermined with respect to P
it’s reusability and quality. Its label is “red”, i.e., the stage defined as Q := {vague, decent,Pfine}. is the collec-
is vague. This means, the model stays in the library for tion of input symbols defined as := Q × (T ∪ {idM })
further processing and is offered for reuse, but the modeler with T := {τadd , τdelete , τrename , τretype }. Moreover, q0 is the
needs to be cautious using this model. It might be that this defined starting state (q0 := vague) and F is the empty set
model holds some specific suffixes (cf. “DAO” in figure 1), (F := ∅) since evolution is not regarded finite. Finally, δ is
technology dependent elements, adapters for legacy use, or the transformation and defined as δ := δv ∪ δd ∪ δf , with
even errors. Despite all this uncleanliness, it was chosen
δv := {(vague, τi ) 7→ vague | τi ∈ T }
to be put in the library for reuse since it is thought to be
reusable in general. Due to these characteristics of “vague”, ∪ {(vague, idM ) 7→ decent},
every model put in the library starts in this stage. δd := {(decent, τj ) 7→ decent | τj ∈ T }
As the major issues are fixed, the model progresses to be ∪ {(decent, idM ) 7→ vague}
a decently reusable model. Its label is “yellow” now, i.e.,
the stage is decent. This means, the model does not hold ∪ {(decent, idM ) 7→ fine}, and
any specifics or errors and is reusable in general. Still, it δf := {(fine, τk ) 7→ fine | τk ∈ {τrename , τretype }}
might be, that certain care needs to be taken if a modeler ∪ {(fine, idM ) 7→ decent}
reuses this model, for example, the purpose does not per-
∪ {(fine, idM ) 7→ vague}
fectly match the intuition or a design decision is not clever.
Even the layout might not be very appealing or the qualita- A closer look at the transitions unveils that some non-
tive statements rely on assessments only but not on actual determinism is inherent in this automaton. First, transitions
experience while reusing this model. that go from the fine stage to another stage could represent
A finely reusable model is considered almost perfectly the same type of operations. Second, the identity operations
reusable and holds a “green” label indicating that the stage is are no hindrance between stages. This means, so far it is
fine. Now, the purpose is in line with the model and the qual- always possible to change the stage and this is why user
ity is most reasonable. Notwithstanding that, models most interaction based on quality assessments will be required
likely will not be reusably “out of the box”. This might be later. But first, an example should provide a better idea
due to a template mechanism that requires a modeler to fill how a model might progress through different stages.
in the optional parts or due to adaption that is required by
this particular reuse. If any operation other than renaming 3.7 Model Evolution in Action
or retyping is applied, the model looses it’s fine status. The above mentioned automaton is non-deterministic; so,
room is left for reasoning how this could be changed. We use
3.6 Model Evolution Automaton the example from figure 1 and demonstrate how it might un-
Taking into account the above mentioned reasoning and dergo evolution in a model library. This will set the reason-
operations, the formal model of the model evolution stages ing required for transition guards between stages and even-
can be transformed into an automaton as depicted in fig- tually demand a quality model for decision support.
ure 2. It shows, how a model is initially put in a vague As our jukebox from figure 1 was considered beneficial for
stage and that certain operations (τi ) can be performed our model library, it was extracted from its environment and
until an identity operation (idM ) moves the model to de- stored for reuse. Since most of the newly arriving models
cent stage and so forth. The considered operations com- are expected to be biased in one way or another, the initial
prise adding, deleting, renaming and retyping elements in stage of our jukebox model is vague. In our example this
the model. Their impact on the model is quite different, is very reasonable, because the model contains a suffix that
which limits the operations available on a model in fine indicates its purpose and spoils the cleanness of this model.
stage. This is, because adding or deleting elements in a Without going into detail with quality in modeling, we can
model in fine stage could alter the model
P entirely. say that this model can be improved.
More formally, the automaton (Q, , Z, δ, q0 , F ) com- As a modeler improved the model to a certain extent, it
prises the following elements: Q is the set of vertices and can progress to “decent” stage. In our example, a modeler
needs to remove the suffix DAO to make the model hold one Meta-Model
class with a clean name. This was achieved by a simple conformity
rename operation and now the model is free from technolog- Syntactic Quality Transformability
ical details. At this point, the modeler only needs to add,
e.g., a description and model can progress to “decent” stage.
Defect-Freeness
This means, it is all right but certainly not “fine”. Hence,
the design should be revised, though this model is reusable
in general. As a consequence, it is highly unlikely that it Semantic Validity
will be reused as it is. On the contrary, a modeler will most
likely need to apply further add, delete, rename, or retype Semantic Quality Completeness
Model Quality
operations, if the model is reused. For example, some de-
pendent classes, which obviously belong to this model, will
Model
Confinement
need to be designed. In our example, a Jukebox is useless
without a definition of a MediaSet.
As soon as the model matured further, it can progress to Understandability
“fine” stage. This will have needed that some modelers re-
viewed this model or some of them removing model issues. Pragmatic Quality Maintainability
Eventually, the gained snapshot might be like snapshot n
from figure 1. Mind that, this happened only with our de- Purpose
fault set of operations, which is mentioned above. The point Extraction
is, that this model came to a stage that is “fine” for reuse.
From now on, this model is valid in itself and can be reused Emotional
Appeal
by other modelers. Additionally, it might offer template Quality
support, which includes further modeling advise.
Since the quality of models and, likewise, template in-
Figure 3: Model Quality Dimensions
formation breaks easily, when, e.g., add or delete actions
are applied, only rename and retype actions are allowed in
“fine” staged models. This is due to add and delete oper-
First, focusing on reusability, it is sufficient to restrict syn-
ations altering the model in a way that might totally alter
tactic quality to be described by the following three charac-
the purpose and validity of that model. This is why these
teristics: Meta-model conformity describes the conformness
actions lower the stage immediately. But it depends on the
of the model to the abstract syntax specifying the model-
reasoning of a modeler to decide on the next stage. Most
ing language, i.e., the model is well-formed. Additionally,
likely, the model will only drop to a vague stage if it was split
transformability states that a generator, which understands
in two distinct parts, which need to be considered as “new”
the model’s syntax, can successfully transform a model into
in the model library. Otherwise, add and delete operations
another representation, e.g., source code. Finally, a model
will lead to “decent” stage.
is defect-free, if it does not contain any syntax errors. More-
From the above, we understand that some of the tran-
over, syntactic quality can be used for error prevention, and
sitions need a conscious decision whether the model pro-
error detection. Error correction is, however, not feasible,
gresses to another stage. In order to help modelers to take
due to uncertain modeler goals.
these decisions, a quality model would be beneficial. But it
Second, the extent to which the model describes the as-
is challenging to find such a model, since there is no precise
pect it should model, i.e., correspondence between a model
definition of reusability for model libraries, nor is there a
and its domain, is addressed by semantic quality. We sub-
common understanding of what a quality model for model
divide this dimension into: validity, completeness, and con-
libraries might be. This is why we investigated further and
finement. A model is of high validity if, and only if, ev-
found that this particular environment focusing on reusabil-
ery statement defined by the model is valid in the domain.
ity limits certain aspects extensively, so that we were able
Whenever a model includes an invalid statement from the
to propose a reasonable solution.
domain, it must be true that the advantage to simply re-
move this statement is higher than the drawbacks of adapt-
4. QUALITY MODEL FOR MODELS ing the whole model to the invalid statements. Furthermore,
Restricting models to evolve in model libraries, where only a model is complete if, and only if, there is no statement in
general characteristics such as model size, i.e., complexity, the domain not yet included in the model, such that its ben-
are of relevance, model quality becomes manageable. If a efit is higher than the drawback of adapting the model to
model conforms to these general quality characteristics, the this new statement. Third, if a model includes enough valid
model is considered to have a high quality in a model library statements about the domain to describe the intention or to
and is reusable. In the following, we present our quality solve a problem in a domain, the model is confine.
model focusing on model libraries and thereby resolving the Third, pragmatic quality addresses the correspondence
challenge of being hard to define and measure due to its between a modeler’s comprehension and a model. In other
highly subjective and relative nature [24]. words, the model must be understood by a modeler correctly.
Our quality model is based on the research of Lindland In model libraries, model comprehension can be reduced
et al. [19] and Lange et al. [16] and comprising four general to three characteristics: understandability, maintainability,
quality dimensions, namely syntactic, semantic, pragmatic, and purpose extraction. Understandability refers to the de-
and emotional quality; each of which can be subdivided as gree to which the modeler’s interpretation can be build from
shown in figure 3. the model. Maintainability addresses the degree to which a
modeler understood the model and is able to adapt it to dependencies are included, (b) adapters for legacy are re-
environmental changes. Finally, if the modeler’s extracted moved, and (c) the model has no errors. A model does not
purpose of a model corresponds to the purpose originally have to be semantically complete after passing this quality
defined, the purpose extraction is high. gate, because completeness is aimed for in decent stage.
Last, emotional quality addresses the correspondence be- When a model enters the decent stage, the staged evolu-
tween a user’s interpretation and his emotions. If a model is tion can be directed in two directions. First, if the modeler
appealing to modelers, it is more likely to be reused. Con- adapts the model to fit the initial purpose and is satisfied
sequently, such models have a high emotional quality. This with the chosen layout and solution, the model can be moved
model quality dimension is of importance in model libraries, to the fine stage by passing quality gate QG3. Since the next
since reuse depends on individual opinions about models. level of reusability is “green”, i.e., the model library may
This model quality dimension is mentioned for the sake of suggest this model to modelers for reuse, this quality gate
completeness (cf. “thumb up button” in figure 5) requires all quality characteristics to be fulfilled. Emotional
Each model quality dimension and especially the corre- quality, however, is not considered to be a requirement re-
sponding characteristics have to be measureable in order to garding the number of “likes”, instead it shows that modelers
enable qualitative statements about model quality in model agreed on the reuse of the model and its quality. Second, a
libraries. SDMetrics [26] and Genero et al. [11] provide model can be moved back to the vague stage due to errors in
metrics to measure defect-freeness, understandability, and the model, restructuring, or even unsuitability of the model
maintainability. Moreover, simplified model reviews can be for reuse by passing quality gate QG2, which requires that
used to measure semantic validity, completeness, confine- at least one of the requirements for QG1 is violated.
ment, and purpose extraction. Finally, meta-model confor- After a model has been labeled to be reusable by enter-
mity and transformability can be measured with existing val- ing the fine stage, different influences might lead to the loss
idators [27]. Note that appeal is not measured but tracked of its status. If the model requires adaption other than re-
with a counter, which counts the number of model reuses. naming or retyping, it has to be moved to decent or vague
stage depending on the type of adaption. Restructurings of
4.1 Quality Gates the model, which lead to model decomposition or even new
The staged model evolution aims at structuring and guid- models, require the model to be moved to the vague stage.
ing model evolution in model libraries. The structuring is This also holds true for bugs in the model, which are hard
achieved by partitioning model evolution in three stages. to fix or are not going to be fixed in the future. In any
The traversal of models through the stages highly depends other case of adaption, the model has to be moved to decent
on the modeler and his intention. However, stage traversal stage. In both cases, the model has to pass either quality
can be guided by introducing quality gates in order to make gate QG5 or QG4. Both require that at least one of the
qualitative statements about model quality in each stage requiremnts for QG3 is violated. This non-determinism is
and thereby derive its reusability. In the following, we sum- rooted in the adaptions required to be made to the model.
marize the staged model evolution approach as presented in E.g., if a model needs to be completely restructured, it is
section 3.5 and derive quality gates for the stage transition. moved to vague stage.
Generally, quality gates can be seen as metaphorical gates.
A model can pass a gate, if all requirements of this gate are 5. PROTOTYPE
fulfilled. Figure 4 illustrates the staged model and the cor-
Based on the staged model evolution, a software prototype
responding quality gates. The set of requirements for each
in Eclipse has been implemented and evaluated. The main
gate is derived from the quality model for model libraries.
focus of the prototype is guidance of the modeler through the
staged model evolution. Hence, a simplified representation
start vague QG1 decent of the staged model (cf. figure 4) was implemented and en-
hanced with some guidance to make the quality model work.
QG2 For example, model metrics and model reviews are included
4
G
to provide measures regarding the quality model introduced
Q
Q 3
G G above. In addition, wizards check and display the status of
5 Q
fine each quality gate, whenever the modeler intends to change
the current stage. An overview of the main elements of the
prototype is illustrated in figure 5.
Figure 4: Staged Model and Quality Gates The simplified representation of the stages (top of the fig-
ure) contains a representation for each stage colored with
Each model underlying the staged model evolution starts respect to its reusability status, i.e., vague is red, decent is
in the vague stage and is aiming at reaching the fine stage to yellow, and fine is green. The current stage and the transi-
be recommended for reuse in the model library. The main tions a modeler can choose to reach another stage are high-
goal of the vague stage is to remove all obstacles resulting lighted. This color encoding helps displaying the limited
from the fact that the model has been added to the model li- actions a modeler can perform in each stage (cf. figure 2)
brary or has been restructured from a previously fine model. and thereby increases guidance.
When all of these activities are finished and the modeler in- In addition to the three stages of the staged model evo-
tends to move the model to the decent stage, the model has lution, it is always possible that a model can become dep-
to pass the first quality gate QG1. The requirements of this recated. Then, the model is kept in its current stage and
quality gate are meta-model conformity, transformability, marked as deprected. The basket symbol in figure 5 allows
defect-freeness, semantical validity, and confinement. These the modeler to always mark the current model as depre-
requirements verify that (a) no prefixes and technological cated. Please note that once a model becomes deprecated,
Another benefit of this approach is a set of clear instruc-
tions as the result of applying the metrics. These instruc-
tions inform the modeler about steps that need to be done to
resolve the corresponding model metric violation. In combi-
nation with model reviews, which are required to be fulfilled
in order to move to another stage, this proactive quality
guidance approach provides non-obtrusive feedback to raise
model quality awareness and helps guiding modelers through
the staged model evolution.
6. CONCLUSION AND OUTLOOK
Despite a long history in model evolution research, there is
no holistic approach available supporting evolution in model
libraries. This is surprising, since models change in libraries
as well. Moreover, it is surprising because these circum-
stances ease a few obstacles. Evolution, in general, is con-
sidered as aimless, but model libraries would loose their ben-
efits quickly evolving unguided. Hence, evolution needs to
be guided in model libraries, which offers a clear direction of
evolution and provides opportunities to formalize and struc-
ture evolution in model libraries as we did above.
For structuring this evolution, we defined an evolution
graph and partitioned it based on model stages. These
stages serve as indicators for model reusability. We defined
these stages to be vague, decent, and fine and attribute them
with the colors red, yellow, and green respectively. This in-
tuitive stage model allows to define gates that need to be
fulfilled before passing to the next better stage.
In order to define quality gates to separate model stages,
we introduced a quality model, which defines simple means
Figure 5: Staged Model Evolution Prototype of quality assurance. This is possible, because model li-
braries limit possible quality attributes and, hence, keep the
scope of metrics small. All in all, we defined syntactic, se-
its stage cannot be changed anymore. mantic, and pragmatic quality and added emotional quality,
Besides the stage representation, the prototype contains which proved reasonable in our experiments.
a list of model metric values and model review reports to All together, we provided a foundation for quality staged
display information about the model quality. We separated model evolution in model libraries, which we implemented in
model metrics in two categories: model defects and model tool support providing guidance for this holistic approach.
smells. The first type of metrics indicates violations of met- Besides evaluation of this approach, a novel and altered
rics that are known to be errors, e.g., a new class is intro- kind of co-evolution is subject to current and future work.
duced without a class name. In contrast, model smells are Consider a model library that is more a knowledge base.
defined based on Fowler’s definition of smells [8]. But with It would certainly hold information how single models are
respect to the modeling domain, a smell refers to an improve- related to each other. For example, relationships could be
ment of the model, e.g., reducing the amount of classes to established between such models on different levels.
make the model more understandable. Moreover, we simpli- We created such a model library [10] and enhanced it with
fied model reviews to be easy to create and to correspond evolution support as presented here. The drawback of this
to the model quality characteristics. At this point, we ne- approach is that it only takes into account a single model
glect presenting the mapping of a model review to a model disregarding any crossing relationships. But how do these
quality characteristic, but point out the main idea of the relationships “co-evolve” as models evolve? Moreover, we
simplifed model reviews. A simpified model review for each analyze what happens if a model needs to split. This might
model quality characteristic is created by limiting the view happen, most likely, in fine stage and this is why the symbol
of the review to the necessary elements required to verify in our tool, which stands for this stage, is shaped slightly
the model characteristic. different. As the modeler hovers over this symbol, a splitting
The use of model metrics requires modelers to either man- arrow appears allowing to split this model in several parts.
ually apply them or an approach to automatically apply But the semantics and the consequences of what that would
model metrics and inform the modeler about the results. or could mean are still under research.
A major drawback of a manual approach is that metrics
will be forgotten over time and thus will not be applied.
Consequently, we followed the approach of proactive qual- 7. ACKNOWLEDGMENTS
ity guidance. This approach automatically calculates model We would like to thank all our anonymous reviewers for
metrics whenever a model has been changed and immedi- their comments and effort. Moreover, we would like to thank
ately displays metric violations, i.e., the modeler receives Andrej Dyck, Veit Hoffmann, and Matthias Vianden. It was
live feedback during modeling. always a great to have another intriguing discussion.
8. REFERENCES [15] F. Keienburg and A. Rausch. Using xml/xmi for tool
[1] F. Allilaire, J. Bezivin, H. Bruneliere, and F. Jouault. supported evolution of uml models. In HICSS 34,
Global Model Management in Eclipse GMT/AM3. In Proceedings of the Thirty-Four Annual Hawaii
Proceedings of the Eclipse Technology eXchange International Conference on System Sciences. IEEE
workshop (eTX) at the ECOOP 2006 Conference, Computer Society, Jan. 2001.
2006. [16] C. F. Lange and M. R. Chaudron. Managing model
[2] Altmanninger and Kappel. Amor towards adaptable quality in uml-based software development. Software
model versioning. In Proceedings of the 1st Technology and Engineering Practice, International
International Workshop on Model Co-Evolution and Workshop on, 0:7–16, 2005.
Consistency Management (MCCM’08), Toulouse, [17] C. F. J. Lange. Improving the quality of uml models
France, September 28-October 3, 2008, 2008. in practice. In Proceedings of the 28th international
[3] J. Bansiya and C. Davis. A hierarchical model for conference on Software engineering, ICSE ’06, pages
object-oriented design quality assessment. IEEE 993–996, New York, NY, USA, 2006. ACM.
Transactions on Software Engineering, 28:4–17, 2002. [18] M. Lehman. Programs, life cycles, and laws of
[4] L. C. Briand, Y. Labiche, L. O’Sullivan, and M. M. software evolution. Proceedings of the IEEE,
Sowka. Automated impact analysis of uml models. 68(9):1060 – 1076, sept. 1980.
Journal of Systems and Software, 79(3):339–352, [19] O. Lindland, G. Sindre, and A. Solvberg.
March 2006. Understanding quality in conceptual modeling.
[5] M. Chaudron, W. Heijstek, and A. Nugroho. How Software, IEEE, 11(2):42 –49, march 1994.
effective is UML modeling? Software and Systems [20] D. Lucredio, R. de M. Fortes, and J. Whittle.
Modeling, pages 1–10, 2012. MOOGLE: a metamodel-based model search engine.
[6] Eclipse. MoDisco. http://www.eclipse.org/MoDisco/. Software and Systems Modeling, 11:183–208, 2010.
[7] S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, [21] N. H. Madhavji, J. Fernandez-Ramil, and D. Perry.
and A. Mockus. Does code decay? assessing the Software Evolution and Feedback: Theory and
evidence from change management data. IEEE Trans. Practice. John Wiley & Sons, 2006.
Software Eng., 27(1):1–12, 2001. [22] T. Mens, C. Lucas, and P. Steyaert. Supporting
[8] M. Fowler. Refactoring: Improving the Design of disciplined reuse and evolution of UML models. In
Existing Code (Object Technology Series). J. Bezivin and P.-A. Muller, editors, Proc. UML’98 -
Addison-Wesley Longman, Amsterdam, illustrated Beyond The Notation, volume 1618 of Lecture Notes
edition edition, 1999. in Computer Science, pages 378–392. Springer-Verlag,
[9] R. France, J. Bieman, and B. Cheng. Repository for 1999. Mulhouse, France.
Model Driven Development (ReMoDD). In [23] P. Mohagheghi and V. Dehlen. Existing model metrics
T. Kuehne, editor, Models in Software Engineering, and relations to model quality. In Proceedings of the
volume 4364 of LNCS, pages 311–317. Springer Berlin Seventh ICSE conference on Software quality,
/ Heidelberg, 2007. WOSQ’09, pages 39–45, Washington, DC, USA, 2009.
[10] A. Ganser and H. Lichter. Engineering Model IEEE Computer Society.
Recommender Foundations. In Modelsward 2013, [24] D. L. Moody. Theoretical and practical issues in
Proceedings of the 1st International Conference on evaluating the quality of conceptual models: current
Model-Driven Engineering and Software Development, state and future directions. Data Knowl. Eng.,
Barcelona, Spain,19.-21- February 2013, pages 55(3):243–276, Dec. 2005.
135–142, 2013. [25] R. Schuette and T. Rotthowe. The guidelines of
[11] M. Genero, M. Piattini, and C. Calero. Empirical modeling - an approach to enhance the quality in
validation of class diagram metrics. Empirical information models. In ER ’98: Proceedings of the 17th
Software Engineering, 2002. Proceedings. 2002 International Conference on Conceptual Modeling,
International Symposium n, pages 195–203, 2002. pages 240–254, London, UK, 1998. Springer-Verlag.
[12] M. Herrmannsdoerfer and D. Ratiu. Limitations of [26] SDMetrics. SDMetrics, http://www.sdmetrics.com/.
automating model migration in response to [27] W. Shen, K. J. Compton, and J. Huggins. A toolset
metamodel adaptation. In S. Ghosh, editor, Models in for supporting uml static and dynamic model
Software Engineering, volume 6002 of Lecture Notes in checking. In COMPSAC, pages 147–152. IEEE
Computer Science, pages 205–219. Springer Berlin Computer Society, 2002.
Heidelberg, 2010. [28] Uni-Leipzig. Eclipse Model Repository.
[13] M. Herrmannsdoerfer, S. D. Vermolen, and http://modelrepository.sourceforge.net/, Oct. 2012.
G. Wachsmuth. An extensive catalog of operators for [29] G. Xie, J. Chen, and I. Neamtiu. Towards a better
the coupled evolution of metamodels and models. In understanding of software evolution: An empirical
Proceedings of the Third international conference on study on open source software. In ICSM, pages 51–60.
Software language engineering, SLE’10, pages 163–182, IEEE, 2009.
Berlin, Heidelberg, 2011. Springer-Verlag.
[14] S. R. Judson, R. France, and D. L. Carver. Supporting
rigorous evolution of uml models supporting rigorous
evolution of uml models. In Engineering Complex
Computer Systems, 2004. Proceedings. Ninth IEEE
International Conference on, pages 128–137, 2004.