NASA Technical Reports Server (NTRS) 19920017344: Research accomplished at the Knowledge Based Systems Lab: IDEF3, version 1.0

58 Pages·2.8 MB·English

by  NASA Technical Reports Server (NTRS)

L.
H)EF3 Technical Report
Version 1.0
_|
iL,
_chard J. Mayer
Christopher P. Menzel
:i_:_pa_la S.D. Mayer
L Know!edge Based Systems Laboratory
Depar tment- 0fin-dustrial Engineering
Texas A&M University
College Station TX 77843
Reviewed by
Michad-K, Painter, Capt, USAF
Armstrong Laboratory
Logistics Research Division
Wright-Patterson =Air Force Base, Ohio 45433-6503
:_ _=_January 1991
i
_: ?_
| - ,
i
(NASA-CR-I90279) {RESEARCH ACCOMPLISHED AT N92-26587
THE KNOWLEDGE BASED SYSTEMS LAB: IDEF3,
VERSION 1.0] (Texas A&M Univ.) 56 p
Unclag
G]/_I 0086873
L
== ;
IDEF3 Technical Report
Version 1.0
Richard J. Mayer
Christopher P. Menzel
Paula S.D. Mayer
Knowledge Based Systems Laboratory
Department of Industrial Engineering
Texas A&M University
College Station TX 77843
Reviewed by
Michael K. Painter, Capt, USAF
Armstrong Laboratory
Logistics Research Division
Wright-Patterson Air Force Base, Ohio 45433-6503
January 1991
umd
w
_-:7.
m
w
Preface
This paper describes the research accomplished at the Knowledge Based
Systems Laboratory of the Department of Industrial Engineering at Texas
A&M University. Funding for the Laboratory's research in Integrated
Information System Development Methods and Tools has been provided by the
Air Force Armstrong Laboratory, Logistics Research Division,
AFWAL/LRL, Wright-Patterson Air Force Base, Ohio 45433, under the
technical direction of USAF Captain Michael K. Painter, under subcontract
through the NASA RICIS Program at the University of Houston. The authors
and the design team wish to acknowledge the technical insights and ideas
provided by Captain Painter in the performance of this research as well as his
assistance in the preparation of this report. Special thanks goes to the IDEF3
design team whose names are listed below:
Dr. Richard J. Mayer
Dr. Christopher P. Menzel
Dr. Paula S.D. Mayer
F_
W Dr. Thomas Cullinane
Dr. Douglas D. Edwards
L Martha S. Wells
Shashank Joshi
Thomas M. Blinn
r
2
w
Summary
W
This document describes a language for the representation of process and
w
object state centered system descriptions. IDEF3 is a scenario driven process
flow modeling methodology created specifically for these types of descriptive
activities. IDEF3 is based upon the concept of direct capture of facts about
processes and events in a form that is natural to domain experts in a given
environment. This includes the capture of facts about the objects that
w participate in a process, facts about those objects, as well as the precedence,
and causality relations between processes and events. The goal of IDEF3 is to
provide a structured method for expression of the domain expert's knowledge
about how a particular system or organization works. An IDEF3 description
can be used to provide the data for many purposes including:
w
Recording the raw data resulting from fact finding
interviews in systems analysis and knowledge
engineering activities,
Determination of the impact of an organization's
U information resource on the major operation
scenarios of an enterprise.
Documentation of the decision procedures affecting
.
the states and life cycle of critical shared data
w
(particularly manufacturing, engineering,
iL maintenance, and product definition data),
w
5. System design, design tradeoff analysis, and
simulation modeling
Two modes exist within IDEF3, process flow description and object state
transition description. A process flow description is intended to capture
knowledge of "how things work" in an organization, e.g., the description of
what happens to a part as it flows through a sequence of manufacturing
processes. The object state transition description summarizes the allowable
transitions an object may undergo throughout a particular process. Both the
Process Flow Description and Object State Transition Description contain
units of information that make up the description. These model entities, as
they are called, form the basic units of an IDEF3 description. The resulting
diagrams and text comprise what is termed a "description" as opposed to the
focus of what is produced by the other IDEF methods whose product is a
"model".
3
An IDEF3 Process Flow Description captures a description of a process and
-!
the network of relations that exists between processes within the context of the
overall scenario in which they occur. The intent of this description is to show
E Z
how things work in a particular organization when viewed as being part of a
r_
particular problem solving or recurring situation. The development of an
IDEF3 Process Flow Description consists of expressing facts collected from
Z
domain experts in terms of five basic descriptive building blocks. Each of
these building blocks will be described and illustrated in subsequent sections of
this document.
tram 4
w !.0 Introduction and Background
The original IDEFs were developed for the purpose of enhancing
communication among people who needed to decide how their existing systems
were to be integrated. IDEF0 was designed to allow a graceful expansion of
the description of a system's functions through the process of function
decomposition and categorization of the relations between functions (i.e., in
terms of the Input, Output, Control, and Mechanism classification). IDEF1
was designed to allow the description of the information that an organization
deems important to manage to accomplish its objectives. The third IDEF
(IDEF2) was originally intended as a user interface modeling method.
However, since the ICAM 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
w
of math model based simulations. As a result, the lack of a method which
would support the structuring of descriptions of the user view of a system has
w been a major shortcoming of the IDEF system of languages. 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 versus
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. There are
two additional description capture IDEF methods under development: IDEF5
will be a method for knowledge acquisition, and IDEF6 will be a method for
capture of information system design rationale.
m
The second class of IDEF methods that have been developed are focused on
the design portion of the system development process. That is, they
encapsulate the best known method for design with a particular technology (or
class of technology.) Currently there are two IDEF design methods, IDEF1X
and IDEF4. IDEF1X was developed to assist in the design of semantic data
models. IDEF4 was developed to address a need for a design method to assist
in the production of quality designs for object oriented implementations.
IDEF4 like IDEF1X is intended to service the needs of the systems designers
and programmer analysts who are building and evolving large information
systems. Unlike IDEF1X which encapsulates a design method for relational
database design, IDEF4 encapsulates the principles for design of object
oriented applications and databases. Figure 1 illustrates the planned areas of
application for the IDEF methods relative to an updated Zachman framework
for information system architectures [Zachman 86, IUG 90, and Mayer et al.
89].
5
DATA USER FUNCTION NETWORK
W
List of Things List of Scenarios List of Processes 'List of Locations
Important to the the User Performs the Business in whichthe
business performs businessoperates
BSP _-- IDEF0 IDEF0 _
OBJECTIVF_Xt _ l_'.-5"7-.{
BSP
SCOPE IDEFO "----"
.=====..,
ENTITY = Class of P_ss = Class of _-. - /
Business Thing Business Activity
e.g. Concept Model e.g. User Role e.g. Business
Description Process Descrip.
DOMAIN IDEF3 IDEF3 ?
MODEL
ENT = Bus. Con.
Rein = Association
e.g., Entity / e.g., Function e.g., Logistics
e.g. Organization
Relation Diagram Flow Diagram Network
Process Descrip.
MODEL IDEF1
OFTHE IDEF3
BUSINESS
ENT = Irffo. Entity Node= Bus. Unit
1DEFO
Rein = Bus. Rule Link= Bus. Relatn
e.g., Data Model e.g., Transaction e.g., Data e.g., Distributed
model Flow Diagram System Arch
MODEL
9
OFTHE IDEF3
INFORMATION
SYSTEM
Node=US Func.
ENT = Data Entity
Rein = Data Rein DFD Link=Line Char.
e.g., Data Design e.g., Object Design e.g., Structure e.g., System Arch
Chart
?
TECHNOLOGY
IDEF4
MODEL
SCG Node=Hardware
ENT = Se_-rnent
Rein = Pointer Link=Line Spec.
e.g., Data Design e.g., User Inter- e.g., Program e.g., Network
Face Code Architecture
Description
DETAILED
REPRESEN-
TATIONS
ENT = Field
Rein = Address
w
FUNCTIONING
e.g., Data e.g., Scenario e.g., Function e.g., Communication
SYSTEM
Figure 1. Updated Zachman Framework
6
One of the primary mechanisms used for descriptions of the world is relating
a story in terms of a ordered sequence of events or activities. The IDEF3
-- s
method for process description capture is designed to capture descriptions of
W
the process flow and object state transitions associated with a particular
situation (scenario). A scenario can be thought of as (1) a sequence of
activities that constitute a particular process or event, (2) a set of situations
that describes a problem in an organization or system, or (3) a process
description in a given setting. The IDEF3 method is designed to be used by
both the area expert and an anaTyst / modeler for capturing the knowledge of
the area expert about how a particular process, event, or system works.
IDEF3 was also designed as a mechanism for recording facts that analysts
capture either from direct observations or interviews within a particular
domain. The method provides the capability for capturing the temporal (time-
related) precedence and causality relationships about the process or event.
IDEF3 uses the context of the scenario essentially to drive this description
capture method by providing a boundary to what information the description
will cover. The IDEF3 method presents the description capture within an
environment that is natural for the area expert to use to describe his
w
knowledge about his area. The purpose of such a description is to provide the
data for:
• Determination of the impact of an organization's information resource
on the major operation scenarios of an enterprise.
• Documentation of the decision procedures affecting the states and life
cycle of critical shared data, in particular, manufacturing, engineering,
and maintenance product definition data.
• System design and design tradeoff analysis.
• Determination of the pragmatic data models or how the semantics of
data are used by the enterprise.
It should be noted that many of the uses of IDEF3 proposed in Figure 1 are
direct extrapolations from uses of informal process flow modeling in the
system development life-cycle as described in the early phases of the IDEF3
development activities. Much of the thinking behind IDEF3 has been heavily
influenced by those experiences, particularly the experiments performed by
Edwin I. (Sam) Nusinow of Knowledge Based Engineering Enterprises in his
work modeling engineering data management and control processes.
Similarly, many of the interesting ideas behind the semantics for junction
7
types that will be described later in this document were originally suggested
by Timothy Ramey and Stu Coleman of Pacific Information Management, Inc.
1.1 Motivations behind the Development of IDEF3
r : The motivations which drove the requirements and development of the IDEF3
method address three basic needs.
First, there is a need for a method to describe design data life cycle
characteristics. That is, this method will describe how technical data are
managed during the development stages and the life cycle of a product.
Second, there is a need for a method to formalize external-constraint
driven requirements definition methods. Such a method should (1)
provide a description of the functional constraints on a system imposed
by its operational environment and (2) communicate how the system
will be used once in place.
i
Third, there is a need for improved productivity in the system analysis
model development process. The benefits of having this type of method
would allow the system analysis model development process to be done
faster and yet produce more correct, consistent models with the result
of a reduction in the overall cost of enterprises analysis.
L_ Each of these needs will be discussed in more detail.
__= The first major need was for a method to describe design data life cycle
characteristics. One approach to a successful initial information integration
strategy is to start with the control of the configuration of engineering design
r
data within a manufacturing organization. To achieve this control, one must
i
first map out (1) the design artifacts or the containers of design information,
(2) the state transitions through which these artifacts proceed, and (3) the
decision logic that is used to determine the state transitions. Since these
transitions are largely affected by the activities of the associated organizations,
this requires a definition of the activity sequence and decision making logic of
L_.=
the organization. _......
The second major motivation behind the development of the process flow
method was the need for a method to formalize external-constraint driven
Ii
a_
requirements definition methods. It has been repeatedly demonstrated in
practice that an effective mechanism for the design of a new system is to
describe an ordered sequence of the activities as they would be experienced in
the organization within the context of a given scenario. This process
m
description is then used as a framework for proposing alternative external
views of possible information systems to support the activities of the
organization within the given C0ntext. Such development (design) approaches
have been referred to as External-Constraint driven design approaches. Once
L _
this framework is established, each organizational activity can be used as a
context for describing what the application would do to support that activity
from the participant's perspective. In the Air Force Integrated Design Support
(IDS) program, the what was represented as a sequence of man(cid:0)machine
actions, where the machine presented a prompt (or a form to fill out) and the
human responded with the appropriate action. The general method used in
such an approach can be an effective requirements definition mechanism,
particularly if combined with the IDEF0, IDEF1, and IDEF1X methods.
IDEF3 was designed to be extended naturally to serve as a tool for such an
external constraint driven design method.
The third major motivation behind the development of the process flow
method was the desire to speed up the process of business systems modeling.
The experience of the technical coalition who identified such a need was that
'description of process flow' is one of the most natural ways to introduce an
organization expert to information system modeling. A proven interview
method for systems analysts traditionally starts with the identification of the
major problems or situations that the domain expert deals with daily. Using
each of these as a scenario or focus point, the area expert can easily describe
what decisions, activities, and events surround or are included in the normal
processing of such a problem 0r s_tuation. The design of IDEF3 capitalizes on
this phenomenon by making the first step of the method the requirement to
identify the scenarios. As stated in the Introduction, this has the effect of the
w
scenario driving the resulting IDEF3 practice. The IDEF3 method provides a
structured way to communicate this descriptive information. Once this
descriptive information is captured, the resulting structure and information
can be easily used as a framework for construction of the other IDEF3
models.
As a result of these motivations, the IDEF3 method must provide (1) the
concepts, (2) syntax, and (3) procedures for building 'requirements
descriptions'. These requirements descriptions of a system must be adequately
detailed to determine if a system received is acceptable. This implies that the
IDEF3 method must support the following descriptions:
w 9