Software Process & Quality Management Group Project: Integration Definition (IDEF) Mentor: Truong Dinh Huy

SOFTWARE PROCESS & QUALITY MANAGEMENT
GROUP PROJECT
Integration Definition (IDEF)
Mentor: Truong Dinh Huy
Team members :
 Nguyễn Anh Quốc
 Trần Văn Khoa
 Nguyễn Trịnh Huy Quốc
 Phan Thanh Phú
SOFTWARE PROCESS & QUALITY MANAGEMENT–Group

Đỗ Đức Trung
Project 1
International School, Duy Tan University
PROJECT INFORMATION
Project Title Integration Definition (IDEF)
Start Date 12/09/2021 End Date 18/12/2021

Lead Institution International School, Duy Tan University
Truong Dinh Huy, Msc
Instructor Email: huy.truongdinh@gmail.com
Phone: 0982.132.352
Nguyễn Anh Quốc Anhquoca5hht@gmail.com 0868077665
Trần Văn Khoa phamquochung571@gmail.co
0968164172
Team Members m
Nguyễn Trịnh Huy
hungvonhu2@gmail.com 0988114207
Quốc
Phan Thanh Phú builehuybm@gmail.com 0979571914
Đỗ Đức Trung lehuy1703@gmail.com 0923245422
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 2

Contents
1. OVERVIEW OF IDEF METHODS................................................................4

1.1. What Does Integration Definition (IDEF) Mean?........................................4
1.2. IDEF History.................................................................................................4
1.3. Techopedia Explains Integration Definition (IDEF)....................................4
2. OVERVIEW OF IDEF METHODS................................................................5
2.1. IDEF0 : Function modeling..........................................................................5
2.2. IDEF1 : Information modeling.....................................................................5
2.3. IDEF1X : Data modeling..............................................................................5
2.4. IDEF2 : Simulation model design.................................................................5
SOFTWARE
2.5. IDEF3 :PROCESS & QUALITY
Process description MANAGEMENT– Group Project
capture.............................................................5 3
2.6. IDEF4 : Object-oriented design....................................................................5

2.7. IDEF5 : Ontology description capture..........................................................5
2.8. IDEF6 : Design rationale capture.................................................................5
2.9. IDEF7 : Information system auditing...........................................................5
2.10. IDEF8 : User interface modeling..................................................................5
2.11. IDEF9 : Business constraint discovery.........................................................5
2.12. IDEF10 : Implementation architecture modeling..........................................5
2.13. IDEF11 : Information artifact modeling.......................................................5
2.14. IDEF12 : Organization modeling..................................................................5
2.15. IDEF13 : Three schema mapping design......................................................5
2.16. IDEF14 : Network design.............................................................................5
3. THE IDEF MODELING LANGUAGES........................................................6
3.1. IDEF0 : for Function Modeling (purpose:description).................................6

3.2. IDEF1 : for Information Modeling (purpose:description)............................6
3.3. IDEF3 : for Process Modeling. (purpose:description)..................................6
3.4. IDEF3 : for Process Modeling. (purpose:description)..................................6
3.5. IDEF4 : for Object-Oriented Design. (purpose:design)................................6
3.6. IDEF5 : for Ontology Description Capture..................................................6
3.7. Rasmussen - Definition DesignMaps............................................................6
3.8. Side by Side Comparison..............................................................................6
3.9. Rasmussen Map 1 compared to IDEF0- Diagram........................................6
3.10. Key...............................................................................................................6
3.11. Advantage of IDEF......................................................................................6
4. REFERENCES..................................................................................................6

1. OVERVIEW OF IDEF METHODS
1.1. What Does Integration Definition (IDEF) Mean?

