Previous UML Classes Table of Contents UML Packages Next

12.3.44 Pin

BasicActivities , CompleteActivities



   A pin is an object node for inputs and outputs to actions.


   Package CompleteActivities

   • isControl : Boolean [1..1] = false Tells whether the pins provide data to the actions, or just controls when it executes it.


   No additional associations


   See constraints on ObjectFlow .


   Package CompleteActivities

   [1] Control pins have a control type.

   isControl implies isControlType


   See Pin (from BasicActions ) on page 275.

   (CompleteActivities ) Control pins always have a control type, so they can be used with control edges. Control pins are ignored in the constraints that actions place on pins, including matching to behavior parameters for actions that invoke behaviors. Tokens arriving at control input pins have the same semantics as control arriving at an action, except that control tokens can queue up in control pins. Tokens are placed on control output pins according to the same semantics as tokens placed on control edges coming out of actions.


   Pin rectangles may be notated as small rectangles that are attached to action rectangles. See figure below and examples. The name of the pin can be displayed near the pin. The name is not restricted, but it often just shows the type of object or data that flows through the pin. It can also be a full specification of the corresponding behavior parameter for invocation actions, using the same notation as parameters for behavioral features on classes. The pins may be elided in the notation even though they are present in the model. Pins that do not correspond to parameters can be labeled as name:type.

   Input pin Output pin

   Figure 12.119 - Pin notations

Issue 8859 -add clarifying phrase 9010 -explain about multiple arrows

   The situation in which the output pin of one action is connected to the input pin of the same name in another action may be shown by the optional notations of Figure 12.120. The standalone pin in the notation maps to an output pin and an input pin and one object flow edge between them in the underlying model. This form should be avoided if the pins are not of the same type. Multiple arrows coming out of a standalone pin rectangle is an optional notation for multiple edges coming out of an output pin. These variations in notation assume the UML 2.0 Diagram Interchange specification supports the interchange of diagram elements and their mapping to model elements, so that the chosen variation is preserved on interchange.



   Figure 12.120 - Standalone pin notations

   See ObjectNode for other notations applying to pins, with examples for pins below.

   Package CompleteActivities

   To show streaming, a text annotation is placed near the pin symbol: {stream} or {nonstream}. See figure below. The notation is the same for a standalone object node. Nonstream is the default where the notation is omitted.

Issue 8263 -fix typo ends instead of end











   Standalone object node, Input pin, Output pin, streaming on both ends streaming streaming

   Figure 12.121 - Stream pin notations

   Pins for exception parameters are indicated with a small triangle annotating the source end of the edge that comes out of the exception pin. The notation is the same even if the notation uses a standalone notation. See figure below.

   Output pin, pin style, exception

   Input and output pin, standalone style, exception

   Figure 12.122 - Exception pin notations

   Specifying the effect that the behavior of actions has on the objects passed in and out of their parameters can be represented by placing the effect in braces near the edge leading to or from the pin for the parameter.

   Figure 12.123 - Specifying effect that actions have on objects

   Control pins are shown with a text annotation placed near the pin symbol {control}.

   See ObjectNode for other notations applying to pins, with examples for pins below.

*Presentation Options

   When edges are not present to distinguish input and output pins, an optional arrow may be placed inside the pin rectangle, as shown below. Input pins have the arrow pointing toward the action and output pins have the arrow pointing away from the action.

   Input pin, Output pin, pin-style, with arrow pin-style, with arrow

   Figure 12.124 - Pin notations, with arrows

   Package CompleteActivities

   Additional emphasis may be added to streaming parameters by using a graphical notation instead of the textual adornment. Object nodes can be connected with solid arrows containing filled arrowheads to indicate streaming. Pins can be shown as filled rectangles. When combined with the option above, the arrows are shown as normal arrowheads.






[state] name [state]

   Input and output pin, Input pin, Output pin,stand-alone style, streaming on both ends pin-style, streaming pin-style, streaming

   Figure 12.125 - Stream pin notations, with filled arrows and rectangles


   In the example below, the pin named Order represents Order objects. In this example at the upper left, the Fill Order behavior produces filled orders and Ship Order consumes them and an invocation of Fill Order must complete for Ship Order to begin. The pin symbols have been elided from the action symbols; both pins are represented by the single box on the arrow. The example on the upper right shows the same thing with explicit pin symbols on actions. The example at the bottom of the figure illustrates the use of multiple pins.


   Figure 12.126 - Pin examples

   In the figure below, the object node rectangle Order is linked to a class diagram that further defines the node. The class diagram shows that filling an order requires order, line item, and the customer’s trim-and-finish requirements. An Order token is the object flowing between the Accept and Fill activities, but linked to other objects. The activity without the class diagram provides a simplified view of the process. The link to an associated class diagram is used to show more detail.

   Object node

   rectangle linked

   with a class diagram

Figure 12.127 - Linking a class diagram to an object node

   Package CompleteActivities

   In the example below Order Filling is a continuous behavior that periodically emits (streams out) filled-order objects, without necessarily concluding as an activity. The Order Shipping behavior is also a continuous behavior that periodically receives filled-order objects as they are produced. Order Shipping is invoked when the first order arrives and does not terminate, processing orders as they arrive.


Order Order [Filled] [Filled]


{stream} {stream} {stream} Order {stream}


   Figure 12.128 - Pin examples

   Example of exception notation is shown at the top of the figure below. Accept Payment normally completes with a payment as being accepted and the account is then credited. However, when something goes wrong in the acceptance process, an exception can be raised that the payment is not valid, and the payment is rejected.



   Figure 12.129 - Exception pin examples

   The figure below shows two examples of selection behavior. Both examples indicate that orders are to be shipped based or order priority—and those with the same priority should be filled on a first-in/first-out (FIFO) basis.


   Figure 12.130 - Specifying selection behavior on an ObjectFlow

   In the figure below, an example depicts a Place Order activity that creates orders and Fill Order activity that reads these placed orders for the purpose of filling them.

   Order Order

   Figure 12.131 Pin example with effects

   Pin is specialized in Activities to make it an object node and to give it a notation.

*Changes from previous UML

   Pin is new to activity modeling in UML 2.0. It replaces pins from UML 1.5 action model.