IDEF3 modeling methodology for describing Work Flow Modeling.

The IDEF3 notation is intended to describe Work Flow Modeling. IDEF3 is widely used to create models of business processes of an organization at a lower level - when describing work performed in departments and workplaces. It should be noted that the IDEF3 notation was taken as the basis for creating a methodology for describing ARIS eERC processes - “an extended chain of an event-driven process”.

The main graphic objects of the model used in IDEF3 are quadrangles and arrows. The first ones are used to describe functions (works, processes), the second ones - to reflect in the model the sequence of performing functions in time or the sequence of performing functions due to the flow of material resources.

In order to avoid the ambiguity of the description of workflows, additional objects are defined in the IDFE3 notation, which are used to display possible variants of branching and merging workflows that are implemented under certain conditions. These objects are logical symbols of three types:

1. logical operator "And";
2. logical operator "OR";
3. logical operator - exclusive "OR".

Unlike IDEF0 notation in IDEF3 notation of the side of a quadrilateral representing a function (work, process), they are not used to bind inputs of various types. Moreover, only one arrow can enter and exit the quadrangle. Otherwise, the charting rules in IDEF3 will be violated.

With the decomposition of processes in IDEF3, there is no migration and tunneling of arrows. The analyst himself must take care of the coherence of the modeling process and the correctness of the decomposition.

IDEF3 notation should be used in the case of relatively simple processes at the lower level of decomposition, i.e. workflow processes. In this case, the process diagram can serve as a basis for creating documents regulating the work of the performers. Obviously, the process in IDEF3 notation is “flat”. Using this notation, it is rather difficult to create combined models in which the descriptions of workflows and processes for managing these works would be combined. This fact becomes evident especially when comparing the descriptions of processes in IDEF3 and IDEF0 notation.

IDEF3 is a way of describing processes using a structured method that allows an expert in the subject domain to present a state of affairs as an ordered sequence of events while simultaneously describing objects of direct relevance to the process.

IDEF3 is a technology well suited for collecting data required for structural analysis of a system.

Unlike most business process modeling technologies, IDEF3 has no hard syntactic or semantic restrictions, which make the description of incomplete or non-integral systems inconvenient. In addition, the author of the model (system analyst) does not need to mix his own assumptions about the functioning of the system with expert statements in order to fill gaps in the description of the subject area. In fig. 3.1 depicts an example of a process description using the IDEF3 methodology .

IDEF3 can also be used as a business process design method. IDEF3 modeling organically complements traditional modeling using the IDEF0 standard methodology. Currently, it is becoming increasingly common as a completely viable way of constructing models of designed systems for further analysis using simulation methods. Simulation testing is often used to assess the performance of a system being developed. In more detail the methods of simulation analysis will be discussed below.

Fig.3.1 Description of the process in the IDEF3 methodology

Syntax and semantics of IDEF3 models

The IDEF3 model is based on the so-called business process scenario, which highlights the sequence of actions or subprocesses of the system being analyzed. Since the script determines the purpose and boundaries of the model, it is quite important to choose the appropriate name to indicate actions. For the selection of the required name, the standard recommendations for the preferred use of verbs and verbal nouns are used, for example, “process a customer’s order” or “apply a new design”.

The script for most models should be documented. Usually this is the name of the set of job duties of the person who is the source of information about the process being modeled.

It is also important for the system analyst to understand the purpose of modeling — the set of questions that will be answered by the model, the limits of modeling — which parts of the system will enter and which will not be displayed in the model, and the target audience — for whom the model is being developed.

Charts

As with any action modeling technology discussed in this book, the main organizational unit of the IDEF3 model is the diagram. The reciprocal organization of diagrams within the IDEF3 model is especially important when the model is deliberately created for subsequent publication or review, which is quite common practice in the design of new systems. In this case, the system analyst should take care of such information content of the diagrams so that each of them is self-sufficient and at the same time understandable to the user.

Unit of work. Act

Similar to other modeling techniques, action, or in terms of IDEF3, the Unit of Work (UOW), is another important component of the model. IDEF3 charts display the action as a rectangle. As already noted, actions are named using verbs or verbal nouns, each of the actions is assigned a unique identification number. This number is not used again even if the action is deleted in the process of building the model. In IDEF3 diagrams, the action number is usually preceded by the number of its parent (Fig. 3.2)

Fig. 3.2. Image and numbering of the action in the IDEF3 chart

Connections

Links highlight the essential relationship between actions. All links in IDEF3 are unidirectional, and although the arrow can start or end on either side of the block that indicates the action, IDEF3 diagrams are usually organized from left to right so that the arrows start on the right and end on the left side of the blocks. In tab. 3.1 shows the three possible types of relationships.

Communication type "temporary precedence . " As the name implies, links of this type indicate that the original action must be fully completed before the execution of the final action begins. The link must be named so that the person viewing the model understands the reason for its appearance. In many cases, the completion of one action initiates the beginning of the execution of another, as shown in Fig. 3.3. In this example, the author must accept the recommendations of the reviewers before starting to make the appropriate changes to the work.

Table 2.1

Fig. 3.3. Relationship of the type of “temporal precedence” between actions 1 and 2.

Communication type "object flow" . One of the most common reasons for using an object flow relationship is that an object that is the result of an initial action is required to perform an end action. The designation of such a connection is different from the connection of the temporal precedence by a double arrow. The names of streaming links should clearly identify the object that is transmitted with their help. The temporal semantics of object relationships are similar to precedence relationships, which means that the original action that generates the object relationship must complete before the final action can begin to run.

