home Accounting Making idef0 diagrams. IDEF0: what is it and how is it used

Making idef0 diagrams. IDEF0: what is it and how is it used

The main one of the three methodologies supported by BPwin is IDEF0. IDEF0, belongs to the IDEF family, which appeared in the late sixties under the name SADT (Structured Analysis and Design Technique). IDEF0 can be used to model a wide range of systems. For new systems, the use of IDEF0 is aimed at defining requirements and specifying functions for the subsequent development of a system that meets the requirements and implements the selected functions. In relation to already existing systems IDEF0 can be used to analyze the functions performed by a system and display the mechanisms by which those functions are performed. The result of applying IDEF0 to a system is a model of that system consisting of a hierarchically ordered set of diagrams, documentation text, and vocabularies that are cross-referenced together. The two most important components that make up IDEF0 diagrams are the business functions or activities (represented in the diagrams as boxes) and the data and objects (represented as arrows) that connect the activities. In this case, the arrows, depending on which face of the work rectangle they enter or which face they exit from, are divided into five types:

Entry arrows (included in the left side of the work) - depict data or objects that change during the execution of the work.

Control arrows (included in the upper edge of the work) - depict the rules and restrictions according to which the work is performed.

Exit arrows (extending from the right side of the work) - depict data or objects that appear as a result of the work.

Mechanism arrows (included in the bottom edge of the work) - depict the resources necessary to complete the work, but do not change during the work (for example, equipment, human resources...)

Call arrows (coming from the bottom of the work) - depict connections between different diagrams or models, pointing to some diagram where this work discussed in more detail.

All jobs and arrows must be named. The first diagram in the IDEF0 diagram hierarchy always depicts the functioning of the system as a whole. Such diagrams are called context diagrams. The context includes a description of the purpose of the modeling, the scope (a description of what will be considered as a component of the system and what as an external influence) and the point of view (the position from which the model will be built). Typically, the point of view is the point of view of the person or object responsible for the operation of the modeled system as a whole.

Figure 7.1. Functional block and interface arcs

Activities on diagrams are depicted as rectangles (functional blocks). Each job depicts some function or task and is named by a verb or verb phrase indicating the action, for example, “Making a product,” “Customer service,” etc. Arrows are marked with a noun and indicate objects or information that connects the works with each other and with the outside world.

After describing the context, a functional decomposition is carried out - the system is divided into subsystems and each subsystem is described in the same syntax as the system as a whole. Then each subsystem is divided into smaller ones, and so on until the desired level of detail is achieved. As a result of this partition, each fragment of the system is depicted on a separate decomposition diagram.

Once the context has been described, the following diagrams in the hierarchy are constructed. Each subsequent diagram is more detailed description(decomposition) of one of the jobs in the above diagram. An example of contextual work decomposition is shown in Figure 7.2 and Figure 7.4. The description of each subsystem is carried out by an analyst together with a subject area expert. Typically the expert is the person in charge of that subsystem and therefore has a thorough knowledge of all its functions. Thus, the entire system is divided into subsystems to the required level of detail, and a model is obtained that approximates the system with a given level of accuracy. Having received a model that adequately reflects current business processes (the so-called AS IS model), the analyst can easily see all the most vulnerable points of the system. After this, taking into account the identified shortcomings, it is possible to build a model of a new organization of business processes (TO BE model).

One of the most important features of the SADT methodology is the gradual introduction of greater and greater levels of detail as diagrams representing the model are created.

Figure 7.2, which shows three diagrams and their relationships, shows the structure of the IDEF0.-model. Each component of the model can be decomposed into a different diagram. Each diagram illustrates the "internal structure" of a block in its parent diagram.

Figure 7.2 - Example of a context diagram

As can be seen in Fig. 7.2, BPwin allows you to highlight activities and arrows in different colors, as well as link the names of the arrows to the arrows themselves (an arrow named “Reporting”), which increases the clarity and readability of the diagram.

Figure 7.3 - Example of a decomposition diagram

Drawing7 . 4 - Context diagram example

Figure 7.5 - Decomposition diagram example

Diagram Hierarchy

The construction of the IDEF0 model begins with the representation of the entire system in the form of the simplest component - one block and arcs depicting interfaces with functions outside the system. Because a single block represents the entire system as a whole, the name specified in the block is generic. This is also true for interface arcs - they also represent the complete set of external interfaces of the system as a whole.

The block that represents the system as a single module is then detailed in another diagram using several blocks connected by interface arcs. These blocks represent the main subfunctions of the original function. This decomposition reveals a complete set of subfunctions, each of which is represented as a block, the boundaries of which are defined by interface arcs. Each of these subfunctions can be decomposed in a similar way to provide a more detailed representation.

In all cases, each subfunction can contain only those elements that are included in the original function. In addition, the model cannot omit any elements, i.e., as already noted, the parent block and its interfaces provide context. Nothing can be added to it, and nothing can be removed from it.

Arcs entering and exiting a block in a diagram top level, are exactly the same as the arcs entering and leaving the lower-level diagram, because the block and diagram represent the same part of the system.

Figure 7.6 - Structure of the SADT model. Decomposition of diagrams

Figure 7.7 - Compliance must be complete and consistent

Some arcs are connected to the diagram blocks at both ends, while others have one end unattached. Unconnected arcs correspond to inputs, controls and outputs of the parent block. The source or destination of these boundary arcs can only be found in the parent diagram. The unattached ends must match the arcs on the original diagram. All boundary arcs must continue on the parent diagram for it to be complete and consistent.

As noted, the mechanisms (arcs on the bottom side) show the means by which functions are performed. The mechanism can be a person, a computer, or any other device that helps perform a given function (Figure 7.8).

Rice. 7.8. Mechanism example

Each block on the diagram has its own number. A block of any diagram can be further described by a lower-level diagram, which in turn can be further detailed with the required number of diagrams. Thus, a hierarchy of diagrams is formed.

Chart numbers are used to indicate the position of any chart or block in the hierarchy. For example, A21 is a diagram that details block 1 in diagram A2. Similarly, A2 details block 2 in diagram A0, which is the topmost diagram of the model. Figure 7.9 shows a typical diagram tree.

Figure 7.9 - Hierarchy of diagrams

Lecture 8. MethodologiesDFDAndIDEF3

Goal of the work:

studying the basic principles of the IDEF0 methodology,
creating a new project in BPWin,
formation of a context diagram,
making connections.

Description of a system using IDEF0 is called a functional model. The functional model is designed to describe existing business processes, which uses both natural and graphical languages. To convey information about a specific system, the source of the graphical language is the IDEF0 methodology itself.

IDEF0 methodology prescribes the construction of a hierarchical system of diagrams - single descriptions of fragments of the system. First, a description of the system as a whole and its interaction with the outside world is carried out (context diagram), after which a functional decomposition is carried out - the system is divided into subsystems and each subsystem is described separately (decomposition diagrams). Then each subsystem is divided into smaller ones, and so on until the desired level of detail is achieved.

Each IDEF0 diagrams a contains blocks and arcs. The blocks depict the functions of the modeled system. Arcs link blocks together and represent the interactions and relationships between them.

