JP2001297003A - Structuring method for business process component - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a structuring method for a business component which can derive all business processes from a small number of basic components. SOLUTION: An atom metacomponent has plural atom processes and a metacomponent derived from the atom metacomponent is also present. To derive a component from a metacomponent whose operation object is not prescribed, operation objects are only given corresponding to the specifications of the component to be derived; and a multiplication metaprocess is given an order reception quantity 305a, an order reception unit price 305b, and an order reception amount 305c and then receives those operation objects to derive an order reception amount calculation process. Through mechanism like this, a metaprocess is adaptive to a diversity by deriving a business process according to given operation objects.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for constructing application development utilizing software components.
In particular, it provides a method for efficient construction and reuse of business process components.

[0002]

2. Description of the Related Art Conventional techniques related to the present invention include:
Examples include structured design techniques, data oriented approaches (DOA), and object-oriented analysis and design. These techniques are the methodological foundation of the present invention. In addition, in order to establish the development method as practical, a concrete means for realizing the method is indispensable. The development method of the present invention is specifically realized by COOL: Plex, a development tool of Computer Associates, and has demonstrated its feasibility and effects.

[0003]

Generally, since software components are reused as components developed in the past, it is considered that productivity and quality are improved as application components are developed. If so, if all the components of the application software can be made into parts and an application can be developed by combining the parts, ultimate productivity and quality can be given to the application. The present invention addresses this challenge in business processes,
The goal is to establish a way to build applications using only one principle, "parts".

Specifically, a method for solving the following three points is established. 1. All components must be able to define or change process characteristics while keeping the process description concealed. 2. All components can be combined with each other with the process description hidden. 3. The ability to derive all business processes by applying the above characteristics 1 and 2 from a small number of basic parts. The task is to establish the above three points as the principle of the business process component, which makes it possible to treat all components as black boxes and build an application using only those components.

[0005]

In order to solve the above problems, a method for constructing a business process component according to the present invention comprises:
Realize all business processes by assigning process objects from outside a small amount of atomic process components, constructing single process components, synthesizing multiple single process components constructed in this way and building composite process components It is characterized by the following. The method of constructing a single process component is characterized in that the operation is purified from the operation target of the process, and eight atomic processes are set at the top of the process.

In the above-described method of constructing a single process component, the process description is hidden by externalizing the operation target domain of the process, and the single process can be freely constructed by giving the operation target to the operation target domain. Can be. In the method of constructing a composite process component, various composite processes can be derived by multiple inheriting and synthesizing a higher-order process having a shared structure. In the method of constructing the single process component in the COOL: Plex, the process description can be realized by using the variable of the variable pallet as an external domain and extracting an operation target from the external domain by a meta description.

[0007] COOL: Ple of the composite process component
In the construction method for x, it is preferable to provide a shell for synthesizing primitive functions of COOL: Plex. The method of constructing the composite process component in the COOL: Plex is characterized in that process blocks corresponding to the five structures of the business process are provided, and all processes are positioned in any of these blocks. The method for constructing the COOL: Plex of the atomic process component is characterized in that the flow control process is realized as a meta process.

COOL: Ple of the above atomic process parts
In the construction method in x, an allophone synonym between entities can be defined, and an external process can be called through this definition process. In the present embodiment, COOL: Plex, a development tool of Computer Associates, was used as a means for verifying the feasibility and effects in constructing a development method for solving the above problem.
This is because the development method requires its own abstraction and generalization, and it seems that there is currently no other than COOL: Plex with a function that can realize this.

The functions unique to COOL: Plex required for specifically applying the development method of the present invention are described below. 1. COOL: Plex pattern library. All parts inherit the general-purpose process belonging to this. In particular, it is based on an IO process for the database and a basic process that constitutes a user interface. 2. COOL: Meta description which is a process description method of Plex. The meta description can describe inspection of process components such as entity relations, views, and fields and operations based on the inspection. 3. Multiple inheritance of functions. In COOL: Plex, a process is handled in the form of a function. However, this function can be inherited multiple times to form one function.

[0010]

Next, an embodiment of the present invention will be described in detail with reference to the drawings. 1. Subject of the Invention (1) Development of Reuse and Blockage Situation "Reuse" is an extremely effective means in improving the productivity and maintainability of software. Rather, reuse is the cornerstone of making software development more efficient, and there have been several forms of reuse in the past. Originally, there is nothing more suitable for reuse than software, and it can be said that it is the development history of the reuse form if you look at the history of its development.

[0011] The simplest form of reuse is duplication. The software is very easy to duplicate,
This requires little resources and time. This reuse form of copying is exclusively applied for the purpose of distributing software. On the other hand, there is also a great demand in software development, and in a case where a similar program is created, for example, a method is adopted in which a similar program is copied once and then different parts are modified. Of course, the higher the similarity, the more efficient it is to create from scratch.

