Model evolution is widely considered as a subject under research. Despite its role in research, common purpose concepts, approaches, solutions, and methodologies are missing. Limiting the scope to model libraries makes model evolution and related quality concerns manageable, as we show below. In this paper, we put forward our quality staged model evolution theory for model libraries. It is founded on evolution graphs, which o er a structure for model evolution in model libraries through evolution steps. These evolution steps eventually form a sequence, which can be partitioned into stages by quality gates. Each quality gate is de ned by a lightweight quality model and respective characteristics fostering reusability.
D.2.13 [Software Engineering]: Reusable Software|Domain engineering, Reusable libraries, Reuse models
Omnipresent computers have lead to increasing
complexity of programs and their development. In order to stay on
top of things, numerous approaches were proposed and one
among them is Model-Driven Development (MDD). It
enables designing software by means of models, which are the
This work is licensed under the Creative Commons
AttributionShareAlike 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/.
results of mapping objects from the real world to a higher
level of abstraction [
These models are often formulated in UML for two
reasons. First, because \for larger and distributed projects,
UML modeling is believed to contribute to shared
understanding of the system and more e ective communication" [
Since models are such essential assets in MDD, it is widely
proposed to reuse models. This would decrease
development time and increase software quality [
We believe that evolution and quality in model libraries is insu ciently supported and, to the best of our knowledge, we could not nd an approach enabling guided model evolution. This is surprising, since model quality and evolution have been a subject under research for a long time already (sec. 2). Most importantly, model evolution is generally understood as a goal that is achieved only if the model has been adapted guaranteeing the system's integrity (sec. 2). In contrast, we believe that the understanding of quality and evolution needs to shift, when considered for model libraries (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 separated by a gate, which is derived from a quality model and respective characteristics focusing on reusability (sec. 4).
All in all, we contribute a stage model enhanced with quality gates, which are de ned by aspects of a quality model.
Model evolution, as we will present, can be discussed closely related to model libraries and quality of models. In the following, we present the current understanding of model evolution, model repositories, and model quality. However, we intend to look at model evolution in model libraries and will point out di erences to the current understanding of model evolution.
Evolution of models is often considered as a goal one is
trying to achieve automatically. A tool providing support for
that is MoDisco [
Another tool providing support for model evolution and
co-evolution is COPE. It monitors evolution in an
operationbased manner and applies traced changes to other
models [
Since we study evolution in model libraries, we need to
discuss model management. Such systems o er mechanism
to query for models, resolve con icts, and manage
versioning. As a consequence, aspects of co-evolution are usually
out of scope. For example, MOOGLE is a model search
engine with advanced querying functionality and user-friendly
user interface support [
But evolution support, compared to versioning, makes
sense only if a common understanding of model quality is
maintained. In conceptual modeling, quality is seen as a
subjective and rather social than a formally de nable property
lacking a common understanding and standards [
Supporting quality dimensions, we employ the results by
Lindland et al. [
Multiple approaches exist to de ne UML model quality.
The most suitable for us is by Lange et al. [
Evolution has been a subject under research for decades.
In contrast to its roots in biology, evolution theories are
rather new to computer science. While Lehman summarized
observations on software evolution in the eighties [
Existing research in model evolution assumes that model evolution happens within software systems and addresses basically two concerns. On the one hand, collaboration is seen as one cause initiating model evolution. This is due to different developers and modelers working on the same model without a shared repository. As a consequence, these models are less frequently reviewed leading to declining model quality. On the other hand, integrity is seen to hamper model evolution, since adapted models need to preserve certain constraints. One of these constraints might be that system's integrity has to be preserved. In conclusion, these two concerns de ne model evolution as a goal.
Looking at model evolution in a context of model libraries and model reuse, the properties of model evolution change. This is due to models examined by di erent modelers disregarding any environment and purely focusing on reusability. Hence, the models are meant to provide solutions for problems preserving experience while ignoring any other integrity. As a result, the models are supposed to not contain technical details and maintain high quality. (cf. gure 1 left) 3.2
The Lehman laws [
As a consequence, models in a model library should
focus on problem solving omitting technical aspects. In this
regard, the size of a model is of vital importance for its
reusability. We basically consider the size of a model as the
number of classes, attributes, and methods. To that end,
large models are harder to reuse than small models.
Moreover, models that changed over time require reviews by other
modelers to maintain reusability. Finally, model evolution
does not inherit hidden evolution, i.e., changes in size always
impact the systems visibly [
Since we limit model evolution to model libraries, we limit
its start to the moment the model is added to a model
library. Consequently, Lehman's de nition of evolution as \a
progressive and bene cial process of changes in evolving
attributes of an entity" [
An example for model evolution is depicted in gure 1. It shows a class diagram modeling a jukebox. Starting in snapshot 1 the model is changed by applying rename, retype, delete, or add operations. This results in a snapshot 2. Further changes then might lead to several more snapshots and eventually the model will be in snapshot n. In this example, some technical details, as the su x DAO indicates, spoiled snapshot 1 and should be removed rst.
discs: MediaSet credits[]: Credit play() pay()
... discs play() pay()
titles[]: String costs[]: Credit credits
processPay() convertInput()
It is important to understand that model evolution is not
solely based on adaptations and it is to be distinguished
from maintenance, because maintenance focuses on
correcting faults, adapting, improving a model, and preserving
integrity between models and source code [
These model evolution types characterize the reasons for evolution rather than describing activities as in maintenance. It is important to understand that model evolution is not maintenance, since maintenance changes models and thereby in uences model evolution. In addition, maintenance is not the only reason for model evolution. A model can evolve due to structural changes that are forced by, e.g., successive development and not sustainment.
Another important aspect is that model evolution rarely
happens without con icts. Mens et al. subdivide these
conicts into two types: evolutionary and composition
conicts [
A rst step in formalizing model evolution in model libraries is through structuring its progress. This can be achieved by adapting version graphs known from version control systems to model evolution. Eventually, this suits as the foundation for tool support and a methodology.
Derived from version control graphs, a model evolution graph represents a sequence of pairwise connected model snapshots. Each snapshot is contained in a vertex representing a model at a certain point in time as de ned above. These vertices are labeled with unique version ids as known from version control systems. Moreover, each vertex has at least two adjacent edges, which are labeled with transition ids. A simple excerpt of a model evolution graph is depicted in gure 1. It shows that a model starts in a snapshot labeled with a version id 1 and progresses to snapshot n. Usually, each transition is labeled as well, e.g., with 1.
Each edge in a model evolution graph represents a sequence of primitive operations applied to a model while progressing to the next snapshot. In more detail, these primitive operations are de ned as add; delete; rename; and retype. They form a sequence of primitive operations through i being a word de ned as i 2 f add; delete; rename; retypeg , where i 2 N.
Now, formally de ning the entire model evolution graph, it comprises a tuple (EGmodel; s; t), where EGmodel = (V; E) is a graph with a vertex set V and an edge set E and s; t are labeling functions. s : V ! S is a function for some domain S labeling each vertex. Each edge is labeled by the function t : E ! T , where T = f add; delete; rename; retypeg . Altogether, this enables a de nition of model evolution in model libraries, which we de ne as a sequence of evolution steps, which, in turn, are transitions in our model evolution graph. This means, model evolution in model libraries is a sequence of model snapshots; i.e., the evolution in gure 1 is the sequence (1; :::; n).
We conduced a small eld study with an exemplary model evolution, and participants said that model evolution graphs should contain status information for each snapshot. Consequently, a model evolution graph can be partitioned into sequences of evolution steps with equal status information. For example, the excerpt from gure 1 could show how a model evolves by going through the snapshot 1 with status \vague" and being in snapshot n with status \decent".
Rooting qualitative evaluations on \tra c 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 in terms of reusability. As a nice side e ect, the cognitive load of these three stages is negligible, since the number is small and the semantics of the colors is obvious. We choose the names to be vague, decent, and ne.
A vaguely reusable model is indetermined with respect to it's reusability and quality. Its label is \red", i.e., the stage is vague. This means, the model stays in the library for further processing and is o ered for reuse, but the modeler needs to be cautious using this model. It might be that this model holds some speci c su xes (cf. \DAO" in gure 1), technology dependent elements, adapters for legacy use, or even errors. Despite all this uncleanliness, it was chosen to be put in the library for reuse since it is thought to be reusable in general. Due to these characteristics of \vague", every model put in the library starts in this stage.
As the major issues are xed, the model progresses to be a decently reusable model. Its label is \yellow" now, i.e., the stage is decent. This means, the model does not hold any speci cs or errors and is reusable in general. Still, it might be, that certain care needs to be taken if a modeler reuses this model, for example, the purpose does not perfectly match the intuition or a design decision is not clever. Even the layout might not be very appealing or the qualitative statements rely on assessments only but not on actual experience while reusing this model.
A nely reusable model is considered almost perfectly reusable and holds a \green" label indicating that the stage is ne. Now, the purpose is in line with the model and the quality is most reasonable. Notwithstanding that, models most likely will not be reusably \out of the box". This might be due to a template mechanism that requires a modeler to ll in the optional parts or due to adaption that is required by this particular reuse. If any operation other than renaming or retyping is applied, the model looses it's ne status. 3.6
Taking into account the above mentioned reasoning and operations, the formal model of the model evolution stages can be transformed into an automaton as depicted in gure 2. It shows, how a model is initially put in a vague stage and that certain operations ( i) can be performed until an identity operation (idM ) moves the model to decent stage and so forth. The considered operations comprise adding, deleting, renaming and retyping elements in the model. Their impact on the model is quite di erent, which limits the operations available on a model in ne stage. This is, because adding or deleting elements in a model in ne stage could alter the model entirely.
More formally, the automaton (Q; P; Z; ; q0; F ) comprises the following elements: Q is the set of vertices and start vague idM iiddMM fine τk
τj de ned as Q := fvague; decent; fineg. P is the collection of input symbols de ned as P := Q (T [ fidM g) with T := f add; delete; rename; retypeg. Moreover, q0 is the de ned starting state (q0 := vague) and F is the empty set (F := ;) since evolution is not regarded nite. Finally, is the transformation and de ned as := v [ d [ f , with v := f(vague; i) 7! vague j i 2 T g
[ f(vague; idM ) 7! decentg, d := f(decent; j ) 7! decent j j 2 T g [ f(decent; idM ) 7! vagueg [ f(decent; idM ) 7! fineg, and f := f(fine; k) 7! fine j k 2 f rename; retypegg [ f(fine; idM ) 7! decentg [ f(fine; idM ) 7! vagueg
A closer look at the transitions unveils that some nondeterminism is inherent in this automaton. First, transitions that go from the ne stage to another stage could represent the same type of operations. Second, the identity operations are no hindrance between stages. This means, so far it is always possible to change the stage and this is why user interaction based on quality assessments will be required later. But rst, an example should provide a better idea how a model might progress through di erent stages. 3.7
The above mentioned automaton is non-deterministic; so, room is left for reasoning how this could be changed. We use the example from gure 1 and demonstrate how it might undergo evolution in a model library. This will set the reasoning required for transition guards between stages and eventually demand a quality model for decision support.
As our jukebox from gure 1 was considered bene cial for our model library, it was extracted from its environment and stored for reuse. Since most of the newly arriving models are expected to be biased in one way or another, the initial stage of our jukebox model is vague. In our example this is very reasonable, because the model contains a su x that indicates its purpose and spoils the cleanness of this model. Without going into detail with quality in modeling, we can say that this model can be improved.
As a modeler improved the model to a certain extent, it can progress to \decent" stage. In our example, a modeler needs to remove the su x DAO to make the model hold one class with a clean name. This was achieved by a simple rename operation and now the model is free from technological details. At this point, the modeler only needs to add, e.g., a description and model can progress to \decent" stage. This means, it is all right but certainly not \ ne". Hence, the design should be revised, though this model is reusable in general. As a consequence, it is highly unlikely that it will be reused as it is. On the contrary, a modeler will most likely need to apply further add, delete, rename, or retype operations, if the model is reused. For example, some dependent classes, which obviously belong to this model, will need to be designed. In our example, a Jukebox is useless without a de nition of a MediaSet.
As soon as the model matured further, it can progress to \ ne" stage. This will have needed that some modelers reviewed this model or some of them removing model issues. Eventually, the gained snapshot might be like snapshot n from gure 1. Mind that, this happened only with our default set of operations, which is mentioned above. The point is, that this model came to a stage that is \ ne" for reuse. From now on, this model is valid in itself and can be reused by other modelers. Additionally, it might o er template support, which includes further modeling advise.
Since the quality of models and, likewise, template information breaks easily, when, e.g., add or delete actions are applied, only rename and retype actions are allowed in \ ne" staged models. This is due to add and delete operations altering the model in a way that might totally alter the purpose and validity of that model. This is why these actions lower the stage immediately. But it depends on the reasoning of a modeler to decide on the next stage. Most likely, the model will only drop to a vague stage if it was split in two distinct parts, which need to be considered as \new" in the model library. Otherwise, add and delete operations will lead to \decent" stage.
From the above, we understand that some of the transitions need a conscious decision whether the model progresses to another stage. In order to help modelers to take these decisions, a quality model would be bene cial. But it is challenging to nd such a model, since there is no precise de nition of reusability for model libraries, nor is there a common understanding of what a quality model for model libraries might be. This is why we investigated further and found that this particular environment focusing on reusability limits certain aspects extensively, so that we were able to propose a reasonable solution.
Restricting models to evolve in model libraries, where only
general characteristics such as model size, i.e., complexity,
are of relevance, model quality becomes manageable. If a
model conforms to these general quality characteristics, the
model is considered to have a high quality in a model library
and is reusable. In the following, we present our quality
model focusing on model libraries and thereby resolving the
challenge of being hard to de ne and measure due to its
highly subjective and relative nature [
Our quality model is based on the research of Lindland
et al. [
l e d o M
First, focusing on reusability, it is su cient to restrict syntactic quality to be described by the following three characteristics: Meta-model conformity describes the conformness of the model to the abstract syntax specifying the modeling language, i.e., the model is well-formed. Additionally, transformability states that a generator, which understands the model's syntax, can successfully transform a model into another representation, e.g., source code. Finally, a model is defect-free, if it does not contain any syntax errors. Moreover, syntactic quality can be used for error prevention, and error detection. Error correction is, however, not feasible, due to uncertain modeler goals.
Second, the extent to which the model describes the aspect it should model, i.e., correspondence between a model and its domain, is addressed by semantic quality. We subdivide this dimension into: validity, completeness, and connement. A model is of high validity if, and only if, every statement de ned by the model is valid in the domain. Whenever a model includes an invalid statement from the domain, it must be true that the advantage to simply remove this statement is higher than the drawbacks of adapting the whole model to the invalid statements. Furthermore, a model is complete if, and only if, there is no statement in the domain not yet included in the model, such that its bene t is higher than the drawback of adapting the model to this new statement. Third, if a model includes enough valid statements about the domain to describe the intention or to solve a problem in a domain, the model is con ne.
Third, pragmatic quality addresses the correspondence between a modeler's comprehension and a model. In other words, the model must be understood by a modeler correctly. In model libraries, model comprehension can be reduced to three characteristics: understandability, maintainability, and purpose extraction. Understandability refers to the degree to which the modeler's interpretation can be build from the model. Maintainability addresses the degree to which a modeler understood the model and is able to adapt it to environmental changes. Finally, if the modeler's extracted purpose of a model corresponds to the purpose originally de ned, the purpose extraction is high.
Last, emotional quality addresses the correspondence between a user's interpretation and his emotions. If a model is appealing to modelers, it is more likely to be reused. Consequently, such models have a high emotional quality. This model quality dimension is of importance in model libraries, since reuse depends on individual opinions about models. This model quality dimension is mentioned for the sake of completeness (cf. \thumb up button" in gure 5)
Each model quality dimension and especially the
corresponding characteristics have to be measureable in order to
enable qualitative statements about model quality in model
libraries. SDMetrics [
The staged model evolution aims at structuring and guiding model evolution in model libraries. The structuring is achieved by partitioning model evolution in three stages. The traversal of models through the stages highly depends on the modeler and his intention. However, stage traversal can be guided by introducing quality gates in order to make qualitative statements about model quality in each stage and thereby derive its reusability. In the following, we summarize the staged model evolution approach as presented in section 3.5 and derive quality gates for the stage transition.
Generally, quality gates can be seen as metaphorical gates. A model can pass a gate, if all requirements of this gate are ful lled. Figure 4 illustrates the staged model and the corresponding quality gates. The set of requirements for each gate is derived from the quality model for model libraries. start vague
QG 5
QG1 QG2 fine decent 4 QG
QG3 Each model underlying the staged model evolution starts in the vague stage and is aiming at reaching the ne stage to be recommended for reuse in the model library. The main goal of the vague stage is to remove all obstacles resulting from the fact that the model has been added to the model library or has been restructured from a previously ne model. When all of these activities are nished and the modeler intends to move the model to the decent stage, the model has to pass the rst quality gate QG1. The requirements of this quality gate are meta-model conformity, transformability, defect-freeness, semantical validity, and con nement. These requirements verify that (a) no pre xes and technological dependencies are included, (b) adapters for legacy are removed, and (c) the model has no errors. A model does not have to be semantically complete after passing this quality gate, because completeness is aimed for in decent stage.
When a model enters the decent stage, the staged evolution can be directed in two directions. First, if the modeler adapts the model to t the initial purpose and is satis ed with the chosen layout and solution, the model can be moved to the ne stage by passing quality gate QG3. Since the next level of reusability is \green", i.e., the model library may suggest this model to modelers for reuse, this quality gate requires all quality characteristics to be ful lled. Emotional quality, however, is not considered to be a requirement regarding the number of \likes", instead it shows that modelers agreed on the reuse of the model and its quality. Second, a model can be moved back to the vague stage due to errors in the model, restructuring, or even unsuitability of the model for reuse by passing quality gate QG2, which requires that at least one of the requirements for QG1 is violated.
After a model has been labeled to be reusable by entering the ne stage, di erent in uences might lead to the loss of its status. If the model requires adaption other than renaming or retyping, it has to be moved to decent or vague stage depending on the type of adaption. Restructurings of the model, which lead to model decomposition or even new models, require the model to be moved to the vague stage. This also holds true for bugs in the model, which are hard to x or are not going to be xed in the future. In any other case of adaption, the model has to be moved to decent stage. In both cases, the model has to pass either quality gate QG5 or QG4. Both require that at least one of the requiremnts for QG3 is violated. This non-determinism is rooted in the adaptions required to be made to the model. E.g., if a model needs to be completely restructured, it is moved to vague stage. 5.
Based on the staged model evolution, a software prototype in Eclipse has been implemented and evaluated. The main focus of the prototype is guidance of the modeler through the staged model evolution. Hence, a simpli ed representation of the staged model (cf. gure 4) was implemented and enhanced with some guidance to make the quality model work. For example, model metrics and model reviews are included to provide measures regarding the quality model introduced above. In addition, wizards check and display the status of each quality gate, whenever the modeler intends to change the current stage. An overview of the main elements of the prototype is illustrated in gure 5.
The simpli ed representation of the stages (top of the gure) contains a representation for each stage colored with respect to its reusability status, i.e., vague is red, decent is yellow, and ne is green. The current stage and the transitions a modeler can choose to reach another stage are highlighted. This color encoding helps displaying the limited actions a modeler can perform in each stage (cf. gure 2) and thereby increases guidance.
In addition to the three stages of the staged model evolution, it is always possible that a model can become deprecated. Then, the model is kept in its current stage and marked as deprected. The basket symbol in gure 5 allows the modeler to always mark the current model as deprecated. Please note that once a model becomes deprecated, its stage cannot be changed anymore.
Besides the stage representation, the prototype contains
a list of model metric values and model review reports to
display information about the model quality. We separated
model metrics in two categories: model defects and model
smells. The rst type of metrics indicates violations of
metrics that are known to be errors, e.g., a new class is
introduced without a class name. In contrast, model smells are
de ned based on Fowler's de nition of smells [
The use of model metrics requires modelers to either manually apply them or an approach to automatically apply model metrics and inform the modeler about the results. 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 quality guidance. This approach automatically calculates model metrics whenever a model has been changed and immediately displays metric violations, i.e., the modeler receives live feedback during modeling.
Another bene t of this approach is a set of clear instructions as the result of applying the metrics. These instructions inform the modeler about steps that need to be done to resolve the corresponding model metric violation. In combination with model reviews, which are required to be ful lled 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.
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 circumstances ease a few obstacles. Evolution, in general, is considered as aimless, but model libraries would loose their bene ts quickly evolving unguided. Hence, evolution needs to be guided in model libraries, which o ers a clear direction of evolution and provides opportunities to formalize and structure evolution in model libraries as we did above.
For structuring this evolution, we de ned an evolution graph and partitioned it based on model stages. These stages serve as indicators for model reusability. We de ned these stages to be vague, decent, and ne and attribute them with the colors red, yellow, and green respectively. This intuitive stage model allows to de ne gates that need to be ful lled before passing to the next better stage.
In order to de ne quality gates to separate model stages, we introduced a quality model, which de nes simple means of quality assurance. This is possible, because model libraries limit possible quality attributes and, hence, keep the scope of metrics small. All in all, we de ned syntactic, semantic, and pragmatic quality and added emotional quality, which proved reasonable in our experiments.
All together, we provided a foundation for quality staged model evolution in model libraries, which we implemented in tool support providing guidance for this holistic approach.
Besides evaluation of this approach, a novel and altered kind of co-evolution is subject to current and future work. Consider a model library that is more a knowledge base. It would certainly hold information how single models are related to each other. For example, relationships could be established between such models on di erent levels.
We created such a model library [
We would like to thank all our anonymous reviewers for their comments and e ort. Moreover, we would like to thank Andrej Dyck, Veit Ho mann, and Matthias Vianden. It was always a great to have another intriguing discussion.