Functional blocks (work) in diagrams are represented by rectangles, representing named processes, functions, or tasks that occur over a period of time and have recognizable results. The name of the work must be expressed as a verbal noun denoting the action.

IDEF0 requires that the diagram have at least three and no more than six blocks. These constraints keep the complexity of the diagrams and model at a level that is readable, understandable, and usable.

Each side of the block has a special, very specific purpose. The left side of the block is for inputs, the top is for control, the right is for outputs, and the bottom is for mechanisms. This designation reflects certain system principles: inputs are converted into outputs, control limits or prescribes the conditions for carrying out transformations, mechanisms show what and how a function performs.

Blocks in IDEF0 are placed in order of importance, as understood by the author of the diagram. This relative order is called dominance. Dominance is understood as the influence that one block has on other blocks in the diagram. For example, the most dominant block of the diagram may be either the first of a required sequence of functions, or a planning or controlling function that influences all others.

The most dominant block is usually placed in the top left corner of the diagram, and the least dominant block is in the right corner.

The arrangement of blocks on the page reflects the author's definition of dominance. Thus, the topology of the diagram shows which features have a greater impact on others. To emphasize this, the analyst can renumber the blocks according to their order of dominance. The order of dominance can be indicated by a number placed in the lower right corner of each rectangle: 1 would indicate the greatest dominance, 2 the next, etc.

The interaction of works with the outside world and with each other is described in the form of arrows, depicted as single lines with arrows at the ends. Arrows represent some information and are called nouns.

Types of arrows

IDEF0 distinguishes between five types of arrows.

Entrance- objects used and transformed by work to obtain a result (output). It is allowed that the work may not have a single entry arrow. The entry arrow is drawn as entering the left edge of the work.

Control-.information, action manager work. Typically, control arrows carry information that indicates what a job should do. Each job must have at least one control arrow, which is depicted as entering the top edge of the job.

Exit- objects into which inputs are converted. Each job must have at least one exit arrow, which is drawn as emanating from the right edge of the job.

Mechanism- resources that perform the work. The arrow of the mechanism is drawn as entering the lower edge of the work. At the discretion of the analyst, the arrows of the mechanism may not be depicted on the model.

Call- a special arrow pointing to a different operating model. The call arrow is drawn as coming from the bottom of the work and is used to indicate that some work is being performed outside of the system being modeled.

Rice. 2.1 Types of arrows

The IDEF0 methodology requires only five types of interactions between blocks to describe their relationships: control, input, control feedback, input feedback, output-mechanism. Control and input connections are the simplest because they reflect direct influences that are intuitive and very simple.

Rice. 2.2. Output communication

Rice. 2.3. Management Communications

A control relationship occurs when the output of one block directly affects the less dominant block.

Control feedback and input feedback are more complex because they involve iteration or recursion. Namely, the outputs from one job influence the future execution of other jobs, which subsequently affects the original job.

Control feedback occurs then; when the output of some block affects a block with greater dominance.

Output-mechanism relationships are rare. They reflect a situation in which the output of one function becomes a means to an end for another.

Rice. 2.4. Login feedback

Rice. 2.5. Management Feedback

Output-mechanism relationships are characteristic of the allocation of resource sources (eg, required tools, trained personnel, physical space, equipment, funding, materials).

In IDEF0, an arc rarely represents a single object. It usually symbolizes a set of objects. Because arcs represent collections of objects, they can have multiple starting points (sources) and ending points (destinations). Therefore, arcs can branch and connect different ways. The entire arc or part of it may extend from one or more blocks and end in one or more blocks.

Branching arcs, depicted as radiating lines, mean that all or part of the contents of the arcs may appear in each branch. An arc is always labeled before a branch to give a name to the entire set. Additionally, each branch of an arc may or may not be labeled according to the following rules:

unlabeled branches contain the weight of the objects specified in the arc label before the branch;
branches labeled after the branch point contain all or part of the objects specified in the arc label before the branch.

Arc merges in IDEFO, depicted as lines converging together, indicate that the contents of each branch go to form a label for the arc that results from merging the original arcs. After a merge, the resulting arc is always marked to indicate the new set of objects resulting from the merge. Additionally, each branch may or may not be marked before merging, according to the following rules:

Rice. 2.6. Output-mechanism connection

unlabeled branches contain the weight of the objects specified in the shared arc label after the merge;
branches marked before merging contain all or some of the objects listed in the common label after merging,

Quantitative chart analysis

To conduct a quantitative analysis of the diagrams, we list the model indicators:

number of blocks on the diagram - N;
diagram decomposition level - L;
balance of the diagram - IN;
number of arrows connecting to the block - A

This set of factors applies to each model diagram. The following will list recommendations on the desired values of the factors in the diagram.

It is necessary to strive to ensure that the number of blocks on the diagrams of lower levels is lower than the number of blocks on the parent diagrams, i.e., as the level of decomposition increases, the coefficient decreases. Thus, the decrease of this coefficient indicates that. that as the model is decomposed, the functions should be simplified, therefore, the number of blocks should decrease.

Diagrams must be balanced. This means that within one diagram the situation shown in Fig. 1 should not occur. 2.7: work 1 has significantly more incoming arrows and control arrows than outgoing ones. It should be noted that this recommendation may not be followed in models describing production processes. For example, when describing an assembly procedure, a block may include many arrows describing the components of a product, and one arrow exiting - the finished product.

Rice. 2.7. Example of an unbalanced chart

Let's introduce the diagram's balance coefficient

It is necessary to strive to Q was minimal for the chart.

In addition to analyzing the graphic elements of the diagram, it is necessary to consider the names of the blocks. To evaluate names, a dictionary of elementary (trivial) functions of the modeled system is compiled. In fact, this dictionary should include the functions of the lower level of diagram decomposition. For example, for a database model, the functions “find a record” and “add a record to the database” may be elementary, while the function “user registration” requires further description.

After forming a dictionary and compiling a package of system diagrams, it is necessary to consider the lower level of the model. If there are matches between the names of diagram blocks and words from the dictionary, this means that a sufficient level of decomposition has been achieved. The coefficient quantitatively reflecting this criterion can be written as L*C- product of the model level and the number of matches of block names with words from the dictionary. The lower the model level (larger L), the more valuable the matches are.

BPWin Toolkit

When you start BPWin, the main toolbar, tool palette, and Model Explorer appear by default.

When creating a new model, a dialog appears in which you should indicate whether the model will be created anew, or it will be opened from the ModelMart repository, enter the name of the model and select the methodology in which the model will be built (Fig. 2.8).

Fig.2.8 Model creation dialog

BPWin supports three methodologies - IDEF0, IDEF3 and DFD. In BPWin it is possible to build mixed models, i.e. the model can simultaneously contain both IDEF0 and IDEF3 diagrams and DFD. The composition of the tool palette changes automatically when you switch from one notation to another.

A model in BPWin is considered as a set of works, each of which operates with a certain set of data. If you click on any model object with the left mouse button, a pop-up context menu appears, each item of which corresponds to the editor of a property of the object.

Example

Building a system model should begin with studying all the documents describing it functionality. One of these documents is the technical specification, namely the sections “Purpose of development”, “Goals and objectives of the system” and “Functional characteristics of the system”.

