IDEF4 - AbsoluteAstronomy.com

IDEF4, officially named Integrated DEFinition for Object-Oriented Design, is an object-oriented design modeling language

Modeling language

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules...

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

IDEF

IDEF, an abbreviation of Integration Definition, refers to a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition. These "definition...

family of modeling language

Modeling language

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules...

s in the field of systems

Systems engineering

Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...

and software engineering

Software engineering

Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...

Overview

IDEF4 method is a graphically oriented methodology for the design of object-oriented software systems. The object-oriented programming paradigm provides the developer with an abstract view of his program as composed of a set of state maintaining objects which define the behavior of the program by the protocol of their interactions. An object consists of a set of local state defining attributes and a set of methods (procedures) that define the behavior of that particular object and its relationship to the other objects that make up the system.

The IDEF4 method multi-dimensional approach to object-oriented software system design consists of the following items:

Design layers (system-level, application-level, and low-level design),
Artifact design status (application domain, in transition, software domain),
Design models (static, dynamic, and behavior) and the design rationale
Design Rationale
A Design Rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R...

component, and
Design features ranging from general to specific enabling deferred decision making
Decision making
Decision making can be regarded as the mental processes resulting in the selection of a course of action among several alternative scenarios. Every decision making process produces a final choice. The output can be an action or an opinion of choice.- Overview :Human performance in decision terms...

.

History

The development of IDEF4 came from the recognition that the modularity, maintainability and code reusability that results from the object-oriented programming

Object-oriented programming

Object-oriented programming is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction,...

paradigm can be realized in traditional data processing

Data processing

Computer data processing is any process that a computer program does to enter data and summarise, analyse or otherwise convert data into usable information. The process may be automated and run on a computer. It involves recording, analysing, sorting, summarising, calculating, disseminating and...

applications. The proven ability of the object-oriented programming paradigm to support data level integration in large complex distributed systems is also a major factor in the widespread interest in this technology from the traditional data processing community.

IDEF4 was developed as a design tool for software designers who use object-oriented languages such as the Common Lisp Object System, Flavors, Smalltalk

Smalltalk

Smalltalk is an object-oriented, dynamically typed, reflective programming language. Smalltalk was created as the language to underpin the "new world" of computing exemplified by "human–computer symbiosis." It was designed and created in part for educational use, more so for constructionist...

, Objective-C

Objective-C

Objective-C is a reflective, object-oriented programming language that adds Smalltalk-style messaging to the C programming language.Today, it is used primarily on Apple's Mac OS X and iOS: two environments derived from the OpenStep standard, though not compliant with it...

, C++

C++

C++ is a statically typed, free-form, multi-paradigm, compiled, general-purpose programming language. It is regarded as an intermediate-level language, as it comprises a combination of both high-level and low-level language features. It was developed by Bjarne Stroustrup starting in 1979 at Bell...

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 chart

Structure chart

A Structure Chart in software engineering and organizational theory, is a chart which shows the breakdown of a system to its lowest manageable levels. They are used in structured programming to arrange program modules into a tree. Each module is represented by a box, which contains the module's name...

s, data flow diagram

Data flow diagram

A data flow diagram is a graphical representation of the "flow" of data through an information system, modelling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated...

s, and traditional data design model

Database model

A database model is the theoretical foundation of a database and fundamentally determines in which manner data can be stored, organized, and manipulated in a database system. It thereby defines the infrastructure offered by a particular database system...

s (hierarchical, relational, and network) are not sufficient. IDEF4 seeks to provide the necessary facilities to support the object-oriented design decision making process.

Dimensions of IDEF4 Design Objects

IDEF4 uses an object-oriented design method or procedure that is very similar to Rumbaugh

James Rumbaugh

James E. Rumbaugh is an American computer scientist and object methodologist who is best known for his work in creating the Object Modeling Technique and the Unified Modeling Language .- Biography :...

’s Object Method Technique and Schlaer

Sally Shlaer

Sally Shlaer was the co-author of the Shlaer-Mellor approach to software development and co-founder of Project Technology Inc.With Stephen J. Mellor, she founded Project Technology Inc. in 1985, with the goal of making software development a rational, controllable, predictable, engineering process...

/Mellor

Stephen J. Mellor

Stephen J. Mellor is a computer scientist, developer of the Shlaer-Mellor method and signatory to the Agile Manifesto.Together with Sally Shlaer he founded Project Technology in 1985. That company was acquired by Mentor Graphics in 2004....

’s Object-Oriented Analysis and Design (OOA/OOD) technique. However, there are some crucial differences:

IDEF4 is specifically designed to be compatible with other IDEF methods,
IDEF4 allows one to track the status of design artifacts from domain object through transition to design specification, and
IDEF4 includes a design rationale
Design Rationale
A Design Rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R...

component.

These extra dimensions are shown in the figure. The edges of the box show the progression of the design
from start to finish elaborating each of these dimensions.

IDEF4 Design Activities

In IDEF4, a design starts with the analysis of requirements and takes as input the domain objects. These domain objects are encoded in their equivalent IDEF4 form and marked as domain objects. As computational objects are developed for these objects, they are marked as “transitional” and finally as “completed.” The level of completion of an IDEF4 design is determined by setting measures based on the status, level, and model dimensions of individual artifacts in the design.

The system-level design starts once the “raw material” (domain) objects have been collected. This develops the design context, ensures connectivity to legacy systems, and identifies the applications that must be built to satisfy the requirements. Static, dynamic, behavioral, and rationale models are built for the objects at the system level. These specifications become the requirements on the application level – the next level of design. The application level design identifies and specifies all of the software components (partitions) needed in the design. Static models, dynamic models, behavioral models, and the rationale component are built for the objects at the application level. These specifications become the requirements on the next level of design – the low-level design. Static Models, Dynamic Models, Behavioral Models, and the design rationale

