IDEF0 diagram on the example of a computer game. Rules of the name of the control elements and blocks. Data flow diagram A63

IDEF0 Methodology

IDEF0 Methodology Prescribes the construction of the hierarchical diagram system - single descriptions of the fragments of the system. It is first a description of the system as a whole and its interaction with the outside world (contextual 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 and so on to achieve the desired degree of detail.

Each IDEF0-diagramsbut Contains blocks and arcs. The blocks depict the functions of the simulated system. Arcs bind blocks together and displays the interactions and interrelations between them.

Functional blocks (operations) The diagrams are depicted by rectangles, meaning the named processes, functions or tasks that occur within a certain time and have recognizable results. The work name must be expressed by the exclusive nouns denoting the action.

IDEF0. It requires that the diagram has at least three and no more than six blocks. These restrictions support the complexity of charts and models at a level accessible to read, understanding and use.

Each side of the block has a special, quite definite purpose. The left side of the block is intended for inputs, top - to control, right - for outputs, lower - for mechanisms. Such a designation reflects certain system principles: Inputs are converted to outputs. Control limits or prescribes the conditions for performing transformations, the mechanisms show that and how the function performs.

Blocks in IDEF0 are placed according to the degree of importance as the author of the chart understands. This relative order is called dominance. Dominance is understood as an influence that one block has a chart on other blocks. For example, the most dominant diagram unit can either be either the first of the desired sequence of functions, or the planning or controlling function affecting all others.

The most dominant unit is usually placed in the upper left corner of the chart, and the definition of the dominant is in the right corner.

The location of the blocks on the page reflects the author's definition of dominance. Thus, the topology of the chart shows which functions have a greater impact on the rest. To emphasize this, the analyst can renumber blocks in accordance with the order of their dominance. The order of dominance can be denoted by the number located in the lower right corner of each rectangle: 1 will indicate the largest dominance, 2 - the following and so on.

The interaction of works with the outside world and together is described in the form of arrows depicted by single lines with arrows at the ends. The arrows are some information and are called nouns.

The IDEF0 distinguish five types of arrows.

entrance- Objects used and converted by work to obtain the result (output). It is assumed that the work may not have any entry arrow. The entrance arrow is drawn as part of the left side of work.

Control -.information, managing work actions. Usually, the control arrows carry information that indicates that the work should be performed. Each work should have at least one control arrow, which is depicted as a part of the work.

Output - Objects in which inputs are converted. Each work should have at least one exit arrow that is drawn as outgoing from the right face of work.

Mechanism - Resources performing work. The arrow of the mechanism is drawn as part of the lower line of work. At discretion, the analyst arrow mechanism may not be depicted on the model.

Call - Special arrow indicating another model of work. The call arrow is drawn as outgoing from the bottom of the work and is used to indicate that some work is performed outside the simulated system.

Fig. 2.1Types arrows

The IDEF0 methodology requires only five types of interactions between blocks to describe their relationships: control, input, feedback on control, feedback on the input, output mechanism. Management and entry communications are the simplest, since they reflect direct impacts that are intuitively understandable and very simple.

Fig. 2.2.Communication in exit

Fig. 2.3.Communication in management

The control ratio occurs when the output of one block directly affects a block with less dominance.

Feedback on management and feedback on the entrance are more complex, since it is an iteration or recursion. Namely, outputs from one work affect the future performing other work, which will later affect the initial work.

Feedback on management occurs then; When the output of some block affects the block with large dominance.

Communication "Out-mechanism" is rarely found. They reflect the situation in which the output of one function becomes a means of achieving a goal for another.

Fig. 2.4.Feedback on the entrance

Fig. 2.5.Feedback on management

Communication-mechanism communication is characteristic of the distribution of resource sources (for example, the required tools, trained personnel, physical space, equipment, financing, materials).

In the IDEF0, the arc rarely depicts one object. Usually it symbolizes a set of objects. Since arcs represent sets of objects, they can have many initial points (sources) and endpoints (destinations). Therefore, arcs can branch and be connected in various ways. The entire arc or part of it can leave one or more blocks and end in one or several blocks.

The branching of the arc depicted in the form of diverging lines means that all the contents of the arc or part of it may appear in each branch. The arc is always marked before the branching to give the name to the whole set. In addition, each branch of the arc can be marked or not marked in accordance with the following rules:

unbearable branches contain weight objects specified in the arc label before branching;

branches marked after the point of branching contain all objects or their part indicated in the arc label before branching.

Arc mergers in the IDEFO, depicted as converging together lines, indicates that the contents of each branch goes to form a tag for an arc, which is the result of the fusion of the initial arc. After the confluence, the resulting arc is always marked to specify a new set of objects that occurred after the combination. In addition, each branch before merger can marry or not fall in accordance with the following rules:

Fig. 2.6.Communication Output

unbearable branches contain weight objects specified in the overall arc mark after the merger;

marked before merging branches contain all or some objects from listed as a common after merging,

number of blocks on the diagram - N;

diagram decomposition level - L.;

balance of chart - AT;

the number of arrows connecting with the block - BUT

This set of factors belongs to each diagram of the model. Next, recommendations will be listed on the desired values \u200b\u200bof the chart factors.

It is necessary to strive to ensure that the number of blocks in the diagrams of the lower levels would be below the number of blocks on the parent diagrams, that is, with an increase in the level of decomposition, the coefficient would decrease. Thus, the decrease in this coefficient says that. What, as the model decompositions decompositions, the function should be simplified, therefore, the number of blocks should decrease.

Charts must be balanced. This means that within the framework of the same diagram there should be no situations shown in Fig. 2.7: The operation of 1 incoming arrows and the management arrows is much larger than the outgoing. It should be noted that this recommendation may not be performed in models describing production processes. For example, when describing the assembly procedure, a plurality of arrows describing the components of the product can include a plurality of the product, and one arrow is published.

Fig. 2.7.An example of an unbalanced diagram

We introduce the chart balance ratio

Need to strive to Kjit was minimal for the chart.

In addition to the analysis of graphic elements of the chart, it is necessary to consider the names of the blocks. To estimate the names, a dictionary of elementary (trivial) functions of the simulated system is drawn up. In fact, this dictionary should include the lower, level of decomposition diagrams. For example, for the BD model, it is elementary to "find an entry" function, "add an entry to the database", while the "User Registration" feature requires further description.

After the formation of the dictionary and compiling the system diagrams package, it is necessary to consider the lower level of the model. If there is a coincidence of the names of the blocks of diagrams and words from the dictionary, this says that the sufficient level of decomposition is achieved. Coefficient, quantitatively reflecting this criterion, can be written as L * C -the product of the model level by the number of block name matching with the words from the dictionary. The lower the level of the model (more than L), the more value coincidence.

When you start a BPWIN, the default toolbar, tool palette and Model Explorer appear.

When creating a new model, a dialog appears, in which you should specify whether the model will be created, or it will be open from the Modelmart repository, add the model name and select a methodology in which the model will be built (Fig. 2.8).

Fig.2.8. Model creation dialogue

BPWIN supports three methodologies - IDEF0, IDEF3 and DFD. BPWIN It is possible to build mixed models, i.e. the model can contain both IDEF0 and IDEF3 and DFD diagrams. The composition of the tool palette changes automatically when switching from one notation to another occurs.

The model in BPWIN is considered as a set of work, each of which operates with some dataset. If you click on any object of the model with the left mouse button, a pop-up context menu appears, each item that corresponds to the editor of any property of the object.

Building the model of the system should begin with the study of all documents describing its functionality. One of these documents is a technical task, namely the sections "Assigning Development", "Goals and System Tasks" and "System Functional Specifications".

After studying the source documents and the survey of customers and users of the system, it is necessary to formulate the purpose of modeling and determine the point of view on the model. Consider the technology of its construction on the example of the "Employment Service under the University" system, the main capabilities of which were described in laboratory work number 1.

We formulate the purpose of modeling: describe the functioning of the system, which would be clear to its user, without going into details related to the implementation. Model will build from the point of view of users (student, teacher, administrator, dean, firm).

Let's start with the context of the context IDEF0 diagram. According to the description of the system, the main function is to maintain its clients by processing requests, from them incoming. Thus, we define the only work of the contextual diagram as "serving the client system." Next, we define the input and output data, as well as mechanisms and management.

In order to serve the client, you need to register it in the system, open access to the database and process its request. The "client name", "Customer Password", "Source Database", "Customer Request" will be used as input data. The execution of the request leads either to obtain information from the system, or to changing the contents of the database (for example, in the preparation of expert estimates), so the output data will be "reports" and "modified database". The processing process of requests will be performed by the system monitor under the control of the administrator.

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

Figure 2.9.Contextual system diagram

Cut the decomposition of the context diagram, describing the client's service sequence:

Determining the level of access to the system.

Select subsystem.

Appeal to the subsystem.

Change database (if necessary).

We obtain the chart depicted in fig. 2.10.

After completing the decomposition of the contextual chart, go to the decomposition of the next level diagram. Usually, when considering the third and lower levels, the model returns to parent diagrams and adjust them.

Fig. 2.10.Decomposition of the work "Service, client system"

Decomposition sequentially all blocks of the obtained chart. The first step in determining the level of access to the system is the definition of the user category. By the name of the client is carried out in the user's database, defining its category. According to a specific category, the powers provided by the user system are found. Next, the system access is performed, checking the name and password of access. Combining information on the powers and the level of access to the system, a set of permitted actions is formed for the user. Thus, determining the level of access to the system will look as shown in Fig. 2.11.

Fig. 2.11.Decomposition of the work "Determination of the level of access to the system"

After passing the process of access to the system, the monitor analyzes the customer's request by selecting the subsystem that will process the request. Decomposition of the work "Appeal to the subsystem" does not meet the purpose and point of view of the model. The system of the system is not interested in the internal algorithms of its work. In this case, it is important to him that the selection of the subsystem will be made automatically, without its intervention, therefore, the decomposition of appeal to the subsystem will only complicate the model.

Decomposing the work "Customer Request Processing", executed by requesting requests, define categories and user authority. Before searching for an answer to the request, you must open the database (connect to it). In the general case, the database may be on a remote server, so it may be necessary to establish a connection with it. Determine the sequence of work:

Opening database.

Communication.

Report generation.

After opening the database, it is necessary to inform the system to establish a connection from the database, after which the request and generate reports for the user (Fig. 2.12).

It should be noted that the "execution of the request" includes the work of various subsystems. For example, if the request includes testing, it will be executed by the subsystem of professional and psychological tests. At the query execution stage, it may be necessary to change the contents of the database, for example, in drawing up expert estimates. Therefore, in the diagram it is necessary to provide such an opportunity.

Fig. 2.12.

When analyzing the resulting chart, the question arises, which rules are the generation of reports? It is necessary to have pre-formed templates for which a sample of the database will be made, and these templates must comply with the requests and must be predetermined. In addition, the client must be given the ability to select a report form.

Adjust the chart by adding the "Reports Templates" and "Requests for BD Change" and the Tunnel Arrow "Client System" to it. The tunneling of the "system client" was applied in order not to take the arrow to the top chart, since the report shape selection function is not important enough to display it on the parent chart.

The change in the diagram will pull the adjustment of all parent diagrams (Fig. 2.13 - 2.15).

Decomposition of the work "Performing a request" is advisable to carry out the DFD diagram (Laboratory work number 3), since the IDEF0 methodology considers the system as a set of interrelated work, which poorly reflects the processing processes.

Fig. 2.13.Decomposition of the work "Customer Request Processing"

Fig. 2.14.Decomposition of the work "System customer service" (option 2)

Fig. 2.15.Contextual system diagram (option 2)

Let us turn to the decomposition of the last block "DB Change". From the client's point of view, these systems are located in one database. In fact, there are six databases in the system:

Database users

Database students (option 2)

BD vacancies,

Database

Database tests

Database expert ratings

DB summary.

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

The database is determined in which the information will be changed.

The operator is formed a temporary dataset and is provided to the administrator.

The administrator carries out data control and contributes to the database.

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

Fig. 2.16.Decomposition of the work "Change database"

Fig. 2.17.Decomposition of the work "Change database" (option 2) for the first variant shown in Fig. 2.12.

Conducting the further decomposition of "BD Changes" will complicate the model explaining how the physical change in the database in the system is carried out. At the same time, the user will not receive any additional information about the work of the employment service system. This work decomposition is advisable to carry out in the process of designing the database of the system at the stage of creating a logical model of the database.

The decomposition of the "execution of the query" will be carried out in the following laboratory work, illustrating the use of DFD diagrams to describe information processing processes.

We carry out a quantitative analysis of the models depicted in Fig. 2.12 and 2.13, according to the above described method. Consider the behavior of the coefficient ^ in these models. The parent chart "Customer Request Processing" The coefficient is 4/2 \u003d 2, and the decomposition diagrams 3/3 \u003d 1. The value of the coefficient decreases, which indicates the simplification of the description of the functions with a decrease in the level of the model.

Consider changing the coefficient TO b. two options for models.

for the second option

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

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

Summing up the considered example, it is necessary to note the importance of consideration of several variants of diagrams when modeling the system. Such options may occur when adjusting diagrams, as was done with the "customer request processing" or when creating alternative implementations of the system functions (decomposition of the work "Change database"). Consideration of options allows you to choose the best and enable it in the diagram package for further consideration.

Posted on http://www.allbest.ru/

The relevance of the task of automation of computer and other equipment in the enterprise increases with a large park of computers, office equipment, shopping and other equipment. The greatest need to know where and which unit is located to quickly monitor changes related to the equipment, it occurs from IT units. 2.

Special significance, the task of automation of equipment accounting acquires at large enterprises. Treatment All the time of growing information arrays has become possible only with the use of modern computer technologies. 2.

To organize a system of accounting for technology at the enterprise, keeping accounting of computers and components, now is not possible without additional software installed on the computer. 2.

The main goal term paper Is development information system To account for computer equipment of the enterprise, using the methodology of functional modeling and graphics notation IDEF0, DFD data flow charts and IDEF3 process documentation standards, using the Computer Associates Allfusion Process Modeler R7.3 software product. 2.

2.1 Software Analysis 8

Introduction

The relevance of the task of automation of computer and other equipment in the enterprise increases with a large park of computers, office equipment, shopping and other equipment. The greatest need to know where and which unit is located to quickly monitor changes related to the equipment, it occurs from IT units.

Special significance, the task of automation of equipment accounting acquires at large enterprises. Treatment All the time of growing information arrays has become possible only with the use of modern computer technologies.

To organize a system of accounting for technology at the enterprise, keeping accounting of computers and components, now is not possible without additional software installed on the computer.

The main objective of the course work is to develop an information system to account for computer equipment of the enterprise, using the methodology of functional modeling and graphics notation IDEF0, DFD data flow charts and IDEF3 process documentation standards, through the Computer Associates Allfusion Process Modeler R7.3 software product.

To achieve this goal, it is necessary to solve the following tasks:

Analysis of software products;

Study of information systems design methods;

Functional modeling of the context diagram and diagrams of business-process decompositions (IDEF0) "Accounting for computer engineering enterprises";

Designing an information system using data stream diagrams (DFD);

Using the methodology for modeling and document documentation of IDEF3 processes.

information Polyclinic Documentation Software

1. Methods of designing information systems

In the modern practice of modeling management and production activities, the term "business - process" is made to designate objects of modeling. When modeling business processes, attention should be paid to a number of factors:

Correct statement of goals;

Competent awareness of the organization's staff regarding the objectives and results of the project;

Effective application of modeling tools;

The presence of corporate standards for describing and regulating business processes.

For modeling business processes, several different methods are used. Their foundation is both structural and object-oriented approaches to modeling. The most developed methods use the elements of both approaches. The most common methods can be attributed to:

sADT functional modeling method (IDEF0);

method of modeling IDEF3 processes;

modeling DFD data streams;

From the point of view of business modeling, each of the approaches presented has its advantages. The object approach allows you to build more stable to change the system, it is better.

existing structures of the organization. Functional modeling well shows itself in cases where the organizational structure is in the process of change or is generally weakly framed. The approach from the functions performed is intuitively better understood by the performers when receiving information from them about their current work.

The functional modeling method IDEF0 (FUNCTION MODELING) is a set of rules and procedures designed to construct a functional model of an object object. The functional model of the object displays the actions and links produced by them.

In accordance with this method, the business model should look like this:

The top level of the model should reflect only the context of the system, that is, its interaction with the outside world.

At the second level, the model should contain all the main activities of the enterprise, in other words thematically grouped business - enterprise processes and their relationship.

Further details of business processes are carried out through business functions, that is, the aggregates of operations grouped according to certain features.

The description of the elementary business operations is carried out using the task of the algorithm for its execution.

DFD data stream modeling method (Data Flow Diagrams) - data stream diagrams. The main means of modeling functional requirements for the designed system.

Model components: diagrams; Data Dictionary; Process specifications.

Chart elements: data stream; storage; External essence.

Data stream Mechanism used to model and transmit information from one part of the system to another.

The external entity object \\ the subject outside the context of the system, which is.

The repository is a slice of data streams in time containing the data to be saved between the processes.

Main advantages:

the ability to unambiguously determine external entities by analyzing information flows inside and outside the system;

the possibility of designing from top to bottom, which facilitates the construction of the model "How should be";

the presence of the specifications of the lower level processes, which allows to overcome the logical incompleteness of the functional model and build a full functional specification of the system being developed;

models have a very rich set of elements adequately reflecting their specificity;

there are also supported by a number of CASE tools automatic conversion algorithms for the DFD hierarchy into structural cards that demonstrate intersystem, intrasystem communications and system hierarchy

Disadvantages:

the need for artificial entry management processes, since the control effects (flows) and the control processes from the DFD point of view are no different from the usual;

no concept of time, i.e. Lack of time interval analysis when converting data (all time limits must be entered in processes specifications).

Idef3 Process Modeling Method (Integrated Definition For Process Description Capture Method) - Methodology of modeling and standard documentation of processes occurring in the system. The method of documenting technological processes provides a mechanism for documenting and collecting processes information. IDEF3 shows causal relationships between situations and events in an understandable expert form using the structural method of expressing knowledge on how the system is functioning, process or enterprise.

The technique of describing IDEF3 data set is part of structural analysis. Unlike some methods of descriptions of IDEF3 processes, it does not limit the analytics overly rigid syntax frameworks, which can lead to the creation of incomplete or contradictory models.

IDEF3 can also be used as a method for creating processes. IDEF3 complements IDEFO and contains everything you need to build models that can be used to simulate the simulation analysis.

2. Designing the information system "Accounting for computer engineering enterprises"

2.1 Software Analysis

An analysis of such information systems is carried out to identify in the dignity and disadvantages, as well as for comparing the functionality, interface, design and convenience of its use. The following existing information systems were found as:

IT Invent Software (It-invent.ru)

Hardware Inspector Software (Hwinspector.com)

Configuration 1C: accounting of computers and equipment 8.1 (odineskin.ru)

The first IP, IT Invent, is not only the accounting of computers, printers, programs and components. This is also the same account for repairs and services, supporting equipment, orders to suppliers, earnings and movements of equipment, accounting of counterparties, employees and much more. The main form of the IT Invent program is shown in Figure 1.

Figure 1 "IT Invent"

IT Invent This is a flexible and customizable system that has an intuitive interface, will clarify what is well perceived by the user in terms of design. The program is quite multifunctional. I would like to note the following key features of the program:

Support MS Access and MS SQL Server database.

Multiplayer mode of operation - all branches work with a single base.

The ability to create and configure your own additional properties of various types.

Accounting for performing the work of any species within the organization.

A unique system for creating and printing inventory labels. Support barcode printers.

Support work with barcode scanner. Search records in the database on the barcode.

Keeping the history of changes in equipment.

Accounting for repairs and preventive maintenance of equipment and computers.

Logical binding of programs and components with equipment.

Accounting for consumables, components and offices.

Fastening accounting units for employees of the organization. Acts of receiving-transmission.

Keeping the base of suppliers, service organizations and other counterparties.

Flexible delineation of access rights for users of the system.

Configuring E-Mail Alerts by Events in the program.

A large number of built-in printed forms and reports with the ability to edit them.

Import and view data directly from Active Directory.

IT INVENT program is a network. To work on the network with a single database, each user program has a path in the DBPath.ini file to write a path to connect to a database file or specify this path by selecting the "File" menu item -\u003e "Database Select". At the same time you need not to forget to set a directory with the database of reading and writing for all users of the program.

The second IP is the Hardware Inspector program. The program is designed for automated accounting and inventory of computer equipment and other equipment in organizations. The uniqueness of the Hardware Inspector program lies in the ability to keep accounting not just the current state of the computer parameters, and the entire history of the life of individual components. Figure 2 shows a visual representation of devices in the workplaces tree.

Figure 2 "Hardware Inspector"

The interface is simple, intuitive. As regards the design, it is acceptable. The program is multifunctional. I would like to mark the following key features:

Detailed computers and software;

Life cycle of accounting objects;

Import devices, software, jobs and network settings;

Automated audit of jobs;

Network crossing;

Accounting and planning of consumables;

Accounting of applications from users;

Inventory of accounts;

Flexible separation of access;

Search for information;

More than 30 built-in custom reports;

Detailed directories in all aspects of accounting;

Hardware Inspector, paid. One license gives the right to install the program on any number of computers, within one local network, one organization.

Third IS, this is a 1C configuration: accounting of computers and equipment 8.1. Accounting for equipment is based mainly on the barcoding, thus, any search operation, selection or technology becomes much easier. With this configuration, it is convenient to take into account and carry out inventory of computers, office equipment and any other material values \u200b\u200b(equipment, telephones, furniture), as well as automate other areas of activity.

Figure 3 shows the main form of 1C configuration.

Figure 3 "1C: Accounting computers and equipment 8.1"

The main characteristics of the product:

Accounting for any technique, furniture, software,

Accounting of serial, inventory equipment numbers,

Import from the EVEREST hardware audit system (automatic data collection)

The most convenient user interface

Accounting suppliers

Criterion		"Hardware Inspector"	Configuration 1C.
Functionality	Multifunctional	Multifunctional	Multifunctional
Interface	Intuitively understandable	Simple - intuitive	Most convenient
		Acceptable	Standard
US convenience		Easy to use	Customized settings
Dignity	Works on the network	Works on the local network Update 2 times a month One license can be installed on any number of computers, inside one local network, one organization	Act free line Consultations on email and ICQ, and if necessary, consult on the phone.
disadvantages	Paid program	Paid program	Paid program

Accounting for users and work with them

Accounting consumables

Automatic search when scanning

Customized settings, etc.

Compare selected information systems in Table 1 for the following criteria: functionality, interface, design, user convenience, advantages and disadvantages;

Table 1 - Comparison of Information Systems

Conclusion: All of the information systems considered contain all the necessary functions for accounting for computer engineering enterprises. All of them are multifunction, convenient and easy to use, with an intuitive interface. The only overall disadvantage of all programs is that they are all paid.

2.2 Description of the diagrams of the business process "Accounting for computer engineering enterprises"

2.2.1 Description IDEF0 chart

To build a business process, an IDEF0 diagram was used. IDEF0 methodology prescribes the construction of a hierarchical diagram system - single descriptions of the system fragments. First, a description of the system as a whole and its interaction with the surrounding world (contextual diagram) is carried out. Three levels of diagram were built:

Contextual

Functional decomposition

Decomposition of each work

Figure 1 - Contextual diagram "Accounting for computer engineering enterprises"

Figure 1 shows the contextual diagram of the business process "Accounting for computer engineering enterprises". It displays the system as a whole and its interaction with the main external flow streams.

The contextual diagram is indicated by arrows.

Types of arrows:

Input information for processing:

Computers - PCs (Personal Computers) are in the enterprise

Accessories - Materials necessary to upgrade computers (video cards, motherboards, processors, housings, power supplies, memory modules)

Output streams:

Report - Ready Report on Computer Engineering Enterprise

Input controls:

Rules are the conditions that need to be observed to achieve the goal.

Orders - the task of the enterprise (conduct accounting of computer equipment at the enterprise with the help of certain information systems)

Managers - Directors and main enterprise managers.

Input resources:

PCs - computers with which accounting is carried out.

Employees are specialists who are implementing instructions assigned to the guide. After constructing a conceptual model, a functional decomposition was carried out - the system is divided into subsystems and each subsystem is described separately (decomposition charts).

Figure 2 shows a functional decomposition consisting of four works.

Figure 2 - Functional decomposition "Accounting for computer engineering enterprises"

The following types of work were allocated:

Delivery registration is a process in which the product is assigned, sending to storage, to the warehouse and the enhancing information about the product in the program.

In the work, the delivery of the supply includes seven boundary shooters (input, control, mechanism) and the inner arrow (input communication) comes out.

Arrow Communication at the entrance between the work. Delivery and maintenance of the computer (computer);

Arrows input, output, control are repeated in subsequent works.

Computer service is a process in which the assembly, repair and upgrades of computers occurs.

The computer's maintenance of the computer includes four boundary arrows (input, control, mechanism, output) and several internal arrows (input communication, input feedback).

Arrow Management - Rules, Orders, Head;

Arrow Communication in the input between the works of the computer and the arrangement (data enclosure to the database), between the works of the computer and the reporting of the report (data enclosing the database);

The arrangement is a process in which there is an alignment of computers on offices (cabinets).

Arrows Management - Rules, Orders, Head;

Arrow of the mechanism - employees;

Arrow communication in the input between the arrangement and the compilation of the report (ID);

Report drawing up - the final stage of the accounting process, which consists of generalizing the final indicators obtained by performing the previous current accounting data.

Then each subsystem is divided into smaller decompositions and so on, before reaching the desired degree.

Figure 3 shows a diagram showing the operation of the delivery of deliveries in more detail.

As a result of the detail, the main functions were allocated. The section "Delivery" section includes seven main arrows (entry, output, control, mechanism).

Entrance arrow - computers and components;

The management arrows are the rules, orders and a manager. Booming arrows;

Arrows of the mechanism, branching - PC, employees;

Arrows input, control, mechanisms are repeated in all operations.

Numbers - assigning individual rooms with computers and components.

Input arrows - computers and components. Arrow computers are repeated in subsequent work, in addition to the reporting;

Arrows Management - Rules, Orders and Head;

Arrows of the mechanism - PC and employees;

Arrow Communication at the entrance between the works Assignment of the room and sending goods to the warehouse (relocation), between "Assignment of the room" and "Balance" (introduction to the database);

Sending goods to the warehouse - mandrel of the goods with the assigned room to the warehouse.

Exit arrow - computer;

Arrows Management - Rules, Orders and Head.

Arrow Communication at the entrance between the works "Sending goods to the warehouse" and "Balance" (number);

Staging on the balance - enhancing information to the computer.

Arrows Management - Rules, Orders and Head;

Arrows of the mechanism - PC and employees;

Figure 4 shows a diagram, detailed computer maintenance in more detail.

As a result of the detail, the main functions running in the process of maintenance of the computer were allocated.

A computer maintenance includes 4 boundary arrows (input, output, control, mechanism). Internal arrows (input feedback, input communication).

Assembling computers - configuration of computers for individual orders of leaders.

Entrance arrow - computers;

Arrows Management - Rules, Orders and Head;

Arrows of the mechanism - employees;

Arrow communication at the entrance between the works: "Assembling computers" and "repair of computers" (computer);

Computer repair is an assembly approved to improve computers.

Entrance arrow - computers;

The output arrow is a database;

Arrows Management - Rules, Orders and Head;

Arrows of the mechanism - employees;

Arrows input, exit, control, mechanism are branching;

Arrow Communication at the entrance between the works: "Repair of computers" and "Upgrade" (components);

Upgrade - Improvement, Improvement, Computer Update.

The output arrow is a database;

Arrows Management - Rules, Orders and Head;

Arrows of the mechanism - employees;

Arrow control, mechanism are branched;

Figure 5 shows the "Report Drawing" diagram in more detail. In the work decomposition, the compilation of the report includes 4 boundary arrows (input, output, control, mechanisms). Internal arrows (input feedback, input communication).

As a result of the work, the following functions were derived:

Data collection - Collection of information for analysis and decision-making.

Input arrow - assignment ID;

Arrows Management - Rules, Orders and Head;

Arrows input, control, mechanism are branching;

Arrow communication at the entrance between the works: data collection and data verification (entries);

Data checking - Checking information and sending it to making a report.

Input arrow - ID assignment, data enhancing in the database;

Output arrow - report;

Arrows Management - Rules, Orders and Head;

Arrows of the mechanism - employees, PCs;

Input arrows (ID), control, mechanism are branching;

Feedback arrow in the input from "data check" to "data collection" (re-check).

Learn to see and understand functional structure Your business!

Currently, in Russia, interest in the standards of management generally accepted in the West has increased sharply, however, in real management practices there is one very demonstration point. Many leaders still can be put in a straight issue on organizational structure Companies or about the scheme of existing business processes. The most advanced and regularly reading economic periodical managers, as a rule, begin to draw only one hierarchical charts understandable only by them, but in this process usually quickly enter the deadlock. The same applies to employees and managers of various services and functional units. In most cases, the only set of the rules set out, in accordance with which the enterprise should function, is a set of individual provisions and official instructions. Most often, these documents were compiled not one year ago, weakly structured and unfinished between themselves and, as a result, they simply dust on the shelves. For the time being, such an approach was justified, since during the formation of the Russian market economy, the concept of competition was practically absent, and the costs were not considered a special need - the profit was gigantic. As a result, we see in the last two years a completely explained picture: large companiesGrounding at the beginning of the 90s, gradually give up their position, up to full care from the market. This is partly due to the fact that the enterprise did not introduce management standards, the concept of a functional model of activity and the mission was completely absent. With the help of modeling various areas of activity, it is possible to effectively analyze "bottlenecks" in managing and optimizing the general business scheme. But, as you know, at any enterprise, the highest priority has only those projects that directly bring profits, so we are talking about the survey of activities and its reorganization only during a tangible crisis in managing the company.

At the end of the 90s, when competition and profitability of enterprises appeared on the market as required, the leaders felt tremendous difficulties when trying to optimize costs so that the products remain at the same time and profitable and competitive. Just at this point, the need to have a model of the enterprise's activity before its own eyes, which would reflect all the mechanisms and principles of the relationship of various subsystems within one business.

The very concept of "modeling business processes" has come to the life of most analysts simultaneously with the appearance in the market of complex software products intended for the integrated automation of enterprise management. Such systems always imply a deep pre-project survey of the company's activities. The result of this examination is an expert opinion, in which certain points are made by recommendations to eliminate "bottlenecks" in the management of activities. Based on this conclusion, immediately before the project implementation of the automation system, the so-called reorganization of business processes is carried out, sometimes quite serious and painful for the company. This, and naturally, the team developed for years is always difficult to force "think in a new way." Such comprehensive surveys of enterprises are always complex and significantly different from the case of tasks. To solve such problems of modeling complex systems, well-rolled methodologies and standards exist. Such standards include the methodologies of the IDEF family. With their help, it is possible to effectively display and analyze models of activity of a wide range of complex systems in various cuts. At the same time, the latitude and depth of the survey of processes in the system is determined by the developer himself, which allows not overloading the created model by excessive data. At the moment, the following standards can be attributed to the IDEF family:

IDEF0 - Methodology of functional modeling. Using a visual graphic IDEF0, the system studied appears before developers and analysts in the form of a set of interrelated functions (function blocks - in the terms IDEF0). As a rule, modeling tools IDEF0 is the first step in the study of any system;

IDEF1 - Methodology for modeling information flows inside the system, allowing to display and analyze their structure and interconnection;

IDEF1X (IDEF1 EXTENDED) - Methodology for constructing relational structures. IDEF1X refers to the type of "Entity-Relationship" methodologies (ERTITY-Relationship) and, as a rule, is used to simulate relational databases related to the system under consideration;

IDEF2 is a methodology for dynamic modeling of system development. Due to the very serious difficulties of analyzing dynamic systems, it was almost abandoned from this standard, and its development has suspended on the very initial stage. However, there are currently algorithms and their computer implementations, allowing to transform a set of static IDEF0 diagrams into dynamic models built on the basis of "Petri painted networks" (CPN - Color Petri Nets);

IDEF3 is a methodology for documenting processes occurring in a system that is used, for example, in the study of technological processes in enterprises. Using IDEF3 describes the script and sequence of operations for each process. IDEF3 has a direct relationship with IDEF0 methodology - each function (functional block) can be represented as a separate process by IDEF3;

IDEF4 - Methodology for building object-oriented systems. IDEF4 means can clearly display the structure of objects and the principles of their interaction, thereby allowing to analyze and optimize complex object-oriented systems;

IDEF5 - methodology of ontological research complex systems. Using IDEF5 methodology, the system ontology can be described using a certain dictionary of terms and rules, on the basis of which reliable allegations of the state of the system under consideration can be formed at some point in time. Based on these statements, conclusions are being formed about the further development of the system and it is optimized.
As part of this article, we consider the most commonly used methodology for functional modeling IDEF0.

The history of IDEF0 standard

The IDEF0 methodology can be considered as follows the development phase of the well-known graphic language description of the SADT functional systems (Structured Analysis and Design Teqnique). Several years ago, a similar book was released in a small circulation, devoted to the description of the basic principles of building SADT diagrams. Historically, IDEF0, as the standard was developed in 1981 as part of an extensive automation program industrial enterpriseswhich Icam wore the designation (Integrated Computer Aided Manufacturing) and was proposed by the Department Air force USA. Actually, the IDEF family of standards inherited its designation from the name of this program (IDEF \u003d ICAM Definition). During practical implementationThe ICAM program participants faced the need to develop new methods for analyzing the processes of interaction in industrial systems. At the same time, in addition to the improved set of functions for describing business processes, one of the requirements for the new standard was the existence of an effective methodology for interaction in the framework of the "analyst-specialist". In other words, new method It was supposed to provide group work on the creation of a model, with the direct participation of all analysts and specialists engaged in the project.

As a result of the search for the relevant solutions, the methodology of functional modeling IDEF0 was born. Since 1981, the IDEF0 standard has undergone several minor changes, mainly limiting, and his last editorial board was issued in December 1993 by the National Institute for Standrays and US Technologies (NIST).

The main elements and ideals of IDEF0

Graphic IDEF0 language is surprisingly simple and harmonious. The methodology is based on four basic concepts.

The first of them is the concept of the function block (Activity Box). The function block is graphically portrayed as a rectangle (see Fig. 1) and personifies some specific function within the framework of the system under consideration. According to the requirements of the standard, the name of each functional block should be formulated in the verballation (for example, "to produce services", and not "production services").

Each of the four sides of the function block has its own definite value (role), while:

The top side has the "Control" value;

The left side is "input" (INPUT);

The right side is "output" (Output);

The bottom side has the value "Mechanism".

Each functional block within the framework of the unified system under consideration should have its own unique identification number.

Figure 1. Function block.

The second "whale" IDEF0 methodology is the concept of an interface arc (arrow). Also, interface arcs are often called streams or arrows. The interface arc displays the element of the system, which is processed by the function block or has a different effect on the function displayed by this functional block.

The graphical display of the interface arc is a unidirectional arrow. Each interface arc must have its own unique name (Arrow Label). At the request of the Standard, the name must be a normalization of the noun.

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

Depending on which the parties suits this interface arc, it is called the "incoming", "outgoing" or "control". In addition, the "source" (beginning) and the "receiver" (end) of each functional arc can only be functional blocks, and only the output side of the block can be "source", and any of the three remaining "receiver.

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

When building IDEF0 - diagrams it is important to properly separate incoming interface arcs from the managers, which is often not easy. For example, in Figure 2 shows a functional block "Processing the workpiece".

In the real process, working, producing processing, is issued to the workpiece and technological instructions for processing (or safety regulations when working with a machine). It may seem erroneously that the workpiece and document with technological directions are incoming objects, but it is not. In fact, in this process, the workpiece is processed according to the rules reflected in the technological instructions, which must be represented accordingly to the control interface arc.

Figure 2.

Another thing is when technological instructions are processed by the main technologist and changes are made in them (Fig. 3). In this case, they are displayed already in the incoming interface arc, and the control object is, for example, new industrial standards, based on which changes are made.

Figure 3.

The examples above emphasize the externally similar nature of incoming and control interface arcs, however, for systems of the same class there are always certain distinctions. For example, in the case of consideration of enterprises and organizations, there are five main types of facilities: material flows (parts, goods, raw materials, etc.), financial flows (cash and non-cash, investments, etc.), documents flow (commercial, financial and organizational documents), information flows (information, information about intent, oral orders etc.) and resources (employees, machines, machines, etc.). At the same time, in various cases, incoming and outgoing interface arcs may display all types of objects that are managers only related to flows and information, and mechanisms with arcs only resources.

The mandatory availability of control interface arcs is one of the main differences in the IDEF0 standard from other DFD (DAGRAM) and WFD (Work Flow Diagram).

The third basic concept of IDEF0 is decomposition (Decomposition). The principle of decomposition is used when splitting the complex process to the components of its function. At the same time, the level of process detail is determined directly by the model developer.

Decomposition allows you to gradually and structured to represent the system model in the form of a hierarchical structure of individual diagrams, which makes it less overloaded and easily absorbed.

The IDEF0 model always begins with a system representation as a single integer - one functional block with interface arcs extending outside the region under consideration. This diagram with one functional block is called a contextual diagram, and is indicated by the "A-0" identifier.

In the explanatory text to the contextual diagram, the target (Purpose) of the constructions of the diagram should be specified in the form of brief description And the viewpoint is fixed.

Definition and formalization of the purpose of developing IDEF0 - model is an extremely important point. In fact, the goal determines the corresponding areas in the system under study, on which it is necessary to focus primarily. For example, if we simulate the activities of the enterprise with the aim of building further on the basis of this model of the information system, then this model will differ significantly from the one that we would be developed for the same enterprise, but in order to optimize logistics chains.

The point of view determines the main direction of the development of the model and the level of necessary detail. A clear fixation of the point of view allows you to unload the model, refusing the detailing and study of individual elements that are not necessary, based on the selected point of view on the system. For example, the functional models of the same enterprise from the points of view of the main technologist and the financial director will differ significantly in the direction of their detail. This is due to the fact that in the end, the financial director does not interest the aspects of the processing of raw materials at production machines, and the main technologist has nothing to do with the schemes of financial flows. Right choice The point of view significantly reduces the time costs of building a final model.

In the process of decomposition, the function block, which in the contextual diagram displays the system as a whole, is subjected to detail on another diagram. The resulting second level diagram contains functional blocks that display the main subfunctions of the functional block of the context diagram and is called a subsidiary (Child Diagram) with respect to it (each of the functional blocks belonging to the child diagram is respectively called the Child Box). In turn, the functional block is called the parent block in relation to the subsidiary (Parent Box), and the diagram to which he belongs is a parent diagram (Parent Diagram). Each of the subfunctions of the daughter diagram can be further detailed by a similar decomposition of the corresponding functional block. It is important to note that in each case of the decomposition of the function block, all interface arcs included in this unit are recorded or coming from it on a subsidiary. This achieves the structural integrity of IDEF0 - model. The principle of decomposition is clearly shown in Figure 4. Attention should be paid to the relationship of the numbering of functional blocks and diagrams - each unit has its own unique serial number on the diagram (digit in the lower right corner of the rectangle), and the designation under the right angle indicates the number of subsidiary for this block diagram . The absence of this designation suggests that the decomposition for this block does not exist.

There are often cases when individual interface arcs make no sense to continue to consider in child diagrams below some particular level in the hierarchy, or vice versa - separate arcs do not have a practical meaning above some level. For example, an interface arc depicting the "part" at the entrance to the functional block "Processing on the lathe" does not make sense to reflect on higher levels - it will only overload diagrams and make them complex for perception. On the other hand, it happens to get rid of individual "conceptual" interface arcs and not detail them deeper than some level. To solve such tasks in IDEF0 standard, the concept of tunneling is provided. The designation "Tunnel" (arrow Tunnel) in the form of two round brackets around the beginning of the interface arc indicates that this arc was not inherited from the functional parent block and appeared (from the "tunnel") only on this diagram. In turn, the same designation around the end (arrows) of the interface arc in the immediate close of the unit - the receiver means the fact that in a subsidiary in relation to this block of the diagram, this arc will not be displayed and considered. Most often it happens that individual objects and the corresponding interface arcs are not considered at some intermediate levels of the hierarchy - in which case, they first plunge into the tunnel ", and then, if necessary," return from the tunnel. "

The last of the concepts IDEF0 is a glossary (Glossary). For each of IDEF0 elements: diagrams, function blocks, interface arcs The existing standard involves creating and maintaining a set of appropriate definitions, keywords, narrative presentations, etc., which characterize an object displayed by this element. This set is called glossary and is a description of the essence of this item. For example, for the management interface arc "Payment Regulation" Glossary may contain a list of fields of the corresponding document arc, the necessary set of visas, etc. The glossary is harmoniously complements a visual graphic language, supplying diagrams with the necessary additional information.

Figure 4. Decomposition of function blocks.

Principles of the restriction of the complexity of IDEF0-diagrams

Usually, the IDEF0-model carry complex and concentrated information in itself, and in order to limit their overload and make readable, the corresponding difficulty restrictions are taken in the appropriate standard:

Restricting the number of functional blocks in a three-six chart. The upper limit (six) causes the developer to use hierarchies when describing complex items, and the lower limit (three) ensures that there is enough details on the corresponding diagram to justify its creation;

Restricting the number of suitable to one function block (emerging from one function block) interface arcs Four.
Of course, strictly follow these restrictions at all optionally, however, as experience shows, they are very practical in real work.

Discipline of group work on the development of the IDEF0 model

The IDEF0 standard contains a set of procedures that allow you to develop and coordinate the model of a large group of people belonging to different areas of the system of the simulated system. Typically, the development process is iterative and consists of the following conditional stages:

Creating a model of a group of specialists belonging to various fields of activity of the enterprise. This group in the terms IDEF0 is called authors (Authors). The construction of the initial model is a dynamic process during which the authors interview competent to the structure of various processes. Based on the available provisions, documents and surveys, a draft (Model Draft) model is created.

Distribution of draft for consideration, coordination and comments. At this stage there is a discussion of a draft model with a wide range of competent persons (in terms of IDEF0 readers) at the enterprise. At the same time, each of the diagrams of the draft model is criticized and commented in writing and commented, and then transmitted to the author. The author, in turn, also agrees in writing with criticism or rejects it with the presentation of the decision logic and again returns the corrected draft for further consideration. This cycle continues until the authors and readers come to a common opinion.

Official approval of the model. The approval of the agreed model takes place by the head of the Working Group if the authors of the model and readers do not have disagreements about its adequacy. The final model is a coordinated idea of \u200b\u200bthe enterprise (system) from a given point of view and for a given purpose.
The clarity of the graphic language IDEF0 makes the model quite readable for individuals who did not participate in the project of its creation, as well as effective for showing and presentations. In the future, on the basis of a constructed model, new projects may be organized, aimed at the production of changes in the enterprise (in the system).

Features of the National Practice Application of Functional Modeling by IDEF0

In recent years, interest in Russia in the methodologies of the IDEF family is growing steadily. I am constantly watching, looking through the statistics of appeals to your personal web page (http://www.vernikov.ru), which briefly describes the basic principles of these standards. At the same time, interest in such standards as IDEF3-5 I would be theoretical, and Idef0 is quite practically substantiated. Actually, the first CASEs, allowing to build DFD and IDEF0 diagrams appeared in the Russian market back in 1996, simultaneously with the release of a popular book on the principles of modeling in SADT standards.

Nevertheless, most managers still regard the practical application of modeling in IDEF standards rather as tribute to fashion than an effective way to optimize the existing business management system. Most likely it is due to the pronounced disadvantage of information on practical application These methodologies and with an indispensable software bias of the absolute majority of publications.

It is no secret that almost all projects of surveys and analyzing the financial and economic activities of enterprises are now in Russia anyway are associated with the construction automated systems Control. Due to this, IDEF standards in the understanding of most became conditionally inseparable from the introduction of information technologies, although with their help, sometimes you can effectively solve even small local tasks, literally with a pencil and paper.

When conducting complex projects for enterprise surveys, the development of models in the IDEF0 standard allows you to clearly and effectively display the entire mechanism of activity of the enterprise in the desired section. However, the most important thing is the possibility of collective work, which is provided by the IDEF0. In my practical activity there were quite a lot of cases when the construction of the model was carried out with direct help of employees of various units. At the same time, the consultant for a fairly short time explained them the basic principles of IDEF0 and taught working with appropriate application software. As a result, employees of various departments have created an IDEF diagram of the activities of their functional division that should have answered the following questions:

What enters the division "at the entrance"?

What functions, and in what sequence are performed within the division?

Who is responsible for performing each of the functions?

What is guided by the Contractor when performing each of the functions?

What is the result of the work of the unit (at the output)?

After coordinating the draft diagrams inside each particular unit, they are collected by the consultant in the draft model of the enterprise, in which all input and output elements are linked. At this stage, all the inconsistencies of individual diagrams and their controversial places are recorded. Further, this model again passes through the functional departments for further coordination and making the necessary adjustments. As a result, for a fairly short time and when attracting a minimum of human resources from the consulting company (and these resources, as you know, very expensive), it turns out an IDEF0-model of an enterprise according to the principle "as is", and what is important, it represents an enterprise with The positions of employees who work in it and thoroughly know all the nuances, including informal. In the future, this model will be transferred to the analysis and processing to business analysts that will search for "bottlenecks" in the management of the company and the optimization of the main processes, transforming the model "as is" to the corresponding representation "as it should be". Based on these changes and the final conclusion is made, which contains recommendations on the reorganization of management system.

Of course, such an approach requires a number of organizational measures, primarily by the leadership of the surveyed enterprise. This is due to the fact that this technique implies the imposition on some additional responsibilities for the development and practical application of new methodologies. However, it ultimately justifies itself, since additional one or two hours of work of individual employees within a few days make it possible to significantly save funds to pay for consulting services of a third party company (which in any case will tear off the work of the same employees with questionnaires and issues). As for the employees of the enterprise, one way or another, a pronounced opposition on their part I have not met in my practice.

The conclusion from all this can be made the following: absolutely not necessarily every time you yourself invent solutions for standard tasks. Always when you come across the need to analyze one or another functional system (from the system of designing a spacecraft, to the process of cooking a complex dinner) - use the proven and occasional methods for years. One of these methods is ideF0, which allows you to solve complex life tasks with the help of your simple and understandable toolkit.

One picture costs thousands of words

Folk wisdom

Often, in my work there is a need to not just explore and solve a certain problem, but to identify its location in the general model of the company's work. It is not enough to understand that a certain division works incorrectly, it is important to understand how it interacts with others. Otherwise, it is impossible to identify all existing problems and choose optimal method solutions to the task. And for this you need to explore the company's work and make it a functional model.

Of course, in theory, the functional model of the company's work should be at the head, and it does not matter, it is about organizing the work of the warehouse or the IT system from Lida before the application. But in reality, it almost never turns it out, and therefore, in the process of studying and finding a solution to the task with the client, I also create a functional model of the company's work or a certain process (function) on its own.

A few words about the advantages of graphics

As you know, IDEF0 functional models are always graphic schemes. They have their own features and rules for compiling. We will talk about it a little later. And now I would like to give a couple of examples of graphics efficiency. Why do I make an emphasis on this? Most likely, after my statement about the need for a functional model of the company's work, many people thought that it was all optionally, you can also explain how this or that function in the company works. That's what I want to talk about this.

And for starters, we will make a small excursion in history. Let's return to the distant 1877, during the Russian-Turkish war. It was then that the polygraphist Sotan first applied the schedule when describing hostilities. Now all this is usually for us, when describing any battle, everyone has arrow cards, which clearly show the course of battle. And in those days, military actions were described in words. For each fight - many, many words. And to understand in the end, what happens, it was very difficult.

And because the idea of \u200b\u200bSytin was truly revolutionary - he began to print lithographic copies of cards with the designation of fortifications and locations of military units. Called these cards "for newspaper readers. Benefit. " The idea turned out to be so relevant that the first edition of the "benefits" was spread instantly. And then such applications were very in demand. The reason is obvious. The schedule helped to understand what was practically impossible to disassemble with some words.

A similar example of helplessness of verbal descriptions I can also lead from my practice. One of my customers really asked to take up the implementation of the ERP system for his company. To the question, do they have some kind of technical task, I received the answer: "Yes, there is. But in it 400 pages. " At the same time, the client was very complained that my colleagues, to whom he applied earlier, or refused the project at all, or called clearly overestimated prices. After I saw that in the technical task there are really 400 pages, and it consists exclusively of the text description, I understood the cause of the behavior of the developers. To read this volume of text, to be inserted into it, understand all the nuances only in order to understand the task and call the price - this is true very difficult.

I suggested this client alternative option - Describe everything you can, graphically in the form of notations. Showed him examples of modeling. As a result, they now rethink their wishes and the design of the technical task.

I also know many other examples when the graphic modeling of business processes helped in working both my colleagues, business consultants and developers and businessmen himself.

Why it is important for my work

My work is always associated with making changes to the existing system. And in order to make changes and get the desired result, you need to explore what exists now. And it does not matter what exactly we do - we configure or install the CRM system from scratch, create an effective ERP system, engage in the integration of various systems to increase the automation of work as a whole. In any case, first, it is necessary to obtain an idea of \u200b\u200bthe existing work pattern, and only after that you can offer any changes and think over the solution options for the task.

After studying the existing position of things, I, like any other third-party specialist, create a commercial offer, in which I disclose my vision in the most detailed in detail, as well as the actions that must be implemented to solve the task, and, of course, the expected result.

Such reports on the survey of work are obtained by volume, occupy not one page that on the one hand, it is necessary, and on the other, it complicates perception. At first, I, like many, thought that surround reports are good, because a person pays for work and need to provide a maximum of detailed information.

Typical errors

Functional modeling is performed using a wide variety of tools, including not intended for modeling. In the latter case there is no verification on errors and limitations of the standard. The desire to increase the visibility and the lack of experience is often ending with errors.

Use of different colors

All items in the diagram are equally important. With functional modeling there are no more or less important elements. The disappearance of any will lead to a violation of the process and production marriage.

Often, when modeling on paper or in various programs, users are trying to increase visibility through the use of different colors. This is one of the most common mistakes. In fact, the use of multicolored arrows and blocks only makes an additional confusion, and also distorts the perception of the scheme.

Your model should be read in black and white, without any additional color solutions. This approach simultaneously helps to avoid misunderstandings and disciplines the creator of the model, as a result, the readability and literacy of the model increases.

Too large blocks

When drawing up the model, all the nuances of the company with all the details are often trying to display on one sheet. The result is a very large number of blocks with a large number of control arrows. Readability is lost.

The optimal option is the detailing sufficient to understand the question, and nothing more. Detailed details of the work of each unit or even an employee can be disclosed when selecting a detailed viewing of a process. And such a structure is created only if it really needs to work or make a decision.

Violation of the structure when making adjustments

Carefully make sure that it does not arise confusion or processes without incoming, outgoing and other important elements. For example, if in the example above, I consider it necessary to shift the point of view on the copywriter, I will be deleted from the author's scheme. And then the control elements "the author's experience and third-party sources", as well as the publication plan become unnecessary. After all, by them enjoys the author. The copywriter works with an audio file. And if they stay in general schemeIn detail will be carried out not clear where to make confusion.

Similarly, if I decide to add some block, it is important to make sure that he also have all the necessary attributes. Attentiveness is very important here, since when modeling complex business processes, changes in one part of the model may entail changes to another. They must be made.

Rules of the name of the control elements and blocks

It is important to remember a simple rule: control arrows are called noucent names, blocks - verbs. So accepted in the IDEF0 standard, and this approach helps to avoid confusion and errors.

Most often, errors are allowed when block names. For example, instead of "creating an article" write "Creating an article". Blocks in this approach are actions, and therefore they should always be verbs.

Benefits using IDEF0.

• The very first benefit is obvious - this is visibility. You yourself begin to understand how this or that system works, and you can also clearly clarify where in this system "subtle places" and how your solutions will help get rid of them.
• Understanding and lack of discrepancies. When discussing the work of the company using a functional model, you have visual and understandable intuitive problems with control elements. In addition, functional modeling involves creating a glossary, in which the conditional notation and terms are disclosed. As a result, you and the client, the head, other employees, when discussing the problem, speak the same language.
• Easy and high speed models. Of course, learn the simulation is not as simple as it seems. After all, the scheme is, in fact, the supersaturation of information, which is very good for understanding, but to implement such a submission required special approach. The brain analytics acts in this case as a very powerful press on the one hand, and the filter is on the other. But with experience, this process becomes very fast. As a result, you get a tool that will help and disassemble yourself, which is happening in a particular system, and with the help of a visual manual created in a short time to illustrate important moments to colleagues or customers.
• Discipline and no error. The IDEF0 standard assumes the strict framework and rules. This approach disciplines, and the habit of acting within the framework of the standard helps to avoid errors by inattention. Any violations of the standard become immediately noticeable.

What is the difficulty of using IDEF0

It is important to understand that only in the most simple cases two business analysts will create absolutely identical functional models to describe the work of the company. Any model is a reflection of the analytics experience, the depth of understanding the work of the business, which he seeks to describe, as well as in some way, his personal point of view on this business. Those. A person develops a business model from the point of view of the head, as if this leader is he who.

At the same time, I believe that a business analyst is not quite a profession, every business analytics is engaged in business analyst or developer of some systems that analyzes the business and seeks to build the most effective system. It is for these people and for these purposes the IDEF0 tool is intended.

Therefore, it is very important when drawing up a functional business model "as is" to constantly advise with the company's head, so as not to make mistakes that entail automatically errors at the decomposition stages. Also at subsequent stages, additional coordination may be required with the heads of structural units and employees. Only if your functional model "as is" will really reflect the real state of affairs, you can make some changes and suggestions. And to achieve qualitative results in such a work, first of all, the practical experience and knowledge of the characteristics of a particular type of business is required.

More articles on this topic.

6.2. Purpose and composition of the SADT methodology (IDEF0)

SADT Methodology (Structured Analysis and Design Technique - the methodology of structural analysis and design) is a set of methods, rules and procedures designed to build a functional model of the system.

The beginning of the development of this methodology was laid by Douglas Ross (USA) in the mid-60s. Xx in. Since then, Softech, Inc. system analysts have since Improved SADT and used it in solving a wide range of problems. Telephone network software, diagnostics, long-term and strategic planning, automated production and design, computer systems configuration, personnel training, finance and logistics management - here are some of the regions effective application SADT. Wide spectrum Regions indicates the versatility and the power of the SADT methodology. The program "Integration of Computer and Industrial Technologies" (Integrated Computer Aided Manufacturing, ICAM) of the US Department of Defense was recognized as SADT utility. This led to the publication of its part in 1981, called IDEF0. (ICAM Definition), as a federal standard for software development. Under this name SADT began to be applied by thousands of specialists in military and industrial organizations. Latest edition IDEF0 standard was released in December 1993. National Institute for US Standards and Technology (National Institute Standards and Technology, Nist).

This methodology describing the functional aspect of the information system competes with methods focused on data streams (DFD). Unlike them, IDEF0 allows you to:

Describe any systems, not just informational (DFD is designed to describe the software);

Create a description of the system and its external environment before determining the final requirements for it. In other words, using this methodology, you can gradually build and analyze the system even when it is difficult to prevent its embodiment.

Thus, IDEF0 can be used in the early stages of creating a wide circle of systems. At the same time, it can be used to analyze functions. existing systems and making decisions to improve them.

The basis of the IDEF0 methodology is a graphic process description language. The model in the notation IDEF0 is a combination of hierarchically ordered and interconnected diagrams. Each diagram is a unit description unit and is located on a separate sheet.

Model (AS-IS, TO-BE or SHOULD-BE) may contain 4 types of diagrams [ , ]:

Contextual diagram;

Decomposition diagrams;

Diagrams of tree knots;

Charts only for exposure (for Exposition Only, Feo).

Contextual diagram (Top-level diagram), being a vertex of the tree structure of charts, shows the purpose of the system (the main function) and its interaction with the external environment. In each model there can be only one contextual chart. After describing the main function, a functional decomposition is performed, i.e., the functions of which are the main one.

Further, the functions are divided into subfunction and so until the desired level of detailing the system under study is achieved. Diagrams that describe each such fragment of the system are called decomposition diagrams . After each decomposition session, expertise sessions are held - the subject area experts indicate the compliance of real processes to the created diagrams. The found inconsistencies are eliminated, after which they begin to further detail the processes.

Diagram of tree nodes Shows the hierarchical dependence of functions (works), but not the relationship between them. There may be several of them, as the tree can be built on an arbitrary depth and from an arbitrary node.

Charts for exposure it is built to illustrate individual fragments of the model in order to display an alternative point of view on the processes occurring in the system (for example, from the point of view of the organization's management).

6.3. Idef0 graphic notation elements

IDEF0 methodology has found wide recognition and application, first of all, thanks to the simple graphics notation used to build a model. The main components of the model are diagrams. They displays the functions of the system in the form of rectangles, as well as the relationship between them and the external medium by the arrows. The use of only two graphic primitives (rectangle and arrow) allows you to quickly explain the rules and principles of constructing IDEF0 diagrams to people unfamiliar to this methodology. This dignity allows you to connect and activate the Customer's activities to describe business processes using a formal and visual graphic language.

The following figure shows the main elements of the IDEF0 graphic notation.

Fig. 6.1. Idef0 graphic notation elements

The rectangle is work (process, activity, function or task) which has a fixed target and leads to a certain end result. The name of the work should express an action (for example, "Production of details", "Calculation of permissible speeds", "The formation of a statement of TsDL No. 3").

The interaction of work between each other and the outer world is described in the form of arrows. In IDEF0 distinguish 5 species arrows :

- entrance (English Input) - the material or information that is used and is converted to the operation to obtain the result (exit). The entrance answers the question "What is subject to processing?". As an entry, it can be like a material object (raw materials, detail, examination ticket), and not having clear physical contours (a request to the database, a teacher's question). It is assumed that the work may not have any entrance arrow. The entrance arrows are always drawn into the left side of work;

- control (English Control) - managers, regulating and regulatory data, which guides work. Management answers the question "in accordance with the work?". Management affects work, but not transformed by it, i.e. acts as a restriction. As management, there may be rules, standards, standards, rates, oral instructions. The arrow of control is drawn included in the upper face. If when constructing a diagram, the question arises how to correct the arrow from above or left, it is recommended to draw it as an input (on the left side);

- output (Eng. Output) - material or information that represent the result of the performance. The output answers the question "What is the result of work?". As an exit, it can be like a material object (part, car, payment documents, statement) and intangible (sample of data from the database, the answer to the question, oral instruction). The exit arrows are drawn outgoing from the right face of work;

- mechanism (Eng. Mechanism) - Resources that work. The mechanism answers the question "Who does work or through what?". As a mechanism, enterprise staff, student, machine, equipment, program can be. The shooters of the mechanism are drawn included in the lower line of work;

- call (English Call) - the arrow indicates that some of the work is performed outside the block under consideration. The exit arrows are drawn outgoing from the lower facet of the work.

6.4. Types of ties between work

After determining the composition of the functions and relationships between them, the question arises on the correct composition (combining) in the modules (subsystems). In this case, it is understood that each individual function should solve one, strictly defined task. Otherwise, further decomposition is necessary or the separation of functions.

When combining functions in the subsystem, it is necessary to strive to ensure that internal connectivity (between functions inside the module) is as stronger as possible, and the external (between functions included in different modules), as weaker than as possible. Relying on the semantics of the relationship of the methodology, we introduce the classification of links between functions (operations). This classification is an extension. Types of connections are given in order to reduce their significance (binding force). In the examples given by examples, functions are allocated, between which there is a type of communication in question.

1. Hierarchical connection (Communication "Part" - "whole") It takes place between the function and subfunctions, of which it consists.

Fig. 6.2. Hierarchical communications

2. Regulatory (managing, subordinate) Reflects the dependence of one function from the other when the output of one work is sent to managing the other. The function from which control comes out should be considered a regulatory or controlling, and in which it includes a subordinate. Distinguish direct communication when control is transmitted from the superior to the lower (Fig. 6.3), and control on management when control is transmitted from the downstream to the higher (Fig. 6.4).

3. Functional (technological) communication There is a place when the output of one function serves as input data for the next function. From the point of view of the flow of material objects this communication Shows technology (sequence of work) processing these objects. Distinguish direct communication at the entrance when the output is transmitted from the upstream operation to the lower (Fig. 6.5), and input feedback When the output is transmitted with the downstream to the higher (Fig.6.6).

Fig. 6.5. Direct communication at the entrance	Fig. 6.6. Feedback on the entrance

4. Consumer communication There is a place when the output of one function serves as a mechanism for the next function. Thus, one function consumes the resources produced by the other.

Fig. 6.7. Consumer communication

5. Logic communication It is observed between logically homogeneous functions. Such functions, as a rule, perform the same work, but different (alternative) methods or using different source data (materials).

Fig. 6.8. Logic communication

6. Collective (Methodical) Communication It takes place between functions, the algorithm of which is determined by the same control. Analogue of such a connection is the joint work of employees of one department (colleagues) submitting to the boss, which gives instructions and orders (control signals). Such a link also occurs when the algorithms of the operation of these functions are determined by the same methodological support (SNiP, GOST, official regulatory materials, etc.), which serves as a management.

Fig. 6.9. Methodical communication

7. Resource communication It occurs between the functions that use the same resources for their work. Resource-dependent functions, as a rule, cannot be performed simultaneously.

Fig. 6.10. Resource communication

8. Information communication It takes place between functions using the same information as input data.

Fig. 6.11. Information communication

9. Temporary communication It occurs between the functions that must be performed simultaneously before or simultaneously after another function.

In addition to those indicated in the figure, this connection also occurs between other combinations of management, input and mechanisms entering one function.

Fig. 6.12. Temporary communication

10. Random communication It occurs when a specific relationship between the functions of the small or is completely absent.

Fig. 6.13. Random communication

Of the above types of links, the hierarchical bond is the strongest, which, in fact, determines the combination of functions in the modules (subsystems). Several weakens are regulating, functional and consumer connections. Functions with these connections are usually implemented in the same subsystem. Logical, collegial, resource and information connections are one of the weakest. Functions with them are usually implemented in different subsystems, with the exception of logically homogeneous functions (functions associated with a logical link). Temporary connection indicates a weak dependence of the functions from each other and requires their implementation in separate modules.

Thus, when combining functions in the modules, the first five types of ties are the most desirable. Functions related to last five connections are better implemented in separate modules.

The IDEF0 has agreements (rules and recommendations) to create diagrams, which are designed to facilitate reading and examination of the model [,]. Some of these CASE rules support automatically, other execution should be provided manually.

1. Before building a model, it is necessary to determine which model (models) of the system will be built. This implies the definition of its type AS-IS, TO-BE or SHOULD-BE, as well as determining the position, from the point of view of which the model is built. The "point of view" is best to imagine as a place (position) of a person or an object in which you need to get up to see the system in action. For example, when building a model of the product of the grocery store, you can among possible applicants, from the point of view of which the system is considered, select the seller, cashier, accountant or director. One point of view is usually selected, the most fully embracing all the nuances of the system work, and, if necessary, for some decomposition diagrams, FEO diagrams displaying an alternative point of view are being built.

2. On the contextual diagram, one block is displayed, indicating the purpose of the system. It is recommended to display 2-4 arrows that come from each side for it.

3. The number of blocks on decomposition diagrams is recommended within 3-6. If there are two blocks on the decomposition diagram, then it usually does not make sense. In the presence of large number The blocks of the diagram becomes oversaturated and difficult to read.

4. Blocks on the decomposition diagram should be located left to right and top down. This location allows you to more clearly reflect the logic and sequence of work. In addition, the arrow routes will be less confusing and have a minimum intersection.

5. The lack of the function at the same time the arrow of the control and input is not allowed. This means that the launch of this function is not controlled and can occur at any time of time or never.

Fig. 6.14. Function without control and entry

The block with the availability of only control can be viewed as a call in the function program (procedures) without parameters. If the block has an input, it is equivalent to calling the function with parameters. Thus, the block without control and input is equivalent to the function that in the program is never called by execution.

In fig. 6.7-6.12, displaying fragments of IDEF0 diagrams, there are blocks without logging and control. It is not necessary to consider as an error, as it is understood that one of these arrows should be.

6. Each block must have at least one output.

Fig. 6.15. Function without exit

Work without result does not make sense and should not be modeled. The exception is the work displayed in the AS-IS model. Their presence indicates the inefficiency and imperfection of technological processes. In the TO-BE model, these works must be absent.

7. When building diagrams, minimize the number of intersections, loops and turns of the arrows.

8. Feedback and iterations (cyclic actions) can be depicted using reverse arcs. The inverse links on the entrance are drawn "lower" loop, feedback on management - "top" (see Fig. 6.4 and 6.6).

9. Each unit and each arrow on diagrams must necessarily have a name. It is allowed to use branching (decomposition) or a merger (composition) of the arrows. This is due to the fact that the same data or objects generated by one work can be used immediately in several other works. Conversely, identical or homogeneous data and objects generated by different works can be used in one place.

Fig. 6.16. Branch arrows

At the same time, it is allowed to set the clarifying name arrow after branching (before the merger). If any branch after branch is not named, it is believed that its name corresponds to the name of the arrow recorded before branching.

So, in fig. 6.16 Management included in the "Production of details" and "Product Assembly" blocks have clarifying values \u200b\u200band are an integral part of the overall control of the "drawings". All drawings are used to work "quality control".

The diagram does not allow the arrows to draw when before and after branching they are not named. In fig. 6.17 The arrow entering the block "Formation of typical statements" does not have a name before and after branching, which is an error.

Fig. 6.17. Incorrect name of the shooter

10. When building diagrams for better readability, the tunneling mechanism of the arrows can be used. For example, in order not to clutter the upper levels of the upper levels (parental), on the decomposition diagrams, the arc is placed in the tunnel.

Fig. 6.18. Tunneling arrows

In this example, when building a model of new Year's matinee The "Two Ax" mechanism will not be displayed on the upper level diagrams, when reading which a fair question may arise: "Why do you need two axes on the New Year's matinee?".

Similarly, you can perform tunneling with an inverse purpose - preventing the display of the arrow in diagrams lower levels. In this case, round brackets are put at the end of the arrow. On the contextual diagram (see Fig. 6.21), the mechanism of the Way Service Engineer, which is included in the "Definition of Allowed Speed" block. This decision is made, since the engineer directly participates in all the works displayed in the decomposition diagram of this block (see Fig. 6.22). In order not to show this connection and not clutter the decomposition diagram, the arrow was played.

11. All arrows incoming and leaving the block when building a decomposition diagram must be displayed on it. The exclusion is the cheesened arrows. The names of the shooters transferred to the decomposition chart should coincide with the names specified on the top-level diagram.

12. If two arrows pass in parallel (starting from one and the same facet of one work and end on the same facet of other work), if possible, they should combine them and call a single term.

Fig. 6.19. Combining connections

13. Each block on the diagrams should have its own number. In order to specify the position of any diagram or block in the hierarchy, the chart numbers are used. The block on the top-level diagram is indicated 0, blocks on the second-level diagrams - numbers from 1 to 9 (1, 2, ..., 9), blocks at the third level - two digits, the first of which indicates the number of the detailed block from the parent diagram, and The second block number in order on the current diagram (11, 12, 25, 63), etc. The contextual diagram has the designation "A - 0", the diagram of the first-level decomposition - "A0", the decomposition diagrams of the following levels - consist of the letter " A, "followed by the number of the decomposed block (for example," A11 "," A12 "," A25 "," A63 "). The figure shows a typical diagram tree (knotting tree diagram) with numbering.

Fig. 6.20. Hierarchy diagrams

In modern case-tools, the numbering mechanisms are supported automatically. Case funds also provide automatic construction of knotting diagrams, which contain only hierarchical ties. The vertex of such a diagram can be any node (block), and it can be built on any depth.

6.6. An example of constructing an IDEF0 model for a system for determining allowable speeds

The calculation of the allowable speeds of trains is a time-consuming engineering task. When passing by train, any site, the actual speed of the train should not exceed the maximum allowable. This maximum permissible speed is established on the basis of operating experience and specially conducted tests on the dynamics of movement and effect on the path of rolling stock. The failure of this speed guarantees the safety of trains movement, comfortable conditions for the ride of passengers, etc. They are determined depending on the type of rolling stock (the brand of the locomotive and the type of wagons), the parameters of the upper structure of the path (type of rails, ballast, spanks) and the plan (radius curves, transition curves, elevation of the outer rail, etc.). As a rule, it is necessary to determine at least two (on direct) and five (in curves) velocities to establish allowable speeds, of which the final permissible speed is selected as the smallest of all calculated. The calculation of these velocities is governed by the Order of the Ministry of Emergency Situations of Russia No. 41 of November 12, 2001. "The norms of permissible speed of movement of rolling stock in railway tracks of the King 1520 (1524) mm of federal railway transport".

As noted, the construction of the IDEF0 model begins with the representation of the entire system as the simplest component (contextual diagram). This chart displays the assignment (basic function) of the system and the necessary input and output, controlling and regulatory information, as well as mechanisms.

The contextual diagram for the definition of permissible speeds is shown in Fig.6.21. To build a model, a BPWIN 4.0 product was used by Computer Associates.

Fig. 6.21. Contextual diagram of a system for determining allowable speeds (IDEF0 methodology)

As source informationOn the basis of which the determination of permissible speeds is determined:

The data of the project of the new line or the reconstruction project (contain all the necessary information for the project implementation, namely kilomera, axes of separate items, line plan, etc.);

A detailed longitudinal profile (contains information similar to the above);

Passport Distance path (contains information similar to the above, as well as information about the upper structure of the path (VSP));

Data on the results of the shooting plan of the path by the passage carriage;

The statement of elevation of the outer rail in the curves (contains information about the path of the path).

Part of the source information can be taken from different sources. In particular, information about the plan (parameters of curves) can be taken from the project of a new line or a project of reconstruction, a detailed longitudinal profile, passports distance path, etc.

Data managers are:

Specifying the head of the road road or department of the road and structures of Russian Railways for the calculation;

Order number 41 containing regulatory and reference information, order and formula for determining allowable speeds;

Information about the current or planned trail (data on the brands of the contact locomotives and types of cars used);

Information about planned repairs of ways, reconstruction and reorganization of structures and devices.

Result System works must be:

Vedomosti allowed velocities containing all types of calculated speeds and allowing to establish the cause of their restrictions;

The statement of the order of the head of the road to establish permissible speeds on the distillations and separate items (order "H") according to the form adopted on the road. The approved order "H" officially enshrines the permissible speeds of trains;

Typical forms No. 1, 1A and 2, containing planned permissible speeds for developing train schedules.

The speeds contained in the "H" order and typical forms may differ from the calculated and shown in the permanent velocity. This is due to the fact that they reflect the limitations of the speed not only by the design of the rolling stock, the parameters of the VSP and curves, but also by the state of devices and structures (deformation of the earth canvas, the connector of the contact network supports, etc.). In addition, they are adjusted taking into account the planned repairs of the path, reconstruction and reorganization of structures and devices, etc.

After constructing the contextual diagram is detailed using a first-level decomposition diagram. This diagram displays the functions of the system that must be implemented within the framework of the main function. The diagram for which the decomposition is made, in relation to the details of its diagrams are called parental . The decomposition diagram in relation to the parental is called daughter .

The first-level decomposition diagram for the problem under consideration is shown in Fig.6.22. As a rule, when constructing a decomposition diagram, the initial function (decomposed) is divided into 3-8 subfunctions (blocks). At the same time, blocks on the decomposition diagram are recommended to be left to right from top to bottom so that the sequence and logic of the interaction of subfunctions is better visible.

Fig. 6.22. First Level Decomposition Chart (IDEF0 Methodology)

Priority of functions to solve the problem under consideration as follows:

Input and adjustment of regulatory information and data on road sites (blocks 1 and 2);

Preparation of the calculation assignment (block 3). It indicates for which site and path, as well as the brand of locomotive and the type of cars, the calculation should be calculated;

Calculation of permissible speeds in accordance with the procedure and formulas specified in Order No. 41 (block 4). As initial information, data on the path of the site (plan, upper structure of the path, etc.) and standards selected on the basis of a calculation assignment are performed;

The formation of the statements of permissible speeds (block 5). On the basis of the calculation results, several types of output documents are created, which, on the one hand, make it possible to reveal the reason for the speed restrictions, on the other hand, act as a basis for the preparation of regulated documents;

Formation and preparation of the project of the order "H" and typical statements (blocks 6 and 7).

After constructing the first level decomposition diagram for the functions specified on it, individual charts are being built (second-level decomposition diagrams). Then the process of decomposition (constructing diagrams) continues until further detailing of functions loses meaning. For each atomic function describing the elementary operation (i.e., the function that does not have a decomposition chart) includes a detailed specification that determines its features and an algorithm of implementation. As a supplement to the specification, block diagrams of algorithms can be used. Thus, the process of functional modeling is to gradually build the hierarchy of functions.

6.7. Icom-codes

The arrows included in the block and coming out of it on the top-level diagram are the same as the arrows included in the lower level diagram and the emerging of it, because the unit and diagram represent the same part of the system (see fig. and). As a result, the boundaries of the top-level function are the same as the boundaries of the decomposition chart.

Icom-codes (Abbreatetura from INPUT, Control, Output and Mechanism) are designed to identify boundary arrows. The iCom code contains a prefix that corresponds to the type of arrow (I, C, O or M), and the sequence number (see Fig.).