After studying the source documents and interviewing customers and users of the system, it is necessary to formulate the purpose of the modeling and determine the point of view on the model. Let us consider the technology of its construction using the example of the “University Employment Service” system, the main capabilities of which were described in laboratory work № 1.

Let us formulate the goal of modeling: to describe the functioning of the system, which would be understandable to its user, without going into details related to the implementation. We will build the model from the point of view of users (student, teacher, administrator, dean's office, company).

Let's start by building a context IDEF0 diagram. According to the description of the system, the main function is to serve its clients by processing requests from them. Thus, we define the only job context diagram as “Serve system client”. Next, we define the input and output data, as well as mechanisms and control.

In order to serve a client, it is necessary to register him in the system, open access to the database and process his request. The input data will be “client name”, “client password”, “source database”, “client request”. Executing a request leads either to receiving information from the system or to changing the contents of the database (for example, when compiling expert assessments), so the output will be “reports” and “modified database”. The request processing process will be performed by the system monitor under the control of the administrator.

Context diagram

Thus, we define the context diagram of the system (Fig. 2.9).

Figure 2.9. System Context Diagram

Let's decompose the context diagram, describing the sequence of customer service:

Determining the level of access to the system.
Subsystem selection.
Access to the subsystem.
Changing the database (if necessary).

We get the diagram shown in Fig. 2.10.

Having completed the decomposition of the context diagram, proceed to the decomposition of the next level diagram. Typically, when considering the third and lower levels, models return to the parent diagrams and adjust them.

Rice. 2.10. Decomposition of the work “Service, system client”

We decompose sequentially all the blocks of the resulting diagram. The first step in determining the level of access to the system is to determine the user category. The client's name is searched in the user database, determining its category. According to a certain category, the powers granted to the user of the system are determined. Next, the procedure for accessing the system is carried out, checking the access name and password. By combining information about authorities and access level to the system, a set of allowed actions is formed for the user. Thus, determining the access level to the system will look like shown in Fig. 2.11.

Rice. 2.11. Decomposition of the work “Determining the level of access to the system”

After completing the system access procedure, the monitor analyzes the client's request, selecting the subsystem that will process the request. The decomposition of the work “Appeal to a subsystem” does not correspond to the purpose and point of view of the model. The system user is not interested internal algorithms her work. In this case, it is important for him that the choice of subsystem will be made automatically, without his intervention, so decomposition of access to the subsystem will only complicate the model.

We decompose the work “Processing a client request”, performed by the subsystem for processing requests, determining the categories and powers of users. Before searching for an answer to a query, you must open the database (connect to it). In general, the database can be located on remote server, so you may need to establish a connection with it. Let's determine the sequence of work:

Opening the database.
Executing the request.
Generating reports.

After opening the database, you need to inform the system that a connection to the database has been established, then execute the request and generate reports for the user (Fig. 2.12).

It should be noted that “Query Execution” includes the work of various subsystems. For example, if the request includes testing, then it will be executed by the subsystem of professional and psychological tests. At the stage of query execution, it may be necessary to change the contents of the database, for example, when compiling expert assessments. Therefore, it is necessary to provide for this possibility in the diagram.

Rice. 2.12.

Chart adjustment

When analyzing the resulting diagram, the question arises: what rules are used to generate reports? It is necessary to have pre-generated templates that will be used to select from the database, and these templates must correspond to queries and must be pre-defined. In addition, the client should be given the opportunity to choose the form of the report.

Let’s adjust the diagram by adding the “Report Templates” and “Database Change Requests” arrows and the “System Client” tunnel arrow. Tunneling of the “System Client” is used in order not to place the arrow on the top diagram, since the function of selecting the report form is not important enough to be displayed on the parent diagram.

Changing the diagram will result in adjustments to all parent diagrams (Fig. 2.13 - 2.15).

It is advisable to decompose the “Query Execution” work using a DFD diagram (laboratory work No. 3), since the IDEF0 methodology considers the system as a set of interrelated works, which does not reflect information processing processes well.

Rice. 2.13. Decomposition of the work “Processing a client’s request”

Rice. 2.14. Decomposition of work “System client service” (option 2)

Rice. 2.15. System context diagram (option 2)

Let's move on to the decomposition of the last block “Changing the Database”. From the client's point of view, the system data is located in one database. In reality, there are six databases in the system:

According to the purpose of modeling, it is important for the client to understand that the received data is not immediately updated in the system, but goes through an additional stage of processing and control. The change algorithm can be formulated as follows:

The database in which the information will be changed is determined.
The operator generates a temporary data set and provides it to the administrator.
The administrator controls the data and enters it into the database.

This model can be implemented in another way, by providing the ability to update the database directly upon requests, bypassing the data control process. In this case, it is necessary to ensure control of the integrity of the database to avoid its damage. In this case, the diagram will look like this (Fig. 2.17).

Rice. 2.16. Decomposition of the work “Changing the database”

Rice. 2.17. Decomposition of the work “Changing the database” (option 2) For the first option, shown in Fig. 2.12

Carrying out further decomposition of “Database Changes” will complicate the model, explaining how the physical change of the database in the system is carried out. In this case, the user will not receive any additional information about the operation of the employment service system. It is advisable to decompose this work during the design process of a database system at the stage of creating a logical model of the database.

A decomposition of the "Query Execution" work will be carried out in the next lab, illustrating the application DFD charts to describe information processing processes.

Let's carry out quantitative analysis models shown in Fig. 2.12 and 2.13, according to the method described above. Let us consider the behavior of the coefficient ^ for these models. The parent diagram “Processing a client request” has a coefficient of 4/2 = 2, and the decomposition diagram has 3/3 = 1. The value of the coefficient decreases, which indicates a simplification of the description of functions as the level of the model decreases.

Let's consider the change in the coefficient K b have two model options.

for the second option

Coefficient K b does not change its value, therefore, the balance of the diagram does not change.

We will assume that the level of decomposition of the diagrams considered is sufficient to reflect the purpose of the modeling, and in the diagrams of the lower Level, elementary functions are used as names of work (from the point of view of the system user).

Summarizing the considered example, it is necessary to note the importance of considering several diagram options when modeling a system. Such options may arise when adjusting diagrams, as was done with “Processing a Client Request” or when creating alternative implementations of system functions (decomposition of the work “Changing the Database”). Reviewing the options allows you to select the best one and include it in a package of diagrams for further consideration.

Control questions

List Security questions:

What is a model in IDEF0 notation?
What do the jobs in IDEF0 mean?
What is the order of naming works?
How many works should be present on one diagram?
What is the order of dominance?
How are the works arranged according to the principle of dominance?
What is the purpose of the sides of work rectangles on diagrams?
List the types of arrows.
Name the types of relationships.
What are boundary arrows called?
Explain the principle of naming branching and merging arrows.
What methodologies are supported by BPWin?
List the main elements of the BPWin main window.
Describe the process of creating a new model in BPWin.
How to make connections between works?
How to set a job name.
Describe the work breakdown process.
How to add work to a diagram?
How to resolve tunneled arrows?
Can a BPWin model contain diagrams of multiple methodologies?

At the initial stages of creating an IS, it is necessary to understand how the organization that is going to be automated works. No one in the organization knows how it works in the detail needed to create the IP. The manager knows the work well as a whole, but is not able to delve into the details of the work of each ordinary employee. An ordinary employee knows well what is going on at his workplace, but does not know how his colleagues work. Therefore, to describe the operation of an enterprise, it is necessary to build a model. Such a model must be adequate to the subject area; therefore, it must contain the knowledge of all participants in the organization’s business processes.

The most convenient language for modeling business processes is IDEF0, proposed more than 20 years ago by Douglas Ross (SoftTech, Inc.) and originally called SADT - Structured Analysis and Design Technique. (In the early 1970s, the US military used the process modeling subset of SADT to implement projects under the Integrated Computer-Aided Manufacturing (ICAM) program. This subset of SADT was subsequently adopted as a US federal standard under the name IDEF0. Detailed Specifications for IDEF standards can be found at http://www.idef.com.

In IDEF0, a system is represented as a collection of interacting activities or functions. This purely functional orientation is fundamental - the functions of the system are analyzed independently of the objects with which they operate. This allows you to more clearly model the logic and interaction of the organization’s processes.

A model in IDEF0 is understood as a description of a system (textual and graphic), which should answer some predetermined questions.

The simulated system is considered as an arbitrary subset of the Universe. It is arbitrary because, firstly, we ourselves speculatively determine whether a certain object will be a component of the system, or we will consider it as an external influence, and, secondly, it depends on the point of view of the system. The system has a boundary that separates it from the rest of the Universe. The interaction of a system with the outside world is described as input (something that is processed by the system), output (the result of the system's activities), control (the strategies and procedures under which the work is carried out) and mechanism (the resources necessary to carry out the work). While under control, the system converts inputs into outputs using mechanisms.

The process of modeling a system in IDEF0 begins with defining the context, that is, the most abstract level of description of the system as a whole. The context includes the definition of the subject of modeling, the purpose and point of view of the model.

The subject is understood as the system itself, and it is necessary to establish exactly what is included in the system and what lies outside it, in other words, we must determine what we will further consider as components of the system, and what as an external influence. The definition of the subject of the system will be significantly influenced by the position from which the system is viewed, and the purpose of the modeling - questions to which the constructed model should answer. In other words, it is initially necessary to determine the scope of the modeling. A description of the area of both the system as a whole and its components is the basis for constructing a model. Although it is assumed that the scope can be adjusted throughout the simulation, it must essentially be formulated initially, since it is the scope that determines the direction of the simulation and when the model should be completed. When formulating a scope, there are two components to consider—breadth and depth. Breadth involves defining the boundaries of the model - we determine what will be considered inside the system and what outside. Depth determines at what level of detail the model is complete. When determining the depth of the system, it is necessary not to forget about time limitations - the complexity of building a model grows exponentially with the depth of decomposition. Once the boundaries of the model are defined, it is assumed that no new objects should be introduced into the modeled system; Since all model objects are interconnected, introducing a new object can be not just an arithmetic addition, but can change existing relationships. Making such changes to a finished model is usually a very labor-intensive process (the so-called "floating region" problem).

Modeling Purpose. A model cannot be built without a clearly defined goal. The goal should answer the following questions:

Why should this process be modeled?

What should the model show?

What can the reader get?

Formulating a goal allows the analytics team to focus its efforts in the right direction. Examples of goal statements include the following statements: “Identify and define current problems, enable analysis of potential improvements,” “Identify the roles and responsibilities of employees for writing job descriptions,” “Describe the functionality of the enterprise for the purpose of writing information system specifications,” etc.

Viewpoint. Although the views of different people are taken into account when building a model, the model must be built from a single point of view. A point of view can be represented as the view of a person who sees the system in the aspect required for modeling. The point of view must correspond to the purpose of the modeling. Obviously, the description of the enterprise’s work from the point of view of a financier and a technologist will look completely different, so during the modeling it is important to remain on the chosen point of view. As a rule, the point of view of the person responsible for the simulated work as a whole is chosen. Often when choosing a perspective on a model, it is important to document additional alternative perspectives. FEO (For Exposure Only) charts are commonly used for this purpose.

The IDEF0 model assumes the presence of a clearly formulated goal, a single subject of modeling and a single point of view. To add scope, purpose and viewpoint to IDEF0 models in BPwin, select the menu item Edit/Model Properties, which brings up the Model Properties dialog (Fig. 4). Bookmarked Purpose you should add a goal and point of view, and bookmark Definition- definition of the model and description of the area.

Bookmarked Status In the same dialog, you can describe the status of the model (draft, working, final, etc.), the time of creation and last editing (later tracked automatically by the system date). Bookmarked Source the sources of information for building the model are described (for example, “Survey of subject matter experts and analysis of documentation”). Bookmark General serves to enter the name of the project and model, the name and initials of the author and the time frame of the model - AS-IS And TO-VE.

Rice. 4. Dialog for setting model properties

Models AS-IS and TO-BE. Usually, first, a model of the existing work organization is built - AS-IS (as is). Based on the AS-IS model, consensus is reached between the various business units on “who did what” and what each business unit adds to the process. The AS-IS model allows us to figure out “what we are doing today” before jumping to “what we will do tomorrow.” Analysis of the functional model allows you to understand where the weakest points are, what the advantages of new business processes will be, and how profound changes the existing structure of the business organization will undergo. Detailing business processes allows you to identify shortcomings of the organization even where the functionality seems obvious at first glance. Signs of ineffective activity can be useless, unmanaged and duplicative work, ineffective document flow (the right document is not in the right place at the right time), lack of feedback on management (the work is not affected by its result), input (objects or information are used irrationally ) etc. The shortcomings found in the AS-IS model can be corrected when creating the TO-BE (as will be) model - a model of a new organization of business processes. The TO-BE needs the model to analyze alternative/better ways of doing work and document how the company will do business in the future.

A common mistake to point out when creating an AS-IS model is creating an idealized model. An example would be the creation of a model based on the knowledge of the manager, and not a specific performer of work. The manager is familiar with how work is supposed to be done according to manuals and job descriptions and often does not know how subordinates actually perform routine work. The result is an embellished, distorted model that carries false information and cannot be used for further analysis. This model is called SHOULD_BE (as it should be).

IS design technology involves first creating an AS-IS model, analyzing it and improving business processes, i.e. creating a TO-BE model, and only on the basis of the TO-BE model is a data model, a prototype and then the final version of the IS built. Building a system based on the AS-IS model leads to automation of the enterprise according to the principle of “leaving everything as is, just to keep the computers standing,” i.e. IS automates imperfect business processes and duplicates, rather than replaces, existing document flow. As a result, the implementation and operation of such a system only leads to additional costs for the purchase of equipment, creation of software and maintenance of both.

Sometimes the current AS-IS and future TO-BE models are very different, so that the transition from the initial to the final state is not obvious. In this case, a third model is needed to describe the process of transition from the initial to the final state of the system, since such a transition is also a business process.

The result of the model description can be obtained in the report Model Report. The model report settings dialog is called from the menu item Report/Model Report. In the settings dialog, you should select the required fields, and the order in which information is output to the report is automatically displayed (Fig. 5).

Rice. 5. Model report

IDEF0 diagrams. The IDEF0 methodology is based on a graphical language for describing business processes. A model in IDEF0 notation is a collection of hierarchically ordered and interconnected diagrams. Each diagram is a unit of description of the system and is located on a separate sheet.

The model can contain four types of diagrams:

context diagram (each model can have only one context diagram);

decomposition diagrams;

node tree diagrams;

exposure-only (FEO) charts.

The context diagram is the top of the tree structure of diagrams and represents the most general description of the system and its interaction with external environment. After describing the system as a whole, it is divided into large fragments. This process is called functional decomposition, and the diagrams that describe each fragment and the interaction of the fragments are called decomposition diagrams. After decomposing the context diagram, each large fragment of the system is decomposed into smaller ones, and so on, until the desired level of detail in the description is achieved. After each decomposition session, examination sessions are conducted - subject matter experts indicate the correspondence of real business processes to the created diagrams. Any inconsistencies found are corrected, and only after passing the examination without any comments can the next decomposition session begin. This ensures that the model matches real business processes at any and every level of the model. The syntax for describing the system as a whole and each of its fragments is the same throughout the model.

A node tree diagram shows the hierarchical dependency of activities, but not the relationships between activities. There can be as many node tree diagrams in the model as desired, since the tree can be built to an arbitrary depth and not necessarily from the root.

Exposure diagrams (FEO) are constructed to illustrate parts of a model, to illustrate an alternative point of view, or for special purposes.

An example of creating a functional model.

As an example, the activities of the fictional company “Computer Word” are considered. The company primarily assembles and sells desktop computers and laptops. The company does not produce components itself, but only assembles and tests computers.

The main types of work in the company are as follows:

sellers accept customer orders;

operators group orders by computer type;

operators assemble and test computers;

operators pack computers according to orders;

The storekeeper ships orders to customers.

The company uses a licensed accounting information system that allows you to place an order, an invoice and track invoice payments.

Method of doing the work

1. Run BPwin().

2. If a dialog appears ModelMart Connection Manager, click on the button Cancel(Cancel).

3. Click the button. A dialog box appears I would like to(Fig. 6). Type in text field Name model name "Company Activity" and select Type – Business Process (IDEF0). Click the button OK.

Rice. 6. Naming the model and selecting the model type

4. A dialog box will open Properties for New Models(Properties of the new model) (Fig. 7). Enter in the text field Author(Author) name of the author of the model and in the text field Author initials his initials. Press the buttons in sequence Apply And OK.

5. A blank context diagram is automatically created (Fig. 8).

6. Notice the button on the toolbar. This button turns the browsing and navigation tool on and off - Model Explorer(Model browser). Model Explorer has three tabs - Activities (), Diagrams() And Objects(). In the tab Activities Right-clicking an object in the model browser allows you to select options for editing its properties (Fig. 9).

Rice. 8. Blank context diagram

Rice. 9. Right-clicking an object in the Activities tab allows you to use the context menu to edit its properties

7. Go to menu Model/Model Properties. In the tab General dialog box Model Properties to text field Model name you should enter the name of the model “Company Activities”, and in the text field Project the name of the project "Model of the company's activities", and, finally, in the text Time Frame(Time coverage) - AS-IS(As is) (Fig. 10).

Rice. 10. Window for setting model properties

8. In the tab Purpose dialog box Model Properties to text field Purpose(goal) enter data about the purpose of developing the model - “To model current (AS-IS) business processes of the company”, and in the text field Viewpoint(point of view) - “Director” (Fig. 11).

Rice. 11. Entering data about the purpose of modeling and point of view

9. In the tab Definition dialog box Model Properties to text field Definition(Definition) enter “This is a training model that describes the activities of a company” in the text field Scope(coverage) - " General management the company's business: market research, procurement of components, assembly, testing and sales of products" (Fig. 12).

10. Go to the context diagram and right-click on the rectangle representing, in the notation IDEF0, conventional graphic designation of work. From the context menu, select the option Name(Fig. 13). In the tab Name enter the name “Company Activities” (Fig. 14).

11. In the tab Definition dialog box Activity Properties to text field Definition(Definition) enter “Current business processes of the company” (Fig. 15). Text field Note(Notes) leave blank.

Rice. 12. Entering additional data defining the model

Rice. 13. Context menu for working with the selected Name option

Rice. 14. Naming the work

Rice. 15. Entering additional data about the work

12. Create ICOM-arrows on the context diagram (Table 1).

Table 1 - Context diagram arrows

Arrow name (ArrowName)	Arrow definition (ArrowDefinition)	Arrow type (ArrowType)
Customer calls	Requests for information, orders, technical support, etc.
Rules and procedures	Sales rules, assembly instructions, testing procedures, performance criteria, etc.
Products sold	Desktops and laptops
Accounting system	Preparation of invoices, payment of bills, work with orders

13. Using the button, enter text in the diagram field - point of view and goal (Fig. 16).

Rice. 16. Entering text into a chart field using the Text Block Editor

14. Create a report on the model. On the menu Tools/Reports/Model Report(Fig. 17) set the report generation options (check the boxes) and click the button Preview(Preview) (Figure 18).

Rice. 17. Setting options for generating a Model Report

Rice. 18. Model Report Preview

Decomposition of production processes according to methodologyIDEF0

Works (Activity)

Activities refer to named processes, functions, or tasks that occur over a period of time and have recognizable results. Works are depicted as rectangles. All works must be named and defined. The name of the work must be expressed as a verbal noun denoting the action (for example, “Making a part,” “Receiving an order,” etc.). The work “Production of a part” may have, for example, the following definition: “The work refers to the full cycle of manufacturing a product from quality control of raw materials to shipment of the finished packaged product.” When creating a new model (menu File/New) a context diagram is automatically created with a single work depicting the system as a whole (Fig. 1).

To enter a job name, right-click on the job and select from the menu Name Editor and in the dialog that appears, enter the name of the work. To describe other properties of the work, use the dialog Activity Properties(Fig. 2).

Rice. 1. Example of a context diagram

Rice. 2. Editor for setting job properties

Decomposition diagrams contain related work, i.e. child jobs that have a common parent job. To create a decomposition diagram, click on the button.

A dialogue arises Activity Box Count(Fig. 3), in which you should indicate the notation of the new diagram and the number of works on it. Let's choose a notation IDEF0 and click on OK. A decomposition diagram appears (Fig. 4). The acceptable range of number of jobs is 2-8. It makes no sense to decompose work into one task: diagrams with more than eight tasks turn out to be oversaturated and difficult to read. To ensure clarity and better understanding of the simulated processes, it is recommended to use from three to six blocks on one diagram.

Rice. 3. DialogueActivity Box Count

Rice. 4. Example of a decomposition diagram

If it turns out that the number of works is not enough, then the work can be added to the diagram by first clicking on the button on the tool palette, and then on an empty space on the diagram.

Activities on breakdown diagrams are usually arranged diagonally from the top left to the bottom right.

This order is called the order of dominance. According to this arrangement principle, the most important work or work performed on time first. Further down to the right are less important or later tasks. This arrangement makes the diagrams easier to read, and the concept of work relationships is based on it.

Each of the activities on the decomposition diagram can be decomposed in turn. In a breakdown diagram, work is numbered automatically from left to right. The job number is shown in the lower right corner. There is a small diagonal line in the upper left corner, which indicates that this work has not been decomposed. So, for example, the work “Assembling a product” has number 3 and has not yet been decomposed. Work "Quality Control" (number 4) has a lower level of decomposition

Arrows

The interaction of works with the outside world and with each other is described in the form of arrows. Arrows represent some information and are called nouns (for example, “Product”, “Product”, “Order”).

There are five types of arrows in IDEF0:

Input- material or information that is used or transformed by work to produce a result (output). It is allowed that the work may not have a single entry arrow. Each type of arrow approaches or leaves a specific side of the rectangle representing the work. The entry arrow is drawn as entering the left edge of the work. When describing technological processes (this is why IDEF0 was invented), there are no problems identifying inputs. Indeed, “Raw materials” in Fig. 1. is something that is processed during the “Product Making” process to produce a result. When modeling an IP, when the arrows are not physical objects, but data, not everything is so obvious. For example, during a “Patient Reception”, the patient’s card can be both at the input and at the output, meanwhile the quality of this data changes. In other words, in this example, in order to justify its purpose, the input and output arrows must be precisely defined to indicate that the data has actually been processed (eg, the output is "Completed Patient Record"). It is often difficult to determine whether data is input or control. In this case, a clue can be whether the data is processed/changed in the work or not. If they change, then most likely it is an input; if not, it is control.

Control- rules, policies, procedures or standards that guide work. Each job must have at least one control arrow. The control arrow is drawn as entering the top edge of the work. In Fig. 1 arrows “Task” and “Drawing” - control for the work “Manufacture of a product”. Management influences work, but is not transformed by work. If the goal of a job is to change a procedure or strategy, then that procedure or strategy will be the input to the job. If there is uncertainty in the status of an arrow (control or input), it is recommended to draw a control arrow.

Output- the material or information that is produced by the work. Each job must have at least one exit arrow. Work without results has no meaning and should not be modeled. The exit arrow is drawn as emanating from the right edge of the work. In Fig. 1 arrow "Finished product" is the output for the work "Product manufacturing".

Mechanism- resources that perform the work, for example, enterprise personnel, machines, devices, etc. The mechanism arrow is drawn as included in the lower edge of the work. In Fig. 1 arrow "Enterprise personnel" is a mechanism for the work "Product manufacturing". At the discretion of the analyst, the arrows of the mechanism may not be depicted in the model.

Call- a special arrow pointing to a different operating model. The call arrow is drawn as emanating from the bottom edge of the work. In Fig. 1 arrow "Other work model" is a call for the work "Product manufacturing". A call arrow is used to indicate that some work is being performed outside of the system being modeled. In BPwin, call arrows are used in the mechanism for merging and splitting models.

Border arrows. The arrows on the context diagram are used to describe the interaction of the system with the outside world. They can start at the border of the diagram and end at the work, or vice versa. Such arrows are called boundary arrows.

To add a boundary entry arrow:

Control, output, mechanism and output arrows are depicted similarly. To draw an exit arrow, for example, click the arrow symbol button in the Tools palette, click on the right side of the work on the exit side (where the arrow starts), move the cursor to the right side of the screen until the initial dashed line appears, and click once along the dashed strip.

The names of newly added arrows are automatically entered into the dictionary ( Arrow Dictionary).

ICOM codes. A breakdown diagram is designed to detail the work. Unlike models that display the structure of an organization, the work on the top-level diagram in IDEF0 is not a control over the work below it. Lower-level work is the same as upper-level work, but in more detail. As a consequence, the boundaries of a top-level work are the same as the boundaries of a decomposition diagram. ICOM(abbreviation for Input, Control, Output and Mechanism) - codes intended to identify boundary arrows. Code ICOM contains a prefix corresponding to the arrow type ( I,WITH,ABOUT or M), and serial number. BPwin enters ICOM codes automatically. To display ICOM codes, enable the Show ICOM codes option on the tab Presentation dialogue Model Properties.

The arrow dictionary is edited using a special editor Arrow Dictionary Editor, in which the arrow is defined and a comment related to it is entered (Fig. 6). The arrow dictionary solves a very important problem. Diagrams are created by an analyst in order to conduct an examination session, i.e., discuss the diagram with a subject matter specialist. In any subject area, professional jargon is formed, and very often jargon expressions have an unclear meaning and are perceived differently by different specialists. At the same time, the analyst - the author of the diagrams - must use those expressions that are most understandable to experts. Since formal definitions are often difficult to understand, the analyst is forced to use professional jargon, and in order to avoid ambiguous interpretations, in the arrow dictionary each concept can be given an expanded and, if necessary, formal definition.

The contents of the arrow dictionary can be printed as a report (menu Report/Arrow Report...) and thereby obtain an explanatory dictionary of domain terms used in the model.

Rice. 5. DialogueArrow Properties

Rice. 6. Vocabulary arrows

Unconnected border arrow. When decomposing a work, the arrows entering and leaving it (except for the call arrow) automatically appear on the decomposition diagram (migration of arrows), but do not touch the works. Such arrows are called unlinked and are treated as a syntax error in BPwin. To link input, control or mechanism arrows, you must go into arrow editing mode, click on the arrowhead and click on the corresponding work segment. To link an output arrow, you must go into arrow editing mode, click on the work output segment and then on the arrow.

Inner arrows. To connect the works with each other, internal arrows are used, i.e. arrows that do not touch the border of the diagram begin at one work and end at another.

To draw an internal arrow, you must, in arrow drawing mode, click on a segment (for example, exit) of one work and then on a segment (for example, input) of another. IDEF0 distinguishes five types of work relationships.

Output-input communication, when the output arrow of the higher-level work (hereinafter referred to as simply the output) is directed to the input of the lower-level one.

Control communication (output-control), when the output of a higher-level operation is sent to control the lower one. Management communication shows the dominance of higher-level work. The data or output objects of the higher-level work are not changed in the lower-level work.

Output-input feedback, when the output of a lower-level work is sent to the input of a higher-level one. Such a relationship is usually used to describe cycles.

Output-control feedback, when the output of a lower-level operation is sent to the control of a higher-level one. Management feedback often indicates the effectiveness of a business process.

Output-mechanism connection, when the output of one job is sent to the mechanism of another. This relationship is used less frequently than others and shows that one activity prepares the resources needed to carry out another activity.

Explicit arrows. An explicit arrow has a source of one and only one job and a destination of one and only one job.

Branching and merging arrows. The same data or objects generated by one job can be used in several other jobs at once. On the other hand, arrows generated in different works may represent the same or homogeneous data or objects that are further used or processed in one place. To model such situations, IDEF0 uses branching and merging arrows. To branch an arrow, in the arrow editing mode, click on the arrow fragment and on the corresponding segment of work. To merge two exit arrows, in arrow editing mode, first click on the work exit segment, and then on the corresponding arrow fragment.

The meaning of branching and merging arrows is conveyed by the naming of each branch of the arrows. There are certain rules for naming such arrows. Let's look at them using branching arrows as an example. If an arrow is named before the branch, but after the branch no branches are named, then each branch is assumed to model the same data or objects as the branch before the branch.

If an arrow is named before a branch, but after the branch any of the branches are not named, then it is assumed that these branches correspond to the naming. If any branch after the branch remains unnamed, then it is assumed that it models the same data or objects as the branch before the branch.

The situation is unacceptable when the arrow is not named before the branch, and after the branch any of the branches is not named. BPwin detects such an arrow as a syntax error.

The rules for naming merging arrows are completely similar - an arrow that is not named after the merger, and any of its branches is not named before the merger, will be considered an error. To name a separate branch of branching and merging arrows, select only one branch in the diagram, then call the name editor and assign a name to the arrow. This name will only match the selected branch.

Arrow tunneling. Newly introduced boundary arrows are shown in square brackets on the lower-level decomposition diagram and do not automatically appear on the top-level diagram.

To “drag” them to the top, you must first select the button on the tool palette and click on the square brackets of the border arrow. A dialogue appears Border Arrow Editor(Fig. 7).

Rice. 7. DialogueBorder Arrow Editor

If you click on the button ResolveBorderArrow, the arrow migrates to the top-level diagram if the ChangeToTunnel button is used - the arrow is tunneled and does not end up on another diagram.

Tunneling can be used to depict unimportant arrows. If on any lower-level diagram it is necessary to depict unimportant data or objects that are not processed or used by work at the current level, then they must be sent to a higher level (to the parent diagram). If this data is not used in the parent chart, it needs to be sent even higher, etc. As a result, an insignificant arrow will be drawn at all levels and will make it difficult to read all the charts on which it appears. The solution is to tunnel the arrow at the lowest level. This tunneling is called "not-in-parent-diagram".

Example of creating a decomposition diagram

1. Select the down button in the tool palette and in the dialog box Activity Box Count(Fig. 8) set the number of jobs on the lower level diagram - 3 - and click the button OK.

Rice. 8. Activity Box Count Dialog Box

2. A decomposition diagram will be created automatically (Fig. 9).

Rice. 9. Decomposition diagram

Right-click on the work located in the upper left corner of the model editing area, select the option in the context menu Name and enter the job name. Repeat the operation for the remaining two jobs. Then enter the definition, status, and source for each work as shown in Table 1.

Table 1. Works of the A0 decomposition diagram

The decomposition diagram will take the form shown in Fig. 10.

Fig. 10 Decomposition diagram after assigning names to works

3. To change the properties of jobs after they are included in the diagram, you can use the jobs dictionary (Fig. 11). The dictionary is called using the main menu item Dictionary/Activity.

Rice. 11. DictionaryActivity Dictionary

If you describe the name and properties of the work in the dictionary, you can add it to the diagram later using a button in the tool palette. It is not possible to remove a work from the dictionary if it is used in any diagram. If a work is removed from the chart, it is not removed from the dictionary. The name and description of such work may be used later. To add a work to the dictionary, go to the end of the list and right-click on the last line. A new line appears in which you need to enter the name and properties of the job. To delete all job names that are not used in the model, click the button ( Purge(Clean)).

4. Switch to arrow drawing mode and link the boundary arrows using the button on the tool palette as shown in Fig. 12.

Rice. 12. Connected boundary arrows on the A0 diagram

5. Right-click on the control arrow branch of the “Building and testing computers” work and rename it to “Build and testing rules” (Fig. 13). Enter a definition for the new branch: "Build instructions, testing procedures, performance criteria, etc." Right-click on the arrow branch of the “Sales and Marketing” work mechanism and rename it as “Ordering System” (Fig. 14).

Rice. 13. Arrow "Build and test rules"

Rice. 14. Arrow "Ordering system"

6. An alternative method of entering names and properties of arrows is to use the arrow dictionary (call the dictionary - menu Dictionary/Arrow). If you enter the name and properties of the arrow into the dictionary (Fig. 15), it can be added to the diagram later.

Rice. 15. Vocabulary arrows

An arrow cannot be removed from the dictionary if it is used in any diagram. Removing an arrow from a diagram does not remove it from the dictionary. The name and description of such an arrow can be used later. To add an arrow, go to the end of the list and right-click on the last line. A new line appears in which you need to enter the name and properties of the arrow.

7. Create new internal arrows as shown in Fig. 16.

Rice. 16. Inner arrows of A0 diagram

8. Create an arrow feedback(for management) “Assembly and testing results”, going from the work “Assembling and testing computers” to the work “Sales and Marketing”. Change the arrow style (line thickness) if necessary and set the option Extra Arrowhead(Additional Arrowhead) (from the context menu). Method drag&drop move the names of the arrows so that they are easier to read. If necessary, install from the context menu Squiggle(Zagogulin). The result of possible changes is shown in Fig. 17.

Rice. 17. Result of editing arrows on diagram A0

9. Create a new Marketing Materials exit boundary arrow coming out of the Sales and Marketing job. This arrow does not automatically fall into the top-level diagram and has square brackets at the tip (Figure 18).

Rice. 18. Arrow Marketing materials

10. Right-click on the square brackets and select the menu item Arrow Tunnel(Fig. 19).

In the dialog box Border Arrow Editor(Boundary Arrow Editor) select option Resolve it to Border Arrow(Allow as Boundary Arrow) (Fig. 20).

Rice. 19. ParagraphmenuArrow Tunnel

Rice. 20. DialoguewindowBorder Arrow Editor

For the Marketing Materials arrow, select the option Trim(Arrange) from the context menu. The result of the laboratory work is shown in Fig. 21.

Rice. 21. Result of decomposition

Keywords: structural analysis and design, functional model, functional block, interface arc, context diagram, decomposition, glossary, goal, point of view, identification of subprocesses, decomposition, complexity limitation, tunneling.

Definition

IDEF0 (Integration Definition for Function Modeling) – a functional modeling methodology for describing enterprise functions, offering a functional modeling language for analysis, development, reengineering and integration information systems business processes; or software engineering analysis.

The IDEF0 methodology is a development of the structural analysis and design method SADT (Structured Analysis and Design Technique).

IDEF0 as a standard was developed in 1981 as part of the ICAM (Integrated Computer Aided Manufacturing) program.

IDEF0 – Integration DEFinition language 0 – is based on SADT and in its original form includes simultaneously: a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive model development methodology.

The latest revision of IDEF0 was released in December 1993 by the US National Institute of Standards and Technology (NIST).

IDEF0 was adopted as a federal standard in the United States in 1993, and as a standard in the Russian Federation in 2000.

Application of IDEF0

IDEF0 is used to create functional model, that is, the result of applying the IDEF0 methodology to the system is the IDEF0 functional model.

Functional model is a structural representation of functions, activities or processes within the modeled system or subject area.

The IDEF0 methodology can be used to model a wide range of both automated and manual systems.

For systems being designed, IDEF0 can be used to first define requirements and functions and then create an implementation that satisfies those requirements and performs those functions.

For existing systems, IDEF0 can be used to analyze the functions performed by the system, as well as to account for the mechanisms by which those functions are performed.

Goals of the IDEF0 standard

Main objectives (objectives) of the standard:

document and explain the IDEF0 modeling technique and how to use it;

provide a means for completely and consistently modeling the functions of a system or domain, as well as the data and objects that connect these functions;

provide a modeling language that is independent of CASE methods or tools, but can be used using those methods and tools;

provide a modeling language that has the following characteristics:

general(generic) – for analysis of systems and subject areas;

strict and precise(rigorous and precise) – to create correct, usable models);

brief(concise) – to facilitate understanding, communication, agreement between stakeholders and verification. (to facilitate understanding, communication, consensus and validation);

abstract(conceptual) – to represent functional requirements independent of physical or organizational implementations;

flexible– to support different phases life cycle project.

Rigor and precision(Rigor and Precision)

The IDEFØ rules require sufficient rigor and precision to satisfy the needs without overly constraining the analyst. IDEFØ rules include the following:

control of the details communicated at each level – from three to six functional blocks at each level of decomposition;

Bounded Context – there should be no missing or unnecessary details that go beyond the established framework;

Diagram Interface Connectivity – numbers of nodes, functional blocks, C-numbers and Detail Reference Expression);

data structure coherence. (Data Structure Connectivity) – ICOM codes and the use of parentheses;

Unique Labels and Titles – no duplicate names;

syntax rules for graphics (Syntax Rules for Graphics) – function blocks and arrows;

restrictions on data arrow branches (Data Arrow Branch Constraint) – labels for restrictions on data flows on branches;

separation of data into Input versus Control Separation – a rule for determining the role of data);

