JP2008171023A - Software creation method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To automatically create a source program, and to secure independence from the operation base of task requirements, and to make it unnecessary to consider any variable-related sequence, and to achieve the improvement of quality and the reduction of a test process. <P>SOLUTION: This software creation method comprises: a first step to define predetermined attributes as data by word units belonging to each logical body based on requirement definitions; a second step for adjusting the excess and deficiency of requirements; and a third step for inputting data adjusted by the second step to an automatic creation tool having a Lyee given program structure, and for acquiring a target code. In the method, input processing and task processing and output processing are made independent, and the input processing is provided with a double Loop structure with the task processing as a "nested feature", and when it is decided that the input processing group is not completed, control is shifted to the input processing group again, and when it is decided that the input processing group is completed, control is shifted to the output processing, and the completion decision is not operated in the output processing, and the configurations of a superior/subordinate program are set. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a software generation method, and more particularly, to a software generation method in the Lyee methodology.

  The easy and rapid production of high quality software is a fundamental concern in the field of software development research. Over the past few years, various methodologies and techniques have been devised and proposed to improve one or many aspects related to the software development life cycle.

  However, despite intense efforts in this area of research, the production of a clearly understandable and modifiable system is a difficult goal and far from being achieved.

  Conventional system development has the following disadvantages.

  First, the business requirements depend on the operating base, and even a small change needs to take into account changes in the program and logic, resulting in instability in quality and complexity in the test process. This led to a delay in the entire system development project.

  This has also spread to program maintenance changes and additions, leading to complexity and inefficiencies.

  In addition, the amount of business application definition documents written in the program was enormous.

  In addition, the program only supports frames defined by each individual framework, and its versatility is low.

  The present invention has been made to solve the above-mentioned problems of the prior art, and it is possible to automatically generate a source program, to ensure the independence of business requirements from the operating base, and to consider the order of variable relationships. In addition, it is an object of the present invention to provide a software generation method that enables speedy system development by improving quality and reducing test processes.

  Still another object of the present invention is to provide a software generation method that is effective even in program maintenance change / addition work, and that facilitates and improves the work efficiency.

  Another object of the present invention is to provide a software generation method that can reduce the amount of description of a business application definition document of a program and can reduce the number of definition documents.

  Still another object of the present invention is to provide a software generation method that can easily cope with frames defined by various frameworks.

  In order to solve such a problem, the present invention provides a first step of defining a predetermined attribute as data in units of words belonging to each logical body based on a requirement definition, and a second step of adjusting excess or deficiency of requirements And a third step of obtaining the target code of the desired software by inputting the data adjusted in the second step as an essential element of the software into an automatic generation tool having a given program structure. In the software generation method, the input process, the business process, and the output process are made independent in the given program structure, and the input process has a double loop structure in which the business process is “nested” to complete the input process group. After the determination, if it is not completed, control is transferred to the input processing group again. If the input processing group is completed, control is transferred to the output processing. It is characterized in that the manager / subordinate program is configured without performing the end determination.

  According to the present invention, it is possible to automatically generate a source program, the independence of business requirements from the operating base is ensured, there is no need to consider the order of variable relations, and quality is improved and test processes are reduced. As a result, speedy system development becomes possible. Here, Lyee (trademark) is an acronym for “governmental method Y for software E product E” (a unified methodology in software development).

  Furthermore, the fact that programs can be developed quickly is effective even in program maintenance change / addition work, and facilitates and improves work efficiency.

  Furthermore, since the business application definition document of the program does not require a description related to program control, the amount of description is small, and the amount of definition document can be reduced.

  Furthermore, the Lyee program is compatible with both SIM and PSM defined by MDA. Also, because the Lyee program only defines the program structure, it can easily handle frames defined by frameworks other than MDA.

Hereinafter, the best embodiment of the present invention will be described with reference to the drawings.
Introduction Part 1 What is the Lyee Program? Chapter 1 Features of the Lyee Program 1.1 What are the conditions for starting work?
1.2 Boss / subordinate program 1.3 Boss / subordinate program made up of multiple modules Chapter 2 Basic form of Lyee program 2.1 Programming method of supervisor / subordinate program 2.2 Specific example: Purchase price calculation program 2.3 Summary 2 copies System development method using Lyee program generation function
Role of Lyee Program and System Development Method 1.1 System Construction Method: MDA
1.2 Role of Lyee Program 1.3 Description Method of Lyee Business Application Requirements 1.4 System Development Method 1.5 Lyee Program Generation Function Chapter 2 I / O Processing of Lyee Program 2.1 I / O Processing Programming Method 2 Specific Example: Purchase Price Inquiry Program 2.3 Summary Chapter 3 Multi-module Configuration of Lyee Program 3.1 Multi-Modification of Lyee Program 3.2 Specific Example: Order Screen Processing Program 3.3 Supervisor Program 3 Including Module Control .4 Module control subordinate programs Chapter 4 Effects on system development 4.1 Speedy system development 4.2 Efficiency improvement of maintenance work 4.3 Reduction of business application definition documents 4.4 Coexistence with various frames 4.5 Issues Reference Material 1 Detailed Explanation of Infinite Loop Prevention Specification Reference Material 2 Supplemental Reference to Program Flow 3 Lye eProgram Results Reference Material 4 Source Generation Tool Input Example Introduction
1 Innovative way of developing business application functions An original and innovative way of developing business application functions has been devised. How it is epoch-making is described in various materials introduced on this homepage, but here I would like to explain it from the viewpoint of the authors.
(1) Reasons for fast development: Regarding business application functions, which are the main elements of software development, in Lyee, the relationship between variables only needs to consider the logical relationship of the problem, and the relationship between complex variables There is no need to hesitate. This speeds up software development.
(2) Reasons for easy maintenance of business application functions: As described in (1) above, because Lyee only describes logical relationships, it does not describe other conditions in the first place. Unaffected by other conditions. As a result, the maintenance of the business allocation function does not occur as long as the goal to be realized (the logical relationship of the problem) does not change.
(3) Reason why such a Umai story is established: The relationship between variables can be programmed automatically. It can be said that this became a practical method only after the main memory of the computer became sufficiently large and the calculation speed increased.
Therefore, it is necessary to let the computer search for the relationship between the variables to some extent at the time of execution, and as a result, there is a limit to the application to software development that needs to increase the processing time to the limit. However, the computer automatically searches for the relationship between variables, so it can be useful in applications where speed of development and ease of maintenance are more important. In business processing software, not only processing time but also the value is recognized by the speed and maintainability of software development, so it is a development method that can be used practically enough. When using middleware that does not depend on applications, such as database access, it is necessary to have an interface defined by the middleware used, as with conventional software. Please enjoy the actual atmosphere with the sample program attached to this book.
2 Another explanation for improving development speed and maintainability
If you look closely at Lyee's methodology, you will find that programming in the traditional sense is not necessary to create a program.

  Exaggeratedly speaking, the development of business application functions only describes the “objects that handle meaning” as variables as data. That is, when the data definition is finished, the source program for the business application function is automatically generated there.

  What is specifically "describe as data" is not clear at the moment, but it shows how effective it is as you read this book.

  Programming is something you can't do, no matter how much you study, and software has been tracking this problem since the advent of computers. Nevertheless, there is still no advocacy for new methods of programming. Similar proposals will continue to appear in the future.

  On the other hand, the business application function development method for defining data basically does not continue to increase if the data runs out. This is because logic is attached to the data and the connection between the logics is left to an automatic generation tool, and a person does not create a new program.

Lyee can describe business application functions in the same way as defining data and can automatically create source programs, so in this book, we decided to call Lyee "automatic generation of data-oriented programs".
Part 1 What is the Lyee program? Chapter 1 Features of the Lyee program
The Lyee program has a surprisingly simple structure. Although the structure is simple, there is no need to consider any structure other than that structure regardless of the business application function. Therefore, there is no need to select the program structure from multiple candidates.

In this chapter, the structure of the Lyee program is likened to the role of a “superior / subordinate”, and its characteristics should be understood with an explanation at the idea level, with some precision sacrificed. If you understand here, you should be able to easily understand the explanation based on the program flow from Chapter 2 onwards.
1.1 What are the conditions for starting work?
The structure of the Lyee program is simple, but no matter what the business application function is, there is no need to consider other structures. Why is this possible? We will postpone the analysis of complicated cases, and consider the case where two types of people share work and process. The two types of people are the two types shown in Fig. 1. Here, the former is called the superior and the latter is called the subordinate. As it is intuitively obvious, business processing is performed by the collaboration of these two types of people. When processing is complicated, the subordinate may become a supervisor and work to other subordinates, but this is simply because the processing becomes complicated and the concept of processing does not change.

  Now, when simplifying collaborative work, after the boss asks someone else to do the job, he or she simply has to wait to see if the processing requested by the subordinate has been completed. On top of that, when all the subordinates have completed the process, the boss does the work he has to do and the work is settled down.

  The important thing here is that the order in which the subordinates work does not need to be considered by either the supervisor or the subordinates. In practice, when the conditions necessary for the subordinate A to work are not met, the subordinate A simply waits without performing work until the conditions are met. This naturally determines the order of processing. The subordinate A need only be interested in the conditions he needs, and does not have to worry about other things.

In the case where none of the subordinates who have been given work meets the requirements of their own, the work requested by the boss was impossible in the first place, the boss was notified that it was `` impossible '' The This limits the scope to consider when processing, no matter how big the job. The Lyee program is a computer program that is expanded.
1.2 Overview of Lyee's supervisor program and subordinate program in the specific process of calculating the purchase amount of the supervisor / subordinate program (FIG. 2).
Here, a part of the “lumps” of instructions that constitute a program that can be actually operated is called a program. The program here is equivalent to the supervisor module (or section) and the subordinate module (or section). In the figure, the business requirements are (1) purchase price = purchase quantity × unit price × (1−discount rate / 100), (2) discount rate: 20% or more of purchase quantity is discounted by 20%, and purchase quantity of 19 or less is 0% discount.
The structure of the subordinate program The subordinate is the person who does the work ordered by the supervisor. The “job” in the purchase price calculation processing is calculation of “purchase price”, determination of “unit price”, determination of “discount rate”, and it is assumed that there are three subordinates who take on these jobs.

  For the first person's subordinate (subordinate 1), the “work” of “calculation of purchase price” confirms whether the data necessary for the calculation is available, and if it is available, calculates and reports the completion to the supervisor . If not, wait until it is complete. This is represented by a flow chart in FIG. In the figure, “data necessary for calculation” is the purchase quantity, the product unit price, and the discount rate.

  The “work” of “determination of unit price” of the second subordinate (subordinate 2) is to obtain the unit price of the corresponding product from the product master. If the product master input process is completed, the unit price is obtained, and if the input process is not completed, the process waits until it is completed. This is represented by a flow chart in FIG. In the figure, the unit price is obtained from the product master with respect to “whether the data necessary for the unit price set is available”. Therefore, “data necessary for the unit price set” is a unit price for the corresponding product in the product master file.

  The same applies to the “work” of “determining the discount rate” of the third subordinate (subordinate 3). If the purchase quantity entered on the screen is 20 or more, 20% is discounted and the purchase quantity is 19 or less. In this case, the discount rate is 0% discount. If the purchase quantity entered from the screen cannot be obtained, it will wait until it is obtained. This is represented by a flow chart in FIG. In the figure, “data necessary for determining the discount rate” is the purchase quantity entered from the screen. Therefore, “data necessary for determining the discount rate” is the purchase quantity entered from the screen.

  These are the basic program flow of the subordinate program of Lyee. Since the example of calculating the purchase price is simple, there are only three subordinate programs, but the number of items may be 100 or more on one screen. In this case, there are 100 or more subordinate programs.