A subroutine may be the first form of reusing the internal structure of a program. The subroutine is a re-use of this common process, with the idea that the same process description is frequently generated inside the program, and it is used as a common process and jumps back to it whenever necessary. is there. It can be said that the subroutine aims at reusing a partial process inside the program, while the reuse form of duplication / rework aims at reusing the entire program.

For quite a long time in program development, reuse has been realized by duplicating / reworking this program and making it into a subroutine. What has evolved from the side of reuse by making programs into subroutines is the componentization of software. A subroutine is originally shared within a program, and is limited to reuse within one program. Components that are externalized and can be shared by a plurality of programs are “parts”. As the name implies, the component is extracted and externalized so that the partial process can be shared by a plurality of programs. Come here,
The independence of processes that have only been reused in a single program has greatly increased the reusability of partial processes.

By making a simple subroutine into parts,
The reusability of the software has increased, but not all of the software processes have been turned into components.
This is because there are not many coherent processes that can be completely shared in business processes. Business processes have to deal with a wide variety of information depending on the type of business and business, and the reality is that they intersect in a complicated manner. Non-business processes, such as operations and character string operations that do not involve inputting and outputting information, can be easily made into components like functions, for example. On the other hand, in a business process, a variety of information is input and output, and the process cannot be realized without involvement in the input and output. If such business processes are to be made into components, the amount of components will increase due to the variety of businesses in the momentum. Then, in the development, maintenance and use of parts, there will be a state where it is far from enjoying the benefits of reuse. In business process componentization, the diversity of business processes is in conflict with components that essentially involve the externalization of common processes. This conflict between diversity and commonality has prevented business processes from becoming components.

(2) Object Oriented Development and Componentization The core system of a company can be said to be a systematic collection of business processes. Therefore, the more the reusability is applied to the development and maintenance of the core system, the faster and cheaper the core system can be constructed and the quality can be enhanced. However, as mentioned above, the diversity of business operations has hindered its reuse. This point is a barrier in the conventional development method, and it has not been possible to realize business process components in the original sense. That's where object-oriented development comes in. In the present invention, the characteristics of object-oriented development are grasped as the following two points, and attention is paid to evaluation as a development method.

1. It treats data and its operations as one, and puts it as an object at the core of software. 2. It considers objects as objects of abstraction and generalization, and tries to construct software by deriving concrete things from abstract things. How does object-oriented development with the above characteristics contribute to the componentization of business processes? In fact, component orientation and object orientation differ in their orientation. As mentioned above, the componentization occurred through the process of externalizing the internal common process, and in that respect it can be said that it is a product from a process-oriented viewpoint. Parts have emerged as process reuse has expanded and become more sophisticated.

However, today's process orientation has been baptized by DOA, and the viewpoint of data and processes based on the data is fundamental. The process is not the master, but the process is used for data. DO
A closer examination of the affinity of A with this data and process would lead to a view of data and process as one. At that point, there will be parts that overlap with the first characteristics of object-oriented development listed above.

The entities in the business process may be customers and suppliers, goods and employees, orders and sales, and the like. These entities have various attributes,
It is involved in various functions. And many of the variations are the characteristics of the business process. Object-oriented development is based on the connection between data and operation. Similarly, by projecting this connection onto an entity, an opportunity for partializing the entity is provided.
In other words, entities that appear in business can be dismantled in units of association between attributes and operations.

The following is an example of dismantling a standard order. No Attribute ---- Operation 1 Order number --- Numbering 2 Product and order price --- Acquisition of order price 3 Order quantity, order price, order price --- Order amount calculation 4 Order date --- By system date Initialization In the above example, the order entry entity is disassembled into four. Then, the combination of the attribute and the operation, which were the parts of the disassembled order, are new entities and parts, respectively. As described above, the business entity can be sliced into units by combining the attribute and the operation, and a variety of business processes can be expressed by a combination of such components.

By treating business entities as a combination of partial entities, it is possible to cope with the diversity, but the amount of the partial entities will be considerable. At this stage, development and maintenance of the sub-entities still require a lot of effort. This is because there is no standard for the business process that this partial entity embodies, and there is no mechanism to control it.

The second abstraction and generalization given as characteristics of object-oriented development solves this problem.
If a partial entity is abstracted, its number is reduced as the degree of abstraction progresses, and reaches the highest level abstract entity. If we can generalize this top-level abstract entity and derive various sub-entities from it, we can overcome the conflict between commonality and diversity. Partial entities can be derived by adding a difference to the top-level object as a common core. It establishes a common core through abstraction and creates diversity through the generalization of adding differences. By obtaining the mechanism of abstraction and generalization in this way, we deal with the diversity of partial entities, and create various business entities by combining partial entities.

(3) Subject of the Present Invention The subject of the present invention is to consider a core system as a systematic collection of business processes and to establish a method for efficiently forming the business processes by reuse. The basis of this is the DOA that projects the object-oriented development method as described above. In the present invention, the following concrete method is drawn on this basis. 1. The concept of parts as partial entities. 2. Concrete mechanism of abstraction and generalization. 3. COOL: Implementation of the technique in Plex.

