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).
The Object Constraint Language (OCL) [
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 https://jordicabot.com/ (J. Cabot); https://www.fing.edu.uy/~dcalegar/ (D. Calegari);
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 diferent 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 (environment, competitors, …). • Positive factors (that represent an advantage to the initiative) versus negative factors (detrimental to the initiative).
In the following, we describe the result of the SWOT analysis. Each SWOT dimension is
discussed in a diferent 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 diferent 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 diferent 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 eficient SAT-based solvers
through a reduction to finite structures.
• Moreover, OCL has an important property: it is a side-efect 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 [
OCL dialects, such as EOL [
– 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 ofer 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 ifrst-order logic as a side-efect 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: shortcircuit 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 prototyping 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 capabilities 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 ecosystem 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 semantics) 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-efect 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-efect 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 [
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.
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.
The authors would like to thank the attendees of the OCL workshop for the interesting discussions during the panel.