data arrow markings. Data Arrow Label Requirements (minimum labeling rules);

presence of Control (Minimum Control of Function) – all functions must have at least one Control;

Purpose and Viewpoint – all models have a statement of purpose and point of view.

IDEF0 Basic Concepts

The methodology is based on four main concepts:

functional block;

interface arc;

decomposition;

glossary.

Function block(Activity Box) represents some specific function within the system in question.

According to the requirements of the standard, the name of each functional block must be formulated in the verbal mood (for example, “produce services”).

In the diagram, a functional block is depicted as a rectangle (Fig.). Each of the four sides of the functional block has its own specific meaning (role), and:

the top side is set to “Control”;

the left side is set to “Input”;

the right side is set to “Output”;

the bottom side has the meaning “Mechanism”.

Rice. Function block

Interface arc/arrow(Arrow) displays a system element that is processed by a function block or otherwise affects the function represented by that function block. Interface arcs are often called flows or arrows.

Using interface arcs, various objects are displayed that, to one degree or another, determine the processes occurring in the system. Such objects can be elements of the real world (parts, cars, employees, etc.) or flows of data and information (documents, data, instructions, etc.).

Depending on which side of the functional block this interface arc fits, it is called “incoming”, “outgoing” or “controlling”.

It should be noted that any functional block, according to the requirements of the standard, must have at least one control interface arc and one outgoing one. This is understandable - each process must occur according to some rules (displayed by the control arc) and must produce some result (outgoing arc), otherwise its consideration does not make any sense.

