SOFTWARE PROCESS & QUALITY MANAGEMENT

GROUP PROJECT

Integration Definition (IDEF)

Version
SOFTWARE PROCESS & QUALITY : 1.0
MANAGEMENT– Group Project 1

Mentor: Huy, Truong Dinh

Team members:

 Trần Văn Khoa

 Nguyễn Anh Quốc
 Đỗ Đức Trung
 Phan Thanh Phú
 Nguyễn Trịnh Huy Quốc

International School, Duy Tan University

PROJECT INFORMATION

Integration Definition (IDEF)

 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
Instructor Email: huy.truongdinh@gmail.com
Phone: 0982.132.352
Nguyễn Anh Quốc Anhquoca5hht@gmail.com 0868077665
Trần Văn Khoa lyhoang20012000@gmail.com 0856402080
Team Members Nguyễn Trịnh Huy Quốc quoc3803@gmail.com 0901983180
Phan Thanh Phú tthanhphu84@gmail.com 0856464622
Đỗ Đức Trung doductrung142@gmail.com 0829501402

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 2

Contents
1. INTRODUCTION..................................................................................................................6
1.1. What is a Process ?............................................................................................................7
1.2. What is process improvement...........................................................................................7
1.3. Purpose of process improvement......................................................................................7

Integration Definition (IDEF)

 1.4. Benefits of process improvement......................................................................................7
1.4.1. Increase productivity.................................................................................................7
1.4.2. Employee satisfaction................................................................................................7
1.4.3. Reduce risk................................................................................................................7
1.4.4. Compliance................................................................................................................7
1.4.5. Customer satisfaction.................................................................................................7
1.4.6. Agile..........................................................................................................................7
1.4.7. Technology integration..............................................................................................7
2. OVERVIEW OF IDEF METHODS.....................................................................................6
2.1. What Does Integration Definition (IDEF) Mean?................................................................7
2.2. IDEF History.........................................................................................................................7
2.3. Purpose of IDEF....................................................................................................................7
2.4. Techopedia Explains Integration Definition (IDEF)............................................................7
3. THE IDEF MODELING LANGUAGES.............................................................................6
3.1. IDEF0 : Function modeling..............................................................................................7
3.2. IDEF1 : Information modeling.........................................................................................7
3.3. IDEF1X : Data modeling..................................................................................................7
SOFTWARE PROCESS
3.4. IDEF2 : Simulation & QUALITY
model MANAGEMENT– Group Project
design.....................................................................................7 3

3.5. IDEF3 : Process description capture.................................................................................7

3.6. IDEF4 : Object-oriented design........................................................................................7
3.7. IDEF5 : Ontology description capture..............................................................................7
3.8. IDEF6 : Design rationale capture......................................................................................7
3.9. IDEF7 : Information system auditing...............................................................................7
3.10. IDEF8 : User interface modeling..................................................................................7
3.11. IDEF9 : Business constraint discovery.........................................................................7
3.12. IDEF10 : Implementation architecture modeling..........................................................7
3.13. IDEF11 : Information artifact modeling.......................................................................7
3.14. IDEF12 : Organization modeling..................................................................................7
3.15. IDEF13 : Three schema mapping design......................................................................7
3.16. IDEF14 : Network design..............................................................................................7
4. NATURE AND IMPORTANCE OF METHODS...............................................................6
4.1. IDEF0 : for Function Modeling (purpose:description).....................................................6
4.1.1. Strengths and Weaknesses of IDEF0.........................................................................7

Integration Definition (IDEF)

 4.2. IDEF1: for Information Modeling (purpose:description).................................................6
4.2.1. IDEF1x- Data Modeling Method...............................................................................7
4.2.2. IDEF1 (information Model) vs IDEF1x (Data Model).............................................7
4.3. IDEF2 : for Simulation Modeling. (purpose:description).................................................6
4.4. IDEF3 : for Process Description Capture. (purpose:description).....................................6
4.4.1. Organizing Structure: Scenario..................................................................................7
4.4.2. Example.....................................................................................................................7
4.5. IDEF4 : for Object-Oriented Design. (purpose:design)....................................................6
4.6. IDEF5 : for Ontology Description Capture. (purpose:design)..........................................6
4.7. Effectiveness.....................................................................................................................6
4.7.1. Advantage of IDEF....................................................................................................7
4.7.2. Disadvantage of IDEF...............................................................................................7
5. COMPARE IDEF AND UML...............................................................................................6
5.1. What is UML ?..................................................................................................................7
5.2. The similarities between IDEF and UML.........................................................................7
5.3. The difference between IDEF and UML..........................................................................7
6. CONCLUSION.......................................................................................................................6
7. SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project
REFERENCES.......................................................................................................................6 4

8. TEAM ORGANIZATION.....................................................................................................7
8.1. Team information..............................................................................................................7
8.2. Duty Roster.......................................................................................................................7

Integration Definition (IDEF)

Figure
Y
Figure 1 : Develop System ( IDEF0 Model)..........................................................................21
Figure 2 : Decomposition Diagram (links together the context diagrams)..........................22
Figure 3 : IDEF0 diagram of the simple selling process......................................................23
Figure 4 : IDEF1 Origins.......................................................................................................24
Figure 5 : Basic Data Mode....................................................................................................26
Figure 6 : IDEF1X Origins....................................................................................................26
Figure 7 : IDEF3 Object State Description...........................................................................30
Figure 8 : Process Description Diagram of the Example 1..................................................29
Figure 9 : Process Description Diagram of the Example 2..................................................30
Figure 10 : IDEF3 process flow diagram of the “Order Processing” activity.....................31
Figure 11 : IDEF3 model of an R&D project........................................................................31
Figure 12 : IDEF3 a good way to reference models ?...........................................................32
Figure 13 : IDEF4 Model.......................................................................................................33
Figure 14 : The IDEF Modeling Cycle..................................................................................34

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 5