FIG. 6 shows the program flow of the subordinate program in a general form. The subordinate program is composed of three instruction groups. The feature of the Lyee program is that the first instruction is “determination” and the third instruction is “completion report”. Note that the second command is a command such as “calculation” or “value set” related to “instructed work” in the same way as a normal program.
1.2.2 Structure of the supervisor program Here, the supervisor program is not an essential item in the program structure, but is added to simplify the explanation.
(1) Boss program flow The boss is the person who performs the following three points.

    i. “Assign work and work instructions” to subordinates.

    ii. Do your own “work”.

    iii. Make a “completion decision” for the job.

The specific role of the boss program in the purchase price calculation
i. Assignment of work to subordinates and work instructions Subordinate 1: Calculation of purchase price
Subordinate 2: Determination of unit price Subordinate 3: Determination of discount rate
ii. My job: “input processing” and “output processing”
iii. Make a completion decision. The role of this boss is illustrated in the program flow as shown in FIG.

  It should be noted that here, the explanation of the Lyee program flow regarding input processing and output processing is omitted for the sake of simplicity of explanation regarding “input processing”. Refer to 2.1.1 and 2.1.3 of Part 2 Chapter 2 for the input / output processing Lyee program flow. In FIG. 7, “Call subordinate 1Sec” means that the control is transferred to the processing of the subordinate 1 section. FIG. 7 is a flow based on the current sequential processing type computer. The original concept of the Lyee program assumes the parallel processing shown in FIG.

  In “completion judgment”, a branch occurs between “completed” and “incomplete”, but the branch destination (transition destination) is the next.

      (A) When judged as “completed”: The process proceeds to output processing.

(B) When it is determined as “incomplete”: “work assignment and work instruction” is performed again.
Note that the determination method of “complete” requires a certain consideration in order to avoid an infinite loop. Here, since there is no endless loop, it is necessary not only to determine that “all completed” is complete, but also to “complete” is considered as complete even if the process is repeated many times. There is. For details, refer to Reference Material 1 Detailed explanation on the use of infinite loop prevention at the end of the book. Note that this infinite loop avoidance method is similar to the method of determining that data has been “arranged” in the sort process that arranges data in order.

(2) Process until completion of work The process until completion of work in the specific example of the calculation of the purchase price is as follows. To summarize this process, “the supervisor repeats the work instruction to his subordinates until the work is judged to be completed, and the work is always completed after repeating the work instruction several times”.

** Description of the process up to completion of work **
(1) First, input processing is performed, and the first “completion determination” is performed. The determination is “incomplete”.

<First loop>
(2) The first subordinate process is started. The “determination of purchase unit price” and “determination of discount rate” operations of subordinates 2 and 3 are completed. However, the “calculation of purchase price” operation is incomplete.

        (3) The second “completion determination” is performed, and the determination is “incomplete”.

<Second loop>
(4) The processing of each subordinate for the second time is performed. The calculation of the purchase amount calculation of subordinate 1 is completed because the data of the work premise is available. The subordinates 2 and 3 have already completed their work.

(5) The third “completion judgment” is performed, and the work is judged to be “completion”. The process moves to an output process, and after the output, the work ends. Here, although the number of subordinates increases, the number of repetitions (loop processing) leading to “work completion” is different, but it should be understood that the process until the work is completed is the same.
(3) Addition of criteria for subordinate program As described above, the subordinate program may be called many times by the supervisor program. In order to deal with this, the first determination in the subordinate program flow is that (1) “Is the data necessary for job execution complete?” And (2) “Do not execute again after the process is completed” to add. Specifically, FIG. 10 is obtained. As a result, it is possible to prevent wasteful recalculation and incorrect values of the accumulated value due to recalculation. In the same figure, “the data necessary for determining the discount rate is available” is specifically as follows. That is,
(A) “Data required for determination of discount rate” is “Purchase quantity” entered from the screen.
(B) “Whether or not discount rate has been determined” is determined by “discount rate determination record”. Refer to 2.1.3 (2) “Determination method of“ already implemented ”” in Chapter 2 for the specific contents of “discount rate determination record”.

FIG. 11 shows a summary of the flow of the supervisor program and the subordinate program in the purchase price calculation process.
1.3 Multi-module supervisor / subordinate program The features of the Lyee program have been explained based on the roles of supervisor / subordinate. There are many. Similarly, there are many cases where a single program performs a series of processing by combining a plurality of units (hereinafter referred to as modules). The concept of how the Lyee program deals with this multi-modularization is illustrated in FIG.
1.3.1 Concept of handling multiple modules
The Lyee program is handled with the following concept.
(1) Each module is hierarchically structured.
(2) The internal configuration of each module shall be the supervisor / subordinate configuration described above.

  FIG. 13 shows an example of the three layers on the left side of FIG. First, the structure of “department manager and section managers A and X” is a parent module, “section manager A and employees A1 to An” is a child module 1, and “section manager X and employees X1 to Xm” is a child module 2.

The roles of supervisors and subordinates within each module are the same as before. However, the subordinate “work” is also considered to be “work” (“call out child module” from a program).
Example of Lyee Program with Multiple Modules An outline of the Lyee program with multiple modules will be described with an example of an order screen (FIG. 14) obtained by adding an “order” process to the “money calculation” process described so far. Please refer to Chapter 2 in Chapter 2 for details.
Module structure of order screen program Please refer to Part 2, Chapter 3, 3.1.3 for module division method of Lyee program.

  It is assumed that the order screen processing is performed depending on whether the operator inputs information on the screen and presses the “calculate amount” button or the “order” button. As shown in Table 1, the module configuration of the order screen processing is a two-module configuration that is divided into two functions: a “screen input / output & amount calculation” processing function and an “ordering” processing function.

注文画面処理のモジュール構造は「画面入出力＆金額計算」モジュールが親モジュール、「発注処理」モジュールが子モジュールとなる。これを図示すると図１５のモジュール構造となる。なお同図で「入力：注文番号採番ファイル」とは、注文番号を採番するファイルとする。
（２）各モジュールの上司プログラムフロー
親モジュールと子モジュールの上司プログラムのフローは図１６、１７となる。

As for the module structure of the order screen processing, the “screen input / output & amount calculation” module is a parent module, and the “order processing” module is a child module. This is illustrated in the module structure of FIG. In the figure, “input: order number numbering file” is a file for numbering order numbers.
(2) Supervisor program flow of each module The supervisor program flow of the parent module and the child module is shown in FIGS.

  The feature of multiple modules is that “child module call” work is added as “work”.

  In FIG. 17, for “order number numbering file input”, since the order number is obtained from the numbering file, it is necessary to input and update the numbering file. The content of subordinate processing is “Call subordinate 11 (order number numbering) Sec” is the output item to the order number numbering file, “Call subordinate 12 (customer code set) Sec” to “Call subordinate 16 (order number set) Sec” "Is an output item to the order master.

FIG. 17 shows the superior program flow (order processing module) of the child module, but the actual child module call instruction is issued by “subordinate 5 (child module) Sec” of the parent module. See FIG.
(3) Subordinate program flow of “child module call” The program flow of “child module call” of subordinate 5 is shown in FIG. The feature is that the second instruction content of the program flow is "Call child module". The subordinate programs of the parent module and the child module have the same program flow as that shown in FIG.
Chapter 2 Basic Form of Lyee Program Chapter 1 explained the features of the Lyee program, taking the role of supervisors and subordinates as an example. In this chapter, the “completeness determination” of the supervisor program and the “completion report” of the subordinate program are developed into a flow that can be programmed, and the basic form of Lyee programming is explained. There are various ways of programming the boss and subordinate programs (techniques), but here we will explain them in a simple and clear way.
How to program a supervisor / subordinate program
The basic form of the Lyee program consists of a supervisor program and subordinate programs. In this chapter, programming methods for business application functions (business requirements) such as calculations, conditions, value sets, etc. will be explained with flowcharts.
2.1.1 Unit of work The boss subdivides and assigns “work” to subordinates. The first challenge of the Lyee programming method is how to determine the 'unit' of this “work”.

  The processing of the program is generally to perform business application processing such as “calculation / determination / processing” based on “input information” and “output information”.

  For this reason, the “unit” of “work” in the Lyee program is the item belonging to “output information” that is the result of calculation / judgment / processing as “unit of work”.

  Although the unit of work may be an output item group, there are problems such as how to make this "group", and it cannot be said that it is simple and clear. By determining the unit of work as an output item, the unit of work instruction of the supervisor program and the unit of each subordinate program are also uniquely determined. An operable program requires an input / output function in addition to the business application function. Please refer to Chapter 2, Chapter 2 and Chapter 3 for this "unit of work".

  In the example of the purchase price calculation screen of FIG. 19, if there are three output items, the three items in Table 2 become “units of work” and are also units of subordinate programs.

２．１．２ 上司プログラムの完了判定の方法
次に１章で述べた上司プログラム機能の中での「完了判定」を、プログラミングとしてどう具体化するかを説明する。

2.1.2 Method for Determining Completion of Supervisor Program Next, how the “completion determination” in the supervisor program function described in Chapter 1 is embodied as programming will be described.

  The “completion determination” of the superior program is a method of recording the “completion” state of “work” and determining the completion by determining the recorded contents. The completion can also be determined by determining the deliverable (output content). However, this method also requires judgment depending on the contents of the deliverables, so it is not suitable for automation of programming aimed at simplification.

  If the area name to be recorded is “business execution flag”, the flow of the supervisor program is as shown in FIG. In addition, an infinite loop of the supervisor program does not occur with the proper setting of the completion status record (specifically, “business execution flag”). In the figure, the infinite loop avoidance measure is determined as “completed” in (2) in the following “completion judging method”, so that the infinite loop of the supervisor program can be avoided. For details, refer to Reference Material 1 “Detailed Description of Infinite Loop Prevention Specifications” at the end of this manual. “Initial processing” is processing such as opening a general file, initializing an area (eg, setting the business flag On).

  Further, the completion determination method is one of the following.

(1) Incomplete: “Business implementation flag is On”
It means that processing has been performed by one of the subordinate programs (a product has been created). Using this deliverable, there is a “possibility to be processed”. Therefore, it is determined that the process is “incomplete (intermediate)”.

(2) Completion: “Business implementation flag is off”
No subordinate program was processed. In other words, the product was not made. This means that no matter what number of subordinate program processes are called, no new product can be created. Therefore, it is determined that the process is “complete”.