Integration Definition (IDEF) is a group of modeling languages used to implement
systems and engineer software. These languages are used in data functional
modeling, simulation, object-oriented analysis, and knowledge acquisition.
The U.S. Air Force (USAF) has assumed the responsibility of funding IDEF since
the project launch. IDEF is still used by USAF departments and other military
institutions. IDEF is also available in the public domain.
1.2. IDEF History
In the 1970’s, IDEF0 originated in the U.S. AirForce under the Integrated
Computer-Aided Manufacturing(ICAM) program from a well-established
graphical language, the Structured Analysis and Design Technique (SADT).
1.3.Techopedia Explains Integration Definition (IDEF)
IDEF is maintained by Knowledge Based Systems, Inc. and is compatible with
manufacturing platforms built during its first launch. Additional software industry
SOFTWARE
applications PROCESS
utilize & aQUALITY
IDEF on daily basis.MANAGEMENT– Group Project 5
IDEF includes 16 different methods (IDEF1X, IDEF1, IDEF3, etc.). During the
modeling process, each method captures a certain data type. In addition to IDEF’s
role in model analysis and creation of a system version, IDEF is useful in
translating a system into a graphical form. To simplify model transitions, gap
analysis is applied in collaboration with IDEF.
One of the most common IDEF process applications is the application of IDEF0 to
the function modeling of any enterprise. This is applied to graphically model its
functions’ controls and operators with different resources used within those control
processes, their procedures, and various mutual function interactions.
2. OVERVIEW OF IDEF METHODS
IDEF refers to a family of modeling language, which cover a wide range of uses,
from functional modeling to data, simulation, object-oriented analysis/design and

knowledge acquisition. Eventually the IDEF methods have been defined up to
IDEF14
2.1. IDEF0 : Function modeling
 IDEF0 (Integration Definition for Function Modeling) is a function

modeling methodology for describing manufacturing functions, which offers a
functional modeling language for the analysis, development, reengineering, and
integration of information systems; business processes; or software engineering
analysis.
 IDEF0 is part of the IDEF family of modeling languages in the field of
software engineering, and is built on the functional modeling language Structured
Analysis and Design Technique (SADT).
 The IDEF0 Functional Modeling method is designed to model the decisions,
actions, and activities of an organization or system. It was derived from the
established graphic modeling language Structured Analysis and Design Technique
(SADT) developed by Douglas T. Ross and SofTech, Inc.. In its original form,
IDEF0 includes both a definition of a graphical modeling language (syntax and
semantics) and a description of a comprehensive methodology for developing
SOFTWARE
models. The USPROCESS
Air Force & QUALITY MANAGEMENT–
commissioned the SADT developersGroup Project a
to develop 6
function model method for analyzing and communicating the functional
perspective of a system. IDEF0 should assist in organizing system analysis and
promote effective communication between the analyst and the customer through
simplified graphical devices.
2.2. IDEF1 : Information modeling
 IDEF1 was developed under ICAM program priority 1102 by Dr. Robert R.
Brown of the Hughes Aircraft Company, under contract to SofTech, Inc. Dr.
Brown had previously been responsible for the development of IMS while working
at Rockwell International (Rockwell chose not to pursue IMS as a marketable
product; International Business Machines (IBM), which had served as a support
contractor during development, subsequently took over the product and was
successful in further developing it for market.) Dr. Brown credits his Hughes
colleague Mr. Timothy Ramey as the inventor of IDEF1 as a viable formalism for
modeling information structures. The two Hughes researchers built on ideas from
and interactions with many luminaries in the field at the time. In particular, IDEF1
draws on the following techniques:

 the Evolving Natural Language Information Model (ENALIM) technique of
Dr. G. M. Nijssen (Control Data Corporation) — this technique is now more
widely known as NIAM or the Object-Role Model ORM;
 the network data structures technique, popularly called the CODASYL
approach, of Dr. Charles Bachman (Honeywell Information Systems);
 the hierarchical data management technique, implemented in IBM's IMS
data management system, developed by Dr. R. R. Brown (Rockwell International);
 the relational approach to data of Dr. E. F. Codd (IBM);
 The Entity-Relationship Approach (E-R) of Dr. Peter Chen (UCLA).
