5 IDEF0 Function Modeling Abstract IDEF0 is a widely used function modeling method. It is extended from SADTTM (Structured Analysis and Design TechniqueTM) and now is an IEEE standard. IDEF0 is normally used to describe what the system is.The syntax and semantics of IDEF0 are introduced in this chapter. A structured approach for IDEF0 model development is also discussed. 5.1 Introduction to IDEF0 IDEF0 (Integration DEFinition language 0) is a modeling method includ- ing combined graphics and text to obtain understanding, support analysis, provide logic for system adjustment, specify requirements, or support systems level design and integration. IDEF0 is based on SADTTM (Struc- tured Analysis and Design TechniqueTM), developed by Douglas T. Ross and SofTech, Inc. [2]. It includes both a definition of a graphical modeling language (syntax and semantics) and a methodology for developing models. IDEF0 can be used to model various kinds of systems including enter prises, software, hardware, products and so forth. For an AS-IS system, IDEF0 can be used to analyze the system functions and to document its rel- ative mechanisms. For a TO-BE system, IDEF0 can be used for requirements definition and functions specification, and then for an implementation design to meet the requirements. IDEF0 model includes a hierarchical series of diagrams, text, and glossary cross-referenced to each other. Two primary modeling components of this method are functions and data/objects that inter-relate those functions. As a function modeling language, IDEF0 has the following characteristics [1]: • It can graphically describe various kinds of business, manufacturing and other types of enterprise operations to any level of detail. • Its syntax and semantics is simple and coherent to learn, use and under- stand. • It has been used and proven in lots of projects in various kinds of areas. • It is supported by kinds of computer graphics tools and numerous com- mercial products. As well as the IDEF0 graphical and text language, IDEF0 methodology 5.2 Syntax and Semantics of IDEF0 99 offers a set of procedures and techniques for developing and interpreting models, such as for data gathering, diagram construction, review cycles and documentation. IDEF0 provides a systems engineering approach to [1]: • Support systems analysis and design at all levels; • Communicate among analysts, designers, users, managers and so forth; • Provide reference scheme for enterprise analysis, information engineering and resource management. 5.2 Syntax and Semantics of IDEF01 IDEF0 defines a series of concepts, symbols and rules for function modeling. It also provides a mechanism to organize models under the same project. 5.2.1 Basic Concepts and Rules of IDEF0 The components of the IDEF0 syntax are boxes, arrows, rules, and diagrams. A box represents a function activity and describes what happens in the function, as shown in Fig. 5.1. Each box should have a name and number inside. Fig. 5.1. Box and arrows An arrow represents data or object related to functions. They do not represent flow or sequence as in a process model. As shown in Fig. 5.2, syntax rules for arrows include: • Arrows should be drawn in solid line segments. • Arrows should be drawn vertically or horizontally, not diagonally. • Arrows that bend should be curved using only 90 degree arcs. • Arrow ends should touch the outer boundary of the function box and should not cross into the box. • Arrows should attach at box sides, not at corners. 1 The structure, content and examples of the section reference the technical report “Functional Modeling Language — Syntax and Semantics for IDEF0”developed by KBSI. 100 5 IDEF0 Function Modeling Standard arrow positions are shown in Fig. 5.1. There are 5 kinds of arrows: • Inputs are transformed or consumed by the function to produce outputs. • Controls specify the conditions required for the function to produce cor- rect outputs. • Outputs are the data or objects produced by the function. • Mechanisms identify some of the means that support the execution of the function. • Call arrows enable the sharing of detail between models (linking them together) or between portions of the same model. The called box provides detail for the caller box. Fig. 5.2. Arrow syntax Supporting information related to the function and its purpose should be addressed in the text associated with the diagram. When acronyms, abbre- viations, key words, or phrases are used, the fully defined term(s) should be provided in the glossary. Box and Arrow semantic rules include [1]: • A box shall be named with an active verb or verb phrase. • Each side of a function box shall have a standard box/arrow relation- ship: – Input arrows should interface with the left side of a box. – Control arrows should interface with the top side of a box. – Output arrows should interface with the right side of the box. – Mechanism arrows should point upward and should connect to the bottom side of the box. – Call arrows should point downward, should connect to the bottom side of the box, and should be labeled with the reference expression for the box which details the subject box. • Arrow segments, except for call arrows, should be labeled with a noun or noun phrase unless a single arrow label clearly applies to the arrow as a whole. • A “squiggle” ( ) should be used to link an arrow with its associated label, unless the arrow/label relationship is obvious. 5.2 Syntax and Semantics of IDEF0 101 • Arrow labels should not consist solely of any of the following terms: func- tion, input, control, output, mechanism, or call. 5.2.2 IDEF0 Diagrams IDEF0 model includes graphic diagrams, text, and glossary. These compo- nents are cross-related and referenced to each other. Box in one diagram can be decomposed into a child diagram that provides more detail about relative subject. Each IDEF0 model should have a top-level context diagram. This is called the A-0 diagram with only a single box and bounding arrows. It establishes the model context. The A-0 diagram also sets the model scope or boundary and purpose, as shown in Fig.5.3. Fig. 5.3. An example of top-level diagram The single function in the A-0 diagram can be decomposed into some sub- functions to form a child diagram. In turn, each of these sub-functions may be decomposed into lower-level child diagrams. Each child diagram contains the child boxes and arrows that provide additional detail about the parent box. Based on decomposition, the child diagram covers the same scope as the parent box but more detailed. This structure of decomposition is illustrated in Fig. 5.4. A diagram may have associated structured text, which is used to provide a brief statement of the diagram. The glossary should be used to define key words that have been used in the diagram for correct understanding. In a diagram, there are two types of arrows: internal arrows with both ends (source and use) connected to boxes and boundary arrows with only 102 5 IDEF0 Function Modeling Fig. 5.4. Decomposition structure one end (source or use) connected to boxes. All boundary arrows on a child diagram (except for tunneled arrows) shall correspond to the arrows that connect to its parent box, as shown in Fig. 5.5. For boundary arrows, ICOM codes specify the matching connections. The letter I, C, O or M is written near the unconnected end of each boundary arrow on the child diagram. This coding identifies the arrow as an Input, Control, Output or Mechanism on the parent box. This letter is followed by a number giving the relative position at which the arrow is shown connecting to the parent box, numbering from left to right or top to bottom. In Fig. 5.5, “C3” written on a boundary arrow on a child diagram indicates that this arrow corresponds to the third control arrow (from the left) entering its 5.2 Syntax and Semantics of IDEF0 103 Fig. 5.5. Boundary and internal arrows parent box. This coding relates each child diagram to its own immediate parent box. If boxes on a child diagram are detailed on subsequent child diagrams, new ICOM codes are assigned on each new child diagram, relating that diagram’s boundary arrows to arrows on its own immediate parent box [1]. A tunneled arrow is used to provide information at a specific level of decomposition that is not required for understanding at some other levels. An arrow can be tunneled at any chosen level. As shown in Fig. 5.6, tunneling an arrow where it connects to a box side means that the data or objects expressed by that arrow are not necessary for understanding subsequent level(s) of decomposition, and thus should not be shown on its child diagram. Tunneling an arrow at the unconnected end means that the data or objects are not necessary at its immediate parent level and hence should not be shown connecting to the parent box [1]. IDEF0 diagram syntax rules are as follows [1]. • Context diagram should have node numbers A-0. • The model should contain an A-0 context diagram, which contains only one box. • The box number of the single box on the A-0 context diagram should be 0. • A non-context diagram should have at least three boxes and no more than six boxes. • Each box on a non-context diagram should be numbered in its lower right 104 5 IDEF0 Function Modeling inside corner, in order (from upper left to lower right on the diagram) from 1 to at most 6. • Each box that has been detailed should have the detail reference expres- sion of its child diagram written beneath the lower right corner of the box.