=Paper=
{{Paper
|id=Vol-2999/oclpaper8
|storemode=property
|title=A SWOT Analysis of the Object Constraint Language
|pdfUrl=https://ceur-ws.org/Vol-2999/oclpaper8.pdf
|volume=Vol-2999
|authors=Jordi Cabot,Daniel Calegari,Robert Clarisó,Martin Gogolla,Antonio Vallecillo,Edward D. Willink
|dblpUrl=https://dblp.org/rec/conf/staf/CabotCCGVW21
}}
==A SWOT Analysis of the Object Constraint Language==
https://ceur-ws.org/Vol-2999/oclpaper8.pdf
A SWOT Analysis of the Object Constraint Language
Jordi Cabot1 , Daniel Calegari2 , Robert Clarisó3 , Martin Gogolla4 , Antonio Vallecillo5
and Edward D. Willink6
1
ICREA, Barcelona, Spain
2
Instituto de Computación, Facultad de Ingeniería, Universidad de la República, Uruguay
3
Universitat Oberta de Catalunya, Rambla del Poblenou 156, 08018 Barcelona, Spain
4
University of Bremen, Germany
5
ITIS Software, Universidad de Málaga, Spain
6
Willink Transformations Ltd, Reading, England
Abstract
The Object Constraint Language (OCL) is a textual language to describe constraints or queries over
software models defined by applying the Unified Modeling Language (UML). Using OCL, it is possible
to specify, for instance, integrity constraints in the form of class invariants, operation pre-conditions,
or post-conditions. This paper presents a SWOT analysis (Strengths, Weaknesses, Opportunities, and
Threats) of OCL, considering both its current state and future perspectives: specification, tool support,
applications, competitors, and the community around it. This analysis was the result of the panel
discussion at the 20th International Workshop on OCL and Textual Modeling (OCL’21).
Keywords
UML, OCL, SWOT analysis
1. Introduction
The Object Constraint Language (OCL) [1, 2] is a textual modeling notation defined as an
OMG standard (currently in its version 2.4). OCL is a complement to the graphical models in
the Unified Modeling Language (UML), augmenting UML and other types of models to define
complex expressions, queries, and constraints over software models.
To discuss recent findings related to OCL, the community organizes a yearly meeting, the
“International Workshop on OCL and textual modeling”. Previous editions of the OCL workshop
have included panels where the discussion has focused on potential improvements of the OCL,
either in its syntax, semantics, standard library, or tools. Some of these panel discussions have
been published in the workshop proceedings, e.g., from the OCL workshops that took place in
2014 [3], 2016 [4], 2017 [5] and 2019 [6].
OCL’2021: 20th International Workshop on OCL and Textual Modeling, June 25, 2021, Virtual Event
Envelope-Open jordi.cabot@icrea.cat (J. Cabot); dcalegar@fing.edu.uy (D. Calegari); rclariso@uoc.edu (R. Clarisó);
gogolla@uni-bremen.de (M. Gogolla); av@uma.es (A. Vallecillo); ed at willink.me.uk ( (E. D. Willink)
GLOBE https://jordicabot.com/ (J. Cabot); https://www.fing.edu.uy/~dcalegar/ (D. Calegari);
https://robertclariso.github.io (R. Clarisó); http://www.db.informatik.uni-bremen.de/~gogolla/ (M. Gogolla);
http://www.lcc.uma.es/~av/ (A. Vallecillo)
Orcid 0000-0003-2418-2489 (J. Cabot); 0000-0001-9639-0186 (R. Clarisó); 0000-0003-4311-1117 (M. Gogolla);
0000-0002-8139-9986 (A. Vallecillo)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
Table 1
Characterization of the four dimensions in a SWOT analysis
Positive Negative
Internal Strengths Weaknesses
External Opportunities Threats
In the OCL’21 workshop, the panel focused on analyzing the current state of the OCL,
the tool ecosystem, and the community. This analysis used the SWOT matrix framework, a
strategic planning technique where the status of a given initiative is studied from four different
perspectives: Strengths, Weaknesses, Opportunities, and Threats. Each SWOT perspective can
be classified according to two axes, as displayed in Table 1:
• Factors that are internal (inherent to the initiative) versus factors that are external (envi-
ronment, competitors, …).
• Positive factors (that represent an advantage to the initiative) versus negative factors
(detrimental to the initiative).
2. SWOT analysis
In the following, we describe the result of the SWOT analysis. Each SWOT dimension is
discussed in a different subsection. Then, a final subsection discusses controversial topics, i.e.,
aspects that can be considered both an advantage or a disadvantage.
2.1. Strengths
• OCL provides a useful and (mostly) well-defined notation for expressing constraints and
Boolean expressions on UML models. Besides, OCL is easy to use, e.g., the core concept is
the navigation through a class structure via a simple dot notation.
• OCL applies to many different tasks in the context of software modeling: model querying,
code generation, testing, verification and validation, model transformation, …
• OCL is a “technology-independent” language for defining constraints. Thus, it can be
used in a wide variety of projects using different technology stacks.
• OCL is very close to First-Order Logic (FOL). It provides an underlying formal semantics
and makes it more amenable to computer scientists or developers with a background
in logic. Furthermore, it is possible to adapt and/or reuse tools and solvers for FOL to
analyze OCL specifications. For instance, we can benefit from efficient SAT-based solvers
through a reduction to finite structures.
• Moreover, OCL has an important property: it is a side-effect free language, i.e., evaluating
an OCL constraint does not alter the model in any way. It facilitates a high-quality robust
analysis.
• OCL counts on three complete implementations: USE [7], Eclipse OCL [8] and Acceleo [9].
OCL dialects, such as EOL [10], also help to experiment with new features and mecha-
nisms.
• OCL is the best available language of its kind. There is a lack of suitable general-purpose
alternatives. Paraphrasing Bran Selic’s comment regarding UML: “OCL is the worst
modeling language, except for all the others.”
2.2. Weaknesses
• Tool ecosystem
– Implementations of OCL could be improved: some OCL tools are incomplete or
incompatible with the standard.
– Many existing tools are research prototypes developed by academics. It means that
interoperability, documentation, and support are lacking, hampering industrial or
realistic use.
– Even though a few tools exist (e.g., verification and validation tools or a Java code
generator in Eclipse OCL), there is a lack of a complete ecosystem of tools that use
OCL as input to provide valuable services. It would provide value to dedicating time
to formalize the OCL expressions.
• Complexity of the OCL language: The OCL 2.4 specification is 262 pages long and offers
some features that are complex to understand and/or implement.
– Multivalued Boolean expressions (true, false, null, invalid) increase the complexity
of evaluating properties. For instance, special values need to be taken into account
when considering short-circuits.
– OCL features a complicated type system. In particular, navigation through a class
structure is easy, but understanding the type of the results at the end of the navigation
chain can be hard due to complicated typing rules.
– OCL includes a complex hierarchy of collection types. The choice of operations and
the type hierarchy among them sometimes creates confusion, e.g., OrderedSet is not
a subclass of Set.
– OCL sometimes seems to offer too much expressive power, as there are many ways
to write the same constraint. This is good for people learning and writing OCL
expressions, but bad for building tools as the tools need to cope with all these
potential variations.
• Shortcomings of the OCL: Although OCL includes almost all desirable features, it still
presents some limitations and unresolved issues. For example:
– There are no modularity mechanisms, which could help in the definition of large
specifications.
– There are no constructs for importing or reusing other specifications completely or
partially: each OCL specification should be complete on its own.
– As a consequence of the previous shortcomings, there are no reusable OCL libraries
besides the OCL standard library. In particular, there is no library of standard
mathematical functions.
• There is a strong dichotomy between OCL’s “divine” and “material” nature, which are
impossible to reconcile.
– Under its “divine” nature in the Heaven of logic, it works under the umbrella of
first-order logic as a side-effect free language, with commutative logical operators,
and where datatypes are unbounded and perfect (e.g., no overflow or rounding
issues).
– Under its “material” nature, which appears when used down in Earth as part of
the realization of modeling languages, some issues need to be considered: short-
circuit evaluation of expressions under the presence of errors or float precision and
rounding.
– Frustration occurs when OCL is used in one world with the nature of the other.
• Community
– The team that supports OCL is very small. Despite being a “community” project, it
basically rests on the shoulders of one single person. And it has been like this for a
while with no perspective for a short-term improvement.
– The community behind the language is also small. Moreover, it consists mostly of
academic researchers with little industrial backing that could help popularize the
language or provide more resources to support it.
2.3. Opportunities
• OCL enables defining incompletely specified software systems, which is useful for pro-
totyping and exploring alternatives. It is possible to abstract implementations with
class structures and OCL expressions, e.g., defining (partial) class invariants and (partial)
operation contracts that leave some parts of the behavior unspecified.
• Some aspects that have been identified as a weakness in the OCL specification (e.g., the
lack of libraries and import mechanisms or the lack of a library of standard mathematical
operations) are also an opportunity to improve the language.
• Verification and validation: Currently, not all the potential reasoning and analysis capabil-
ities are being exploited.
– OCL could be used as the basis for much further analysis and automation tasks
that could, for instance, provide the better model analysis (validation, verification,
testing, instantiation).
– OCL could benefit from improved tool support for interactive runtime analysis and
verification, e.g., tools that interactively suggest candidate fixes for modeling faults
or that let users test alternative constraints.
• Synergies with other modeling languages
– Software development is mostly textual-based, which generates a favorable ecosys-
tem to all textual languages, like OCL.
– OCL could be used as a modular add-on to other modeling languages and DSLs. The
experience with ATL and QVT are two success stories. OCL saves users the need to
learn yet another constraint language, and its functional nature makes it suitable
for easy integration in many contexts.
– In particular, we could explore other rule-based languages (e.g., RuleML, Web se-
mantics) and communities to find potential synergies.
– Another alternative is exploring SysML as a potential area of collaboration. The
systems community seems to be more open to modeling than some subcommunities
within the software engineering domain.
– As a query language, it may have good opportunities to be used in developing
domains where some extensions might make sense from a semantic point of view
to specify constraints or query models. Examples of these domains include stream
processing and big data, which need to deal with unbounded models.
2.4. Threats
• Tools are fading rather than strengthening: several valuable tools are no longer under
active development, and others are no longer being maintained. Moreover, there is a lack
of organizations that maintain and mature the tools.
• Slow (or none) adoption of open source projects.
• The level of abstraction of programming languages is rising, lessening the value of
languages like OCL. While this is a threat for OCL, it is probably a positive side-effect of
the existence of OCL.
• Few UML modelers know or use OCL and do not acknowledge the need for OCL. Rigor
and formality are either explicitly neglected (when sketching models) or even realized in
Java.
• Many users still do not understand the two distinct (and irreconcilable) natures of OCL.
Namely, OCL is a side-effect free language, not to be used for programming. Still, many
people ask for mechanisms that allow creating object instances. The identity of OCL and
how to use and implement it needs to be better clarified. Otherwise, this “paranoia” can
kill OCL.
• Related to the previous misconception and considering that OCL is used in various
contexts (query language, verification, …), maybe we are asking too much from OCL: it is
perhaps as good as it should be, but no more.
• Related approaches such as Alloy [11] (based on relational logic) offer powerful analysis
capabilities, both in terms of verification and validation.
2.5. Controversial topics
• OCL is unique in the sense that it includes a 4-valued logic [1]: besides true and false, the
values null and invalid are also supported. Nevertheless, it is unclear whether having
a 4-valued logic is a competitive advantage or a disadvantage versus other modeling
languages. On the one hand, it allows the precise specification of different types of
situations, e.g., distinguishing the lack of information from an error. On the other hand,
it is not intuitive for newcomers to the language, and some tools do not properly support
it in the OCL ecosystem.
• OCL is not a language on its own, but fundamentally an add-on language that can be
embedded into a modeling language (e.g., UML) in which it provides navigability, query,
Table 2
Summary of the results of the SWOT analysis
Strengths Expressive, usable and convenient query & constraint language for object-oriented
software development
Availability of several implementations
Formal foundation based on first-order logic
Navigation as a useful metaphor
Lack of better alternatives
Weaknesses Expressiveness brings complexity in some aspects of the language (navigation,
types, collections, 4-valued logic): this hurts tool development
Lack of industrial tool support
Lack of desirable features (libraries, importing, modularity) in the language
Lack of a complete tool ecosystem that adds value to existing OCL constraints
Opportunities OCL supports describing incomplete specified systems
Room for improvement in future versions of the language
Improved verification and validation (e.g., interactive analysis)
Potential synergies with other languages (SysML, RuleML, business rules)
Threats Lack of organisations involved in OCL tool development and maintenance
Lack of awareness about the need for OCL in UML
Misconceptions about the usage scenarios for OCL
Strong competition from Alloy on the verification & validation side
and constraint specification features to other modeling languages. It allows OCL to add
value to the extended modeling languages and makes OCL a reusable notation with
well-grounded semantics. On the contrary, not being a stand-alone language hinders its
wide adoption — particularly when OCL does not provide mechanisms to be incorporated
into other modeling languages in a modular and reusable manner. Note that with so
many textual notations of the UML, it should be somehow feasible to easily combine UML
and OCL expressions in a single textual model.
3. Conclusions
This paper has presented a discussion of the current state of OCL and its future trends using
the SWOT analysis framework. Table 2 provides a summary of the findings.
These results indicate relevant opportunities for future research and collaborations concerning
OCL and issues that the OCL community should address.
Acknowledgments
The authors would like to thank the attendees of the OCL workshop for the interesting discus-
sions during the panel.
References
[1] OMG, Object constraint language (OCL) version 2.4, 2014. URL: https://www.omg.org/
spec/OCL/.
[2] J. Cabot, M. Gogolla, Object constraint language (OCL): A definitive guide, in: M. Bernardo,
V. Cortellessa, A. Pierantonio (Eds.), Formal Methods for Model-Driven Engineering – 12th
International School on Formal Methods for the Design of Computer, Communication,
and Software Systems, volume 7320 of LNCS, Springer, 2012, pp. 58–90. doi:1 0 . 1 0 0 7 /
978- 3- 642- 30982- 3\_3.
[3] A. D. Brucker, T. Clark, C. Dania, G. Georg, M. Gogolla, F. Jouault, E. Teniente, B. Wolff,
Panel discussion: Proposals for improving OCL, in: A. D. Brucker, C. Dania, G. Georg,
M. Gogolla (Eds.), Proc. of the 14th International Workshop on OCL and Textual Modelling,
co-located with MODELS 2014, Valencia, Spain, September 30, 2014, volume 1285 of CEUR
Workshop Proceedings, CEUR-WS.org, 2014, pp. 83–99. URL: http://ceur-ws.org/Vol-1285/
paper09.pdf.
[4] A. D. Brucker, J. Cabot, G. Daniel, M. Gogolla, A. S. Herrera, F. Hilken, F. Tuong, E. D.
Willink, B. Wolff, Recent developments in OCL and textual modelling, in: A. D. Brucker,
J. Cabot, A. S. Herrera (Eds.), Proc. of the 16th International Workshop on OCL and
Textual Modelling, co-located with MODELS 2016, Saint-Malo, France, October 2, 2016,
volume 1756 of CEUR Workshop Proceedings, CEUR-WS.org, 2016, pp. 157–165. URL: http:
//ceur-ws.org/Vol-1756/paper12.pdf.
[5] R. Bill, A. D. Brucker, J. Cabot, M. Gogolla, A. Vallecillo, E. D. Willink, Workshop in OCL and
textual modelling – report on recent trends and panel discussions, in: M. Seidl, S. Zschaler
(Eds.), Proc. of STAF 2017 Collocated Workshops, Marburg, Germany, July 17-21, 2017,
volume 10748 of LNCS, Springer, 2017, pp. 297–301. doi:1 0 . 1 0 0 7 / 9 7 8 - 3 - 3 1 9 - 7 4 7 3 0 - 9 \ _ 2 6 .
[6] A. D. Brucker, G. Daniel, M. Gogolla, F. Jouault, C. Ponsard, V. Ramon, E. D. Willink,
Emerging topics in textual modelling, in: A. D. Brucker, G. Daniel, F. Jouault (Eds.), Proc.
of the 19th International Workshop in OCL and Textual Modeling (OCL 2019) co-located
with MODELS 2019, Munich, Germany, September 16, 2019, volume 2513 of CEUR Workshop
Proceedings, CEUR-WS.org, 2019, pp. 91–104. URL: http://ceur-ws.org/Vol-2513/paper8.pdf.
[7] M. Gogolla, F. Büttner, M. Richters, USE: A UML-based specification environment for
validating UML and OCL, Sci. Comput. Program. 69 (2007) 27–34. doi:1 0 . 1 0 1 6 / j . s c i c o .
2007.01.013.
[8] Eclipse Foundation, Eclipse OCL (Object Constraint Language), 2021. URL: https://projects.
eclipse.org/projects/modeling.mdt.ocl.
[9] Obeo, Acceleo OCL, 2021. URL: https://wiki.eclipse.org/Acceleo/OCL.
[10] D. S. Kolovos, R. F. Paige, F. Polack, Epsilon Object Language (EOL), 2021. URL: https:
//www.eclipse.org/epsilon/doc/eol/.
[11] D. Jackson, Software abstractions: logic, language, and analysis, MIT press, 2012.