DOCSLIB.ORG

5 IDEF0 Function Modeling

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
5 IDEF0 Function Modeling 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.
Load more

Recommended publications
  • Integration Definition for Function Modeling (IDEF0)
    NIST U.S. DEPARTMENT OF COMMERCE PUBLICATIONS £ Technology Administration National Institute of Standards and Technology FIPS PUB 183 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEFO) » Category: Software Standard SUBCATEGORY: MODELING TECHNIQUES 1993 December 21 183 PUB FIPS JK- 45C .AS A3 //I S3 IS 93 FIPS PUB 183 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEFO) Category: Software Standard Subcategory: Modeling Techniques Computer Systems Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 Issued December 21, 1993 U.S. Department of Commerce Ronald H. Brown, Secretary Technology Administration Mary L. Good, Under Secretary for Technology National Institute of Standards and Technology Arati Prabhakar, Director Foreword The Federal Information Processing Standards Publication Series of the National Institute of Standards and Technology (NIST) is the official publication relating to standards and guidelines adopted and promulgated under the provisions of Section 111 (d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. These mandates have given the Secretary of Commerce and NIST important responsibilities for improving the utilization and management of computer and related telecommunications systems in the Federal Government. The NIST, through its Computer Systems Laboratory, provides leadership, technical guidance,
    [Show full text]
  • Identifying and Defining Relationships: Techniques for Improving Student Systemic Thinking
    AC 2011-897: IDENTIFYING AND DEFINING RELATIONSHIPS: TECH- NIQUES FOR IMPROVING STUDENT SYSTEMIC THINKING Cecelia M. Wigal, University of Tennessee, Chattanooga Cecelia M. Wigal received her Ph.D. in 1998 from Northwestern University and is presently a Professor of Engineering and Assistant Dean of the College of Engineering and Computer Science at the University of Tennessee at Chattanooga (UTC). Her primary areas of interest and expertise include complex process and system analysis, process improvement analysis, and information system analysis with respect to usability and effectiveness. Dr. Wigal is also interested in engineering education reform to address present and future student and national and international needs. c American Society for Engineering Education, 2011 Identifying and Defining Relationships: Techniques for Improving Student Systemic Thinking Abstract ABET, Inc. is looking for graduating undergraduate engineering students who are systems thinkers. However, genuine systems thinking is contrary to the traditional practice of using linear thinking to help solve design problems often used by students and many practitioners. Linear thinking has a tendency to compartmentalize solution options and minimize recognition of relationships between solutions and their elements. Systems thinking, however, has the ability to define the whole system, including its environment, objectives, and parts (subsystems), both static and dynamic, by their relationships. The work discussed here describes two means of introducing freshman engineering students to thinking systemically or holistically when understanding and defining problems. Specifically, the modeling techniques of Rich Pictures and an instructor generated modified IDEF0 model are discussed. These techniques have roles in many applications. In this case they are discussed in regards to their application to the design process.
    [Show full text]
  • Modelling, Analysis and Design of Computer Integrated Manueactur1ng Systems
    MODELLING, ANALYSIS AND DESIGN OF COMPUTER INTEGRATED MANUEACTUR1NG SYSTEMS Volume I of II ABDULRAHMAN MUSLLABAB ABDULLAH AL-AILMARJ October-1998 A thesis submitted for the DEGREE OP DOCTOR OF.PHILOSOPHY MECHANICAL ENGINEERING DEPARTMENT, THE UNIVERSITY OF SHEFFIELD 3n ti]S 5íamc of Allai]. ¿Hoot (gractouo. iHHoßt ¿Merciful. ACKNOWLEDGEMENTS I would like to express my appreciation and thanks to my supervisor Professor Keith Ridgway for devoting freely of his time to read, discuss, and guide this research, and for his assistance in selecting the research topic, obtaining special reference materials, and contacting industrial collaborations. His advice has been much appreciated and I am very grateful. I would like to thank Mr Bruce Lake at Brook Hansen Motors who has patiently answered my questions during the case study. Finally, I would like to thank my family for their constant understanding, support and patience. l To my parents, my wife and my son. ABSTRACT In the present climate of global competition, manufacturing organisations consider and seek strategies, means and tools to assist them to stay competitive. Computer Integrated Manufacturing (CIM) offers a number of potential opportunities for improving manufacturing systems. However, a number of researchers have reported the difficulties which arise during the analysis, design and implementation of CIM due to a lack of effective modelling methodologies and techniques and the complexity of the systems. The work reported in this thesis is related to the development of an integrated modelling method to support the analysis and design of advanced manufacturing systems. A survey of various modelling methods and techniques is carried out. The methods SSADM, IDEFO, IDEF1X, IDEF3, IDEF4, OOM, SADT, GRAI, PN, 10A MERISE, GIM and SIMULATION are reviewed.
    [Show full text]
  • A Method for Business Process Model Analysis and Improvement
    A Method for Business Process Model Analysis and Improvement Andrii Kopp[0000-0002-3189-5623] and Dmytro Orlovskyi[0000-0002-8261-2988] National Technical University “KhPI”, Kyrpychova str. 2, 61002 Kharkiv, Ukraine {kopp93, orlovskyi.dm}@gmail.com Abstract. Since business process modeling is considered as the foundation of Business Process Management, it is required to design understandable and mod- ifiable process models used to analyze and improve depicted business process- es. Therefore, this article proposes a method for business process model analy- sis and improvement. The lifecycle of Business Process Management from business process modeling to applying the Business Intelligence and process mining techniques is considered. Existing approaches to business process model analysis are reviewed. Proposed method is based on best practices in business process modeling, process model metrics, and corresponding thresholds. The usage of business process model metrics and thresholds to formalize process modeling guidelines is outlined, as well as the procedure of business process model analysis and improvement is shown. The application of Business Intelli- gence techniques to support the proposed method is demonstrated. Keywords: Business Process Management, Business Process Modeling, Pro- cess Model Analysis, Process Model Improvement. 1 Introduction Today Business Process Management (BPM) is one of the most popular management concepts. It is based on the set of methods and tools used to design, analyze, improve, and automate organizational business processes. In its turn, business process is a structured set of activities that takes one or more kinds of input and produces a prod- uct or service valuable for a particular customer [1]. According to professor van der Aalst [2], BPM combines knowledge from infor- mation technology and knowledge from management sciences and applies this to operational business processes.
    [Show full text]
  • IDEF0 Includes Both a Definition of a Graphical Model
    Faculty of Information Technologies Basic concepts of Business Process Modeling Šárka Květoňová Brno, 2006 Outline • Terminology • A Brief History on Business Activity • The basic approaches to Business Process Modeling – Formal x informal methods of specification and analysis – Verification of the informal defined methods • Software tools for Business Process specification and analysis (ARIS, BP Studio, JARP, Woflan, Flowmake, Oracle BPEL Process Manager, etc.) • Standards of BPM in context of BP Challenges – BPEL, BPMN, BPML, BPQL, BPSM, XPDL, XLANG, WSCI etc. • Mapping of UML Business Processes to BPEL4WS • Conclusions Terminology of BPM • Business Process is a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. • Business process model – is the representation of a business process in a form which supports automated manipulation, such as modeling or enactment. The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated data, etc. • Workflow – is the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. Terminology of BPM • Method is well-considered (sophisticated) system
    [Show full text]
  • Structured Models and Dynamic Systems Analysis: the Integration of the Idef0/Idef3 Modeling Methods and Discrete Event Simulation
    STRUCTURED MODELS AND DYNAMIC SYSTEMS ANALYSIS: THE INTEGRATION OF THE IDEF0/IDEF3 MODELING METHODS AND DISCRETE EVENT SIMULATION Larry Whitman Adrien Presley Brian Huff Automation & Robotics Research Institute Division of Business and Accountancy The University of Texas at Arlington Truman State University 7300 Jack Newell Boulevard South 100 East Normal Fort Worth, Texas 76118, U.S.A. Kirksville, Missouri 63501, U.S.A. · To analyze and design the enterprise and its ABSTRACT processes prior to implementation · To help reduce complexity The role of modeling and simulation is receiving much · To communicate a common understanding of the press of late. However, the lack of practice in employing system a link between the two is alarming. A static model is · To gain stakeholder buy-in used to understand an enterprise or a system, and · To act as a documentation tool for ISO 9000, TQM, simulation is used for dynamic analysis. Generally, most Concurrent Engineering, and other efforts. models are considered static, whereas simulation is really A primary thrust of this research is to determine the a dynamic model. Static models are useful in achieving feasibility of using a single master static model of the understanding of the enterprise. Simulations are useful in enterprise for multiple purposes. Previous research has analyzing the behavior of the enterprise. presented a single suite perspective (Lingineni, Caraway Most enterprises develop and even maintain multiple et al. 1996) and uses custom developed software (Harrell types of models for different purposes. If a single model and Field 1996). This research uses commercial products can be used to drive other modeling purposes, then exclusively.
    [Show full text]
  • Introduction to IDEF0/3 for Business Process Modelling. Contents Tables & Figures
    Introduction to IDEF0/3 for Business Process Modelling. Contents Introduction ............................................................................................................................................ 2 Introduction to IDEF0 and IDEF3: ....................................................................................................... 2 Parent and Child Maps ........................................................................................................................ 2 Tunnelling ........................................................................................................................................ 3 Construction of IDEF Maps ................................................................................................................. 3 Branches and Joins .......................................................................................................................... 3 Starting an IDEF0 Map ............................................................................................................................ 4 Root definition .................................................................................................................................... 4 The IDEF0 Numbering Convention ...................................................................................................... 5 Creating a model ..................................................................................................................................... 5 Decomposition ...............................................................................................................................
    [Show full text]
  • SADT — Structured Analysis & Design Technique
    Workshop: SADT: Structured Analysis & Design Technique SADT — Structured Analysis & Design Technique Yuling Li 12/5/16 1 Workshop: SADT: Structured Analysis & Design Technique How to Make a Pizza? 2 Workshop: SADT: Structured Analysis & Design Technique 3 Workshop: SADT: Structured Analysis & Design Technique How to Make a Pizza (Process/Activities) Systematically? • Analysis Determine what the system will do • Design Define subsystems and their interfaces • Implementation Create the subsystem independently • Integration Combine the subsystems into a single unit • Testing Verify the system workings • Installation Make the system operational • Operation Use the system 4 Workshop: SADT: Structured Analysis & Design Technique “M models A if M answers questions about A” ---- Douglas T. Ross 5 Workshop: SADT: Structured Analysis & Design Technique Contents 1 Overview of SADT 2 Syntax and Semantics 3 SADT Diagrams 4 Cases 6 Workshop: SADT: Structured Analysis & Design Technique 1 Overview of SADT SADT IDEF0 IDEF Family 7 Workshop: SADT: Structured Analysis & Design Technique Emergent 1950s “hierarchic, layered modular system” SA Box ➕ 1960s “system of systems for building systems” SA Decomposition “top-down hierarchic decomposition” ➕ Cell 1970s “Hori’s Human-directed activity cell model” modelling “language for blueprinting systems” SADT • Douglas T. Ross developed SADT (1969-1973 ) • SADT is a trademark of SofTech, Inc. (After 1973) 8 Workshop: SADT: Structured Analysis & Design Technique Develop • During the 1970s, the U.S. Air Force Program
    [Show full text]
  • Business Modelling: UML Vs. IDEF
    Griffith University School of Computing and Information Technology Domain: Advanced Object Oriented Concepts Business Modelling: UML vs. IDEF available electronically at: http://www.cit.gu.edu.au/~noran © Ovidiu S. Noran Table of Contents. 1 Introduction....................................................................................................1 1.1 The objectives of this paper..............................................................................1 1.2 Motivation.........................................................................................................1 1.3 Some Important Terms.....................................................................................2 1.3.1 Models. .............................................................................................................. 2 1.3.2 Business Process Models.................................................................................. 2 1.3.3 Information Systems Support. ........................................................................... 3 1.3.3.1 The Business Model as a Base for Information Systems.......................... 3 1.3.3.2 'Legacy' Systems....................................................................................... 4 1.3.4 Business Improvement vs. Innovation............................................................... 4 1.4 Business Concepts...........................................................................................4 1.4.1 Business Architecture. ......................................................................................
    [Show full text]
  • Categorization and Representation of Functional Decomposition by Experts
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Calhoun, Institutional Archive of the Naval Postgraduate School Calhoun: The NPS Institutional Archive Theses and Dissertations Thesis Collection 2008-09 Categorization and representation of functional decomposition by experts Melancon, Paul W. Monterey, California. Naval Postgraduate School http://hdl.handle.net/10945/3950 NAVAL POSTGRADUATE SCHOOL MONTEREY, CALIFORNIA THESIS CATEGORIZATION AND REPRESENTATION OF FUNCTIONAL DECOMPOSITION BY EXPERTS by Paul W. Melançon September 2008 Thesis Advisor: Gary O. Langford Second Reader: John Osmundson Approved for public release; distribution is unlimited THIS PAGE INTENTIONALLY LEFT BLANK REPORT DOCUMENTATION PAGE Form Approved OMB No. 0704-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) Washington DC 20503. 1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED September 2008 Master’s Thesis 4. TITLE AND SUBTITLE Categorization and Representation of Functional 5. FUNDING NUMBERS Decomposition by Experts 6. AUTHOR(S) Paul W. Melançon 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION Naval Postgraduate School REPORT NUMBER Monterey, CA 93943-5000 9.
    [Show full text]
  • CIM Modeling: IDEF0 and Idef1x
    CIM Modeling: IDEF0 and IDEF1x 1 Understanding the Process “...the lack of understanding results in incorrect, inconsistent and unclear requirements for a system which in turn results in a faulty system design.” - Bravoco and Yadav (1986) • A systematic methodology is needed to provide understanding and analysis of a complex system • Structural Analysis and Design Technique (SADT) 2 Structural Analysis and Design Technique • SADT is based on three concepts borrowed from software engineering approach –A top-down modeling approach –A graphical approach that highlights specific sections in a hierarchy – Distinguishing between data, people, devices and activities which clearly shows what is performed and how 3 ICAM Project and its Missions • US Airforce, Integrated Computer-Aided Manufacturing (ICAM) Project – To specify a complete system with which an architecture for manufacturing could be defined. • IDEF (ICAM DEFinition method) – IDEF0: a structured functional analysis method – IDEF1: an information modeling method – IDEF2: a dynamic model methodology – IDEF3: a process and simulation model 4 IDEF0 : Structured Functional Analysis C (Control) I (Input)Activity O (Output) M (Mechanism) •An input, an object, information or data, is transformed by an activity to produce an output •A control constrains how the activity is carried out •A mechanism, a person, system or device, performs and carries out the activity 5 Decomposition of Activities in IDEF0 • A hierarchical way of decomposing a complex subject into its constituent parts or sub-activities
    [Show full text]
  • IDEF1 Information Modeling
    IDEF1 Information Modeling A Reconstruction of the Original Air Force Wright Aeronautical Laboratory Technical Report AFWAL-TR-81-4023 Dr. Richard J. Mayer, Editor Knowledge Based Systems, Inc. IDEF1 Information Modeling A Reconstruction of the Original Air Force Wright Aeronautical Laboratory Technical Report AFWAL-TR-81-4023 Dr. Richard J. Mayer, Editor Knowledge Based Systems, Inc. Knowledge Based Systems, Inc. One KBSI Place 1408 University Drive East College Station, Texas 77840-2335 (409) 260-5274 This manual is copyrighted, with all rights reserved. Under the copyright laws, the manual may not be reproduced in any form or by any means, in whole or in part, without written consent of Knowledge Based Systems, Inc. (KBSI). Under the law, reproducing includes translating into another language or format. © 1990, 1992 by Knowledge Based Systems, Inc. One KBSI Place 1408 University Drive East College Station, Texas 77840-2335 (409) 696-7979 Table of Contents List of Figures .......................................................................................................................... v Foreword.................................................................................................................................. ix 1.0 Introduction.................................................................................................................... 3 2.0 IDEF1 Concepts ............................................................................................................. 7 2.1 Introduction........................................................................................................
    [Show full text]