Furthermore, the termination process is a process such as file close, commit / rollback.
2.1.3 Method for Determining Business Execution of Subordinate Program Next, a description will be given of how the “determination of business execution”, which is the first instruction in the program flow of the subordinate program, is embodied as programming (FIG. 21).

  What must be performed in the first determination instruction of the program flow is “whether or not business can be performed” or “whether or not business should be performed”.

  Specifically, as shown in Table 3, the determination items require the following three items.

    (I) Did you have the appropriate data? Here, it has been described so far as “necessary data”, but strictly speaking, it is “appropriate data”. If it is not “appropriate data” for performing the calculation, the second process of the subordinate program flow cannot be performed. A specific example is as follows.

  <Example> 1 When the denominator in division is “0”: If D = E ÷ F and “F is 0”, calculation is not possible.

2 When the data value is Null by adding numerical values: A = B + C and “B is a null value” cannot be calculated.
(2) Has “work” already been carried out?

    (3) Is it necessary to carry out business (business requirements)?

なお、同表中、「データは定義域内か」に関しては、ある関数ｙ＝Ｆ（ｘ）でｘがある範囲内でないと成立しないことを意味する。上記で述べた２つの例はこのことの具体例である。

In the table, “is the data within the domain” means that a function y = F (x) and x is not within a certain range. The two examples described above are specific examples of this.

A specific method for determining the business execution of the subordinate program will be described in order, but FIG. As described later, “xxxx flag” is an item (area) name for recording the completion state.
How to determine whether “appropriate data is prepared” The data item that is the target of the first determination item “appropriate data is prepared” in Table 3 is “quantity” and “unit price” in “amount = quantity × unit price”, for example. It is. In general, the variable “X” of “y = f (x)” is the target item of “appropriate data” (simple item on the left side of the calculation formula). Specific examples are shown in Table 4. Here, the constants (“10” in A = 10, “0” in IF B> 0) are not subject to “appropriate data”.

では、この対象となった「データ項目」は何をもって「適切」と判断するか、が次の課題である。「適切なデータ」の判断は
(一)データの値が「ある」だけを判断する場合
(二)データの値が「あり」かつその値は定義域内でなければならない場合
の２ケースが考えられる。なおここで(二)において、定義域内とは表３のところで述べた注意事項を参照されたい。
ア データ値の「あり」を判定する方法
データ値が「ある」とは、入力されてデータ値が得られたり、計算や値のセットがなされたことによりデータ値が得られた状態である。なお、ここではデータ値の内容については問わない。

Then, what is judged as “appropriate” for this “data item” is the next issue. Judgment of "appropriate data"
(1) When judging whether there is only a data value
(2) There are two cases where the data value is “Yes” and the value must be within the domain. Here, in (2), please refer to the notes mentioned in Table 3 for the definition area.
(A) Method for determining whether or not a data value exists A data value that is “present” means that a data value is obtained by being input, or a data value is obtained by calculation or set of values. Here, the content of the data value is not questioned.

  There are various methods for this determination (there is a method to determine the “initial value” of the item, but there are cases where it depends on the processing content, and it cannot be said that it is a simple and clear method). However, the Lyee program can be automated. For the sake of illustration, it is simple and clear that the “present / not present” state of the data value of each data item is recorded in the area, and the “present / not present” data value is determined based on the recorded contents.

  Specifically, as shown in the upper part of Table 5, “xxxx completion flag” is set for each item, and “set completion” information is recorded after input processing is completed or after calculation or value setting is performed. When the setting of the item value is not completed, the “completion flag” is recorded as “Off”, and when the setting of the item value is completed, the “completion flag” is recorded as “On”. Thus, the “data value present” determination is in the lower part of Table 5.

なお、同表中、「購入数量入力完了フラグ」とは、入力項目の「項目入力完了フラグ」をOnとする処理個所は２部２章Lyeeプログラムの入出力処理で説明する。
イ データ値が「定義域内」であるかを判定する方法
データ値が「定義域内」であるかを判定する方法は、部下プログラムの２番目の命令である計算式や使用する関数等の内容により決るため、それに合わせ判定内容を記述する必要がある。なお(一)「Null」値では数値計算不可や(二)割り算での「分母が０」は不可、などが共通的な内容として「定義域内」か否かの判定の項目である。

In the table, the “purchased quantity input completion flag” means that the processing part where the “item input completion flag” of the input item is On will be described in Part 2, Chapter 2 Lyee program input / output processing.
Method of judging whether data value is "within definition domain" The method of judging whether data value is "within definition domain" depends on the contents of the calculation formula that is the second instruction of the subordinate program, the function to be used, etc. Therefore, it is necessary to describe the contents of the judgment accordingly. Note that (1) “Null” value cannot be numerically calculated and (2) “Denominator is 0” is not possible in division.

（２）「既に実施済か」の判定方法
表３の判定項目の２番目は、当該仕事である「値のセット」や「計算」等が「既に実施済みか」否かを判定する。

(2) Judgment Method of “Is Already Performed” The second judgment item in Table 3 judges whether or not “value set”, “calculation”, etc., which is the work, is “already implemented”.

  The programming method of this determination can be realized by the “xxxx completion flag” method as in the above (1). That is, it is simple and clear that the “executed” state of the work is recorded in the “completion flag” and the execution is determined based on the recorded contents.

  Specifically, a “completion flag” for “output item xx” is prepared, the flag is set to “Off” in the initial state, and when calculation or setting is performed, the flag is recorded as “On”. Note that the processing of the item is executed only once by the on / off setting mechanism. The infinite loop of the supervisor program is prevented by the determination of “already implemented” in this subordinate program and the “completion report” in 2.1.4. Refer to Reference Material 1 for details on infinite loop prevention.

（３）「業務遂行をする必要があるか（業務要件）」の判定方法
表３の判定項目の３番目は「業務遂行の必要性」を判断する。これは一般的な業務要件に該当し、出力項目ｘについての「業務的な条件」がある場合に設定する。このため具体的内容は各業務要件により決まる。表８はその具体例である。

(3) Method for Determining “Does Business Need to be Performed (Business Requirements)” The third judgment item in Table 3 is to determine “need to perform business”. This corresponds to general business requirements and is set when there is a “business condition” for the output item x. Therefore, the specific contents are determined by each business requirement. Table 8 shows specific examples.

２．１．４ 部下プログラムの「完了報告」方法
部下プログラムの説明の最後は部下プログラムフローの第３番目の命令である上司への「完了報告」である。この「完了報告」をどうプログラミングするかを説明する。
（１）「業務完了」の記録
仕事の「完了報告」は前述の「２．１．２ 上司プログラムの完了判定の方法」に対応させる必要がある。部下プログラムの「完了報告」方法は部下プログラムの第３番目の命令で「業務実施フラグ」を「On」と記録する。これにより、上司プログラムもまたこの「業務実施フラグ」をチェックすることで部下に割り当てた仕事の完了判断ができることとなる。
（２）当該項目の「既に実施済み」の記録
また「２．１．３（２）‘既に実施済か’の判定方法」で述べた当該項目の処理完了記録も部下プログラムフローの第３番目の命令群で実行しておく。具体的には当該項目の「セット完了フラグ」を「On」とする。以上をまとめると部下プログラムのフローは図２３となる。なお、同図中、「出力項目ｎの業務的条件」は、業務的条件はOr、Andや＝、≠、＜、＞等、使用言語で記述可能な判定識別子を使用して記述する。
Lyeeプログラムの領域
Lyeeプログラムの領域は一般的なデータ領域の他、Lyeeプログラムに特有な領域として、前述の各種完了情報を記憶する「フラグ」を制御情報として設定する必要がある。図２４に示す。
２．２ 具体例：購入金額計算プログラム
やや抽象的にLyeeプログラミングの方法を説明して来たが、具体例でその内容を 確認されたい。
２．２．１ 購入金額計算のプログラムフロー
（１）画面と業務要件
画面と業務要件は以下（図２５及び表９に示されるとおり）とする。単価は商品マスターを読むことで得られるものとする。

2.1.4 “Completion Report” Method for Subordinate Program The last explanation of the subordinate program is “completion report” to the supervisor, the third command in the subordinate program flow. Explain how to program this "completion report".
(1) Record of “business completion” “Completion report” of work needs to correspond to “2.1.2 Method of judging completion of supervisor program” described above. The “completion report” method of the subordinate program records “operation execution flag” as “On” in the third instruction of the subordinate program. As a result, the supervisor program can also determine the completion of the work assigned to the subordinate by checking the “business execution flag”.
(2) “Already implemented” record for the item The process completion record for the item described in “2.1.3 (2)“ Determination method ”” is also the third subordinate program flow. It is executed with the instruction group. Specifically, the “set completion flag” of the item is set to “On”. In summary, the flow of the subordinate program is shown in FIG. In the figure, “business condition of output item n” is described using determination identifiers that can be written in the language used, such as Or, And, =, ≠, <,>, etc.
Lyee program area
In addition to the general data area, the Lyee program area is an area unique to the Lyee program, and it is necessary to set the “flag” for storing the various types of completion information as control information. It shows in FIG.
2.2 Specific example: Purchase price calculation program The Lyee programming method has been explained somewhat abstractly, but please confirm the content with a specific example.
2.2.1 Purchase Flow Calculation Program Flow (1) Screen and Business Requirements The screen and business requirements are as follows (as shown in FIG. 25 and Table 9). The unit price is obtained by reading the product master.

（２）Lyeeプログラムの全体構成
Lyeeプログラムの領域と命令の構成は以下となる。
ア 領域の構成

(2) Overall configuration of the Lyee program
The Lyee program area and command structure are as follows.
A Area configuration

イ 命令の構成

B Composition of instructions

（３）上司プログラムのフロー
上司プログラムの処理内容は以下の(一)〜(八)となる。(三)〜(六)は業務処理が完了するまで繰返される。フロー図は図２６である。
(一)初期処理：制御情報の各フラグのOff、業務実施フラグのOn、ファイルOpen等を行う。
(二)入力処理：画面情報入力、商品マスターReadを行う
(三)業務処理：完了判定
業務実施フラグがOn：(四)以降を実施
業務実施フラグOff：画面出力処理へ遷移
(四)業務実施フラグをOffとする。

(3) Boss program flow The processing contents of the boss program are the following (1) to (8). Steps (3) to (6) are repeated until the business process is completed. The flowchart is shown in FIG.
(1) Initial processing: Each flag of control information is turned off, task execution flag is turned on, file is opened, etc.
(2) Input processing: Screen information input, product master read
(3) Business processing: Judgment completion Business execution flag is On: (4) and after are executed Business execution flag Off: Transition to screen output processing
(4) Set the task execution flag to Off.