First, the component concept of the present invention will be defined. This is defined as a partial entity as described above. Second, we present specific abstraction and generalization mechanisms to effectively deal with the diversity of parts as subentities. Third, in order to measure the feasibility and effects of the defined component concepts and the mechanisms of abstraction and generalization,
A method for implementing this in COOL: Plex will be described.

2. Definition of “Part” The “part” defined by the present invention is a software model in which a process and an attribute target of the process are integrated. FIG. 1 shows the structure of this "part". "Parts 101"
Consists of zero or more attribute items 103 and one or more processes 105 related to the attribute items. The “component 101” is roughly classified into an abstract component and a concrete component, and has a relationship of inheriting the abstract component and deriving the concrete component. Also, being a model indicates that it exists as design information before implementation in a language.

The component 101 is a systematic reuse unit. The fact that it is systematized has a certain standard, and is different from the reuse in the case where a similar program is copied and modified. More positively, the only thing that qualifies as an embodiment of reuse is parts. In the above, we projected the object-oriented development method and stated that a business entity is a partial entity when it is sliced in units of a combination of attributes and operations. At each point, it can be understood as a class in object-oriented terms. However, this sub-entity is based on the perspective of being a part of the entity, and as such is not an object. Although it is cut out as a part to improve reusability, it is not a part because it is combined during the mounting process.

3. Structural Analysis of Business Processes There are various types of business processes, and it is difficult to expect that obtaining the convenience of parts will involve holding an enormous number of parts that cannot be obtained if they are made into parts as they are. Therefore, it is necessary to elucidate the basic structure of business processes, identify the source of this diversity, and find clues to solving problems based on the elucidated structure. The basic structure of a process consists of the action that is the process itself and the target of the action. As shown in FIG. 2, in the process 201 of calculating the order amount, the multiplication and the setting of the multiplication result (storage in the field) are the effects, and the order quantity, the order unit price, and the order amount are the targets of the operation. is there. As described above, the action and the operation target are the most basic structures of the process. The operation target may be an attribute item of the entity or a temporary work field. Alternatively, a record or a view may be an operation target.

As shown in FIG. 2, calculation 201 of the order amount
And similar processes such as the calculation 203 of the sales amount have the same operation but different operation targets. If you look for such similar processes by focusing on the working side of the process, you will notice that the number is very large. If interpreted as "the process of calculating the amount by multiplying the quantity and the unit price", there are many similar processes such as order amount calculation and purchase amount calculation. If this were to be referred to as the "multiplication process", the similar process would be enormous.

Considering the original structure of the process, it can be said that the core of the diversity of the business process is the abundance of the operation objects. In a business process, this operation target varies depending on the type of business. It reflects the diversity of work in the world, not the diversity of the process itself. Since a business process is a business process, it naturally encompasses the diversity of world business. However, a business process is also based on a process, and if one looks at the diversity of the process itself apart from the diversity of the actors, it can be said to be the diversity of combinations.

The basic type of the operation itself is extremely simple. It is thought to consist of the following seven elements. 1. Reading 2. Write 3. Calculation 4. Settings 5. Conditional branch 6. Repeat 7. Invocation There are some variations on these seven elements, but the process itself is based on these. And the diversity of action is generated by the combination of these seven elements. In addition, since it does not itself take the form of description as a process, it is hard to say that it works,
"Relations" form a combination of actions. For example, in the management of order backlog, “calculation” of increasing or decreasing the order quantity and “calculation” of increasing or decreasing the order backlog occur. In this way, the "relation" connects the actions as an inevitable relation.

These seven basic processes are not business processes but computer processes, needless to examine their contents. It is a matter of course because it is the destination where all processes are abstracted. A business process is a complex of computer processes. This is reflected in the fact that business processes can be replaced by computer processes. If a business process or anything cannot be represented by a computer process, it will not be software. Also, the fact that the computer process is composed of seven
Consider the programming language specifications that exist in the world. In that case, the descriptive specification must be excluded.

The eighth "relationship" of the basic processes is not simply a computer process. And "relationships"
Defines a relationship between two or more objects. However, in relational processes that exclude the operands, the relationship between fields and records, the relationship between records,
This is an abstract relationship such as the relationship between fields and records. What can be regarded as an abstract relationship between fields is synchronization and inversion between fields. The relationship between the order quantity and the backorder quantity is in sync, and the relationship between the sales quantity and the backorder quantity is in a reciprocal relation. In addition, the abstract relationship between records has a dependency relationship such as a parent-child relationship, and the existence of a dependent source is based on the existence of a dependent destination. Therefore, the occurrence or disappearance of the dependent record is a constraint on the occurrence or disappearance of the dependent record. Further, the abstract relationship between a field and a record relates to the occurrence and disappearance of a record having a certain field value, and vice versa. A feature of this "relation" process is that it is a very simple connection of the seven basic processes.

