Skip to main content
Log in

Clafer: unifying class and feature modeling

  • Regular Paper
  • Published:
Software & Systems Modeling Aims and scope Submit manuscript

Abstract

We present Clafer (class, feature, reference), a class modeling language with first-class support for feature modeling. We designed Clafer as a concise notation for meta-models, feature models, mixtures of meta- and feature models (such as components with options), and models that couple feature models and meta-models via constraints (such as mapping feature configurations to component configurations or model templates). Clafer allows arranging models into multiple specialization and extension layers via constraints and inheritance. We identify several key mechanisms allowing a meta-modeling language to express feature models concisely. Clafer unifies basic modeling constructs, such as class, association, and property, into a single construct, called clafer. We provide the language with a formal semantics built in a structurally explicit way. The resulting semantics explains the meaning of hierarchical models whereby properties can be arbitrarily nested in the presence of inheritance and feature modeling constructs. The semantics also enables building consistent automated reasoning support for the language: To date, we implemented three reasoners for Clafer based on Alloy, Z3 SMT, and Choco3 CSP solvers. We show that Clafer meets its design objectives using examples and by comparing to other languages.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13
Fig. 14
Fig. 15
Fig. 16
Fig. 17
Fig. 18
Fig. 19
Fig. 20
Fig. 21
Fig. 22
Fig. 23
Fig. 24
Fig. 25
Fig. 26

Similar content being viewed by others