Tabl

Table 1 : The IDEF languages ( Based on ( Cho, 2000 ))....................................................13

Table 2 : Strengths and Weaknesses of IDEF0.....................................................................24
Table 3 : Strengths and Weaknesses of IDEF1X..................................................................28
Table 4 : Compare IDEF1 and IDEF1X...............................................................................28
Table 5 : UML Language Components..................................................................................38
Table 6 : UML and IDEF.......................................................................................................41
Table 7 : Team Information...................................................................................................42
Table 8 : Work Assignment Table..........................................................................................43

Integration Definition (IDEF)

1. INTRODUCTION

1.1. What is a Process ?

A process is a series of steps and decisions involved in the way work is completed.
We may not realize it, but processes are everywhere and in every aspect of our leisure
and work
1.1. What is process improvement
Software Process Improvement methodology is defined as a sequence of tasks, tools,
and techniques to plan and implement improvement activities to achieve specific goals
such as increasing development speed, achieving higher product quality or reducing
costs.
Process improvement is the practice of optimizing existing business processes in order
to meet best market standards and improve customer experience.
The main goals of process improvement are minimizing errors, reducing waste,
improving productivity and streamlining the efficiency of internal and external processes
ofSOFTWARE
a company PROCESS & QUALITY MANAGEMENT– Group Project 6
1.2. Purpose of process improvement
Constant innovation and growth are the new normal for any company that wants to
meet customer needs in today’s fast-paced world. Organizations have to quickly adjust
their strategies and processes as well as develop new ones. This is why continuous
process improvement, becomes an integral part of business operations.
Process improvement aims to eliminate weak points or bottlenecks in business
operations. By identifying those weak points, you help your business: Reduce process
completion time. Improve process efficiency and quality
1.3. Benefits of process improvement
1.3.1. Increase productivity
The proactive task of identifying, analyzing and improving upon existing business
processes within an organization for optimization and to meet new quotas or standards of
quality.

Integration Definition (IDEF)

 1.3.2. Employee satisfaction
Well-developed business processes help motivate team members who generally aren’t
interested in wasting time or money. Process Improvement cuts down on tedious,
repetitive tasks that eat up critical working hours and brainpower.
Employees can focus on job functions they care about instead of searching endlessly
for documents and manually entering data. Smoother procedures lead to a happier
workforce, resulting in higher productivity and revenue

1.3.3. Reduce risk

Maybe your employees manually transfer information between systems, resulting in
mistakes that take hours to fix.
Manual systems lack controls, increasing the risk of fraud and human error. Non-IT
employees often manage data entry tasks but aren’t familiar with storage and backup best
practices.
Business process improvement helps you highlight activities to automate, reducing
human error and adding additional security measures to protect company data.
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 7

1.3.4. Compliance
Is maintaining compliance a constant headache for your business? If you don’t have a
flexible system in place to handle end-to-end compliance, you could face unforeseen
penalties.
With Process Improvement, your third-party consultant thoroughly documents all
compliance-related procedures, policies and internal controls. By building compliance
into your new business processes, you can create transparency and quickly implement
regulatory requirements, preventing delays in compliance and fines

1.3.5. Customer satisfaction

By upgrading your technology solutions and cutting down time spent on administrative
tasks, your employees are free to focus on real-time collaboration with customers.
Employees will have greater capacity to respond to customer requests, build proposals

Integration Definition (IDEF)

 and customize solutions faster. They will have more time to focus on activities that
deliver results for clients, increasing customer satisfaction.

1.3.6. Agile
Nimble processes are critical for staying competitive. With Process Improvement, you
can constantly improve processes to adapt to changing business needs. Why reinvent the
wheel every time you experience change? Process Improvement focuses on implementing
flexible processes that are easy to adapt and deploy as your business needs evolve .

1.3.7. Technology integration

Business process improvement outlines which software and applications align best
with your organizational requirements. Depending on your industry and business needs,
the best solution might be a commercially available software or a custom web
application. New technology will support your new business processes, from data entry to
employee collaboration
2. OVERVIEW OF IDEF METHODS
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 8
2.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.
2.2. IDEF History
IDEF originally stood for ICAM Definition, initiated in the 1970s at the US Air Force
Materials Laboratory, Wright-Patterson Air Force Base in Ohio by Dennis E. Wisnosky,
Dan L. Shunk, and others.[12] and completed in the 1980s. IDEF was a product of the
ICAM initiative of the United States Air Force. The IEEE recast the IDEF abbreviation
as Integration Definition."[2]

Integration Definition (IDEF)

 The specific projects that produced IDEF were ICAM project priorities 111 and 112
(later renumbered 1102). The subsequent Integrated Information Support System (IISS)
project priorities 6201, 6202, and 6203 attempted to create an information processing
environment that could be run in heterogeneous physical computing environments.
Further development of IDEF occurred under those projects as a result of the experience
gained from applications of the new modeling techniques. The intent of the IISS efforts
was to create 'generic subsystems' that could be used by a large number of collaborating
enterprises, such as U.S. defense contractors and the armed forces of friendly nations.
At the time of the ICAM 1102 effort there were numerous, mostly incompatible, data
model methods for storing computer data — sequential (VSAM), hierarchical (IMS),
network (Cincom's TOTAL and CODASYL, and Cullinet's IDMS). The relational data
model was just emerging as a promising way of thinking about structuring data for easy,
efficient, and accurate access. Relational database management systems had not yet
emerged as a general standard for data management.
The ICAM program office deemed it valuable to create a "neutral" way of describing
theSOFTWARE PROCESS
data content of large-scale&systems.
QUALITY The MANAGEMENT– Group Project
emerging academic literature suggested that 9