The mandatory presence of control interface arcs is one of the main differences between the IDEF0 standard and other methodologies of the DFD (Data Flow Diagram) and WFD (Work Flow Diagram) classes.

Decomposition(Decomposition) is a core concept of the IDEF0 standard. The principle of decomposition is used when breaking a complex process into its component functions. In this case, the level of detail of the process is determined directly by the model developer.

Decomposition allows you to gradually and structuredly present the system model in the form of a hierarchical structure of individual diagrams, which makes it less overloaded and easier to digest.

The last of the IDEF0 concepts is glossary(Glossary).

For each of the IDEF0 elements - diagrams, function blocks, interface arcs - the existing standard requires the creation and maintenance of a set of corresponding definitions, keywords, narrative statements, etc. that characterize the object displayed by this element.

This set is called glossary and is a description of the essence of this element. The glossary harmoniously complements the visual graphic language, providing the diagrams with the necessary additional information.

Modeling. The IDEF0 model always begins with a view of the system as a single whole—one functional unit with interface arcs extending beyond the domain under consideration. Such a diagram with one functional block is called context diagram.

The explanatory text for the context diagram must indicate target(Purpose) to construct a diagram in the form of a brief description and recorded point of view(Viewpoint).

Definition and formalization goals development of the IDEF0 model is an extremely important point. In effect, the goal defines the relevant areas in the system under study that need to be focused on first.

