Shadow objects allow OCL to return constructed objects without side effects by treating them as immutable pre-existing objects, even if constructed multiple times. Shadow objects exist in a separate "shadow model" and cannot be contained, referenced, or mutated in the user model. They must be cloned to regular objects before being added to the user model to avoid side effects.

1. Made available under EPL 2.0
Shadow Objects
Edward D. Willink
Willink Transformations Ltd
Eclipse Foundation
MMT Component co-Lead
OCL Project Lead
QVTd Project Lead
QVTo Committer
OMG (Model Driven Solutions)
OCL 2.3, 2.4, 2.5 RTF Chair
QVT 1.2, 1.3, 1.4 RTF Chair
OCL 2018 @ MODELS 2018
14th October 2018

2. 14 October 2018 Shadow Objects 2Made available under EPL 2.0
Why can't I create an object in OCL?
Object creation has a side effect in the memory
OCL evaluation is side effect free

3. 14 October 2018 Shadow Objects 3Made available under EPL 2.0
Solution
OCL §8.3.8 'solution'
declare as post conditions of a 'make' function
context Parameter::make(n : String, c : Classifier,
k : ParameterDirectionKind) :Parameter
post: result.name = n
post: result.kind = k
post: result.type = c
idiomatic, ugly
Type construction
Tuple literal syntax re-use
Parameter{name = n, kind = k, type = c}
Regular OCL expression

4. 14 October 2018 Shadow Objects 4Made available under EPL 2.0
Memory side effect
Evaluate
uml::State { name : String = 'me' } =
uml::State { name : String = 'me' }
true / false
NB LHS, RHS may be arbitrary query returns
cf Java
1 = 1; // true
new Integer(1) = new Integer(1); // false
"new" allocates memory
two identical objects at different addresses
OCL must be side effect free
identical (re-)constructions must be equal
not regular objects

5. 14 October 2018 Shadow Objects 5Made available under EPL 2.0
Shadow Objects
cf Integers
all Integers exist
programs use only some Integers
Shadow Objects
all possible Shadow Objects exist
pre-existing Shadow Object returned by constructor
shared, therefore equal
re-used, therefore no side effect
immutable
practical implementation lazily creates on first use
IMMUTABLE LAZY 'PRE-EXISTING'

6. 14 October 2018 Shadow Objects 6Made available under EPL 2.0
Shadow Relationships
container always null
cannot be (multiply-) contained
by a user model
root shadow object may contain
regular objects
can only reference shadow
objects/children
cannot be referenced from
user models
no piecemeal bidirectionals
atomic construction only
can share datatype values
shadow 'model'
forest of isolated object trees
User Model
Root
A B
C
Shadow 'Model'
X Y
Y
null null
'me'

7. 14 October 2018 Shadow Objects 7Made available under EPL 2.0
Shadow Objects in use
shadow object OCL expression unuseable
cannot be contained or bidirectionally referenced
let aNode = Node{containedNode = Node{}} in -- ok
Node{containedNode = aNode} -- bad/clone
OCL use as a child / QVT assignment to container
must clone 'contained' shadow object as regular object
QVT assignment to reference
illegal
must use a clone already assigned to a container
(practical implementation may use shadow as the
clone if shadow no longer referenced.)

8. 14 October 2018 Shadow Objects 8Made available under EPL 2.0
Summary
regular object construction
not side-effect-free
shadow object construction
allows OCL to return an object / object pattern
RHS of a model to model transformation
shadow object cloning
accommodates side-effects
executable semantics for OCL §8.3.8
context Parameter::make(n : String, c : Classifier,
k : ParameterDirectionKind) :Parameter
post: result.name = n
post: result.kind = k
post: result.type = c