methods were needed to process data independently of the way it was physically stored.
Thus the IDEF1 language was created to allow a neutral description of data structures
that could be applied regardless of the storage method or file access method.
IDEF1 was developed under ICAM program priority 1102 by Robert R. Brown of the
Hughes Aircraft Company, under contract to SofTech, Inc. 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 but IBM, which had served as
a support contractor during development, subsequently took over the product and was
successful in further developing it for market. Brown credits his Hughes colleague
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:

Integration Definition (IDEF)

  The evolving natural language information model (ENALIM) technique of 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 Charles Bachman (Honeywell Information Systems);
 The hierarchical data management technique, implemented in IBM's IMS data
management system, developed by R. R. Brown (Rockwell International);
 The relational approach to data of E. F. Codd (IBM);
 The entity-relationship approach (E-R) of Peter Chen (UCLA).
The effort to develop IDEF1 resulted in both a new method for information modeling
and an example of its use in the form of a "reference information model of
manufacturing." This latter artifact was developed by D. S. Coleman of the D. Appleton
Company (DACOM) acting as a sub-contractor to Hughes and under the direction of
Ramey. Personnel at DACOM became expert at IDEF1 modeling and subsequently
produced a training course and accompanying materials for the IDEF1 modeling
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 10
technique.
Experience with IDEF1 revealed that the translation of information requirements into
database designs was more difficult than had originally been anticipated. The most
beneficial value of the IDEF1 information modeling technique was its ability to represent
data independent of how those data were to be stored and used. It provided data modelers
and data analysts with a way to represent data requirements during the requirements-
gathering process. This allowed designers to decide which DBMS to use after the nature
of the data requirements was understood and thus reduced the "misfit" between data
requirements and the capabilities and limitations of the DBMS. The translation of IDEF1
models to database designs, however, proved to be difficult.
2.3. Purpose of IDEF
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.

Integration Definition (IDEF)

 2.4. 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
applications utilize IDEF on a daily basis.
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.

SOFTWARE
3. THE PROCESSLANGUAGES
IDEF MODELING & QUALITY MANAGEMENT– Group Project 11

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
In 1995 only the IDEF0, IDEF1X, IDEF2, IDEF3 and IDEF4 had been developed in
full. Some of the other IDEF concepts had some preliminary design. Some of the last
efforts were new IDEF developments in 1995 toward establishing reliable methods for
business constraint discovery IDEF9, design rationale capture IDEF6, human system,
interaction design IDEF8, and network design IDEF14.
The methods IDEF7, IDEF10, IDEF11, IDEF 12 and IDEF13 haven't been developed
any further than their initial definition.

Integration Definition (IDEF)

 Table 1 : The IDEF languages ( Based on ( Cho, 2000 ))
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 12

3.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

Integration Definition (IDEF)

 comprehensive methodology for developing models. The US Air Force commissioned
the SADT developers to develop a 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.
3.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
SOFTWARE
time. PROCESS
In particular, & QUALITY
IDEF1 draws MANAGEMENT–
on the following techniques: Group Project 13

 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).
3.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

Integration Definition (IDEF)

 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 information systems,
and the building of computer databases. This standard is part 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.
3.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
SOFTWARE PROCESS
a manufacturing & QUALITY
system, providing MANAGEMENT–
a framework for specificationGroup Project
of math model based 14

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.
3.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.

Integration Definition (IDEF)

 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 engineering.
3.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.
This method is part of the IDEF family of modeling languages in the field of systems
SOFTWARE
and PROCESS & QUALITY MANAGEMENT– Group Project
software engineering. 15

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 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

Integration Definition (IDEF)

 models (hierarchical, relational, and network) are not sufficient. IDEF4 seeks to provide
the necessary facilities to support the object-oriented design decision making process .
3.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 Method has been developed to
reliably construct ontologies in a way that 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
SOFTWARE
structured PROCESSfor& QUALITY
text language MANAGEMENT–
detailed ontology Group
characterization, andProject
a systematic
16

procedure that provides guidelines for effective ontology capture.

3.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

Integration Definition (IDEF)

 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.

3.9. IDEF7 : Information system auditing

An Information System Audit or information technology audit is an examination of the
controls within an entity's Information technology infrastructure. These reviews may be
performed in conjunction with a financial statement audit, internal audit, or other form of
attestation engagement. It is the process of collecting and evaluating evidence of an
organization's information systems, practices, and operations. Obtained evidence
evaluation can ensure whether the organization's information systems safeguard assets,
maintains data integrity, and are operating effectively and efficiently to achieve the
organization's goals or objectives
SOFTWARE
3.10. PROCESS
IDEF8 : User interface & QUALITY MANAGEMENT– Group Project
modeling 17

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.

Integration Definition (IDEF)

3.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.
3.12. IDEF10 : Implementation architecture modeling
The architectural model is the product of the process and information analysis that has
SOFTWARE
occurred with thePROCESS & QUALITY
business sponsors MANAGEMENT–
and subject Group
area owners. The Project of the
organization 18

