IDEF4 Standard
|
The development of the object-oriented programming significantly facilitated the process of software development. Nevertheless the development of software with good design, reliability, modularity and usability is still problematic. IDEF4 standard was developed for correct usage of object-oriented technologies. Accordingly to IDEF4 standard, the object-oriented process is represented with the help of diagrams, which helps to analyze this process and to discover its key points. The particularity of IDEF4 standard is the representation possibility of the influence of classes’ heredity, objects composition, functional decomposition and polymorphism on the object projecting.
The process of object-oriented projecting by IDEF4 method is divided into separate blocks.Each subrun has notations, which indicate which decision should be accepted during the projecting process and how it will influence on other subruns. By IDEF4 standard the common diagram, describing the whole project, is not developed. This allows to avoid confusion and quickly find the necessary information on the project. IDEF4 standard lets the planner easily find compromises between classes’ heredity, objects composition, functional decomposition and polymorphism in the project.
IDEF4 model consists of 2 submodels: model of classes and model of methods. These submodels are connected between each other with the help of a distribution scheme and contain the whole information on the project. Because of classes’ subruns sizes and methods the planner never uses them as a whole, using a set of simpler diagrams and specifications which contain the part of information.
A submodel of classes consists of the following diagram types: -
Diagrams of heredity, which define the heredity of classes;
- Diagrams of types, which define the composition of classes;
- Diagrams of protocols, which define protocols of methods call;
- Diagrams of objects creation (Instantiation), which describes the process of creation of exemplars of the preset classes’ objects.
A submodel of classes consists of following diagrams: -
Diagrams of methods systematization (Method taxonomy), which classify methods by behavior similarity;
- Diagrams of clients, which represent clients and operations suppliers, so that to define the functional decomposition.
|
The diagram of heredity represents hereditary ties between classes. For example, at the picture below the structure of heredity and Filled Rectangle class behavior is shown.

Diagrams of protocols define arguments of classes for protocols call. At the picture below the diagram of a protocol for Fill-closed-object is shown.
It is obvious from the diagram that Fill-closed-object gets requests from Polygon object (primary argument) and Color object (secondary argument) and returns the request to Polygon object.

Diagrams of objects creation come into diagrams of types and describe possible situations at composition of ties between created objects..

The diagram of methods systematization describes specific type of system behavior at the influence on the set of methods. Arrows on the diagram point at additional influences, done at the sets of methods. The sets of methods are grouped accordingly to additional obligatory conditions. At the example given below the set of methods ‘Print’ has an obligatory condition that the object must be printed and the set of methods ‘Print-Text’ – that the printed object must be a text.

Diagrams of clients represent clients and operations suppliers. Double arrows on the diagram point from the called operation to the calling operation. At the example given below a diagram of clients is shown. On this diagram the Redisplay operation which belongs to Redisplayable-object class calls the Erase operation of the Erasable-object class and the Draw operation of the Drawable-object class.

