de.uka.ipd.sdq.pcm.seff
Interface AbstractAction

All Superinterfaces:

Entity, Identifier, NamedElement

All Known Subinterfaces:

AbstractInternalControlFlowAction, AbstractLoopAction, AcquireAction, BranchAction, CollectionIteratorAction, DelegatingExternalCallAction, ExternalCallAction, ForkAction, InternalAction, LoopAction, ReleaseAction, SetVariableAction, StartAction, StopAction

All Known Implementing Classes:

AbstractActionImpl, AbstractInternalControlFlowActionImpl, AbstractLoopActionImpl, AcquireActionImpl, BranchActionImpl, CollectionIteratorActionImpl, DelegatingExternalCallActionImpl, ExternalCallActionImpl, ForkActionImpl, InternalActionImpl, LoopActionImpl, 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:

• Predecessor Abstract Action
• Successor Abstract Action

See Also:

SeffPackage.getAbstractAction()

Field Summary

static String

copyright

Method Summary

AbstractAction	getPredecessor_AbstractAction() Returns the value of the 'Predecessor Abstract Action' reference.
AbstractAction	getSuccessor_AbstractAction() Returns the value of the 'Successor Abstract Action' reference.
void	setPredecessor_AbstractAction(AbstractAction value) Sets the value of the 'Predecessor Abstract Action' reference.
void	setSuccessor_AbstractAction(AbstractAction value) Sets the value of the 'Successor Abstract Action' reference.

Methods inherited from interface de.uka.ipd.sdq.identifier.Identifier

getId, idHasToBeUnique, setId

Methods inherited from interface de.uka.ipd.sdq.pcm.core.entity.NamedElement

getEntityName, setEntityName

Field Detail

copyright

static final String copyright

See Also:

Constant Field Values

Method Detail

getPredecessor_AbstractAction

AbstractAction getPredecessor_AbstractAction()

Returns the value of the 'Predecessor Abstract Action' reference. It is bidirectional and its opposite is 'Successor Abstract Action'.

If the meaning of the 'Predecessor Abstract Action' reference isn't clear, there really should be more of a description here...

Returns:

the value of the 'Predecessor Abstract Action' reference.

See Also:

setPredecessor_AbstractAction(AbstractAction), SeffPackage.getAbstractAction_Predecessor_AbstractAction(), getSuccessor_AbstractAction()

setPredecessor_AbstractAction

void setPredecessor_AbstractAction(AbstractAction value)

Sets the value of the 'Predecessor Abstract Action' reference.

Parameters:

value - the new value of the 'Predecessor Abstract Action' reference.

See Also:

getPredecessor_AbstractAction()

getSuccessor_AbstractAction

AbstractAction getSuccessor_AbstractAction()

Returns the value of the 'Successor Abstract Action' reference. It is bidirectional and its opposite is 'Predecessor Abstract Action'.

If the meaning of the 'Successor Abstract Action' reference isn't clear, there really should be more of a description here...

Returns:

the value of the 'Successor Abstract Action' reference.

See Also:

setSuccessor_AbstractAction(AbstractAction), SeffPackage.getAbstractAction_Successor_AbstractAction(), getPredecessor_AbstractAction()

setSuccessor_AbstractAction

void setSuccessor_AbstractAction(AbstractAction value)

Sets the value of the 'Successor Abstract Action' reference.

Parameters:

value - the new value of the 'Successor Abstract Action' reference.

See Also:

getSuccessor_AbstractAction()