Modeling Inputs and Outputs with Parameters and Pins

Activities and their constituent Actions are the workforce of systems; while structural elements such as Blocks and Parts define the structure or anatomy of a system, the Activities define the physiology. When an Activity is executing we see the structural elements being called into action to accomplish some type of system behavior. Much of the work that a system does, and the behaviors that define what the work is, are dependent on system inputs that the executing Activity consumes in order to produce outputs.

Inputs and outputs vary greatly between systems and can include things such as control signals, materials, light, fluids, energy, numbers and information. The inputs and outputs are called parameters, which can be typed and can have multiplicities. Typing ensures that the Activity specifies what kind (type) of 'thing' it is expecting. Thus if a distiller had an input parameter with a type of liquid defined or, even more specifically, a liquid-contaminant, then the Activity would be ill-formed if it received a gas or an Integer Value as an input on this parameter. The types can be any one of a defined set ranging from a simple Integer to a compound Structure. Inputs and outputs can be typed by a Block, so that you have a well defined structural element - for example, a grocery item that passes through a self scanning system at a supermarket checkout. There is a range of other properties that can be defined for a parameter, including Streaming or Non Streaming, Multiplicities, and Direction. Streaming is used when there is a continuous flow into the parameter, such as with a fluid, or a communication or information signal such as an audio or visual stream. Multiplicities define the upper and lower bounds of the number of tokens that are consumed by an input parameter or produced by an output parameter. While Direction defines if the parameter is receiving input (in) or producing output (out) or a combination of both (inout).

When Activities are placed on an Activity diagram as invocations they are represented by Actions, and any Parameters owned by an Activity will be modeled as Pins on these Actions. The Pins receive tokens on incoming Object Flows and the owning Action performs its work and places any specified number of tokens on the output Pins. The Pins can have a simple type such as an Integer, a complex Structure such as a matrix or even a Block such as a video stream. Multiplicities specify a lower and upper bound that define the minimum and maximum number of tokens permissible to arrive and depart from any given Pin. This unfinished diagram shows an Action with an input and an output Pin and the transmission of the tokens from the Owning Activity's input parameter along the Object Flow.

The Parameters and Pins are collectively known as Interaction Points, signifying that they are locations where an element interacts with its environment; they can be selected for inclusion on a diagram by using the multi-purpose Features window.

Enterprise Architect allows you to create a diagram that shows the owning Activity as a container for the other Activities included on the diagram as Actions. In this diagram, the Activity Parameters defined on the owning Activities are expressed as Pins on the boundaries of the Actions that have been included as invocations of the Activities. The diagram shows an Activity with two input parameters and a single output parameter. The inputs in the form of tokens can be traced through the diagram as they arrive at Pins. Once the Action has completed its work, tokens are placed on the output Pins. The Control Flows show the sequencing of the enclosed Actions. Notice that a Fork and Join are used to show that two Actions can be carried out in parallel. Notice also that a number of the Pins have been defined as a stream, which is indicated on the diagram by the solid color of the Pin.