architectural model is high-level service functions and processes, with the associated
subject area clustering of business entity types. The information content of the
architectural model is transferred to the enterprise logical model as a one-time starting
point. From then on, business changes are transferred from the architectural model to a
logical modeling tool staging model before being exported to the enterprise business
logical model. Architectural models focus on supporting particular functions in the
network.
3.13. IDEF11 : Information artifact modeling
An Information Artifact Model shows how tangible elements (physical or electronic)
are used and structured in the business process flow of doing the work. Work artifacts are
one of the most important entities that get passed from one work role to another within
the flow model. Examples include paper memos, email messages, correspondence
templates, product change orders, and other things people create and use while working.

Integration Definition (IDEF)

 Sometimes artifacts are work products, information objects used in daily operation of the
enterprise, for example, an order form being filled out, that reveal traces of people's work
practices. The contextual inquiry team must pay close attention to how these artifacts are
created, communicated, and used.
3.14. IDEF12 : Organization modeling
Organizational modelling is a technique for describing the roles and reporting structure
within a business and ensuring that the structure supports the goals of the business.
Organizational models or charts are usually designed by grouping people with a common
set of objectives
3.15. IDEF13 : Three schema mapping design
Three-schema architecture is an idea in relational database design that breaks a
database down into three different categories according to its use and structure, and to the
roles played by system administrators, designers and end users.
3.16. IDEF14 : Network design
IDEF14 or Integrated Definition for Network Design Method is a method that targets
at SOFTWARE
modeling and PROCESS & QUALITY
designing computer MANAGEMENT–
and communication Group
networks. It Project
can be used to 19

model existing ("as is") computer networks or envisioned ("to be") computer networks. It
helps the network designer work with "what if" potential 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.
4. NATURE AND IMPORTANCE OF METHODS

4.1. IDEF0 : for Function Modeling (purpose:description)

The IDEFØ Function Modeling method is designed to model the decisions, actions,
and activities of an organization or system.
IDEFØ was derived from a well-established graphical language known as the
Structured Analysis and Design Technique (SADT).
The Air Force commissioned the developers of SADT to develop a function modeling
method for analyzing and communicating the functional perspective of a system.

Integration Definition (IDEF)

 Effective IDEFØ models assist in organizing system analysis and promoting effective
communication between the analyst and the customer. In addition, the IDEFØ modeling
method establishes the scope of analysis either for a particular functional analysis or for
future analyses from another system perspective. As a communication tool, IDEFØ
enhances domain expert involvement and consensus decision-making through simplified
graphical devices.
As an analysis tool, IDEFØ assists the modeler in identifying functions performed,
what is needed to perform those functions, what the current system does correctly, and
what the current system does incorrectly. Thus, IDEFØ models are often created as one
of the first tasks of a system development effort.

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 20

Figure 1 : Develop System ( IDEF0 Model)

Integration Definition (IDEF)

 Figure 2 : Decomposition Diagram (links together the context diagrams)

4.1.1. Strengths and Weaknesses of IDEF0

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 21
Strengths Weaknesses
 The model has proven effective in  IDEF models might be so concise
detailing the system activities for that only the domain experts can
function modeling understand
 IDEF0 models provide an abstraction  IDEF models are sometimes
away from timing, sequencing and misinterpreted as representing a
decision logic. However, it is easy to sequence of activities.
use IDEF0 for modeling activity  The abstraction away from timing,
sequences whenever needed. sequencing and decision logic leads
 ICOMS. (Inputs, Controls, Output, to comprehension difficulties for the
Mechanism) people outside the domain
 The hierarchical nature of IDEF0
allows the system to be easily refined
into greater detail until the model is

Integration Definition (IDEF)

 as descriptive as necessary for the
decision making task.
 Provides a concise description of
systems, by using the
 (Order the activities from left to right
in the decomposition diagram).

Table 2 : Strengths and Weaknesses of IDEF0

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 22

Figure 3 : IDEF0 diagram of the simple selling process

4.2. IDEF1: for Information Modeling (purpose:description)

The IDEF1 information modeling method derives its foundations from three primary
sources: Entity-Link-Key-Attribute (Figure 4)
The original intent of IDEF1 was to capture what information exists or should be
managed about objects within the scope of an enterprise. The IDEF1 perspective of an
information system includes not only the automated system components but also non-
automated objects such as people, filing cabinets, telephones, etc. IDEF1 was specifically
designed to not be a database design method.
At the time of IDEF1 development, the database community believed that a method
for analyzing and stating information resource management needs and requirements was
needed.

Integration Definition (IDEF)

 This was the intent of IDEF1. Rather than a design method, IDEF1 is an analysis
method used to identify the following:
 The information collected, stored, and managed by the enterprise.
 The rules governing the management of information.
 Logical relationships within the enterprise are reflected in the information.
 Problems resulting from the lack of good information management.
The results of information analysis can be used by strategic and tactical planners
within the enterprise to leverage the information assets to achieve a competitive
advantage.
Part of these plans may include the design and implementation of automated systems
which can more effectively take advantage of the information available to the enterprise.

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 23

Figure 4 : IDEF1 Origins

Integration Definition (IDEF)

 IDEF1 models provide the basis for those design decisions. IDEF1, then, is not used to
design a database; rather, it is used to provide managers with the insight and knowledge
required to establish a good information management policy.

4.2.1. IDEF1x- Data Modeling Method

