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.TracebackStepAndScopeChangeWithOperationCallExpoclFactory, 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, Set, org.eclipse.ocl.examples.impactanalyzer.instanceScope.traceback.TracebackCache, Notification) method on all necessary subsequent TracebackSteps and return their results. |
getStepsannotate, annotateEObject, annotateEObject, cloneWithTypeCheck, createTracebackStepAndScopeChange, createTracebackStepAndScopeChange, getAllVariablesInScope, getExpression, getInnermostClass, getInnermostElementType, getInnermostTypeConsideringTupleLiteralsLookedFor, getOppositeEndFinder, getVariablesScopedByExpression, tracebackpublic 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)
AbstractTracebackStepTracebackStep#traceback(AnnotatedEObject, Set, org.eclipse.ocl.examples.impactanalyzer.instanceScope.traceback.TracebackCache, Notification) method on all necessary subsequent TracebackSteps 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.