(5) Execution of each output item processing sec (calculation of purchase price, determination of unit price, determination of discount rate)
(6) Move to `` (3) ''
(7) Output processing: Output the processing result to the screen.
(8) End processing: file close etc. In the same figure, "initial processing" performs area initialization, open etc. Regarding "input processing (screen input, product master read)", refer to Chapter 2 Chapter 2 for the input / output processing methods unique to Lyee programming. As for the “discount rate”, there are two processes, a set of 0% and a set of 20%, so two subordinate programs sec are prepared.
(3) Flow of Subordinate Program There are four subordinate programs shown in FIGS. Each is the same type as the basic form of FIG.

  The business requirement of the discount rate set ‘purchase quantity“ 19 or less ”is 0%, and“ 20 or more ”is 20%”. The second command differs depending on the conditions, so two subordinate programs are prepared. In this case, “If xx Then yy Else zz” is possible, but in order to make the subordinate program flow the same form and to contribute to the realization of automatic program generation, a plurality of subordinate programs are created.

In addition, “implementation condition determination” in FIG. That is,
If purchase quantity input completion flag = On
And Product unit price set completion flag = On
And Discount rate set completion flag = On
And purchase amount set completion flag = Off
2.2.2 Calculation Completion Order The purchase price calculation program is executed and the order in which the supervisor program and subordinate program are completed and the purchase price are calculated are the same as those in FIG.
2.3 Summary Although this is a very simple example, this is the basic form of the Lyee program. The output of at most 3 items may provide various flags or give the impression that it is quite troublesome, but there is also an aspect that a program that does not consider the ordering can not be done unless it is this place.

The second part will explain the more practical input / output processing method of the Lyee program, etc., but the input / output processing method etc. is an extension of the “completion judgment method” described in this chapter to a “multi-stage” nested structure. It was just. The contents explained in Part 1 and Chapter 2 are basic, and the contents of Part 2 should be read with the recognition that they are “only applied”.
Part 2 System Development Method Using Lyee Program Generation Function Part 1 explained the characteristics of the Lyee program, which is a groundbreaking way to develop business logic. In Part 2, we will explain where the Lyee program is positioned in system development practice, input / output processing and automatic program creation for enabling automatic programming.
Chapter 1 Role of Lyee Program and System Development Method 1.1 System Construction Method: MDA
When constructing a system, it will be constructed using the optimum method among various construction methods proposed. Here, the role of the Lyee program is specified according to MDA (Model Driven Architecture) proposed by the Object Management Group (OMG), and the concept of the system development method on the premise of Lyee programming will be described.

  MDA is a methodology that organizes several standard technical specifications. FIG. 31 shows a brief summary of the functional system defined by the MDA. (1) "Web interface function" responsible for communication-related interfaces (2) "User interface function" responsible for the interface between business and users (3) "Business application function" that performs the business process (4) Common The four functions are “common routine functions” that are responsible for various processes.

  Further, FIG. 32 shows a configuration in which the overall system is associated with the entire system within a company or between companies based on this functional configuration. This positions FIG. 31 as one local system, and the entire system is an image in which these are connected by a network. The contents of each element are as follows.

(1) W: WEB function
(2) A: Business application functions and user interface functions
(3) Lib: Library functions such as common routines
(4) I / O: I / O function such as database 1.2 Role of Lyee program
The Lyee program is responsible for realizing business application functions in the MDA functional system. Operable Lyee programs use web interface functions, user interface functions, and common routine (database, numerical algorithm, etc.) functions, and create business application functions with code that complies with the programming language used. .
1.3 Method of describing business allocation requirements of Lyee program About the method of describing business allocation requirements The Lyee program can describe business requirements from the program structure in the same way as defining data. Table 12 shows the business requirements of the purchase price calculation program in Part 1, Chapter 2, 2.2.

ＭＤＡではシステムの稼動基盤に独立なモデル（PIM：Platform Independent Model）と、稼動基盤に依存したモデル（PSM：Platform Specific Model）の２区分を規定している。Lyeeプログラムの業務アプリケーション機能の要件記述方法は表１．３のように、データを定義するのと同様であり、データは稼動基盤により変化するものではない。このため、Lyeeプログラムの業務アプリケーションの要件記述方法は、稼動基盤に独立した記述モデルと位置付けることができるためＭＤＡのPIMに該当する。
１．４ システム開発方法
ウオータフォール型のシステム開発はシステム化計画や基本設計を行い、外部仕様や業務要件等を確定しプログラミングおよび稼動確認の順実施される。プロトタイピング型のシステム開発はプログラムを作成しながら、その内容の確認と修正を繰返し、システムを完成させる手順で行われる。

In MDA, two types are defined: a model independent of the operating base of the system (PIM: Platform Independent Model) and a model dependent on the operating base (PSM: Platform Specific Model). The requirement description method of the business application function of the Lyee program is the same as that for defining data as shown in Table 1.3, and the data does not change depending on the operation base. For this reason, the requirement description method of the business application of the Lyee program can be positioned as a description model independent of the operation base, and therefore corresponds to the PIM of MDA.
1.4 System development method Waterfall type system development is performed in the order of programming and operation confirmation by conducting systemization planning and basic design, finalizing external specifications and business requirements. Prototyping-type system development is performed in a procedure that completes the system by repeatedly checking and correcting the contents while creating a program.

  The Lyee program development procedure stores input / output specifications (screen layout and file layout information) determined by external design and business application information for each data item determined by internal design in the repository. Enter this information, module structure information and input / output instructions (SQL statements, etc.) and use the Lyee program generation function (as of April 2005, the “LyeeALL” from Catena is available as the Lyee program generation function). Complete programming that matches the operating environment (the source code is 100% automatically generated). The unit test is repeated to complete the program.

  The system development procedure on the premise of Lyee programming can be applied to both waterfall type development and prototyping type development because the program can be created by determining the business requirements for each input / output specification and data item (FIG. 33). And 34).

Lyee program generation function
The Lyee program generation function (FIG. 35 and Table 13) automatically creates a Lyee program source program with the following elements. Program modification corresponding to additional changes in business requirements can also be performed using this generation function. For this reason, the source program is not directly modified.

なお同表中、雛型は上司と部下のLyeeプログラム、および領域情報より構成される。
２章 Lyeeプログラムの入出力処理
Lyeeプログラムは業務アプリケーション機能を担うが、WEBや利用者インターフェース、データベースインターフェースなどとの入出力処理を行う必要がある。この章では業務アプリケーション機能と入力処理機能、出力処理機能の３機能を独立させた構成としたLyeeプログラムを説明する。

In the table, the template is composed of the Lyee program of the boss and subordinates, and area information.
Chapter 2 Lyee Program Input / Output Processing
The Lyee program is responsible for business application functions, but requires input / output processing with the web, user interface, database interface, and so on. This chapter describes the Lyee program that consists of the business application function, input processing function, and output processing function.

In this example, there is a view that the program flow is rather extraordinary and unwieldy. However, this is not an example of creating a program specific to the “Purchase Amount Inquiry” process, which is an example, but it should be read with the intent of how to automatically generate a source program including input / output processes. .
2.1 I / O processing programming method
The input / output processing of the Lyee program is characterized by treating the “input processing instruction group” and the “output processing instruction group” as independent “lumps”. The following describes how to program the “lumps” of the input processing group and output processing group.

  The basic configuration of the Lyee program including input / output processing is shown in FIG.

  In the “initial processing instruction group”, file open, DB connect, and the like are performed, and in the “end processing instruction group”, file close, DB commit / roll back, and the like are performed.

Boss program for input processing (1) Flow of input processing Normally, programming is performed in consideration of the order of issuing input commands. On the other hand, the Lyee program aims to “minimize the range of consideration” without hesitating “relationships between variables”. For this reason, the Lyee program needs to realize a program structure that makes the processing order of each input processing unquestioned and makes the “business application processing” and “input processing” for setting calculations and values independent.
A) Complete separation of input processing and business application processing In order to make each processing independent, the “lumps” of “input processing command group” and “business application command group” are completely separated. The following is the flow (as shown in FIG. 37). Here, business application processing means setting a value in the output area or calculating under certain conditions.
B) Input command issue order unquestioned Next, in order to realize that the input command issue order is not taken into account, the completion status of input processing is recorded in the same way as the method in which the processing order of each instruction group of business applications is unquestioned. Adopt the method to do. If the item name for recording the completion state is “input execution flag”, the program flow of the supervisor program is as follows (as shown in FIG. 38).
C. Coordination method between input processing and business application processing The "processing block" of input processing and the "processing block" of business processing are separated, but the next issue is how to link these processing blocks.

Generally, a “certain input command” is executed, and business application processing can be performed using the input data. As business application processing can be performed, there is a possibility that further input commands can be performed. This is repeated until all necessary input processes are completed. The linkage between input processing and business processing is based on this concept. When this is converted into a program flow, FIG. 39 is obtained.
(2) Completion determination method of input processing group The completion determination method of the input processing instruction group records “completion” of the input processing as in the business application processing, and determines completion based on the recorded contents.

Specifically, the item name of the input completion record is “input execution flag”. If this flag is “On”, it is not completed (input processing can still be performed), and if the flag is “Off”, it is completed (more than this) It can be determined that the input process is invalid. An infinite loop avoidance measure in the input processing group is possible with the same logic as the work processing avoidance measure. (Refer to Reference Material 1 “Detailed Explanation of Infinite Loop Avoidance”)
(3) Control transition after the completion judgment of the input processing group Input processing group is incomplete If the processing of the input processing group is “incomplete”, it is necessary to execute the input processing yet. Transfer control to the instruction group. As a premise of the input process here, the input process executed once is not executed again. Refer to 3.4.2 “Repetition of own module processing” in Chapter 3 for the implementation method of processing that needs to repeat input processing, such as when repeatedly reading input files up to EOF in batch processing.
B) Input processing group is complete When the processing of the input processing group is “complete”, since the business process has already been completed, the control shifts to the output process.
(4) Specific Example FIG. 41 shows a summary of the program flow of the input process and the business process of the supervisor program of the Lyee program, taking the purchase price calculation screen (FIG. 40) as an example.

  In FIG. 41, when an input command is executed by a subordinate program for input processing, the “input execution flag” is set to On. Moreover, in order to emphasize the necessity of considering the input order, “product master input” is intentionally placed at the top.

Subordinate program for input processing The subordinate program for input processing is basically the same type as the subordinate program for business application processing, but the contents differ depending on the result of executing the input command. Specifically, when an input command such as Read or Select ends normally, necessary input items are obtained, so that “flag” type is set to “On” for recording input completion information. The subordinate program flow of the input process is shown in FIG.

In addition, in the same figure, “should an input command be executed” specifically means
1 If Product master input processing execution flag = Off
2 Product name set completion flag of the And search key = On.

  In addition, with regard to “product unit price input completion flag On”, in this example, the “input completion flag” set is one item. However, when multiple items are obtained by an input command, the “completion flag” of each item is set. Must be set to On.

  The points to be noted are the contents of the “input command execution” determination of the first command in the program flow. It is necessary to consider items corresponding to the three points in Table 14 for the determination contents.

２．１．３ 出力処理の上司プログラム
出力処理は、入力処理と業務アプリケーション処理が全て完了した後で実行する。出力処理の上司プログラムのプログラム構成（図４３）はLyeeプグラム全体の同型性を保持するため、「上司/部下」のプログラム構成とするが、出力「完了」判定や繰返し処理は行わない。

