WO2006115229A1 - システム・プログラム、処理装置、記録媒体、プログラム生成支援装置、データ構造並びにプログラム作成方法 - Google Patents

システム・プログラム、処理装置、記録媒体、プログラム生成支援装置、データ構造並びにプログラム作成方法 Download PDF

Info

Publication number
WO2006115229A1
WO2006115229A1 PCT/JP2006/308475 JP2006308475W WO2006115229A1 WO 2006115229 A1 WO2006115229 A1 WO 2006115229A1 JP 2006308475 W JP2006308475 W JP 2006308475W WO 2006115229 A1 WO2006115229 A1 WO 2006115229A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
unit
program
output
unit module
Prior art date
Application number
PCT/JP2006/308475
Other languages
English (en)
French (fr)
Inventor
Keiko Nakamura
Fumio Negoro
Original Assignee
Catena Corporation
Information System Development Institute
The Institute Of Computer Based Software Methodology And Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Catena Corporation, Information System Development Institute, The Institute Of Computer Based Software Methodology And Technology filed Critical Catena Corporation
Publication of WO2006115229A1 publication Critical patent/WO2006115229A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482—Procedural
    • G06F9/4484—Executing subprograms

Definitions

  • the present invention relates to a system program, a processing device, a recording medium, a program generation support device, a data structure, and a program creation method.
  • declarative programming in which programming is performed using declarations that are requirement definitions themselves, includes artificial intelligence, expert systems, logical reasoning, inference, and user intelligence gathering. Calculation system key It is used in the field of prescription.
  • declarative programming the relationship between data defined in the control procedure is declared, and programming is performed based on the declaration. The advantage is that the procedure such as the control procedure must be explicitly specified. Unlike procedural programming, there are requirements that can be implemented accurately.
  • declarative programming also has a problem that the efficiency of execution is not good due to the structure of execution control.
  • Another disadvantage is that it is difficult to use a language for declarative programming.
  • Languages for declarative programming include logical languages that use logical expressions (for example, PROLOG) and functional languages that describe target states as mathematical functions (for example, LISP).
  • Declarative languages have a procedural logical mechanism for executing declarations, because values are not generated just by declaring them. The logical mechanisms of these procedures have a number of conditions in order to be able to execute all declarations, require knowledge of mathematics and logic, and are difficult to master. For this reason, it is not popular as a programming language. This is why procedural programming using a procedural language that has a structure similar to that of human natural language is becoming more prevalent. (3) Object-oriented programming
  • Object-oriented programming is a programming technique in which data and procedures (called methods) that operate on it are combined as a unit called an object, and a program is written as a combination of objects. Since the program is composed of highly independent modules called objects, the scope of the impact of changes and modifications is limited, and there is an advantage that reuse can be reduced in units of objects.
  • Lyee A software development methodology called Lyee has been proposed as a means to solve the above-mentioned problems in software development, called Lyee (which ends with governmenta methodologY for softwarE providencE. Read “Lee”. Yes. Lyee is a new method that can automatically generate the code of a program with the required power.
  • Lyee declares (defines) software requirements for each variable data item (also referred to as a word in Lyee), and creates a fixed structure module for executing the declaration for each data item. Create a program by assigning its declaration.
  • the entire program by Lyee consists of a set of modules with a fixed structure that execute declarations in units of data items. Therefore, if a tool is created, it is possible to automatically generate a program (generate source code) by assigning the declaration of requirements for each data item to this fixed structure module.
  • LyeeALL is a program in Lyee that automatically assigns a requirement declaration to a given place in a boilerplate module code (called a “template”, which is a template) that executes data item declarations.
  • the fixed structure module is arranged according to the design method, and the source code of the entire program is automatically generated.
  • Software development by Lyee is declarative programming. The following outlines the Lyee development methodology.
  • requirements are declared for each data item.
  • the main elements that make up the requirement declaration are: (1) data item name, (2) expression for its value, (3) There are generation conditions for the value (execution conditions for the generation expression), (4) input / output attributes, and (5) value attributes.
  • Table 1 is an example of a word requirement declaration.
  • the data item name is an identifier for identifying the data item
  • the generation formula is a calculation formula for generating the value of the data item
  • the generation condition is an execution condition for executing the generation formula.
  • One data item may have two or more generation expressions, and which one is executed is It will be determined by the generation conditions.
  • the input / output attribute indicates the distinction between the value of the data item being input and the force generated by the program.
  • I represents input and ⁇ represents output.
  • An attribute is an attribute of a data item value, for example, whether the value is an integer, a floating-point number, or a Boolean value (boolean).
  • int is an integer and float is a fixed-point number.
  • the data item used for the generation formula and generation condition is called the start point, and the generated output data item is called the end point.
  • the declaration Sa of the data item a means that the code of Sa means “if b * e> 2 is true, assign the calculation result of b + c to the data item a and output the value of the data item a”. is doing.
  • Replacement paper The 4/1 mode means “enter value in data item c”.
  • the software control logic is provided as a template with a fixed structure as universal logic that can handle all requirements.
  • programming logic errors are eliminated. Since the source is automatically generated using the template, the programming time is greatly reduced. Flexibility is also a major advantage of the Lyee methodology. This is because maintenance work (ie, modification or modification of requirements) can be reduced to the task of adding, deleting and Z or modifying declarations of data items.
  • Lyee solves this order (execution procedure) problem in two ways.
  • the first method is the “iterative method” and the second method is the “optimal ordering method”.
  • Figure 1 shows the execution control logic that executes the declaration for each data item. This control logic repeats code execution until it reaches a fixed point of the execution result of the code within the execution range.
  • a fixed point is a state in which the value of a V or any other data item is no longer generated (a state in which no change occurs) even if the execution of code in the execution range is repeated.
  • a state where the fixed point has been reached is also referred to as “no change in state”. Meaning that there is no change in the value decision state when the previous round result is compared with the current round result. It is.
  • the “iterative” control logic simply repeats the execution of the code in the execution range until a fixed point is reached. Therefore, regardless of the order in which data items are generated, the values of all output data items can be generated.
  • the other case is when there are data items that cannot be generated even after repeated processing. This is because the value of the starting point that constitutes the data item generation formula is not determined within the repeated execution range.
  • the generation formula for data item a is b + c + d.
  • Data item d is not a data item that is input in the execution range of Figure 1, but is also an output data item that is generated.
  • Table 4 shows the formation process of each data item value by repeated execution.
  • the values of input data items c and e are determined by the first execution.
  • the value of data item b is newly determined by the second execution.
  • the generation condition of data item a can be judged.
  • the optimal ordering method is a method of generating execution code that automatically arranges declarations for data items arranged in random order so that they are arranged in an optimal order so that they are satisfied in a single round process.
  • Techniques relating to the rearrangement method are disclosed in Patent Document 10, Patent Document 11, and Patent Document 15. It seems that the iterative method and the optimal ordering method seem to be at the opposite end. These two methods are possible in Lyee.
  • This is a module that composes a program by capturing the requirements in units of data items. Is based on the processing of data items. In the iterative method, the values are established in the order of the optimal order, so it can be said that the order is searched every time the program is executed.
  • the optimal ordering method is a method in which the optimal ordering is performed before implementation and executed in the optimal order when the program is executed.
  • a system is usually divided into several units. It is also a power that is very difficult to make a large system with complex specifications without dividing it.
  • the division is done hierarchically.
  • the system (or subsystem) divided is called a program, and the program divided is called a module.
  • systems screens, forms, external interfaces, etc.
  • design the internal structure of the system to realize it, and design how to divide the system (detailed design 'program design).
  • the structural design (module design) of the divided units is first performed, and finally the source code is described in the programming language.
  • system partition design There are several methods for system partition design.
  • the program is divided into functional units of the system and modules. It can be said that the higher the independence of divided programs and modules (the less the degree of involvement with other programs and modules), the higher the quality of the system.
  • the level of independence depends on the skill of the designer and is generally not high. When independence is low, when designing one program or module, one must understand the relationship with the other. When modifying a module, the effect on other programs and modules must be considered. Also, with the method of dividing into functional units, the processing performed by programs and modules depends on the specifications, so reusability is low.
  • Object orientation is a technique born to solve the problems of module independence and reusability.
  • Modules are completely independent and highly reusable.
  • the definition of modules ie objects
  • the quality of object design depends heavily on the skills of engineers.
  • the design method of the internal structure of the object is specified, the quality of the design depends on the skill of the engineer.
  • the unit of program division is determined by focusing on the output for each event.
  • the role of the system is to output the requested processing results according to user requests (whether direct or indirect). Therefore, the program starts a series of processing (input, calculation, output) corresponding to the event by some event (such as a button press on the screen by the user. Refer to the section below for the definition of the event), and the final output When you are finished (such as displaying the results on the screen), the process ends.
  • This program is composed of modules having a fixed control structure. This module is called a “unit module”. This unit module is further composed of several types of modules for executing declarations for each data item. A module that executes these declarations is called an “element module”.
  • Fig. 2 illustrates the above-described system division structure using Lyee.
  • the unit module is a unit in which element modules are grouped by paying attention to the output.
  • Computer input / output processing is performed on a set of data items rather than on a data item basis, but at the same time, it is input or output to the same medium (means for recording or displaying data items such as screens, files, and forms).
  • a set of data items to be processed is referred to as a logical record in this application.
  • a unit module captures a set of element modules involved in the generation and output of one output logical record, and processes one or more of these sets.
  • FIG. 3 illustrates the structure of the unit module.
  • the unit module palette is a collection of element modules for each processing content.
  • “Processing content” here refers to processing from the hardware perspective of input, output, and computation, which are basic computer processing rather than functional processing depending on specifications.
  • the feature of Lyee is the modularity
  • the three pallets are called W02 pallet, W03 pallet, and W04 pallet, respectively.
  • the W02 palette is a set of element modules related to input of input data items.
  • the W03 pallet is a set of element modules involved in determining the execution condition of the output data item generation expression.
  • the W04 palette is a set of element modules related to the generation of output data item values (by execution of generation formulas) and the output of values.
  • Each pallet has a pallet control module that is responsible for activating element modules in the pallet.
  • the pallet control module itself is activated by the overall control module shown in Fig. 2. There may be one overall control module for a program or one for the entire system.
  • element modules There are several types of element modules depending on the type of processing, and they have a fixed structure that does not depend on requirements. There are nine types in the embodiment described here. The outline of the element module is described below for each pallet.
  • the W04 palette consists of four types of element modules: initialization module S4 (S4), data item module L4 (L4), output module 04 (04), and route determination module R4 (R4).
  • S4 initialization module
  • L4 data item module
  • L4 output module 04
  • R4 route determination module
  • Fig. 4 the abbreviations in Katsuko are shown.
  • the data item module L4 executes the output data item generation formula and determines the value.
  • Data item module L4 is created for each output data item generation formula.
  • Figure 3 shows the configuration of element modules for the requirements shown in Table 1.
  • L4_a executes the generation formula b + c of the output data item a
  • L4_b executes the generation formula 2 * c + 5 of the output data item b.
  • the output module 04 performs a process of outputting a set of output data item values (output logical records) to a medium.
  • the route determination module R4 designates the pallet to be executed next as W02 after the W04 pallet reaches the fixed point.
  • the initialization module S4 initializes the values and flag areas in the unit module. 1 1
  • the W02 palette consists of input module 12 (12), data item module L2 (L2), and route determination module R2 (R2).
  • the input module 12 performs processing to input a set of input data item values (input logical records) from the medium to the memory area.
  • Data item Module L2 checks whether the attribute of the input value meets the requirements. One L 2 is created for each input data item.
  • the route determination module R2 designates the pallet to be executed next as W03 after the W02 pallet reaches the fixed point.
  • the W03 palette consists of data item module L3 (L3) and route determination module R3 (R3).
  • the data item module L3 is created for each execution condition (generation condition) of the output data item generation expression, and executes the generation condition determination.
  • L3_a performs the determination of the generation condition b * e> 2 of the output data item a
  • L3_b performs the determination of the generation condition c> 0 of the output data item b.
  • the path determination module R3 designates the pallet to be executed next as the W04 pallet in its own unit module or the pallet of another unit module after reaching the fixed point in the W03 pallet.
  • the element module is modeled, and the module is completed by substituting information that changes according to requirements, such as the data item to be processed, the generation expression 'generation condition, and the input / output target medium.
  • Data item modules have a common processing flow structure as shown in FIG. Each element module is responsible for a single process. If the target process is incomplete and the execution conditions are met, the target process is executed, and if the execution conditions are not met or the process has been completed. If it is not executed, it has a judgment step (step 41). In the iteration method, we want to execute only the modules to be processed in order to eliminate unnecessary processing at the time of repetition. This control is realized by autonomous self-control of the element module in Step 41.
  • Step 41 is a step of determining whether or not to execute the target process.
  • the first determination “objective processing incomplete?” Determines whether there is a value in the recording area of the value of data item a. With Lyee, initialization is performed at an appropriate timing for the value recording area, and the value is recorded in the area only once when the value of the data item is satisfied, so this determination is possible.
  • the second judgment “execution condition satisfied?” Judges whether or not the generation condition (execution condition of the generation expression to be executed) is satisfied. That is, it is determined whether L3_a (b * e> 2) is satisfied. If these two determinations are both true, the target process is executed (step 42). The target process is the execution of generator b + c. The value of the execution result is recorded in the temporary area a_tmp. The next step is to determine whether a result that meets the requirements has been obtained (step 43). Specifically, it is determined whether or not the temporary area a_tmp has a value.
  • step 43 determines whether to execute again. This determination is made based on whether or not there has been a state change in the own pallet. Check the status change in its own pallet and record the result in the control area. If there is a status change, proceed to step 47 because it should be re-executed. In step 47, information indicating that the four groups of the own pallet are to be executed once again is recorded in the control area.
  • step 46 the process proceeds to step 46, and the fact that the result of the objective process is not established is recorded in the control area. If it is determined in step 43 that the target process is successful, the value of the temporary area a_tmp is copied to the area a to confirm the processing result (step 44).
  • Table 6 shows the code of the palette function that controls the execution of the element modules in the unit module.
  • Table 6 corresponds to Figure 3 because it is a unit module with the requirements of Table 1.
  • the comment indicates the meaning of the code.
  • this refers to events (such as mouse clicks and key presses) that are performed by the user on the computer, as well as power events (error messages, etc.) generated by the computer.
  • the program performs a series of processes corresponding to the generated event as a cue to start some event, and displays or records the result of the process, and then the program enters an idling state. For example, when you click the button at the right end of the combo box on the operation screen of Windows (trademark) OS (trademark), an item selection list (list box) is displayed.
  • the “click the button at the right end of the combo box” performed by the user is the event
  • the series of processing until “display the item selection list (list box)” is a series of processing corresponding to the event.
  • Events are not limited to operations performed directly by the user.
  • a timer set in advance in the program is also an event.
  • Patent Document 1 Pamphlet of International Publication No. 97 16784
  • Patent Document 2 International Publication No. 98Z19232 Pamphlet Patent Publication 3: International Publication No. 99 No. 49387 Pamphlet Patent Literature 4: International Publication No. 00,79385 Pamphlet Patent Literature 5: International Publication No. 01Z35213 Pamphlet Patent Literature 6 : Pamphlet of International Publication No. 01 Z93026 Patent Document 7: Pamphlet of International Publication No. 02/42904 Patent Document 8: JP 2002-202883 A
  • Patent Document 9 International Publication No. 2004Z25463 Pamphlet
  • Patent Document 10 International Publication No. 2004Z68342 Pamphlet
  • Patent Document 11 Pamphlet of International Publication No. 2004Z81788
  • Patent Document 12 International Publication No. 2005Z29321 Pamphlet
  • Patent Document 13 International Publication No. 2005Z29322 Pamphlet
  • Patent Document 14 Pamphlet of International Publication No. 2005Z29323
  • Patent Document 15 International Publication No. 2005Z43271 Pamphlet
  • Patent Document 16 International Publication No. 2006Z006621 Pamphlet
  • Patent Document 17 International Publication No. 2006Z025472 Pamphlet
  • Patent Document 18 Pamphlet of International Publication No. 2006Z030809
  • Patent Document 19 International Publication No. 2006Z035676 Pamphlet
  • Patent Document 20 Pamphlet of International Publication No. 2006Z038303
  • Lyee achieved new development and maintenance development productivity and quality improvements by providing the means to implement the requirements accurately, simplify program design, and automate coding.
  • the conventional Lyee has a problem that the execution speed is slow and the program size is large.
  • the purpose of this application is to provide an improved technique for the iteration method Lyee, which maintains the advantages of Lyee, improves processing speed, reduces the size of the program, and further reduces the work of the developer. It is to disclose.
  • the present invention relates to the following improvement method for Lyee in the conventional iterative method. These improvements aim to increase the software execution speed, improve the program size, and reduce the work of developers by using the Lyee methodology.
  • an object of the present invention is to provide a system, a processing device, a recording medium, a program generation support device, a data structure, and a program creation method for realizing the above improvement.
  • the present invention realized as a system 'program is a unit program developed based on a program design method for creating a unit program for each event.
  • a plurality of unit modules each of which is an element module having a fixed structure, an input processing module for inputting input data items to the medium force memory, and for generating output data items
  • Output data generation processing module for performing condition determination and generation formula execution, output processing module for outputting output data item from memory to medium, and value of data item to be processed by own unit module For initializing the recording area and the storage area for information related to the control of the unit module.
  • Initialization process Moji 16 modules and a path determination module for specifying the unit module to be executed after the unit module reaches the fixed point and determining whether the Z or system program ends.
  • a system comprising at least a unit program and an overall control module for activating or ending a specific unit module according to the determination of the path determination module among the plurality of unit programs.
  • Each of the modules has at least a function of determining an execution condition of the target process and a function of executing the target process when the execution condition is met, and when the target process is not executed and the execution condition is satisfied
  • the element module is executed only when the unit of output logic or the restart condition of the requirement restarts.
  • the unit module is configured by forming a set in the same unit, and repeated execution of the element module in the set is controlled by a state change within the repeated range in the set, and the unit module and the adjacent unit module are adjacent to each other.
  • the path is determined based on the status change of the lower unit module, the end condition of the own unit module, the requirement restart condition of the own unit module, and the execution status of the connected lower unit module, and for each unit of the set, Initialization is performed at the time of initial activation of a set after the occurrence of an event and at the time of restarting the requirements of the set.
  • element modules having a fixed structure are clarified after being limited to five types, and further, a unit module in which these element modules are assembled according to a certain rule is provided. Since this unit module is formed and generated in units of events, it is possible to eliminate the pallet division structure, which is essentially an extra work. Therefore, a more compact program can be realized. Furthermore, at this time, the unit module unit is set for each output logical body or for each set of output logical bodies having the same requirement restart condition, and the initialization module is started immediately after the unit module is started. It is possible to rule out the execution timing of, and to eliminate arbitraryness in this sense. This eliminates the individuality, personality, and arbitraryness of each developer, and makes it possible to reduce the developer's work by simply making the program generation work common and thus enabling automation.
  • each of the modules according to claim 1 is routinely executed and a computer executes the routined instruction. 17
  • the initialization execution timing can be standardized 'ruled', individuality for each developer 'personality'
  • a processing device with functions that enables automation of "removal of arbitrariness, standardization of program generation work” and reduction of developer work is realized.
  • the present invention realized as a recording medium is characterized in that the system program including each of the modules according to claim 1 is stored.
  • the present invention implemented as a program generation support device or a program generation tool defines an event from a software development request, defines a unit program for each event, and defines an output logic body in the unit program.
  • a system comprising at least a unit program to be developed and an overall control module by creating a program design (processing path diagram creation) information by defining a unit module according to the requirement restart condition of the output logic body 'Generate a program Input processing modules for inputting input data items from a medium to a memory, and condition determination for generating output data items, each of which is an element module having a fixed structure
  • Output data generation processing module for executing generation formulas
  • An output processing module for outputting an output data item from memory to a medium, a storage area for data item values to be processed by the unit module, and information relating to control of the unit module Area initialization processing module for initializing the area, and the unit module to be executed after the unit module reaches the fixed point and the path for determining the Z or system 'program end
  • each of the element modules has a function for determining the execution condition of the target process and the purpose when the execution condition is met.
  • the element module is executed only when the target process is not executed and the execution condition is satisfied, and the element module has the same output logical unit or the restart condition of the requirement restart.
  • the unit module is configured by forming a set in a unit, and the repeated execution of the element module in the set is controlled by a state change in the repeated range in the set.
  • the path is determined by the status change of the self-unit module and the adjacent lower unit module, the termination condition of the self-unit module, the requirement restart condition of the self-unit module, and the execution status of the connected sub-unit module. For each unit of the set, initialization is performed when the set is initially activated after the event occurs and when the requirements of the set are restarted.
  • the “information related to the declaration” may be the information itself including the declaration in the intermediate language, or may be obtained by converting the declaration in the intermediate language into the desired programming language. It may be information.
  • the “first storage means” to “third storage means” are areas where information can be temporarily stored or stored at least temporarily. As a corresponding structure, specifically, for example, in the computer Or a memory area outside the computer. “Substitution means” refers to a function for substituting the information related to the declaration into each predetermined (blank) position of the element module.
  • a corresponding structure for example, This includes a statement for causing the computer to execute the function, or a computer that includes and executes the statement (including a case where a general-purpose computer is used as a dedicated computer for executing the function).
  • the “arranging means” means a function for arranging the element module so as to be configured based on the processing path diagram information reflecting the development request.
  • the corresponding structure is as follows. For example, a command statement for causing the computer to execute the function or a computer that executes the command statement (a general-purpose computer can be used to execute the function). 19 and the case where the computer is converted to a dedicated computer).
  • element modules having a fixed structure are clarified after being limited to five types, and further, a unit module in which these element modules are assembled according to a certain rule is provided. Since this unit module is generated in units of events, a program generation support device or a program generation tool for generating a more compact program that eliminates the division structure of the nozzle is realized. Furthermore, since the unit module unit is set for each output logical body or for each set of output logical bodies having the same requirement restart condition, the initialization module is started immediately after the unit module is started. Can be used to reduce the decision work and design work for program developers and realize more efficient program development work.
  • the present invention realized as a data structure or a program template defines an event from a software development request, defines a unit program for each event, defines an output logical body in the unit program, By defining a unit module in accordance with the requirement restart condition of the output logic body and creating program design (processing path diagram creation) information, at least a unit program to be developed and an overall control module are provided, and the unit program Is a system having a plurality of unit modules.
  • a data structure as a module used to generate a program, and the data structure is an input processing module for inputting an input data item into a medium memory.
  • Input with a fixed structure with fields for entering declarations corresponding to requirements Is an output data generation processing module that performs condition determination and generation formula execution for generating output data items, and includes a template for entering a declaration corresponding to the requirement.
  • An output data generation processing module with a structure and an output processing module for outputting output data items from memory to a medium, and an output with a fixed structure with fields for entering declarations corresponding to requirements This is an area initialization processing module for initializing a processing module, a recording area for data item values to be processed by the unit module, and a storage area for information related to the control of the unit module.
  • the area initialization processing module having a fixed structure with a field for entering a declaration corresponding to the requirement, and the unit module of the self reached a fixed point.
  • a unit control module for determining activation and z or restart of the arranged element module in the unit module, and a plurality of unit control modules when arranging based on the program design (processing path diagram creation) information Start of a specific unit module or system according to the determination of the path determination module in the unit program.
  • a data structure comprising an overall control module for ending the program, each of the element modules having a function for determining the execution condition of the target process and the execution condition And at least a function for executing the target process, and is executed only when the target process is not executed and execution conditions are satisfied, and the element module is a unit of output logical body or a restart condition for restarting a requirement.
  • the unit module is configured by forming a set in units having the same, and the repeated execution of the element module in the set is controlled by a state change in the repeat range within the set, and the unit module and the adjacent lower module are controlled.
  • Status change of unit module, termination condition of own unit module, requirement restart condition of own unit module, execution status of connected lower unit module A path is determined by, for each unit of the set, characterized in that the initialization is performed and when requirements resurgence of the set and the time of initial activation of the set of post-event.
  • the "information related to the declaration” may be the information itself including the declaration in the intermediate language, or may be converted into a desired programming language by converting the declaration into the intermediate language. It may be the information that can be obtained.
  • a desired program can be obtained by substituting information declaring a development request into a template having a standard structure as a data structure or a program template.
  • the program development work will be greatly improved.
  • the present invention realized as a program creation method is a software development request key.
  • 21 Define the event, define the unit program for each event, define the output logic in the unit program, specify the unit module according to the requirement restart condition of the output logic, and design the program (processing Creating a path diagram), declaring the software development request for each event, and constituting the unit module, each of which is a declaration of the requirement information declared in the template of an element module having a fixed structure
  • the element module is used to input a data item from a medium to a memory, to determine a condition for generating an output data item, and to execute a generation formula.
  • An output data generation processing module an output processing module for outputting output data items from memory to a medium
  • a unit area module for initializing a recording area of data item values to be processed by the unit module, a storage area for information related to the control of the unit module, and the unit of the unit module.
  • a step that is a path determination module for specifying the unit module to be executed after the module reaches the fixed point and determining whether the Z or system program ends, and for each of the unit programs, the path determination module The step of defining a global control module for starting a specific unit module or ending a system program according to the determination is provided.
  • the element module having a fixed structure 'control module can be used, and the configuration method and work steps of each module can be ruled. It is possible to eliminate the developer dependency that was inherent.
  • an event is defined from a software development request
  • a unit program is defined for each event
  • an output logic body in the unit program is defined
  • the output A step of defining a unit module in accordance with a requirement restart condition of a logical body and designing a program (processing path diagram creation), a step of declaring the software development request for each event, and the method generated in claim 5
  • a step of substituting the declared requirement information may be provided in the blank of the data structure as a program template.
  • the element module 'unit module' unit program described above 22 Identifies the settings, grasps and restarts them as requirement restarts and non-requires restarts, and clearly defines the range to be restarted in the element module 'control module, and rules the initialization module execution timing. Eliminates palette division, simplifies and reduces the number of element modules, does not depend on requirements, efficient and repetitive control, improves initialization execution judgment, simplifies path judgment conditions' standardization, inputs multiple records And the clearness of the output processing control and the clearness of the program design method are realized.
  • the present invention relates to the following improvement method for Lyee in the conventional iterative method. According to the present invention, it is possible to improve the execution speed of software developed by the Lyee methodology, improve the program size, and reduce the work of the developer in the development process.
  • specific embodiments of the present invention will be described with reference to the drawings. In the following, the processing flow will be explained with tables, flowcharts and words, but no code is shown. It is easy to realize such information with a programming language such as VisualBasic (trademark), for example.
  • the invention of the present application can be grasped as a processing device to be executed on the computer, as a recording medium on which the program is recorded, or as a method of carrying out these, respectively. All of these are included.
  • the unit module has a structure with no pallet division, and is composed of the following two types of control modules and five types of element modules. twenty three
  • One total control module ⁇ is created for each program or one for the system. Its role is to start the unit control module ⁇ of the unit module to be started next or to terminate the program according to the determination of the path determination module R.
  • Input a set of input data items (input logical records) from the medium to memory. Create for each input logical record.
  • Output data item generation condition judgment and generation formula are executed, and output data item value is generated. Create for each output data item. If the output data item has multiple generation expressions, it is better to create it for each generation expression. In this application, the case where it creates for every production
  • generation formula is demonstrated.
  • Output data item set (output logical record) is output from memory to media.
  • the route has the following cases.
  • the upper unit module is executed.
  • the essence of the input module I is to transfer input data input from a medium outside the memory to a memory area where generation is performed.
  • ancillary processing to be performed on input data check the attribute of the value, check whether the value is in the domain (for example, if the input data item is quantity, the domain is not null), attribute There is conversion.
  • These processes can be implemented as input module I, or can be implemented as generation module L. It can be implemented in an optimal way such as considering the system execution environment such as a database. Yes.
  • Other incidental processing that should be performed during input processing is not particularly specified but is included in input processing.
  • the essence of the output module O is to transfer output data, which is a generation result recorded in the memory area, to a medium outside the memory.
  • Ancillary processing to be performed on the output data includes editing of values (such as adding a comma to a numerical value). May be.
  • Other incidental processing that should be performed during output processing is included in the output processing, although it is not specified.
  • the essence of the generation module L is to perform the operation specified by the requirement using the input data in the memory area and record the operation result in the memory. twenty five
  • Step 1 is a step for determining whether the target process should be executed. There are three execution conditions, and the first condition is that the target process has not been completed. This determination is indispensable for eliminating unnecessary processing execution if it is an iterative method, and is the same as conventional Lyee, but in this application, another method is shown as a determination method nomination.
  • the completion of the objective processing of the element module provides an area for recording the completion. The initial value of the area is a value indicating incomplete, and when the element module completes its target processing, a value indicating completion is recorded. A target process completion area is provided for each element module.
  • the second condition is that the generation condition and the starting point of the generation formula are all determined. By adding this second condition, the target process is executed only when it is satisfied.
  • the third condition is that the generation condition is satisfied. The third condition is necessary when the output data item has multiple generation expressions. Only one of the generation conditions defined for each generation formula is established, the corresponding generation formula is executed, and one output data item value is determined. Even if there are multiple generation formulas, there is one area to record the generated value. After the value is established, L in the other generation formula does not satisfy the first execution condition, so the process ends only in step 1.
  • Step 2 is executed only when the three execution conditions are all satisfied in the determination of Step 1. If any one of the conditions is not satisfied, the generation module L ends. At this time, the value of the generation completion area remains the initial value and indicates incomplete. Step 2 is the execution of the objective process. The generation module L executes the generation formula and records the value in the recording area of the generation module.
  • step 3 three processes are performed. One changes the value of the above-mentioned generation completion area and records that the target process is completed. In the other process, a value indicating “change in state” is recorded in the state change X region used for determining whether or not the generation module group is executed again.
  • One state change X area is provided in the unit module, and the initial value is a value indicating “no state change”. A method of determining non-requirement reoccurrence using this state change X region will be described later. 26
  • a value indicating "status change” is recorded in the status change Y area.
  • This state change Y area is used to determine whether or not to repeatedly execute the ranges of the input module I group, the generation module L group, and the output module O group.
  • the initial value is a value indicating “no change in state”. How to determine non-requirement using state change Y area will be described later.
  • the generation module L will be specifically described using an example of a “purchase price calculation” system.
  • the “ ⁇ purchase price calculation” system has the screen shown in Fig. 6. In this screen, enter the product name in the input data item “Product name”, the number of products to be purchased in “Purchase quantity”, and press the “Calculation display” button. Unit price power The discount rate when the product is purchased in the quantity specified in “Discount rate”, and the purchase price is displayed in “Purchase price”.
  • the business requirements for this system are summarized in Table 7.
  • Table 8 shows a specific example of the processing flow of the generation module L for the output data item “Purchase Amount” corresponding to FIG.
  • Table 9 shows a specific example of the processing flow of the generation module L for the output data item “unit price” corresponding to FIG.
  • Table 10 and Table 11 show specific examples of the processing flow of the generation module L for the output data item "discount rate".
  • the output data item “discount rate” has a different generation formula depending on the conditions.
  • the processing flow of the generation module L described in this application explains the implementation method when creating each generation expression.
  • Step 71 is a step for determining whether the objective process should be executed.
  • the first condition is that the target process has not been completed.
  • the determination is based on the state of the value of the input executed area provided for each input module I.
  • the second condition is necessary only when the input medium is a file. In order to input file power, the value of the data item that serves as a reference key for searching the target data is required. Determine whether the key item value has been determined. If both execution conditions are satisfied in step 71
  • Step 72 is executed only if the first condition is satisfied when the input source is a screen. If the condition is not met (No in step 71), input module I terminates. At this time, the value of the input completion area remains the initial value indicating incomplete.
  • Step 72 is execution of a target process.
  • the purpose processing of input module I is the input of input data items from the medium.
  • the input source is a file
  • an instruction written in SQL or the like is executed.
  • the value of the reference key item described above is required.
  • a value indicating input completion is recorded in the input execution completed area.
  • Step 73 determines whether the input has been completed normally. Judgment is made based on the input processing result information recorded in step 72. If input is successful, go to step 75. If the force does not complete normally, go to step 76 and record the value indicating that the input did not complete normally in the input error area.
  • Step 75 is a step of recording that the input has been normally completed.
  • One is to record a value indicating that the value of the input data item is determined in the input completion area provided for each input data item.
  • the processing flow in Fig. 7 is explained using a specific example of the input of the “Purchase Amount Calculation” system described above. In the processing program corresponding to the “calculation display” button event in the “purchase price calculation” system, there are two input logical records.
  • Step 81 is a step of determining whether or not the objective process should be performed.
  • the first condition is that all output data items belonging to the output logical record to be output have been generated (unless otherwise specified in the business requirements).
  • the second condition is that when the output is update or deletion to a file, the value of the key item for searching for the item to be updated or deleted is determined.
  • the third condition is that this condition is met when there is an output condition defined in the business requirements. In the case of output processing, there is no repetitive processing, so whether or not the target processing is incomplete needs to be an execution condition. If these execution conditions are satisfied in the determination of step 81, the process proceeds to step 82. If the condition is not satisfied, the output module ⁇ is terminated.
  • Step 82 is execution of the target process.
  • the target processing of output module O is the output of output data items to the medium. If the output destination is a file, use SQL
  • the instruction will be executed. At this time, the value of the reference key item described above is required. After executing the output, record the result information of the output process returned by the operation system.
  • Step 83 determines whether the input has been completed normally. Judgment is made based on the output processing result information recorded in step 82. If the output is completed successfully, go to step 84. If not completed normally, go to step 85 and record a value indicating that the output did not complete normally in the output error area. In step 84, since the output has been completed normally, the output completion is recorded.
  • FIG. 8 The processing flow of FIG. 8 will be described using a specific example of the output of the “purchase price calculation” system described above.
  • the processing program corresponding to the “Calculation Display” button event in the “Purchase Amount Calculation” system there is one output logical record, which is output to the “Purchase Amount Calculation” screen.
  • the output data items are “unit price”, “discount rate”, and “purchase amount”.
  • the output logical record output module ⁇ is as shown in Table 14.
  • the input module group I is sequentially activated (step 8102). This is to input the input logical records necessary for the output that is the final purpose of the unit module.
  • the activation order of the input module group I is not limited. For example, if the input value of logical record A, which is input from a file, is used as the key, the logical record A
  • the generation module L group is activated next (step 8103).
  • the activation order of the generation module L group is not questioned.
  • the activation of group L is repeated until there is no change in state (step 8104).
  • the range subject to state change is the range indicated by the dotted line X.
  • one control information area for recording the state change is provided, and this is called the state change X area.
  • the generation module L whose value is satisfied records that there was a state change in the state change X area. Records in this area are overwritten. If even one of the L groups has a new value, the state changes.
  • the L value may be newly established, so the one-round execution of the L group is repeated.
  • the state change X area is initialized every time so that the state change information always represents the result of the round-trip process executed immediately before.
  • output module group 0 is sequentially activated (step 8105). The activation order of group 0 is also unquestioned. If input or generation is not complete, output will not be completed. This is also resolved by non-requirement restart.
  • step 8106 it is determined whether or not to repeat the one-round execution of the range indicated by dotted line Y (range from input to output) (step 8106). Judgment is made based on the state change in range Y.
  • the input module I and generation module L for which the value is established records that there was a state change in the state change Y area. Recording in this area is overwriting. If at least one of the I and L groups is satisfied, the state is changed. While it is determined that “there is a state change”, new values of I and L may be established and 0 may be completed. Therefore, a round of I, L, and 0 groups is repeated.
  • the state change Y area is initialized every time immediately before starting a round of the range Y so that the state change information always represents the result of the round process executed immediately before. 32
  • the path determination module group is sequentially activated. As mentioned above, there are the following four types of routes.
  • the upper unit module is executed.
  • Restart own module (restart requirement).
  • the route determination module R creates one for each route type. For the four types of routes, the conditions under which each route is selected are determined, and only one route with each force is established. When the route determination module R group is activated sequentially, the R that matches the route condition records the identifier of the unit module to be executed next in the route area. The unit control module ⁇ ends, and the overall control module ⁇ starts the unit control module ⁇ of the unit module specified in the path area.
  • the route determination module R group processing flow and each route will be described in detail later.
  • the number of requirement restarts of the element modules that are executed in any order can be reduced compared to the pallet division structure that is repeated for each pallet.
  • the I group, the L group, and the O group may be topologically sorted into their respective groups (see Patent Document 10 and Patent Document 15 for the topological sort).
  • topological sorting may be performed by combining the I group, the L group, and the O group. In this case, the status change is recorded and judged only in the Y range.
  • the Lyee program design (processing path diagram creation) method of the present invention is based on the method described in detail in Patent Document 17. So The main points of 33 are to create a program for each event, and to create a unit module that is the unit of the program based on the unit of the output logical record.
  • Lyee's program design diagram is shown in Figure 10. The line connecting the arrangement of unit modules and unit modules represents the order and path in which the unit modules are activated.
  • the activation sequence and path are sequentially activated from left to right starting from the left end (top), and return to the left end while completing the output of the right force in order.
  • the output force S is established at the leftmost module.
  • the unit module that outputs to the screen is placed at the left end.
  • the unit modules that are in the upper and lower relationship have an end point start relationship between any of the data items belonging to the two unit modules.
  • Unit modules related to the end point start point are adjacent to each other.
  • Unit modules having no end point start point relationship are usually placed in a parallel relationship.
  • File input / output may be processed for a plurality of records.
  • a loop or subroutine is called again in a program when processing multiple records.
  • a unit module processes a range to be processed. This unit for processing multiple records can also be understood based on the same criteria of output logical record units.
  • a unit module may be created for each output logical record. In this case, however, the division unit of the program becomes larger than necessary. In the case of the iterative method, if there are many division units, the number of non-requirement restarts increases. For a set of output logical records that do not have requirement reoccurrence, a set of output logical records that have the same condition for requirement reoccurrence is one set of each.
  • an efficient program with fewer non-required restarts can be created. For example, suppose there are two detail displays on the screen, one displaying 10 and the other displaying 20. In this case, the 10 output logical records and the 20 output logical records are created as separate unit modules. However, the output to the screen is not the same unit module as the output logic record of the other single output, but is normally created as one independent unit module and output at the end. Place it in the upper position (left end).
  • the multiple case processing there is a case of the "order status inquiry" screen of FIG.
  • the specified customer name is displayed (8303), and the order status data details are the order number. (8304).
  • the event of this process is a combo box list selection, and the input data from the screen is the customer code and the selected year and month.
  • Input data from the file is the customer name (eg from the customer master) and order status data (eg from the order file).
  • the output data to the screen is a customer name and order status data. There is no output to the file.
  • the customer name is processed in one case.
  • the order status data is processed in multiple cases.
  • FIG. 12 shows a processing path diagram of this processing.
  • Path 1 is usually placed in the unit module (top level) that does not have a higher rank. Unless otherwise specified in the requirement, it normally ends when all the events have been processed, so it is placed at the top level where output is completed at the end. There is no need for unit modules that do not transition to end processing.
  • the lower level is “not executed”. One is when the lower level has not yet been initially activated. The other is when the requirements are reinitiated after returning to themselves from a lower level.
  • the vertical relationship is the force with which the mutual data is in the end point start point relationship. Then, the reason why it is divided is because the requirement restart condition of each output logical record is different, or one is one case processing.
  • the hierarchical relationship differs only in the conditions for reinitiating the requirements (one case can be regarded as a condition force for reinitiating the requirements)
  • the explanation according to the 36 road selection conditions is as follows.
  • the 8401 is activated and the status does not change (the status is that the input from the screen is completed and the output data value is satisfied). Since the condition of path 2 is satisfied, the lower unit module 8402 is selected. When the state change of 8402 disappears (input and generation is completed), the condition of path 3 is satisfied, so the upper 840 1 is selected. 8401 is activated and there is no state change (all output data values are not established). Since 8403 is not executed, route 2 is established and 8403 is selected. When the state change of 8403 disappears (the state where the input and generation of one record have been completed), the condition of path 4 is satisfied, so 8403 is re-started.
  • Order file power The condition of path 4 is satisfied until the last record is input and generated.
  • the state change of 8403 disappears after generation of the last corresponding record, the condition of path 3 is satisfied and the upper 8401 is executed.
  • the state change disappears, the condition of path 1 is satisfied, and the program ends.
  • Step 8501 is execution condition determination, and there are two execution conditions.
  • the first condition is that the route is undecided. If the route determination module R executed before itself has determined the route, it ends.
  • the second condition is that the execution conditions listed in Table 15 are satisfied. If the two execution conditions are met, in step 8502 the identifier of the unit module on the route in charge is recorded in the route area. In the case of end, it is the end module identifier that performs the end processing of the program.
  • Overall control module force Reads the path area identifier and activates the unit control module of the corresponding unit module.
  • the processing flow of the initialization module is shown in Fig. 14.
  • the initialization module S is activated immediately after the unit module is activated.
  • initialization is not triggered during a unit module restart.
  • the purpose of initialization is to control to finish all the output that is the final purpose specified in the requirements, and to terminate the program upon completion. This is because data items and control flag values must not be initialized until final output is completed. Also, if the initialization is done until the program ends. 37 No. This is because the initialization of the area causes unnecessary execution of the element module even if the target output is completed, and the program does not end.
  • the initialization module is started in the following three cases.
  • initialization must not be performed in the case of (3).
  • Initialization is necessary for the requirement restart in (2). Therefore, since the execution condition of the initialization module S is to be satisfied only in the cases (1) and (2), it will be “First start of unit module?” Or “Required restart?” (Step 91) ). Whether or not it is the first activation and whether or not the requirement restart force is sufficient may be determined by preparing an area for recording the activation status.
  • step 92 initialization, which is a target process, is performed.
  • the objects to be initialized are the data item value area that is established by the unit module and the control area related to the execution control of the module (initialization 2).
  • the area to be initialized has different parts at the first startup and when the requirements are restarted. In the case of requirement restart, do not initialize the area for key items required for file I / O and the area for control of requirement restart among the aforementioned initialization targets (initialization 2).
  • the unit module unit is set for each output logical record or each set of output logical records having the same requirement restart condition, and the initialization module S is started immediately after the unit module is started. It is now possible to set execution conditions (initialization timing) in a routine and build them into modules. There is no need for the developer to set the range that can be initialized and the conditions for executing the initialization, reducing the developer's work.
  • a program (system 'program), a processing device, a recording medium, a program generation support device and a Z or program generation tool, a data structure and a Z or a program template, a program creation method and a Z or It can also be realized as a program development support method, software for realizing these functions on a computer, and a recording medium equipped with the software, such as a dedicated machine.
  • FIG. 15 is a diagram when the present invention is implemented as a program generation support apparatus.
  • a storage unit 1501 stores the following three types of information.
  • the first information is an input processing module for inputting input data items from the medium to the memory, and a condition determination and generation formula for generating output data items, each of which is an element module having a fixed structure.
  • An output data generation processing module for execution, an output processing module for outputting output data items from the memory to the medium, a recording area for data item values to be processed by the unit module, and
  • An area initialization processing module for initializing the storage area of information related to the control of the unit module, the designation of the unit module to be executed after the unit module reaches the fixed point, and the Z or system.
  • a path determination module for determining the end of a program, a unit control module for controlling these element modules, and a unit A code information of the overall control module for starting the control module.
  • Each of the aforementioned element modules has at least a function for determining the execution condition of the target process and a function for executing the target process when the execution condition matches the execution condition, and when the target process is not executed and the execution condition is satisfied Only run on.
  • the second information is that the software development request power also defines an event, defines a unit program for each event, defines an output logical record in the unit program, and defines a unit according to the requirement restart condition of the output logic.
  • Program design processing path diagram creation
  • declaration information that declares software development requests for each event.
  • [0093] 1502 creates a copy of each module, which is the first information, based on the declaration information, which is the third information, and copies the declaration information to the code of the copied module. It is an assignment unit that performs a process of assigning information to each predetermined position. Modules whose declaration has been assigned are stored in the storage unit 1501.
  • 1503 constitutes a program that satisfies the software development request based on the program design information, which is the second information, for the module whose declaration information has been assigned in 1502. 39 This is the placement section.
  • a completed program which is a module group into which the declaration information whose arrangement has been completed so as to constitute a program that satisfies the software development request, has been assigned, is stored in the storage unit 1501.
  • element modules are grouped into units of output logical records or units that have the same restart condition for requirement restart, and constitute a unit module.
  • the unit module is controlled by the state change within the repeat range in the unit module.
  • the state change of the own unit module and the adjacent lower unit module and the end of the own unit module Conditions and requirements of own unit module
  • the route is determined based on the restart condition and the execution status of the connected lower unit modules. For each unit of the above set, the unit module's initial startup and unit module Generated so that initialization occurs when the requirement is restarted.
  • the present invention allows various modifications, additions, substitutions, expansions, reductions, etc. within the scope of the same and equivalent technical idea.
  • an apparatus, method, software, or system produced using the present invention is listed as a secondary product and commercialized, the value of the present invention is not reduced at all.
  • the present invention can be applied to any application field of software regardless of business, education, game, or the like.
  • element modules having a fixed structure are clearly defined after being limited to five types, and further, a unit module in which the element modules are assembled according to a certain rule is formed, and this unit module force event Since it is generated in units, it is possible to eliminate the pallet division structure, which is essentially an extra work. Therefore, a more compact program can be realized. Furthermore, at this time, the unit module unit is set for each output logical body or for each set of output logical bodies having the same requirement restart condition, and the initialization module is started immediately after the unit module is started. The execution timing can be standardized, and arbitraryness in this sense can be eliminated.
  • FIG. 3 Shows the structure of unit modules in conventional Lyee.
  • FIG. 4 A flowchart showing the operation of the W04 palette element module in the conventional Lyee.
  • FIG. 5 is a flowchart showing the processing flow of the generation module L according to an embodiment of the present invention.
  • FIG. 6 is a diagram showing an example of a screen related to a request for development of a “purchase price calculation” system for explaining a generation module L according to an embodiment of the present invention.
  • FIG. 7 is a flowchart showing the processing flow of the input module I according to an embodiment of the present invention.
  • FIG. 8 is a flowchart showing a processing flow of the output module O according to the embodiment of the present invention.
  • FIG. 9 is a flowchart showing a processing flow of a unit control module ⁇ that performs execution control of element modules in a unit module according to an embodiment of the present invention.
  • FIG. 10 is a diagram showing an example of a program design diagram of Lyee according to an embodiment of the present invention.
  • FIG. 11 is a view showing an example of a screen related to a request for development of an “order status inquiry” system, for explaining a specific example of the plural case processing according to the embodiment of the present invention.
  • FIG. 12 is a diagram for showing an example of a program design diagram related to multiple processing of Lyee according to an embodiment of the present invention.
  • FIG. 13 is a flow chart showing a processing flow of a route determination module according to an embodiment of the present invention.
  • FIG. 14 is a flowchart showing a processing flow of an initialization module according to an embodiment of the present invention. 41.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Description

システム 'プログラム、処理装置、記録媒体、プログラム生成支援装置、デ ータ構造並びにプログラム作成方法
技術分野
[0001] 本発明は、システム 'プログラム、処理装置、記録媒体、プログラム生成支援装置、 データ構造並びにプログラム作成方法に係る。
背景技術
[0002] <ソフトウェア開発の課題 >
高 、品質を持つソフトウエアを容易に迅速に製造することは、ソフトウエア開発研究 分野の基本的な関心事である。ソフトウエア開発の生産性、保守性、品質を向上する ための種々の方法論および技術が考案され提案されてきたが、いまだにこれらの課 題を本質的に解決できたものはない。その理由の 1つは、ソフトウェア自身が複雑な ものであり、捕らえにくいものである力もであり、もう 1つの理由は、現在の方法論に限 界があるからである。実際、提案されたほとんどすべての方法論は、明快に理解でき 、修正可能なシステムの製造に失敗しているのみならず、それらは、非常に広範囲の 能力、技術および知識を持つ専門家にし力利用できないものといまだに見なされて いる。そのため、人件費や維持費が高いものになり、ソフトウェア上で実行させるため には広範なチェックが必要になる。従来のソフトウェア開発手法の概要と課題をまとめ ると以下のようになる。
(1)手続き型プログラミング
一般に、手続型プログラミングは、その記述言語の扱いやすさから、業務システム 開発とその実装において効果を発揮してきた。しかし、いまだ要件を正確に実装する ことの困難性、生産性や保守性の向上という重大な課題が残されている。
(2)宣言型プログラミング
一方、要件定義そのものである宣言によってプログラミングを行う宣言型のプロダラ ミングは、人工知能、エキスパートシステムをはじめ論理的証明（logical reasoning)、 推論（inference)、ユーザ情報収集（user intelligence gathering )など、非計算系のァ プリケーシヨン分野で使用されている。宣言型プログラミングは、制御手順でなぐ要 件定義されているデータ間の関係を宣言し、その宣言に基づいてプログラミングを行 うので、そのメリットは、制御手順などの手続きを明示的に指定する必要がある手続き 型プログラミングと異なり、要件を正確に実装できるということである。
[0003] しかし、宣言型プログラミングにも、実行制御の構造上、実行時の効率が良くないと いう問題がある。また、宣言型プログラミングを行うための言語は使いこなすのが難し いという欠点がある。宣言型プログラミングを行うための言語には、論理式を用いる論 理型言語 (たとえば PROLOG)や対象の状態を数学的な関数として記述する関数型 言語 (たとえば LISP)がある。宣言しただけでは値は生成されないから、値を生成す るためには、宣言型言語は、宣言を実行するための手続きの論理メカニズムを持って いる。これらの手続きの論理メカニズムには、あらゆる宣言を実行できるようにするた めに多くの条件があり、数学や論理学の知識も必要で、使いこなすのが難しい。この ために、プログラミング言語として普及していない。人間の自然言語に近い構造を持 つ手続き型言語による、手続き型プログラミングの方が普及して 、るゆえんである。 (3)オブジェクト指向プログラミング
データとそれを操作する手続き (メソッドと呼ぶ）をオブジェクトと呼ばれるひとまとま りの単位として一体ィ匕し、オブジェクトの組み合わせとしてプログラムを記述するプロ グラミング技法として、オブジェクト指向プログラミングがある。オブジェクトという独立 性の高いモジュールによってプログラムが構成されるため、変更'修正の影響の範囲 が限定され、またオブジェクトの単位で再利用がしゃすくなるなどのメリットがある。
[0004] しかし、要件を、どのような単位のオブジェクトによって実装するの力 さらに、構成 要素をどのように組み立てるかについては厳格な規則はなぐまた、構造化設計アブ ローチのような実行順序についての規制もない。実際の開発の場においては、ォブ ジェタト間の関係が完全に一貫性を持って適用されず、多くの場合、開発成果物に 大量のオブジェクトが生成されて 、ても、作成者自身を除けば誰もそれを理解して ヽ ないということになる。すなわち、完成したソフトウェアは規則性のない機能のかたまり となり、最終的に解体したり、再使用したりするのが困難になる傾向が強い。
<Lyee開発方法論 > 上述のようなソフトウェア開発の課題を解決する手段として、 Lyee (governmentaL methodologY for softwarE providencEの語尾をとつたもの。「リー」と読む。 発明者は根来文生。）と呼ばれるソフトウェア開発方法論が提案されている。 Lyeeは 、要件力もプログラムのコードを自動的に生成することが可能な新しい方法である。
[0005] Lyeeは、ソフトウェアの要件を、変数であるデータ項目（Lyeeでは単語とも呼ばれ る）ごとに宣言 (定義)し、データ項目ごとの宣言を実行するための定型構造のモジュ ールに、その宣言を代入することによってプログラムを作成する。
[0006] Lyeeによるプログラム全体は、データ項目単位の宣言を実行する定型構造のモジ ユールの集合で構成されている。従って、ツールを作成すれば、この定型構造のモジ ユールにデータ項目ごとの要件の宣言を代入し、自動的にプログラムを生成 (ソース コードを生成)することも可能である。
[0007] Lyeeによるプログラムの自動生成は、たとえば「LyeeALL」と呼ばれるツールによ つて実現されている。 LyeeALLは、データ項目の宣言を実行する定型構造モジユー ルのコード（「テンプレート」と呼ぶ。テンプレートはひな形の意。）の所定の場所に、 要件の宣言を自動的に代入し、 Lyeeにおけるプログラム設計方法に従って定型構 造モジュールを配置し、プログラム全体のソースコードを自動的に生成する。 Lyeeに おけるプログラミングでは、要件を実行する手順 (手続き）を記述する（ソースコードを 記述する）必要がなぐ要件をデータ項目単位に宣言すればよい。 Lyeeによるソフト ウェア開発は、宣言型プログラミングと言える。以下に、 Lyee開発方法論の概要を述 ベる。
1.データ項目ごとの要件の宣言
Lyee方法論では、データ項目ごとに要件を宣言するが、その要件の宣言を構成す る要素の主なものを挙げると、（1)データ項目名、（2)その値の生成式、（3)その値の生 成条件 (生成式の実行条件)、（4)入出力属性、（5)値の属性、がある。表 1は、単語の 要件の宣言の一例である。
[0008] データ項目名はデータ項目を識別するための識別子、生成式はデータ項目の値を 生成するための計算式、生成条件は生成式を実行するための実行条件である。 1つ のデータ項目が 2つ以上の生成式を持つ場合があり、そのどちらが実行されるかは、 生成条件によって決定されることになる。入出力属性はデータ項目の値が、入力され るの力、プログラムによって生成されるの力、の区別を示す。表 1では、 Iは入力、〇は 出力を表わしている。属性は、データ項目の値の属性で、たとえば、値が整数か、浮 動小数点数か、ブール値 (真偽値)かなどの区別である。表 1では、 intは整数 (intege r)、 floatは不動小数点数を表す。
ほ 1]
Figure imgf000006_0001
生成式、生成条件に用いられるデータ項目を始点と呼び、生成される出力データ 項目を端点と呼ぶことにする。
[0010] 表 1に示したデータ項目の要件の宣言は、従来のプログラミング言語のコードで表 すと表 2のようになる。 Saは、データ項目 aの宣言を意味する。
[0011] [表 2]
Figure imgf000006_0002
たとえば、データ項目 aの宣言 Saのコードは、「もし、 b*e〉2が真ならば、データ項目 a に b+cの計算結果を代入し、データ項目 aの値を出力」、を意味している。宣言 Scのコ
差替え用紙 4/1 ードは、「データ項目 cに値を入力」、を意味している。
Lyee方法論にぉレ、ては、開発者は、これらの定義が実行される順序（制御ロジック )を指定する必要はない。表 1に示すように、データ項目 aの定義は、データ項目 bを 使用しているにもかかわらず、宣言 Sbは、宣言 Saの後に位置している。 Lyeeでは、表 3に示したように要件をデータ項目ごとに宣言すれば、データ項目の宣言を実行する 順序を指定することなぐすべてのデータ項目の計算が完了するコードを生成するこ と力 sできる。
差替え用紙 (m ) 5
[0013] 従来の手続き型開発方法であれば、プログラムが要件通りに成立するためには、開 発者が Sc→Se (または Se→Sc)→Sb→Saのように実行順序を記述しなければならな！/、 。このような実行順序を決定するためには、要件が全て決定済みである必要があり、 要件が決定しなければプログラミングをスタートできな力つた。しかし、 Lyeeでは、開 発者はデータ項目の値の生成の実行順序 (制御ロジック）の問題を扱う必要がな 、の で、要件が不完全であっても、プログラミング (Lyeeにおいては要件をデータ項目ご とに宣言していく作業)をスタートすることができる。
[0014] ソフトウェアの制御ロジックは、 Lyee方法論においては、すべての要件に対応でき る普遍的ロジックとして、これも定型構造のテンプレートとして提供される。その結果、 プログラミングにおける制御ロジック上のミスがなくなる。テンプレートを用いて、ソース を自動生成するので、プログラミング時間が大幅に短縮される。柔軟性も、 Lyee方法 論の主要な利点である。何故なら、保守業務 (すなわち、要件の修正，変更）は、デ ータ項目の宣言の追加、削除および Zまたは修正という作業にまで軽減できるから である。
2.実行順序の指定を不要にする実行制御ロジック
では、 Lyeeにおいては、なぜデータ項目の宣言の実行順序を指定する必要がな いのか。 Lyeeにおいて、どのような制御ロジックによって、出力データ項目の値の生 成が要件どおりに成立することを保証しているの力。 Lyeeでは、この順序（実行手続 き）の問題を、 2通りの方法で解決している。第 1の方法は「繰り返し法」、第 2の方法 は「最適順序化法」である。
(1)繰り返し法
第 1の方法「繰り返し法」について、表 1の要件を例にとって説明する。図 1は、デー タ項目ごとの宣言を実行する実行制御ロジックを簡易に示したものである。この制御 ロジックは、実行範囲内のコードの実行結果力 不動点 (fixed point)に達するまで、 コードの実行を繰り返す。不動点とは、実行範囲のコードの実行をこれ以上繰り返し ても、 V、かなるデータ項目の値も新たに生成されなくなった状態 (変化が起こらなくな つた状態)である。不動点に達した状態を「状態変化なし」とも言う。直前の一巡実行 の結果と、今回の一巡結果を比較したとき、値の決定状態に変化がない、という意味 である。「繰り返し法」の制御ロジックは、不動点に達するまで、実行範囲のコードの 実行を単純に反復する。従って、どんな順序にデータ項目の生成を実行しても、全て の出力データ項目の値を生成することができるのである。
[0015] 不動点に達する原因は、次の 2つのケースがある。 1つは、繰り返し範囲内のデータ 項目の値が全て生成済み (決定済み）となることである。図 1の場合の値の成立過程 を表 3に示す。〇印は値が成立済みであることを示す。 X印は値が未決定であること を示す。 1回自の実行で入力データ項目 cと eの値が決定される。 2回目の実行でデ ータ項目 bの値が新たに決定される。 3回目の実行でデータ項目 aの値が決定される 。全てのデータ項目の値が決定して不動点に達するので、 4回目の実行で新たに生 成される値はない。この過程を「状態変化」で言い換えれば、 1回目終了後の状態は 初期状態と比較して「状態変化あり」、 2回目は 1回目と比較して「あり」、 3回目は 2回 目と比較して「あり」、 4回目は 3回目と比較して「なし」、となる。
[0016] [表 3]
Figure imgf000009_0001
もう 1つのケースは、レ、くら繰り返し処理をしても値が生成できないデータ項目が残 る場合である。この原因は、データ項目の生成式を構成する始点の値が、繰り返し実 行範囲内では決定されない場合である。たとえば、図 1において、データ項目 aの生 成式が b+c+dだとする。データ項目 dは、図 1の実行範囲で入力されるデータ項目で もなく、生成される出力データ項目でもなレ、。この場合の、繰り返し実行による、各デ ータ項目の値の成立過程は表 4の通りである。
[表 4]
差替え用紙 (¾IJ26) 6/1
Figure imgf000010_0001
1回目の実行で入力データ項目 cと eの値が決定される。 2回目の実行でデータ項 目 bの値が新たに決定される。 3回目の実行では、データ項目 aの生成条件は判定可
差替え用紙 (¾IJ26) 能である力 生成式は始点 dの値が未決定であるので値が決まらない。 3回目の実行 では、新たに値が決定するデータ項目がなぐ従って、データ項目 aは、これ以降は 何回実行を繰り返しても、値が成立する可能性が全く無ぐ未決定のままである。この 過程を「状態変化」で言い換えれば、 1回目終了後の状態は初期状態と比較して「状 態変化あり」、 2回目は 1回目と比較して「あり」、 3回目は 2回目と比較して「なし」。こ の 2つの事例でわかるように、「状態変化」がなしの判断は、不動点に達した後、もう 1 回実行した結果でなければ判定できな!/、。
繰り返し法では、 、つ繰り返しを停止するかが重要である。繰り返しを制御するため には、要件に依存せずに、不動点に達したことを判定するロジックが必要である。こ のような制御ロジックについては、処理速度やプログラムサイズの点からみても効率 のよ 、技術力 Sこれまでには開示されて ヽな 、。
(2)最適順序化法
最適順序化法は、順不同に並べられたデータ項目ごとの宣言を、一巡処理で成立 するように、自動的に最適順序に並べかえた実行コードを生成する方法である。並べ 替えの方法に関する技術は、特許文献 10、特許文献 11、特許文献 15において開 示されている。繰り返し法と最適順序化法は、一見対極にあるようである力 この 2つ の方法が可能になっているのは、 Lyeeにおいては、要件をデータ項目単位に要件 をとらえ、プログラムを構成するモジュールをデータ項目単位の処理を基本にしてい ることにある。繰り返し法では、最適順序の順に値が成立するので、プログラムの実行 の都度順序を探しているといってもよい。最適順序化法は、実装する前に最適順序 化して、プログラムの実行時に最適順序で実行される方法である。
3.システム、プログラムの構造
(1)システムの分割
1つのシステムは、通常いくつかの単位に分割された構造になっている。それは、 複雑な仕様の大きなシステムを分割せずに作るのは非常に困難だ力もである。分割 は、階層的に行われる。ここでは、システム (あるいはサブシステム）を分割したものを プログラム、プログラムを分割したものをモジュールと呼ぶことにする。一般的なソフト ウェア開発では、ユーザから見たシステム（画面 ·帳票や外部インタフェースなど）の 8 設計 (基本設計)が終わると、次に、それを実現するためのシステムの内部構造の設 計、システムをどのように分割するかを設計する (詳細設計'プログラム設計)。次のプ ログラミングの段階では、まず分割した単位の構造設計 (モジュール設計)を行い、最 後にプログラム言語によってソースコードの記述を行う。
1)従来の開発手法の場合
システムの分割設計手法にはいくつかの方法がある。構造化手法では、システムの 機能単位にプログラム、そしてモジュールへの分割を行う。分割されたプログラム、モ ジュールの独立性が高 ヽ（他のプログラム、モジュールとの係わり度合 、が少な 、）ほ ど、システムの品質が高いといえる。しかし、構造化手法の設計方法には厳密な設計 規則がないので、独立性の高さは設計者のスキルに依存し、一般には独立性は高く ない。独立性が低い場合、 1つのプログラム、モジュールを設計するとき、その他との 関連を理解しなければならい。モジュールを修正するときも、他のプログラム、モジュ ールに与える影響を考慮しなければならない。また、機能単位に分割する方法では、 プログラムやモジュールが行う処理は仕様に依存するので、再利用性も低 、。
[0019] オブジェクト指向は、モジュールの独立性、再利用性の問題を解決するために生ま れた手法である。モジュールは完全な独立性があり、再利用性が高い。しかし、モジ ユール (すなわちオブジェクト）の単位の定義は観念的なところがあり、オブジェクトの 設計の良し悪しは技術者のスキルに大きく依存する。また、オブジェクトの内部構造 の設計方法は規定されて 、な 、ので、その設計の良し悪しはやはり技術者のスキル に依存する。
2) Lyeeの場合
Lyeeでは、プログラムの分割の単位を、イベントごとの出力に着目して決定する。シ ステムの役割は、ユーザの求め（直接であれ間接であれ）に応じて、求められた処理 結果を出力することである。従って、プログラムは、何らかのイベント（ユーザによる画 面上のボタン押下など。イベントの定義は後述箇所参照。 )によって、イベントに対応 した一連の処理 (入力、演算、出力）を開始し、最終の出力（画面への結果の表示な ど)を完了したとき、処理を終了する。
[0020] Lyeeに基づいた本願では、システムからプログラムへの分割の基準を「イベントに 9 対応した一連の処理」とする。このことによって、プログラムは相互依存のない完全な 独立性を持ち、ソフトウェアの開発'保守における品質維持が容易になる。また、分割 基準として明快で理解しやすぐプログラム設計の良し悪しが技術者のスキルに依存 することがない。
[0021] このプログラムは、定型の制御構造を持ったモジュールで構成されている。このモジ ユールを「単位モジュール」と呼ぶことにする。この単位モジュールは、さらに、データ 項目ごとの宣言を実行するための何種類かのモジュール群によって構成されている 。これらの宣言を実行するモジュールを「要素モジュール」と呼ぶことにする。図 2は、 上述した Lyeeによるシステムの分割構造を図示したものである。
[0022] 単位モジュールは、出力に着目して要素モジュールをグループ化した単位である。
コンピュータの入出力処理は、データ項目単位ではなぐデータ項目の集合単位に 行われるが、同時に同一の媒体 (画面、ファイル、帳票など、データ項目を記録また は表示する手段）に対して入力または出力処理されるデータ項目の集合を、本願で は論理レコードと呼ぶ。 1つの出力論理レコードの生成および出力に関与する要素 モジュールの集合をとらえ、この集合を 1つ又は複数処理するのが単位モジュールで ある。
4.従来の Lyeeの構造
「繰り返し法」制御ロジックを採用した場合の、単位モジュールの構造や、各要素モ ジュールの処理内容や構造は、いくつかの実施例があり、特許文献 6、特許文献 11 、特許文献 13に開示されている。これらの従来の Lyeeでは、単位モジュールは、さ らにパレットと呼ばれる単位に 3分割されて 、た。単位モジュールが 3分割されて 、る 従来 Lyeeの実施例の 1つについて、単位モジュール、要素モジュールの概要を説 明する。
(1)単位モジュール
図 3は、単位モジュールの構造を図示したものである。単位モジュールのパレットは 、その処理の内容ごとに要素モジュールを集合させたものである。ここでいう「処理の 内容」とは、仕様に依存する機能的処理ではなぐコンピュータの基本処理である入 力、出力、演算というハードウェアの視点から見た処理ある。 Lyeeの特長は、モジュ 10
一ルイ匕を機能依存でなぐ普遍性をもったコンピュータの基本処理ごとに行ったとこ ろにある。これによつて、汎用的に適用可能なモジュールのひな型化に成功している
[0023] 3つのパレットを、それぞれ W02パレット、 W03パレット、 W04パレットと呼ぶ。 W02パ レットは、入力データ項目の入力にかかわる要素モジュールの集合である。 W03パレ ットは出力データ項目の生成式の実行条件の判定にかかわる要素モジュールの集 合である。 W04パレットは出力データ項目の値の生成（生成式の実行による）と、値の 出力にかかわる要素モジュールの集合である。
[0024] 各パレットには、パレット内の要素モジュールを起動する役割のパレット制御モジュ ールがある。パレット制御モジュール自体は、図 2に示した全体制御モジュールによ つて起動される。全体制御モジュールはプログラムに 1つ、またはシステム全体で 1つ でもよい。
(2)要素モジュール
要素モジュールは、処理の種類別にいくつかの種類があり、要件に依存しない定 型構造を持っている。ここで説明する実施例では 9種類ある。以下に、パレットごとに 、要素モジュールの概要を説明する。
< W04パレットの要素モジュール >
W04パレットは、初期化モジュール S4 (S4)、データ項目モジュール L4 (L4)、出力モ ジュール 04 (04)、経路判定モジュール R4 (R4)の 4種類の要素モジュールで構成さ れている。図 4の中ではカツコ内の略記号で示した。データ項目モジュール L4は、出 力データ項目の生成式を実行し、値を決定する。データ項目モジュール L4は出力デ ータ項目の生成式ごとに作成される。図 3は、表 1に示した要件の場合の要素モジュ ールの構成を示したものである。 L4_aは、出力データ項目 aの生成式 b+cを実行し、 L4 _bは出力データ項目 bの生成式 2*c+5を実行する。
[0025] 出力モジュール 04は、出力データ項目の値の集合（出力論理レコード)を媒体へ 出力する処理を行う。経路判定モジュール R4は、 W04パレットが不動点に達した後、 次に実行するパレットを W02に指定する。初期化モジュール S4は、単位モジュール内 の値やフラグの領域の初期化を行う。 1 1
< W02パレットの要素モジュール >
W02パレットは、入力モジュール 12 (12)、データ項目モジュール L2 (L2)、経路判定 モジュール R2 (R2)で構成されている。入力モジュール 12は、入力データ項目の値の 集合 (入力論理レコード)を、媒体からメモリ領域へ入力する処理を行う。データ項目 モジュール L2は、入力された値の属性が要件に合致するかどうかのチェックを行う。 L 2は入力データ項目ごとに 1つ作成される。経路判定モジュール R2は、 W02パレットが 不動点に達した後、次に実行するパレットを W03に指定する。
< W03パレットの要素モジュール >
W03パレットは、データ項目モジュール L3 (L3)と経路判定モジュール R3 (R3)で構 成される。データ項目モジュール L3は、出力データ項目の生成式の実行条件（生成 条件)ごとに作成され、生成条件判定を実行する。図 3の L3_aは、出力データ項目 a の生成条件 b*e〉2の判定を実行し、 L3_bは出力データ項目 bの生成条件 c〉0の判定 を実行する。経路判定モジュール R3は、 W03パレット内が不動点に達した後、次に実 行するパレットを自身の単位モジュール内の W04パレットか、または他の単位モジュ ールのパレットに指定する。
(3)要素モジュールの構造
要素モジュールはひな型化されており、処理の対象データ項目、生成式'生成条 件、入出力対象の媒体など、要件によって変化する情報を代入することによって、モ ジュールが完成する。
[0026] データ項目モジュールの場合は、図 4に示すような共通の処理フロー構造を持って いる。各要素モジュールはそれぞれ単一の処理を担当している力 その目的処理が 未完了かつ実行条件が整っているなら目的処理を実行し、実行条件が整わない、ま たは処理が完了済みであれば実行しな 、、 t 、う判定ステップを持って 、る (ステップ 41)。繰り返し法では、繰り返し時の無駄な処理を除くため、処理すべきモジュール のみを実行したい。この制御が、ステップ 41の要素モジュールの自律的自己制御に よって、実現されている。
[0027] データ項目モジュール L4_a (目的処理が出力データ項目 aの値生成）の具体例で説 明する。表 5は、図 4の処理フローに対応するデータ項目モジュール L4の処理内容 12 である。ステップ 41は、目的処理を実行するか否かを判定するステップである。第一 の判定「目的処理未完了？」は、データ項目 aの値の記録領域に値があるか否かで 判断を行う。 Lyeeでは値の記録領域の適切なタイミングで初期化を行レ、、データ項 目の値が成立したときの 1度だけ領域に値を記録するので、このような判定が可能に なる。第二の判定「実行条件成立？」は、 L4の場合、生成条件 (実行する生成式の実 行条件）が成立しているか否かで判断を行う。すなわち、 L3_a (b*e>2)が成立か否か を判定する。この 2つの判定が共に真であれば、目的処理を実行する（ステップ 42)。 目的処理は、生成式 b+cの実行である。実行結果の値は仮領域 a_tmpに記録する。次 のステップは、要件に適合した結果が得られたか否か判定する (ステップ 43)。具体 的には、仮領域 a_tmpに値があるか否かを判定する。たとえば、データ項目 cの値が 成立していな力つたとすると、生成式 b+cの実行は成功せず、 a_tmpに値は記録され なレ、。従って、ステップ 43の判定の結果、ステップ 45へ進み、再実行するかを判定 する。この判定は自パレット内で状態変化があつたか否かによって判定する。自パレ ット内の状態変化を調べて結果を制御領域に記録し、状態変化があつたのであれば 、再実行すべきなのでステップ 47に進む。ステップ 47では、自パレットのし 4群を再度 一巡実行させる旨の情報を制御領域に記録する。状態変化がなかったのであれば、 ステップ 46に進み、目的処理の結果が不成立であったことを制御領域に記録する。 ステップ 43で、目的処理が成功だと判定された場合、処理結果を確定させるために 、仮領域 a_tmpの値を領域 aにコピーする（ステップ 44)。
[表 5]
Figure imgf000016_0001
差替え用紙 12/1
(4)パレット関数の処理内容
最後に、表 6に単位モジュール内の要素モジュールの実行を制御するパレット関数 のコードを示す。表 6は、表 1の要件の単位モジュール場合であるので、図 3に対応 する。コメントはコードの意味を示している。
差替え用紙 (¾IJ26) 13
[表 6]
Figure imgf000018_0001
<用語の説明〉
■イベント
プログラミングの分野では，ユーザがコンピュータに対して行った操作という事象（マ ウスのクリックやキー押下など）やコンピュータが発するなん力 の事象（エラーメッセ —ジなど）などのことを指す。プログラムは、何らかのイベントを開始の合図として、発 生したイベントに対応した一連の処理を行レ、、処理の結果を表示したり、記録したりし た後、プログラムはアイドリング状態となる。たとえば、 Windows (商標） OS (商標）など の操作画面で、コンボボックスの右端のボタンをクリックすると、項目選択リスト（リスト ボックス）が表示される。この場合、ユーザが行った「コンボボックスの右端のボタンを クリック」がイベントで、「項目選択リスト（リストボックス）を表示」するまでの一連の処理 がイベントに対応した一連の処理である。イベントは、ュ一ザが直接行う操作に限定 されなレ、。プログラム内部に予め設定されたタイマーもイベントである。
特許文献 1：国際公開第 97 16784号パンフレット
差替え用紙 (mm 13/1 特許文献 2 :国際公開第 98Z19232号パンフレット 特許文献 3：国際公開第 99ノ 49387号パンフレット 特許文献 4 :国際公開第 00,79385号パンフレット 特許文献 5 :国際公開第 01Z35213号パンフレット 特許文献 6 :国際公開第 01 Z93026号パンフレット 特許文献 7：国際公開第 02/42904号パンフレット 特許文献 8：特開 2002— 202883号公報
差替え用紙 14 特許文献 9：国際公開第 2004Z25463号パンフレット
特許文献 10：国際公開第 2004Z68342号パンフレット
特許文献 11：国際公開第 2004Z81788号パンフレット
特許文献 12：国際公開第 2005Z29321号パンフレット
特許文献 13：国際公開第 2005Z29322号パンフレット
特許文献 14:国際公開第 2005Z29323号パンフレット
特許文献 15：国際公開第 2005Z43271号パンフレット
特許文献 16 :国際公開第 2006Z006621号パンフレット
特許文献 17 :国際公開第 2006Z025472号パンフレット
特許文献 18：国際公開第 2006Z030809号パンフレット
特許文献 19：国際公開第 2006Z035676号パンフレット
特許文献 20：国際公開第 2006Z038303号パンフレット
発明の開示
発明が解決しょうとする課題
[0030] 1.従来の Lyeeの問題点
Lyeeは、要件の正確な実装、プログラム設計の簡易ィ匕、コーディングの自動化を 実現する手段を提供することによって、新規開発および保守開発の生産性、品質の 向上を達成した。しかし、従来の Lyeeには、実行速度が遅ぐプログラムサイズが大 きいという課題があった。 Lyeeによるプログラムの構造を、その宣言的プログラミング の利点をそのままに、要件的意味を変更せずに維持しながら、不要な反復がなぐよ りサイズが小さぐ効率的処理速度のプログラムに改善することは重要な課題である。
[0031] 実行速度を向上させるための方法として、不要な繰り返し処理をなくす方法として、 プログラムの分割構造をなくし、プログラム全体の要素モジュールを最適な処理順序 に自動的に並べる方法が、特許文献 15で開示されている。また、プログラムサイズを 小さくするためのいくつかの改善も示唆されている。しかし、ここでは、各要素モジュ ールの構造およびプログラム全体がどのように制御されるしくみなのかについては、 さらに開示を充実ィ匕する余地が残されている。また、論理レコードを複数件入力また は出力する場合にどのように制御されるのかについては、さらに開示を充実ィ匕する余 15 地が残されている。
2.本願が解決する課題
本願の目的は、 Lyeeの利点をそのまま維持し、処理速度の向上とプログラムのサイ ズダウンを実現し、開発者の作業をより軽減する、繰り返し法 Lyeeの改善された技術 を提供すると共にこれを詳しく開示することである。
[0032] 本発明は、従来の繰り返し法の Lyeeに対する、以下の改善方法に関するものであ る。これらの改善により、 Lyee方法論によるソフトウェアの実行速度の向上、プロダラ ムサイズの改善、開発者の作業の軽減を実現することを目的とする。
1. ノルット分割の排除
2.要素モジュールの簡素化と種類の削減
3.要件に依存しない、効率の良い繰り返し制御
4.初期化の実行判断の改善
5.経路判定条件の簡素化'定型化
6.複数レコードの入力および出力処理制御の明確ィ匕
7.プログラム設計方法の明確ィ匕
本発明は、具体的には、上記の改善を実現させるシステム 'プログラム、処理装置、 記録媒体、プログラム生成支援装置、データ構造並びにプログラム作成方法を提供 することを目的とする。
課題を解決するための手段
[0033] 力かる課題を解決するため、システム 'プログラムとして実現される本発明は、ィベン トごとに単位プログラムを作成するプログラム設計方法にもとづいて開発する単位プ ログラムであって、前記単位プログラムは複数の単位モジュールを備え、前記単位モ ジュールは、それぞれが定型構造をもった要素モジュールである、入力データ項目 を媒体力 メモリに入力するための入力処理モジュールと、出力データ項目を生成 するための条件判定と生成式の実行を行うための出力データ生成処理モジュールと 、出力データ項目をメモリから媒体に出力するための出力処理モジュールと、前記自 身の単位モジュールが処理対象とするデータ項目の値の記録領域と、前記単位モジ ユールの制御に関わる情報の記憶領域の初期化を行うための領域初期化処理モジ 16 ユールと、前記自身の単位モジュールが不動点に達した後に実行すべき単位モジュ ールの指定及び Zまたはシステム ·プログラム終了の判定を行うための経路判定モジ ユールとを具備して構成される単位プログラムと、複数の前記単位プログラムのうち前 記経路判定モジュールの判定に従って特定の単位モジュールの起動またはシステ ム.プログラムの終了を行うための全体制御モジュールとを少なくとも備えるシステム. プログラムにおいて、前記要素モジュールの各々は、目的処理の実行条件を判定す る機能と該実行条件に合致するときに該目的処理を実行する機能とを少なくとも備え 、前記目的処理が未実行かつ実行条件が整ったときにのみ実行され、前記要素モジ ユールは、出力論理体の単位、あるいは、要件再起の再起条件が同じである単位に 集合をなして前記単位モジュールを構成し、前記集合内の前記要素モジュールの繰 り返し実行が該集合内繰り返し範囲内の状態変化によって制御され、自単位モジュ ールおよび隣接する下位の単位モジュールの状態変化と、自単位モジュールの終 了条件と、自単位モジュールの要件再起条件と、連接する下位単位モジュールの実 行状況とによって経路が判定され、前記集合の単位ごとに、イベント発生後の集合の 初期起動のときと該集合の要件再起のときとに初期化が行われることを特徴とする。
[0034] カゝかる構成を備える本発明に依れば、定型構造を持つ要素モジュールが 5種類に 限定された上に明確化され、さらにこの要素モジュールが一定の法則で集合した単 位モジュールが形成され、この単位モジュールがイベント単位で生成されるので、本 来的に余計な作業であるパレットの分割構造を排することが可能になる。したがって よりコンパクトなプログラムの実現ができる。さらにこのとき、単位モジュールの単位を 出力論理体ごと、あるいは、同じ要件再起条件を持つ出力論理体の集合ごととし初 期化モジュールの起動を単位モジュールの起動直後におくこととしたので、初期化の 実行タイミングを定型化'ルールイ匕でき、この意味での恣意性を排除できる。このため 、開発者ごとの個別性、属人性、恣意性を排除し、プログラム生成作業の共通化、ひ いては自動化が可能となるだけでなぐ開発者の作業が軽減することが可能となる。
[0035] また処理装置として実現される本発明は、請求項 1記載の前記モジュールのそれぞ れをルーチンィ匕し、該ルーチンィ匕された命令をコンピュータに実行させることを特徴 とする。 17
[0036] 力かる構成を備える本発明に依れば、上記と同様の理由により、コンパクトなプログ ラムの実現、初期化の実行タイミングの定型化'ルール化、開発者ごとの個別性 '属 人性'恣意性の排除、プログラム生成作業の共通化'自動化、開発者作業の軽減の それぞれを可能とする機能を持った処理装置が実現される。
[0037] また記録媒体として実現される本発明は、請求項 1記載のそれぞれの前記モジユー ルを含む前記システム ·プログラムを記憶させたことを特徴とする。
[0038] 力かる構成を備える本発明に依れば、上記と同様の理由により、コンパクトなプログ ラムの実現、初期化の実行タイミングの定型化'ルール化、開発者ごとの個別性 '属 人性'恣意性の排除、プログラム生成作業の共通化'自動化、開発者作業の軽減の それぞれを可能とする機能をコンピュータに果たさせ得る記憶媒体が実現される。
[0039] またプログラム生成支援装置或いはプログラム生成ツールとして実現される本発明 は、ソフトウェア開発要望からイベントを定義し、該イベントごとに単位プログラムを規 定し、前記単位プログラムにおける出力論理体を定義し、該出力論理体の要件再起 条件にしたがって単位モジュールを規定してプログラム設計 (処理経路図作成)情報 を作成することにより開発する単位プログラムと全体制御モジュールとを少なくとも備 えるシステム 'プログラムを生成するためのプログラム生成支援装置において、それぞ れが定型構造をもった要素モジュールである、入力データ項目を媒体からメモリに入 力するための入力処理モジュールと、出力データ項目を生成するための条件判定と 生成式の実行を行うための出力データ生成処理モジュールと、出力データ項目をメ モリから媒体に出力するための出力処理モジュールと、前記自身の単位モジュール が処理対象とするデータ項目の値の記録領域と前記単位モジュールの制御に関わ る情報の記憶領域の初期化を行うための領域初期化処理モジュールと、前記自身の 単位モジュールが不動点に達した後に実行すべき単位モジュールの指定及び Zま たはシステム 'プログラム終了の判定を行うための経路判定モジュールとが記録され た第 1の記憶手段と、前記作成されたプログラム設計 (処理経路図作成)情報を記憶 させる第 2の記憶手段と、前記ソフトウェア開発要望が前記イベントごとに宣言化され た宣言を記憶させる第 3の記憶手段と、前記第 3の記憶手段に記録された前記宣言 に係る情報を前記第 1の記憶手段に記録された前記要素モジュールのそれぞれの 18 所定の位置に代入する代入手段と、 前記代入手段により得られた前記宣言に係る 情報が代入された前記要素モジュールを、前記第 2の記憶手段に記録されたプログ ラム設計 (処理経路図作成)情報に基づ 、て所望のプログラムを構成するように配置 する手段とを少なくとも備え、前記要素モジュールの各々は、目的処理の実行条件を 判定する機能と該実行条件に合致するときに該目的処理を実行する機能とを少なく とも備え、前記目的処理が未実行かつ実行条件が整ったときにのみ実行され、前記 要素モジュールは、出力論理体の単位、あるいは、要件再起の再起条件が同じであ る単位に集合をなして前記単位モジュールを構成し、前記集合内の前記要素モジュ ールの繰り返し実行が該集合内繰り返し範囲内の状態変化によって制御され、自単 位モジュールおよび隣接する下位の単位モジュールの状態変化と、自単位モジユー ルの終了条件と、自単位モジュールの要件再起条件と、連接する下位単位モジユー ルの実行状況とによって経路が判定され、前記集合の単位ごとに、イベント発生後の 集合の初期起動のときと該集合の要件再起のときとに初期化が行われることを特徴と する。
ここで、「宣言に係る情報」とは、宣言を中間言語ィ匕した情報そのものでもよいし、或 いは、かかる宣言を中間言語ィ匕したものを所望のプログラミング言語に変換して得ら れる情報でもよい。また、「第 1の記憶手段」乃至「第 3の記憶手段」とは、情報を少な くとも一時的に記憶もしくは格納できる領域を 、、対応する構造体としては具体的 には、たとえばコンピュータ内部のメモリ領域或いはコンピュータ外部のメモリ領域が 該当する。また、「代入手段」とは、当該宣言に係る情報を要素モジュールのそれぞ れの所定の (空欄)位置に代入するための機能をいい、対応する構造体としては具 体的には、たとえば当該機能をコンピュータに実行させるための命令文、或いは当該 命令文を搭載'実行するコンピュータ (汎用コンピュータを当該機能を実行させるため に用いることで専用コンピュータ化する場合を含む)が該当する。また、「配置する手 段」とは、当該要素モジュールを、開発要望を反映した処理経路図情報に基づいて 構成するように配置するための機能をいい、対応する構造体としては具体的には、た とえば当該機能をコンピュータに実行させるための命令文、或いは当該命令文を搭 載'実行するコンピュータ (汎用コンピュータを当該機能を実行させるために用いるこ 19 とで専用コンピュータ化する場合を含む）が該当する。
[0041] カゝかる構成を備える本発明に依れば、定型構造を持つ要素モジュールが 5種類に 限定された上に明確化され、さらにこの要素モジュールが一定の法則で集合した単 位モジュールが形成され、この単位モジュールがイベント単位で生成されるので、ノ レットの分割構造を排したよりコンパクトなプログラムを生成するためのプログラム生成 支援装置或いはプログラム生成ツールが実現される。さらに、単位モジュールの単位 を出力論理体ごと、あるいは、同じ要件再起条件を持つ出力論理体の集合ごととし 初期化モジュールの起動を単位モジュールの起動直後におくこととしたので、初期 化の実行タイミングを定型化'ルールイ匕できるので、プログラム開発者にとっての判断 業務、設計業務を軽減し、より効率的なプログラム開発業務を実現する。
[0042] また、データ構造或いはプログラムの雛型として実現される本発明は、ソフトウェア 開発要望からイベントを定義し、該イベントごとに単位プログラムを規定し、前記単位 プログラムにおける出力論理体を定義し、該出力論理体の要件再起条件にしたがつ て単位モジュールを規定してプログラム設計 (処理経路図作成)情報を作成すること により、開発する単位プログラムと全体制御モジュールとを少なくとも備え、前記単位 プログラムは複数の単位モジュールを備えるシステム .プログラムを生成するために 用いられるモジュールとしてのデータ構造であって、該データ構造は、入力データ項 目を媒体力 メモリに入力するための入力処理モジュールであって、要件に対応した 宣言を入力するための欄を備えた定型構造をもった入力処理モジュールと、出力デ ータ項目を生成するための条件判定と生成式の実行を行うための出力データ生成処 理モジュールであって、要件に対応した宣言を入力するための欄を備えた定型構造 をもった出力データ生成処理モジュールと、出力データ項目をメモリから媒体に出力 するための出力処理モジュールであって、要件に対応した宣言を入力するための欄 を備えた定型構造をもった出力処理モジュールと、前記自身の単位モジュールが処 理対象とするデータ項目の値の記録領域と、前記単位モジュールの制御に関わる情 報の記憶領域の初期化を行うための領域初期化処理モジュールであって、要件に 対応した宣言を入力するための欄を備えた定型構造をもった領域初期化処理モジュ ールと、前記自身の単位モジュールが不動点に達した後に実行すべき単位モジユー 20 ルの指定及び zまたはシステム ·プログラム終了の判定を行うための経路判定モジュ ールであって、要件に対応した宣言を入力するための欄を備えた定型構造をもった 経路判定モジュールとを要素モジュールとして具備し、さらに、前記ソフトウェア開発 要望が前記イベントごとに宣言化された宣言に係る情報を前記要素モジュールに代 入し、該宣言に係る情報が代入された前記要素モジュールを前記作成されたプログ ラム設計 (処理経路図作成)情報に基づいて配置するにあたり、前記配置された前記 要素モジュールの前記単位モジュール内での起動及び zまたは再起の判定を行う ための単位制御モジュールと、複数の前記単位プログラムのうち前記経路判定モジ ユールの判定に従って特定の単位モジュールの起動またはシステム.プログラムの終 了を行うための全体制御モジュールとを具備して構成されるデータ構造であって、前 記要素モジュールの各々は、目的処理の実行条件を判定する機能と該実行条件に 合致するときに該目的処理を実行する機能とを少なくとも備え、前記目的処理が未実 行かつ実行条件が整ったときにのみ実行され、前記要素モジュールは、出力論理体 の単位、あるいは、要件再起の再起条件が同じである単位に集合をなして前記単位 モジュールを構成し、前記集合内の前記要素モジュールの繰り返し実行が該集合内 繰り返し範囲内の状態変化によって制御され、自単位モジュールおよび隣接する下 位の単位モジュールの状態変化と、自単位モジュールの終了条件と、自単位モジュ ールの要件再起条件と、連接する下位単位モジュールの実行状況とによって経路が 判定され、前記集合の単位ごとに、イベント発生後の集合の初期起動のときと該集合 の要件再起のときとに初期化が行われることを特徴とする。
[0043] ここで、「宣言に係る情報」とは、宣言を中間言語ィ匕した情報そのものでもよいし、或 いは、かかる宣言を中間言語ィ匕したものを所望のプログラミング言語に変換して得ら れる情報でもよい。
[0044] かかる構成を備える本発明に依れば、データ構造或いはプログラムの雛型として、 テンプレート化され定型構造をもったものに、開発要望を宣言化した情報を代入する ことで所望プログラムが得られることになるので、プログラム開発業務の大幅な改善を 実現する。
[0045] また、プログラム作成方法として実現される本発明は、ソフトウェア開発要望カもィ 21 ベントを定義し、該イベントごとに単位プログラムを規定し、前記単位プログラムにお ける出力論理体を定義し、該出力論理体の要件再起条件にしたがって単位モジユー ルを規定してプログラム設計 (処理経路図作成)するステップと、前記ソフトウェア開 発要望を前記イベントごとに宣言化するステップと、前記単位モジュールを構成する 、それぞれが定型構造をもった要素モジュールの雛型に前記宣言化した要件情報を 代入するステップであって、前記要素モジュールは、入力データ項目を媒体からメモ リに入力するための入力処理モジュールと、出力データ項目を生成するための条件 判定と生成式の実行を行うための出力データ生成処理モジュールと、出力データ項 目をメモリから媒体に出力するための出力処理モジュールと、前記自身の単位モジュ ールが処理対象とするデータ項目の値の記録領域と、前記単位モジュールの制御 に関わる情報の記憶領域の初期化を行うための領域初期化処理モジュールと、前記 自身の単位モジュールが不動点に達した後に実行すべき単位モジュールの指定及 び Zまたはシステム ·プログラム終了の判定を行うための経路判定モジュールである ステップと、複数の前記単位プログラムごとに、前記経路判定モジュールの判定に従 つて特定の単位モジュールの起動またはシステム 'プログラムの終了を行うための全 体制御モジュールを規定するステップとを具備することを特徴とする。
[0046] 力かる構成を備える本発明に依れば、定型構造をもった要素モジュール '制御モジ ユールを用いる上に、各モジュールの構成方法、作業ステップがルール化できるので 、プログラム開発にこれまでつきものだった開発者依存性を排除することが可能とな る。
[0047] また、本発明は、プログラム作成方法として実現するに際し、ソフトウエア開発要望 からイベントを定義し、該イベントごとに単位プログラムを規定し、前記単位プログラム における出力論理体を定義し、該出力論理体の要件再起条件にしたがって単位モ ジュールを規定してプログラム設計 (処理経路図作成)するステップと、前記ソフトゥェ ァ開発要望を前記イベントごとに宣言化するステップと、請求項 5で生成されたプログ ラムの雛型としてのデータ構造の空欄に、前記宣言化した要件情報を代入するステ ップとを具備するように構成しても良 、。
[0048] 総じて、本発明によれば、要素モジュール '単位モジュール '単位プログラムの上述 22 したような設定'把握、再起を要件再起と非要件再起にわけ要素モジュール '制御モ ジュールにお 、て再起させる範囲を明確ィ匕したこと、初期化モジュールの実行タイミ ングをルールイ匕したことにより、パレット分割の排除、要素モジュールの簡素化と種類 の削減、要件に依存しない、効率の良い繰り返し制御、初期化の実行判断の改善、 経路判定条件の簡素化'定型化、複数レコードの入力および出力処理制御の明確 ィ匕、プログラム設計方法の明確ィ匕が実現される。
発明の効果
[0049] 本発明によれば、要素モジュール力もなるプログラムの実行における、ソフトウェア の実行速度の向上、プログラムサイズの改善、開発者の作業の軽減が可能になる。 発明を実施するための最良の形態
[0050] 本発明は、従来の繰り返し法の Lyeeに対する以下の改善方法に関するものである 。本発明によって、 Lyee方法論によって開発されるソフトウェアの実行速度の向上、 プログラムサイズの改善、開発工程における開発者の作業の軽減を実現する。以下 、図面を参照しながら、本願の発明の具体的な実施形態について説明する。なお、 以下では、処理フローを表、フローチャート及びことばで説明するが、コードを示さな い。これらの情報を、たとえば VisualBasic (商標）などのプログラミング言語をもって 実現することは容易であり、これをプログラムとして、或いはこのプログラムが搭載され た汎用もしくは専用コンピュータ或いは構造体として、或いはこのプログラムを専用的 に実行する処理装置として、或いはこのプログラムが記録された記録媒体として、ま たは、これらを実施する方法として、それぞれ本願発明を捉えることが可能であり、本 願発明は、このような実施形態の総てを包含するものである。また、いわゆる当業者 であれば、処理フローの表、フローチャート及び対応する詳細な説明を読むことによ り、発明をどうやって実施するかを十分理解できるからである。したがって、本明細書 及び図面の開示は、当業者が発明を実施するのに十分なものである。
1.モジュールの概要
本願の改善を行った Lyeeプログラムを構成するモジュールにつ 、て、概要と改善 のポイントを説明する。本願では、単位モジュールは、パレットの分割がない構造で、 以下の 2種類の制御モジュールと 5種類の要素モジュールによって構成される。 23
(1)全体制御モジュール Ψ
全体制御モジュール Ψは、プログラムごとに 1つ、又は、システムに 1つ作成する。 その役割は、経路判定モジュール Rの判定に従って、次に起動する単位モジュール の単位制御モジュール Φを起動する、またはプログラムの終了を行うことである。
(2)単位制御モジュール Φ
単位モジュールごとに 1つ作成する。単位モジュール内の要素モジュールの起動、 再起の判定を行う。詳細は後述する。
(3)要素モジュール
要素モジュールには以下の 5種類がある。（a)(b)(c)は、入力、生成、出力という、プロ グラムの基本処理に関わるモジュールで、（d)(e)は、実行順序の制御のために必要な モジュールである。これら 5つの処理は、他の処理と統合されて 1つのモジュールとし て実装されない。
(a)入力モジュール I
入力データ項目の集合 (入力論理レコード)を媒体からメモリへ入力する。入力論 理レコードごとに作成する。
(b)生成モジュール L
出力データ項目の生成条件判定と生成式を実行し、出力データ項目の値を生成 する。出力データ項目ごとに作成する。出力データ項目が複数の生成式を持つ場合 は、生成式ごとに作成する方がよい。本願では、生成式ごとに作成する場合を説明 する。
(c)出力モジユーノレ O
出力データ項目の集合（出力論理レコード)をメモリから媒体へ出力する。
(d)初期化モジュール S
単位モジュール内の値やフラグの領域の初期化を行う。プログラムとは、何度も使 い回しをするものである。一度出力という最終目的を終了したなら、新たな処理のラウ ンドを開始するために領域を初期状態に戻す必要がある。上書きでは、領域に記録 された値やプログラムの実行制御情報力 今回ラウンドのものであるかどうかが保証さ れないからである。 24
(e)経路判定モジュール
自身の単位モジュールが不動点に達した後、次に実行する単位モジュールや、プ ログラム終了の判定を行う。経路は以下のケースがある。
(0自プログラムを終了、または、終了して他のプログラムを実行。
(ii)下位の単位モジュールを実行する。
Gii)
上位の単位モジュールを実行する。
(vi)
自単位モジュールを再起する（要件再起：要件から必然化される再起)。
2.入力、生成、出力のモジュール
最初に、プログラムの基本処理に関わる入力、生成、出力のモジュールについて、 処理フローを示しながら説明する。
[0051] 入力モジュール Iの本質は、生成が行われるメモリ領域に、メモリ外の媒体から入力 された入力データを移すことである。入力データに対して行う付随的処理に、値の属 性のチェック、値が定義域内であるかのチェック（たとえば、数量という入力データ項 目であれば定義域は「nullでない」など）、属性変換などがある。これらの処理は、入 力モジュール Iで行うように実装しても、生成モジュール Lで行うように実装してもよぐ データベースなどシステムの実行環境を考慮するなど、最適な方法で実装すればよ い。また、入力処理時に行うべきその他の付随処理 (ファイルのオープンなど）は、特 に明記しないが、入力処理に含まれるものとする。
[0052] 出力モジュール Oの本質は、メモリ領域に記録された生成結果である出力データを 、メモリ外の媒体へ移すことである。出力データに対して行う付随的処理に、値の編 集 (数値へのカンマ付けなど）があるが、これは生成モジュール Lで行うように実装し ても、出力モジュール Oで行うように実装してもよい。また、出力処理時に行うべきそ の他の付随処理（ファイルのクローズや、ロールバックなど）は、特に明記しないが、 出力処理に含まれるものとする。
[0053] 生成モジュール Lの本質は、メモリ領域内の入力データを用いて、要件で指定され た演算を行 、、演算結果をメモリ内に記録することである。 25
(1)生成モジュール L
生成モジュール Lの処理フローは、図 5のようになる。生成モジュール Lの役割は、 出力データ項目の値の生成である。ステップ 1は、目的処理を実行すべきか判定す るステップである。実行条件は 3つあり、第 1の条件は目的処理が未完了であること。 繰り返し法であれば不要な処理実行を排除するために不可欠な判定で、従来 Lyee と同じであるが、本願では、判定方法のノリエーシヨンとして別の方法を示す。本願で は、要素モジュールの目的処理完了は、完了を記録するための領域をもうける。領域 の初期値は未完了を示す値で、要素モジュールが自身の目的処理を完了したときに 、完了を示す値を記録する。目的処理完了領域は要素モジュールごとに設けられる 。生成モジュールの場合のこの領域を生成完了領域と呼ぶ。第 2の条件は、生成条 件と生成式の始点の値が全て決定して 、ることである。この第 2条件を加えることで、 目的処理実行は必ず成立する場合にのみ実行されることになる。第 3の条件は、生 成条件が成立していることである。第 3の条件が必要なのは、出力データ項目が複数 の生成式を持つ場合である。生成式ごとに定められた生成条件のうち 1つだけが成 立し、対応する生成式が実行され、出力データ項目の値が 1つ決まる。生成式が複 数あっても生成した値を記録する領域は 1つである。値が成立した後は、他の生成式 の Lは第 1の実行条件が満たされないので、ステップ 1のみで終了する。
[0054] ステップ 1の判定で、 3つの実行条件が共に満たされた場合のみ、ステップ 2を実行 する。いずれか 1つの条件でも満たされない場合は、生成モジュール Lは終了する。 このとき、生成完了領域の値は初期値のままで、未完了を示している。ステップ 2は目 的処理の実行である。生成モジュール Lでは、生成式を実行し、生成モジュール の 記録領域に値を記録する。
[0055] ステップ 3では 3つの処理を行う。 1つは上述の生成完了領域の値を変更し、目的 処理が完了したことを記録する。もう 1つの処理は、生成モジュール群を再度実行さ せる力否かの判定に用いる状態変化 X領域に「状態変化あり」を示す値を記録する。 状態変化 X領域は、単位モジュールに 1つ設け、初期値は「状態変化なし」を示す値 である。この状態変化 X領域を用いた非要件再起 (要件によらな 、再起)の判断方法 は後述する。 26
[0056] さらにもう 1つの処理は、出力データ項目の値が決定したので、状態変化 Y領域に「 状態変化あり」を示す値を記録する。この状態変化 Y領域は、入力モジュール I群、生 成モジュール L群、出力モジュール O群の範囲を繰り返し実行するか否かの判定に 用いる。初期値は「状態変化なし」を示す値である。状態変化 Y領域を用いた非要件 再起の判断方法は後述する。
[0057] 生成モジュール Lを、「購入金額計算」システムの例を用いて具体的に説明する。 Γ 購入金額計算」システムは図 6に示す画面を持ったシステムである。この画面は、入 力データ項目「商品名」に商品名、「購入数量」に商品を購入する数を入力し、「計算 表示」ボタンを押下すると、出力データ項目「単価」に指定した商品の単価力 「割引 率」に当該商品を指定した数量購入した場合の割引率が、「購入金額」に購入金額 が表示される。このシステムの業務要件をまとめると表 7のようになる。
[0058] [表 7]
Figure imgf000032_0001
図 5に対応させて、出力データ項目「購入金額」の生成モジュール Lの処理フロー の具体例を示すと、表 8になる。
[0059] [表 8]
差替え用紙 m 26/1
Figure imgf000033_0001
図 5に対応させて、出力データ項目「単価」の生成モジュール Lの処理フローの具 体例を示すと、表 9になる。
[表 9]
差替え用紙 ( U6) 27
Figure imgf000034_0001
図 5に対応させて、出力データ項目「割引率」の生成モジュール Lの処理フローの 具体例を示すと、表 10と表 11になる。出力データ項目「割引率」は、条件によって生 成式が異なる。このような出力データ項目の場合、生成モジュール Lを生成式ごとに 作成する場合と、出力データ項目に対して 1つ作成する方法がある。本願で説明した 生成モジュール Lの処理フローは、生成式ごとに作成する場合の実装方法を説明し ている。
[表 10]
Figure imgf000034_0002
[表 11] 差替え用紙 (¾IJ26) 27/1
Figure imgf000035_0001
(2)入力モジュール I
入力モジュール Iの処理フローは、図 7のようになる。入力モジュール Iの役割は、入 力データ項目を媒体からメモリ上に入力することである。ステップ 71は、 目的処理を 実施すべきか判定するステップである。実行条件は 2つあり、第 1の条件は目的処理 が未完了であること。生成モジュール Lの場合と同様で、入力モジュール Iごとに設け られた入力実行済み領域の値の状態で判定する。第 2の条件は、入力もとの媒体が ファイルの場合のみ必要な条件である。ファイル力 入力するためには、 目的のデ一 タを検索するための参照キ一となるデータ項目の値が必要である。キー項目の値が 決定済みかを判定する。ステップ 71の判定で、 2つの実行条件が共に満たされた場
差替え用紙 (¾IJ26) 28 合のみ (入力もとが画面の場合は第 1の条件が満たされた場合)、ステップ 72を実行 する。条件が満たされない場合 (ステップ 71で Noの場合）は、入力モジュール Iは終 了する。このとき、入力完了領域の値は初期値である未完了を示す値のままである。
[0063] ステップ 72は目的処理の実行である。入力モジュール Iの目的処理は媒体からの 入力データ項目群の入力である。入力もとがファイルの場合は、 SQLなどで記述した 命令を実行することになる。このとき、前述の参照キー項目の値が必要となる。入力を 実行した後、オペレーションシステムなどが返す入力処理の結果情報を記録する。ま た、入力実行済み領域に入力実行済みを示す値を記録する。
[0064] ステップ 73は、入力が正常に完了したかを判定する。ステップ 72で記録した入力 処理の結果情報によって判定する。入力が正常に完了した場合は、ステップ 75に進 む。正常に完了しな力つた場合は、ステップ 76に進み、入力エラー領域に入力が正 常完了しな力つたことを示す値を記録する。
[0065] ステップ 75は、入力が正常に完了したことを記録するステップである。 1つは、入力 データ項目ごとにもうけられる入力完了領域に、入力データ項目の値が決定したこと を示す値を記録する。もう 1つは、入力データ項目の値が決定したので、状態変化 Y 領域に「状態変化あり」を示す値を記録する。この状態変化 Y領域を用いた非要件再 起の判断方法は後述する。図 7の処理フローを、前述の「購入金額計算」システムの 入力の具体例で説明する。「購入金額計算」システムの、「計算表示」ボタンのィベン トに対応する処理プログラムでは、 2つの入力論理レコードがある。 1つは「購入金額 計算」画面からの入力で、入力データ項目は「商品名」と「購入数量」である。もう 1つ は商品マスタ力もの入力で、入力データ項目は、「単価 _DB」である。それぞれの入力 論理レコードの入力モジュール Iは表 12、表 13のようになる。
[0066] [表 12] 29 [：
Figure imgf000037_0001
(3)出力モジュール〇
出力モジュール Oの処理フローは、図 8のようになる。出力モジュール Oの役割は 差替え用鉞 (m ) 29/1 出力データ項目をメモリ上にから媒体へ出力することである。ステップ 81は、目的処 理を実施すべきか判定するステップである。実行条件は 3つあり、第 1の条件は、出 力対象の出力論理レコードに属す出力データ項目が全て生成完了であること (業務 要件で別に定められている場合を除く）。第 2の条件は、出力が、ファイルへの更新ま たは削除である場合に、更新または削除対象の項目を検索するためのキー項目の 値が決定していること。第 3の条件は、業務要件で定められた出力条件がある場合に 、この条件に合致していることである。出力処理の場合は繰り返し処理がないので、 目的処理が未完了であるか否かは実行条件にする必要がなレ、。ステップ 81の判定 で、これらの実施条件が満たされた場合に、ステップ 82へ進む。条件が満たされない 場合は、出力モジュール〇は終了する。
ステップ 82は目的処理の実行である。出力モジュール Oの目的処理は、媒体への 出力データ項目群の出力である。出力先がファイルの場合は、 SQLなどで記述した
差替え用紙 (¾IJ26) 30
命令を実行することになる。このとき、前述の参照キー項目の値が必要となる。出力を 実行した後、オペレーションシステムなどが返す出力処理の結果情報を記録する。
[0069] ステップ 83は、入力が正常に完了したかを判定する。ステップ 82で記録した出力 処理結果情報によって判定する。出力が正常に完了した場合は、ステップ 84に進む 。正常に完了しなかった場合は、ステップ 85に進み、出力エラー領域に出力が正常 完了しな力 たことを示す値を記録する。ステップ 84では、出力が正常に完了したの で、出力完了を記録する。
[0070] 図 8の処理フローを、前述の「購入金額計算」システムの出力の具体例で説明する 。 「購入金額計算」システムの、「計算表示」ボタンのイベントに対応する処理プロダラ ムでは、出力論理レコードは 1つで、 「購入金額計算」画面への出力である。出力デ ータ項目は「単価」「割引率」「購入金額」である。出力論理レコードの出力モジュール 〇は表 14のようになる。
[0071] [表 14]
Figure imgf000039_0001
3.単位モジュ一ゾレの処理フロー
単位モジュール内の要素モジュールの実行がどのように制御されてレ、るかを説明 する。実行制御を行う単位制御モジュール Φの処理フローは図 9に示すとおりである 。最初に Φが起動するのは、初期化モジュール Sである。前述の通り、イベント発生後
差替え用弒 (MIJ26) 30/1 の、単位モジュールの最初の実行時には、データ項目の値および制御情報の領域 を初期化する必要がある（ステップ 8101)。初期化モジュール Sの処理フローについ ては、後述する。次に、入力モジュール I群を順次起動する（ステップ 8102)。単位モ ジュールの最終目的である出力のために必要な入力論理レコードの入力を行うため である。入力モジュール I群の起動順序は不問である。たとえば、ファイルからの入力 である論理レコード A力 論理レコード Bの入力値をキーとして用いる場合、論理レコ
差替え用紙 (WU6) 31 ード Aの入力が最初に実行された場合、論理レコード Bの入力は実行できない。ある いは、ファイルからの入力である論理レコード Cのキー力 生成の結果得られる出力 データである場合も入力が実行できない。このような完了されない入力は、繰り返し 実行 (要件が指定する再起ではな ヽ「非要件再起」 )によって解決する。
[0072] 全ての入力モジュール Iが起動されたら、次に生成モジュール L群を起動する（ステ ップ 8103)。生成モジュール L群の起動順序も不問である。 L群の起動は、状態変化 がなくなるまで繰り返される (ステップ 8104)。この場合の状態変化の対象となる範囲 は、点線 Xで示した範囲である。範囲 Xの状態変化を判定するために、状態変化を記 録する制御情報領域を 1つ設け、これを状態変化 X領域と呼ぶ。値が成立した生成 モジュール Lは、状態変化 X領域に状態変化があったことを記録する。この領域への 記録は上書きである。 L群のうち 1つでも新たに値が成立すれば、「状態変化あり」、と なる。「状態変化あり」、と判定される間は、新たに Lの値が成立する可能性があるの で、 L群の一巡実行が繰り返される。 L群の一巡実行を開始する直前に、状態変化 X 領域を毎回初期化し、状態変化情報が、常に直前に実行された一巡処理の結果を 表すようにする。
[0073] 範囲 Xの状態変化がなくなったとき、出力モジュール 0群を順次起動する (ステップ 8105)。 0群の起動順序も不問である。入力や生成が完了しな力つた場合、出力が 完了しない 0がある。これも非要件再起によって解決する。
[0074] 全ての 0群が起動されたら、点線 Yで示した範囲 (入力から出力までの範囲）の一巡 実行を繰り返すか否力判定する (ステップ 8106)。判定は、範囲 Yの状態変化によつ て行う。範囲 Yの状態変化を記録する制御情報領域を 1つ設け、これを状態変化 Y領 域と呼ぶ。値が成立した入力モジュール Iおよび生成モジュール Lは、状態変化 Y領 域に状態変化があったことを記録する。この領域への記録は上書きである。 I群およ び L群のうち 1つでも新たに値が成立すれば、「状態変化あり」、となる。「状態変化あ り」、と判定される間は、新たに I、 Lの値が成立、 0が完了する可能性があるので、 I群 、 L群、 0群の一巡は繰り返される。範囲 Yの一巡実行を開始する直前に、状態変化 Y 領域を毎回初期化し、状態変化情報が常に直前に実行された一巡処理の結果を表 すようにする。 32
[0075] 範囲 Yの状態変化がなくなったとき、経路判定モジュール群を順次起動する。前述 のように、経路は以下の 4種類ある。
(0自プログラムを終了、または、終了して他のプログラムを実行。
(ii)下位の単位モジュールを実行する。
Gii)
上位の単位モジュールを実行する。
(vi)
自単位モジュールを再起する（要件再起)。
[0076] 経路判定モジュール Rは、各経路の種別ごとに 1つ作成する。 4種類の経路は、そ れぞれの経路が選択される条件が定まっており、どれ力 1つの経路のみが成立する。 経路判定モジュール R群を順次起動すると、経路条件に合致した Rが、次に実行す べき単位モジュールの識別子を経路領域に記録する。単位制御モジュール Φは終 了し、全体制御モジュール Ψは、経路領域に指定された単位モジュールの単位制御 モジュール Φを起動する。経路判定モジュール R群の処理フローおよび各経路につ いては、詳しくは後述する。
[0077] 以上のように、パレットに分割しない単位モジュールでは、パレットごとに繰り返すパ レット分割構造に比べ、順序不問に実行される要素モジュールの要件再起回数を削 減することができる。
[0078] さらに繰り返し回数を削減させるために、 I群、 L群、 O群を、それぞれの群ことにトポ ロジカルソート（トポロジカルソートについては、特許文献 10、特許文献 15を参照）し てもよい。さらには、 I群、 L群、 O群を総合してトポロジカルソートしてもよい。この場合 は、状態変化の記録および判定は Yの範囲のみになる。
4.経路判定モジュール R
(l) Lyeeのプログラム設計
経路の種別と種別ごとの経路判定モジュール Rについて説明する力 その前に、前 提となる本発明の Lyeeにおけるプログラム設計方法について再度説明する。経路と プログラム設計方法は、相互に依存した関係があるからである。本発明の Lyeeのプ ログラム設計 (処理経路図作成)方法は、特許文献 17に詳述された方法に基づく。そ 33 の要点を言えば、プログラムをイベント単位に作ること、プログラムの構成単位である 単位モジュールを出力論理レコードの単位に基づいて作ること、である。本願 Lyee のプログラム設計図の 1つの例は、図 10のように表すことができる。単位モジュール の配置と単位モジュールをつなぐ線は、単位モジュールが起動される順番と経路を 表している。線によって直接連結された単位モジュール間（隣接する単位モジュール 間）で実行が遷移する。隣接する単位モジュールにおいて、右方向に隣接する単位 モジュールを下位にあると言い、左方向に隣接する単位モジュールを上位にあると言 う。上位下位の関係を親子とも呼ぶ。垂直方向に隣接している単位モジュールは並 列関係にあると言い、兄弟関係とも呼ぶ。
[0079] 起動される順序と経路は、左端 (最上位)を基点として、左から右へ順次起動され、 右力も順に出力が完了しながら、左端に戻る。並列関係にある単位モジュールへは、 直接遷移することはなぐー且上位へ戻ってから遷移する。図 10で示せば、 8201→ 8202→8203→8202→8201→8204→8201→8205の川頁になる。最後に出力力 S 成立するのは、左端のモジュールで、オンラインシステムでは、画面への出力を行う 単位モジュールが左端におかれる。
[0080] 上下の関係となる単位モジュールは、 2つの単位モジュールに属すデータ項目の いずれかの間に、端点始点の関係がある。端点始点関係のある単位モジュールは上 下に隣接させる。端点始点関係のない単位モジュールは、通常並列関係におく。
[0081] ファイルの入出力は、複数レコード分処理される場合がある。複数レコードの処理 の場合は、単位モジュールを複数回再起させて対応する。従来法でも、プログラムの 中でループやサブルーチンの再起呼び出しがあるのは、複数レコード処理の場合で ある。本願 Lyeeでは、複数件処理する範囲を単位モジュールにおいて処理する。こ の複数件処理の単位も、出力論理レコード単位という同じ基準でとらえることができる
[0082] 単位モジュールを、出力論理レコードごとに作成しても良いが、その場合、プロダラ ムの分割単位が必要以上に多くなる。繰り返し法の場合、分割単位が多いということ は、非要件再起の回数が増えることになる。要件再起がない出力論理レコードの集 合、要件再起が同じ条件である出力論理レコードの集合は、それぞれの集合を 1つ 34 の単位モジュールに作るようにすれば、非要件再起の回数がより少ない、効率よぃプ ログラムを作成することができる。たとえば、画面に 2つの明細表示があり、 1つは 10 件表示、もう 1つは 20件表示だとする。この場合、 10件表示の出力論理レコードと 20 件表示の出力論理レコードは、別の単位モジュールとして作成する。ただし、画面へ の出力は、他の 1件出力の出力論理レコードと同じ単位モジュールとはせず、通常独 立した 1つの単位モジュールとして作成し、最後に出力を行うので、処理経路図の最 上位の位置 (左端）におく。
[0083] 複数件処理の具体例を上げると、図 11の「注文状況照会」画面の場合がある。この 画面では、顧客コード（8301)を入力した後、コンボボックス（8302)のリストから表示 したい年月を選択すると、指定した顧客名が表示され (8303)、注文状況データの明 細が注文番号ごとに表示される（8304)。この処理のイベントは、コンボボックスのリス ト選択で、画面からの入力データは、顧客コードと選択された年月である。ファイルか らの入力データは、顧客名（たとえば顧客マスタから）と注文状況データ (たとえば注 文ファイルから）である。画面への出力データは、顧客名と注文状況データである。フ アイルへの出力はない。この処理では、顧客名は 1件処理である力 注文状況データ は、複数件処理になる。
[0084] この処理の処理経路図を描くと、図 12になる。単位モジュール 8401で、画面のデ ータが入力される。出力データが生成されていないので、次に 8402が起動され、顧 客コードを参照キーとして、顧客マスタカゝら顧客名を入力し (顧客名ファイル）、画面 に出力するためのデータ項目を生成し (顧客名 _画面 =顧客名ファイル）、出力する 。次に、ー且 8401に戻り、まだ画面に出力するデータがそろわないので、 8401から 、未実行の 8403が起動される。 8403では、顧客コードと年月を参照キーとして注文 ファイルから注文状況データを 1レコードずつ入力し、 1レコードずつ画面出力データ を生成する。参照条件に合致するレコード全てを入力、生成、出力し終わるまで、 84 03は要件再起する。 8403が全ての該当レコードの生成、出力を完了すると、 8401 に戻る。 8401では、 8402および 8403で画面に出力するデータの生成が完了して いるので、それらのデータを画面へ出力し、 8405へ遷移してプログラムを終了する。 (2)経路の選択条件 35 上述の処理経路図の設計方法によるプログラムでは、単位モジュール間の実行遷 移の経路は、表 15のような条件によって決まる。経路番号は、経路判定モジュール R が実行される順番を表している。すなわち、経路 1を担当する経路判定モジュール R 1が最初に起動される。表 15の中で、「自身」とは経路判定モジュールが所属してい る単位モジュールを指す。「下位」とは、「自身」に隣接する下位の単位モジュールで ある。「上位」とは、「自身」に隣接する上位の単位モジュールである。
[表 15]
Figure imgf000045_0001
経路 1は、通常上位がない単位モジュール (最上位）に置かれる。要件で特に指定 されない限り、通常はイベントの処理が全て終わったときに終了するので、最後に出 力が完了する最上位におくのである。終了処理に遷移しない単位モジュールにはお く必要がない。経路 2の実行条件の説明中にある、下位が「未実行」とは、 1つは下位 がまだ初期起動していないときである。もう 1つは、下位から自身に戻ってきたあと、 自身が要件再起した場合である。上下関係にあるのは、相互のデータが端点始点関 係にある力 である。ではなぜ分割されてレ、る力といえば、相互の出力論理レコード の要件再起条件が異なる、あるいは一方が 1件処理の場合だからである。上下関係 は、要件再起の条件が異なるだけで（1件処理は要件再起の条件力 a件とみなせる）
差替え用紙 (¾IJ26) 35/1
、同じラウンドに属している（上位が下位のラウンドを内包している）。つまり、両者の データ項目を端点始点関係によってつなげは、途切れのないネットワークが成立す る集合である。上位が要件再起する時点で、下位も新たなラウンドに入るということで あって、下位も未実行ということになる。下位の実行状況の記録は、上位のモジュ一 ノレ力 Sfi1う。
図 12の注文状況照会のプログラムの処理経路図の例の経路の遷移は、表 15の経
差替え用紙 (mm) 36 路選択条件に従って説明すると次のようになる。 8401が起動され、状態変化がなく なる（画面からの入力が完了して出力データの値が成立して 、な 、状態)。経路 2の 条件が成立するので、下位単位モジュール 8402が選択される。 8402の状態変化が なくなると (入力と生成が完了した状態）、経路 3の条件が成立するので、上位の 840 1が選択される。 8401が起動され、状態変化がなくなる（出力データの値が全部成 立していない）。 8403が未実行なので経路 2が成立し、 8403が選択される。 8403の 状態変化がなくなると（1レコートの入力、生成が完了した状態）、経路 4の条件が成 立するので、 8403が要件再起される。注文ファイル力 最後の該当レコードが入力、 生成されるまで、経路 4の条件が成立する。最後の該当レコードの生成後、 8403の 状態変化がなくなったとき、経路 3の条件が成立し、上位の 8401が実行される。 840 1は、画面への出力を完了したとき状態変化がなくなり、経路 1の条件が成立して、プ ログラム終了が実行される。
(3)経路判定モジュール Rの処理フロー
経路の種類ごとに作成される場合の経路判定モジュール Rの処理フローは、図 13 のようになる。ステップ 8501は実行条件判定で、実行条件は 2つある。第 1の条件は 経路が未決定であること。自身より前に実行された経路判定モジュール Rが経路を決 定済みであれば、終了する。第 2の条件は、表 15に記載した実行条件を満たしてい ることである。 2つの実行条件に合致した場合、ステップ 8502で、担当する経路にあ る単位モジュールの識別子を、経路領域に記録する。終了の場合はプログラムの終 了処理を行う終了モジュール識別子である。全体制御モジュール力 経路領域の識 別子を読み、該当する単位モジュールの単位制御モジュールを起動する。
5.初期化モジュール S
初期化モジュールの処理フローは図 14のようになる。初期化モジュール Sが起動さ れるのは、単位モジュールが起動される直後である。図 9でわ力るように、初期化は、 単位モジュール内再起のときは起動されない。初期化の目的は、要件で定められた 最終目的である出力を全て完了させ、完了したらプログラムを終了するように制御す るためである。最終出力が完了するまでデータ項目や制御フラグの値が初期化され てはならないからである。また、プログラムが終了するまで、初期化が行われてもなら 37 ない。なぜなら、領域の初期化によって、目的である出力が完了しているにもかかわ らず、要素モジュールの不要な実行が起こってしまい、プログラムが終了しないから である。
[0087] 図 9の処理フローでは、初期化モジュールが起動されるのは、次の 3つのケースが ある。
(1)イベント発生後に最初に起動されるとき
(2)自モジュールの要件再起のとき
(3)下位単位モジュールから戻った後で、再度起動されるとき
このうち、初期化が実行されてはならないのは、（3)の場合である。（2)の要件再起 では、初期化は必要である。従って、初期化モジュール Sの実行条件は、（1)と（2) の場合のみ成立させたいので、「単位モジュールの最初の起動か？」 または、「要 件再起か？」となる (ステップ 91)。最初の起動か否か、および、要件再起力否かは、 起動の状況を記録する領域を用意するなどで判定すればよい。
[0088] ステップ 92では、目的処理である初期化を行う。初期化を行う対象は、自単位モジ ユールが成立させるデータ項目の値の領域と、自モジュールの実行制御に関わる制 御領域である (初期化 2)。初期化する領域は、最初の起動時と要件再起時では異な る部分がある。要件再起の場合は、前述の初期化対象のうち、ファイル入出力に必 要なキー項目の領域や要件再起の制御のための領域は初期化しな 、 (初期化 2)。
[0089] 単位モジュールの単位を出力論理レコードごと、あるいは、同じ要件再起条件を持 つ出力論理レコードの集合ごととして、初期化モジュール Sの起動を単位モジュール の起動直後におくことで、初期化の実行条件 (初期化のタイミング)を定型的に設定 してモジュールに作りこむことができるようになった。開発者が、初期化してよい範囲 や初期化を実行する条件を考えて設定する必要がなくなり、開発者の作業が軽減さ れた。
[0090] なお、本発明は、上述した実施形態および実施例には限定されず、本発明の技術 思想の範囲内で様々な変形が可能である。たとえば、プログラム (システム 'プロダラ ム）、処理装置、記録媒体、プログラム生成支援装置及び Zまたはプログラム生成ッ ール、データ構造及び Zまたはプログラムの雛型、プログラム作成方法及び Zまたは 38 プログラム開発支援方法、あるいはこれらの機能をコンピュータに実現するためのソ フトウエア並びに該ソフトウェアを搭載した記録媒体 '専用機、などとしてもそれぞれ 実現することが可能である。
[0091] 図 15は、本発明をプログラム生成支援装置として実施する場合の図である。 1501 は、以下の 3種類の情報を記憶する記憶部である。第 1の情報は、それぞれが定型 構造をもった要素モジュールである、入力データ項目を媒体からメモリに入力するた めの入力処理モジュールと、出力データ項目を生成するための条件判定と生成式の 実行を行うための出力データ生成処理モジュールと、出力データ項目をメモリから媒 体に出力するための出力処理モジュールと、前記自身の単位モジュールが処理対 象とするデータ項目の値の記録領域と前記単位モジュールの制御に関わる情報の 記憶領域の初期化を行うための領域初期化処理モジュールと、前記自身の単位モ ジュールが不動点に達した後に実行すべき単位モジュールの指定及び Zまたはシ ステム.プログラム終了の判定を行うための経路判定モジュールと、これらの要素モジ ユールを制御する単位制御モジュールと、単位制御モジュールを起動する全体制御 モジュールのコード情報である。前述の要素モジュールの各々は、目的処理の実行 条件を判定する機能と該実行条件に合致するときに該目的処理を実行する機能とを 少なくとも備え、目的処理が未実行かつ実行条件が整ったときにのみ実行される。
[0092] 第 2の情報は、ソフトウェア開発要望力もイベントを定義し、このイベントごとに単位 プログラムを規定し、単位プログラムにおける出力論理レコードを定義し、該出力論 理体の要件再起条件にしたがって単位モジュールを規定することによって設計した プログラム設計 (処理経路図作成)情報である。第 3の情報は、ソフトウェア開発要望 をイベントごとに宣言化した宣言の情報である。
[0093] 1502は、前述の第 3の情報である宣言の情報に基づいて、前述の第 1の情報であ るそれぞれのモジュールの複製を作成し、宣言の情報を、複製したモジュールのコー ド情報のそれぞれの所定の位置に代入する処理を行う代入部である。宣言が代入済 みとなつたモジュールは 1501の記憶部に記憶される。
[0094] 1503は、 1502で宣言情報が代入済みとなったモジュールを、第 2の情報であるプ ログラム設計情報に基づいて、ソフトウェア開発要望を満たすプログラムを構成するよ 39 うに配置する配置部である。ソフトウェア開発要望を満たすプログラムを構成するよう 配置が完了した宣言情報が代入済みのモジュール群である完成プログラムは、 150 1の記憶部に記憶される。完成プログラムは、要素モジュールが、出力論理レコード の単位、あるいは、要件再起の再起条件が同じである単位に集合をなして単位モジ ユールを構成しており、単位モジュール内の要素モジュールの繰り返し実行力、単位 モジュール内の繰り返し範囲内の状態変化によって制御され、単位モジュール内の 総ての状態変化がなくなったとき、自単位モジュールおよび隣接する下位の単位モ ジュールの状態変化と、自単位モジュールの終了条件と、自単位モジュールの要件 再起条件と、連接する下位単位モジュールの実行状況によって経路が判定され、前 記集合の単位ごとに、イベント発生後の単位モジュールの初期起動のときと単位モジ ユールの要件再起のときとに初期化が行われるように、生成されて 、る。
[0095] さらに本願発明は、その技術思想の同一及び等価に及ぶ範囲において様々な変 形、追加、置換、拡大、縮小等を許容するものである。また、本願発明を用いて生産 される装置、方法、ソフトウェア、システムが、その 2次的生産品に登載されて商品化 された場合であっても、本願発明の価値は何ら減ずるものではない。また、本願発明 は、ソフトウェアの適用分野としては、ビジネス、教育、ゲーム等分野を問わずあらゆ るものに適用可能である。
産業上の利用可能性
[0096] 本発明は、定型構造を持つ要素モジュールが 5種類に限定された上に明確ィ匕され 、さらにこの要素モジュールが一定の法則で集合した単位モジュールが形成され、こ の単位モジュール力イベント単位で生成されるので、本来的に余計な作業であるパ レットの分割構造を排することが可能になる。したがってよりコンパクトなプログラムの 実現ができる。さらにこのとき、単位モジュールの単位を出力論理体ごと、あるいは、 同じ要件再起条件を持つ出力論理体の集合ごととし初期化モジュールの起動を単 位モジュールの起動直後におくこととしたので、初期化の実行タイミングを定型化'ル 一ルイ匕でき、この意味での恣意性を排除できる。このため、開発者ごとの個別性、属 人性、恣意性を排除し、プログラム生成作業の共通化、ひいては自動化が可能とな るだけでなぐ開発者の作業が軽減することが可能となる。したがって本願は、いかな 40 る用途、或いはネットワークを介して配信され若しくはスタンドアローンを問わずあらゆ る存在形態におけるソフトウェア、及びソフトウェアの生産方法にも適用できる。 図面の簡単な説明
[図 l]Lyeeにおける「繰り返し法」についての説明のため、データ項目ごとの宣言を実 行する実行制御ロジックを簡易に示したものである。
[図 2]Lyeeによるシステムの分割構造を図示したものである。
[図 3]従来の Lyeeにおける単位モジュールの構造を図示したものである。
[図 4]従来の Lyeeにおける W04パレットの要素モジュールの動作を示すフローチヤ一 トである。
[図 5]本発明の一実施形態に係る生成モジュール Lの処理フローを示すフローチヤ一 トである。
[図 6]本発明の一実施形態に係る生成モジュール Lを説明するための、「購入金額計 算」システムの開発要望に係る画面の例を示した図である。
[図 7]本発明の一実施形態に係る入力モジュール Iの処理フローを示すフローチヤ一 トである。
[図 8]本発明の一実施形態に係る出力モジュール Oの処理フローを示すフローチヤ ートである。
[図 9]本発明の一実施形態に係る単位モジュール内の要素モジュールの実行制御を 行う単位制御モジュール Φの処理フローを示すフローチャートである。
[図 10]本発明の一実施形態に係る Lyeeのプログラム設計図の一例を示すための図 である。
[図 11]本発明の一実施形態に係る複数件処理の具体例を説明するための、「注文状 況照会」システムの開発要望に係る画面の例を示した図である。
[図 12]本発明の一実施形態に係る Lyeeの複数件処理に係るプログラム設計図の一 例を示すための図である。
[図 13]本発明の一実施形態に係る経路判定モジュールの処理フローを示すフロー チャートである。
[図 14]本発明の一実施形態に係る初期化モジュールの処理フローを示すフローチヤ 41 ートである。
圆 15]本発明の別の実施形態に係るプログラム生成支援装置として実施する場合の 機能ブロック図である。
符号の説明
1501 じ' 1思 p:[5
1502 代入部
1503 配置部
8201 単位モジユ -ル
8202 単位モジユ -ル
8203 単位モジユ -ル
8204 単位モジユ -ル
8301 顧客コード入力欄
8302 =1ンホボックス
8303 顧客名表示欄
8304 注文状況データ明細表示欄
8401 単位モジユ -ル
8402 単位モジユ -ル
8403 単位モジユ -ル

Claims

42 請求の範囲
イベントごとに単位プログラムを作成するプログラム設計方法にもとづいて開発する 単位プログラムであって、前記単位プログラムは複数の単位モジュールを備え、前記 単位モジュールは、それぞれが定型構造をもった要素モジュールである、入力デー タ項目を媒体からメモリに入力するための入力処理モジュールと、出力データ項目を 生成するための条件判定と生成式の実行を行うための出力データ生成処理モジユー ルと、出力データ項目をメモリから媒体に出力するための出力処理モジュールと、前 記自身の単位モジュールが処理対象とするデータ項目の値の記録領域と、前記単 位モジュールの制御に関わる情報の記憶領域の初期化を行うための領域初期化処 理モジュールと、前記自身の単位モジュールが不動点に達した後に実行すべき単位 モジュールの指定及び zまたはシステム ·プログラム終了の判定を行うための経路判 定モジュールとを具備して構成される単位プログラムと、複数の前記単位プログラム のうち前記経路判定モジュールの判定に従って特定の単位モジュールの起動または システム ·プログラムの終了を行うための全体制御モジュールとを少なくとも備えるシ ステム ·プログラムにお 、て、
前記要素モジュールの各々は、 目的処理の実行条件を判定する機能と該実行条 件に合致するときに該目的処理を実行する機能とを少なくとも備え、前記目的処理が 未実行かつ実行条件が整ったときにのみ実行され、
前記要素モジュールは、出力論理体の単位、あるいは、要件再起の再起条件が同 じである単位に集合をなして前記単位モジュールを構成し、
前記集合内の前記要素モジュールの繰り返し実行が該集合内繰り返し範囲内の状 態変化によって制御され、
自単位モジュールおよび隣接する下位の単位モジュールの状態変化と、 自単位モ ジュールの終了条件と、自単位モジュールの要件再起条件と、連接する下位単位モ ジュールの実行状況とによって経路が判定され、
前記集合の単位ごとに、イベント発生後の集合の初期起動のときと該集合の要件 再起のときとに初期化が行われる
ことを特徴とするシステム ·プログラム。 43
[2] 請求項 1記載の前記モジュールのそれぞれをルーチン化し、該ルーチン化された 命令をコンピュータに実行させることを特徴とする処理装置。
[3] 請求項 1記載のそれぞれの前記モジュールを含む前記システム ·プログラムを記憶 させたことを特徴とする記録媒体。
[4] ソフトウェア開発要望からイベントを定義し、該イベントごとに単位プログラムを規定 し、前記単位プログラムにおける出力論理体を定義し、該出力論理体の要件再起条 件にしたがって単位モジュールを規定してプログラム設計 (処理経路図作成)情報を 作成することにより開発する単位プログラムと全体制御モジュールとを少なくとも備え るシステム ·プログラムを生成するためのプログラム生成支援装置において、 それぞれが定型構造をもった要素モジュールである、入力データ項目を媒体からメ モリに入力するための入力処理モジュールと、出力データ項目を生成するための条 件判定と生成式の実行を行うための出力データ生成処理モジュールと、出力データ 項目をメモリから媒体に出力するための出力処理モジュールと、前記自身の単位モ ジュールが処理対象とするデータ項目の値の記録領域と前記単位モジュールの制 御に関わる情報の記憶領域の初期化を行うための領域初期化処理モジュールと、前 記自身の単位モジュールが不動点に達した後に実行すべき単位モジュールの指定 及び Zまたはシステム ·プログラム終了の判定を行うための経路判定モジュールとが 記録された第 1の記憶手段と、
前記作成されたプログラム設計 (処理経路図作成)情報を記憶させる第 2の記憶手 段と、
前記ソフトウェア開発要望が前記イベントごとに宣言化された宣言を記憶させる第 3 の記憶手段と、
前記第 3の記憶手段に記録された前記宣言に係る情報を前記第 1の記憶手段に記 録された前記要素モジュールのそれぞれの所定の位置に代入する代入手段と、 前記代入手段により得られた前記宣言に係る情報が代入された前記要素モジユー ルを、前記第 2の記憶手段に記録されたプログラム設計 (処理経路図作成)情報に基 づ 、て所望のプログラムを構成するように配置する手段と
を少なくとも備え、 44 前記要素モジュールの各々は、目的処理の実行条件を判定する機能と該実行条 件に合致するときに該目的処理を実行する機能とを少なくとも備え、前記目的処理が 未実行かつ実行条件が整ったときにのみ実行され、
前記要素モジュールは、出力論理体の単位、あるいは、要件再起の再起条件が同 じである単位に集合をなして前記単位モジュールを構成し、
前記集合内の前記要素モジュールの繰り返し実行が該集合内繰り返し範囲内の状 態変化によって制御され、
自単位モジュールおよび隣接する下位の単位モジュールの状態変化と、自単位モ ジュールの終了条件と、自単位モジュールの要件再起条件と、連接する下位単位モ ジュールの実行状況とによって経路が判定され、
前記集合の単位ごとに、イベント発生後の集合の初期起動のときと該集合の要件 再起のときとに初期化が行われる
ことを特徴とするプログラム生成支援装置。
ソフトウェア開発要望からイベントを定義し、該イベントごとに単位プログラムを規定 し、前記単位プログラムにおける出力論理体を定義し、該出力論理体の要件再起条 件にしたがって単位モジュールを規定してプログラム設計 (処理経路図作成)情報を 作成することにより、開発する単位プログラムと全体制御モジュールとを少なくとも備 え、前記単位プログラムは複数の単位モジュールを備えるシステム ·プログラムを生 成するために用いられるモジュールとしてのデータ構造であって、該データ構造は、 入力データ項目を媒体からメモリに入力するための入力処理モジュールであって、 要件に対応した宣言を入力するための欄を備えた定型構造をもった入力処理モジュ 一ノレと、
出力データ項目を生成するための条件判定と生成式の実行を行うための出力デー タ生成処理モジュールであって、要件に対応した宣言を入力するための欄を備えた 定型構造をもった出力データ生成処理モジュールと、
出力データ項目をメモリから媒体に出力するための出力処理モジュールであって、 要件に対応した宣言を入力するための欄を備えた定型構造をもった出力処理モジュ 一ノレと、 45 前記自身の単位モジュールが処理対象とするデータ項目の値の記録領域と、前記 単位モジュールの制御に関わる情報の記憶領域の初期化を行うための領域初期化 処理モジュールであって、要件に対応した宣言を入力するための欄を備えた定型構 造をもった領域初期化処理モジュールと、
前記自身の単位モジュールが不動点に達した後に実行すべき単位モジュールの 指定及び Zまたはシステム ·プログラム終了の判定を行うための経路判定モジュール であって、要件に対応した宣言を入力するための欄を備えた定型構造をもった経路 判定モジュールと
を要素モジュールとして具備し、さらに、
前記ソフトウェア開発要望が前記イベントごとに宣言化された宣言に係る情報を前 記要素モジュールに代入し、該宣言に係る情報が代入された前記要素モジュールを 前記作成されたプログラム設計 (処理経路図作成)情報に基づ!/ヽて配置するにあたり
、前記配置された前記要素モジュールの前記単位モジュール内での起動及び Zま たは再起の判定を行うための単位制御モジュールと、
複数の前記単位プログラムのうち前記経路判定モジュールの判定に従って特定の 単位モジュールの起動またはシステム ·プログラムの終了を行うための全体制御モジ ユールと
を具備して構成されるデータ構造であって、
前記要素モジュールの各々は、 目的処理の実行条件を判定する機能と該実行条 件に合致するときに該目的処理を実行する機能とを少なくとも備え、前記目的処理が 未実行かつ実行条件が整ったときにのみ実行され、
前記要素モジュールは、出力論理体の単位、あるいは、要件再起の再起条件が同 じである単位に集合をなして前記単位モジュールを構成し、
前記集合内の前記要素モジュールの繰り返し実行が該集合内繰り返し範囲内の状 態変化によって制御され、
自単位モジュールおよび隣接する下位の単位モジュールの状態変化と、 自単位モ ジュールの終了条件と、自単位モジュールの要件再起条件と、連接する下位単位モ ジュールの実行状況とによって経路が判定され、 46 前記集合の単位ごとに、イベント発生後の集合の初期起動のときと該集合の要件 再起のときとに初期化が行われる
ことを特徴とするデータ構造。
[6] ソフトウェア開発要望からイベントを定義し、該イベントごとに単位プログラムを規定 し、前記単位プログラムにおける出力論理体を定義し、該出力論理体の要件再起条 件にしたがって単位モジュールを規定してプログラム設計 (処理経路図作成)するス テツプと、
前記ソフトウェア開発要望を前記イベントごとに宣言化するステップと、 前記単位モジュールを構成する、それぞれが定型構造をもった要素モジュールの 雛型に前記宣言化した要件情報を代入するステップであって、前記要素モジュール は、入力データ項目を媒体力 メモリに入力するための入力処理モジュールと、出力 データ項目を生成するための条件判定と生成式の実行を行うための出力データ生成 処理モジュールと、出力データ項目をメモリから媒体に出力するための出力処理モジ ユールと、前記自身の単位モジュールが処理対象とするデータ項目の値の記録領域 と、前記単位モジュールの制御に関わる情報の記憶領域の初期化を行うための領域 初期化処理モジュールと、前記自身の単位モジュールが不動点に達した後に実行 すべき単位モジュールの指定及び zまたはシステム ·プログラム終了の判定を行うた めの経路判定モジュールであるステップと、
複数の前記単位プログラムごとに、前記経路判定モジュールの判定に従って特定 の単位モジュールの起動またはシステム ·プログラムの終了を行うための全体制御モ ジュールを規定するステップと
を具備することを特徴とするプログラム作成方法。
[7] ソフトウェア開発要望からイベントを定義し、該イベントごとに単位プログラムを規定 し、前記単位プログラムにおける出力論理体を定義し、該出力論理体の要件再起条 件にしたがって単位モジュールを規定してプログラム設計 (処理経路図作成)するス テツプと、
前記ソフトウェア開発要望を前記イベントごとに宣言化するステップと、 請求項 5で生成されたプログラムの雛型としてのデータ構造の空欄に、前記宣言化 47 した要件情報を代入するステップと
を具備することを特徴とするプログラム作成方法。
PCT/JP2006/308475 2005-04-21 2006-04-21 システム・プログラム、処理装置、記録媒体、プログラム生成支援装置、データ構造並びにプログラム作成方法 WO2006115229A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005124245A JP2008171023A (ja) 2005-04-21 2005-04-21 ソフトウェア生成方法
JP2005-124245 2005-04-21

Publications (1)

Publication Number Publication Date
WO2006115229A1 true WO2006115229A1 (ja) 2006-11-02

Family

ID=37214844

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/308475 WO2006115229A1 (ja) 2005-04-21 2006-04-21 システム・プログラム、処理装置、記録媒体、プログラム生成支援装置、データ構造並びにプログラム作成方法

Country Status (2)

Country Link
JP (1) JP2008171023A (ja)
WO (1) WO2006115229A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002312167A (ja) * 2001-04-13 2002-10-25 Fujitsu Ltd 変数の値をコンピュータに算出させるためのプログラム、コンパイルプログラム、変数値確定方法およびプログラム生成方法
WO2005029323A1 (ja) * 2003-09-22 2005-03-31 Catena Corporation ソフトウェア生成方法
WO2005029322A1 (ja) * 2003-09-22 2005-03-31 Catena Corporation ソフトウェアの生成方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002312167A (ja) * 2001-04-13 2002-10-25 Fujitsu Ltd 変数の値をコンピュータに算出させるためのプログラム、コンパイルプログラム、変数値確定方法およびプログラム生成方法
WO2005029323A1 (ja) * 2003-09-22 2005-03-31 Catena Corporation ソフトウェア生成方法
WO2005029322A1 (ja) * 2003-09-22 2005-03-31 Catena Corporation ソフトウェアの生成方法

Also Published As

Publication number Publication date
JP2008171023A (ja) 2008-07-24

Similar Documents

Publication Publication Date Title
Ward Proving program refinements and transformations
Biermann Approaches to automatic programming
Coulange Software reuse
Estublier et al. Toward scm/pdm integration?
RU2630383C2 (ru) Способ обработки процессов машиной состояний
Vasilache et al. Automatic correction of loop transformations
JPWO2002097727A1 (ja) 知識の自動生成方法、知識の自動生成システム、知識の自動生成プログラム、自動設計方法及び自動設計システム
JP3577400B2 (ja) システム設計装置及びデータウエアハウス設計システム
JP2801931B2 (ja) 論理設計処理装置および回路変換ルール翻訳装置ならびに回路変換ルール翻訳方法
CN115469860B (zh) 基于指令集的需求到软件领域模型的自动生成方法及系统
Jarke et al. Managing knowledge about information system evolution
Bruynooghe et al. First order logic with inductive definitions for model-based problem solving
Castro et al. Automatically deriving cost models for structured parallel processes using hylomorphisms
WO2006115229A1 (ja) システム・プログラム、処理装置、記録媒体、プログラム生成支援装置、データ構造並びにプログラム作成方法
Mi et al. Articulation: an integrated approach to the diagnosis, replanning, and rescheduling of software process failures
Saini et al. Functional programming for business process modeling
Kahrs et al. The semantics of Extended ML: a gentle introduction
Smith Rapid software prototyping
Feijs A formalisation of design methods: a lambda-calculus approach to system design with an application to text editing
JPWO2007018295A1 (ja) プログラム実行順序決定装置および方法
Borgida et al. Techne: A (nother) requirements modeling language
JP2007265418A (ja) 自動詳細化システム
JPWO2006025472A1 (ja) Ｌｙｅｅ方法論に基づく処理経路図作成方法、作成装置、ソフトウェア生成方法、生成装置、ソフトウェア並びにソフトウェア開発支援用ソフトウェア
Moss et al. Dynamic interpretations of constraint-based grammar formalisms
Abdallah et al. Deriving correct prototypes from formal Z specifications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 06732233

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP