eclipse-ocl-bot
commented
3 weeks ago By Ed Willink on Jun 23, 2017 10:06
(In reply to Ed Willink from comment #0)
Currently the CompleteInheritance incorrectly has Sequence
conforms to Collection .
Attempting to correct this runs into problems with loss of nullability for superclasses.
Probably need to fix Bug 518709 first.
| --- | --- | | Bugzilla Link | 518573 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 21, 2017 08:33 EDT | | Modified | Aug 02, 2017 03:56 EDT | | Depends on | 520440, 518709 | | Blocks | 492801 | | Reporter | Ed Willink |
Description
This bug reviews the design principles underpinning Bug 492801.
Naively, specialization is a macro mechanism that supports synthesis of a family of unrelated types from a common generalization. Full synthesis can result in a very bloated XMI rendering. Inadequate synthesis incurs run-time complexity.
Inheritance:
Does Sequence conformTo Collection ?
No. Sequence, Sequence and Sequence are independent types.\
Sequence conformsTo Collection conformsTo OclAny.
Sequence is statically convertible to Sequence (and so to Collection). This may be an explicit oclAsType() or an implicit conversion to facilitate operation argument return type compatibility.
Sequence is dynamically convertible to Sequence by an explicit oclAsType().
Currently the CompleteInheritance incorrectly has Sequence conforms to Collection.
Operations:
Currently nearly all specialized operations are library operations whose Java implementation works satisfactorily wrt the unspecialized type. Operation specialization has therefore been ignored except that the return type of an OperationCallExp is specialized; arguments are converted. OperationCallExp.referredOperation is the unspecialized Operation.
This seems appropriate. If we interpret "referredOperation" as the declared capability, specialization is not necessary. Conversely if library operations are specialized, the orphanage bloats with some (? all) operations for each specialized type. Multiple models then gives multiple specializations to merge.
But if an operation is OCL-defined, its body may involve specialized types and so must be specialized prior to/during evaluation. Automated specialization in XMI seems like bloat; only a manual redefinition (is this supported?) needs XMI serialization.
The current operation lookup skips to the unspecialized type too quickly. It should lookup in the specialization so that necessary specializations occur on demand. Unnecessary specializations redirect to the unspecialized.
Properties/Constraints:
Similar principles can apply to all 'features'; it is just Constraints that are more prone to use of OCL-defined bodies that must be specialized.