2.1.3 Boss program for output processing Output processing is executed after all input processing and business application processing are completed. The program structure of the boss program of the output process (FIG. 43) has the “superior / subordinate” program structure in order to maintain the homogeneity of the entire Lyee program, but does not perform the output “completion” determination or repetitive processing.

In summary, the program flow of the input process, business application process, and output process of the supervisor program is shown in FIG.
2.1.4 Output Processing Subordinate Program The output processing subordinate program describes output commands such as Write, Insert, Update, and Delete, and determines whether or not the output command should be executed as a preceding stage. The subordinate program flow of the output process is shown in FIG.

Note that the “completion” determination is not required in the boss program of the output process, and therefore the “completion information (flag)” is not set as a basic form. In addition, with regard to “whether to execute an output command”, a specific output execution determination is as follows:
(1) If unit price set completion flag = On
(2) And Product code key value set completion flag = On.

In general,
(1) If Set flag for each output item = On
(2) And update / delete key item set completion flag = ON
(3) And Output business conditions are met 2.2 Specific example: Purchase amount inquiry program In the specific example, the flow of the Lyee program including input / output processing is confirmed.
2.2.1 Process Outline Enter the product name and purchase quantity, and display the purchase price with discount rate and consumption tax.
2.2.2 Screen The screen shown in FIG.
2.2.3 Database The database to be searched is the product master, and the belonging items are simply shown in Table 15.

２．２．４ 業務要件
業務要件は表１６とする。

2.2.4 Business requirements Table 16 shows business requirements.

  The discount rate depends on the purchase quantity and purchase price.

  If there is no product name in the product master, a message is output.

購入金額照会処理のプログラムフロー
上司プログラムのプログラムフローは図４７となる。いままで説明しているようにプログラム構造は入力処理と業務処理が独立の“塊”となり、「入れ子」構造となっている。
初期処理の内容
一般的プログラムの初期処理と同様にトランザクションの開始、ＤＢへのコネクト、ファイルOPENを行う。また、Lyeeプログラムの固有処理としては制御情報の初期化を行う。制御情報の項目名と初期化内容は表１７である。

Program Flow for Purchase Amount Inquiry Process The program flow of the supervisor program is shown in FIG. As described so far, the program structure is a “nested” structure in which input processing and business processing are independent “lumps”.
Contents of initial processing Starts a transaction, connects to a DB, and opens a file in the same way as the initial processing of a general program. Control information is initialized as specific processing of the Lyee program. Table 17 shows the item names and initialization contents of the control information.

上司プログラム
図４７に示す。なお、「初期処理」は領域初期化やトランザクション開始、Lyeeプログラム特有のフラグ類の初期化を行う。また、業務処理については、入力される「購入商品名」と「購入数量」の内容は出力しないものとした。出力する必要がある場合は該当の部下プログラムを作成し、上司プログラムよりCallする必要がある。
（３）入力処理の部下プログラム
商品マスター入力secや画面入力secのプログラムフローは以下（図４８〜４９）である。
業務アプリケーション処理の部下プログラム
各業務アプリケーション処理の部下プログラムのフローは第１部２章の部下プログラムフロー図２．１８〜図２．２１と同型である。

Boss program Shown in FIG. “Initial processing” performs area initialization, transaction start, and initialization of flags specific to the Lyee program. Regarding business processing, the contents of “purchased product name” and “purchased quantity” to be input are not output. If it is necessary to output, the corresponding subordinate program must be created and called from the supervisor program.
(3) Subordinate program of input processing The program flow of the product master input sec and the screen input sec is as follows (FIGS. 48 to 49).
Business Application Processing Subordinate Programs The flow of each business application processing subordinate program is the same type as the subordinate program flow diagrams 2.18 to 2.21 in Part 1, Chapter 2.

Since the 20% discount rate set condition is “Purchase quantity” of 20 pieces or “Purchase price is 10,000 yen” or more, the first judgment of the flow is the addition of FIG. 50 and “Or” judgment. Become.
(4) Subordinate program for output processing
The program flow of the screen output section is as follows (FIG. 51).
(5) End processing As with general program end processing, processing such as transaction commit / rollback and file close is performed as necessary.
2.3 Summary The above is the explanation of the Lyee program flow including input / output processing. The main points can be summarized in the following three points.
(1) The Lyee program is a lump that separates input processing, business processing, and output processing. The input process has a double loop structure in which business processes are “nested”.
(2) After the completion determination of the input processing group, if the following is incomplete, control is transferred to the input processing group again.
When the input process group is completed, control is transferred to the output process.
(3) Completion determination is not performed in the output process, but a supervisor / subordinate program configuration is used to maintain the homogeneity of the Lyee program.
Chapter 3 Multiple module configuration of Lyee program This chapter explains Lyee programming when there are multiple internal modules in the program. Now you can create a Lyee program that can be used in an actual system.

Needless to say, when creating an operable program or program generation function, it is necessary to create a source program in consideration of language grammar and characteristics such as Java and Cobol, and operating environment interface rules.
3.1 Making the Lyee Program into Multiple Modules The concept of “Lyee Program Configuration for Multiple Modules” was explained in FIG. 1.14 to FIG. How this is realized as a program will be described in turn.

In general, a module is a unit for creating a program when developing a program, such as a screen, a form, or an event. Usually, this determined unit is further functionally divided to create a “lumps”. There are various ways to call this “block”, such as modules, sections, subprograms, functions, and objects. Hereinafter, this “block” is simply referred to as a module. It is often called an “internal module” because it is a block that further divides the program. (It goes without saying that subroutines and objects can also be created with the Lyee program.)
The module is created as a functional “bulk”, but the explanation here is based on the structural idea of the Lyee program. The purpose is to automatically determine the “module configuration”. (Lyee program modules can also be created taking into account the ease of maintenance and the traditional way of modularizing companies. This is both practical and practical.)
3.1.2 Function of Lyee program module
The module functions of the Lyee program are (1) Initial processing, (2) Input processing, (3) Business application processing, (4) Output processing, and (5) End processing up to the previous chapter. (6) “Module control” Consists of 6 functions plus functions.

  The area configuration is divided into a module common area and a unique area of each module by structuring a plurality of modules (FIG. 52 and Table 18).

  The module of the Lyee program realizes a plurality of modules in the hierarchical structure of FIG. The control of calling and returning (Call / Return) such as “parent module” to “child module” and “child module” to “grandchild module” is handled by the module control instruction group.

３．１．３ モジュール分割基準（プログラムをどのような単位で作成するかは、与えられた稼動環境等により異なる。ここではプログラムの単位は「画面」毎とか「イベント」毎とかに決った後のこととして説明する。）
Lyeeプログラム内のモジュール分割の基準は次とする。(一)は一般的であるが(二)の入出力件数区分はLyeeプログラムの構造上およびプログラムの自動生成を容易に実施するためのモジュール分割基準である。この基準に従いプログラムのモジュール分割を行う。
(一)処理（イベント）・機能区分
(二)入出力件数区分
入出力件数単位とは、入力または出力が「１件」か「複数件」の処理かで区分する。
３．２ 具体例：注文画面処理プログラム
「注文画面」処理の具体例でLyeeプログラムのモジュール分割とプログラムフローを概観する。
３．２．１ 処理概要
画面遷移や各ボタン押下時の処理は以下（表１９に示すとおり）である。

3.1.3 Module division criteria (The unit in which a program is created varies depending on the given operating environment, etc. Here, the unit of the program is determined for each “screen” or “event”. I will explain it as.)
The criteria for dividing modules in the Lyee program are as follows. Although (1) is general, the input / output number category in (2) is a module division standard for the easy construction of the Lyee program and automatic program generation. The program is divided into modules according to this standard.
(1) Processing (event) / function classification
(2) Number of input / output cases The number of input / output cases is classified according to whether the input or output is “one” or “multiple”.
3.2 Specific Example: Order Screen Processing Program A specific example of the “order screen” process outlines the module division and program flow of the Lyee program.
3.2.1 Process Overview The process when the screen transitions and each button is pressed is as follows (as shown in Table 19).

３．２．２ 画面
図５４の画面とする。
３．２．３ ファイル
検索や更新するファイルは表２０とする。

3.2.2 Screen The screen shown in FIG.
3.2.3 Files Table 20 shows the files to be searched and updated.

  It is assumed that a customer code is obtained at the time of login and the information is stored in the “takeover file”. As for file organization, “succession file” is a sequential organization (text) file, and others are databases.

３．２．４ 業務要件
業務アプリケーションの処理要件は表２１とする。

3.2.4 Business requirements Table 21 shows the business application processing requirements.

３．２．５ モジュール構成
（１）プログラムの単位
プログラムをどのような単位で作成するかをまず決めておく必要がある。ここでは画面単位にプログラムを作成するとする。（イベント単位でプログラムを作成する場合は各イベント内でのモジュール構成の検討となる。また複数画面をまとめて１つのプログラムとする場合は複数画面をまとめたモジュール構成の検討となる。）
（２）注文処理のモジュール分割
ア 注文画面の処理の単位（以降イベントと呼ぶ）は以下となる。
(一)初期起動
(二)金額計算ボタン押下
(三)発注ボタン押下
(四)クリアボタン押下
(五)戻るボタン押下
イ (一)〜(四)に共通している機能は画面の入出力処理であるため、まず画面の入出力処理を親モジュールとする。

3.2.5 Module configuration (1) Program units It is necessary to decide in advance what units the program will be created in. Here, a program is created for each screen. (If a program is created for each event, the module configuration within each event is considered. If a plurality of screens are combined into one program, the module configuration including a plurality of screens is considered.)
(2) Module division of order processing a) The unit of order screen processing (hereinafter referred to as event) is as follows.
(1) Initial startup
(2) Press the amount calculation button
(3) Press the order button
(4) Press clear button
(5) Pressing the back button (a) Since the function common to (1) to (4) is the screen input / output processing, the screen input / output processing is first set as the parent module.

    C) Since the processing of (4) and (5) can be processed by the parent module, no child module is created.

    D The process of displaying the customer name in the initial activation process reads one customer master, so “one process”, and the product name display process of the purchased product combo box is “multiple processing” of the product master. The child module of the initial startup process consists of two modules according to the “one / multiple cases” classification of the input / output process of the module division standard.

O The amount calculation process only needs to read one item master, so the child module is composed of one module.

The ordering process has one module configuration because each file has one “Select” process and one “Insert” process.
(3) Module Configuration From the above examination, the module configuration is shown in Table 22, and this is shown in FIG.

３．２．６ 各モジュールのプログラムフロー
上司プログラムのフロー
各モジュールの上司命令群は参考資料２プログラムフロー参照（表２３）。

3.2.6 Program flow of each module Supervisor program flow Refer to Reference Material 2 Program Flow for the supervisor instruction group of each module (Table 23).

（２）部下プログラムのフロー
「モジュール制御処理」のプログラムフローは参考資料２プログラムフロー参照（表２４）。

