verbalizing OCL

Tools to "read aloud" a formal specification belong to the basic repertoire of the (Controlled) Natural Language research community. "Reading aloud" more like paraphrasing, e.g.



∀x.Number(x)∧Prime(x)∧LessThan(x,3)⇒Even(x)


can be rewritten into

Every prime number less than 3 is even

A tool along these lines for OCL is OCLNL. Given this OCL as input:

context Copy

inv: Copy.allInstances()->forAll(c1,c2
not (c1=c2) implies not (c1.barCode=c2.barCode))

The verbalization computed by OCLNL is:

for the class Copy the following invariants hold : for all copies c2 , c1 in the set of all instances of Copy if it is not the case that c1 is equal to c2 then this implies that it is not the case that the bar code of c1 is equal to the bar code of c2

OCLNL has been applied to JavaCard APIs (security aspects mostly) and similar real-world case studies. Papers and theses can be found in the OCLNL homepage , the technical doc makes us aware to the fact that the core of OCLNL has been implemented in Haskell (but hey, if you've mastered Java's type system then you've accomplished more than you need to learn Haskell). The input models are not Ecore-based.

One quick way to get your hands dirty in this playground (verbalization of Ecore + OCL models) consists in detecting patterns in OCL Abstract Syntax Trees (ASTs) for which there's an (empirically convenient) English-language paraphrasing. For example, there's one such pattern behind the invariant above, that allows its translation to the more compact:

Two different copies have different bar codes

In a way, that's not playing fair, because covering just some such patterns from all those that may show up in valid OCL ASTs does not get the full job done. Still, it's interesting if you want to try your hand at processing OCL ASTs ... which brings me to the real plunge I wanted to make: take a look at my article on that very subject, How to process OCL Abstract Syntax Trees , and its accompanying Eclipse-based plugin. With it, you can do cool stuff such as:



'nuff said! Actually a big advantage of turning a formal spec into controlled natural language is the larger audience that can review it (and thus find errors). This aspect is highlighted in David Burke's master thesis, an excerpt follows:


May be it's just me, but I think it would be great if someone took up the task of performing similar OCL AST processing for Eclipse!