Since business processes are required to embody business functions, many of them appear as complex specifications. The order amount calculation process taken as an example earlier does not simply multiply, but also involves actual customer rounding. Here, there are a customer-specific fraction processing information acquisition process, an order amount calculation process, and a fraction processing process. A business process that reflects such business specifications is nothing less than a composite process in which processes are combined. The diversity of real work can also be understood as the diversity of combinations of these processes.

A business process is derived by combining seven basic processes and assigning business fields. And various business processes are composed of various input processes, various conversion processes, and various output processes. That is, a business process that is a composite process is considered to have a basic structure such as input, transformation, and output. At the level of the basic process, "read" and "write" correspond to the input process and the output process. And the conversion process
"Operation", "Setting", "Conditional branch", "Repeat",
Formed by "call".

On the other hand, if this is grasped at the component level, the basis of input and output is the component itself, which is the subject of the process. From an object-oriented perspective, the process of inputting and outputting to this class is the basis of a business process. By distinguishing this from input and output to other classes,
The five processes of own input process, other input process, conversion process, own output process, and other output process are the basic structure of the business process.

From the above considerations, it can be said that the business process absorbs the diversity of information processing in business operations in the following two points. 1. A variety of information on actual business processes is received by enriching the process targets. 2. Various processes of the actual business process are dealt with by increasing the degree of complexity of the process.

The above discussion has elucidated the basic structure of a business process and identified the source of its diversity. The business process has a basic structure of the operation target and the operation, and realizes various business processes by enriching the operation target and improving the degree of compounding of the operation. In order to derive all business processes from a small number of basic components, which is the core of the subject of the present invention, attention must be paid to the mechanism by which this business process accepts the diversity of business. Then, if this mechanism can be correctly applied to the component configuration, the problem of the present invention will be solved.

4. Specific mechanisms of abstraction and generalization (1) Meta components In the structural analysis of business processes so far, the composition of eight basic processes and abundant objects that reflect the diversity of business has been drawn. In the present invention, the above eight basic processes are referred to as “atomic processes”. And we believe that all business processes can be derived from this atomic process. Further, in the present invention, the atomic process is not merely a category, but has a characteristic as “part” and is positioned at the top of the parts system.

If the operation target is excluded from the structure of the business process, the number of the processes is reduced, and finally the processes reach the atomic processes. Therefore, if the atomic processes excluding the operation target can be fixed as “parts” as they are, all processes can be derived by giving the operation target. Please look at FIG. Although an operation component is defined, the attribute of this component remains unspecified. In the process 303, there is a multiplication, but no operation target is defined. In the present invention, a “part” for which the attribute items are not defined is called a “meta part”.
A process whose operand is unspecified is called a “meta-process”. Since the "operation" shown in the figure is an atomic process,
We want to call such parts "atomic meta parts". This atomic meta-part is the source of all business process parts. An atomic meta-part has a plurality of atomic processes, and there is a meta-part derived from this atomic meta-part.

In order to derive a part from a meta-part whose operation target is unspecified, it is only necessary to give an operation target according to the specification of the part to be derived. As shown in FIG. 3, when the order quantity 305a, the order unit price 305b, and the order amount 305c are given to the multiplication meta process, the multiplication meta process receives these operation targets and derives the order amount calculation process. With such a mechanism, meta-processes derive business processes and deal with diversity according to a given operand.

In order to realize the characteristics of the meta process, the process description of the meta process must be described as a process for an undefined object. A process is described by treating an operand as a "operator defined in the future", but the descriptive object must exist.
In the case of the multiplication meta-process, two multiplication target values and one multiplication result value must be distinguished, and therefore, in the description, “△ multiplication △ = □” is used to distinguish between △ and □. On the other hand, ○, △, and □ are given at the derivation destination, so that they can be given from outside the process description. In other words, it is necessary to separate the process description itself from its substance, and to extend the receiving point of the substance outside the process description. The process description must have the function of referring to the socket where this entity is defined and incorporating it into its own process description. By obtaining such a mechanism, the meta-process can separate the action and the operation target at the description level, and can hide the process description from which it is derived.

In the case where a business process is derived by giving an operation target to a metaprocess, the structure for giving an operation target is as described above. Since the metaprocess separates the domain of the operation target outside the process description, it can be specified separately from the process description. In addition, by clearly defining the operation target domain, it is possible to define an operation target suitable for the operation. In the previous example, the domain to be multiplied and the domain to be multiplied are clear, the order quantity 305a and the unit price 305b are designated in the domain to be multiplied, and the order amount 305c is designated to the domain to be multiplied. I just need to. By separating the action and the action target in the metaprocess, a business process can be derived while completely hiding the process description. In the metaprocess, only the operation domain is made public to the outside, and the rest is kept hidden. With such characteristics, the first problem to be solved by the present invention can be solved.

(2) Process Synthesis The structure provided in the metaprocess can be said to correspond to the first mechanism described above, in which the business process accepts the diversity of business in the business. Metaprocesses deal with diversity by separating actions from objects and ensuring the freedom of giving the objects to actions. By exposing only the domain of the operation target and hiding all others, it is easy to derive various components. Next, I would like to describe a second mechanism for business processes to recognize the diversity of business operations, that is, a method of realizing a compound action while maintaining the process concealment.