In Figure 1, IDEF1X is intended as a method for accomplishing the Design System
activity. Because it is a design method, IDEF1X is not particularly suited to serve as an
“AS-IS” analysis method, although it is often suggested as an alternative to IDEF1.
IDEF1X is most useful for logical database design after the information requirements
are known and the decision to implement using a relational database has been made.
Hence, the IDEF1X perspective of the information system is focused on the actual data
elements in a relational database.
If the target system is not a relational system, e.g., an object-oriented system, IDEF1X
is not the best method.
The development of IDEF1X was influenced by Chen’s Entity-Relationship (ER)
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 24
model, Codd’s Relational model, and Smith’s Aggregation/Generalization model.
These origins led to the development of the Logical Database Design Technique
(LDDT) by the Database Design Group, Inc. LDDT later became a commercial product
of Dan Appleton Company (DACOM) as the Data Modeling Technique (DMT).
A coalition of companies led by General Electric including SDRC, CDC, and
DACOM used this method and their experience with IDEF1, to create the IDEF Data
Modeling Method, or IDEF1X (See Figure 5).

Integration Definition (IDEF)

 Figure 5 : Basic Data Mode

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 25

Figure 6 : IDEF1X Origins

IDEF1X was released as a standard for Data Modeling by the Computer Systems
Laboratory of the National Institute of Standards and Technology.(1993)

Integration Definition (IDEF)

 4.2.1.1 Strengths and Weaknesses of IDEF1X
Strengths Weaknesses
 Powerful tool for data modeling.  The modeler must be experienced in
 IDEF1X don’t have numerous order to create good models.
variants, unlike ER.  Not suited to serve as an AS-IS
 Depicts the rules governing the analysis tool.
management of information.
 Used to validate the concepts in the
associated IDEF0 model.
 Helps to discover underlying causes
for problems
Table 3 : Strengths and Weaknesses of IDEF1X

4.2.2. IDEF1 (information Model) vs IDEF1x (Data Model)

Information Model Data Model
SOFTWARE
Focuses on: PROCESS & QUALITY MANAGEMENT–
Focuses on: Group Project 26

-Information collected, stored, and -Actual data elements in a relational

managed by the organization database
-Logical relationships within the -Representation & structure of the data
organization reflected in the information
Used for: Used for:
-Problem identification -Logical design of databases &
-Requirements definition applications
-Information system design -The physical design of database
implementation
Table 4 : Compare IDEF1 and IDEF1X

4.3. IDEF2 : for Simulation Modeling. (purpose:description)

The potential for benefits from the use of simulation modeling for manufacturing and
information system analysis, planning, and design have been well established over the

Integration Definition (IDEF)

past 20 years. As a result, more and more decision-makers turn to simulation to study the
complex interactions and the dynamic behaviors of integrated manufacturing systems.
Simulation modeling is a powerful decision support tool that aids in solving complex
problems in a variety of application domains. Simulation is useful when:
 The cause of a problem is the result of a complex time-dependent interaction
among the components of the system.
 The effect of a change to an existing system needs to be analyzed.
 A proposed system does not exist.
 Options to improve or measure system performance need to be quantified.
 Other quantitative analytic methods are computationally intractable.
Simulation allows one to ask “what if” questions and to derive new information from
existing knowledge.
The simulation activity, coupled with the evaluation of alternate designs and courses of
action, can lead to a better understanding of system operations and management policies.
The widespread use of simulation as effective manufacturing or system development
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 27
decision aid has been thwarted by the requirement for extensive training and skill in the
design and use of the simulation modeling technique.
The frustration of simulation has been that domain experts who know how their
systems operate, and who can describe in detail the system operation, have been unable to
take advantage of simulation modeling.
These experts have relied on experienced simulation analysts to design and develop
the simulation model.
The success of simulation activities depends on :
1) How well the expert can describe the system to a simulation expert
2) How well the simulation analyst can understand that system
3) The effectiveness of accurately translating systems descriptions and goals to a
simulation model.

Integration Definition (IDEF)

 IDEF2 is focused on improving the productivity of the simulation modeler by
improving the ability of the simulation modeler to communicate model assumptions and
designs to the domain expert.
Thus IDEF2 is a simulation model design tool that provides a language for
representing models of the time-varying behavior of resources in a manufacturing system,
providing a framework for the specification of math model-based simulations.
IDEF2 was designed to improve the process of design of representative simulation
models that can be executed to predict what a system will do under specific conditions.
4.4. IDEF3 : for Process Description Capture. (purpose:description)
IDEF3 is a scenario-driven process flow modeling method created specifically for
these types of descriptive activities.
IDEF3 is based upon the concept of direct capture of descriptions of the precedence
and causality relations between situations and events in a form that is natural to domain
experts in an environment.
The goal of IDEF3 is to provide a structured method for expressing the domain
SOFTWARE
expert’s PROCESS
knowledge about how&aQUALITY MANAGEMENT–
particular system or organization Group
works. Project 28

An IDEF3 description can be used to provide the data for many purposes including the
following :
 To provide a systematic method for recording and analyzing the raw data that
results from fact-finding interviews in a systems analysis project.
 To determine the impact of an organization’s information resource on the major
operating scenarios of an enterprise.
 To provide a mechanism for documenting the decision procedures affecting the
states and life-cycle of critical shared data (particularly manufacturing,
engineering, maintenance, and product definition data).
 To define data configuration management and change control policy definition.
 To support system design and design tradeoff analysis.
 To provide powerful mechanisms to support the generation of simulation
models.

Integration Definition (IDEF)

  To provide useful information for the creation of functional (IDEFØ) models.
 To facilitate process mapping for the design of software to achieve real-time
control by providing a mechanism for clearly defining the facts, decision points,
and job classifications.
 To provide an analyst with a method to clearly define the data needed to
develop needs and requirements from a user viewpoint.
 To collect and express the views of domain experts required for the