2.3. IDEF1X : Data modeling
 IDEFIX (Integration Definition for Information Modeling) is a data

modeling language for the developing of semantic data models. IDEF1X is used to
produce a graphical information model which represents the structure and
semantics of information within an environment or system.
 Use of the IDEF1X permits the construction of semantic data models which
may serve to support the management of data as a resource, the integration of
SOFTWARE PROCESS & QUALITY
building of MANAGEMENT–
computer databases.Group Project is part 7
information systems, and the This standard
of the IDEF family of modeling languages in the field of software engineering.
 In 1983, the U.S. Air Force initiated the Integrated Information Support
System (I2S2) project under the ICAM program. The objective of this project was
to provide the enabling technology to logically and physically integrate a network
of heterogeneous computer hardware and software. As a result of this project, and
industry experience, the need for an enhanced technique for information modeling
was recognized.
2.4. IDEF2 : Simulation model design
 The third IDEF (IDEF2) was originally intended as a user interface

modeling method. However, since the [node:1369] Program needed a simulation
modeling tool, the resulting IDEF2 was a method for representing the time varying
behavior of resources in a manufacturing system, providing a framework for
specification of math model based simulations. It was the intent of the
methodology program within ICAM to rectify this situation but limitation of
funding did not allow this to happen. As a result, the lack of a method which would
support the structuring of descriptions of the user view of a system has been a

major shortcoming of the IDEF system. The basic problem from a methodology
point of view is the need to distinguish between a description of what a system
(existing or proposed) is supposed to do and a representative simulation model that
will predict what a system will do. The latter was the focus of IDEF2, the former is
the focus of IDEF3.
2.5. IDEF3 : Process description capture
 IDEF3, officially named a Integrated DEFinition for Process Description

Capture Method, is a business process modelling method complementary to
IDEF0. The IDEF3 method is a scenario-driven process flow description capture
method intended to capture the knowledge about how a particular system works.
 The IDEF3 method provides modes to represent both
 Process Flow Descriptions to capture the relationships between actions
within the context of a specific scenario, and
 Object State Transition to capture the description of the allowable states and
conditions.
 This method is part of the IDEF family of modeling languages in the field of
systems and software
SOFTWARE PROCESSengineering.
& QUALITY MANAGEMENT– Group Project 8
2.6. IDEF4 : Object-oriented design
 IDEF4, officially named Integrated DEFinition for Object-Oriented Design,

is an object-oriented design modeling language for the design of component-based
client/server systems. It has been designed to support smooth transition from the
application domain and requirements analysis models to the design and to actual
source code generation. It specifies design objects with sufficient detail to enable
source code generation.
systems and software engineering.
 The IDEF3 method provides modes to represent both
 Process Flow Descriptions to capture the relationships between actions
within the context of a specific scenario, and
 Object State Transition to capture the description of the allowable states and
conditions.

systems and software engineering.
 IDEF4 was developed as a design tool for software designers who use
object-oriented languages such as the Common LISP Object System, Flavors, C++,
SmallTalk, Objective C and others. Since effective usage of the object-oriented
paradigm requires a different thought process than used with conventional
procedural or database languages, standard methodologies such as structure charts,
data flow diagrams, and traditional data design models (hierarchical, relational, and
network) are not sufficient. IDEF4 seeks to provide the necessary facilities to
support the object-oriented design decision making process.
2.7. IDEF5 : Ontology description capture
 IDEF5 or Integrated Definition for Ontology Description Capture Method is

a software engineering method to develop and maintain usable, accurate, domain
ontologies. In the field of computer science ontologies are used to capture the
concept and objects in a specific domain, along with associated relationships and
meanings. In addition, ontology capture helps coordinate projects by standardizing
terminology and creates opportunities for information reuse. The lDEF5 Ontology
Capture MethodPROCESS
SOFTWARE has been developed
& QUALITYto reliably construct ontologies
MANAGEMENT– in a way that
Group Project 9
closely reflects human understanding of the specific domain.

 In the IDEF5 method, an ontology is constructed by capturing the content of