A composite process is a combination of a plurality of single processes. In the case of the order amount calculation with fraction processing for each customer as described above, it is a combination of a customer-specific fraction processing information acquisition process, an order amount calculation process, and a fraction processing process. And when the processes combine,
In many cases, it is necessary to share the operation target. As shown in FIG. 4, the calculation amount is an operation target of both the order amount calculation process 401 and the fraction processing process 403. As described above, in the composite process, a mechanism in which the single processes share the operation target is important.

A single process must be able to function alone as a single process. On the other hand, when the single processes are combined, there are internal elements to be shared. It includes not only the operation target, but also initial processing and end processing, and message processing for errors and the like. While providing these shared elements as individual unit processes, they must be shared without duplication when combined. To do so, it is necessary to extract a primitive process consisting of those shared elements and derive all processes from the primitive process. This primitive process is the minimum function that the process must have as a process and must be provided equally by all previous atomic processes. This derivation is “inheritance”, and in the inheritance, the component of the inheritance source is shared by the inheritance destination. When a process is derived by multiple inheritance of processes having the inheritance source structure, the structure of the process that is the original inheritance source is shared and integrated into one structure.

From the characteristics of such multiple inheritance, if the shared element is a process shell and all the single processes inherit the same, the shared elements become one structure without duplication when combined. In this way, in the process inheritance, only the single process description, which is a difference from the viewpoint of the process shell, coexists. By applying multiple inheritance to processes in this way, single processes can be "synthesized" to form a composite process. As described above, since a plurality of single processes have a single structure, it is “synthesis” rather than “combination”.

In the example of the order amount calculation accompanied by the fraction processing for each customer, a complex form is adopted in which single processes are executed in parallel and sequentially. Composite processes include some such parallel composites and some more complex nested composites. Please look at FIG. The customer-by-customer order amount summarization process 501 is a combination of an order group read process 503, a customer-specific classification process 505, and an order amount summarization process 507 in a nested manner. Such a classification and aggregation process performs the aggregation while sequentially reading the records of the entities, and initializes the aggregation when a break in the classification key is detected. For this reason, a structure is provided in which the classification process is executed in the sequential reading process, and the counting process and the initialization process operate under the judgment of the classification process.

In order to derive a composite process such as a classification and aggregation process, it is necessary to draw an inheritance structure of a single process as shown in FIG. In order to enable free synthesis of a single process, the higher-level process structure inherited by the process to be synthesized must match. In the example of FIG. 6, both processes to be synthesized have inherited the group read process 601, and the structures match at that point. The atomic processes listed above are the top processes that all processes should inherit. Therefore, if it is possible to synthesize these atomic processes, all processes that inherit this process can be freely synthesized in principle.

Thus, the second problem, "the process description can be combined with each other while the process description is hidden" can be solved. In the composition of a process, a multiple process can be derived by multiple inheritance of a plurality of processes. This operation does not break into the process description because it only defines the inheritance relationship for the hidden process. Therefore, even in the synthesis of the process, the concealment of the process description is maintained.

5. Reuse of Business Process In the present invention, a method of object-oriented development is projected onto a DOA, and components are defined as partial entities integrating data and processes. We also devised an abstraction and generalization mechanism that separates action and action object based on the structural analysis of the process, and derives various processes depending on how the action object is given to the action. Then, the atomic process was positioned on the basis of the structure that combines the processes by multiple inheritance of the process to form a composite process.

By applying such a development method, it is possible to derive all the components from the atomic process while maintaining the concealment of the process, and realize a composite process by multiple inheritance of the components. In this way, a business process is constructed from a process with a small granularity through operation target definition and composition. In this method of creating a wide variety of business processes by accumulating processes from atomic processes, the only parts that are ultimately material are atomic meta parts. In this development method, various business process components are only derivatives of this atomic meta component. Therefore, any business process can be realized by repeatedly reusing atomic processes.

6. Method for Realizing Method in COOL: Plex (1) Means for Applying Development Method The outline of applying the development method of the present invention is as follows. 1. How to implement the part definition. 2. How to build a meta-process mechanism. 3. How to build an abstract process with a structure that realizes process synthesis. In order to apply the development method of the present invention, 3
Must have specific means in respect of the point. Hereinafter, means for realizing the development method of the present invention in COOL: Plex will be described in detail.

(2) Implementation of Component Definition The "component" defined by the present invention is a software model in which a process and an attribute object of the process are integrated. COOL: Plex is a model-based development tool that automatically generates program codes corresponding to various platforms from created models. Therefore, C
The model in OOL: Plex is provided with all information necessary for implementation. The implementation by COOL: Plex is realized by the model information given by the application developer and the information interpreted and given by COOL: Plex itself.