(2) Subordinate program flow For the program flow of “module control processing”, see Reference 2 Program Flow (Table 24).

  Repeat: To read multiple product masters and output multiple items to the combo box. For details, refer to 3.3.2 “Repeat processing of own module”.

３．３ モジュール制御を含んだ上司プログラム
一般的な内容でモジュール制御を含めたプログラムフローを説明する。
３．３．１ モジュール制御機能
モジュール制御機能は一般的なプログラムと同様まず以下が必要である。

3.3 Boss program including module control The program flow including module control will be explained with general contents.
3.3.1 Module control function As with a general program, the module control function requires the following.

(1) "Transition to child module"
(2) “Return to parent module (caller)”
Considering the configuration of one program and one module, the following is added as a program control function.

(3) "Transition to other programs"
(4) End of program
Following these, we add a fifth feature specific to the Lyee program. The content is a module control function that enables "multiple processing" to repeat "input processing and output processing", such as the output processing file of the purchased product combo box on the example order screen and batch processing that reads all records. is there.
“Multiple processing” repeats a series of processing of input processing, business application processing, and output processing in the module, and repeats until a processing end condition (for example, completion of reading of all records) is met.

(5) "Repeat processing of own module"
The above is the module control function of the Lyee program.

３．３．２ 自モジュール処理の繰返
「自モジュール処理の繰返」はLyeeプログラム特有の機能であり、図５６のように画面に「複数行」表示する場合や入力ファイルを１件読み、処理結果を１件出力する、２件目も同様に処理し、これを入力ファイルの全レコードについて行うような場合に適用する。
３．３．３ 「自モジュール繰返」機能を加えた上司プログラム
「自モジュ−ル処理の繰返」機能を追加したLyeeプログラムの上司プログラムは図５７のコーデング例となる。プログラムフロー図は参考資料２の図２．１１参照。

3.3.2 Repeating own module processing “Repeating own module processing” is a function unique to the Lyee program. When “multiple lines” are displayed on the screen as shown in FIG. This is applied to the case where the second processing for outputting one processing result is processed in the same manner, and this processing is performed for all the records of the input file.
3.3.3 Boss program with “Repeat own module” function The supervisor program of the Lyee program to which the “Repeat own module process” function is added is the coding example of FIG. See Figure 2.11 of Reference Material 2 for the program flow diagram.

The “initial processing” in the module is divided into the following two categories (Table 26).
(1) Initial processing 1: Processing to be performed only once at module startup
(2) Initial process 2: Process to be executed for each repetition process of “Repetition of own module process”

３．３．４ 各モジュール制御機能の適用優先度
５種類のモジュール制御機能の適用順序はそれぞれの機能を考慮し、優先度に従ったプログラミングをする必要がある。ここはプログラムの順序性を考慮しソースプログラムを作成する。
（１）「他プログラムへ遷移」や「プログラム終了」
この条件が発生したら、すみやかに「他プログラムへ遷移」や「プログラム終了」処理を行い、当該プログラムは処理完了として良いので、他のモジュール制御機能に比べ適用順位は１位である。

3.3.4 Application priority of each module control function The application order of the five types of module control functions needs to be programmed according to the priority in consideration of each function. Here, a source program is created in consideration of the order of the program.
(1) "Transition to other program" or "End program"
When this condition occurs, “transition to another program” or “program end” processing is immediately performed, and the program may be completed, so that the application order is first in comparison with other module control functions.

In actual coding, it is necessary to reshape, but the point at which the process is resumed is from the business process.
(2) “Return to parent module”
Since this condition needs to be processed at the stage where all the processing of the module itself is completed (completion is judged based on whether the output process is completed or the end condition of the repeated process is met), the application order is the lowest. Become.
(3) “Transition to child module” and “Repetition of own module processing”
The condition of “repeating own module processing” requires that “repeating processing” be performed after all child module processing is completed. For this reason, the “transition to child module” process has a higher application order than the “repeating own module process” process.

  In summary, the application order and application conditions in the module control function are shown in Table 27.

３．３．５ モジュール制御処理の内容
モジュール制御命令群の処理開始は、一連の「入力処理と業務アプリケーション処理」が完了し、これ以上入力処理が行われない時点である。モジュール制御処理機能は表２５の５種類である。

3.3.5 Contents of Module Control Processing The module control instruction group starts processing when a series of “input processing and business application processing” is completed and no further input processing is performed. There are five types of module control processing functions shown in Table 25.

The contents of the processing are functional, but it is necessary to pay attention to what should be done after completion of the processing.
For example, when there are a plurality of child modules, “after executing child module 1, perform parent module business processing and input processing” and then “execute child module 2 and then perform parent module business processing and input processing. It is necessary to set the processing contents to “execute”. This is because there is a possibility that some processing can be performed as a parent module after the child module is executed (Table 28). For the program flow, see the coding example in FIG.

モジュール制御機能を含めた上司プログラムのコーデング例は図５８となる。プログラムフロー図は参考資料２の図２．１２参照。

FIG. 58 shows a coding example of the supervisor program including the module control function. See Figure 2.12 of Reference Material 2 for the program flow diagram.

  However, in FIG. 58, “2. Call initial process 1” is “initial process 2” for initializing the area every time the module process is repeated, and the contents for initializing the area only when the module is activated. Performed in “Initial processing 1”.

  The flow of the module control processing subordinate program is the same as the flow so far, but there are two types of contents (Table 29).

子モジュールへ遷移の部下プログラム
子モジュールへ遷移する部下プログラムは子モジュール遷移条件に合致したら、実際に「子モジュールへ遷移」する。また子モジュールから戻った場合「モジュール制御実施フラグをOn」とするなど各種制御情報の記録を行う（図５９）。

Subordinate programs that transition to child modules Subordinate programs that transition to child modules actually "transition to child modules" if they match the child module transition conditions. Also, when returning from the child module, various control information is recorded (eg, “module control execution flag is set to On”) (FIG. 59).

  However, in the figure, with regard to “whether to transition to the child module X”, the module control performance determination is as follows.

If (1) Module control execution flag = Off
And (2) The relevant module control X execution flag = Off
And (3) Business conditions for module control (examples of business conditions: pressing “Back button”, etc.)
3.4.2 Subordinate programs other than child module transition Module control subordinate programs other than child module transition only set information, and the supervisor program realizes module control functions such as “Repeat own module” ( FIG. 60).

  However, in the same figure, as to “module control information should be set”, the module control performance determination is as follows.

If (1) Is the module control execution flag off?
And (2) Is the relevant module control Y execution flag off?
And (3) Module control business conditions (example of business conditions "Return button" pressed, etc.)
In addition, when the module control is "Transition to other program" and the condition is met for the "transition destination other program name set", the "Own module repeat flag = On" matches the repeat condition when the module control is "Own module repeat" Is the case.
3.4.3 Control information (data area)
There are five types of control information (data area) for module control, such as a module control execution flag that manages information on whether or not module control has been completed, a self-module repeat flag, and a transition destination module name when transitioning to another program Is prepared (Table 30).

但し、同表中、「各モジュール制御実施フラグ」について「Ｎ」とは、Ｎはモジュール制御の部下プログラムの数となる。
４章 システム開発上の効果
Lyeeプログラムのプログラミング方法の特徴や説明を行って来たが、ここでは「は じめに」で述べたLyeeプログラムのシステム開発上の効果をまとめる。なおLyeeプログラムでシステム開発事例を参考資料３としてまとめてあるので参照されたい。
スピーデイなシステム開発
４．１．１ ソースプログラムの自動生成
前章までで説明して来たように、Lyeeプログラムは定型的なプログラム構造をしている。このため、出力項目についての計算式や条件、値のセット等の業務アプリケーション処理情報が得られれば、特定言語のプログラムソースを作成する「ソースジェネレータ」を作ることは容易に可能となる。特に「フレーム」だけでなく業務アプリケーション部分のソースプログラムも１００％できることを強調したい。

However, in the table, “N” for “each module control execution flag” means N is the number of subordinate programs for module control.
Chapter 4 Effects on System Development
We have explained the features and explanations of the programming method of the Lyee program. Here, we summarize the effects of the Lyee program on system development described in “Introduction”. Please refer to the reference material 3 for system development examples in the Lyee program.
Speedy system development 4.1.1 Automatic generation of source program As explained in the previous chapter, the Lyee program has a typical program structure. Therefore, if business application processing information such as calculation formulas, conditions, and value sets for output items is obtained, it is possible to easily create a “source generator” that creates a program source in a specific language. In particular, I want to emphasize that not only “frames” but also source programs for business application parts can be made 100%.

The source generator has a template source prepared in advance for the interface with each product (OLTP, DBMS, etc.) in the operating environment, and it can be imported into the source generator. For this reason, it is easy to conceal the operating environment and cope with version upgrades. (As of April 2005, Catena Co., Ltd. sells a product called “LyeeALL” that supports multiple languages and operating environments.)
4.1.2 Independence of business requirements from operating infrastructure
The business requirements of the Lyee program are to determine the information of “output items” and to determine the calculation formula, conditions, and value setting method for each “output item”. This is a matter that can be determined by determining the screen, form, and file contents, and can be separated and independent from the operating base (Table 31).

表３１は２部２章で使用した要件定義表であるが、このような表を作成することで要件定義が完了する。

Table 31 is the requirement definition table used in Part 2 Chapter 2. The requirement definition is completed by creating such a table.

“Data-oriented program” of “automatic generation of data-oriented program” as a subtitle is named from the relationship of “table data” = “data-oriented” = “program”, and business application requirements are equivalent to data It means that it can be handled.
4.1.3 Order of variable relations not considered Source programs such as formulas, conditions, and value sets for “output items” need to consider the processing order. In the example of FIG. 61, since each process needs to be arranged in the processing order, it must be set to Case 1.

  The Lyee program can be processed in either case 1 or case 2 in FIG. 61 because “someday” “A and B are satisfied” and “C = A + B” is calculated as a result. FIG. 61 is a simple example. However, when there are a large number of items or the relationship between a plurality of “nested” functions and variables, even if each function expression can be clarified, “someday” will be “each variable is satisfied (value Is set) ”Finally, the calculation of the function is completed. (Even in the following functions, the value of Y is finally obtained by obtaining the sequential value regardless of the order of arrangement: Y = F (g, h) g = G (g1, g2) h = H (h1) g1 = x1, g2 = x2, h1 = x3) “No need for pro-granulation in the conventional sense” described in “Introduction” indicates this.

The fact that it is not necessary to consider the processing order of the relationship between the variables has a great effect on the productivity and quality of the program in creating the program.
Improvement of quality and reduction of test process In the system development test process, the contents of the system are checked in sequence by a unit test including a single program test, file, screen transition, etc., and a comprehensive test, and the error of the program is corrected. Since the program structure of the Lyee program is fixed, program processing errors are relatively small, and the error location can be easily found. For this reason, the test period and man-hour of the unit test can be shortened.

