Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
DOI 10.1007/s10270-014-0441-1
REGULAR PAPER
Abstract We present Clafer (class, feature, reference), a show that Clafer meets its design objectives using examples
class modeling language with first-class support for feature and by comparing to other languages.
modeling. We designed Clafer as a concise notation for meta-
models, feature models, mixtures of meta- and feature mod- Keywords Language design Feature modeling OOM
els (such as components with options), and models that cou- Semantics Unification
ple feature models and meta-models via constraints (such
as mapping feature configurations to component configura-
tions or model templates). Clafer allows arranging models 1 Introduction
into multiple specialization and extension layers via con-
straints and inheritance. We identify several key mechanisms Both feature and meta-modeling have been used in Software
allowing a meta-modeling language to express feature mod- Product Line (SPL) engineering to model variability. Feature
els concisely. Clafer unifies basic modeling constructs, such models can be seen as tree-like menus of mostly Boolean,
as class, association, and property, into a single construct, sometimes also numerical and textual, configuration options,
called clafer. We provide the language with a formal seman- augmented with cross-tree constraints [45]. These models
tics built in a structurally explicit way. The resulting seman- are typically used to show the variation of user-relevant
tics explains the meaning of hierarchical models whereby characteristics of product variants within a product line. In
properties can be arbitrarily nested in the presence of inher- contrast, meta-models, usually represented as class models
itance and feature modeling constructs. The semantics also as expressed using Meta Object Facility (MOF) [54], spec-
enables building consistent automated reasoning support for ify concepts representing more detailed aspects of products,
the language: To date, we implemented three reasoners for including behavioral and architectural aspects. For example,
Clafer based on Alloy, Z3 SMT, and Choco3 CSP solvers. We meta-models are often used to specify the component and
connector types of product-line architectures and the valid
Communicated by Dr. Benoit Baudry. ways of connecting them. The nature of variability expressed
by each type of models is different: Feature models capture
K. Bak (B) Z. Diskin M. Antkiewicz K. Czarnecki
GSD Lab, University of Waterloo, Waterloo, Canada
selections from predefined choices within a fixed tree struc-
e-mail: kbak@gsd.uwaterloo.ca ture; meta-models support making new structures by creating
multiple instances of classes and connecting them via links.
Z. Diskin
e-mail: zdiskin@gsd.uwaterloo.ca Over the last decade, the distinction between feature mod-
M. Antkiewicz
els and meta-models has been blurred in the literature due to
e-mail: mantkiew@gsd.uwaterloo.ca (i) feature modeling extensions, such as cardinality-based
K. Czarnecki
feature modeling [6,21], (ii) proposals to unify feature mod-
e-mail: kczarnec@gsd.uwaterloo.ca eling notations into a useful and widely applicable sub-
A. Wasowski
set [58], and (iii) attempts to express feature models as class
IT University of Copenhagen, Copenhagen, Denmark models in the Unified Modeling Language (UML) [16,23].
e-mail: wasowski@itu.dk In fact, a number of practitioners use UML-based repre-
123
K. Bak et al.
sentations to model variability [11]. A key driver behind particularly, concept unification, instance composition
some of these developments has been the desire to express and type nesting, and default singleton multiplicity.
both configuration options and variability of component 2. We unify basic constructs of structural modeling: class,
architecture instantiations in one notation [19,32,37,38]. association, and property (which includes attribute, ref-
Cardinality-based feature modeling achieves this by extend- erence, and role), into a single construct, called clafer.
ing feature models toward class modeling by introducing Such a construct has the characteristics of a class (ability
multiple instantiation and references. It is incomplete, how- to nest and inherit properties and other classes in it), an
ever, because it does not offer inheritance. Class modeling, association (ability to navigate over it), and an attribute
which natively supports multiple instantiation, references, (ability to store single or multiple (set, bag) values of
and inheritance, enables feature modeling by a stylized use primitive types in it).
of containment (UMLs composition) and the profiling mech- 3. Rich semantic capabilities are packed into very compact
anisms of MOF or UML (e.g., as in [34]). syntax that makes class models concise. If necessary,
Both developments have notable drawbacks, however. concrete uses of Clafer could introduce syntax to distin-
An important advantage of feature modeling as originally guish among the various interpretations of clafers, such
defined by Kang et al. [45] is its simplicity; several respon- as features, classes, components, as well as, any domain-
dents to a recent survey confirmed this view [46]. Extending specific concepts.
feature modeling with multiple instantiation and references 4. We provide a mathematical model of Clafers syntacti-
diminishes this advantage by introducing additional com- cal mechanism (meta-models and the overall architec-
plexity. Models that contain significant amounts of multiply ture) using formal class diagrams [29], which is a struc-
instantiatable features and references can be hardly called tural modeling formalism based on category theory and
feature models in the original sense; they are more of class diagrammatic logic [31]. The formalism has allowed us
models rather than easy-to-use menus guiding configura- to define semantics concisely by specifying mappings
tion decisions. On the other hand, whereas the model parts between artifacts and operations over the artifacts and
requiring multiple instantiation and references are naturally mappings. The structures of the syntactic and semantic
expressed as class models, the parts that have feature mod- domains are aligned and made explicit rather than flat-
eling nature cannot be expressed simply in class models, tened and hidden in a multitude of first-order logic for-
but rather clumsily simulated using composition hierarchy mulas.
and certain modeling patterns. Even worse, such a solution
requires inconvenient model refactorings, while according to The main benefit of semantic unification is simplification
a recent survey [11], evolvability of variability models is one of analyses and tools that operate both on feature and class
of the main challenges faced by practitioners. models, and mappings between them. The language is sup-
We present Clafer (class, feature, reference), a language ported by tools for model analyses including consistency
that unifies feature and class modeling. It can naturally checking, instantiation and instance completion [48,49],
express feature models, while allowing for full-class model- and single- and multi-objective optimization [53]. Analyzes
ing and relating both types of models. Clafer supports the fol- are performed by translating Clafer models into the input
lowing: (i) class-based meta-models, (ii) object models, (iii) language of the underlying backend solvers (Alloy rela-
partial object models (with uncertainty), (iv) feature models tional logic solver [40], Z3 satisfiability modulo theories
with attributes and multiple instantiation, (v) full and partial (SMT) solver [26], and Choco 3 constraint satisfaction prob-
configurations of feature models, (vi) mixtures of meta- and lems (CSP) and constraint programming (CP) solver) [44].
feature models and model templates [18], (vii) first-order The results of the analysis are translated back to Clafer. We
logic constraints. Clafer also allows arranging models into also provide a web-based suite of tools for working with
multiple specialization and extension layers via constraints Clafer models and the backend solvers [3,52].
and inheritance. On the other hand, by designing Clafer we In the industrial context, support for variability is needed
wanted to create a language that builds upon as few concepts when modeling product-line architectures using such stan-
as possible and that is easy to learn. The main principle guid- dards as AUTOSAR [56], EAST-ADL [17], and SysML [35].
ing our design was that simple things (feature models and These standards do not require the unification of feature and
simple constraints) should be natural and simple while com- class modeling; however, they point to the need of having
plex things (meta-models and complex constraints) should both feature and architectural models in a single, integrated
be possible. system specification. In fact, the first level of an EAST-ADL
In this paper, we present several contributions. specification is the technical feature model and AUTOSAR
defines a feature model interchange format [57] allowing for
1. We identified several key mechanisms allowing a meta- integration of external feature modeling tools and support for
modeling language to express feature models concisely; adding variation points into AUTOSAR models. The thesis
123
Clafer: unifying class and feature modeling
123
K. Bak et al.
plaECU (product-line architecture ECU) specifies that each The example motivates two issues of modeling variability
ECU will have either one or two plaDisplays. We specialize in SPLs: (1) the necessity to merge feature and class mod-
the component meta-model by adding extra information via els in a single solution space and (2) the need to support
constraints: None of the displays has cache, and we con- relating (mapping) feature configurations to component and
strain the server reference in each plaDisplay, so that it option configurations. In the next section, we will show that
points to its associated ECU. A concrete product must have managing the issues is not straightforward and challenging.
at least one ECU. Hence, there are two singleton subclasses, Correspondingly, we will refer to them as Problem 1 and
ECU1 and ECU2 (with multiplicities 1..1), that serve as a Problem 2.
specification of objects. We choose to specify objects by sin-
gleton classes because for ECU2 we need to extend the base
type with new property master that was not specified in the 3 Two problems
high-level component class. Modeling ECU2 instance as a
singleton class solves this problem (a more detailed discus- 3.1 Problem 1: merging feature and class models
sion of modeling objects by singleton classes can be found
in [14]). The solution space in Fig. 2 contains a class-based meta-
We need to endow the class model with a variability model and a feature model. To capture our intention, the
mechanism aligned with variability provided by the feature models are connected via UML composition. As the precise
model (from the solution space). One way of doing this is to semantics of such notational mixture is not clear, this connec-
make the existence of some classes in the template optional tion should be understood only informally for now. Basically,
by annotating them with propositional formulas composed we have two choices to model components and options in a
from features offered by the feature model (so-called pres- single notation: either enrich feature modeling to allow it to
ence conditions introduced in feature-based model templates capture class modeling, or encode feature models as class
(FBMTs) [18]). In Fig. 2d, class ECU1 is mandatory and models. We will consider them in the two consecutive sub-
class ECU2 is optional, because its presence in the model sections.
is regulated by the condition dual, which refers to a
feature from Fig. 2a. The presence condition means that in 3.1.1 Class modeling via feature modeling
a concrete configuration, ECU2 will be included if the fea-
ture dual is selected; it will be removed otherwise. Thus, Figure 3 shows the part of the model which represents com-
FBMTs relate the problem-space feature configurations to ponents. The model introduces a synthetic root feature; dis-
the solution-space component and option configurations. A play and ECU can be multiple instantiated (as indicated by
block arrow in Fig. 2 represents this mapping. We will pro- the multiplicity *), but they cannot be abstract; display has
vide a precise specification of the complete mapping later in a server subfeature representing a reference to instances of
this paper. ECU. Two subfeatures version are added to display and
123
Clafer: unifying class and feature modeling
(a)
(b)
123
K. Bak et al.
3.2 Problem 2: mapping features to component 4 Clafer versus the two problems
configurations
4.1 Clafer in a nutshell
Relating heterogeneous models by a mapping is a non-trivial
task. For example, a FBMT in Fig. 2 relates a feature model, Clafer has a minimalistic syntax but rich semantics that
a class model (of components), and (implicitly) their meta- unifies class, association, and property (which includes
models. As annotations, such as dual, change the class attribute, reference, and role) into a single construct called
model itself, complicated syntactic checks are needed to clafer. Throughout the paper, if the word Clafer begins with
guarantee the correctness of all template configurations. For upper case, then it refers to the language, otherwise it refers
example, when dual is deselected and ECU2 is con- to the unifying concept or the corresponding construct, or to
sequently removed, then master may become a dangling a syntactical unita model expressed using Clafer is built
association (because it is mandatory and has no presence from clafers. For example, Fig. 6a shows a sample Clafer
condition). Thus, the configured template does not conform model consisting of two clafer declarations. First, a clafer
to the UML meta-model for class diagrams. Verification of display is declared, then the declaration of the clafer server
annotative model templates is a non-trivial task and requires is nested under the first declaration (display, implicitly, is
specialized tools [24]. nested under the synthetic root clafer, i.e., ancestor of all
clafers). A clafer declaration includes multiplicities and may
3.3 Toward a solution optionally contain a superclafer or a reference to a clafer or
both. In the example, the clafer display has the multiplicity *:
We conclude that a solution to the aforementioned issues is There can be any number of instances of this clafer. The clafer
to design a (class-based) meta-modeling language with first- server refers to the clafer ECU (defined elsewhere in the
class support for feature modeling. We postulate that such a model), and it has multiplicity 1..1: Each display has exactly
language should satisfy the following design goals: one ECU server.
The clafer declaration (server) specifies a relationship
1. Provide a concise notation for feature modeling, between its parent class (display) and its target class (ECU),
2. Provide a concise notation for class modeling, and it declares the following (cf. Fig. 6b):
3. Allow mixing of feature models and class models,
4. Use a minimal number of concepts and have a uniform 1. A new class server and a bidirectional composition asso-
semantics. ciation, which enables navigation to the introduced class
via the end server and back to the parent/owner;
The last requirement is aimed at a language that unifies the 2. A unidirectional association dref (dereference) to navi-
concepts of feature and class modeling as much as possible, gate to the target class from the new class;
both syntactically and semantically. We see the following 3. A unidirectional association server* to navigate to the tar-
advantages of unification: (1) the ability to encode a vari- get from the parent class (note that the * mimics a deref-
123
Clafer: unifying class and feature modeling
123
K. Bak et al.
123
Clafer: unifying class and feature modeling
123
K. Bak et al.
in figures throughout the paper is that shaded shapes are reference clafer master is contained within plaECU and,
assumed to exist, whereas blank shapes are assumed to be simultaneously, has plaECU as a reference target. Further-
fully derived. more, it is possible to navigate from the top-level plaECU
Figure 13 illustrates that a Clafer Model is typed over to the one pointed to by master. Figure 14d shows an intu-
and required to conform to the Abstract Syntax Tree itive meaning of the model, i.e., a UML class diagram with
(AST) Meta-Model (cf. the constraint | ). Then, the Clafer a reified association being a loop. This intuitive meaning
Model is compiled into an intermediate representation, a is precisely captured in Fig. 14b by an MCS that follows
Multi-Clafer Shape (MCS) , which is typed over and cre- the concrete syntax of Clafer. MCS defines Clafer models
ated so that it conforms to the MCS Meta-Model (cf. the in terms of formal class diagrams [29] (formal CDs or just
constraint | ). The MCS structurally resembles the Clafer CDs for short), which we use as a notation for our semantic
Model, and it is not yet a class diagram as class names can domain. In general, an MCS is a tree-like structure com-
repeat when classes play different roles. Therefore, the MCS posed by joining Clafer Shapes (CSs). A single Clafer Shape
needs to be transformed into a Class Diagram (CD), which (CS) represents a single clafer declaration. In the example,
is typed over and created so that it conforms to the CD Meta- the MCS is composed of only one CS.
Model. Roughly, the transformation glues classes with the A formal CD is a graph with additional labels encoding
same name playing different roles into single classes. constraints. For the CD in Fig. 14b, the graph encompasses
At this point, the class diagram can be given to a backend three nodes and three edges, and the constraint labels denote
reasoner for instantiation, which creates an Object Diagram multiplicities and a commutativity constraint ([=]). Nodes of
(OD) typed over and required to conform to the class diagram the graph (think of UML classes) are interpreted as sets (of
CD. Now, the object diagram must be claferized, that is, their instances). Edges (think of UML associations) are inter-
transformed into an instance Multi-Clafer Instance (MCI) preted as mappings, i.e., sets of links mapping elements from
typed over and conforming to the MCS. In the MCI, objects the source set to the elements of the target set. The commu-
are replicated so that they can appear in the original positions, tativity constraint denotes that the mapping master* is the
as before the gluing. The instance MCI can now be decom- sequential composition of master followed by dref. In fact,
piled into a Clafer Instance. Note that the Clafer Instance is this equality means that class master together with its pair
transitively typed over the AST Meta-Model, which explains of associations (parent, dref) can be considered as reification
why instances in Clafer have the same notation as the Clafer of association master* (which is shown by a dashed line in
modelsthey have the same abstract syntax. For example, the UML diagram in Fig. 14d).
compare the clafer options from Fig. 7 and its instances o1 We use the following notation for maps (edges). Prede-
o4 in Fig. 12, lines 10, 16, 25, and 31, respectively. fined maps, e.g., parent, are underlined. By default, maps
In our toolchain [3], the Clafer compiler first parses a tex- are partially defined and multi-valued, and are denoted by
tual Clafer model into its abstract syntax tree Clafer Model arrows with a black triangle head; see, e.g., the shapes of
and then compiles it into an MCS. Next, the compiler trans- arrows master and master* in Fig. 14b. An open arrow head
forms the MCS into an encoding of a class diagram CD in (e.g., arrow dref) means that the map is single-valued: each
the language of the chosen backend solver, such as, Alloy, instance of master points to at most one instance of plaECU.
SMT-LIB, and Choco 3. The backend solver then produces A black bullet arrow tail means that the map is total: each
object diagrams OD which are instances of the class diagram instance of master points to at least one instance of plaECU.
CD. Finally, these ODs are translated back to Clafer syntax. A black diamond arrow tail (arrow master) denotes contain-
ment considered as a conjunction of two conditions: multi-
5.1 Clafers as views onto class diagrams plicity 1 (there is one and only one instance of plaECU for
an instance of master) and existence dependency (deletion
Figure 14a shows a Clafer model where plaECU is a top-level of an instance of plaECU implies the deletion of its nested
basic clafer with an unrestricted multiplicity. The optional instance of master). The first condition is often referred to
Fig. 14 a A Clafer model, b its compilation, c label extraction, d the rendering using reified association
123
Clafer: unifying class and feature modeling
inv Maps f, g are mutually inverse iff their spans f , g are such
= f .g = h
mult-trg m | f (a)| n
as non-sharing (and the multiplicity is sometimes relaxed Notice, however, that the MCS in Fig. 14b is not a
to 0..1). The second condition is also referred to as cascade valid class diagram, because it contains two classes named
deletion. Although it is not expressible in the CD formal- plaECU. What is the meaning of this strange diagram then?
ism described in this work (which does not have any means In contrast to class diagrams (where names are unique), the
of expressing dynamic constraints), it is an important part of Clafer model (and the corresponding MCS) distinguishes two
Clafer semantics. Existence dependency can be formalized in different roles that instances of the class plaECU can play:
the framework of Class Diagrams with dynamic predicates (i) being the parent of reference master and (ii) being the
described in [30]. Our arrow notation for maps is summa- target of the reference. What Fig. 14b actually encodes is a
rized in Table 2. Table 3 summarizes the diagram predicates mapping from a diagram of roles to a diagram of classes and
we use. They are formally defined in Appendices 1 and 2. associations, as shown in Fig. 14c. The source of the map-
We mark a non-constrained bag-valued mapping with the ping is the carrier graph of the diagram from Fig. 14b. The
label [bag] while being set-valued is assumed by default and target is a formal class diagram that makes the meaning of
we hide the predicate [set]. Note the difference between the the class diagram from Fig. 14d precise. Indeed, as an object
arrow heads for a general multi-valued mapping (a black tri- of class master is supposed to reify a master link, such an
angle) and a single-valued mapping (an open arrow-head). object must have a source projection reference (to the source
123
K. Bak et al.
123
Clafer: unifying class and feature modeling
They correspond to bag-valued references, i.e., two or more Abstract clafers define only a type (no direct instances). We
references from the same source instance can point to the distinguish nested and top-level abstract clafers. The CS of
same target instance. The target clafer name follows the the former is the same as of previously described clafers. Top-
double arrow symbol (). For example, there may be sev- level abstract clafers, on the other hand, have slightly differ-
eral connections from a display to ECU. The second row of ent CSs: They have no parent in the containment hierarchy,
Table 4 illustrates a compilation of the reference bag clafer i.e., the CS excludes the head class and the corresponding
server to a corresponding CS. In fact, reference bag clafers maps. When a top-level clafer is declared abstract, then all
follow the structure of basic clafers, but additionally have its descendants (in the containment hierarchy) are declared
the target class (cf. Fig. 16). In reference bag clafers, the abstract by default; this is the only case in which abstract
target map is bag-valued, hence the annotation [bag] on clafers are nested.
server*.
123
K. Bak et al.
(a)
(b) (c)
(c)
(d)
Fig. 17 Compilation of a Clafer model to an MCS, gluing into a CD, and instantiation, a Clafer model, b corresponding MCS, c definition of the
mapping label, c corresponding MCS mapped via label defined in (c) to a CD, d an MCI mapped via label* to a sample OD
123
Clafer: unifying class and feature modeling
123
K. Bak et al.
123
Clafer: unifying class and feature modeling
(a) (b)
(c)
Fig. 21 Formal class diagrams: an instance in UML (a), formal CD rendering (b), and the meta-model (c)
single-valued. In contrast, display is a general mapping, i.e., us the links. If, for example, for an object e ECU,
partial and multi-valued. we have display(e) = {d1, . . . , dn} Display, then
Very important and very special mappings are inclusions, in the object diagram we create n links from ECU e to dis-
which are denoted by arrows with a hollow-triangle head plays d1, d2, . . . dn, all typed by mapping display. We will
see arrows i1 and i2 in the diagram of Fig. 21b. An inclusion also have a link from e ECU to e Comp typed
between two sets can be defined iff the source is a subset of by i1, a link from e Comp to an integer version(e),
the target; inclusion maps each element of the source to itself, and so on. In this way, a mega-mapping .. gives rise to a
but now considered as an element of the target. For example, directed graph G .. of objects and links, and a typing map-
inclusion i1 means that ECU Comp and i1(e) = e ping t.. : G .. [FD ], which again respects the graph
for all e ECU. Thus, inclusion changes the role/type of structure. Conversely, an object diagram O with object-link
ECU object e: object i1(e) is a component with all its ECU- graph G O and typing mapping t O : G O [FD ] gives rise
properties forgotten. In this way, inclusions model inheri- to a mega-mapping .. O : [FD ] SetMap by defining
tance. As there can be only one inclusion between a subset
and its superset, we can name all inclusions by the same ECU O = {n is a node (object) in G O : t O (n) = ECU},
default name isA and omit it in concrete visualizations of Display O = {n is a node in G O : t O (n) = Display},
formal CDs. Labels i1, i2 in Fig. 21b are IDs of the arrows server O = {a is an arrow (link) in G O : t O (a) = server}
rather than their names.
The discussion above can be summarized by saying that and so on. An accurate formal definition of this construction,
an instance of formal class diagram FD is a mega-mapping and a proof of equivalence of the two ways of instantiating
.. : [FD ] SetMap from the carrier graph of FD into formal class diagrams (via mega-mappings into SetMap and
a universe of sets and mappings, SetMap, also arranged as typing), are known in category theory under the name of the
a directed graph: Nodes are sets and arrows are mappings Grothendieck construction [10].
between sets. This mega-mapping preserves the graph struc-
ture (nodes are mapped to nodes and arrows to arrows so that 6.1.2 Instantiation of formal CDs, II: the constraints
their incidence is preserved) and respects mappings proper-
ties: Arrows with bullet tails are mapped to total mappings in We have already discussed multiplicitiessimple constraints
SetMapand arrows with hollow-triangle heads are mapped assigned to single arrows. However, the diagram FD also
to inclusion mappings in SetMap, etc. has four constraints shown in square brackets, which regu-
A mega-mapping .. is practically equivalent to the stan- late instantiation of groups of arrows. Three of them, [disj],
dard UML understanding of instantiation as having an object [cover], and [inv], have a predefined meaning and their names
diagram typed over a class diagram. Indeed, sets ECU, are written in small font; the fourth, [VC], has a user-defined
etc., give us the objects, and mappings server, etc., give meaning specified by the OCL expression in Fig. 21a (links
123
K. Bak et al.
from the label [VC] to the four arrows, whose instantiation 6.1.3 Meta-model
[VC] constrains, are not shown in the diagram to avoid line
clutter). A meta-model of formal CDs is specified in Fig. 21c. It is
In the abstract syntax, the four constraints encode the itself a formal CD, MCD , and any valid formal CD should
following expressions: [inv](server, display), [disj](i1,i2), have a valid instance .. : MCD SetMap. The meaning of
[cover](i1,i2), and [VC](server, i1, i2, version) of the for- the central part (dashed-framed) of the formal CD is standard;
mat P(a1 , . . . an ) with P a predicate name and a1 . . . an a we show how it works for our formal CD FD in Fig. 21b. The
list of arguments matching the predicates arity. The predi- latter is the following instance of the meta-model (we denote
cate [inv] can be declared only for two arrows between two names of meta-classes in Small Capital font):
classes going in the opposite directions, [cover] works for a
Class = {#Comp, #Int, #ECU, #Display},
group of arrows with a common target, and [disj] has the same
arity. We can use these arities to check correctness of con- Map = {#version, i1, i2, #server, #display},
straint declarations. Similarly, multiplicities are constraints
for a single arrow, and diagram FD actually declares several
where #xyz denotes the ID of the classifier named xyz. This
such constraints: [single-valued](server), [total](version),
gives us the set Classifier = Class Map. Mapping
[0..5](display), etc., and also [incl](i1), [incl](i2).
name is defined as follows:
In contrast, the arity of the user-defined predicate [VC]
is given by the constraint declaration, and the arity condi- name(#ECU) = ECU String,
tion is automatically true as soon as the expression is syn- name(#display) = display String,
tactically correct. In fact, any OCL, or another constraint
language, expression written over a class diagram can be ...,
trivially considered as a respective diagram predicate decla- name(i1) = name(i2) = is A String,
ration of the aforementioned format. Moreover, there exists a
where String is the set of all possible strings, and string
compact set of predefined diagram predicates, which allows
isA is the default name of all inclusions.
one to express any FOL (and actually higher-order too) con-
Definition of mappings so and ta are also clear:
straint as a composition of these predefined predicates [47].
This result may be useful for our future work on Clafer, so(#display) = #ECU,
but we do not need it here. The Clafer compiler treats a ta(#ser ver ) = #ECU,
Clafer constraint expression as a property of the respec-
tive configuration of classes and mappings, like it is done
in OCL. and so on. And Incl = {i1,i2} so that Incl Map
Each predefined predicate has a certain semantics in terms as required. It is also easy to check that mega-mapping ..
of sets and mappings (cf. Table 3). For example, two map- is a correct graph morphism, and all multiplicities are also
pings with a common target satisfy the predicate [cover] iff respected.
any element in the target belongs to the image of one of the Let us consider the meaning of the left part of the meta-
mappings, or to both. The latter possibility is prohibited by model (to the left of the dashed frame). Meta-class SING is
predicate [disj]. Predicate [inv] holds iff the two mappings a singleton with a predefined (but optional) instantiation by
are mutually inverse. For example, for any ECU e and dis- a class Sing, which, in turn, is instantiated (optionally) by
play d, e server(d) iff d display(e). Semantics of a predefined object *; that is, for any formal CD F instanti-
user-defined predicates is given by the user. Thus, a legal ating MCD , set SING F is (either empty or) the same fixed
instance of diagram FD is a mega-mapping .. such that singleton class {Sing}; for any object diagram O instantiat-
all constraints declared in [FD ] are satisfied. Note that we ing F, Sing O is (either empty or) the same fixed singleton
have modeled abstractness of class Comp by requiring the {*}. Meta-class SING is not instantiated in CD in Fig. 21b,
two inclusions to be covering, i.e., stating that but in formal CDs generated by the Clafer compiler, class
Sing is always present as discussed in Sect. 5.3.
Similarly, the meta-class Dom is instantiated by (names
Comp = ECU Display
of) predefined primitive-value domains like Int, String, or
Bool, which, in turn, are instantiated by predefined sets of val-
and hence, any component is either ECU or Display (but ues. For example, for formal CD in Fig. 21b, Dom={#Int},
not both because of the [disj] declaration). In contrast to the and instances of #Int are predefined integer values. Thus, for a
UML class diagram in Fig. 21a, writing the name Comp in CD F, we have a set of predefined classes Predef F , which
italic in the formal CD is a pure decoration without semantic have predefined fixed names, say, name(#Int) = I nt
meaning. PredefStr and are common for all CDs. Constraint [nd]
123
Clafer: unifying class and feature modeling
Signature = {[cover],[disj],[inv],[incl],[set],[VC]}
{[m..n]:m N, n N {}}
although not all multiplicities are used. Meta-class Formula Fig. 22 Clafer AST meta-model
is instantiated by constraint formulas declared in the CD, and
the constraint [key] states that a formula Formula is includes the CD meta-model but names its elements differ-
uniquely determined by its predicate symbol P = pred() ently. We describe the meta-models in Sects. 6.2.2 and 6.2.3,
and its list of arguments (a1 , ..., an ) = args() (we respectively.
consider a list of formulas as a bag/family of formulas Formally, all nodes at the model and meta-model levels
indexed by natural numbers, see section Multi-valued func- in Fig. 13 are CDs (i.e., DP-graphs). The vertical arrows are
tions of Appendix 2); that is, a formula is actually a pair graph morphisms typing elements in their source graphs by
(P, (a1 ...an )), which we typically write as P(a1 ...an ). For elements in the target graphs. In addition, these typing map-
example, for the diagram in Fig. 21b, the set Formula is pings must satisfy constraints declared in their target graphs
(meta-models). We visualize this requirement by labeling the
{[disj](i1, i2), [cover](i1, i2), [inv](#server, #display), mapping with the entailment symbol | .
[incl](i1), [incl](i2), [0..5](#display),
6.2.2 Abstract syntax tree
[1..1](#version), [0..1](#server)
[VC](#server, i1, i2, #version)} The AST meta-model (cf. Fig. 22) specifies the abstract syn-
plus three default declarations tax of Clafer. The AST corresponds to a grammar of Clafer
models (cf. Fig. 27, Appendix 3). We discuss the meta-model
{[set](#version), [set](#server), [set](#display)}. starting from the left. Each clafer has a name, some multi-
plicity and, optionally, a super-type. The class BasicClafer
Importantly, the list of arguments in the formula P(a1 , .., stands for a basic clafer declaration; RefClafer for ref-
an ) must match the arity of predicate symbol P as it was erence clafer; and RefSetClafer for reference set clafer.
discussed in Sect. 6.1.2. In detail, the mapping args is bag- The map target specifies the target of a reference clafer, and
valued, and the indexing set for a formula (section Multi- the map abstract indicates whether a clafer is abstract. The
valued functions of Appendix) is the list of the arrows of the class Dom represents a family of primitive domain clafers
arity graph of predicate pred(); a precise formal definition (e.g., clafer Int is a basic clafer whose parent is synthetic
can be found in section Multi-valued functions of Appen- root); the singleton class Sing represents the synthetic root
dix. This condition is encoded by a meta-constraint [ad] (read clafer. The map parent establishes the containment hierar-
Arity Discipline), which is a part of the meta-model like other chy among Clafers. It is specified for each clafer besides
meta-constraint declarations: [key](args, pred), [nd], etc. the synthetic root and top-level abstract clafers: For any clafer
Thus, legal instances of the meta-model Fig. 21c are (for- C, if C.parent = and C
= Sing, then C.abstract = true.
mal) CDs or, synonymously, DP-graphs. The class Constraint represents user-defined constraints
in Clafer models. The map context points to the clafer in
6.2 Formalizing Clafer syntax which a constraint was declared. The map scope indicates
a bag of clafers that each constraint refers to (besides the
6.2.1 Architecture of Clafers syntactical mechanism context clafer). For example, group cardinalities, such as the
xor group cardinality in line 2 in Fig. 7, are simple constraints
We already presented the syntactical mechanism of Clafer in that relate a clafer with its children. There, the constraint
Fig. 13. There are three meta-models: Abstract Syntax Tree c relates the clafer size with its children small and large;
(AST) Meta-Model, Multi-Clafer Shape (MCS) Meta- formally:
Model, and Class Diagram (CD) Meta-Model. The MCS
meta-model includes the AST meta-model and extends it context(c) = size,
with new properties of clafers. The MCS meta-model also scope(c) = {small, large}.
123
K. Bak et al.
123
Clafer: unifying class and feature modeling
Table 7 Clafer kind constraints in the context of Clafer, which the 3. Clafer Kind/Shape Discipline Equations specify the struc-
MCS meta-model in Fig. 23 must satisfy ture of CSs of different kinds of clafers. Table 7 in Appen-
Description Constraints dix 5 lists the clafer kind equations. For example, the first row
specifies that the synthetic root clafer has neither source nor
The Clafer Shape (CS) of this Sing
target classes, nor super-type.
Sing has only the class this.source_class =
Sing as head and does this.target_class =
not participate in this.super =
inheritance
4. Naming Discipline Equations specify the Clafer naming
The Clafer Shape (CS) of this Dom economy mechanism: given a clafer C, names of all ele-
Dom is a basic clafer this.source_class = Sing
whose parent is Sing this.target_class = ments in Cs shape are derived from Cs name and can be
this.super = used for navigation over the hierarchy. These constraints are
Basic clafers have a this BasicClafer also necessary for resolving targets of reference clafers and
source_class but no this.source_class
= supertypes. Table 8 in Appendix 5 presents the naming con-
target_class. Analogical this.target_class = straints. For example, the equation from the first row requires
constraints apply to
reference clafers that the head map in a given CS has the same label as the
Top-level clafers, that are this.parent = this
=
head class.
not a synthetic root, are Sing
abstract this.abstract = true
6.2.4 Compilation: from Clafer model to multi-Clafer shape
123
K. Bak et al.
6.3 Formalizing instantiation as a source, and e1 : plaECU2 as a target played twice: once
as a target of e1 and once as a target of e2) and one clone of e2
Figure 20a presents a definition of Clafer instances and (only e2 : plaECU1 as a source, because e2 does not play the
Fig. 20b shows their main featurederivability from the role of a target). Other OD elements are not cloned because
respective CD instances. Whereas the two model-level arti- the mapping label only glues together classes plaECU1 and
facts are formal CDs (DP-graphs), the two instance-level arti- plaECU2 . Mapping label 0 :MC I O D provides trace-
facts are merely graphs (Clafer model instances, like ODs, ability of roles to objects, particularly, it glues together clones
do not carry constraints). All vertical arrows are typing map- into their original objects.
pings that respect the graph structure and satisfy the con- Note that graph MCI is properly typed over graph MCS.
straints (note the symbols | ). The right column of models It also satisfies all multiplicities declared in MCS because
conforms to the standard MOF architecture of instantiation; the mapping label carries these predicates into CD and the
the left column is its counterpart for Clafer. All horizontal instance OD satisfies them.
mappings are also graph morphisms; in addition, the map-
pings label respect constraints (are DP-graphs morphisms).
Chevron Claferize denotes an operation that completes an 7 Analytical evaluation
instance of a CD, i.e., a pair (OD, type) to a Clafer instance
(MCI, type*) (which is traced to the original instance via We examine the extent to which Clafer meets its design goals
the mapping label*). Below we will often refer to instances from Sect. 3.
by their source graphs and say instance OD and instance
MCI. 1. Clafer provides a concise notation for feature modeling.
The operation Claferize recursively traverses an MCS and This can be seen by comparing Clafer to TVL, a state-of-
OD and builds a corresponding MCI. It takes each source the-art textual feature modeling language [15]. Figure 24
class R from MCS, finds its instances O in OD, such that shows the TVL encoding of the feature model from Fig. 7.
label(R) = type(O), and, for each O, creates a source object Conciseness can be measured as the number of elements
role in MCI. It then finds and adds corresponding instances used to encode a model. The Clafer model has slightly
of the mappings head, source, etc. If the mapping target is fewer concepts than the TVL model. Feature models in
instantiated for a given source object O, then it also adds the Clafer look very similar to feature models in TVL, except
target object. After processing the class role R, the operation that TVL uses explicit keywords (e.g., to declare groups),
processes its children (pointed to by the mapping head) one braces for nesting, and feature names must be unique.
by one, for each instance O. Clafers language design reveals several key ingredients
Let us illustrate how the operation Claferize works based allowing a class modeling language to provide a concise
on the example from Fig. 17d. Note that in the class diagram notation for feature modeling:
CD, the class plaECU plays two roles: the source of the
map master and the target of the map dref. The Claferize Concept unification: The concept clafer unifies basic
constructs the MCI in such a way that the diagram commutes, constructs of structural modeling, such as class, asso-
that is, type*.label = label*.type. ciation, and property (which includes attribute, refer-
As we have seen in Sect. 6.1, an instance of a CD can be ence, and role). Such a unification enables arbitrary
seen as a mega-mapping .. : C D SetMap. In the exam- property nesting, which allows us to concisely specify
ple, we have the instance SingOD = {}, plaECUOD = feature models in a class modeling language. Neither
{e1, e2}, master*OD = {m21, m11}, etc. Sequential map- UML nor Alloy provide this mechanism; there, asso-
ping composition label...OD then yields an instance of ciations and classes are declared separately, and prop-
MCS; that is, for any element x of graph MCS, we define erties cannot be arbitrarily nested. Although UML
x=x.labelOD , which gives us a mega-mapping .. :
MC I SetMap. The latter can be represented by a typed
graph (due to the Grothendieck construction discussed at the
end of Sect. 6.1.1), which we denote by MCI. In other words,
we set xMCI = x.labelOD =x.label...OD for all elements
x of graph MCS.
Note that as the mapping label maps two different roles
into one class (plaECU1 mcio = plaECU2 mcio =
{e1, e2}), each object ei , i = 1, 2 may play two roles of
being the source and the target of master links. Hence, in the
carrier graph MCI we have three clones of e1 (e1 : plaECU1 Fig. 24 Options feature model in TVL
123
Clafer: unifying class and feature modeling
offers association classes, they cannot use primitive archy. Both models have the same number of concepts.
domains as association ends. KM3, however, cannot express additional constraints in
Instance composition and type nesting: Clafer nest- the model. They are specified separately, e.g., as OCL
ing accomplishes instance composition and type nest- invariants.
ing in a single construct. UML provides composition, 3. Clafer allows one to concisely mix feature and meta-
but type nesting is specified separately (cf. Fig. 5b). models. Clafer integrates subclassing into hierarchical
Alloy has no built-in support for composition and modeling. Clafers at any nesting level in the contain-
thus requires explicit parentchild constraints. It also ment hierarchy can subclass other clafers. Inheritance
has no signature nesting, so name clashes need to be among clafers is a semantically rich operation. For exam-
avoided using prefixes or alike. ple, inheritance among two reference clafers introduces
Default singleton multiplicity: All clafers that have two classes (head and target), four maps (head, parent,
a parent in the containment hierarchy are singletons dref, and head*), and three inclusions (head s , head h ,
by default. It allows one to specify mandatory fea- and head t ), with all the constraints regulating well-
tures without declaring their multiplicity explicitly formedness of CS and inheritance. Using inheritance, one
in the concrete syntax. In UML and Alloy, on the can reuse feature or class types in multiple locations; ref-
other hand, associations are multi-valued by default. erence clafers allow reusing both types and instances. Fea-
Group constraints: Clafers group constraints are ture and class models can be related via constraints.
expressed concisely as intervals. In UML groups can 4. Clafer tries to use a minimal number of concepts and
be specified in OCL, but using a lengthy encoding, has uniform semantics. While integrating feature model-
explicitly listing features belonging to the group. The ing into meta-modeling, our goal was to avoid creating
same applies to Alloy. a language with duplicate concepts. In Clafer, there is
Constraints with default quantifiers: Default quanti- no distinction between class and feature types; they are
fiers on relations enable writing constraints that look all clafers. Features are relations and, besides their obvi-
like propositional logic, although their underlying ous role in feature modeling, they also play the role of
semantics is FOL. For example, clafer names in the attributes in meta-modeling.
last line in Fig. 7 would be preceded by the quanti- We also contribute a simplification to feature modeling:
fier some (cf. lines 1113 in Fig. 26 in Appendix 3). Clafer has no explicit feature group construct; instead, every
Name resolution rules further contribute to the con- clafer has a group cardinality to constrain the number of chil-
ciseness of constraints. dren. This is a significant simplification; we no longer need to
Navigation over optional clafers: Navigation expres- distinguish between grouping features (features used purely
sions of the form n 1 .n 2 . . . n m encompass navigation for grouping, such as menus) and feature groups. The group-
along the clafer hierarchy and occur in constraints ing intention and grouping cardinalities are orthogonal: Any
(e.g., in the last line of Fig. 8). Each of the names n i clafer can be annotated as a grouping feature, and any clafer
may refer to a clafer of any multiplicity; in particular, may choose to impose grouping constraints on children. This
the clafer n 1 may be optional, whereas n 2 manda- idea has also been adopted in the current draft of CVL [39].
tory. In Clafer and Alloy, all navigation expressions Finally, both feature and class modeling have uniform seman-
uniformly evaluate to a set (either empty or not). In tics. Syntactic and semantic unification in Clafer keeps the
OCL, however, one needs to explicitly check whether language small, allows for uniform representation of models,
navigation over an optional element evaluates to an and also simplifies development of tools for model analyses.
empty set before proceeding to the next element. Further, unification has the potential of simplifying model
Otherwise, the navigation results in an undefined evolution as fewer special cases (concepts) need to be consid-
value indicating an error. Formally, unconditional ered. In general, however, syntactic unification may also have
mapping composition is defined in OCL for only total some drawbacks, such as a lack of correspondence between
mappings, whereas in Clafer and Alloy one can com- the modelers intent and native support for that intent in the
pose partial mappings as well. language, worsened model comprehension, and less efficient
2. Clafer provides a concise notation for meta-modeling. model analyses. On the other hand, one could easily intro-
Figure 25 shows the meta-model of Fig. 8 encoded in duce two subclasses of clafer: class and feature, allowing
KM3 [43], a state-of-the-art textual meta-modeling lan- the user to state an intention explicitly. All the tools, how-
guage. The most visible syntactic difference between ever, could still benefit from the semantic unification by
KM3 and Clafer is the use of explicit keywords intro- looking at instances of features and classes as instances of
ducing elements and mandatory braces establishing hier- clafer.
123
K. Bak et al.
123
Clafer: unifying class and feature modeling
deep instantiation, enabling concise definitions of languages called sketches). Particularly, considering UML class dia-
with class-like instantiation semantics. Clafers purpose is grams as visualizations of formal class diagrams is elabo-
different: to provide a concise notation for combining feature rated in [27,29]. Several applications of DP-graphs to model-
and class models within a single model. Nivel could be used driven software engineering are developed in [59,60].
to define the abstract syntax of Clafer, but it would not be Relating problem-space feature models and solution-
able to naturally support our concise concrete syntax. space models has a long tradition. For example, feature mod-
In essence, Alloy [41] is a class modeling language that els have been used to configure model templates before [18,
reduces OOM to two primitives: signatures (typed sets) and 36]. That work considered model templates as superim-
relations. The former correspond to classes, and the latter posed instances of a meta-model and presence conditions
to associations. Alloy can encode and analyze more concep- attached to individual elements of the instances; however,
tually complex UML class diagrams [1]. In the context of Clafer implements model templates as specializations of a
variability modeling, Alloy has the same shortcomings as meta-model. Such a solution allows us treating the feature
UML class diagrams (cf. Sect. 3). Clafer, on the other hand, model, the meta-model, and the template at the same meta-
was designed to support variability modeling and hierarchi- level, simply as parts of a single Clafer model. This design
cal models. allows us to elegantly reuse a single constraint language at all
As mentioned earlier, class-based meta-modeling lan- these levels and to relate them. As another example, Janota
guages, such as KM3 [43] and MOF [54], cannot express and Botterweck show how to relate feature and architectural
feature models as concisely as Clafer. Furthermore, Clafer models using constraints [42]. Again, our work differs from
covers the same scope as MOF, but is based on fewer con- this work in that our goal is to provide such integration within
cepts, as a clafer represents classes, attributes, and relation- a single language. Such integration is given in Kumbang [7],
ships. which is a language that supports both feature and archi-
Decision models group decisions and focus on product tectural models, related via constraints. Kumbang models
derivation from a product family [20]. Notations for specify- are translated to Weight Constraint Rule Language (WCRL),
ing decision models include a tabular notation [61] and Syn- which has a reasoner supporting model analysis and instanti-
thesis [62]. Clafer models are more expressive, and therefore ation. Kumbang provides a rich domain-specific vocabulary,
subsume decision models (modulo language features con- including features, components, interfaces, and ports; how-
trolling UI aspects such as visibility). In fact, owing to unifi- ever, Clafers goal is a minimal uniform language covering
cation, Clafer can encode variability, class, and meta-models. both feature and class modeling, and serving as a platform
A rigorous approach to unification of different types of to derive such domain-specific languages, as needed.
associations based on mathematical operations with map-
pings, particularly, tabulation, was proposed in [29]. Clafer
develops this idea further by introducing: (1) inheritance 9 Conclusion
among clafers, (2) the ability to arbitrarily nest properties,
(3) a naming discipline that compacts syntax, and (4) the Clafer closes the gap between feature and class models and
notion of multi-clafer shape and the corresponding hierar- provides improvements on both sides. We showed how the
chical view on Class Diagrams. essential modeling concepts can be unified both syntactically
Formalization and unification of different views on rela- and semantically, which allows for arbitrary property nest-
tionships and properties have been done in conceptual mod- ing and uniform representation of feature and class models.
eling, e.g., [25,65]. In contrast to our work, they typically Clafer subsumes cardinality-based feature modeling with ref-
focus on complex semantic aspects rather than seemingly erences. We are not aware of other works that precisely define
simple tabular and navigational aspects, and use first-order semantics of such models. We provided semantics in a struc-
rather than diagrammatic logic and algebra. turally explicit way, as MCSs resemble models in concrete
Refactoring of UML class diagrams is a practical activ- syntax. Furthermore, the work on formal semantics gave us
ity performed during model evolution [8,64]. We acknowl- new insights and helped to fix the language (e.g., clarified
edge the importance of refactorings, but our idea with Clafer the meaning of reference clafers and navigation through the
is more radical: We conjecture that unification of modeling clafer hierarchy).
concepts reduces the number of required model refactorings. Our work contributes to the design of modeling notations
Formalization of conceptual modeling constructs within a and model analyses. Clafer can encode rich structural models,
framework based on diagram predicates and operations over e.g., domain models, variability models, class models. Uni-
sets and mappings was proposed in [28,30]. The subsequent fied syntax and semantics allow using a common infrastruc-
idea to interpret various diagrammatic notation used in struc- ture for reasoning on a large variety of models. We have
tural modeling as different visualizations of the same format implemented reasoning support based on Alloy, Z3 SMT,
of DP-graphs is developed in [31] (where DP-graphs are and Choco 3 CSP solvers.
123
K. Bak et al.
Our work intends to help modelers express and analyze A set-valued mapping is containment if its inverse is total
complex Software Product Lines. We have previously shown and single-valued.
that a wide range of realistic feature models, meta-models,
and model templates can be expressed in Clafer and that Shapes and fonts
useful analyses can be run on them within seconds [13].
The recent thesis demonstrates using Clafer for modeling We use the following terminology and conventions to
the three levels of EAST-ADL architecture on an example formally specify models and meta-models. Boxes (called
of complex automotive electronic/electric architecture and classes) represent sets, boxes with rounded edges represent
reasoning over such an integrated model [51]. primitive domains (e.g., Integer), arrows (called maps) rep-
This work has also implications for programming lan- resent mappings between sets. Names of classes in models
guage design. Current OO programming languages suffer are written in Serif font, whereas names of classes in meta-
from the same problems as UML class diagrams. The need models are written in Small Capital font. Names of maps
for arbitrary object nesting (declaring containment and the are in italic font. If a class or map name is predefined then it
type of contained object) has been recognized in, for exam- is underlined. Diagram predicates are [red and enclosed
ple, JavaScript Object Notation (JSON) and protocol buffers. in brackets]. For multiplicities, we skip the braces and write
In the future, we would like to carry out empirical studies numbers (e.g., 1), or number ranges (e.g., 1..1). Derived ele-
to explore the benefits and disadvantages of concept unifi- ments are shown as blue and blank.
cation in practical modeling. Other promising directions for
future work include adding support for: (1) domain-specific
abstractions in Clafer, (2) modularity to provide visibility and Appendix 2: Semantics and syntax of DP-graphs
variability interfaces, and (3) behavioral modeling to express (formal CDs)
the evolution of state specified by Clafer models over time.
In the OO-modeling view, the world consists of objects and
Finally, we would like to adapt Clafer and the tools to bet-
links between them. We typically collect objects into sets,
ter support architecture modeling, design exploration, and
and links into mappings between these sets. Taken together,
multi-objective optimization, e.g., to find optimal function-
objects, links, sets, and mappings, constitute a huge uni-
to-hardware deployment and topology generation.
verse denoted by SetMap. A particular OO model (class
diagram) specifies a small fragment of the universe; usu-
Appendix 1: Notation and terminology ally, describing a diagram of sets and mappings involved
in the fragment, and properties they must satisfy. Here, we
Mappings outline the basics of a mathematical framework, in which
such OO modeling can be formally specified. We first con-
By a mapping f from a source set A to a target set B, we
sider semantics, i.e., the universe SetMap as such, in sec-
understand a function that sends each element of A to a col-
tions Semantic universe: mappingsSemantic universe:
lection (perhaps, empty) f (a) of elements of B. We say that
configurations of mappings and their properties, and then
f is multi-valued. The most general collection we consider
proceed with syntactical means for specifying fragments of
is a bag (or a family, or an indexed set) of elementsprecise
SetMap (section Syntax: DP-graphs). We assume that the
definitions are in section Semantic universe: mappings. We
basic notions of naive set theory (set, subset, an ordered pair
call a mapping set-valued, if all bags f (a) are actually sets
etc., and (single-valued) function, injection, bijection, etc.)
(UML then annotates the mapping with marker unique).
are known.
A set-valued mapping is single-valued, if all non-empty sets
f (a) are singletons.
Semantic universe: mappings
A mapping is total if all bags f (a) are not empty; other-
wise it is strictly partial. An underspecified mapping, which We give two definitions: relational (a mapping is a span of
may be total but not necessarily, is called partial. Thus, total- functions), and navigational or functional (a mapping is a
ity and strict partiality are constraints that a general (partial) multi-valued function as in section Mappings). Then, we
mapping may satisfy. Following a common practice, we often show that both essentially define the same construct called a
say partial instead of strictly partial. Note that according to mapping.
the definition above, a single-valued mapping can be partial.
A set-valued mapping is inclusion if its source is a sub- Multi-relations or Spans
set of the target, A B, and for all A A, f (a) = a
(but a on the right of equality is considered as an element Let A and B be sets. By a mapping from A to B, we can
of B). An inclusion of A into itself is the identity map- understand a set of labeled links, i.e., triples (a, b, ) with
ping id A : A A. a A, b B, and L a label taken from some predefined
123
Clafer: unifying class and feature modeling
set L of link IDs, so that multiple links between the same a x : I X , for which we prefer to write xi for the value
and b are possible. The following definition makes the idea x(i), i I . Correspondingly, the graph of function x, i.e.,
precise. the set {(i, xi )| i I } is denoted by expression {{xi | i I }},
where double brackets indicate that repetitions (say, xi = x j
Definition 1 (span) A multi-relation or a span, r : A B, is
for i
= j) are possible. In the UML parlance, such double-
a triple (L r , sr , tr ) with L r a set, and sr , tr two totally defined
bracketed expressions are often called bags, and we also use
single-valued functions from L r as shown in the following
this term. However, formally, a bag is a family, i.e., the graph
diagram:
of the indexing function of the family.
(span)
sr
A L r B.
tr The set of all bags of X s elements is denoted Bag(X ).
Set L r is the head, functions sr , tr are the source and target Note that an ordinary subset A of X can be seen as a bag
legs, and sets A, B are the source and target feet of the span. {{aa | a A}} = {(a, a)| a A}, which is the graph of
We will denote the set of all spans from A to B by inclusion A into X . Thus, the powerset of X , Set(X ), is
Span(A, B). included into Bag(X ).
Any bag/family x Bag(X ) can be compressed to its
To ease reading formulas, we will align them with the geom- carrier set by eliminating repetitions, i.e., by taking the
etry of diagram (span) and write a = sr . to denote appli- image {xi | i I } of the indexing function. We denote
cation of function sr to L r , which results in a A, and the resulting set by x! X . We thus have a function
similarly .tr = b denotes tr applied to with result b B. ! X : Bag(X ) Set(X ); the subindex will be omitted if
The triple (a, , b) is then called an r-link from a to b. it is clear from the context.
It is easy to see that a span r : A B gives rise to a
total single-valued function r : L r A B (even if r is Definition 4 A multi-valued (mv) function, f : A B,
strictly partial), and conversely, any such function gives us is a single-valued total function f : A Bag(X ). Given
a span with sr = r . p and tr = r .q where p : A A B a A, we will denote the indexing function of family f (a)
and q : A B B are projection functions (Totality of r as f a : I af B.
is equivalent to left-surjectivity of r , i.e., surjectivity of sr .).
Any relation r A B is a span, whose head is r and legs By composing f with ! X , we obtain the set-valued reduct of
are projections restricted to r . Hence, the set of all relations f , function f ! : A Set(X ).
Rel(A, B) is included into Span(A, B). Like for span isomorphism, what matters is the number of
A span r Span(A, B) can be seen as a multi-relation, indices rather than their IDs.
i.e., a relation with possible repetitive pairs of elements Definition 5 Two mv-functions f 1, f 2 : A B are con-
(links). We can eliminate repetitive links by considering the
def
sidered isomorphic, f 1
= f 2, if for each a A, there is a
image of L r , i.e., set L r ! = r (L r ) A B, which consists bijection between the indexing sets a : I af 1 I af 2 commut-
of pairs of elements, i.e., is a binary relation. It gives rise to ing with the indexing functions f i a , that is, a . f 2a = f 1a .
a reduct span r !, whose head is L r !, and legs are restrictions
of projections p, q above to set L r !. Thus, we have a func-
Spans and functions together: mappings
tion ! A,B : Span(A, B) Rel(A, B); the subindex will be
omitted if it is clear from the context.
Given a span r : A B, we can build a multi-valued function
We will also need the notion of span isomorphism, in
r : A B by defining for a given a A,
which the number of links matters, not their IDs.
(1) the index set Ira = sr1 (a) L r , and
Definition 2 Two spans r 1, r 2 : A B are considered iso- (2) for a link Ira considered as an index, r a () = .tr
morphic, r 1
= r 2, iff there is a bijection between their heads (see Def.4 for the notation used).
commuting with legs. In a slightly different notation,
123
K. Bak et al.
(Sequential) Mapping composition Table 3 presents several important properties of mapping con-
figurations, which we call diagram predicates. The left col-
For set-valued mappings, f : A B, g : B C, their umn gives their names, the middle one specifies their arities,
composition is an ordinary functional composition: for any i.e., configurations of mappings that may have the property,
a A, a. f.g = (a. f ).g, where for a set X B, X.g =
def and the right column provides semantics.
xX x.g.
For the general case of bag-valued mappings, it is much Syntax: DP-graphs
easier to define composition for the span representation.
Given two consecutive spans q : A B, r : B C, An OO model specifies a fragment of the universe by describ-
their composition q.r : A C is defined as follows. The ing a diagram of sets and mappings involved in the fragment,
head and properties they must satisfy; that is, a model appears as a
graph with diagram predicate declarations (a DP-graph) that
L q.r = {(, ) L q L r : 1 .tq = sr .2 },
def
describe properties. Formal CDs used in the paper are DP-
123
Clafer: unifying class and feature modeling
graphs, whose nodes are called classes, arrows are maps (= args. f : G ar (P) G 2 is a graph morphism. Then, we
unidirectional associations), and predicate declarations are require that all translated formulas were declared in 2 :
constraints imposed on classes and maps. Hence, semantics f () 2 for all 1 .
of a formal CDs is given by interpreting its classes as sets,
and maps as mappings such that the constraints are satisfied. Syntax and semantics together
Here, we specify syntax and semantics of DP-graphs/formal
CDs formally. A major idea of categorical logic [10] is to treat semantic
universes syntactically, that is, in our case, as DP-graphs.
Graphs Indeed, the universe SetMap can be seen as a huge (cate-
goricians would say big) DP-graph: Its nodes are sets, arrows
Definition 6 (Graphs and their morphisms.) A (directed are mappings, and formulas are true statements about sets and
multi)graph G consists of a set of nodes G N , a set of arrows mappings. For example, if A and B are sets (nodes in graph
G A , and two total single-valued functions sr c, trg: G A [SetMap]), and f , g are mappings between them (i.e.,
G N giving each arrow its source and target. arrows in [SetMap]) going in the opposite direction, then,
A graph morphism (mapping) f : G 1 G 2 is a pair of if mappings f and g are mutually inverse, i.e., ( f, g) | [inv],
functions f N : G 1N G 2N and f A : G 1A G 2 A such that then we add formula [inv]( f, g) to set [SetMap]. Thus, the
the incidence of nodes and arrows is preserved: for any arrow big set of formulas [SetMap] consists of all valid state-
a G1 A , sr c( f A (a)) = f N (sr c(a)) and trg( f A (a)) = ments about all possible configurations of sets and mappings
f N (trg(a)). matching predicate arities. Then, an instance of a DP-graph
S can be seen as a DP-graph morphism .. : S SetMap.
DP-graphs An immediate consequence of such an arrangement is the
following result:
Definition 7 (Signature.) A (diagram predicate) signature
Theorem 3 Any DP-graph morphism f : S1 S2 gives
is a set of predicate symbols together with assignment to
rise to a function between the respective sets of instances,
each label P its arity shapea graph G ar (P).
f : S1 S2 , where Si denotes the (big) set of all
Definition 8 ((Diagram) formulas) Given a diagram predi- instances of DP-graph Si .
cate signature and a graph G, a (diagram) formula over
Proof As a correct instance of S2 is a correct graph mor-
G is a pair (P, args) with P a predicate symbol, and
phism, .. : S2 SetMap, its composition with f gives us
args : G ar (P) G a graph morphism binding formal para-
a correct instance of S1 .
meters in the arity graph by the actual argumentselements
of graph G. Assume the arity graph G ar (P) has a finite set
of arrows 1 . . . n and does not have isolated nodes. Then, a Appendix 3: Clafer concrete syntax
formula can be encoded by an expression P(a1 . . . an ) where
ai = args(i ), i = 1 . . . n. In other words, a formula is a Conciseness is an important goal for Clafer; therefore, it pro-
pair (P, a) with P a predicate symbol and a a bag of arrows vides syntactic sugar for common constructions. Figure 26
of the carrier graph, whose indexing set is the arity graph shows the model from Fig. 7 in a desugared notation, in which
G ar (P) (note that the indexing function must be a correct the defaults (e.g., multiplicities) are inserted into clafer dec-
graph morphismthis constraint was called [ad], arity disci- larations. Each declaration starts with group cardinality, fol-
pline, in section Meta-model.
123
K. Bak et al.
123
Clafer: unifying class and feature modeling
Universal quantification. In the rule below, the environment Environment maps variables to values, which are either sets
env is extended by specifying that the type of var is SetExp. of objects or links. Note that a single object would be repre-
env, var :: SetExp Exp :: Boolean sented as a singleton set.
A constraint is a Boolean-valued expression. The seman-
env all var : SetExp | Exp :: Boolean
tics uses two interpretation functions:
Conjunction.
env Exp1 :: Boolean env Exp2 :: Boolean E : Exp Env Boolean P(Object)
S : SetExp Env Value
env Exp1 && Exp2 :: Boolean The former function interprets abstract syntax elements
env Exp :: Boolean of expressions for a given environment and evaluates to a
Negation.
env !Exp :: Boolean Boolean value or a set of objects. A set of objects is always
Comparison. a singleton. In particular, values of primitive domains (e.g.,
env Exp1 :: env Exp2 :: integer) are encoded as singletons. Analogically, the latter
,
env Exp1 Exp2 :: Boolean function interprets set expressions, which are either sets of
where {<, =}. objects or links.
123
K. Bak et al.
123
Clafer: unifying class and feature modeling
References 20. Czarnecki, K., Grenbacher, P., Rabiser, R., Schmid, K.,
Wasowski, A.: Cool features and tough decisions: a comparison of
1. Anastasakis, K., Bordbar, B., Georg, G., Ray, I.: UML2Alloy: a variability modeling approaches. In: Proceedings of the Sixth Inter-
challenging model transformation. Model Driven Eng. Lang. Syst. national Workshop on Variability Modeling of Software-Intensive
(2007) Systems (2012)
2. Antkiewicz, M., Bak, K., Zayan, D., Czarnecki, K., Wasowski, 21. Czarnecki, K., Helsen, S., Eisenecker, U.: Formalizing cardinality-
A., Diskin, Z.: Example-driven modeling using clafer. In: First based feature models and their specialization. Softw. Process
International Workshop on Model-Driven Engineering By Exam- Improv. Pract. 10(1), 331348 (2005)
ple (2013). http://ceur-ws.org/Vol-1104 22. Czarnecki, K., Hwan, C., Kim, P., Kalleberg, K.: Feature models
3. Antkiewicz, M., Bak, K., Murashkin, A., Liang, J., Olaechea, R., are views on ontologies. Software Product Line Conference, 10th
Czarnecki, K.: Clafer tools for product line engineering. In: Pro- International (2006)
ceedings of the 17th International Software Product Line Confer- 23. Czarnecki, K., Kim, C.H.: Cardinality-based feature modeling and
ence Co-located Workshops (2013) constraints: a progress report. In: International Workshop on Soft-
4. Antkiewicz, M., Czarnecki, K., Stephan, M.: Engineering of ware Factories (2005)
framework-specific modeling languages. Softw. Eng. IEEE Trans. 24. Czarnecki, K., Pietroszek, K.: Verifying feature-based model tem-
35(6), 521549 (2009) plates against well-formedness ocl constraints. In: Proceedings of
5. Asikainen, T., Mnnist, T.: Nivel: a metamodelling language with the 5th International Conference on Generative Programming and
a formal semantics. Softw. Syst. Model. 8(4), 3140 (2009) Component Engineering (2006)
6. Asikainen, T., Mnnist, T., Soininen, T.: A unified conceptual 25. Dahchour, M., Pirotte, A., Zimnyi, E.: Generic relationships in
foundation for feature modelling. In: Software Product Line Con- information modeling. J. Data Semant. IV 3730, 134 (2005)
ference, 10th International (2006) 26. De Moura, L., Bjrner, N.: Z3: An efficient SMT solver. In: Tools
7. Asikainen, T., Mnnist, T., Soininen, T.: Kumbang: A domain and Algorithms for the Construction and Analysis of Systems, pp.
ontology for modelling variability in software product families. 337340 (2008)
Adv. Eng. Inform. 21(1), 2340 (2007) 27. Diskin, Z.: Visualization vs. specification in diagrammatic nota-
8. Astels, D.: Refactoring with UML. In: Proceedings of the 3rd Inter- tions: A case study with the UML. In: Hegarty, M., Meyer, B., Hari
national Conference Extreme Programming and Flexible Processes Narayanan, N. (eds.) Diagrams 2002, LNAI 2317, pp. 112115.
in Software Engineering (2002) Springer, Heidelberg (2002)
9. Bak, K., Zayan, D., Czarnecki, K., Antkiewicz, M., Diskin, Z., 28. Diskin, Z., Cadish, B.: Variable sets and functions framework for
Wasowski, A., Rayside, D.: Example-driven modeling: model = conceptual modeling: integrating ER and OO via sketches with
abstractions + examples. In: New Ideas and Emerging Results dynamic markers. In: Object-Oriented and Entity-Relationship
(NIER) Track of the 35th International Conference on Software Modeling (1995)
Engineering (2013) 29. Diskin, Z., Easterbrook, S., Dingel, J.: Engineering Associations:
10. Barr, M., Wells, C.: Category Theory for Computing Science, From Models to Code and Back through Semantics. In: Objects,
vol. 10. Prentice Hall, New York (1990) Components, Models and Patterns (2008)
11. Berger, T., Rublack, R., Nair, D., Atlee, J.M., Becker, M., Czar- 30. Diskin, Z., Kadish, B.: Variable set semantics for keyed generalized
necki, K., Wasowski, A.: A survey of variability modeling in sketches: formal semantics for object identity and abstract syntax
industrial practice. In: Proceedings of the Seventh International for conceptual modeling. Data Knowl Eng 47, 159 (2003)
Workshop on Variability Modelling of Software-Intensive Systems 31. Diskin, Z., Kadish, B., Piessens, F., Johnson, M.: Universal arrow
(2013) foundations for visual modeling. In: Anderson, M., Cheng, P.,
12. Berger, T., She, S., Lotufo, R., Wasowski, A., Czarnecki, K.: Vari- Haarslev, V. (eds.) Diagrams 2000, LNAI 1889, pp. 345360.
ability modeling in the real: a perspective from the operating sys- Springer, Heidelberg (2000)
tems domain. In: Proceedings of the IEEE/ACM International Con- 32. Felfernig, A., Friedrich, G.E., Jannach, D.: UML as domain specific
ference on Automated Software Engineering (2010) language for the construction of knowledge-based configuration
13. Bak, K., Czarnecki, K., Wasowski, A.: Feature and meta-models systems. Int. J. Softw. Eng. Knowl. Eng. 10(04), 449469 (2000)
in Clafer: mixed, specialized, and coupled. In: Malloy, B., Staab, 33. Gaeta, J.A.P.: Modeling and implementing variability in aerospace
S., van den Brand, M. (eds.) SLE 2010, LNCS 6563, pp. 102122. systems product lines. Masters thesis, University of Waterloo
Springer, Heidelberg (2010) (2014)
14. Bak, K., Diskin, Z., Antkiewicz, M., Czarnecki, K., Wasowski, A.: 34. Gomaa, H.: Designing Software Product Lines with UML.
Partial instances via subclassing. Softw. Lang. Eng. (2013) Addison-Wesley, Boston (2004)
15. Classen, A., Boucher, Q., Heymans, P.: A text-based approach to 35. Group, O.M.: Systems Modeling Language (SysML) (2012).
feature modelling: Syntax and semantics of TVL. Sci. Comp. Pro- http://www.omg.org/spec/SysML/1.3/
gram. 76(12), 11301143 (2011) 36. Heidenreich, F., Kopcsek, J., Wende, C.: FeatureMapper: mapping
16. Clau, M., Jena, I.: Modeling variability with UML. In: Young features to models. In: Companion of the 30th International Con-
Researchers Workshop at GCSE (2001) ference on Software Engineering (2008)
17. Consortium, A., et al.: EAST-ADL domain model specification, 37. Hubaux, A., Boucher, Q., Hartmann, H., Michel, R., Heymans, P.:
Nov. 28, 2013. Version 2.1.12 Evaluating a textual feature modelling language: four industrial
18. Czarnecki, K., Antkiewicz, M.: Mapping features to models: a tem- case studies. Softw. Lang. Eng. (2010)
plate approach based on superimposed variants. In: Gluck, R., 38. Hubaux, A., Xiong, Y., Czarnecki, K.: A user survey of con-
Lowrt, M. (eds.) GPCE 2005, LNCS, vol. 3676, pp. 422437. figuration challenges in Linux and eCos. In: Proceedings of the
Springer, Heidelberg (2005) Sixth International Workshop on Variability Modeling of Software-
19. Czarnecki, K., Bednasch, T., Unger, P., Eisenecker, U.: Gener- Intensive Systems (2012)
ative programming for embedded software: an industrial expe- 39. IBM, Thales, Fokus, F., TCS: Proposal for Common Variabil-
rience report. In: Batory, D., Consel, C., Taha, W. (eds.) ity Language (CVL) (2012, revised submission). http://www.
GPCE 2002, LNCS 2487, pp. 156172. Springer. Heidelberg omgwiki.org/variability/doku.php
(2002)
123
K. Bak et al.
40. Jackson, D.: Alloy: a lightweight object modelling notation. ACM 62. Software Productivity Consortium Services Corporation: Reuse-
Trans. Softw. Eng. Methodol. 11(2), 256290 (2002) Driven Software Processes Guidebook, version 02.00.03. Techni-
41. Jackson, D.: Software Abstractions: Logic, Language, and Analy- cal Report SPC-92019-CMC (1993)
sis. The MIT Press, Cambridge (2011) 63. Stephan, M., Antkiewicz, M.: Ecore.fmp: A tool for editing and
42. Janota, M., Botterweck, G.: Formal approach to integrating feature instantiating class models as feature models. Technical Report
and architecture models. Fundam. Approach. Softw. Eng. 3145 2008-08, University of Waterloo (2008)
(2008) 64. Suny, G., Pollet, D., Traon, Y.L., Jzquel, J.M.: Refactoring UML
43. Jouault, F., Bzivin, J.: KM3: a DSL for metamodel specification. models. In: UMLThe Unified Modeling Language. Modeling
In: Formal Methods for Open Object-Based Distributed Systems, Languages, Concepts, and Tools, pp. 134148 (2001)
pp. 171185 (2006) 65. Wand, Y., Storey, V., Weber, R.: An ontological analysis of the rela-
44. Jussien, N., Rochart, G., Lorca, X., et al.: Choco: an open source tionship construct in conceptual modeling. ACM Trans. Database
java constraint programming library. In: CPAIOR08 Workshop Syst. 24(4), 494528 (1999)
on Open-Source Software for Integer and Contraint Programming
(OSSICP08) (2008)
45. Kang, K., Cohen, S., Hess, J., Nowak, W., Peterson, S.: Feature-
oriented domain analysis (FODA) feasibility study. Technical
Report CMU/SEI-90-TR-21, CMU (1990)
46. Kang, K.C.: FODA: Twenty years of perspective on feature mod-
eling. In: Proceedings of the Fourth International Workshop on Kacper Bak is a Senior Soft-
Variability Modelling of Software-Intensive Systems (2010) ware Engineer at MathWorks. He
47. Lambek, J., Scott, P.J.: Introduction to Higher-Order Categorical is interested in bringing software
Logic, vol. 7. Cambridge University Press, Cambridge (1988) research, model-based software
48. Liang, J.: Correcting Clafer Models with Automated Analysis. development, and functional pro-
Technical Report GSDLab-TR 2012-04-30, GSD Lab, University gramming into practice. Cur-
of Waterloo (2012) rently, he develops a meta-
49. Liang, J.: Solving Clafer models with Choco (GSDLab-TR 2012- modeling infrastructure and dia-
12-30) (2012) gram editors for MATLAB and
50. Michel, R., Classen, A., Hubaux, A., Boucher, Q.: A formal seman- Simulink. Before joining the
tics for feature cardinalities in feature diagrams. In: Proceedings of industry, he received a PhD
the 5th Workshop on Variability Modeling of Software-Intensive degree at the University of Water-
Systems (2011) loo (2013). For his thesis, he
51. Murashkin, A.: Automotive electronic/electric architecture mod- designed and developed Clafer,
eling, design exploration and optimization using Clafer. Masters a language for modeling and
thesis, University of Waterloo (2014) analyses of software product line variability. He also contributed to
52. Murashkin, A., Antkiewicz, M., Rayside, D., Czarnecki, K.: Visu- the specification of the OMG Common Variability Language standard
alization and exploration of optimal variants in product line engi- proposal and worked on example-driven modeling, an approach that
neering. In: Proceedings of the 17th International Software Product systematically uses explicit examples for eliciting, modeling, verify-
Line Conference (2013) ing, and validating complex business knowledge.
53. Olaechea, R., Stewart, S., Czarnecki, K., Rayside, D.: Modeling
and multi-objective optimization of quality attributes in variability-
rich software. In: Proceedings of the Fourth International Workshop Zinovy Diskin is Senior Research
on Nonfunctional System Properties in Domain Specific Modeling Scientist with NECSIS (Network
Languages (2012) for the Engineering of Complex
54. OMG: Meta Object Facility (MOF) Core Specification (2011) Software Intensive Systems), a
55. OMG: OMG Object Constraint Language (OCL) 2.4 (2014) joint collaboration between GM,
56. Partnership, A.D.: Automotive open system architecture (autosar), IBM, Malina Software, and eight
release 4.1 (2013). http://www.autosar.org/specifications/release- universities in Canada. He is
41/ also cross-appointed as Research
57. Partnership, A.D.: Feature model exchange format (2013). Associate with the University of
https://www.autosar.org/fileadmin/files/releases/4-1/methodolog Waterloo. His area of expertise is
y-templates/templates/standard/AUTOSAR_TPS_FeatureModel algebraic models for constructs
ExchangeFormat.pdf and concepts used in MDE, par-
58. Reiser, M.O., Kolagari, R.T., Weber, M.: Unified feature modeling ticularly meta-modeling, multi-
as a basis for managing complex system families. In: Proceedings modeling and model manage-
of the First International Workshop on Variability Modelling of ment. He worked as a mechanical
Software-Intensive Systems (2007) engineer and database designer
59. Rossini, A., Rutle, A., Lamo, Y., Wolter, U.: A formalisation of the in Latvia, business analyst and consultant in the USA, and a researcher
copy-modify-merge approach to version control in MDE. J. Log. and mentor in Canada.
Algebr. Program. 79(7), 636658 (2010)
60. Rutle, A., Rossini, A., Lamo, Y., Wolter, U.: A formal approach to
the specification and transformation of constraints in MDE. J. Log.
Algebr. Program. 81(4), 422457 (2012)
61. Schmid, K., John, I.: A customizable approach to full lifecycle vari-
ability management. Sci. Comput. Program. 53, 259284 (2004)
123
Clafer: unifying class and feature modeling
123