[uml] Rationalize / provide an eager OCL Standard Library initialization

[eclipse-ocl-bot]

| --- | --- |
| Bugzilla Link | 583536 |
| Status | NEW |
| Importance | P3 normal |
| Reported | Aug 29, 2024 03:35 EDT |
| Modified | Aug 29, 2024 04:11 EDT |
| See also | 582625 |
| Reporter | Ed Willink |

Description

Bug 582625 ensured that EcoreOCLStandardLibrary provided a fully initialized library avoiding some problems with QVTo concurrency.

Attempting to provide the corrersponding functionality in UMLOCLStandardLibrary failed and identified many smells.

a) In practice the Ecore OCLStandardLibrary always shortcuts to build() the built-in implementation. The corresponding shortcuts are missing from UML support so the dyanmically loaded library is always used, unless an exception is thrown provoking a fallback to the built-in.

Surely the UML support should also default to built-in?

b) There are no tests of the configuration of a custom library, so significant init code lacks test coverage.

c) Attempting to test the 'better' UMLOCLStandardLibrary identifies that

• more EClassifiers are created than expected
• 'same' EClassifiers may have varying operation counts
• multiple 'same' operations are in referenced

(It looks as if the UML TypeResolver is buggy.)

---

The better EcoreOCLStandardLibrary was an enhancement to aid the not-supported concurrency in QVTo. It was not a necessary bug fix.

The correspondingly better UMLOCLStandardLibrary is a tidy/courteous enhancement with no known user requirement. Indeed it is not clear that UMLOCLStandardLibrary has ever been used.

---

It is not even clear that there are any users of the UML binding at all; it was added to support IBM requirements at a time when IBM were moving on from modeling.

Therefore investigating the smells identified by this work is not justified without a user requirement.

[eclipse-ocl-bot]

By Ed Willink on Aug 29, 2024 04:11

WIP on smells / testing pushed to archive/583536