Package org.palladiosimulator.pcm.seff

Interface AbstractAction

All Superinterfaces:
org.eclipse.emf.cdo.CDOObject, org.eclipse.emf.cdo.common.id.CDOWithID, Entity, EObject, de.uka.ipd.sdq.identifier.Identifier, NamedElement, Notifier, PCMBaseClass, PCMClass
All Known Subinterfaces:
AbstractInternalControlFlowAction, AbstractLoopAction, AcquireAction, BranchAction, CollectionIteratorAction, EmitEventAction, ExternalCallAction, ForkAction, InternalAction, InternalCallAction, LoopAction, RecoveryAction, ReleaseAction, SetVariableAction, StartAction, StopAction
All Known Implementing Classes:
AbstractActionImpl, AbstractInternalControlFlowActionImpl, AbstractLoopActionImpl, AcquireActionImpl, BranchActionImpl, CollectionIteratorActionImpl, EmitEventActionImpl, ExternalCallActionImpl, ForkActionImpl, InternalActionImpl, InternalCallActionImpl, LoopActionImpl, RecoveryActionImpl, ReleaseActionImpl, SetVariableActionImpl, StartActionImpl, StopActionImpl
public interface AbstractAction extends Entity
A representation of the model object 'Abstract Action'. AbstractActions model either a service's internal computations or calls to external (i.e., required) services, or describe some form of control flow alteration (i.e., branching, loop, or fork). The following first clarifies the notions of internal and external actions, whose meta-classes both inherit from AbstractAction.
The RDSEFF defines the control flow between internal and external actions with the predecessor/successor relationship between AbstractActions to model sequential executions. Additionally, special actions for branching, loops, and forks allow other kinds of control flow. Other than flowcharts or UML activity diagrams, the RDSEFF language (as well as the usage model language) requires developers to make the branching, loop, fork bodies explicit using nested ResourceDemandingBehaviours. It disallows backward references in the chain of AbstractActions, which are basically
goto statements and can lead to ambiguities and difficult maintainability. For example, this might lead to intertwined control flows as in the example in Fig. 4.9(a), where both the sequences 'abcabcdbcd' and 'abcdbcabcd' could be occur if each backward reference is executed once, which might lead to different execution times. Backward references also allow the specification of loops with multiple entry points as in Fig. 4.9(b). This is not desirable, as the number of loop iterations cannot be specified directly in these cases, which is however necessary for accurate performance prediction. If a developer would specify that each backward link in Fig. 4.9(b) is executed only once, both sequences 'ababc' and 'abcababc' would be possible although they would have different execution times, as 'a' is executed three times in the latter case. To avoid such ambiguities, control flow in the PCM RDSEFF and usage model must be specified without backward references in the chain of AbstractActions. Branches, loops, forks, and their respective bodies have to be made explicit in the specification using nested ResourceDemandingBehaviours.

The following features are supported:

See Also:
Generated class or method.
EMF model class or method.
abstract="true"