public class VariableTracebackStep extends BranchingTracebackStep<VariableExp>
OCLExpression
as their scope. For example, a let-variable has the
in
expression as its static scope. Additionally, scopes are dynamically instantiated during
expression evaluation. For example, during evaluation of an IterateExp
, the body expression forms the static scope
for the result variable
. During each iteration, a new dynamic scope is created and the same
static result variable may have a different value in each dynamic scope. It is important to understand that the traceback
step learns about the value of the variable only in one particular dynamic scope.
AbstractTracebackStep.TracebackStepAndScopeChange, AbstractTracebackStep.TracebackStepAndScopeChangeWithOperationCallExp
oclFactory, provenUnused, requiredType, tracebackExecutions
Constructor and Description |
---|
VariableTracebackStep(VariableExp sourceExpression,
org.eclipse.emf.ecore.EClass context,
OperationBodyToCallMapper operationBodyToCallMapper,
java.util.Stack<java.lang.String> tupleLiteralNamesToLookFor,
TracebackStepCache tracebackStepCache,
UnusedEvaluationRequestFactory unusedEvaluationRequestFactory,
OCLFactory oclFactory) |
Modifier and Type | Method and Description |
---|---|
protected OCLExpression |
getRootExpression(OCLExpression e)
There are a few known idiosyncrasies in the OCL "composition" hierarchy.
|
protected OperationCallExpKeyedSet |
performSubsequentTraceback(AnnotatedEObject source,
UnusedEvaluationRequestSet pendingUnusedEvalRequests,
TracebackCache tracebackCache,
org.eclipse.emf.common.notify.Notification changeEvent)
This method is used to invoke the
TracebackStep.traceback(AnnotatedEObject, UnusedEvaluationRequestSet, TracebackCache, Notification) method on all necessary subsequent TracebackStep s and return their results. |
getSteps
annotate, annotateEObject, annotateEObject, cloneWithTypeCheck, createTracebackStepAndScopeChange, createTracebackStepAndScopeChange, getAllVariablesInScope, getExpression, getInnermostClass, getInnermostElementType, getInnermostTypeConsideringTupleLiteralsLookedFor, getOppositeEndFinder, getVariablesScopedByExpression, traceback
public VariableTracebackStep(VariableExp sourceExpression, org.eclipse.emf.ecore.EClass context, OperationBodyToCallMapper operationBodyToCallMapper, java.util.Stack<java.lang.String> tupleLiteralNamesToLookFor, TracebackStepCache tracebackStepCache, UnusedEvaluationRequestFactory unusedEvaluationRequestFactory, OCLFactory oclFactory)
protected OperationCallExpKeyedSet performSubsequentTraceback(AnnotatedEObject source, UnusedEvaluationRequestSet pendingUnusedEvalRequests, TracebackCache tracebackCache, org.eclipse.emf.common.notify.Notification changeEvent)
AbstractTracebackStep
TracebackStep.traceback(AnnotatedEObject, UnusedEvaluationRequestSet, TracebackCache, Notification)
method on all necessary subsequent TracebackStep
s and return their results.
Which subsequent steps are necessary depends on the respective source
OCLExpression
the TracebackStep
was created for.performSubsequentTraceback
in class BranchingTracebackStep<VariableExp>
protected OCLExpression getRootExpression(OCLExpression e)
TupleLiteralExp
does not contain its
tuple parts
which are variable declarations, a CollectionLiteralExp
does not
contain its parts
, and of those parts, none of CollectionRange
nor
CollectionItem
contains the expressions that it uses to describe itself.
We still need to be able to determine the scope of, e.g., self or operation parameters and therefore need to ascend what may be called the "logical composition hierarchy" of an OCL expression. Therefore, this operation ascends the real composition hierarchy until it finds a null parent or a parent of type constraint or EAnnotation. In this case, it tries the aforementioned "logical compositions" one after the other. If for one such association another element is found, ascending continues there.