The process and the process of attribute of the process are realized by the “entity 701” of COOL: Plex. The entity 701 has a field as an attribute, and makes the process dependent in the form of its function. The entity 701 is a basic unit of inheritance. The entity 701 is an entity 701
Can be inherited singly or multiple times. Thus, the “parts” defined by the present invention are COOL: Pl
In ex, “entity” corresponds to it. See FIG.

(3) Construction of Meta Process In the present invention, a “part” whose attribute item is unspecified is called a “meta part”, and the process description of this meta process must be described as a process for an undefined target. . Then, it is necessary to extend the undefined target domain outside the process description.

The characteristic of such a metaprocess is COO
L: It can be realized by applying “meta description” provided by Plex as a unique process description method. In the meta description, fields in a set variable (variable area) are sequentially grasped, and the values and names of the fields can be used for the process description. COOL: P
In lex, the process description is made in an “action diagram”, and the variable is set in a “variable palette” because it is a variable area. Therefore, if the operation target domain is interpreted as variable, the operation target domain can be set separately from the process description. By defining a field that is an operation target in this variable and extracting it in the meta description, it is possible to construct a process without directly describing the operation target in the action diagram.

FIG. 8 shows a setting method for realizing the increment process by a meta process.
The "operation" atomic metaprocess has a function called increment. In this example, BP Inc. of the variable palette 801 inherits this increment function.
A field called counter is set in a variable called rementL (within 803 frames). Inside the metaprocess,
This counter field is incorporated into the increment description by the meta description, and the calculation process is realized.

(4) Construction of Process Synthesis In the synthesis of a process, a plurality of processes can be multiply inherited to derive a composite process. In order to achieve this process synthesis, the tool must support multiple inheritance of the process. In the COOL: Plex, the “entity” is a “part”, and the function subordinate to the entity is a process.
COOL: Plex can inherit this function multiple times.

Since COOL: Plex supports multiple inheritance of functions, it is possible in principle to specifically combine processes to derive a composite process. However, simply inheriting multiple functions often causes inconsistency inside the composite process. In the synthesis of processes, it is necessary that the shared elements of the single processes are not provided by themselves but are inherited from a higher-level process. To do so, it is necessary to extract a primitive process consisting of those shared elements and derive all processes from the primitive process. By doing so, the shared element becomes one structure of the composite process, and the multiple inherited process differences are composited.

COOL: Plex provides an original function, which is designed to inherit and implement a business process. The basic functions are shown below. 1. InsertRow (record registration) -------------------
-901 in FIG. UpdateRow (change record) -------------------
903 in FIG. DeleteRow (delete record) -------------------
-905 in Fig. 9 4. SingleFetch (1 record reading) -----------------
-907 in Fig. 9 5. ProcessGroup (read a group of records) 909 in FIG. 9 These primitive functions are ServerShel
Although derived from a common inheritance source of l, inconsistency may occur depending on the combination of multiple inheritance. Further, in order to realize a specific composite process, it is necessary to cope with the structure, flow control, and the like as the composite process. In the following, I would like to discuss what actions can be taken in this regard.

(5) Shell of Original Function In order to avoid inconsistency in multiple inheritance between the original functions provided by COOL: Plex, a shell of this original function is prepared. At the same time, this shell has a shared structure as the top function of the business process. Actually, the above 1 to 4
The original functions are called from the same point in the created shell. A common variable is provided for the call parameter and set. The COOL: Plex has a function of setting a field by specifying a call parameter in a variable manner. Furthermore, when a view is specified as a variable, restrictions such as “only a key field” or “other than a key field” can be given to the view.

Among the primitive functions, 5 is foreign. The “record group reading” of No. 5 is a combination of the repetition process and the record reading process. In this “record group reading”, the repetition process always has priority. Therefore, the repetition process also takes precedence when it is combined with other processes 1 to 4,
Other synthesized processes appear as processes in the iteration. For this reason, "read group of records" is not called in the shell, but is synthesized directly with the shell and becomes one. See FIG.

Thus, the underlying functions of COOL: Plex can be based on the same structure by being subsumed by the shell. When functions 1 to 4 are mutually inherited multiple times, a composite function in which processes are executed in the order of inheritance is derived. In the case where the functions 1 to 4 are multiple inherited with the function 5, a composite function in which the functions 1 to 4 are executed in the inherited order among the functions 5 is derived. In this composite function, while records are sequentially read, other inheritance processes are executed in the order of inheritance based on the read information.

(6) Structuralization of Composite Process The basic functions provided by COOL: Plex include “own input processes”, “other input processes”, and “own Output process "and" other output processes ". Process compounding is realized by multiple inheritance of functions. Then, in order to introduce five structures into this process complex, it is necessary to introduce a process block. The process block is a function for giving five blocks to the composite process. In the present invention, five blocks of an internal read block, an external reference block, an internal processing block, an internal update block, and an external update block are created. These blocks are obtained by adding each block as a subroutine to the basic shell described in (5) and setting an edit point. This process block has a function of controlling the execution order of a single process. The characteristics of each block are shown below.

