12.3.5 ActivityEdge

*Generalizations

   •

    RedefinableElement (from Kernel ) on page 132

*Description

    ActivityEdge is an abstract class for the connections along which tokens flow between activity nodes. It covers control and data flow edges. Activity edges can control token flow.

   Package CompleteActivities

   Complete activity edges can be contained in interruptible regions.

*Attributes

   No additional attributes

*Associations

   Package BasicActivities

Issue 8210 -add subsets and redefines constraints to appropriate entries

• activity : Activity[0..1] Activity containing the edge. {Subsets Element::owner}

• /inGroup : ActivityGroup [0..*] Groups containing the edge. Multiplicity specialized to [0..1] for StructuredActivityGroup .

Issue 9089 -rename as ‘redefinedEdge’ and replace Redefines with Subsets

• redefinedEdge: ActivityEdge [0..*] Inherited edges replaced by this edge in a specialization of the activity. {Subsets RedfinableElement::redefinedElement}

• source ActivityNode [1..1] Node from which tokens are taken when they traverse the edge.

• target : ActivityNode [1..1] Node to which tokens are put when they traverse the edge.

   Package IntermediateActivities

• inPartition : Partition [0..*] Partitions containing the edge. {Subsets ActivityEdge ::inGroup}

• guard : ValueSpecification [1..1] = true Specification evaluated at runtime to determine if the edge can be traversed. {Subsets Element::ownedElement}

   Package CompleteStructuredActivities

   • inStructuredNode : StructuredActivityNode [0..1] Structured activity node containing the edge. {Subsets ActivityEdge ::inGroup}

   Package CompleteActivities

   • interrupts : InterruptibleActivityRegion [0..1] Region that the edge can interrupt.

Issue 8919 replace ‘objects’ with ‘tokens’

*Constraints

   [1] The source and target of an edge must be in the same activity as the edge.

   [2] Activity edges may be owned only by activities or groups.

   Package CompleteStructuredActivities

   [1] Activity edges may be owned by at most one structured node.

*Semantics

   Activity edges are directed connections, that is, they have a source and a target, along which tokens may flow.

   Other rules for when tokens may be passed along the edge depend on the kind of edge and characteristics of its source and target. See the children of ActivityEdge and ActivityNode. The rules may be optimized to a different algorithm as long as the effect is the same.

   The guard must evaluate to true for every token that is offered to pass along the edge. Tokens in the intermediate level of activities can only pass along the edge individually at different times. See application of guards at DecisionNode .

   Package CompleteActivities

   Any number of tokens can pass along the edge, in groups at one time, or individually at different times. The weight attribute dictates the minimum number of tokens that must traverse the edge at the same time. It is a value specification evaluated every time a new token becomes available at the source. It must evaluate to a positive LiteralUnlimitedNatural , and may be a constant. When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once. The guard must evaluate to true for each token. If the guard fails for any of the tokens, and this reduces the number of tokens that can be offered to the target to less than the weight, then all the tokens fail to be offered. An unlimited weight means that all the tokens at the source are offered to the target. This can be combined with a join to take all of the tokens at the source when certain conditions hold. See examples in Figure 12.45. A weaker but simpler alternative to weight is grouping information into larger objects so that a single token carries all necessary data. See additional functionality for guards at DecisionNode .

   Other rules for when tokens may be passed along the edge depend on the kind of edge and characteristics of its source and target. See the children of ActivityEdge and ActivityNode. The rules may be optimized to a different algorithm as long as the effect is the same. For example, if the target is an object node that has reached its upper bound, no token can be passed. The implementation can omit unnecessary weight evaluations until the downstream object node can accept tokens.

   Edges can be named, by inheritance from RedefinableElement , which is a NamedElement . However, edges are not required to have unique names within an activity. The fact that Activity is a Namespace , inherited through Behavior, does not affect this, because the containment of edges is through ownedElement, the general ownership metaassociation for Element that does not imply unique names, rather than ownedMember.

   Edges inherited from more general activities can be replaced. See RedefinableElement for more information on overriding inherited elements.

*Semantic Variation Points

   See variations at children of ActivityEdge and ActivityNode.

*Notation

Issue 8210 -replace ‘stick’ with ‘open’

   An activity edge is notated by a open arrowhead line connecting two activity nodes. If the edge has a name, it is notated near the arrow.

   Regular activity edge Activity edge with name

   Figure 12.39 - Activity edge notation

   An activity edge can also be notated using a connector, which is a small circle with the name of the edge in it. This is purely notational. It does not affect the underlying model. The circles and lines involved map to a single activity edge in the model. Every connector with a given label must be paired with exactly one other with the same label on the same activity diagram. One connector must have exactly one incoming edge and the other exactly one outgoing edge, each with the same type of flow, object or control. This assumes the UML 2.0 Diagram Interchange specification supports the interchange of diagram elements and their mapping to model elements.

   (where, n is connector name)

   Figure 12.40 - Activity edge connector notation

   Package CompleteActivities

   The weight of the edge may be shown in curly braces that contain the weight. The weight is a value specification that is a positive integer or null, which may be a constant. A weight of null is notated as all. When regions have interruptions, a lightning-bolt style activity edge expresses this interruption, see InterruptibleActivityRegion . See Pin for filled arrowhead notation.

   {weight=*}

   Activity edge for interruptible regions

   With edge weight(where n is a value specification)

   Figure 12.41 - Activity edge notation

*Examples

   Package BasicActivities

   In the example illustrated below, the arrowed line connecting Fill Order to Ship Order is a control flow edge. This means that when the Fill Order behavior is completed, control is passed to the Ship Order. Below it, the same control flow is shown with an edge name. The one at the bottom left employs connectors, instead of a continuous line. On the upper right, the arrowed lines starting from Send Invoice and ending at Make Payment (via the Invoice object node) are object flow edges. This indicates that the flow of Invoice objects goes from Send Invoice to Make Payment.

   Invoice

   is equivalent to

   Figure 12.42 - Activity edge examples

   In the example below, a connector is used to avoid drawing a long edge around one tine of the fork. If a problem is not priority one, the token going to the connector is sent to the merge instead of the one that would arrive from Revise Plan for priority one problems. This is equivalent to the activity shown in Figure 12.44, which is how Figure 12.43 is stored in the model.

   Figure 12.44 - Equivalent model to Figure 12.43

   Package CompleteActivities

   The figure below illustrates three examples of using the weight attribute. The Cricket example uses a constant weight to indicate that a cricket team cannot be formed until eleven players are present. The Task example uses a non-constant weight to indicate that an invoice for a particular job can only be sent when all of its tasks have been completed. The proposal example depicts an activity for placing bids for a proposal, where many such bids can be placed. Then, when the bidding period is over, the Award Proposal Bid activity reads all the bids as a single set and determines which vendor to award the bid.

   {weight=11} {weight=no_of_job_tasks}

   Cricket

*Changes from previous UML

    ActivityEdge replaces the use of (state) Transition in UML 1.5 activity modeling. It also replaces data flow and control flow links in UML 1.5 action model.