development of expert systems.
The IDEF3 Process Description Capture Method is used by systems developers to
capture domain expert knowledge about the “behavioral” aspects of an existing or
proposed system.
Process knowledge captured using IDEF3 is structured within the context of a
scenario, making IDEF3 an intuitive knowledge acquisition device for describing a
system.
Unlike IDEFØ models which adopt a single perspective of the system and explicitly
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 29
remove all temporal logic to promote generality and simplification, IDEF3 serves to
structure different user descriptions of the temporal precedence and causality
relationships associated with enterprise processes.
The resulting IDEF3 descriptions provide a structured knowledge base from which
analysis and design models can be constructed.
The development of IDEF3 was motivated by the need to distinguish between
descriptions of what a system is supposed to do and mathematical idealizations, or
models, that predict what a system will do.
The IDEF2 Simulation Modeling Method and a host of other simulation languages
(e.g., QGERT, SLAM, etc.) are targeted at satisfying the latter concern. Such languages
represent the time-varying behavior of system resources and provide a framework for the
specification of math model-based simulations. I
DEF3 addresses the former concern as a language for the organization and expression
of different user views of the system.

Integration Definition (IDEF)

 Figure 7 : IDEF3 Object State Description

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 30

The organizational principles and concepts upon which IDEF3 is based come from
pioneering work by : Dr. Shir Nijssen , Dr. Jon Barwise , Dr. Nijssen promoted the notion
that an information system is the embodiment of a discourse situation between agents in
an organization.

4.4.1. 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.

4.4.2. Example
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

Integration Definition (IDEF)

 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.
Object State Transition Network of the Example :

Figure 8 : Process Description Diagram of the Example 1

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 31

Figure 9 : Process Description Diagram of the Example 2

Integration Definition (IDEF)

 Figure 10 : IDEF3 process flow diagram of the “Order Processing” activity

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 32

Figure 11 : IDEF3 model of an R&D project

Integration Definition (IDEF)

 Figure 12 : IDEF3 a good way to reference models ?

4.5. IDEF4 : for Object-Oriented Design. (purpose:design)

Like IDEF1X, IDEF4 (Object-oriented Design Method) is intended to be used as a
design method for automated systems implementation.
SOFTWARE PROCESS
IDEF4, however, & QUALITY
targets the MANAGEMENT–
use of object-oriented Group
technology, ratherProject
than relational
33

technology, for the target implementation.

The emergence of object-oriented philosophy and development practice have
demonstrated the ability to produce code that exhibits desirable life-cycle qualities such
as modularity, maintainability, and reusability.
Likewise, the object-oriented programming paradigm has demonstrated major
advancements in the ease with which software code can be created, enabling more people
to successfully produce code.
The goal of IDEF4 [Edwards 89] is to assist in the correct application of the Object-
oriented Programming (OOP) paradigm to ensure consistent benefits from that
technology
There are five diagram types used within IDEF4 to express the structure of the data
object classes, inheritance relations, methods, and protocol of an object-oriented design.
The following is a list of these diagrams and a brief description of their purpose :

Integration Definition (IDEF)

  Inheritance Diagrams specify the inheritance relations among classes.
 Type Diagrams specify relations among classes defined through attributes of
one class having instances of another class as values.
 Protocol Diagrams specify the protocol for method invocation.
 Method Taxonomy Diagrams classify method types by behavior similarity and
links between class features and method types.
 Client Diagrams illustrate clients and suppliers of methods.
There are also two specialized Data Sheets that accompany the diagrams :
1. Class Invariant Data Sheets (specify constraints which apply to every instance
of a particular class of objects),
2. Contract Data Sheets (specify contracts that the methods in a method set must
satisfy).

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 34

Integration Definition (IDEF)

 SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 35

Figure 13: IDEF4 Model

4.6. IDEF5 : for Ontology Description Capture. (purpose:design)

IDEF5 is targeted at the construction of reference models that can be used as a basis
for both manual and automated identification of these similarities.
IDEF5 can also be used as a precursor to enterprise information analysis. It provides a
structure for recording and organizing the raw knowledge about physical and conceptual
objects along with their natural associations.
This fact base can then be used as the basis for a variety of analysis purposes
(including determination of the information implications of these concepts).

Integration Definition (IDEF)

 Finally, ontological analysis has been demonstrated to be an effective first step in the
construction of robust knowledge-based systems.
The current generation of CIM implementations will be taking advantage of
knowledge-based and expert systems technology.
IDEF5 provides a method for the initial knowledge acquisition for these systems. It
also provides a representation of that knowledge that is independent of any particular
implementation shell.
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.
SOFTWARE PROCESS
The IDEF5 ontology & QUALITY
development processMANAGEMENT– Group
consists of the following Project
activities. 36

 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

Integration Definition (IDEF)

 Figure 14 : The IDEF Modeling Cycle

4.7. Effectiveness
4.7.1. Advantage
SOFTWARE of IDEF& QUALITY MANAGEMENT– Group Project
PROCESS 37
 IDEF 5 attempts to incorporate the vocabulary of the specific application
 IDEF is a well documented robust standard that can be used without having to
defend the technique.
 The documentation is freely available and standardised.
 IDEF is industry as well as technology independent and ha proven to be used in
almost every possible context.
 Many tools are available to support IDEF modelling.
 IDEF makes use of a limited set of notation.
 A person can be taught how to read IDEF diagrams within less than half an hour.
– IDEF specifies a formal methodology for naming processes, diagrams and for
providing feedback on diagrams.
 IDEF0 and IDEF3 give two views on the process from different perspectives