Design Rationale

A Design Rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R...

component are built for the low-level design objects. Sub-layers may be built within each layer to reduce complexity.

IDEF4 is an iterative procedure involving partitioning, classification/specification, assembly, simulation, and re-partitioning activities, see figure. First the design is partitioned into objects, each of which is either classified against existing objects or for which an external specification is developed. The external specification enables the internal specification of the object to be delegated and performed concurrently. After classification/specification, the interfaces between the objects are specified in the assembly activity (i.e., static, dynamic, and behavioral models detailing different aspects of the interaction between objects are developed). While the models are developed, it is important to simulate use scenarios or cases between objects to uncover design flaws. Based on these flaws the designer can then rearrange the existing models and simulate them until the designer is satisfied.

IDEF4 Object-oriented Concepts

IDEF4’s defines a set of object oriented concepts:

Domains : IDEF4 projects are implemented in a domain. A domain can be seen as the scope of the system being developed. During system design, the software is transitioned between three domains: the application domain, the design domain, and the implementation domain.
Features, Artifacts, and Objects
Object Instance : Objects can be object instances, object classes, and object partitions. Object instances are the individual things encountered in the application domain.
Classes : Classes are generalizations about objects and are used to manage complexity by taking advantage of similarities in object instances and grouping them under a class or category.
Subclass/Superclass : The term subclass captures the concept of grouping particular instances of a class into an even more specialized class.
Partitions : A partition object contains objects and relations.
Attributes : Attributes are an implementation choice on how to represent an object’s state.
Object States : Object states represent situations or conditions of an object instance that are meaningful in the design.
Method : A method is an implementation of behavior (i.e., a set of instructions according to which the object performs some operation).
Message and Polymorphism : Objects communicate by sending messages to each other.
Event : An event is a signal generated by a method in an object indicating some condition in the object.
Object Life cycles : In any system, objects exhibit patterns of behavior as they cycle through different states.
Client/Server : An object plays the role of a client relative to a message if it is the sender of that message.
Relationships and Roles : Objects connected together with arcs. These arcs are called relationships and they show associations between objects.
Inheritance : A specific type of relationship used in object-oriented technology is inheritance.
Encapsulation and Information Hiding : Encapsulation and information hiding are two object-oriented concepts that are most easily understood when discussed in terms of interactions between objects.

Object Class Identification

The IDEF4 Method assumes that the domain objects have been identified through Object-Oriented Domain Analysis. Methods such as IDEF1, IDEF5

IDEF5

IDEF5 is a software engineering method to develop and maintain usable, accurate, domain ontologies...

, IDEF3

IDEF3

IDEF3, officially named a Integrated DEFinition for Process Description Capture Method, is a business process modelling method complementary to IDEF0...

, SA/SD can be used to perform domain analysis. However, IDEF4 practitioners should be aware of how objects are identified, as the design process may reveal deficiencies in the Object-Oriented Analysis. IDEF4 had defined five types of classes:

Physical Objects
Role Objects : The role may be related to other activities that the person engages in (e.g., a patient in a hospital, a stockholder, a client, a trustee, a suspect in a burglary, or a tax payer).
Event Objects : Events or incidents may also be considered objects. The identification of events as objects is highly subjective, and will depend on the domain in which the software is to be used.
Interaction Objects : Interaction objects are the result of interactions or transactions between two or more objects.
Specification and Procedure Objects : Specification objects describe the acceptable characteristics of objects instances. Procedure objects refer to the way other object instances may interact.

IDEF4 Building blocks

IDEF4 Layers

IDEF4 users design in three distinct layers:

system design,
application design, and
low-level design.

This three layered organization reduces the complexity of the design. The system design layer ensures connectivity to other systems in the design context. The application layer depicts the interfaces between the components of the system being designed. These components include commercial applications, previously designed and implemented applications, and applications to be designed. The low-level design layer represents the foundation objects of the system.

IDEF4 Artifact Status

IDEF4 distinguishes between IDEF4 artifacts newly created from the application domain, artifacts in transition to design specification, and artifacts that have been specified that can be applied to create the design specification. Any design artifact in IDEF4 can be marked as domain, transition, or complete. This allows practitioners and reviewers to track the progress of the design toward completion.

IDEF4 Design Models

IDEF4 uses three design models and a design rationale component:

The Static Model (SM) defines time-invariant relations between objects (for example, inheritance).
The Dynamic Model (DM) specifies the communication between objects and the state transitions of objects.
The Behavior Model (BM) defines the relations between the respective behaviors of objects.

The design rationale component provides a top-down representation of the system, giving a broad view that encompasses the three design models and documents the rationale for major design evolutions.

Each model represents a different cross section of the design. The three design models capture all the information represented in a design project, and the design rationale documents the reasoning behind the design. Each model is supported by a graphical syntax that highlights the design decisions that must be made and their impact on other perspectives of the design. To facilitate use, the graphical syntax is identical among the three models.

Design Features

IDEF4 provides a broad range of design features – from generic to specific. This range enables deferred decision making by allowing the designer to first capture design features in general terms and later to refine them. This significantly reduces the burden on designers by allowing them to immediately capture new design concepts with IDEF4 design features, even if these design concepts have not yet been explored in detail.

External links

IDEF4 Overview at idef.com

The source of this article is wikipedia, the free encyclopedia. The text of this article is licensed under the GFDL.