References

  1. Anastasakis, K., Bordbar, B., Georg, G., Ray, I.: UML2Alloy: a challenging model transformation. Model Driven Eng. Lang. Syst. (2007)

  2. Antkiewicz, M., Bąk, K., Zayan, D., Czarnecki, K., Wąsowski, A., Diskin, Z.: Example-driven modeling using clafer. In: First International Workshop on Model-Driven Engineering By Example (2013). http://ceur-ws.org/Vol-1104

  3. Antkiewicz, M., Bąk, K., Murashkin, A., Liang, J., Olaechea, R., Czarnecki, K.: Clafer tools for product line engineering. In: Proceedings of the 17th International Software Product Line Conference Co-located Workshops (2013)

  4. Antkiewicz, M., Czarnecki, K., Stephan, M.: Engineering of framework-specific modeling languages. Softw. Eng. IEEE Trans. 35(6), 521–549 (2009)

  5. Asikainen, T., Männistö, T.: Nivel: a metamodelling language with a formal semantics. Softw. Syst. Model. 8(4), 31–40 (2009)

  6. Asikainen, T., Männistö, T., Soininen, T.: A unified conceptual foundation for feature modelling. In: Software Product Line Conference, 10th International (2006)

  7. Asikainen, T., Männistö, T., Soininen, T.: Kumbang: A domain ontology for modelling variability in software product families. Adv. Eng. Inform. 21(1), 23–40 (2007)

  8. Astels, D.: Refactoring with UML. In: Proceedings of the 3rd International Conference Extreme Programming and Flexible Processes in Software Engineering (2002)

  9. Bąk, K., Zayan, D., Czarnecki, K., Antkiewicz, M., Diskin, Z., Wąsowski, A., Rayside, D.: Example-driven modeling: model = abstractions + examples. In: New Ideas and Emerging Results (NIER) Track of the 35th International Conference on Software Engineering (2013)

  10. Barr, M., Wells, C.: Category Theory for Computing Science, vol. 10. Prentice Hall, New York (1990)

  11. Berger, T., Rublack, R., Nair, D., Atlee, J.M., Becker, M., Czarnecki, K., Wąsowski, A.: A survey of variability modeling in industrial practice. In: Proceedings of the Seventh International Workshop on Variability Modelling of Software-Intensive Systems (2013)

  12. Berger, T., She, S., Lotufo, R., Wąsowski, A., Czarnecki, K.: Variability modeling in the real: a perspective from the operating systems domain. In: Proceedings of the IEEE/ACM International Conference on Automated Software Engineering (2010)

  13. Bąk, K., Czarnecki, K., Wąsowski, A.: Feature and meta-models in Clafer: mixed, specialized, and coupled. In: Malloy, B., Staab, S., van den Brand, M. (eds.) SLE 2010, LNCS 6563, pp. 102–122. Springer, Heidelberg (2010)

  14. Bąk, K., Diskin, Z., Antkiewicz, M., Czarnecki, K., Wąsowski, A.: Partial instances via subclassing. Softw. Lang. Eng. (2013)

  15. Classen, A., Boucher, Q., Heymans, P.: A text-based approach to feature modelling: Syntax and semantics of TVL. Sci. Comp. Program. 76(12), 1130–1143 (2011)

  16. Clauß, M., Jena, I.: Modeling variability with UML. In: Young Researchers Workshop at GCSE (2001)

  17. Consortium, A., et al.: EAST-ADL domain model specification, Nov. 28, 2013. Version 2.1.12

  18. Czarnecki, K., Antkiewicz, M.: Mapping features to models: a template approach based on superimposed variants. In: Gluck, R., Lowrt, M. (eds.) GPCE 2005, LNCS, vol. 3676, pp. 422–437. Springer, Heidelberg (2005)

  19. Czarnecki, K., Bednasch, T., Unger, P., Eisenecker, U.: Generative programming for embedded software: an industrial experience report. In: Batory, D., Consel, C., Taha, W. (eds.) GPCE 2002, LNCS 2487, pp. 156–172. Springer. Heidelberg (2002)

  20. Czarnecki, K., Grüenbacher, P., Rabiser, R., Schmid, K., Wąsowski, A.: Cool features and tough decisions: a comparison of variability modeling approaches. In: Proceedings of the Sixth International Workshop on Variability Modeling of Software-Intensive Systems (2012)

  21. Czarnecki, K., Helsen, S., Eisenecker, U.: Formalizing cardinality-based feature models and their specialization. Softw. Process Improv. Pract. 10(1), 331–348 (2005)

  22. Czarnecki, K., Hwan, C., Kim, P., Kalleberg, K.: Feature models are views on ontologies. Software Product Line Conference, 10th International (2006)

  23. Czarnecki, K., Kim, C.H.: Cardinality-based feature modeling and constraints: a progress report. In: International Workshop on Software Factories (2005)

  24. Czarnecki, K., Pietroszek, K.: Verifying feature-based model templates against well-formedness ocl constraints. In: Proceedings of the 5th International Conference on Generative Programming and Component Engineering (2006)

  25. Dahchour, M., Pirotte, A., Zimányi, E.: Generic relationships in information modeling. J. Data Semant. IV 3730, 1–34 (2005)

  26. De Moura, L., Bjørner, N.: Z3: An efficient SMT solver. In: Tools and Algorithms for the Construction and Analysis of Systems, pp. 337–340 (2008)

  27. Diskin, Z.: Visualization vs. specification in diagrammatic notations: A case study with the UML. In: Hegarty, M., Meyer, B., Hari Narayanan, N. (eds.) Diagrams 2002, LNAI 2317, pp. 112–115. Springer, Heidelberg (2002)

  28. Diskin, Z., Cadish, B.: Variable sets and functions framework for conceptual modeling: integrating ER and OO via sketches with dynamic markers. In: Object-Oriented and Entity-Relationship Modeling (1995)

  29. Diskin, Z., Easterbrook, S., Dingel, J.: Engineering Associations: From Models to Code and Back through Semantics. In: Objects, Components, Models and Patterns (2008)

  30. Diskin, Z., Kadish, B.: Variable set semantics for keyed generalized sketches: formal semantics for object identity and abstract syntax for conceptual modeling. Data Knowl Eng 47, 1–59 (2003)

  31. Diskin, Z., Kadish, B., Piessens, F., Johnson, M.: Universal arrow foundations for visual modeling. In: Anderson, M., Cheng, P., Haarslev, V. (eds.) Diagrams 2000, LNAI 1889, pp. 345–360. Springer, Heidelberg (2000)

  32. Felfernig, A., Friedrich, G.E., Jannach, D.: UML as domain specific language for the construction of knowledge-based configuration systems. Int. J. Softw. Eng. Knowl. Eng. 10(04), 449–469 (2000)

  33. Gaeta, J.A.P.: Modeling and implementing variability in aerospace systems product lines. Master’s thesis, University of Waterloo (2014)

  34. Gomaa, H.: Designing Software Product Lines with UML. Addison-Wesley, Boston (2004)

    Google Scholar 

  35. Group, O.M.: Systems Modeling Language (SysML) (2012). http://www.omg.org/spec/SysML/1.3/

  36. Heidenreich, F., Kopcsek, J., Wende, C.: FeatureMapper: mapping features to models. In: Companion of the 30th International Conference on Software Engineering (2008)

  37. Hubaux, A., Boucher, Q., Hartmann, H., Michel, R., Heymans, P.: Evaluating a textual feature modelling language: four industrial case studies. Softw. Lang. Eng. (2010)

  38. Hubaux, A., Xiong, Y., Czarnecki, K.: A user survey of configuration challenges in Linux and eCos. In: Proceedings of the Sixth International Workshop on Variability Modeling of Software-Intensive Systems (2012)

  39. IBM, Thales, Fokus, F., TCS: Proposal for Common Variability Language (CVL) (2012, revised submission). http://www.omgwiki.org/variability/doku.php

  40. Jackson, D.: Alloy: a lightweight object modelling notation. ACM Trans. Softw. Eng. Methodol. 11(2), 256–290 (2002)

  41. Jackson, D.: Software Abstractions: Logic, Language, and Analysis. The MIT Press, Cambridge (2011)

    Google Scholar 

  42. Janota, M., Botterweck, G.: Formal approach to integrating feature and architecture models. Fundam. Approach. Softw. Eng. 31–45 (2008)

  43. Jouault, F., Bézivin, J.: KM3: a DSL for metamodel specification. In: Formal Methods for Open Object-Based Distributed Systems, pp. 171–185 (2006)

  44. Jussien, N., Rochart, G., Lorca, X., et al.: Choco: an open source java constraint programming library. In: CPAIOR’08 Workshop on Open-Source Software for Integer and Contraint Programming (OSSICP’08) (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 modeling. In: Proceedings of the Fourth International Workshop on Variability Modelling of Software-Intensive Systems (2010)

  47. Lambek, J., Scott, P.J.: Introduction to Higher-Order Categorical Logic, vol. 7. Cambridge University Press, Cambridge (1988)

    MATH  Google Scholar 

  48. Liang, J.: Correcting Clafer Models with Automated Analysis. Technical Report GSDLab-TR 2012-04-30, GSD Lab, University of Waterloo (2012)

  49. Liang, J.: Solving Clafer models with Choco (GSDLab-TR 2012-12-30) (2012)

  50. Michel, R., Classen, A., Hubaux, A., Boucher, Q.: A formal semantics for feature cardinalities in feature diagrams. In: Proceedings of the 5th Workshop on Variability Modeling of Software-Intensive Systems (2011)

  51. Murashkin, A.: Automotive electronic/electric architecture modeling, design exploration and optimization using Clafer. Master’s thesis, University of Waterloo (2014)

  52. Murashkin, A., Antkiewicz, M., Rayside, D., Czarnecki, K.: Visualization and exploration of optimal variants in product line engineering. In: Proceedings of the 17th International Software Product Line Conference (2013)

  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 on Nonfunctional System Properties in Domain Specific Modeling Languages (2012)

  54. OMG: Meta Object Facility (MOF) Core Specification (2011)

  55. OMG: OMG Object Constraint Language (OCL) 2.4 (2014)

  56. Partnership, A.D.: Automotive open system architecture (autosar), release 4.1 (2013). http://www.autosar.org/specifications/release-41/

  57. Partnership, A.D.: Feature model exchange format (2013).https://www.autosar.org/fileadmin/files/releases/4-1/methodology-templates/templates/standard/AUTOSAR_TPS_FeatureModelExchangeFormat.pdf

  58. Reiser, M.O., Kolagari, R.T., Weber, M.: Unified feature modeling as a basis for managing complex system families. In: Proceedings of the First International Workshop on Variability Modelling of Software-Intensive Systems (2007)

  59. Rossini, A., Rutle, A., Lamo, Y., Wolter, U.: A formalisation of the copy-modify-merge approach to version control in MDE. J. Log. Algebr. Program. 79(7), 636–658 (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), 422–457 (2012)

  61. Schmid, K., John, I.: A customizable approach to full lifecycle variability management. Sci. Comput. Program. 53, 259–284 (2004)

  62. Software Productivity Consortium Services Corporation: Reuse-Driven Software Processes Guidebook, version 02.00.03. Technical Report SPC-92019-CMC (1993)

  63. Stephan, M., Antkiewicz, M.: Ecore.fmp: A tool for editing and instantiating class models as feature models. Technical Report 2008-08, University of Waterloo (2008)

  64. Sunyé, G., Pollet, D., Traon, Y.L., Jézéquel, J.M.: Refactoring UML models. In: UML—The Unified Modeling Language. Modeling Languages, Concepts, and Tools, pp. 134–148 (2001)

  65. Wand, Y., Storey, V., Weber, R.: An ontological analysis of the relationship construct in conceptual modeling. ACM Trans. Database Syst. 24(4), 494–528 (1999)

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Kacper Bąk.

Additional information

Communicated by Dr. Benoit Baudry.

Appendices

Appendix 1: Notation and terminology

1.1 Mappings

By a mapping \(f\) from a source set \(A\) to a target set \(B\), we understand a function that sends each element of \(A\) to a collection (perhaps, empty) \(f(a)\) of elements of \(B\). We say that \(f\) is multi-valued. The most general collection we consider is a bag (or a family, or an indexed set) of elements—precise definitions are in section “Semantic universe: mappings.” We call a mapping set-valued, if all bags \(f(a)\) are actually sets (UML then annotates the mapping with marker “unique”). A set-valued mapping is single-valued, if all non-empty sets \(f(a)\) are singletons.

A mapping is total if all bags \(f(a)\) are not empty; otherwise it is strictly partial. An underspecified mapping, which may be total but not necessarily, is called partial. Thus, totality and strict partiality are constraints that a general (partial) mapping may satisfy. Following a common practice, we often say partial instead of strictly partial. Note that according to the definition above, a single-valued mapping can be partial.

A set-valued mapping is inclusion if its source is a subset of the target, \(A \subset B\), and for all \(A\in A\), \(f(a)=a\) (but \(a\) on the right of equality is considered as an element of \(B\)). An inclusion of \(A\) into itself is the identity mapping  \({{{\mathsf{\textit{id} }}}}_A\!:A\rightarrow A\).

A set-valued mapping is containment if its inverse is total and single-valued.

1.2 Shapes and fonts

We use the following terminology and conventions to formally specify models and meta-models. Boxes (called classes) represent sets, boxes with rounded edges represent primitive domains (e.g., Integer), arrows (called maps) represent mappings between sets. Names of classes in models are written in Serif font, whereas names of classes in meta-models are written in Small Capital font. Names of maps are in italic font. If a class or map name is predefined then it is \({\mathsf{underlined}}\). Diagram predicates are [red and enclosed in brackets]. For multiplicities, we skip the braces and write numbers (e.g., 1), or number ranges (e.g., \(1..1\)). Derived elements are shown as blue and blank.

Appendix 2: Semantics and syntax of DP-graphs (formal CDs)

In the OO-modeling view, the world consists of objects and links between them. We typically collect objects into sets, and links into mappings between these sets. Taken together, objects, links, sets, and mappings, constitute a huge universe denoted by SetMap. A particular OO model (class diagram) specifies a small fragment of the universe; usually, describing a diagram of sets and mappings involved in the fragment, and properties they must satisfy. Here, we outline the basics of a mathematical framework, in which such OO modeling can be formally specified. We first consider semantics, i.e., the universe SetMap as such, in sections “Semantic universe: mappings”–“Semantic universe: configurations of mappings and their properties,” and then proceed with syntactical means for specifying fragments of SetMap (section “Syntax: DP-graphs”). We assume that the basic notions of naive set theory (set, subset, an ordered pair etc., and (single-valued) function, injection, bijection, etc.) are known.

1.1 Semantic universe: mappings

We give two definitions: relational (a mapping is a span of functions), and navigational or functional (a mapping is a multi-valued function as in section “Mappings”). Then, we show that both essentially define the same construct called a mapping.

1.1.1 Multi-relations or Spans

Let \(A\) and \(B\) be sets. By a mapping from \(A\) to \(B\), we can understand a set of labeled links, i.e., triples \((a,b, \ell )\) with \(a\in A\), \(b\in B\), and \(\ell \in L\) a label taken from some predefined set \(L\) of link IDs, so that multiple links between the same \(a\) and \(b\) are possible. The following definition makes the idea precise.

Definition 1

(span) A multi-relation or a span, \(r\!:A\nrightarrow B\), is a triple \((L_r,s_r,t_r)\) with \(L_r\) a set, and \(s_r\), \(t_r\) two totally defined single-valued functions from \(L_r\) as shown in the following diagram:

$$\begin{aligned} \mathsf {(span)}\qquad \qquad \qquad \qquad A\mathop {\longleftarrow }\limits ^{s_r}L_r\mathop {\longrightarrow }\limits ^{t_r}B. \end{aligned}$$

Set \(L_r\) is the head, functions \(s_r, t_r\) are the source and target legs, and sets \(A,B\) are the source and target feet of the span.

We will denote the set of all spans from \(A\) to \(B\) by \(\mathsf {Span}(A,B)\).

To ease reading formulas, we will align them with the geometry of diagram \(\mathsf {(span)}\) and write \(a=s_r.\ell \) to denote application of function \(s_r\) to \(\ell \in L_r\), which results in \(a\in A\), and similarly \(\ell .t_r=b\) denotes \(t_r\) applied to \(\ell \) with result \(b\in B\). The triple \((a,\ell ,b)\) is then called an r-link \(\ell \) from \(a\) to \(b\).

It is easy to see that a span \(r\!:A\nrightarrow B\) gives rise to a total single-valued function \(\hat{r}\!:L_r\rightarrow A\times B\) (even if \(r\) is strictly partial), and conversely, any such function gives us a span with \(s_r=\hat{r}.p\) and \(t_r=\hat{r}.q\) where \(p\!:A\leftarrow A\times B\) and \(q\!:A\times B\rightarrow B\) are projection functions (Totality of \(r\) is equivalent to left-surjectivity of \(\hat{r}\), i.e., surjectivity of \(s_r\).). Any relation \(r\subset A\times B\) is a span, whose head is \(r\) and legs are projections restricted to \(r\). Hence, the set of all relations \(\mathsf {Rel}(A,B)\) is included into \(\mathsf {Span}(A,B)\).

A span \(r\in \mathsf {Span}(A,B)\) can be seen as a multi-relation, i.e., a relation with possible repetitive pairs of elements (links). We can eliminate repetitive links by considering the image of \(L_r\), i.e., set \(L_r!\mathop {=}\limits ^{\small {\mathrm {def}}}\hat{r}(L_r)\subset A\times B\), which consists of pairs of elements, i.e., is a binary relation. It gives rise to 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 function \(!_{A,B}\!:\mathsf {Span}(A,B)\rightarrow \mathsf {Rel}(A,B)\); the subindex will be omitted if it is clear from the context.

We will also need the notion of span isomorphism, in which the number of links matters, not their IDs.

Definition 2

Two spans \(r1,r2\!:A\nrightarrow B\) are considered isomorphic, \(r1\cong r2\), iff there is a bijection between their heads commuting with legs.

1.1.2 Multi-valued functions

By a mapping from \(A\) to \(B\), we can also understand a function that sends each element of \(A\) to a collection (perhaps, empty) \(f(a)\) of elements of \(B\). Hence, we first need to define collections.

Definition 3

(families or bags) Let \(X\) be a set. A family of \(X\)’s elements is given by an indexed set \(I\) and a function \(x\!:I\rightarrow X\), for which we prefer to write \(x_i\) for the value \(x(i)\), \(i\in I\). Correspondingly, the graph of function \(x\), i.e., the set \(\{(i,x_i){|}~i\in I\}\) is denoted by expression {\(\{x_i{|}~i\in I\}\)}, where double brackets indicate that repetitions (say, \(x_i=x_j\) for \(i\ne j\)) are possible. In the UML parlance, such double-bracketed expressions are often called bags, and we also use this term. However, formally, a bag is a family, i.e., the graph of the indexing function of the family.

The set of all bags of \(X\)’s elements is denoted \(\mathsf {Bag}(X)\).

Note that an ordinary subset \(A\) of \(X\) can be seen as a bag {\(\{a_a{|}~a\in A\}\)} \(=\) \(\{(a,a){|}~a\in A\}\), which is the graph of inclusion \(A\) into \(X\). Thus, the powerset of \(X\), \(\mathsf {Set}(X)\), is included into \(\mathsf {Bag}(X)\).

Any bag/family \(x\in \mathsf {Bag}(X)\) can be compressed to its carrier set by eliminating repetitions, i.e., by taking the image \(\{x_i{|}~i\in I\}\) of the indexing function. We denote the resulting set by \(x!\subset X\). We thus have a function \(!_X\!:\mathsf {Bag}(X)\rightarrow \mathsf {Set}(X)\); the subindex will be omitted if it is clear from the context.

Definition 4

A multi-valued (mv) function, \(f\!:A\twoheadrightarrow B\), is a single-valued total function \(f\!:A\rightarrow \mathsf {Bag}(X)\). Given \(a\in A\), we will denote the indexing function of family \(f(a)\) as \({f}^{a}\!:I_{f}^{a}\rightarrow B\).

By composing \(f\) with \(!_X\), we obtain the set-valued reduct of \(f\), function \(f!\!:A\rightarrow \mathsf {Set}(X)\).

Like for span isomorphism, what matters is the number of indices rather than their IDs.

Definition 5

Two mv-functions \(f1,f2\!:A\twoheadrightarrow B\) are considered isomorphic, \(f1\cong f2\), if for each \(a\in A\), there is a bijection between the indexing sets \(\iota _a\!:I_{f1}^{a}\rightarrow I_{f2}^{a}\) commuting with the indexing functions \({fi}^{a}\), that is, \(\iota _a.{f2}^{a} = {f1}^{a}\).

1.1.3 Spans and functions together: mappings

Given a span \(r\!:A\nrightarrow B\), we can build a multi-valued function \({{r}^*}\!:A\twoheadrightarrow B\) by defining for a given \(a\in A\),

(1) the index set \(I_{{{r}^*}}^{a}=s_r^{-1}(a)\subset L_r\), and

(2) for a link \(\ell \in I_{{{r}^*}}^{a}\) considered as an index, \({{{r}^*}}^{a}(\ell )=\ell .t_r\) (see Def.4 for the notation used).

In a slightly different notation,

$$\begin{aligned} {{r}^*}(a)&= \{\{b_\ell {|}~\ell \in I_{{{r}^*}}^{a} \text{ and } \ell .t_r=b_\ell )\}\}\nonumber \\&= \{(\ell , b_\ell ){|}~\ell \in I_{{{r}^*}}^{a} \text{ and } \ell .t_r=b_\ell \}, \end{aligned}$$
(1)

