In an OV-5 Activity Model diagram, ICOM arrows are drawn into or out of operational activities to denote Input, Control, Output, or Mechanism (ICOM) of the symbol.
Controls are a form of input that are used to direct the activity in the process. Inputs and controls are distinguished from each other by the fact that inputs get transformed or changed in some way in order to create the outputs, while controls seldom are changed. Examples of forms of control include standards, plans, templates, and checklists.
Mechanisms are the resources and tools that are required to complete the process. This includes people with particular skills, machines and other tools.
ICOM arrow placement rules
The position of the arrow on the symbol is what determines its line type. Any output arrow can provide input, control, or mechanism data to one or more boxes. The child diagram also shows the constraining relationship of arrows, that is, a function that receives input or control from a previous function is constrained by that previous function.
Arrow placement rules
ICOM arrows
Function
Side of activity box
Input
Consists of objects and/or data a function needs to perform its activities.
Into left
Control
Dictates why and how the function is performed. For example, in a software system a control could be a Software Design Specification
Downwards into top only
Call
When an original function is described in greater detail in another function, the original function “calls” the other function.
Downwards from bottom
Output
Consists of objects and/or data created by the function.
From the right
Mechanism
The means to perform a function also thought of as a resource.
Upwards into the Activity Box
Drawing ICOM arrows on a constraint diagram
ICOM arrows on Constraint (child, decomposition IDEF0) diagrams obey the same conventions as on Context diagrams, and the basic method for drawing them is the same. Likewise, they can be tunneled or not tunneled, as appropriate.
However, because Constraint diagrams are more complex than Context diagrams, ICOM arrows can be used in several additional ways:
▪ICOM arrows from the Parent diagram can be carried over and used on the Child diagram.
▪Because Child diagrams can have multiple Operational Activity symbols, arrows can connect one box to another on the same diagram. These are considered internal arrows.
▪Arrows headed to the same destination can join, or bundle. Likewise, arrows with a mutual origin but separate destinations can split, or unbundle.
▪An arrow can loop back to the same function it came from, as when showing iterated activity such as memory storage or feedback.
▪An arrow can be marked with a squiggle to show that a particular name applies to a particular arrow, in cases where the two are no longer adjacent on the diagram.
Looping ICOM arrows
To show iterated activity in an IDEF0 child decomposition diagram, you can draw a call or output arrow exiting from a function or activity symbol that loops back to that same box as an input or control.
Draw a loop by starting and ending the line on the appropriate sides of the function box. You must use the line style Straight (orthogonal) to loop ICOM Arrows. Although this is the default style, if for some reason you have changed it to Straight - any orientation or Elliptical arcs, you can set it to Straight (orthogonal) by selecting an already drawn ICOM Arrow and selecting Format, Line Style.
Tunneled ICOM arrows
When an arrow into a box is tunneled, it means that the object/data associated with the arrow does not need further understanding (or need to be modeled) on the next-level child decomposition IDEF0 diagram. System Architect will not automatically add tunneled arrows to a child IDEF0 diagram.
Tunneled arrows are notated with a parenthesis on a control on the Parent.