Internal Read Block The SingleFetch (one record read) shell described in (4) is applied as a block as it is. External reference block Inherits the basic shell and derives a function that simply adds an edit point to the external reference subroutine. Internal processing block Inherits the basic shell and derives a function that adds an edit point to the internal processing subroutine.
Atomic processes of “calculation”, “setting”, “conditional branch”, and “repetition” inherit this internal processing block and derive it to be executed in this block. Internal Update block (InsertRow (record registration), UpdateR described in (4))
ow (change record), DeleteRow (delete record)
Apply the shell as a block as is. External update block Inherits the basic shell and derives a function that adds an edit point to the external update subroutine.

With these five process blocks, the structure of the business process can be maintained, and the execution order of the processes can be controlled. If the structure of the composite process is not maintained, the execution order of the single processes cannot be properly controlled. If a single process is simply combined, the following problems occur. When the composite process including the operation and the record addition A and the composite process including the operation and the record addition A are combined, a composite process including the operation, the record addition A, and the execution order of the operation is derived. In this case, the operation is meaningless as shown in FIG. 10 because no result is output (within 1001 frame). On the other hand, when the process block is applied, the calculation,
The execution order of the operation and the record addition A becomes the order, and the result of the operation can be output to the record as shown in FIG. 11 (within 1101 and 1103).

(7) Construction of Flow Control Process The “conditional branch” and “repetition” which are atomic processes control the flow of a process, and are conventionally described by control commands such as IF, CASE, and ROOP. Have been. And, in a process having a complicated structure, a plurality of flow control commands have always been used. The meta-process described above realizes a general-purpose process that can cope with diversity by externalizing an operation target and separating it from the operation itself. Meta-processing of the process that controls the flow enables the control process embedded in the process description to be controlled from outside. In addition, it is possible to separate the control process and the controlled process, and make each of them independent and subject to reuse.

In order to make the flow control process a metaprocess in COOL: Plex, the execution of a subroutine must be controlled after applying a meta description. In other words, the flow control needs to determine whether the process is TRUE or FALSE and control whether or not the process is executed.
For this reason, in the conditional branch, a variable that specifies the subroutine to be executed when the conditional branch determination is TRUE, and FALSE
In the case of, a variable for designating a subroutine to be executed is provided. What is specified in this variable is a field having the same name as the subroutine name. For these variable-specified fields, the field value is irrelevant to the process, and it makes sense whether a field with the same name as the subroutine is specified. TRUE for branch judgment
In the case of, the meta description gets the specified field name from the TRUE variable, and changes the execution of the subroutine with the same name from off to on. The principle is the same in the iterative process, the condition is that the designated area is provided as a variable, and even a logical operation is designated as a variable. It is also possible to extend the function to support complex conditional branching. See FIG.

(8) Construction of calling process There was a "call" in the atomic process. Processes promote their autonomous work by calling external processes,
Receive the result. The external process can be considered separately as an external process in which the entity including the operation target is the same and an external process in which the entity is different. And the information exchanged between the calling process and the called process must be common,
If the entities are different, they often do not match. For example, consider a case in which in the order receiving process, product unit price information is obtained from an external process. The product unit price acquisition process requires a product code to call this. However, if the product code is regarded as an ordered product code in the order receiving process, an external call cannot be established due to information mismatch. Also, the product price acquisition process returns the product price, but what is waiting in the order receiving process may be the order price. As described above, information transmission between processes is performed by relying on the names of the transmission items. Therefore, if the names of the transmission items do not match, the processes cannot be combined. Until now, developers who understand this synonymous synonym have corrected each time in their process descriptions. Without taking care of this allomorph, the "calling" process cannot be independent of the process description.

In order to properly deal with allophone synonyms that often occur in a business process and to make the calling process independent as a component, it is necessary to add a correspondence definition between fields and move values to the calling process. COO
In order to realize this in L: Plex, a meta description is applied to the definition of correspondence between fields, the corresponding definition area on the calling side and the corresponding definition area on the called side are respectively variable, and the value is moved between both variables. Have the function to make. In addition, the call itself is described as a CALL of a dummy function, and is replaced with the call function at the derivation destination. See FIG. As a result, the calling process becomes a general-purpose process that can externalize the field correspondence domain and replace it with a necessary calling process by replacement.

(9) Limits of Process Synthesis In a complex process, there are many cases where a plurality of the above-mentioned calling processes are executed. Such a complex process can be realized by inheriting a plurality of calling processes in a multiplex manner, but here a limitation appears. When multiple processes derived from a single general-purpose calling process are inherited multiple times, the common structure is the only structure at the destination. This property of multiple inheritance enables process synthesis, but prevents multiple inheritance of parts derived from the same meta-part.

FIG. 14 shows a calling process of combining an operation defining an allophone synonym between an order unit price and a product unit price, and a calling process of an operation defining an allophone synonym between a sales unit price and a product unit price. Was. What was required here was
The two calling processes are performed without interference. However, as a result of the composition, only the operation call of the calling process inherited later is valid, and the operation call has disappeared. In this case, the derived processes are synthesized with the expectation that the calling of the external process will be executed as many as the number of the derived processes to be inherited. Only the external calls are valid.