Given any mv-function \(f\!:A\twoheadrightarrow B\), we build a span \({{f}^*}\!:A\nrightarrow B\) by defining

1. the set of links \(L_{{f}^*}=\uplus \{I_{f}^{a}{|}~a\in A\}\) (where \(\uplus \) denotes disjoint union), and

2. for any link \(\ell \in L_{{f}^*}\), \(s_{{f}^*}(\ell )=a\) iff \(\ell \in I_{f}^{a}\), and \(t_{{f}^*}(\ell )={f}^{a}(\ell )\).

Theorem 1

For any span \(r\!:A\nrightarrow B\), \({{{r}^*}}^*\cong r\) and \({r!}^*={{r}^*}!\).

For any mv-function \(f\!:A\twoheadrightarrow B\), \({{{f}^*}}^*\cong f\) and \({f!}^*={{f}^*}!\).

Proof

Straightforward checking

Thus, spans and mv-functions are two equivalent ways of specifying a unidirectional association between two sets. We can use either of them to make technicalities easier. We thus use a loose term “mapping” as a reference to either a span, or an equivalent mv-function. For example, working with set-valued functions is convenient, and this is how we have interpreted non-bag arrows in our formal CDs. However, if we need to consider instantiation in the classical UML sense via typed graphs, direct linking and, hence, spans, may be a better choice. As for bag-valued functions, working with them is technically much simpler in the span representation.

