INTRODUCTION
The Model Driven Architecture (MDA) [
1
] is an approach
to the development of software systems that promotes the use
of transformations between successive models from
requirements to analysis, to design, to implementation, and to
deployment [
2
]. Much attention has been paid to MDA by
academia and industry in recent years [
3
], which has resulted in
models gaining more importance in software development. The
Unified Modeling Language (UML) [
4
] is the Object
Management Group’s specification most frequently used and is
the de-facto standard modeling language for object-oriented
modeling and documentation [
5
]. It is the most commonly used
modeling language to implement the MDA although it should
not be used in every single software development project [
6
].
The UML provides 14 diagram types [
4
] that can be used to
describe a system from different perspectives (e.g., structure,
behavior) or abstraction levels (e.g., analysis, design), which
helps deal with complexity and distribute responsibilities
between stakeholders. Those diagrams help support many
software development activities, such as: transforming an
analysis model into a design model, transforming a design
model into an implementation, generating documentation,
model-driven testing, model-driven validation and verification,
performance estimation, and schedulability analysis. Since the
various UML diagrams describe different perspectives of one,
and only one, software under development, they strongly
depend on each other and hence must be consistent. To be
successful, any software development activity that consumes a
UML model made of diagrams, such as the ones mentioned
earlier, requires that those diagrams be consistent. As UML is
not a formal notation, inconsistencies may arise in the UML
specification of a complex software system when such
specification requires multiple diagrams to describe different
perspectives of the software [
7
]. When UML diagrams portray
contradicting or conflicting meaning, the diagrams are said to
Yvan Labiche
be inconsistent [
8
]. Such inconsistencies may be a source of
faults in the software system [
9
]. It is therefore paramount that
they be detected, analyzed and fixed [
10
], which requires that
consistency between the diagrams of a UML model be first
specified. One can find some UML diagram consistency
specifications in the UML standard itself, where they are often
referred to as well-formedness rules. As discussed in the
literature, one can reason about consistency according to
different dimensions: Horizontal vs. Vertical vs. Evolution
Consistency, Syntactic vs. Semantic consistency, and
Observation vs. Invocation consistency [
11
]. One can find
consistency specification in the UML standard itself. One can
also imagine consistency specification that is specific to a
domain (e.g., telecom, aerospace), to an organization, to a
project or a team. Even though there is a need for UML
diagram consistency, even though there exist different ways to
reason about consistency rules, one can observe from the
literature [
11
] that: 1) there is no well-accepted set, as
complete as possible, of consistency specification rules, or
simply rules, for UML diagrams (beyond the small set of
wellformedness rules in the standard specification); 2) many
researchers have proposed, explicitly or implicitly, rules to
detect inconsistencies, without any effort to validate those
rules; 3) the majority of the consistency rules target a small
subset of the UML diagrams (mostly, class, sequence, and state
machine diagrams); 4) a non-negligible set of consistency rules
are provided over and over again by researchers (instead of, for
instance, referring to an accepted list of such rules); 5) a
nonnegligible set of consistency rules presented by researchers are
actually included in the UML standard itself; 6) the UML
standard is far from providing a comprehensive set of
consistency rules; 7) the vast majority of consistency rules are
horizontal and syntactic (other dimensions are barely used in
those rules). These observations motivated WUCOR, during
which we sought the opinion of experts about the consistency
rules researchers have been defining in the literature, and the
rules that may be missing. The goal of this workshop has been
to gather community input and feedback on UML consistency
rules in general. WUCOR provided an opportunity for
researchers who have been working on UML consistency, or
whose (research) activities require consistent diagrams, to
engage with each other in a highly interactive venue so that the
group could validate the rules that have been collected and
pave the path for future initiatives. The objective of the
workshop has been to bring together any one, either from the
industry or academia, interested in consistency rules between
UML diagrams of a given model, and to provide a platform for
discussions, interactions and collaborations regarding this
topic. One of the starting point for the discussion groups was
the set of 190 unique consistency rules we have coalesced in
our work [
12
]. We also asked for expert opinion about a subset
of those rules that are deemed paramount, and should therefore
always be enforced, and other rules that can be considered
optional. The final program of the WUCOR is presented in
TABLE I.
Time
8:45am
8:50am
9:15am
9:40am
10:20am
10:45am
11:45am
1:00pm
1:10pm
3:00pm
3:20pm
4:45pm
Duration Activity
5min Welcome to WUCOR
Bernhard Hoisl and Stefan Sobernig.
25min sCpoencsiifsictencLyanRguulaegse
foMrUodMelLs:-baAsedLDitoermaatuinre
Review
Dan Chiorean, Vladiela Petrascu and Ioana
25min Chiorean. Proposal for Improving the UML
Abstract Syntax
40min 1CsotnsAisctetvnictyy about dimensions of UML
25min Coffe Break
1hr 2UsMtALctCvoitnysiasbteonuctyUML diagrams involved in
1hr15min Lunch Break
10min Introduction to UML Consistency Rules
rd Activity about UML consistency rules in
1hr50min 3Model-Driven Development
20min Coffe Break
1hr25min Discussion and Presentation of Results
15min Conclusion, Summary and Next Steps
The WUCOR proceedings collect the two papers presented
at the workshop (shown in TABLE I). Those submitted papers
were peer-reviewed by three independent reviewers. The two
accepted papers discuss 1) a review about UML-based
Domain-specific Language Models, and 2) a proposal for
Improving the UML Abstract Syntax; both papers were
considered very related to UML Consistency rules issues.
We would like to thank the authors for submitting their
papers to WUCOR. We are also grateful to the members of the
Program Committee and to the MODELS 2015 organizers for
their support during the workshop organization. For more
information about WUCOR please visit the workshop website
at https://wucor.wordpress.com. The Program Committee was
composed by :
• Steve Cook, Hidden Symmetry Ltd, UK
•
•
•
•
•
•
•
•
•
•
•
Alexander Egyed, Johannes Kepler University, Austria
Kenn Hussey, Committerati Consulting, Canada
Zbigniew Huzar, Wroclaw University of Technology,
Poland
Robert Karban, Jet Propulsion Laboratory, USA
Florian Noyrit, CEA LIST, France
Richard Paige, University of York, UK
Gianna Reggio, Università di Genova, Italy
Nicolas Rouquette, Jet Propulsion Laboratory, USA
George Spanoudakis, City University London, UK
Mehrdad Sabetzadeh, University of Luxembourg,
Luxembourg
Miroslaw Staron, University of Gothenburg, Sweden