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
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 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"
-
Field Summary
-
Method Summary
Modifier and TypeMethodDescriptionReturns the value of the 'Predecessor Abstract Action' reference.Returns the value of the 'Resource Demanding Behaviour Abstract Action' container reference.Returns the value of the 'Successor Abstract Action' reference.void
Sets the value of the 'Predecessor Abstract Action
' reference.void
Sets the value of the 'Resource Demanding Behaviour Abstract Action
' container reference.void
Sets the value of the 'Successor Abstract Action
' reference.Methods inherited from interface org.eclipse.emf.cdo.CDOObject
cdoConflict, cdoDirectResource, cdoHistory, cdoID, cdoInvalid, cdoLockState, cdoPermission, cdoPrefetch, cdoReadLock, cdoReload, cdoResource, cdoRevision, cdoRevision, cdoState, cdoView, cdoWriteLock, cdoWriteOption
Methods inherited from interface org.eclipse.emf.ecore.EObject
eAllContents, eClass, eContainer, eContainingFeature, eContainmentFeature, eContents, eCrossReferences, eGet, eGet, eInvoke, eIsProxy, eIsSet, eResource, eSet, eUnset
Methods inherited from interface de.uka.ipd.sdq.identifier.Identifier
getId, setId
Methods inherited from interface org.palladiosimulator.pcm.core.entity.NamedElement
getEntityName, setEntityName
Methods inherited from interface org.eclipse.emf.common.notify.Notifier
eAdapters, eDeliver, eNotify, eSetDeliver
-
Field Details
-
copyright
- See Also:
- Generated class or method.
-
-
Method Details
-
getPredecessor_AbstractAction
AbstractAction getPredecessor_AbstractAction()Returns the value of the 'Predecessor Abstract Action' reference. It is bidirectional and its opposite is 'Successor Abstract Action
'.- Returns:
- the value of the 'Predecessor Abstract Action' reference.
- See Also:
- Generated class or method.
- EMF model class or method.
- opposite="successor_AbstractAction" ordered="false"
-
setPredecessor_AbstractAction
Sets the value of the 'Predecessor Abstract Action
' reference.- Parameters:
value
- the new value of the 'Predecessor Abstract Action' reference.- See Also:
- Generated class or method.
-
getSuccessor_AbstractAction
AbstractAction getSuccessor_AbstractAction()Returns the value of the 'Successor Abstract Action' reference. It is bidirectional and its opposite is 'Predecessor Abstract Action
'.- Returns:
- the value of the 'Successor Abstract Action' reference.
- See Also:
- Generated class or method.
- EMF model class or method.
- opposite="predecessor_AbstractAction" ordered="false"
-
setSuccessor_AbstractAction
Sets the value of the 'Successor Abstract Action
' reference.- Parameters:
value
- the new value of the 'Successor Abstract Action' reference.- See Also:
- Generated class or method.
-
getResourceDemandingBehaviour_AbstractAction
ResourceDemandingBehaviour getResourceDemandingBehaviour_AbstractAction()Returns the value of the 'Resource Demanding Behaviour Abstract Action' container reference. It is bidirectional and its opposite is 'Steps Behaviour
'.- Returns:
- the value of the 'Resource Demanding Behaviour Abstract Action' container reference.
- See Also:
- Generated class or method.
- EMF model class or method.
- opposite="steps_Behaviour" transient="false" ordered="false"
-
setResourceDemandingBehaviour_AbstractAction
Sets the value of the 'Resource Demanding Behaviour Abstract Action
' container reference.- Parameters:
value
- the new value of the 'Resource Demanding Behaviour Abstract Action' container reference.- See Also:
- Generated class or method.
-