For a puristically oriented reader, we can define a mapping in the Clafer spirit as a pair \((r,f)\) with \(r\!:A\nrightarrow B\) a span and \(f\!:A\twoheadrightarrow B\) an mv-function with \({{r}^*}\cong f\) (or, equivalently, \({{f}^*}\cong r\)).

1.1.4 Set-valued mappings

Given an mv-function \(f\!:A\twoheadrightarrow B\) and an element \(a\in A\), suppose that the indexing function \({f}^{a}\!:I_{f}^{a}\rightarrow B\) (see Definition 4) is injective. Then, the bag \(f(a)\) does not have repetitions, indexes can be forgotten, and the bag can be seen as a subset of \(B\). If all indexing functions are injections, then all bags \(f(a)\) can be seen as subsets, and \(f\cong f!\!:A\rightarrow \mathsf {Set}(B)\). We then say that \(f\) is a set-valued function.

It is easy to see that in the span representation, the counterpart of set-valued functions are relations. A mapping/span \(r\!:A\nrightarrow B\) is a relation iff each element/link \(\ell \in L_r\) is completely identified by the pair \((s_f.\ell , \ell .t_f)\).

Theorem 2

A span \(r\!:A\nrightarrow B\) is a relation iff its navigational counterpart, mv-function \({{r}^*}\!:A\twoheadrightarrow B\), is set-valued.