certain assertions about real-world objects, their properties, and their
interrelationships and representing that content in an intuitive and natural form.
The IDEF5 method has three main components: A graphical language to support
conceptual ontology analysis, a structured text language for detailed ontology
characterization, and a systematic procedure that provides guidelines for effective
ontology capture.
2.8. IDEF6 : Design rationale capture
 IDEF6 or Integrated Definition for Design Rationale Capture is a method to

facilitate the acquisition, representation, and manipulation of the design rationale
used in the development of enterprise systems. Rationale is the reason,
justification, underlying motivation, or excuse that moved the designer to select a
particular strategy or design feature. More simply, rationale is interpreted as the
answer to the question, “Why is this design being done in this manner?” Most

design methods focus on the what the design is (i.e., on the final product, rather
than why the design is the way it is).
 IDEF6 will be a method that possesses the conceptual resources and
linguistic capabilities needed (i) to represent the nature and structure of the
information that constitutes design rationale within a given system, and (ii) to
associate that rationale with design specifications, models, and documentation for
the system. The scope of IDEF6 applicability covers all phases of the information
system development process, from initial conceptualization through both
preliminary and detailed design activities. To the extent that detailed design
decisions for software systems are relegated to the coding phase, the IDEF6
technique should be usable during the software construction process as well.
2.9. IDEF7 : Information system auditing
2.10. IDEF8 : User interface modeling
 IDEF8 or Integrated Definition for Human-System Interaction Design is a

method for producing high-quality designs of the interactions that occur between
users and the systems they operate. Systems are characterized as a collection of
objects which perform functions to accomplish a particular goal. The system with
which the user interacts can be any system, not necessarily a computer program.
Human-system interactions are designed at three levels of specification within the
IDEF8 method. The first level defines the philosophy of system operation and
produces a set of models and textual descriptions of overall system processes. The
second level of design specifies role-centered scenarios of system use. The third
level of IDEF8 design is for human-system design detailing. At this level of
design, IDEF8 provides a library of metaphors to help users and designers specify
the desired behavior in terms of other objects whose behavior is more familiar.
Metaphors provide a model of abstract concepts in terms of familiar, concrete
objects and experiences.
2.11. IDEF9 : Business constraint discovery
 IDEF9 or Integrated Definition for Business Constraint Discovery is

designed to assist in the discovery and analysis of constraints in a business system.
A primary motivation driving the development of IDEF9 was an acknowledgment
that the collection of constraints that forge an enterprise system is generally poorly
defined. The knowledge of what constraints exist and how those constraints
interact is incomplete, disjoint, distributed, and often completely unknown. This
situation is not necessarily alarming. Just as living organisms do not need to be

aware of the genetic or autonomous constraints that govern certain behaviors,
organizations can (and most do) perform well without explicit knowledge of the
glue that structures the system. However, if the desire exists to modify the business
in a predictable manner, the knowledge of these constraints is as critical as
knowledge of genetics is to the genetic engineer. concepts in terms of familiar,
concrete objects and experiences.
2.12. IDEF10 : Implementation architecture modeling
2.13. IDEF11 : Information artifact modeling
2.14. IDEF12 : Organization modeling
2.15. IDEF13 : Three schema mapping design
2.16. IDEF14 : Network design
 IDEF14 or Integrated Definition for Network Design Method is a method

that targets at modeling and designing computer and communication networks. It
can be used to model existing ("as is") computer networks or envisioned ("to be")
computer
SOFTWARE networks. It helps&the
PROCESS network designer
QUALITY work with "what
MANAGEMENT– Groupif" potential
Project 11
network designs and document design rationale. The fundamental goals of the
IDEF14 method research project have developed from a perceived need for good
network designs that can be implemented quickly and accurately.
3. THE IDEF MODELING LANGUAGES

