The 19th edition of the OCL workshop featured a lightning talk session where authors were invited to present their recent work and open questions related to textual modeling in general and OCL in particular. These 5 minute presentations triggered fruitful discussions within the OCL community on the usage of textual modeling, model validation, and specific technical points of the OCL specification. This community paper provides an overview of the presented contributions (one per section), as well as a summary of the questions and discussions they have triggered during the session.
Textual modeling in general and OCL in particular is a well-established but still active field of research. The OCL standard, which was first released in 1997, has been continuously enriched since then, and is now the cornerstone of several model querying, verification, and transformation approaches. Current work on textual modeling covers its foundation (e. g., the formal semantics of textual modeling languages) to its usage in cutting edge applications like database querying, or AI specification.
The lightning talk session of the 19th edition of the OCL workshop was animated by three experts of the field. They presented their ongoing work on the usage of textual modeling with respect to graphical modeling, discussed specific constructs of the OCL language, and introduced optimization strategies for model verification.
The following sections are contributed by these experts. They summarize both their recent works and the related discussions that took place during the workshop. 2
Tweaking Class Model Validation with Specialized Association Bounds
Martin Gogolla
In the context of validating and verifying UML and OCL class models, we have
developed a so-called model validator [
The requirements on the instantiations, i. e., the objects diagrams, can be summarized as follows: Plain associations are interpreted by plain, directed graphs having no particular restrictions, aggregations yield acyclic graphs (socalled dags, i. e., directed, acyclic graphs), and compositions end up in graphs with tree-like structures. Fig. 1 states an overview and an example. With respect to the number of upper bound of links in associations, aggregations, and compositions the requirements imply the following upper bounds. We assume the simple case that we consider one class with one association, one aggregation and one composition defined on the class in a reflexive manner. Furthermore we assume that n objects are present in the considered class. The specialized association bounds can be stated as follows: At most n ∗ n links are allowed in the case of association, at most (n − 1) ∗ (n − 2)/2 links in the case of aggregation, and at most n − 1 links in the case of composition.
An OCL Map Type
Edward D. Willink OCL’s family of Collection types is well known, but a Map(K,V) type is missing. Some distinguished authors have suggested that the deficiency can be remedied by a Set(Tuple(K, V)), but this is clearly misguided since a Set(Tuple) can have many different-valued entries for the same key, whereas a map can only have one value per key.
The Java Map type is very familiar and might perhaps inspire an equally familiar library type for OCL, but this too is misguided since a Java Map is mutable while an OCL Map should be immutable.
The ordered Collections are therefore a better source of inspiration. The following have obvious functionality: =, <>, isEmpty(), notEmpty(), size().
New keys() and values() operations can access the two halves of the map. Similarly obvious functionality with respect to the keys can be provided by: excludes(k), excludesAll(c), excluding(k), excludingAll(c), includes(k), includesAll(c)
Further emulation of ordered Collections suggests that at(k) accesses the map at index k. including(k,v) creates a new map with an additional or replacement k<-v binding. It returns null for a null value and invalid for a missing value.
Richer support can be provided by: excludesMap(m), excludesValue(v), excludingMap(m), includesMap(m), includesValue(v), includingMap(m)
Construction of a Map literal can re-use the Tuple literal syntax in conjunction with a new binding operator <-. Thus a map literal with two entries for two value to key bindings my be created by:
Map{k1<-v1, k2<-v2}
The above facilities were prototyped in Eclipse OCL 2015-06. They provide an adequate ability to use a Map but prove very inefficient for Map construction since creating a Map with N entries requires progressive construction of N-1 intermediate maps; the execution performance is therefore at best quadratic. The Eclipse OCL 2019-03 release therefore extends the create/operation Map functionality with iteration support.
A Map is treated as a set of keys each with a bound co-value. All the standard Collection iterations apply to Maps using the set of keys as the iteration domain. Additionally a co-iterator may be bound to the iterator to avoid the need to invoke at(k) to obtain the value of each key. Thus a map can be checked to ensure that each v bound to its k iterator is equal to the squared value of the iterator.
let c : Map(Integer, Real) = ... in c->forAll(k<-v | v = k*k) A new collectBy iterator, that may be used on Collections or Maps, supports creation of a Map by collecting an expression value for each iterator key. A map from ten integer values to their squares may be built by:
Sequence{1..10}->collectBy(k | k*k)
Future work might generalize k<-v from special purpose punctuation to an expression operator. The downside of this generalization is the cost/complexity of a new Entry(K,V) type for the new expression result and of course many new operations to allow an Entry type to be used sensibly. The upside is that the collectBy body may use let variables and may compute both key and value. A map that binds an integer value to its string value could be built by: Sequence{1..10}->collectBy(k | k.toString()<-k)
A consequence of permitting both key and value to be computed, is that, in general, uniqueness of the key values cannot be guaranteed. To avoid nondeterministic loss of colliding values, the Map parameterization would need to be a multimap: Map(K,Bag(V)). 4
Some Guidelines About When to Use Textual And/Or Graphical Modelling in MBSE
Christophe Ponsard and Valéry Ramon
Model-based systems engineering (MBSE) is the application of modelling
techniques throughout the whole system development lifecycle to support system
requirements, specification, design, verification and validation activities [
Textual and graphical modelling languages can also be combined and
complement each other. Indeed, textual model elements may appear in graphical-based
languages for stating precise properties (e. g. OCL constraints in UML class
diagrams, formal layer of KAOS [
Although textual and graphical notations may capture the same information,
one modality might be more adapted to some context modelling related activities
involving both humans and tool chains. We give here a synthetic comparison of
the benefits of both kinds of notations according to relevant factors such as
analysability, learning curve or scalability. Our work is based on both a review
of results from some empirical studies [
The following comments and lessons learned can be summarised from Table 1.
a Accuracy : textual is better according to the study of [
In conclusion, the above evidence gives some hint about the respective benefits of textual and graphical modalities in MBSE. However, they are not yet strong enough, given the small number of the empirical studies as well as their simplified models and engineering tasks not necessarily realistic from a real-world perspective. Our plan is to enrich this comparison based on MBSE on-going and future deployments, in connection with a more systematic literature survey.