Communication type "fuzzy relationship." Links of this type are used to highlight the relationship between actions that cannot be described using antecedent or object relationships. The value of each such relationship must be determined, since the relations of the “fuzzy relation” type by themselves do not imply any restrictions. One of the applications of fuzzy relationships is the mapping of relationships between concurrently performing actions. Most often fuzzy relationships are used to describe special cases of precedence links, for example, to describe alternative variants of temporal precedence.

Connections

The completion of one action may initiate the beginning of the execution of several other actions at once, or, conversely, a certain action may require the completion of several other actions before they begin their execution. Connections break up or connect internal threads and are used to describe the branching process:

• sweep connections are used to split the stream. Completion of one action causes the beginning of the execution of several others;
• folding compounds combine threads. Completing one or more actions causes the start of another action.

In tab. 2.2 combined three types of compounds .

Table 3.2

Examples of folding and folding connections are shown in Fig. 3.4

Fig. 3.4 Two types of connections

"And" -connections. Compounds of this type initiate the execution of final actions. All actions attached to a folding "and" -connection must complete before the next action begins. In fig. 3.5 after detection

Fig. 3.5 “And” - Connections

the fire is triggered by the inclusion of a fire alarm, a call to the fire brigade, and the fire is extinguished. Logging is performed only when all three of the above actions are completed.

Connection "exclusive" or "". Regardless of the number of actions associated with the collapsing or unfolding connection “exclusive” or, only one of them will be initiated, and therefore only it will be completed before any action following the collapsing connection “exclusive” or “can begin . If the rules for activating a joint are known, they must be documented either in its description, or by marking the arrows coming out of the unfolding joint, as shown in fig. 3.6

In fig. 3.6 The connection “exclusive“ or ”is used to reflect the fact that a student cannot simultaneously be sent to lectures in two different courses.

Fig. 3.6 Connection “exclusive" or ""

Connection "or" is intended to describe situations that cannot be described by the two previous types of connections. In a similar way to a fuzzy relationship, the connection “or” is mainly determined and described directly by the system analyst.

Pointers

Pointers are special characters that refer to other sections of the process description. They are used in building a chart to draw the user's attention to any important aspects of the model.

The pointer is depicted in the diagram as a rectangle similar to the action image. The name of the pointer usually includes its type (for example, OBJECT, UOB, etc.) and an identifier (Table 3.3).

Table 3.3

Decomposition of actions

Actions in IDEF3 can be decomposed or decomposed into components for more detailed analysis. The IDEF3 method allows decomposing an action several times, which ensures that alternative process streams are documented in one model.

For correct identification of actions in a model with multiple decompositions, the numbering scheme of actions is expanded and, along with the numbers of the action and its parent, includes the ordinal number of the decomposition. For example, in the action number 1.2.5: 1 is the number of the parent action, 2 is the decomposition number, 5 is the action number.

IDEF3 business process description requirements

In this section, we consider the construction of an IDEF3 diagram based on a textual description of the process. It is assumed that the author of the diagram (mainly as a system analyst) and one or several subject matter experts representing the process take part in the construction of the diagram.

Definition of scenario, boundaries of modeling, point of view

For subject matter experts who prepare a description of the process being modeled, the boundaries of the modeling should be documented so that they understand the required depth and completeness of the description required from them. In addition, if the analyst’s point of view on a process differs from that of an expert, this should be clearly and thoroughly substantiated.

It is possible that experts will not be able to make an acceptable description without a formal survey by the author of the model. In this case, the author must prepare a list of questions in advance in the same way as a journalist for an interview.

Defining actions and objects

The result of the work of experts is usually a text document describing the range of questions that the analyst is interested in. In addition, written documentation may be attached to it, allowing to determine the nature of the process being studied. Regardless of whether the information is textual or verbal, it is analyzed and divided by parts of speech to identify the list of actions (verbs and verbal nouns) that make up the process, and objects (nouns) involved in the process.

In some cases, it is possible to create a graphical model of the process with the participation of experts. Such a model can be developed after collecting all the necessary information, which allows us not to take the time of experts on the formatting details of the resulting diagrams.

Since IDEF3 models can be simultaneously developed by several teams, IDEF3 supports a simple scheme of reserving action numbers in a model. Each analyst is given a unique range of action numbers, which ensures their independence from each other. In tab. 3.4 action numbers are allocated to each analyst in large blocks. In this example, analyst 1 fully used the range of numbers given to him at the beginning and additionally received the second one.

Table 3.4

Consistency and parallelism

If a model is created after the interview, the analyst must decide on the hierarchy of the diagrams participating in the model, for example, how detailed will be each particular diagram.If the sequence or parallelism of the implementation of actions is not completely clear, experts may be interviewed again (possibly using rough versions of incomplete diagrams) to obtain the missing information. It is important, however, to distinguish between the supposed (due to lack of information about the connections) and obvious (indicated in the description of the expert) ambiguities.

Выводы. IDEF3 — это способ описания бизнес-процессов, который нужен для описания положения вещей как упорядоченной последовательности событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу. IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения структурного анализа системы. Кроме того, IDEF3 применяется при проведении стоимостного анализа поведения моделируемой системы.