1.2 Semantic universe: operations on mappings

1.2.1 (Sequential) Mapping composition

For set-valued mappings, \(f\!:A\twoheadrightarrow B\), \(g\!:B\twoheadrightarrow C\), their composition is an ordinary functional composition: for any \(a\in A\), \(a.f.g=(a.f).g\), where for a set \(X\subset B\), \(X.g\mathop {=}\limits ^{\small {\mathrm {def}}}\bigcup _{x\in X}x.g\).

For the general case of bag-valued mappings, it is much easier to define composition for the span representation. Given two consecutive spans \(q\!:A\nrightarrow B\), \(r\!:B\nrightarrow C\), their composition \(q{.}r\!:A\nrightarrow C\) is defined as follows. The head

$$\begin{aligned} L_{q{.}r}\mathop {=}\limits ^{\small {\mathrm {def}}}\{(\ell ,\ell ')\in L_{q}\times L_{r}: \ell _1.t_{q}=s_{r}.\ell _2\}, \end{aligned}$$

and the legs are defined by setting

$$\begin{aligned} s_{q{.}r}.(\ell ,\ell ')=s_{q}.\ell ,\quad \text{ and }\quad (\ell , \ell ').t_{q{.}r}=\ell '.t_{r}, \end{aligned}$$

which is a straightforward generalization of the ordinary binary relation composition for the general span case. It is easy to see that if spans are relations and hence functions \({q}^*\), \({r}^*\) are set-valued, two definitions of composition coincide (up to isomorphism).

Note that composition of set-valued mappings can be bag-valued. For example, suppose that \(A=\{a\}\), \(B=\{b_1, b_2\}\), \(C=\{c\}\), and mappings are defined functionally: \({f}^*(a)=\{b_1, b_2\}\), and \({g}^*(b_1)={g}^*(b_2)=\{c\}\). Then, \(f.g\) consists of two links, \(\ell _1=(ab_1,b_1c)\) and \(\ell _2=(ab_2,b_2c)\), so that \({(f{.}g)}^*(a)\) is a bag \(\{\{c_{\ell _1}, c_{\ell _2}\}\}\).

With so defined mapping composition, we can check that given a span \(f\!:A\nrightarrow B\), its navigational counterpart \(f^*\) is actually the composition \(s_f^{-1}.t_f\). Although functions \(s_f\) and \(t_f\) are always set-valued, their composition can be bag-valued as demonstrated by the example above. Think of \(B\) as the head \(L_\beta \) of some span \(\beta \) with \(s_\beta =({f}^*)^{-1}\), and \(t_\beta ={g}^*\). Then, \(\beta ^*=s_\beta ^{-1}.t_\beta =f.g\).

1.2.2 Inversion

Given a set-valued function \(f\!:A\twoheadrightarrow B\), its inverse is a set-valued function \(g\!:A\twoheadleftarrow B\) such that the equivalence

$$\begin{aligned} a\in g.b \Leftrightarrow a.f \ni b \end{aligned}$$

holds for any \(a\in A\) and \(b\in B\). For the general case of bag-valued functions, we again resort to spans.

Given a span \(r\!:A\nrightarrow B\), its inverse \(r^{-1}\!:A\nleftarrow B\) is defined as follows: \(L_{r^{-1}}=L_r\), \(s_{r^{-1}}=t_r\) and \(t_{r^{-1}}=s_r\); that is, the inverse of mappings uses the same span but swaps the roles of its legs. If spans are relations, both definitions coincide. It is evident that \({r^{-1}}^{-1}=r\).

1.3 Semantic universe: configurations of mappings and their properties

Table 3 presents several important properties of mapping configurations, which we call diagram predicates. The left column gives their names, the middle one specifies their arities, i.e., configurations of mappings that may have the property, and the right column provides semantics.

1.4 Syntax: DP-graphs

An OO model specifies a fragment of the universe by describing a diagram of sets and mappings involved in the fragment, and properties they must satisfy; that is, a model appears as a graph with diagram predicate declarations (a DP-graph) that describe properties. Formal CDs used in the paper are DP-graphs, whose nodes are called classes, arrows are maps (= unidirectional associations), and predicate declarations are constraints imposed on classes and maps. Hence, semantics of a formal CDs is given by interpreting its classes as sets, and maps as mappings such that the constraints are satisfied. Here, we specify syntax and semantics of DP-graphs/formal CDs formally.

1.4.1 Graphs

Definition 6

(Graphs and their morphisms.) A (directed multi)graph \(G\) consists of a set of nodes \(G_N\), a set of arrows \(G_A\), and two total single-valued functions \(src,trg{:\,} G_A\rightarrow G_N\) giving each arrow its source and target.

A graph morphism (mapping) \(f\!:G_1\rightarrow G_2\) is a pair of functions \(f_N{:}~G_{1N}\rightarrow G_{2N}\) and \(f_A{:}~ G_{1A}\rightarrow G_{2A}\) such that the incidence of nodes and arrows is preserved: for any arrow \(a\in G1_A\), \(src(f_A(a))=f_N(src(a))\) and \(trg(f_A(a))=f_N(trg(a))\).

1.4.2 DP-graphs

Definition 7

(Signature.) A (diagram predicate) signature is a set \(\varSigma \) of predicate symbols together with assignment to each label \(P \in \varSigma \) its arity shape—a graph \(G_{\mathrm {ar}}(P)\).

Definition 8

((Diagram) formulas) Given a diagram predicate signature \(\varSigma \) and a graph \(G\), a (diagram) formula over \(G\) is a pair \((P, args )\) with \(P\in \varSigma \) a predicate symbol, and \( args \!:G_{\mathrm {ar}}(P)\rightarrow G\) a graph morphism binding formal parameters in the arity graph by the actual arguments—elements of graph \(G\). Assume the arity graph \(G_{\mathrm {ar}}(P)\) has a finite set of arrows \(\alpha _1\ldots \alpha _n\) and does not have isolated nodes. Then, a formula can be encoded by an expression \(P(a_1\ldots a_n)\) where \(a_i= args (\alpha _i)\), \(i=1\ldots n\). In other words, a formula is a pair \((P,\mathbf{a})\) with \(P\) a predicate symbol and \(\mathbf{a}\) a bag of arrows of the carrier graph, whose indexing set is the arity graph \(G_{\mathrm {ar}}(P)\) (note that the indexing function must be a correct graph morphism–this constraint was called [ad], arity discipline, in section “Meta-model.”

Definition 9

(DP-Graph) A DP-graph is a pair \(S=(G, \varPhi )\) with \(G\) a carrier graph, and \(\varPhi \) a set of formulas over \(G\) (here \(S\) stands for specification, or sketch—a family of categorical constructs similar to DP-graphs).

Definition 10

(DP-Graph Morphisms.) A DP-graph morphism (mapping) \(f\!:S_1\rightarrow S_2\) is a morphism of the carrier graphs, \(f\!:G_1\rightarrow G_2\), compatible with formulas in the following way.

Note that any graph morphism \(f\!:G_1\rightarrow G_2\) translates formulas over \(G_1\) into formulas over \(G_2\): any formula \(\phi =P(a_1\ldots a_n)\) in \(\varPhi _1\) (with \(a_i=\alpha _i. args \)) is translated into a formula over \(G_2\), \(f(\phi )=P(a_1.f,\ldots ,a_n.f)\)—indeed, \( args .f\!:G_{\mathrm {ar}}(P)\rightarrow G_2\) is a graph morphism. Then, we require that all translated formulas were declared in \(\varPhi _2\): \(f(\phi )\in \varPhi _2\) for all \(\phi \in \varPhi _1\).

1.5 Syntax and semantics together

A major idea of categorical logic [10] is to treat semantic universes syntactically, that is, in our case, as DP-graphs. Indeed, the universe SetMap can be seen as a huge (categoricians would say big) DP-graph: Its nodes are sets, arrows are mappings, and formulas are true statements about sets and mappings. For example, if \(A\) and \(B\) are sets (nodes in graph \(\varGamma [{{\textsc {SetMap}}}]\)), and \(f\), \(g\) are mappings between them (i.e., arrows in \(\varGamma [{{\textsc {SetMap}}}]\)) going in the opposite direction, then, if mappings \(f\) and \(g\) are mutually inverse, i.e., \((f,g)\models {{\mathsf{[inv]}}{ }}\), then we add formula \({{\mathsf{[inv]}}{ }}(f,g)\) to set \(\varPhi [{{\textsc {SetMap}}}]\). Thus, the big set of formulas \(\varPhi [{{\textsc {SetMap}}}]\) consists of all valid statements about all possible configurations of sets and mappings matching predicate arities. Then, an instance of a DP-graph \(S\) can be seen as a DP-graph morphism \([\![.. ]\!]\!:S\rightarrow {\textsc {SetMap}}\). An immediate consequence of such an arrangement is the following result:

Theorem 3

Any DP-graph morphism \(f\!:S_1\rightarrow S_2\) gives rise to a function between the respective sets of instances, \([\![f ]\!]\!:[\![S_1 ]\!]\leftarrow [\![S_2 ]\!]\), where \([\![S_i ]\!]\) denotes the (big) set of all instances of DP-graph \(S_i\).

Proof

As a correct instance of \(S_2\) is a correct graph morphism, \([\![.. ]\!]\!:S_2\rightarrow {\textsc {SetMap}}\), its composition with \(f\) gives us a correct instance of \(S_1\).

Appendix 3: Clafer concrete syntax

Conciseness is an important goal for Clafer; therefore, it provides syntactic sugar for common constructions. Figure 26 shows the model from Fig. 7 in a desugared notation, in which the defaults (e.g., multiplicities) are inserted into clafer declarations. Each declaration starts with group cardinality, followed by name, optional supertype, then by optional clafer’s target, and ends with multiplicity (see Fig. 27). The desugared notation shows that all clafers nested in an abstract clafer are abstract by default. There are also different kinds of clafers: basic (have no reference target), reference set (name followed by ‘\(\rightarrow \)’ symbol, and reference bag (name followed by ‘\(\twoheadrightarrow \)’ symbol); not shown.

Fig. 27
figure 27

BNF grammar of Clafer (no constraints)

Clafer multiplicity is given by an interval \({m}\mathrm .. {n}\). Clafer provides syntactic sugar similar to syntax of regular expressions: ? (optional) denotes \({0}\mathrm .. {1}\); * denotes \({0}\mathrm .. {*}\); and + denotes \({1}\mathrm .. {*}\). By default, clafers have multiplicity \({1}\mathrm .. {1}\).

Group cardinality is given by an interval \({m}\mathrm .. {n}\), with the same restrictions on \(m\) and \(n\) as for multiplicities, or by a keyword: xor denotes \({1}\mathrm .. {1}\); or denotes \({1}\mathrm .. {*}\); opt denotes \({0}\mathrm .. {*}\); and mux denotes \({0}\mathrm .. {1}\); further, each of the keywords makes children optional by default. For example, xor on size (line 2) states that only one child instance of either small or large is allowed. No explicit group cardinality stands for \({0}\mathrm .. {*}\), except when it is inherited from clafers supertype.

Appendix 4: Clafer constraint language

The Clafer constraint language is essentially borrowed from Alloy [41]. The two most significant differences are name resolution rules and the default some quantifier before clafer names. Both developments contribute to conciseness of the constraints defined over hierarchical models. Constraints are logical expressions composed of terms and logical operators. Terms either relate values (integers, strings) or are navigational expressions. The value of navigational expression is always a set; therefore, each expression must be preceded by a quantifier, such as no (requires set to be empty), one (requires set to have one element), lone (requires set to have at most one element), or some (requires the set to be non-empty). Lack of explicit quantifier (Fig. 7) stands for some (Fig. 26).

Although the constraints are specified over Clafer models, we define their semantics over Class Diagrams (our semantic domain). A formal class diagram of Clafer model is composed of classes, maps, and constraints. An instance of class diagram is an object diagram that is composed of objects and links; it must satisfy constraints defined over CD. Each constraint is defined in context of a class. The context corresponds to defining constraints nested under clafers, because in a CS the head class represents the clafer. If in a Clafer model constraint is defined at top-level, then in the corresponding MCS and CD it is defined in the context of synthetic root. The constraint language used in Clafer allows one to define new diagram predicates of shapes spanning several Clafer shapes and whose semantics is expressible in first-order logic.

1.1 Grammar

Figure 28 shows grammar of the core constraint language. The full constraint language has additional syntactic sugar, but any constraint may be desugared to the core constraint language. In the first production in Fig. 28, var represents variables bound by quantifiers. In the production with binary operators, \(\oplus \) is one of \(<, =, +, -\) (logical comparison, equality, addition, and subtraction, respectively). In the production with set operators, \(\otimes \) is one of \( ++, --, \& , \textit{in}\) (set union, difference, intersection, and subsetting, respectively). The last production Name represents names of head maps that correspond to clafer names, or is one of reserved names. When Names form a sequence \(n_1.n_2\ldots n_m\), we call such as an expression a navigation. The dot between names indicates relational join.

Fig. 28
figure 28

BNF grammar of core Clafer constraints

1.2 Name resolution rules

Name resolution rules disambiguate names of clafers used in constraints. The rules are needed as clafer names may repeat in Clafer model. The rules are applied during compilation of Clafer model to MCS; thus MCS and CD have all names properly resolved. The rules are similar to CVL rules [39], as the latter were inspired by Clafer. A name is resolved in the context of a clafer (top-level constraints are defined in the context of synthetic root) as follows:

  1. 1.

    Reserved names. Check if it is a special name: such as parent, dref, and \({\underline{\mathsf{this}}}\). The latter indicates object for which the constraint is evaluated. Further, primitive domains also use reserved names, \({\underline{\mathsf{int}}}\) for integers, and \({\underline{\mathsf{string}}}\) for strings.

  2. 2.

    Binding. Check if name is introduced by a local variable (used in constraints with quantifiers).

  3. 3.

    Descendants. Look up the name in descendant clafers of the context clafer in breadth-first search manner. If a clafer has supertype, take into account inherited clafers.

  4. 4.

    Targets. Similar to the previous step but additionally take into account clafers reachable via references.

  5. 5.

    Ancestors. Search in the ancestors clafers starting from the parent clafer of the context and up. For each ancestor, look up the name using the rules Descendants and, if necessary, Targets.

  6. 6.

    Top level. Search in other top-level clafers. For each clafer apply rules Descendants and, if necessary, Targets.

  7. 7.

    Error. If the name cannot be resolved or is ambiguous within a single step, the constraint is not well formed and an error is reported.

For navigations (expressions of the form \(n_1.n_2\ldots n_m\)), the name resolution rules are applied to resolve \(n_1\) first. Once it is resolved, subsequent clafers (\(n_2.n_3\ldots n_m\)) are resolved by applying only rules Reserved names, Descendants, and Error. Note that \(n_1\) becomes the context clafer for resolving \(n_2\), and \(n_2\) becomes the context for \(n_3\), etc. A fully resolved name is a navigation that starts with this, i.e., is of the form this \(.c_2 \ldots c_m\).

1.3 Type rules

The type system is specified in a series of formal rules.

The above rule says that if \(A\) holds, then \(B\) follows.

1.3.1 Expressions

figure s

1.3.2 Set expressions

figure t

1.4 Semantics

The semantics assumes that (1) navigation paths have already been resolved to specific clafers (head classes) and (2) all expressions are correctly typed. A constraint is specified in the context of a class and is evaluated in the context of each instance (object) of that class. We call the latter context an environment. For an object \(o\) we initialize environment to be \(\textit{env}= \{\mathsf{this } \mapsto o\}\)

$$\begin{aligned} \textit{Env}&= \textit{Var} \rightarrow \textit{Value}\\ \textit{Value}&= \mathcal {P}(\textit{Object}) \cup \mathcal {P}(\textit{Link}) \end{aligned}$$

Environment maps variables to values, which are either sets of objects or links. Note that a single object would be represented as a singleton set.

A constraint is a Boolean-valued expression. The semantics uses two interpretation functions:

\([\![ ]\!]\) \(_E\) \(: \textit{Exp} \rightarrow \textit{Env} \rightarrow \textit{Boolean} \cup \mathcal {P}(\textit{Object})\)

\([\![ ]\!]\) \(_S\) \(: \textit{SetExp} \rightarrow \textit{Env} \rightarrow \textit{Value}\)

The former function interprets abstract syntax elements of expressions for a given environment and evaluates to a Boolean value or a set of objects. A set of objects is always a singleton. In particular, values of primitive domains (e.g., integer) are encoded as singletons. Analogically, the latter function interprets set expressions, which are either sets of objects or links.

1.4.1 Semantics of expressions

figure u

1.4.2 Semantics of set expressions

figure v

Appendix 5: MCS constraints

Each Multi-Clafer Shape is only valid if it satisfies incidence constraints (defined in Table 5), clafer kind/shape discipline constraints (defined in Table 7), clafer cojoining constraints (defined in Table 6), and naming discipline constraints (defined in Table 8).

Appendix 6: Full telematics model

Below is the running example of telematics system modeled in Clafer.

figure w

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Bąk, K., Diskin, Z., Antkiewicz, M. et al. Clafer: unifying class and feature modeling. Softw Syst Model 15, 811–845 (2016). https://doi.org/10.1007/s10270-014-0441-1

Download citation

  • Received:

  • Revised:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10270-014-0441-1

Keywords

Navigation