search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
1 stars 0 forks source link

[debugger] Support MODEL-derived types in the debugger #1671

Open eclipse-ocl-bot opened 2 months ago

eclipse-ocl-bot commented 2 months ago

| --- | --- | | Bugzilla Link | 487800 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 14, 2016 13:17 EDT | | Modified | Feb 17, 2016 04:59 EDT | | Depends on | 487797 | | Reporter | Ed Willink |

Description

The Bug 400090 fix supports evaluation for a UML InstanceSpecification using InstanceSpecification::classifier rather than 'eClass()' to define the context type.

This should work in the debugger, but it doesn't.

a) the synthetic Complete OCL document doesn't understand how to parse using this type system.

b) the Variables View needs to show model rather than metamodel features.

These appear to be two symptoms that could be solved by generic support for OCL in a user-defined type system.

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Feb 14, 2016 13:29

(In reply to Ed Willink from comment #0)

These appear to be two symptoms that could be solved by generic support for OCL in a user-defined type system.

Potentially something like the old UMLReflection class could provide all the type system services, with a Pivot default using the CompleteModel.

How does the Complete OCL editor etc know to use a user-defined type system?

? a new Complete OCL declaration pointing at a 'Java class' ?

? an OCL EAnnotation on the EPackage in an Ecore metamodel ?

? a registered capability of a nonstandard user-defined metamodel file ?

? a registered capability of a *.instanceocl file ?

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Feb 14, 2016 14:01

(In reply to Ed Willink from comment #1)

Potentially something like the old UMLReflection class could provide all the type system services, with a Pivot default using the CompleteModel.

No. This misses the whole point of the Pivot model. The XX2AS converter normalizes the external modeling. Needing to change the debugger underlines the failure to use the Pivot correctly.

Perhaps we need a LazyXX2AS and a LazyASResource to avoid converting the whole XX model, particularly those facilities that are not convertible. This could solve the problem with bloated UML concepts such as UseCase that are not in the Pivot model. Re-using the auto-generated CS2AS technology could make this lazy conversion efficient and reliable.(In reply to Ed Willink from comment #1)

How does the Complete OCL editor etc know to use a user-defined type system?

By ensuring that debug_9uAWYCiBEeOgPJa2W3yNiA.ocl importing a synthesized 'UserModel.instanceuml' rather than 'UserModel.uml'

ensuring that InstanceUML2AS rather than UML2AS is used to create the Pivot model.

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Feb 15, 2016 12:31

Bug 487797 makes these problems go away by exploiting multi-classification.

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Feb 17, 2016 04:59

(In reply to Ed Willink from comment #3)

Bug 487797 makes these problems go away by exploiting multi-classification.

Bug 487797#c4 suggests the introduction of oclAsModelType.

The debugger's Variables View should therefore partition the children of $self for each oclTypes() and each oclModelTypes().