Point of view determines the main direction of model development and the level of required detail. A clear fixation of the point of view allows you to unload the model by refusing to detail and study individual elements that are not necessary, based on the chosen point of view on the system.

Initially methodology IDEF was developed for the US Air Force, then operated by NASA, and only after some time began to be used for modeling business processes.

The most popular varieties of the IDEF family, among those used in business, are notations IDEF0 And IDEF3. Distinctive feature notation is the possibility of decomposition, i.e. Each individual block in a process can in turn be represented as a separate process.

IDEF0

Notation IDEF0 usually used to describe top-level processes, although it allows you to describe all the activities of the company. A distinctive feature of the notation is the ability to display not only the inputs and outputs of each block, but also the “controls” and “mechanisms”. Together with additional features The requirements for the qualifications of business analysts who are involved in modeling processes in notation are also increasing. IDEF0. So, for example, it is not always obvious that technical standards and specifications should be classified as “management”, but should not be classified as job descriptions or production manager. Disputes also arise around the “mechanisms” of process control, since each specialist tends to interpret this concept in my own way.

Despite the presence of additional properties, in the form of “control” of the process, the notation IDEF0 still remains static and is not able to reflect how exactly the progress of the process changes under the influence of this very “control”.

Number of blocks in the diagram IDEF0 usually strictly limited by the modeling tool and, as a rule, does not exceed 9. Often this number is not enough, which is why particularly large processes have to be split into several diagrams, which causes certain inconvenience.

When constructing processes in notation IDEF0 it is recommended to draw blocks not in the order in which they are executed, but in order of dominance: from the most important to the secondary; however, many business modelers ignore this recommendation, preferring to arrange the blocks in the most visual way.

Despite the described shortcomings and the relative difficulty of perception of graphic schemes by ordinary employees of the enterprise, the notation IDEF0 still remains one of the most popular among consultants and specialists in the field of management consulting.

The most famous Russian product that supports building processes in notation IDEF0, is , this notation also has support Microsoft Visio.

IDEF3

Notation IDEF3 often used to build lower-level processes; can also be used when decomposing process blocks IDEF0. Unlike IDEF0 This notation does not support the display of “mechanisms” and “controls”, but it displays the order of work performed by personnel. Despite the similarity with the notation FlowChart, has some significant differences. Firstly, the entire process is built not from top to bottom, but from left to right and, as a rule, is limited by the number of blocks used per diagram. Secondly, the notation was originally intended for technical specialists, therefore it contains special intersections, such as “XOR”, “Synchronous OR”, “Asynchronous OR”, “Synchronous AND” and “Asynchronous AND”, familiar to programmers, but requiring additional explanation enterprise managers.