In process synthesis, processes derived from the same metaprocess must not be synthesized. In the record addition process including the operation process described earlier in the structuring of the composite process, the operation and the operation, which were separate processes, were combined into one, but the two operation processes are the same operation meta process. If it is derived from, it does not hold. In such a case, it is necessary to make the operation an external process and construct the process so that it is called externally immediately after the operation. Even in an external call, it is not possible to have a plurality of calling processes derived from a single calling metaprocess in the same process. Therefore, it is necessary to prepare a plurality of call metaprocesses.

In the synthesis of processes, a single process is synthesized to create a composite process, and attempts to cope with the diversity of business processes. The driving force is the mechanism of multiple inheritance. Single processes, on the other hand, try to deal with their diversity by assigning actors to a small amount of metaprocesses. And at the point of contact between these two mechanisms, the constraints mentioned here arise.

As described in detail above, according to the present invention, the incompleteness of the "abstraction" of the object-oriented technology is solved by the meta-component having the operation of the unspecified object. This made it possible to derive almost all business process components from a suppressed amount of top-level components. In addition, component synthesis is applied to effectively embody the abstracted components, but contradiction and inconsistency of the synthesis are avoided by standardizing the component structure. This facilitates compounding of the process and enables flexible part formation. Furthermore, as a mechanism for calling parts from parts, an interface and embedded parts were developed. This makes it possible to handle component calls by component synthesis,
It is now possible to accomplish this only with parts that are treated as black boxes in the entire life cycle of application development.

[0075]

As described above, according to the present invention, it is possible to provide a method of constructing a business process component in which all the components can define or change the characteristics of the process while keeping the process description hidden. Further, it is possible to provide a method of constructing a business process component in which all components can be combined with each other while the process description is hidden. Further, it is possible to provide a method of constructing a business process component that can derive all business processes by applying the above characteristics from a small number of basic components.

[Brief description of the drawings]

FIG. 1 is a view for explaining the structure of a component.

FIG. 2 is a diagram for explaining an original structure of a process.

FIG. 3 is a view for explaining the structure of a meta component.

FIG. 4 is a diagram for explaining the structure of a composite process.

FIG. 5 is a view for explaining a nested composite process.

FIG. 6 is a diagram for explaining synthesis of a process.

FIG. 7 is a view for explaining parts in COOL: Plex.

FIG. 8 is a diagram for explaining a metaprocess in COOL: Plex.

FIG. 9 is a diagram for explaining a shell of an original function.

FIG. 10 is a diagram for explaining a process in which a block is not introduced.

FIG. 11 is a diagram for explaining a process in which blocks are introduced.

FIG. 12 is a diagram for explaining a conditional branching process.

FIG. 13 is a diagram for explaining a calling process.

FIG. 14 is a diagram illustrating a simple composition of a calling process.

[Explanation of symbols]

 101,703 part 103 attribute item 105 process

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Hidego Ebata 1-4-10 Nakamachi, Urawa-shi, Saitama 5th Floor Inside CBCC Co., Ltd. (72) Inventor Masato Imamura 2-chome Nishi-Gotanda, Shinagawa-ku, Tokyo 23-1 F-term in Consulting M & S Co., Ltd. (Reference) 5B076 DD05 DD10

Claims (9)

[Claims] 1. A single process component is constructed by assigning a process target from outside a small amount of atomic process components, and a plurality of single process components constructed as described above are synthesized to construct a composite process component. A business process component construction method characterized by realizing a business process. 2. The method for constructing a single process component according to claim 1, wherein the action is purified from an operation target of the process, and eight atomic processes are set at the top of the process. How to build. 3. The method for constructing a single process component according to claim 1, wherein the process description is hidden by externalizing a process target domain of the process, and the process description is concealed freely according to how to give the target to the target domain. A method for building a business process component characterized by building a single process. 4. The method for constructing a composite process component according to claim 1, wherein various composite processes are derived by multiple inheriting and synthesizing an upper process having a shared structure. How to build. 5. The C of the single process component according to claim 3.
OOL: A construction method in Plex, wherein a variable of a variable palette is defined as an external domain, and a process description is realized by extracting an operation target from the external domain by a meta description. 6. The C of the composite process component according to claim 4.
A method for constructing a business process component, wherein a shell is provided for synthesizing primitive functions of COOL: Plex. 7. The composite process component according to claim 4, wherein
OOL: A method of constructing a business process component in which a process block corresponding to five structures of a business process is provided, and all processes are positioned in any of the process blocks. 8. The C of the atomic process component according to claim 2,
OOL: A method for constructing a business process component, wherein a flow control process is realized as a meta process in the plex construction method. 9. The C of the atomic process component according to claim 2,
OOL: A construction method in Plex, which defines an allophone synonym between entities and calls an external process through this definition process.