Although the Object Constraint Language (OCL) was significantly influenced by functional programming languages, most of its interpreters are based on the object-oriented paradigm, providing direct representation for model-oriented features like inheritance. In previous works, we introduced a Haskell-based sandbox providing a functional interpretation of OCL invariants. In this paper, we use this sandbox for experimenting with functional features proposed in the literature for OCL, showing the benefits of a functional interpretation and its limitations.
The Object Constraint Language (OCL, [
In previous works [
In this paper, we discuss advances in the experimentation with functional features proposed by the scientific community. We focus on OCL as an embedded domain-specific language (EDSL) in Haskell, to open the language to the functional programming community, to experiment with it. This means that we describe how OCL interpretation benefits from such an encoding and its corresponding limitations, neither focusing on proposing new features to the language itself nor on making any comparison at the level of technological support for it.
The rest of this paper is organized as follows. In Section 2 we introduce basic aspects of the functional paradigm used in the rest of the article, and in Section 3 we briefly present the sandbox and the functional encoding of OCL. In Section 4 we use this encoding to evaluate the main advanced features we have identified, and in Section 5, we complement the analysis with other features and open issues. Finally, in Section 6 we present some conclusions and ideas for future work. 2
Haskell [
Our sandbox provides a Haskell-based interpretation for OCL [
The output Haskell file is available to experiment directly with it, and since OCL is defined as an EDSL, in this work we focus on the Haskell encoding, its potential, and limitations. In this context, Eclipse OCL is used only as a reference of value for the community in terms of coverage of basic language constructions. In what follows we present the basics of the OCL functional encoding. 3.1
Each class of a metamodel is represented as a Haskell datatype with a constructor resulting from the translation of their properties (attributes and associations). The primitive type of an attribute is represented with its corresponding Haskell type, and associations are represented with an Int parameter (or list of integers) identifying the referenced elements. If a Class has subclasses, a field of type ClassChild is added, defining one constructor (ClassCh) for each subclass (Class) with its corresponding type. For non-abstract classes this field is wrapped with a Maybe type. We also define a class ModelElement, which is the superclass of all the orphan classes, defining a unique identifier other elements can refer to. A model is thus represented as a list of ModelElement values.
The metamodel depicted in Figure 1 (from [
We defined OCL m a, a Reader monad representing computations in a shared environment of type m (the model), that returns a value a with respect to the OCL four-valued logic with the notion of truth, undefinedness and nullity. type OCL m a = Reader m a data Val a = Null | Inv | Val a
A sequence of computations describes the navigation through properties and functions, and the shared environment (which is the model itself) can be used by the computations to look up the elements referred by others. We defined specialized versions of bind (>>=) for better representing the object navigation operator (|.|) and the collection navigation operator (|->|). Primitive types and collection types have their corresponding Haskell representation. Collection operators were defined in terms of iterate which is almost directly translated to the fold recursion scheme in Haskell (a monadic version of it), e.g., iterate : : (Val b −> Val a −> OCL m (Val b)) −> Val b −> Val [ Val a ] −> OCL m (Val b) iterate f b = pureOCL (foldM f b) pureOCL f (Val x) = f x pureOCL _ Inv = oclInv pureOCL _ Null = oclNull
A function context defines a boolean computation that verifies a list of invariants in a given context (self): context : : (OCLModel m e , Cast m e a)
=> Val a −> [ Val a −> OCL m (Val Bool ) ] −> OCL m (Val Bool) context self invs = ocl self |.| allInstances |->| forAll (mapInvs invs) data ModelElement = ModelElement Int ModelElementChild data ModelElementChild = PersonCh Person | . . . data Person = Person String Int String String (Maybe PersonCh) data PersonCh = TeammemberCh Teammember data Teammember = Teammember String [ Int ] [ Int ] [ Int ] . . . name : : Cast Model Person_ a => Val a −> OCL Model (Val String) name a = upCast _Person a >>= pureOCL (\(Person x _ _ _ _) −> return (Val x))
In Figure 3 there is an OCL invariant and its Haskell OCL version. It specifies that a team meeting has to be organized for a whole team. −− context Teammeeting inv : −− self . participants −> forAll (team = self . for ) invariant = context _TeamMeeting [ inv ] inv self = ocl self |.| participants |->| forAll (\a −> ocl a |.| team |==| ocl self |.| for)
Some type classes of our library provide functions to navigate through models, and instances of such classes have to be provided for any data type representing a model element within a given metamodel. Boilerplate code is defined to navigate through a model uniformly, e.g., to implement the oclAsType operation.
As summarized in Table 1, our Haskell OCL proposal currently provides an almost complete representation of OCL for invariants and queries. We take Eclipse Oxygen OCL 6.3 as a reference and use a semaphore-like notation, where: green, yellow and red means that the OCL aspect is fully, partially or not supported, respectively. Eclipse OCL supports parsing of other OCL aspects as pre/postconditions but it does not provides any interpretation for them since it is focused on Essential OCL (as we are), which provides the core capabilities for expressing invariants on models. Our biggest limitation is not the support of OCL itself, but the support of other constructs not focused (or not commonly used) on metamodels, e.g., operations on types and association classes.
The functional paradigm provides a purely functional, declarative and concurrent
programming environment with static typing and type inference. These features
are strongly connected with the OCL language. In what follows we analyze three
main functional features proposed to be incorporated into OCL.
a Syntactic sugar, can be easily supported.
b Association classes and qualified associations are not supported.
c Not defined, but its operations are implemented for any type; oclIsInState,
oclIsNew, oclType are not supported (only the last one in Eclipse OCL).
d Not defined as a type, but undefined considered as a value during evaluation.
e flatten, sortedBy and collectNested are not supported.
Functions are first-class citizens in Haskell. It allows higher-order functions
taking other functions as arguments or return types. OCL defines something like
functions (e.g., when defining a let expression) with some restrictions since it
is not possible to define higher-order functions, except in the case of collection
operations. In [
in ocl self |.| isConfirmed |==>| noConflict −− context Meeting inv : −− let priority (Set(Teammember)) : Teammember = . . . , −− getModerator(m:Meeting, p:( Set(Teammember) −> Teammember)) : Teammember −− = p(m. participants) −− in self .moderator = getModerator( self , priority ) invariant = context _Meeting [ inv ] inv self = let priority = . . .
getModerator m p = p (m |.| participants) in ocl self |.| moderator |==| getModerator (ocl self) priority
We can also support higher-order functions, e.g., iterate in Section 3, which is defined as a higher-order function based on foldM. Assume, by abuse of notation, that OCL can express the second invariant in Figure 4, stating that the moderator is the one with highest priority. In such case, we can define a function priority for selecting the member with highest priority, and a higher-order function getModerator that takes a Meeting, a priority function and returns a Teammember. This representation is nowadays supported in our sandbox.
Even though the use of functions benefits OCL, there are some problematic aspects. For example, the function flatten, which returns a collection containing all elements of self recursively flattened, is not easily supported when there is more than one level of recursion, or there are elements in the collection with a different type. A recursive definition of this function can be defined with type flatten :: Collection (Collection a) −> Collection b. However, it has a typing problem since it is not possible to define a generic relation between types a and b. To find a solution, we need to add more information within the representation of metamodels and to generate boilerplate code, which deserves further analysis. A derivation of this problem is that since the operation collect is based on flatten, we provided a limited version in which the OCL expression is applied to every element in the collection but not recursively on collections of collections. 4.2
Lazy evaluation is Haskell’s default evaluation strategy. Since lazy functions
do not evaluate their arguments until their values are needed, lazy evaluation
for OCL [
Although laziness can improve performance, it also adds memory overhead
since the compiler has to record the expression in the heap in case it is evaluated
later. Haskell provides strictness analysis and explicit strict evaluation features,
which may improve this aspect. Further studies are required in this way.
OCL pattern matching [
Inspired by the syntax in [
(oclVal t |==| oclVal ”Engineer”) )) <||> (caseOCL (_Person <::> age <:> title <=> ”Engineer” <:> NilP) (\(a , ( ) ) −> oclVal a |>| oclInt 22)) <||> (caseOCL (_Person <::> age <:> NilP) (\(a , ( ) ) −> oclVal a |>| oclInt 18)) )
The implementation of the whole pattern matching mechanism is very simple. We first define a couple of datatypes to represent patterns: data Pattern m e p as where
Pattern : : Val p −> PList m e p as −> Pattern m e p as data PList m e p as where
NilP : : PList m e p () VarP : : (Cast m e p => Val e −> OCL m (Val a)) −> PList m e p as −> PList m e p (a , as) LitP : : Eq a => (Cast m e p => Val e −> OCL m (Val a)) −> a
−> PList m e p as −> PList m e p as The combinators <::>, <:> and <=> used in Figure 6 are just smart constructors of such types. For example, the first pattern is equivalent to: (Pattern _Teammember (VarP age (LitP role ”Chief” (VarP title NilP ))))
A pattern consists of a reference to a class (Val p) and a list of sub-patterns referring to the attributes of the class. A sub-pattern can bind the matched element to a variable (VarP) or compare it to a literal (LitP). We could have defined sub-patterns recursively as patterns, but for simplicity we decided to have only two-level patterns. Notice that the as index of the types is increased every time a VarP is included, constructing a nested cartesian product, that ends with () at NilP (e.g., the type as for our example pattern is (Int ,( String ,())) ). The first parameter of both VarP and LitP is a function that knows how to extract some information from an element representing a class e that can be casted to the referenced class p. Thus, age, role and title in Figure 6 are attribute accessor functions defined in the same way we defined name in Figure 2.
The function caseOCL implements a case branch. It takes a pattern p, a function f that takes the values bound by the pattern and returns an OCL computation (with a value of type Val a), and the value self to inspect, and returns the OCL computation. It basically evaluates the pattern to produce the cartesian product needed to apply to the function f. If the pattern fails it results in Inv. caseOCL : : Cast m e p => Pattern m e p as −> (as −> OCL m (Val a)) −> Val e −> OCL m (Val a) caseOCL p f self = evalPattern p self >>= pureOCL f
Pattern evaluation needs to downcast the given element to the class the pattern refers. If it succeed, we go through the list of sub-patterns, applying the access function to the elements and constructing the cartesian product in the case of VarP, or checking the match in the case of LitP (returning Inv if it fails). evalPattern : : Cast m e p => Pattern m e p as −> Val e −> OCL m (Val as) evalPattern (Pattern p plist) e = do p ’ <− downCast p e case p ’ of Inv −> return Inv _ −> evalPList plist e evalPList : : Cast m e p => PList m e p as −> Val e −> OCL m (Val as) evalPList NilP _ = return $ Val () evalPList (VarP f ps) e = f e >>= pureOCL (\x −> evalPList ps e >>= pureOCL (\xs −> return (Val (x , xs)))) evalPList (LitP f l ps) e = f e >>= pureOCL (\x −> if x == l then evalPList ps e else return Inv) 5
Packages and Package Invariants. Haskell already provides modules for
packaging definitions and the use of qualified names. In Figure 7 there is a
module UML defining the metamodel and there is a qualified import for expressing
invariants in another module OCL. Moreover, in [
Safe Navigation. The existence of the null object is troublesome since it
introduces potential navigation failures. Safe navigation is proposed in [
By exploiting monads, we can get other interesting features. In [
if res |==| oclVal True then return res else throwError ”There was an error” Operations & Pre/postconditions. The navigation language we provide can be used to the derivation of properties in terms of other properties or the specification of the body of an operation that does not change the state of the system. In Figure 9 there is an example of a derived property (size) whose value (the size of the team) is computed when needed, and the body of an operation (getMeetingTitles) which returns the titles of the meetings that a team member attends. Both aspects can be currently supported as any other property introduced in Section 3. Pre/postconditions support rely on the same settings but with some additional features. In particular, we must consider a pair or pre and post models where the pre/postconditions of an operation specification must hold. As an example, take the pre/postconditions of the operation shift in Figure 9. Supporting preconditions is straightforward, since they are invariants that must hold in the pre model. In the case of a postcondition, it is also an invariant check, but we need to define a new context in which we can shift from one model to another by using a function atPre in order to get the value of any expression marked with @pre from the pre model. The example in this last case is just explanatory since it requires further development. 6
In this paper, we discussed advances in the experimentation with functional features proposed for OCL and provided a different perspective on the interpretation of OCL as a Haskell EDSL. −− context Team: : size : Integer −− derive : members−>size () size : : Cast Model Team_ a => Val a −> OCL Model (Val Int) size self = (ocl self) |.| members |->| size −− context Teammember: : getMeetingTitles ():Bag(String) −− body: meetings−>collect ( title ) −− context Meeting : : shift (d: Integer) −− pre : self . isConfirmed = false and d > 0 −− post : start = start@pre + d and end = end@pre + d context _Teammeeting [ inv ] inv self d = (((ocl self) |.| isConfirmed) |==| (oclVal False)) |&&| ((oclInt d) |>| (oclInt 0)) post self d = (((ocl self) |.| start)) |==|
(ocl self) |.| atPre start) |+| (oclInt d)) |&&| (((ocl self) |.| end)) |==| (ocl self) |.| atPre end) |+| (oclInt d))
Hierarchical typing and identities introduce the main mismatch problems. Once some functional boilerplate is generated to take care of this, the resulting expressions and their interpretation are more modular, abstract and extensible. Nevertheless, there are still some challenges, e.g., the definition of recursive multi-typed collection operators and reflection capabilities, as with other open issues, as discussed in Section 5, that require further studies.
To our knowledge, the most related work to ours is Sigma [
Considering that in some cases OCL could be benefited from the introduction of some kind of controlled side effects, e.g., for expressing error messages, an interesting research line could be to analyze how to define a modular effects mechanism for OCL, e.g., inspired by monads and monad transformers.
As a complementary perspective, we are currently addressing a benchmark comparison between Haskell OCL and Eclipse OCL, dealing with performance concerns (time and memory) on some (larger) real-world examples.
This work was partially funded by Fondo Carlos Vaz Ferreira 2017, Direcci´on de Innovaci´on, Ciencia y Tecnolog´ıa (DICYT), MEC, Uruguay.