3.1. IDEF0 : for Function Modeling (purpose:description)
 IDEF0 models the decisions, actions, and activities of an organization or

system, in order to communicate the functional perspective of a system.
 IDEF0 models are created as one of the first tasks of a system

development effort because they describe:
• the functions that are performed,
• what is needed to perform those functions,
 IDEF0 was released as a standard for Function Modeling by the Computer

Systems Laboratory of the National Institute of Standards and Technology.
(1993)
 Syntax:
context PROCESS
SOFTWARE diagram: is&a QUALITY
model of the function at the highest
MANAGEMENT– Group level of inputs,
Project 12
controls, outputs, and mechanisms

Decomposition Diagram: links together the context diagrams

STRENGTHS
 The model has proven effective in detailing the system activities

for function modeling
 IDEF0 models provide an abstraction away from timing,

sequencing and decision logic. However, it is easy to use IDEF0 for
modeling activity sequences whenever needed.
(Order the activities from left to right in the decomposition

diagram).
 Provides a concise description of systems, by using the
ICOMS. (Inputs, Controls, Output, Mechanism)
 The hierarchical nature of IDEF0 allows the system to be easily

refined into greater detail until the model is as descriptive as
necessary for the decision making task.

WEAKNESSES
 IDEF models might be so concise that only the domain experts

can understand
 IDEF models are sometimes misinterpreted as representing
a sequence of activities.
 The abstraction away from timing, sequencing and decision
logic leads to comprehension difficulties for the people
outside the domain
EXAMPLE (source: [4])
3.2. IDEF1 : for Information Modeling (purpose:description)
IDEF1 is a method for both analyzing and communicating the structure and
semantics of information within a system.
IDEF1 models are used to:

 Identify what information is currently managed in a real-world system,
both automated system components, and
non-automated objects (e.g. people).
 Identify the rules for managing the information.
 Identify deficiencies information.
Specify what information will be managed in a TO-BE implementation.

(TO-BE implementation: Design of the functional architecture)
Main IDEF1 Concepts
 Entities: Represent the information maintained in a system about

the real-world objects
 Distinguishing properties:
Persistent
SOFTWARE PROCESSMay
& QUALITY MANAGEMENT– Group Project
be individuated 15
 Attributes:
Key
Non-key
 Relations: Association between entities

STRENGTHS
Modeling
 IDEF1 requires active participation of the information users,

which serves to accurately model where and how the information is
used managed
 An effective method for documenting the informational

requirements of an enterprise, providing a foundation for database
design
 IDEF1 enforces modularity that eliminates the
incompleteness, imprecision, inconsistencies, and
inaccuracies found in the modeling process.

3.2.1 IDEF1x- Data Modeling Method
IDEF1X is a method for designing relational databases.
IDEF1X Model: Graphical and Textual depiction of “What must I

know to do what I do?”
IDEF1X is most useful for logical database design after the information
requirements are known and the decision to implement a relational database
has been made.
IDEF1X was released as a standard for Data Modeling by the

Computer Systems Laboratory of the National Institute of Standards and
Technology. (1993)
EXAMPLE (ref:[2])

STRENGTHS
 Powerful tool for data modeling.
 IDEF1X don’t have numerous variants, unlike ER.
 Depicts the rules governing the management of information.
 Used to validate the concepts in the associated IDEF0 model.
 Helps to discover underlying causes for problems.
WEAKNESSES
 The modeler must be experienced in order to create good models.
 Not suited to serve as an AS-IS analysis tool.
3.2.2 IDEF1 (information Model) vs IDEF1x (Data Model)
Information Model Data Model

SOFTWARE
focuses on: PROCESS & QUALITY MANAGEMENT–
focuses on: Group Project 18
Information collected, stored, and Actual data elements in a relational

managed by the organization database
Logical relationships within the Representation & structure of the