IDEF4 standard implies not only graphical presentation but the additional information about diagrams of heredity, methods systematization and types which are contained in specifications. Accordingly to IDEF4 standard there are specifications of invariant classes and specifications of obligatory conditions.
Specifications of invariant classes are connected with diagrams of heredity and define influences which form properties of each concrete class of objects. For each class there exists a separate specification. For instance, the properties “Each square has four sides” and “All square sides are equal” are the properties of specification of the Square class.
Specifications of obligatory conditions are connected with sets of methods in diagrams of methods systematization and define obligatory conditions, which influence on methods and which methods should satisfy.
For each set of methods there is one specification of obligatory conditions. For example the set of methods ‘Pop’, which deletes values from the stack, as obligatory condition will have the absence of attempts to delete the value from the stack if the stack is empty.
IDEF 4 standard is developed by professional planners and programmers of the U.S. Air Force Armstrong Laboratory and is intended to facilitate the usage of object-oriented technologies at software development.
TEN RELATED HOW TO's:
How-To-Guide/aom-db
Picture: Databases Access Objects Model with ConceptDraw DIAGRAM
Use ConceptDraw DIAGRAM diagramming and vector graphics software to visually model your own IT construction processes.
Picture: How to Create a Process Flowchart
Related Solution:
A causal model is an abstract concept, that describes the causal mechanisms of a system, by noting certain variables and their influence on each other, in an effort to discover the cause of a certain problem or flaw. This model is presented in diagram form by using a fishbone diagram.
ConceptDraw DIAGRAM diagramming and vector drawing software enhanced with Fishbone Diagrams solution helps you create business productivity diagrams from Fishbone diagram templates and examples, that provide to start using of the graphic method for the analysis of problem causes. Each predesigned Fishbone Diagram template is ready to use and useful for instantly drawing your own Fishbone Diagram.
Picture: Fishbone Diagram Template
Related Solution:
The activity of any organization is more or less branchy network of processes. The description of these processes is a hard technical task which requires definite methodology and standards.
According to the IDEF0 standard any process can be described in the form of a block (Activity Box) which has inputs and outputs. The process consists in transformation of inputs into outputs under the influence of the management and in the presence of necessary resources. Outputs of the given process later on can be either inputs for the next process or resources, or management means.
Picture: IDEF0 standard with ConceptDraw DIAGRAM
Related Solution:
The Process Flowchart or Process Flowchart Diagram (PFD) is a visual representation relations between major parts of the system, the steps in a process, and even connections between various systems. The possibility to easy create professional-looking and attractive Process Flowcharts, Business Process Diagrams and Maps which visualize the steps of complex processes is provided by Business Process Diagram Solution from the Business Processes Area of ConceptDraw Solution Park and 16 libraries with 230 process flowchart symbols from BPMN 1.2 and BPMN 2.0.
Picture: Process Flowchart Symbols
Related Solution:
Special libraries of highly detailed, accurate shapes and computer graphics, servers, hubs, switches, printers, mainframes, face plates, routers etc.
Use ConceptDraw DIAGRAM with Computer & Networks solution for drawing LAN and WAN topology and configuration diagrams, Cisco network diagrams, network wiring schemes and floor plan layouts.
Picture: How To use Switches in Network Diagram
Related Solution:
ConceptDraw DIAGRAM is a chemistry drawing software that is ideal for designing of various: chemistry drawings, scientific and educational chemistry illustrations, schemes and diagrams of chemical and biological lab set-ups, images with chemical formulas
Picture: Chemistry Drawings
Related Solution:
A database is a data collection, structured into some conceptual model. Two most common approaches of developing data models are UML diagrams and ER-model diagrams. There are several notations of entity-relationship diagram symbols and their meaning is slightly different. Crow’s Foot notation is quite descriptive and easy to understand, meanwhile, the Chen notation is great for conceptual modeling.
An entity relationship diagrams look very simple to a flowcharts. The main difference is the symbols provided by specific ERD notations. There are several models applied in entity-relationship diagrams: conceptual, logical and physical. Creating an entity relationship diagram requires using a specific notation. There are five main components of common ERD notations: Entities, Actions, Attributes, Cardinality and Connections. The two of notations most widely used for creating ERD are Chen notation and Crow foot notation. By the way, the Crow foot notation originates from the Chen notation - it is an adapted version of the Chen notation.
Picture: ERD Symbols and Meanings
Related Solution:
Garrett IA diagrams are used at development of Internet-resources, in particulars at projecting of interactions of web-resource elements. The diagram of information architecture of the web resource which is constructed correctly with necessary details presents to developers the resource in comprehensible and visual way.
Picture: Garrett IA Diagrams with ConceptDraw DIAGRAM
ConceptDraw DIAGRAM is perfect for software designers and software developers who need to draw Rack Diagrams..png)
Picture: Design Element: Rack Diagramfor Network Diagrams