This post summarizes our paper “Managing design-time uncertainty in OCL expressions” published in the Journal of Object Technology. This paper, co-authored with Loli Burgueño and Jordi Cabot, was part of the JOT Special issue dedicated to Professor Antonio Vallecillo on his 60th birthday, as a tribute to his contributions to the field of software modeling. In our case we chose to focus our tribute on the specific topic of uncertainty modeling. But instead of discussing how to express the uncertain aspects of the domain being modeled, in this paper we propose a new contribution to deal with models that are themselves uncertain, in particular when it comes to their OCL constraints and business rules.

Designing software systems is a complex process that requires domain knowledge and the participation of all relevant stake-holders. Errors in a software design, such as missing or incorrect information may cause faults at later stages of the development process, when they are more expensive to fix. Thus, there is a strong incentive to ensure the quality of the artifacts built in the software design phase.

On the other hand, design happens at an early stage of the software development process. Therefore, designers may not yet have a clear understanding about the domain or the business rules of the system being developed. Furthermore, different stakeholders may be unable to reach an agreement regarding the expected behavior in specific scenarios. Finally, it may be desirable to postpone some design decisions until later stages of the design process, when more information is available. In all of these situations, capturing the uncertainty during the design process is useful instead of just waiting for all these aspects to be clear.

So far, design uncertainty has limited to core structural modeling concepts, such as the existence of a particular attribute or association. Nevertheless, an aspect where design uncertainty is particularly significant, and that has not been addressed yet, is the definition of the integrity constraints of a software system. Integrity constraints may describe precise details about system behavior or the validity and consistency of the information base. These details may be unknown or undecided at this stage of the development, so it is desirable to define and manage uncertain integrity constraints.

In this work, we target the definition of integrity constraints in UML diagrams using the Object Constraint Language (OCL). OCL constraints take the form of class invariants that must hold true for all instances of that class or pre/post-conditions of operations. We propose an extension of the OCL notation that supports the definition of uncertain integrity constraints and their analysis using existing off-the-shelf tools for the verification and validation of OCL.

To this end, we extend the syntax of OCL by introducing a notation for denoting uncertainty. This notation indicates that the value of a particular subexpression within a constraint is uncertain: it could take several potential alternative values, and currently it is not possible to decide which alternative is the correct one as we do not know enough about the domain we are modeling and we believe it’s better to at least propose a constraint with some uncertain aspects that entirely ignore the constraint until later on. Indeed, we prefer to have partial information available now that full information in a yet-to-decide future. This extension supports the following concepts:

  • Uncertain invariants: It is possible for a designer to be uncertain about whether a certain constraint should exist or not in the system being developed.
[? context Employee inv EmployeeNotClient:
not Client.allInstances()→
exists(c | = ]
  • Uncertain expressions and operations: It is possible to specify a set of alternative values for a given subexpression or a set of alternative names of operations to be invoked in a given expression. We specify the alternatives as a bracketed comma-separated list.
context Bundle inv BundleAvailability1:
self.available =
[ exists, forAll ](p | p.available)
context Bundle inv BundleAvailability2:
self.available =
[ self.products→exists(p | p.available),
self.products→forAll(p | p.available) ]
  • Uncertain integer expressions: When describing uncertain integer expressions it is possible to specify ranges of values using the syntax lower-bound..upper-bound, where the lower and upper bounds are defined as integer constants.
context User inv Adult:
self.age >= [ 18..21 ]
  • Labels: It is possible to assign a label to one or more of the alternative values. Labels specify uncertainty points that are related among them: selecting a label in one alternative forces us to select it in all other alternatives if possible.
context User inv Adult:
self.age >= [ *EU* 18, *USA* 21 ]
context User::gdprRequired(): Boolean
post consent:
result = [ *EU* true, *USA* false ]
  • Unknowns: Part of a OCL expression can be currently unknown during design time. We denote this fact with the unknown keyword.
context User::borrow(b: Book)
pre: self.pendingBooks.size() < self.quota
and self.lateBooks→isEmpty()
and self.damagedBooks = 0
and unknown
post: self.pendingBooks.includes(b)

Several existing tools provide facilities to analyze, test, validate or verify OCL constraints included in UML models. Nevertheless, such tools do not support uncertain OCL expressions. In the following, we describe how we can leverage existing tools in order to analyze uncertain OCL models. In this way, it may be possible to detect problems such as unsatisfiable OCL constraints or inconsistencies between OCL constraints early on, i.e., even when some of these constraints are still uncertain. Two alternate methods can be used to achieve this goal:

  • Exact method: This methods enables the generation of all the potential concrete variants for uncertain OCL constraints. To do this, starting from the innermost uncertain OCL subexpression, we generate a copy of the OCL constraint that takes each alternative as its value. Each copy is a concrete OCL expression with no uncertainty that can be checked using existing tools with no adaptations required. Constraints including unknowns will be excluded from this concretization. A problem of this method is the combinatorial explosion in the number of variants.
context User inv Adult_A: self.age >= 18
context User inv Adult_B: self.age >= 19
context User inv Adult_C: self.age >= 20
context User inv Adult_D: self.age >= 21
  • Approximate method: In order to improve the efficiency of the analysis of uncertain OCL constraints, we can reduce the number of variants being generated by aggregating the set of all potential alternative values. This aggregation can be more or less restrictive than the values it is approximating, e.g., in the case of several integer expressions, we make take the minimum or maximum of all alternatives. As a trade-off, this approach may produce false negatives: it may detect some errors, but it will be unable to detect all of them.
context User inv Adult_MIN: self.age >= 18
context User inv Adult_MAX: self.age >= 21

We have implemented a tool, available in GitHub, to implement the exact method: given an uncertain OCL specification, it generates the list of all potential concretizations. The tool is implemented in Java, using JFlex and CUP for creating the uncertain OCL parser. It supports features such as nested uncertain expressions. This type of tool facilitates detecting faults even in the presence of uncertain constraints, as it is still possible to use all UML/OCL tools for verification and validation.

Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This