In addition, since there are many parts related to the screen and file design in the integration test and the comprehensive test, a good quality of the program alone contributes to efficiency.
4.2 Improving the efficiency of maintenance work The speedy development of the program described in 4.1 is effective even when program maintenance is changed or added, thereby facilitating and improving the efficiency of the work.

  Generally, the program is standardized and created, but in the maintenance work, it takes a lot of time to “confirm change location”, “examination of influence range”, “confirmation of level down prevention test” and the like. In addition to this, the work efficiency is further deteriorated by changing the person in charge and repeating the program correction.

  The Lyee program is “table-data-like” and is “not considering the order of variable relationships”, so it can be corrected without having to consider only whether or not the “variable relationship” of requirements changes (Table 32). .

なお、同表において、「給与明細票出力」「賞与明細表出力」に関して、社員に月々の給与明細を知らせる帳票である。プログラムの修正方法は上記以外にも考えられる。例えば新規に部長以上の処理モジュールを作成し、現在の処理モジュールは課長以下とする方式も有力である。
４．３ 業務アプリケーション定義書類の削減
プログラムの業務アプリケーション定義書は、プログラム制御に係わる記述が不要となるため記述量が少なくて済み、定義書の量的な削減が図られる。

In the table, regarding “salary details output” and “bonus details output”, it is a form for notifying employees of monthly salary details. There are other ways to modify the program. For example, a method in which a processing module of a department manager or higher is newly created and the current processing module is set to a section manager or lower is also effective.
4.3 Reduction of business application definition documents Since the business application definition document of a program does not require a description related to program control, the amount of description can be reduced and the definition document can be reduced in quantity.

Each company makes great efforts to synchronize the contents of the source program and business application definition document, but the application definition document of the Lyee program is a tabular data format in which "item name and requirement" are paired. As a result, the program and the definition document can be easily synchronized.
4.4 Coexistence with Various Frames Part 2 Chapter 1 explained the functions and positioning of the Lyee program within the MDA framework. The Lyee program is compatible with both SIM and PSM defined by MDA. In addition, since the Lyee program only defines the program structure, it can be easily adapted to frames defined by frameworks other than MDA.
4.5 Issues Although the effects described above can be expected, the following issues also exist. By using Lyee programming more widely, it seems that better solutions to these issues can be made.
4.5.1 Array Processing In general, data processing is often performed as a two-dimensional or three-dimensional array. For example, when the sales amount for each monthly branch is obtained, the coding shown in Table 33 is often performed.

Lyeeプログラミングでは現在は表３４の対応方法がある。しかし「完了報告」の単位を１配列（例えば表３３の月別支店別売上金額）１個とするか否か等プログラム構造上の課題も残っている。

In Lyee programming, there is currently a correspondence method shown in Table 34. However, there still remains a problem in the program structure, such as whether or not the unit of “completion report” is one array (for example, the sales amount by branch of each month in Table 33).

４．５．２ 領域の初期化
プログラムを作成する上で、使用しているデータ領域をいつ初期化するかは単純ではない。またこの領域初期化条件をあまり複雑化してしまうと、分かり難いプログラムとなってしまう。Lyeeプログラムでは現在は表３５のNo１の内容で領域の初期化を行っているが、必ずしも作業者に理解され易い内容とはなっていない。特に合計を求める場合や突合（マージ）処理での新／旧のキー値比較などを表３５のNo１で実施した場合「Lyeeプログラム特有」の処理となる感じは拭えない。これらを隠蔽した方法などが今後の課題である。

4.5.2 Initialization of area When creating a program, it is not easy to initialize the data area in use. If the area initialization conditions are too complicated, the program becomes difficult to understand. The Lyee program currently initializes the area with the contents of No. 1 in Table 35, but the contents are not necessarily easily understood by the operator. In particular, when the total is obtained or when the new / old key value comparison in the matching process is performed with No. 1 in Table 35, the feeling of “Lyee program unique” processing cannot be wiped out. How to conceal these is a future issue.

４．５．３ 使用コンピュータ資源や処理完了時間
昨今はCPUの処理能力やメモリ容量、ＯＳのアドレス空間など急激に拡張増大されている。このため、Lyeeプログラムの冗長なソースコードでも特段の問題は無い場合が多いが、一定の考慮をしておく必要がある。

4.5.3 Computer resources used and processing completion time In recent years, the CPU processing capacity, memory capacity, OS address space, etc. have been rapidly expanded. For this reason, there are many cases where there is no particular problem with the redundant source code of the Lyee program, but it is necessary to take certain considerations into consideration.

The processing completion time such as response time cannot be generally described as the difference between the Lyee program and the general program, but the CPU time is considered to be relatively long from the structure in which the value is established by repeating the Lyee program. However, since the CPU time is usually a unit of 1 / 1,000 second or less, the problem due to the long CPU time does not occur in a system that has already been created and operated in the Lyee program. However, since the process completion time varies greatly depending on the file design and SQL creation method, it is necessary to construct a system by carefully considering these as well as developing with a general program.

Reference 1 Detailed description of infinite loop prevention specifications
Program 1.2.2 “Supervisor Program Structure”, 2.1.2 “Supervisor Program Completion Judgment Method” and Part 2.2.1.1 “Supervisor Program for Input Processing” Although it is explained that an infinite loop does not occur in the specification, here is a summary of the mechanism.

1 Business Process Supervisor Program The flow of the purchase price calculation supervisor program in Part 1 Chapter 2 is as follows (as shown in FIG. 62). (Hereafter, we will explain in this specific example. The mechanism of infinite loop avoidance does not change even if the number of items increases.)
(1) Pay attention to the flow of the loop portion of FIG. 63 in order to examine the infinite loop, and number each instruction with (1) and (2). In order to end the loop, it is sufficient that the “task execution flag” is “Off” in the determination of (1). In other words, the “work execution flag” should remain “Off” among the three subordinate programs.
(2) FIG. 64 shows a general form of a subordinate program. If “No” is determined in (1) of the subordinate program, the “business execution flag” is not “On”. For this reason, it is a problem whether subordinate programs are always judged as “No” in (1). An infinite loop can be avoided if it always happens.
(3) When the three subordinate programs corresponding to FIG. 63 are repeated N times as shown in FIG. 65, the following state is obtained.

    Case 1: For a certain subordinate, the “instruction required for the IDn” in FIG. 64 is executed and the “subordinate n set completion flag” is On.

    In the (N + 1) th time, since the condition 4 is not met, the first determination is “No”.

    Case 2: A certain subordinate does not execute the “instruction necessary for the IDn” in FIG. 64 and the “subordinate n set completion flag” remains Off. Even in the N + 1th time, the determination of 1 is not “Yes” due to any of the conditions 2, 3, and 5, so 6 is not performed and the flag of 8 remains Off.

Therefore, in the (N + 1) th time, since 6 of FIG. 64 is not newly implemented in all subordinate programs, 7 is not also implemented. As a result, the “business execution flag” remains Off, and an infinite loop is avoided.
(4) From another point of view, if 6 of FIG. 64 is executed once, the “subordinate n set completion flag” is turned on in 8 and the control of the sub n program is subsequently transferred. It is always judged as “No”, and “Business implementation flag” remains Off.

  In some subordinate programs, “some data” does not correspond to 2, 3 and 5 in FIG. 64, no matter how many times the loop processing in FIG. 63 is repeated, and the determination of 1 is always No. In this case, the “business execution flag” remains Off.

Therefore, in the loop of FIG. 63, the “business execution flag” will be turned off at some point and an infinite loop will not occur. The maximum number of loops is equal to the number of subordinate programs.
2 Supervisor Program Including Input Processing In Part 2 Chapter 2 2.1.1, the supervisor program flow including input processing is as follows (as shown in FIG. 66).
As described in “1 Business Process Supervisor Program”, the business process part in the lower half of FIG. 66 does not endlessly loop. Therefore, there is no problem even if the boss program flow including input processing is simplified to FIG.

      In order to end the loop of FIG. 67, it is only necessary that the “input execution flag” is OFF in the determination of 1.

  Figure 1.7 shows the general form of a subordinate program for input processing. If “No” is determined in the determination of 1, the “input execution flag” is not “On”. For this reason, an infinite loop can be avoided if it is determined that all subordinate input programs are determined to be “No”.

Assuming two input processing subordinate programs corresponding to FIG. 67 and repeating the loop N times in FIG. 69, the following state is obtained.
Case 1: For a certain subordinate input program, 4 in FIG. 68 is executed, and the 7 or 10 flag is On. In the N + 1th process, 1 determination is No due to condition 3.
Case 2: For a certain subordinate input program, 4 in FIG. 68 is not performed and neither 7 nor 10 is performed. For this reason, the “input processing n execution flag” remains Off. 4 is not performed even in the N + 1th processing. This is because the determination of 1 does not become Yes due to any of conditions 2 and 4.

Therefore, in the (N + 1) th process, all subordinate input programs are No in the determination of 1 in FIG. That is, the “input execution flag” remains Off, and an infinite loop is avoided.
3 Repeating of own module When the repetition processing of its own module is added, the program flow of FIG. 70 is obtained, and an infinite loop may also occur here.

  Conditions for stopping the repetition of the own module comply with business requirements as shown in Table 36. Since this stop condition exists in the repetition process of the own module, the repetition is always stopped except for the condition setting error.

４ 複数モジュール構成について
複数モジュール構成となった場合、無限ループは起こらないか？につき考察する。

4. About multiple module configuration Is there an infinite loop when multiple module configuration is used? I will consider.

First, the lowest module does not cause an infinite loop as described above. As a result, an infinite loop does not occur in the higher-level module. The same logic can be applied to the final top-level module. Eventually, an infinite loop does not occur even if it has multiple modules.

Reference Material 2 Supplement to Program Flow The subordinate program flow of the supervisor program flow and module control processing of 3.2 “Specific Example: Product Ordering Program” in Part 2 is as follows (as shown in FIG. 71).
1. Manager program flow of parent module of product order screen As shown in FIG. In this figure, subordinates 12 to 14 are created because three types of messages are required from the business requirements of 3.2.4 of Part 2 Chapter 3.
2 The supervisor program flow of the child module 1 of the product order screen This process reads the takeover file and the customer master (FIG. 72).
3. The supervisor program flow of the child module 2 of the product order screen The product master is read and a plurality of product name combo box contents are output (FIG. 73).
4 Program flow of the supervisor of the child module 3 of the product order screen This is a process of reading the product master by the selected product name (FIG. 74).
5 Supervisor program flow of child module 4 of product order screen This is a process of reading the product master and the numbering table, registering the order receiving master and updating the numbering table (FIG. 75).
6 Subordinate program flow of “return to parent module” The subordinate program flow of “return to parent module” module control of child module 1 of the product ordering screen is as follows (as shown in FIG. 76).
7 Subordinate Program Flow of “Transition to Child Module 1” The module control subordinate program flow of “Transition to Child Module 1” of the parent module of the product ordering screen is as follows (as shown in FIG. 77).
8 Subordinate Program Flow of “Transition to Child Module 4” The subordinate program flow of module control of “Transition to Child Module 4” of the parent module of the product ordering screen is as follows (as shown in FIG. 78).
9. Subordinate program flow of “transition to menu program” The subordinate program flow of module control of “transition to menu program” of the parent module of the product order screen is as follows (as shown in FIG. 79).
10 Subordinate Program Flow of “Self Module Repeat” The subordinate program flow of “Self Module Repeat” module control of child module 2 of the product order screen is as follows (as shown in FIG. 80).
11 Boss program flow with "Repeat module processing" added (Fig. 81)
12 Boss program flow including module control processing (Figure 82)

