5 IDEF0 Function Modeling

Abstract IDEF0 is a widely used function modeling method. It is extended from SADTTM ( 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 (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 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. • Arrows should be drawn as horizontal and vertical straight line segments. Diagonal line segments are forbidden.

Fig. 5.6. An example of tunneled arrows

• Each box should have a minimum of one control arrow and one output arrow. • A box should have zero or more input arrows. • A box should have zero or more non-call mechanism arrows. • A box should have 0 or 1 call arrows. • Control feedbacks should be shown as “up and over”. • Input feedbacks should be shown as “down and under”. • Mechanism feedbacks should be shown as “down and under”. • The unconnected end of a boundary arrow should have the proper ICOM code specifying its connection to the parent box, or should be tunneled. • Open-ended boundary arrows that represent the same data or objects should be connected through a fork to show all the places affected, unless this results in an unreadable diagram. Multiple sources that represent the same data or objects should join to form a single output boundary arrow. • Box names and arrow labels should not consist solely of the following 5.3 Structured Approach of IDEF0 105

words: function, activity, process, input, output, control or mechanism.

5.3 Structured Approach of IDEF0

IDEF0 model development requires the participation of a project team. The roles and duties of members involved in an IDEF0 model development team are [1]: • Author (Analyst): People who prepare any IDEF models. • Commenter (Expert or other Author): People assigned to make a written comment of a kit. • Reader (Expert or anyone who wishes to act as a reader): People assigned to review documents but are not expected to make written comments. • Librarian: A person assigned to maintain a file of documents, make copies, distribute kits and keep records. • Project manager: The leader of the model development project who con- trols the operation direction of the project. Throughout a project, the model drafts are developed by authors and distributed to others (project members, experts, managers, etc.) for review and comment. These model drafts are called Kits and contain diagrams, text, glossary or any other information relative to the model development. In creating a document, an author prepares model drafts and distributes, in the form of a standard Kit, to commenter, reviewers and other readers. Commenter reviews the kit and writes comments about it. The commenter returns the Kit to the author who reacts to comments and may modify or expand the kit. The Kit is returned to the commenter with the reactions from the author. Readers may return comments to the author as well, but this is not required. This is known as a Kit Cycle (see Fig. 5.7). The steps of the Kit Cycle are as follows [1]: • The author assembles the material to be reviewed into a Standard Kit. Copies of the kit are distributed to each of the readers, and to the author. The original is filed for reference. • Within the specified response time, the commenter reads the kit and writes comments directly on the copy in the form of reader notes. The kit is returned to the author. • The author responds in writing directly on each commenter’s copy. The author may agree with the comment by check-marking it, noting it on his working copy and incorporating it into the next version of the model. If there is disagreement, the author writes a note of reply attached to the reader’s note (no new note number). Whether or not there is disagree- ment, the kit is returned to the reader, completing one Reader/Author Cycle. • The reader reads the author’s responses and, if satisfied, files the kit. (Commented kits are always retained by the reader.) If an assigned com- 106 5 IDEF0 Function Modeling

menter does not agree with the author’s responses, a meeting is arranged with the author to resolve differences. If this cannot be done, a list of issues is taken to appropriate authority for decision.

Fig. 5.7. Kit cycle

This cycle continues until a document is created which represents the careful consideration of all project members. If there are arguments that cannot get a tradeoff, the project manager will make the decision, or a team meeting will be held to overcome the problem. In addition, a complete history of the process has been retained.

5.4 IDEF0 Modeling Case

AA Manufacturing Company is a professional manufacturer of machine tools, who has 40 years history and 1 300 staffs. AA’s organizational structure is shown in Fig. 5.8. In order to improve AA’s efficiency and effectiveness, the Computer Integrated Manufacturing System is designed for the company. The system framework is shown in Fig. 5.9. It has 5 sub-systems upon network system, database system and application service platform. IDEF0 is used to do system design and decomposition. AA CIMS function models are shown in Fig. 5.10 – Fig. 5.16. U.S. Department of Commerce and National Institute of Standards pub- lished “SIMA Reference Architecture Part 1: Activity Models”. IDEF0 is used to develop the activity models [3]. The models can be used as a refer- ence to design an integrated manufacturing system. 5.4 IDEF0 Modeling Case 107

Fig. 5.8. Organizational chart of AA Company

Fig. 5.9. System framework of AA’s CIMS 108 5 IDEF0 Function Modeling 5.4 IDEF0 Modeling Case 109 110 5 IDEF0 Function Modeling 5.4 IDEF0 Modeling Case 111 112 5 IDEF0 Function Modeling 5.4 IDEF0 Modeling Case 113 114 5 IDEF0 Function Modeling 5.4 IDEF0 Modeling Case 115 116 5 IDEF0 Function Modeling 5.4 IDEF0 Modeling Case 117 118 5 IDEF0 Function Modeling 5.4 IDEF0 Modeling Case 119 120 5 IDEF0 Function Modeling 5.4 IDEF0 Modeling Case 121 122 5 IDEF0 Function Modeling References

[1] KBSI. IEEE Standard for Functional Modeling Language: Syntax and Semantics for IDEF0. IEEE, 1998. [2] Marca D A, McGowan, C L. SADT Structured Analysis and Design Tech- nique. McGraw-Hill Book Company, 1988. [3] Barkmeyer E J. SIMA Reference Architecture Part 1: Activity Models. NISTIR 5939, United States Department of Commerce National Institute of Standards and Technology, 1996.