allowing the one perspective to influence the other perspective.

Integration Definition (IDEF)

  IDEF3 allows an easy mechanism for capturing process information while IDEF0
provides a good tool for process design.
 IDEF0 is incredibly rich in information and glue together all the other architecture
domains as they impact on the process
 IDEF0 focus rightly on the value of the output of a process to ensure that the
design is purposive.
 IDEF3 provides an excellent temporal perspective on the process allowing you to
define all time related interdependencies to ensure the implementation of a solution is
practical and feasible.
 IDEF3 allows for detailed descriptions that makes the reading of the diagrams
easier.
 IDEF0 offers a controlled manner for drilling down from high level views to more
detail views so that the integrity of the design can be checked at each step
 Business people usually relates quickly and easily to IDEF if the techniques is
correctly introduced. 
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 38
4.7.2. Disadvantage of IDEF
 IDEF was developed long before case tools evolved and it is sometimes difficult
to integrate different IDEF techniques
 IDEF is a business analysis tool and not a very good system development
methodology (UML is a better system development support language – I like to
combine the two techniques)
 The top level diagrams in IDEF0 can easily get confusing and complex. Many
people has an initial shock reaction when they see the diagram
 Like all graphical presentations IDEF is limited in the number of nodes allowed
per page.
 Getting input from subject matter experts require that the facilitator understand all
the details of IDEF modeling and who applies the IDEF tchnique set with rigor. –
IDEF0 requires consistency between different levels of modelling which is
sometimes difficult to maintain.

Integration Definition (IDEF)

  Many software support tools does not support the IDEF numbering notation
which makes it difficult to maintain.
 Some people struggle to unite IDEF with object oriented analysis methodologies.
– Other techniques like BPML is more focused on supporting business process
management technologies than IDEF
 Some business process analysis tools like Aris does not really support the IDEF
method of thinking.

5. COMPARE IDEF AND UML

5.1. What is UML ?

The Unified Modelling Language (UML) originates in three modelling method
streams, represented by Booch (Booch, 1991), Jacobson (Jacobson, 1994) and Rumbaugh
(Rumbaugh et al., 1991).

UML has been subsequently complemented by the Unified Process (Jacobson et al.,
SOFTWARE
1999) - a softwarePROCESS & QUALITY
development methodologyMANAGEMENT–
based on an iterativeGroup Project
development 39

paradigm.

UML is a standardized modeling language consisting of an integrated set of diagrams,

developed to help system and software developers for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems. The UML represents a collection of best
engineering practices that have proven successful in the modeling of large and complex
systems. The UML is a very important part of developing object oriented software and
the software development process. The UML uses mostly graphical notations to express
the design of software projects. Using the UML helps project teams communicate,
explore potential designs, and validate the architectural design of the software.

Integration Definition (IDEF)

 Table 5 : UML Language Components

5.2. The similarities between IDEF and UML

-Both the UML and IDEF approaches may be used to model almost any useful view of
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project
a business 40

-The UML and IDEF sets of languages characterize typical modelling approaches of
software engineering and integrated computer-aided manufacturing.

5.3. The difference between IDEF and UML

IDEF
Definition IDEF comprises a suite of graphical
modelling techniques designed to
formally specify and communicate
important aspects of enterprise
engineering projects
UML
UML is a modelling language that can
be used to generate computer-
executable models that encode key
aspects of software engineering
projects.

History -IDEF originally stood for ICAM -UML(1999s) is a 'young' modelling

Definition, initiated in the 1970s at language compared to the IDEF

Integration Definition (IDEF)

 the US Air Force Materials