Reference Material 3 Lyee Program Results (Figure 83) As of April 2005

Reference Material 4 Source Generation Tool Input Example <Purchase Price Calculation>
Screen (Fig. 84)
(2) Requirements (Figure 85)
(3) Input contents to the source generation tool A. Related to supervisor program (A) Input / output information (Fig. 86)
Input / output information and item / attribute purchase price calculation screen: KEISAN_gm
(Fig. 87)
Product Master: GoodsMF
(Fig. 88)
(I) Subordinate programs (Figure 89)
<Purchase price inquiry>
Screen (Fig. 90)
Requirements (Figure 91)
Example of input to the source generation tool a. Boss program related input / output information (Figure 92)
Input / output information and item / attribute purchase price inquiry screen: Syoukai_gm
(Fig. 93)
Product Master: GoodsMF (Fig. 94)
(I) Subordinate programs (Figure 95)
The present invention is not limited to the above-described embodiments and examples, and various modifications can be made within the scope of the technical idea of the present invention.

  For example, the present application is not limited to the application examples described above, and the present application can be applied to any system development that realizes various functions, and each object to which the present application is applied has an effect unique to the object. Play.

  Furthermore, the present invention allows various modifications, additions, substitutions, expansions, reductions, etc. within the scope of the same and equivalent technical idea. In addition, even if an apparatus, a method, software, and a system that are produced using the invention of the present application are listed as a secondary product and commercialized, the value of the invention of the present application is not reduced at all.

  According to the present invention, it is possible to automatically generate a source program, the independence of business requirements from the operating base is ensured, there is no need to consider the order of variable relations, and quality is improved and test processes are reduced. As a result, speedy system development becomes possible.

  Furthermore, the fact that programs can be developed quickly is effective even in program maintenance change / addition work, and facilitates and improves work efficiency.

  Furthermore, since the business application definition document of the program does not require a description related to program control, the amount of description is small, and the amount of definition document can be reduced.

Furthermore, the Lyee program is compatible with both SIM and PSM defined by MDA. Also, because the Lyee program only defines the program structure, it can easily handle frames defined by frameworks other than MDA.
Therefore, the present invention can be applied to software in any form of existence regardless of use, distribution over a network, or stand-alone, and a software production method.

It is a figure for demonstrating notionally the feature of the Lyee program of this invention. It is a figure which shows the example of the screen of the purchase amount calculation which concerns on one Embodiment of this invention. It is a flowchart of purchase amount calculation concerning one embodiment of the present invention. It is a flowchart of determination of the unit price concerning one embodiment of the present invention. It is a flowchart of determination of the discount rate which concerns on one Embodiment of this invention. It is a flowchart which shows the program flow of the subordinate program which concerns on one Embodiment of this invention. It is a flowchart which shows the role of the supervisor which concerns on one Embodiment of this invention with a program flow. It is a flowchart which shows the parallel processing which is the original idea of the Lyee program of this invention. It is a flowchart which shows the process until the completion of the operation | work of the purchase price calculation which concerns on one Embodiment of this invention. It is a flowchart which shows addition of the determination conditions of the subordinate program which concerns on one Embodiment of this invention. It is a flowchart which shows collectively the flow of the supervisor program and the flow of a subordinate program which purchase price calculation processing which concerns on one Embodiment of this invention collectively. It is a figure which shows notionally the supervisor / subordinate program made into multiple modules based on one Embodiment of this invention. It is a figure which shows the structure which makes the example of the three layers of the left side of FIG. 12 which concerns on one Embodiment of this invention into a Lyee module. It is a figure which shows the example of the order screen which added the "ordering" process to the "amount calculation" process which concerns on one Embodiment of this invention. It is a figure which shows the module structure of the order screen process which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program of the parent module which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program of the child module which concerns on one Embodiment of this invention. It is a flowchart which shows the program flow of the "child module call" which concerns on one Embodiment of this invention. It is a figure which shows the example of the purchase amount calculation screen which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate program of the output item n which concerns on one Embodiment of this invention. It is the figure which showed the area | region of the Lyee program which concerns on one Embodiment of this invention. It is a figure which shows the screen of the purchase amount calculation which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate program which concerns on one Embodiment of this invention. It is a figure which briefly summarizes the functional system prescribed | regulated by MDA. It is a figure which shows the whole system configuration presupposing the Lyee programming of this invention. It is a figure which shows the Lyee system development procedure example (waterfall type | mold) which concerns on one Embodiment of this invention. It is a figure which shows the system development image which concerns on one Embodiment of this invention. It is a figure which shows the Lyee program production | generation function which concerns on one Embodiment of this invention. It is a figure which shows the basic composition of the Lyee program which concerns on one Embodiment of this invention. It is a figure which shows notionally the complete separation of the input process and business application process which concern on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program of the input process which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program including the input process and business process which concern on one Embodiment of this invention. It is a figure which shows the example of the purchase amount calculation screen which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program including the input process which concerns on one Embodiment of this invention. It is a flowchart which shows the program flow of subordinate input 1 (product master) which concerns on one Embodiment of this invention. It is a flowchart which shows the supervisor program of the output process which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program including the input / output process which concerns on one Embodiment of this invention. It is a flowchart which shows the subordinate program flow of the goods master update process which concerns on one Embodiment of this invention. It is a figure which shows the example of the screen of the purchase amount inquiry program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program of the purchase amount inquiry which concerns on one Embodiment of this invention. It is a flowchart which shows the program flow of subordinate input 1 (product master) which concerns on one Embodiment of this invention. It is a flowchart which shows the program flow of subordinate input 2 (purchase amount screen input) which concerns on one Embodiment of this invention. It is a flowchart which shows the program flow of the discount rate 20% set sec which concerns on one Embodiment of this invention. It is a flowchart which shows the program flow of the screen output sec concerning one Embodiment of this invention. It is a figure which shows notionally the structure of the module which concerns on one Embodiment of this invention. It is a figure which shows the multiple module structure of the Lyee program which concerns on one Embodiment of this invention. It is a figure which shows the example of the screen of the order screen process program which concerns on one Embodiment of this invention. It is a module block diagram of the goods order processing program which concerns on one Embodiment of this invention. It is a figure which shows the "repetition of an own module process" about the example of "single output" and "multiple output" concerning one embodiment of the present invention. It is a figure which shows the boss program coding example which added "repeat of own module process" concerning one Embodiment of this invention. It is a figure which shows the boss program coding example which added all the "module control functions" concerning one Embodiment of this invention. It is a flowchart which shows the subordinate program flow of the child module transition which concerns on one Embodiment of this invention. It is a flowchart which shows the module control processing subordinate program flow other than the child module control which concerns on one Embodiment of this invention. It is a figure which shows notionally the order of the source code (instruction) which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the loop part which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate program n which concerns on one Embodiment of this invention. It is a figure which shows n times loop which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program including the input process which concerns on one Embodiment of this invention. It is a flowchart which shows the input processing loop partial flow which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the subordinate n program of the input process which concerns on one Embodiment of this invention. It is a flowchart which shows the flow of the input process loop part which concerns on one Embodiment of this invention. It is a flowchart which shows the Lyee program flow which added the "repetition of a self-module process" concerning one Embodiment of this invention. It is a flowchart which shows the supervisor program flow of the parent module of the goods order screen which concerns on one Embodiment of this invention. It is a flowchart which shows the supervisor program flow of the child module 1 of the goods order screen which concerns on one Embodiment of this invention. It is a flowchart which shows the supervisor program flow of the child module 2 of the goods order screen which concerns on one Embodiment of this invention. It is a flowchart which shows the supervisor program flow of the child module 3 of the goods order screen which concerns on one Embodiment of this invention. It is a flowchart which shows the supervisor program flow of the child module 4 of the goods order screen which concerns on one Embodiment of this invention. It is a flowchart which shows the subordinate program flow of the module control which returns to the parent which concerns on one Embodiment of this invention. It is a flowchart which shows the subordinate program flow of the module control which changes to the child module 1 which concerns on one Embodiment of this invention. It is a flowchart which shows the subordinate program flow of the module control which changes to the child module 5 which concerns on one Embodiment of this invention. It is a flowchart which shows the subordinate program flow of the module control of the transition to the menu program which concerns on one Embodiment of this invention. It is a flowchart which shows the subordinate program flow of the module control of the transition to the menu program which concerns on one Embodiment of this invention. It is a flowchart which shows the supervisor program flow which added the "repeat of own module process" concerning one Embodiment of this invention. It is a flowchart which shows the flow of the supervisor program including the module control process which concerns on one Embodiment of this invention. It is a figure which shows a Lyee program performance. It is the figure which showed the example of the screen of the purchase amount calculation which concerns on one Embodiment of this invention. It is a figure which shows the business requirement which concerns on one Embodiment of this invention. It is a figure which shows the example of the input-output information input into the source generation tool which concerns on one Embodiment of this invention. It is a figure which shows the example of the input-output information and item and attribute which are input into the source generation tool which concerns on one Embodiment of this invention. It is a figure which shows the example of the input-output information and item and attribute which are input into the source generation tool which concerns on one Embodiment of this invention. It is a figure which shows the example related to the subordinate program input into the source generation tool which concerns on one Embodiment of this invention. It is a figure which shows the example of the screen of the purchase amount inquiry which concerns on one Embodiment of this invention. It is a figure which shows the example of the requirement of the purchase amount inquiry which concerns on one Embodiment of this invention. It is a figure which shows the example of the input-output information input into the source generation tool which concerns on one Embodiment of this invention. It is a figure which shows the example of the input-output information and item and attribute which are input into the source generation tool which concerns on one Embodiment of this invention. It is a figure which shows the example of the input-output information and item and attribute which are input into the source generation tool which concerns on one Embodiment of this invention. It is a figure which shows the example related to the subordinate program input into the source generation tool which concerns on one Embodiment of this invention.

Explanation of symbols

sec section MDA modeling driven architecture

Claims (1)

A first step of defining a predetermined attribute as data in units of words belonging to each logical body based on a requirement definition;
A second step of adjusting the requirement deficiency,
A third step of obtaining a target code of the desired software by inputting the data adjusted in the second step as an essential element of the software into an automatic generation tool having a given program structure. In the method
In the above-mentioned Lyee program structure, input processing, business processing, and output processing are independent, and the input processing has a double loop structure in which the business processing is “nested”, and after completion of the input processing group is determined to be incomplete In this case, the control is transferred to the input processing group again, and when the input processing group is completed, the control is transferred to the output processing, and the completion of the output processing is not performed and the supervisor / subordinate program is configured. To generate software.

Images