organization reflected in the data
information
used for: used for:
Problem identification Logical design of databases &

applications
Requirements definition
The physical design of database
Information system design implementation
3.3. IDEF3 : for Process Modeling. (purpose:description)

“IDEF3 is a mechanism for collecting and documenting
processes...IDEF3 captures the behavioral aspects of an existing or
proposed system.” (temporal information, including precedence and
causality relationships associated with enterprise processes.)
“The resulting IDEF3 descriptions provide a structured knowledge

base for constructing analytical and design models. (unlike
simulation languages that build predictive mathematical models,
IDEF3 builds structured descriptions.)”
“These descriptions capture information about what a system

actually does or will do and also provide for the organization and
expression of different user views of the system.”
The development of an IDEF3 Process Flow Description consists of

expressing facts, collected from domain experts, in terms of five basic
descriptive building blocks
Organizing Structure: Scenario
A scenario can be thought of as a recurring situation, a set of situations that

describe a typical class of problems addressed by an organization or system,
or the setting within occurs.
Example

Scenario:
Parts enter the shop ready for the primer coat to be applied. We apply one
very heavy coat of primer paint at a very high temperature. The paint is
allowed to dry in a bake oven after which a paint coverage test is performed
on the part. If the test reveals that not enough primer paint has been sprayed
on the surface of the part, the part is re-routed through the paint shop again.
If the part passes the inspection, it is routed to the next stop in the process.
Process Description Diagram of the Example
Object State Transition Network of the Example

Other Example

Discussion
 The statement of IDEF3 sounds like …

3.4. IDEF4 : for Object-Oriented Design. (purpose:design)
IDEF4 method is designed to assist in creating object-oriented

programming software.
IDEF4 provides a framework for navigating an object-oriented

design.
IDEF4 divides the object-oriented design activity into discrete

chunks. A graphical syntax highlights the design decisions that must
be made and their impact on other perspectives of the design.
IDEF4 model consists of two submodels, the class submodel and the
method submodel. These two structures capture all the information
represented in a design model.

3.5. IDEF5 : for Ontology Description Capture.
An ontology is a domain vocabulary complete with a set of precise

definitions or axioms that constrain the meanings of the terms
sufficiently, to enable consistent interpretation of the data that use
that vocabulary.
General ontology construction steps:
1. catalog the terms;

2. capture the constraints that govern how those terms can be used
to make descriptive statements about the domain; and
3. build the model.
The IDEF5 ontology development process consists of the following activities.
DataCollection of raw data needed for ontology development.
Data Analysis to facilitate ontology extraction.
Initial Ontology Development to develop a preliminary ontology from the data

gathered.
Ontology Refinement and Validation

3.6. Rasmussen - Definition DesignMaps
Map1: Domain, tasks, and user incontext
Map 2: Knowledge base
Map3: Road maps for navigation
Map 4: Knowledge representation in design
Map 5: Display composition
3.7. Side by Side Comparison
3.8. Rasmussen Map 1 compared to IDEF0- Diagram
Decomposition Diagram: links together the context diagrams

3.9. Key
Both require an expert in the field touse and understand the model
This is a result of the method being a very high level concept and
developing the details for any single application is not a trivial
matter
SOFTWARE PROCESS
3.10. Advantage & QUALITY MANAGEMENT– Group Project
of IDEF
26
IDEF 5 attempts to incorporate the vocabulary of the specific application
4. REFERENCES
[1] What is Integration Definition (IDEF)? - Definition from Techopedia

[2] IDEF - Wikipedia

Software Process & Quality Management Group Project: Integration Definition (IDEF) Mentor: Truong Dinh Huy

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Process & Quality Management Group Project: Integration Definition (IDEF) Mentor: Truong Dinh Huy

Uploaded by

Copyright:

Available Formats

SOFTWARE PROCESS & QUALITY MANAGEMENT

Integration Definition (IDEF)

Mentor: Truong Dinh Huy