Laboratory, Wright-Patterson Air
Force Base in Ohio by Dennis E.
Wisnosky, Dan L. Shunk, and others. (UML) originates in three main
and completed in the 1980s. IDEF
was a product of the ICAM initiative
of the United States Air Force. The
IEEE recast the IDEF abbreviation as et al., 1991) and Jacobson (Jacobson,
Integration Definition."
-The IDEF language family has
around 30 years of development and
a few US governmental bodies
behind it (e.g. Department of
Defence, the US Air Force, etc).
Content IDEF comprises a suite of graphical
modelling techniques designed to
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project
formally specify and communicate
important aspects of enterprise
engineering projects
Background IDEF is coming from the
manufacturing / information
environment and aims to cover
object orientation, knowledge
representation and software
development
Positive side -The documentation is freely
available and standardised.
-IDEF is industry as well as
technology independent and ha
proven to be used in almost every
possible context.
-Many tools are available to support
Integration Definition (IDEF)
(1970s), aimed mostly towards
software development.
-The Unified Modelling Language
modelling methods within the
industry, represented by Booch
(Booch, 1991), Rumbaugh (Rumbaugh
1994) . UML has been subsequently
complemented by an Unified Process
(Jacobson et al., 1999) based on an
iterative development paradigm. In
fact, the UML is a set of essentially
graphical languages expressed via
diagrams.
UML is a modelling language that can
be used to generate computer-
41
executable models that encode key
aspects of software engineering
projects.
UML is still in its infancy; it comes
from the domain of object-oriented
software development but there are
increasing efforts to extend it towards
business process modelling
UML is easy to learn and may
introduce the interested users to
advanced modelling concepts such as
the meta-model. Users do not need to
use all the diagrams and are free to
implement their model any way they
want.
 IDEF modelling
Used for IDEF cover a wide range of uses
from functional modeling to data,
simulation, object-oriented analysis
and design, and knowledge
acquisition
Components IDEF including 14 types
(languages) :
Refer to table 1
Modelling -In IDEF, the business architect may
Approach choose to use IDEF0,
IDEF1/IDEF1X, IDEF3 and IDEF5
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project
for Dataand/or Function-driven
analysis and design, or to use such
languages in order to enhance an
OOAD performed in IDEF10, which
is similar to Rumbaugh’s Object
Modelling Technique.Thus, the
IDEF family gives the user flexibility
in the choice of the analysis and
design languages and modelling
methods.The IDEF family of
languages offers components which
allow taking a holistic approach to
business modelling.
Language A set of integrated languages must be
Structure based on a common metamodel that
guarantees the consistency of its
Integration Definition (IDEF)
UML can be used for modeling a
system independent of a platform
language. UML is a graphical
language for visualizing, specifying,
constructing, and documenting
information about software-intensive
systems. UML gives a standard way to
write a system model, covering
conceptual ideas.
UML has started with a total of 9
diagram types (languages) :
Refer to table 5
-UML is based on the Object-Oriented
Analysis and Design (OOAD) method;
this strongly suggests the UML user to
42
follow an Object-Oriented design
method
-The Unified Process may also provide
a life cycle modelling methodology.
In contrast, UML does have a
common framework underlying its
languages and binding together the
 components. The syntax and
semantics of the IDEF languages are
separately described in their
associated documentation; however,
IDEF developers have not published
a common metamodel underlying the
component languages. This is an
significant drawback, as typically the
modelled business views are
mutually dependent.
SOFTWARE PROCESS & QUALITY MANAGEMENT–
supported byGroup Project
a glossary, this will
diagrams describing the various views
constructed using these languages. The
component languages are described in
metamodels organised into a
collection of packages, which together
form a unified UML metamodel. Thus,
a modelling tool claiming UML
compliance should be based on the
UML metamodels and semantics. The
UML specification allows for its
extension and customization, which,
when performed according to a
structured process , leads to UML
profiles tailored for a particular
domain. Thus, any such modification
must be properly documented and
43
ensure that the models created with the
customised language are still
comprehensible to the target audience.

Table 6 : UML and IDEF

6. CONCLUSION

IDEF standard was developed at the end of 1970 by USAF with assumption to
improve manufacturing productivity using IT and modeling, and represents a set of
standardized methods and family language for information modeling in field software
engineering, and improvement of business process.
The use of functional modeling in the IDEF0 standard is an effective and visual tool
for displaying and analyzing the structure and functions of energy production facilities,
process business planning and generation of modernization projects for facilities.

Integration Definition (IDEF)

 IDEF is a very good robust and proven technique to use for business process
modelling and analysis but may be sometimes in conflict with more modern ways of
analysis and thinking.
Process of production-investment building presents a very complex project, which
requires systematic planning with successful realization in order to accomplish useful
value and efficiency.
7. REFERENCES

[1] What is Integration Definition (IDEF)? - Definition from Techopedia

[2] IDEF - Wikipedia
[3] IDEF modelling – Pro’s and Con’s | Toolbox Tech
[4] https://www.edrawmax.com/article/the-complete-guide-to-understand-idef-diagram.html
[5]https://www.researchgate.net/publication/29453502_UML_vs_IDEF_An_Ontology-
oriented_Comparative_Study_in_View_of_Business_Modelling
[6]https://www.sciencedirect.com/science/article/abs/pii/S0166361502001458#:~:text=IDEF
%20comprises%20a%20suite%20of,aspects%20of%20software%20engineering%20projects.
SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project
[7] https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/ 44

[8]https://www.semanticscholar.org/paper/UML-vs.-IDEF%3A-An-Ontology-Oriented-
Comparative-in-Noran/49162d5d15633af814901fcdfd1171170ff0b912
[9] https://www.scitepress.org/Papers/2004/26293/26293.pdf
[10] https://enablealignment.blogspot.com/2010/01/modelling-its-all-about-communication.html
[11] https://dl.acm.org/doi/10.1016/S0166-3615%2802%2900145-8
[12] https://www.researchgate.net/publication/226325476_The_IDEF_family_of_languages
[13] https://studfile.net/preview/358539/
[14] https://www.mxotech.com/2018/04/7-benefits-business-process-improvement/
8. TEAM ORGANIZATION

8.1. Team information

Full name Mail Phone Position
Nguyễn Anh Quốc Anhquoca5hht@gmail.com 0868077665 Team leader
Trần Văn Khoa lyhoang20012000@gmail.com 0856402080 Team member

Integration Definition (IDEF)

 Nguyễn Trịnh Huy Quốc quoc3803@gmail.com 0901983180 Team member
Phan Thanh Phú tthanhphu84@gmail.com 0856464622 Team member
Đỗ Đức Trung doductrung142@gmail.com 0829501402 Team member

Table 7 : Team Information

8.2. Duty Roster

Full Name Work
Nguyễn Anh Quốc 8,7, 3.1, 3.2, 3.3, 1.1, 1.2, 1.3, 4.7
Trần Văn Khoa Document Alignment, 5, 8, 7, 6, 3.14,
3.15, 3.16, 1.4
Nguyễn Trịnh Huy Quốc 8, 7, 3.4, 3.5, 3.6, 2.1, 4.1, 4.2
Phan Thanh Phú 8, 7, 3.7, 3.8, 3.9, 2.2, 2.3, 4.2, 4.3
Đỗ Đức Trung 8, 7, 3.10, 3.11, 3.12, 3.13, 2.4, 4.4, 4.5
Table 8 : Work Assignment Table

SOFTWARE PROCESS & QUALITY MANAGEMENT– Group Project 45

Integration Definition (IDEF)