JPH11288367A - Automatic program generation system and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To effectively generate a program that is used for organization of a system where a single terminal must react to many events by enlarging the description system of a state transition automaton and building in the transition of a lock state into the automaton. SOLUTION: The description system of a state transition automaton is enlarged, and the transition of a lock state which performs a prescribed exclusive control operation is built in into the automaton. Then an operation which controls the lock state transition is described on the automaton in a lock state transition mode, and the user detects this description and generates a program to return an event showing a locked state to an external event in a lock state mode. In this system, the system description 1 is described on the automaton by the user and inputted to an information processor. A program generation part 2 generates a prescribed program in a process that is carried out based on the contents of the description 1.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION The present invention relates to a state transition automaton, that is, a computer program for generating a corresponding program by computer processing based on a system description expressed as a set of module descriptions including state transitions and operation definitions in each state. Regarding the technology of automatic generation (creation),
In systems such as providing services to remote customers / residents via networks in fields such as finance / public,
A system in which one terminal must respond to many events, such as an event sent from a printer, scanner, cash dispenser, card reader, etc., mounted on that terminal, or an event representing a request from the other terminal. The present invention relates to an automatic program generation system and method suitable for efficiently generating a program used for construction.

[0002]

2. Description of the Related Art Conventionally, as a technique for developing a program of a system for processing events of a plurality of devices and communication partners, for example, "Protocol Language" supervised by Tadanori Mizuno (1994, Inc.)
Cut System Publishing), "Estelle" and "SDL". In particular, Estelle on pages 63-85 is a language for protocol description.
Users describe such a system as a collection of finite state automata (hereafter referred to as modules) that send events to each other, and programmatically derive from the description using a tool provided for Estelle. Can be automatically generated.

[0003] The function of such Estelle will be described using a description example on page 68 of the above-mentioned document. Here, a module E that has two channels, has four internal states, and exchanges events with the outside is defined.

Specification Example; default individual queue; channel ChU (R1, R2); by R1: put; channel ChS (Ra, Rb); by Ra: dt0; dt1; by Rb: ak0; ak1; module E systemprocess; ip U: ChU (R2); S: ChS (Ra); end; body E1 for E; state s0, s1, s2, s4; .. (1) initialize to s0 begin end; .. (2) trans .............. .............. (3) when U.put ............. (4) from s0 to s1 ..... (5) begin output S.dt0 end; ... (6) from s2 to s3 ... (7) begin output S.dt1 end; ...... (8) when S.ak0 ............. (9):: end; end ;

The line (1) indicates that the module E has four states "S0, S1, S2, S3". (2)
Line indicates that when the system is started, module E
0 ". "Begin end;" on that line
Is for the program to run between the "begin" and "end" when the system boots, but is empty because it does nothing in this example.

[0006] Also, after "trans" in the line (3),
State transitions for events are described. That is, “when U.put” in line (4) indicates that the description of the state transition when the event “put” comes from the channel “U” is described after that line. )
"From s0 to s1" indicates that when the event arrives, transition from state "s0" to state "s1" is made, and line (6)
“Begin output S.dt0 end;” describes the operation at the time of the state transition. Here, the operation of sending the event “dt0” to the channel S is described.

As described above, in "Estelle" and the like, the parallel operation of the module is described by the operation such as the state transition and the event exchange at that time, so that it is intuitive and easy to understand. Also, in "Estelle", the state transition is represented by text, but in "SDL", which is also described in the above document, a graphical description method has been developed, and the user can understand the state transition of each module more easily. Can be defined.

An example of a system description in a technique for creating a program by describing the system with such a group of module descriptions including state transitions and operation definitions in each state will be described below. FIG. 16 is an explanatory diagram showing a description example of an operation definition in each state, and FIG. 17 is an explanatory diagram showing a description example of a state transition in each state.

[0009] In the example shown in FIGS.
61 and the state transition definition 171 define the system,
In the state definition 161 of FIG. 16, the specification of what state the module has is stored in the field of the state name 162, and which state is the state when the system is started (this state is called the initial state). Specify the initial state 16
In the field of the operation definition 164, the definition of a command to be executed at the time of transition to each state (this is called the operation definition of the state) is described in the field of the operation definition 164.

[0010] The module described in FIG.
The state "L" is an initial state, and when the system is started, send (module A, initialization) send (module B, initialization) send (module C, initialization) send (module C) described in its operation definition Module D, initialization) is executed. In addition to the state “IDOL”, the state “Prin
ting ", state" Completed ", state" Incompleted ", and the like.

In FIG. 17, a state transition is represented by a table such as a state transition definition 171. This table shows the status name 1
72, each field of an event name 173, and a next state name 174, which state is described for each state when an event is sent. FIG. 18 shows the two tables, the module represented by the state definition 161 in FIG. 16 and the module represented by the state transition definition 171 in FIG.

FIG. 18 is an explanatory diagram showing an example of a diagram language in which modules expressed by the state definition and the state transition definition in FIGS. 16 and 17 are expressed graphically. In FIG. 18, the “state” of the module 181 is represented by describing the state name in a circle, and particularly, the initial state is described by a double circle. “State transition” is expressed by describing an event name at an edge from “state” to “state”. The “operation definition” of each state is expressed by associating a square with the “state”. For example, an operation definition 183 is described for the state “IDOL” 182.

From this state "IDOL" 182, the state "Printi"
ng) 184 has an edge “material printing”, which means that when the module is in the state “IDOL” 182 and the event “material printing” is sent to this module, the state is “printing” 184. The transition is made and the operation indicated by the operation definition 185 is performed. State "Printing" 18
4 and state "Completed" 186, state "Incompl"
The same applies to “eted” 187 and the like. Since such a graphical representation is easier to understand intuitively, the description will be continued using this graphical representation.

In the remote service window system, complicated exclusive control (lock control) for controlling various devices and synchronizing with a plurality of communication partners is required. That is,
Since one module sends events to and from many device control modules, state transitions must be written for all events that may be sent during lock, for example, as shown in FIG. 19 below. In addition, the description becomes very complicated.

FIG. 19 is an explanatory diagram showing a description example of a state transition for lock control according to the prior art. In this example,
It represents a part of the state transition of the main module of a certain system. Here, the main module is first,
In the “IDOL” state 191, when the “material print” event comes to the main module, the “Printing” state 192
And sends a print event to the printer control module, and then waits for the printer to complete printing.

During this time, the main module is locked for all events that may be sent to the main module, as shown in the figure, so as not to accept requests other than the printer. State transition ("Answering LockSt
atus A "state 193," Answering LockStatus B "state 194, and operation definitions 195 and 196).

[0017]

The problem to be solved is that, in the prior art, in the description of a system that requires lock control, all the events that may be sent are locked. The point is that the user must write a state transition for sending back an event indicating that the event is being performed. An object of the present invention is to solve these problems of the prior art, and one terminal responds to many events, such as a system for providing services to remote customers / residents via a network in fields such as finance and public services. It is an object of the present invention to provide a program automatic generation system and a method capable of efficiently generating a program used for constructing a system to be performed.

[0018]

In order to achieve the above object, an automatic program generation system and method according to the present invention transitions an internal state according to an event, and transmits an event to the outside or inside according to the transitioned state. The user describes the system as a group of state transition automata, such as the execution of commands, and automatically generates a system program by computer processing from such a description.The description system of the state transition automaton is expanded, A lock state transition for performing a predetermined exclusive control operation is incorporated in the transition automaton. Then, when the user describes an operation for controlling the transition of the lock state when the state transits to the lock state in the state transition automaton, this description is detected, and when the state is the lock state, the operation is locked against an external event. Generate a program to return an event indicating that Further, as a lock state that the state transition automaton can take, not only two states of “lock” and “unlock” but also a third state of “short-time lock” is provided. Then, in response to the transmitted event, the state transition automaton of the “short-time lock state” sends an event indicating that the state is “short-time lock state” back to the sender, and the state transition automaton of the sender transmits the “short-time lock state” If it is in the "locked state", the program is generated as an operation for waiting for the lock to be released. In this way, by expanding the description system of the state transition automaton and incorporating the transition of the lock state,
A program that realizes lock control can be automatically generated without requiring the user to write complicated lock control state transitions.

[0019]

Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a block diagram showing an embodiment of the configuration of the automatic program generation system of the present invention according to the present invention, and FIG. 2 is a block diagram showing an example of the device configuration of the automatic program generation system in FIG.

In FIG. 2, reference numeral 21 denotes a CRT (Cathode Ra).
y, a display device comprising a keyboard, a mouse, etc., and a CPU (Central Processes) 23.
singUnit) and an information processing apparatus which includes a main memory and the like and performs computer processing by a storage program method, 24
Is an auxiliary storage device such as a hard disk device, 25 is an optical disk on which a procedure program of the automatic program generation method of the present invention is recorded, and 26 is an optical disk drive for reading programs and data from the optical disk 25.

The information processing device 23 reads a program recorded on the optical disk 25 via the optical disk drive device 26 into the main memory or the auxiliary storage device 24, and constructs each function of the program generating section 2 shown in FIG.

In FIG. 1, reference numeral 1 denotes a system description which is described by a user on a screen of a display device 21 via an input device 22 of FIG. 2 using a state transition automaton and is input to an information processing device 23; A program generation unit 3 for generating a predetermined program by computer processing based on the description content is a program generated by the program generation unit 2.

The system description 1 is described by a user as a group of modules (module definition 1a) for exchanging signals called events with each other in the system. Each module definition 1a includes a set of states that the module definition 1a can take, a state definition 1b including a description of a command to be executed in each state, and a state definition 1b when an event is sent to each state. It is described in a state transition definition 1c representing a transition (an edge between states). The details of the state definition 1b and the state transition definition 1c will be described later with reference to FIGS.

The program generation unit 2 includes an event management engine and an event queue generation unit 2a for generating a code 3a of the event management engine and an event queue storage area 3b as fixed parts of the program 3, and a system description 1
And a module code corresponding to each of the module definitions 1a in the program 3 (a module corresponding function code generator 2b for generating a module corresponding function code 3c. Then, when each module sends an event, it enters the event queue storage area 3b, and the code 3a of the event management engine uses the event stored in the event queue storage area 3b as an argument to execute the function of the transmission destination module. Call sequentially.

The module corresponding function code generator 2b in the program generator 2 includes a state storage area generator 2c for generating the state / lock state storage area 3d in the module corresponding function code 3c of the program 3, and another module in the locked state. When an event is sent from a module, a lock event processing code 3e in the program 3 for sending an event indicating that the module is locked
And a state transition code for generating a state transition code (a code for transitioning the state according to the type of the sent event) 3f in the program 3 based on the state transition definition 1b in the system description 1. The operation code 3g in the program 3 based on the generation unit 2e and the state definition 1c in the system description 1.
(A code to be executed upon transition to each state).

Further, the operation code generation unit 2f has a lock code generation unit 2g that generates a lock code 3h in the program 3 based on the lock specification 1d in the system description 1. Thus, in the automatic program generation system of the present example, in the system description 1,
Lock specification 1 in the state operation definition (state definition 1c)
If d is performed, a code for locking (lock code 3h) is generated in the operation code 3g.

Hereinafter, the language (C) used to describe the program 3 generated from the system description 1 by the user
And a programming language such as PASCAL, Basic, and Lisp) as a target language, and a language used by the user for the system description 1 as a source language.

In the automatic program generation system of this embodiment,
Of the state definition 1b and the state transition definition 1c used for the system description 1 in the source language, in the state definition 1b, a description of LockMeWithout (module name 1,..., Module name n) and a specification 1d of a lock called UnlockMe Is converted to a target language to generate a program 3.

That is, the code 3a of the event management engine and the event queue storage area 3b are generated as fixed parts in the program 3, and the code (function module) for realizing the function of the module is defined for each module definition 1a. A corresponding function 3c) is generated, and when each module sends an event, the event is stored in the event queue storage area 3b. The event management engine code 3a uses the event stored in the event queue storage area 3b as an argument and Function of each module is sequentially called.

In the program 3, functions for realizing the function of each module include (1) an area for storing a state and a lock state (state / lock state storage area 3d),
(2) When an event is sent from another module in the locked state, a code for sending an event indicating that the module is locked (locked event processing code 3e), and (3) a code for the sent event A code that changes states according to the type (state transition code 3f),
(4) It consists of a code (operation code 3g) that is executed when a transition is made to each state.

If the operation definition (state definition 1c) of the state in the system description 1 specifies that the lock is to be locked or unlocked (lock specification 1d), the operation is performed by the lock code generation unit 2g. In code 3g,
A code for locking or unlocking (lock code 3h) is generated.

Thus, in the automatic program generation system of this embodiment, the user can specify the operation of the state (state definition 1c) without expressing the lock state one by one in the state transition definition 1b as in the conventional case. For example, if LockMeWithout (MODULE1, ..., MODULEn) is described, the variable indicating the lock state of the function is locked, and the module name, MODULE1, ..., MODULEn is displayed In this case, the event "LOCKED" can be sent to the sender by the lock event processing code 3e.

The lock state is set to three types of "unlocked state", "locked state", and "short locked state (short-time locked state)", and the operation designation in the state in the source language is "LockMeWithout". ”, LockMeShortWithout (module name 1, ..., module name n) can be described.

In response to this description, a code for setting the variable indicating the lock state to the lock state for a short time is generated, and a function corresponding to the module in the lock state for a short time is generated.
When an event is sent from a module other than the module whose lock has been excluded, the management function of the event queue storage area 3b determines that event, and stores the event in the event queue until the lock state of the module to which the event is sent is released. By holding in the area 3b, a function of waiting in the locked state for a short time can be realized.

Hereinafter, such a program automatic generation system will be described in more detail with reference to FIGS. First, details of the system description 1 described by the user will be described with reference to FIGS.

FIG. 3 is an explanatory diagram showing a detailed example of the state definition in FIG. In the state definition 1c of this example, a state name 31 that specifies what state the corresponding module has, an initial state 32 that specifies which state is the state when the system is started, and An operation definition 33 that defines a command to be executed when transitioning to each state is described.

In the state definition 1c of this example, three operations of send (module name, event name, argument 1, ...) LockMeWithout (module name 1, module name 2, ...) UnlockMe are used as the operation definition 33. Can be described.

Note that "send (module name, event name,
Arguments 1,...) ”Include the event specified by the“ event name ”in the module specified by the“ module name ”. . . Is sent as an argument. “LockMeWithout (module name 1, module name 2,...)” Is an operation of locking the module for which this operation is specified from a module other than the module specified by “module name 1”,. Locking here means sending back an event called LOCKED for any event sent. Also, "UnlockM
"e" is an operation for releasing the locked state.

In the module described in the example of FIG. 3, the state "IDOL" is an initial state, and when the system is started, "send (module A, initialization)" described in the operation definition is performed. Is executed. Then, in the next state “Printing”, “LockMeWithout (printer, U
L), "writeMessage (printing)", and "send (printer, Print, document A)". Furthermore, in the state "Completed", "writeMessage
(Print completed) "and" unLockMe "are executed, and in the state" Incompleted "," writeMessage
(Cancelled) "and" unLockMe "are executed.

FIG. 4 is an explanatory diagram showing a detailed example of the state transition definition in FIG. The state transition definition 1b of this example is composed of fields of a state name 41, an event name 42, and a next state name 43, and describes which state to transition to when each event is sent. Have been. Here, a special event “* immediate *” is provided, and this (“* immediate *”) indicates that the state immediately transits to the next state without receiving the event. For example, in the state transition definition 1b of this example, the state “Co
From "mpleted" to "IDOL" with the event name "* immediate *", this means transition to "Completed", and after completing the operation there, immediately transition to "IDOL" .

FIG. 5 shows two tables shown in FIG. 3 and FIG. 4, that is, the module expressed by the state definition 1c of FIG. 3 and the state transition definition 1b of FIG.
FIG. 5 is an explanatory diagram showing an example of a diagram language for graphically expressing modules represented by the state definition and the state transition definition in FIGS. 3 and 4. In the description of the module definition 1a of this example, each “state” is represented by describing a state name in a circle, and particularly, the initial state is described by a double circle.

The “state transition” is expressed by describing an event name on an edge from “state” to “state”. The “operation definition” of each state is expressed by associating a square with the “state”. That is, in this example, the module definition 1a is initially stopped in the “IDOL” state. Then, since the edge “material printing” appears from the initial state “IDOL” 51 to the state “Printing” 52, the initial state “IDOL”
At the time of 51, the event "print material" from another module
Is sent, the module definition 1a changes the state “Prin
ting ”52.

Then, in the state "Printing" 52, the user locks himself / herself except from the printer and the UI.
To the event "Print material A" and stop again. That is, in accordance with the operation definition 53, "LockMeWithout (printer, UL)", "send (printer, Print, document A)", and "LockMeWithout (printer, UI)" (not shown) are specified. "WriteMes" for events other than printer and UI
sage (printing). "

Similarly, when the edge “printing completed” is sent when the module definition 1 a is in the state “Printing” 52, the state transits to the state “Completed” 54. According to 55, "Unl
ockMe ". Also, if the event "printing complete" is sent from the "printer", the status "Completed"
54, and according to the operation definition 55 of "Unlocked",
Then the lock is released. The state “Printing” 52
At this time, if an event “cancel” comes, the state transits to the state “Incompleted” 56.

As described above, in this example, when exclusive control is performed, the operation designation of “LockMeWithout (module name 1, module name 2,...)” Is performed for a desired module, thereby For each event sent from a module other than the module specified by "module name 1", ...
Since an event called LOCKED can be sent back, for example, a system that requires complicated exclusive control (lock control) to control various devices and synchronize with multiple communication partners, such as a remote service window system Programs can be generated with simple system descriptions.

Next, referring to FIG. 1, a description will be given of a target language program 3 which performs an operation equivalent to the system described in the system description 1 in the source language. The target language program 3 includes an event queue storage area 3b and an event management engine code 3a which are commonly present irrespective of the contents of the source language, and a module which is a function that realizes its function and exists for each module It consists of a group of function codes 3c.

The module-corresponding function code 3c includes a status / lock status storage area 3d for storing “module status”, “lock status”, and “list of module names from which locks are excluded”, an event and its status. A function that takes three parameters, the module from which the event came and the argument of the event, and executes the operation when the event is sent to the module, and performs the event processing in a locked state It is composed of a lock event processing code 3e, a state transition code 3f for executing a state transition, and an operation code 3g for executing an operation corresponding to each state.

The lock event processing code 3e is a process for returning an event "LOCKED" to an event sent from a module other than the lock exclusion target module. The state transition code 3f is a code for obtaining the next state from the module state and the event stored in the state / lock state storage area 3d for each module and transitioning to the next state. The actual rewriting of the state / lock state storage area 3d of the module and the operation at the time of transition to the state are performed by the operation code 3g which is a code corresponding to the operation in each state.

Next, the operation of the program 3 described in such a target language will be briefly described. The event management engine code 3a is stored in the event queue storage area 3
If there is any event in b, take out the event, check which module is directed to which module, and find the function code corresponding to the destination module.
Call the module corresponding function code 3c.

In the module corresponding function code 3c,
If locked, lock event processing code 3e
And return the event "LOCK" to the sender. If not, the state transition is performed with the state transition code 3f, and the operation of the state to which the transition is made is performed within the operation code 3g.

If an event transmission to another module is described in the operation code 3g, the event is added to the event queue storage area 3b by the operation code 3g.
The code 3a of the event management engine retrieves the event from the event queue storage area 3b and calls the module corresponding function code 3c.

Further, if there is a description to lock or unlock the operation of the state after the transition, the state of the function is locked or unlocked by the lock code 3h. By repeating this operation, the behavior of the system described in the system description 1 in the source language can be realized.

Next, the operation of the program generator 2 for generating the program 3 described in the target language from the system description 1 in the source language will be described. First, the event management engine and event queue generation unit 2a generates an event management engine code 3a and an event queue storage area 3b that are common to any module description.

Then, in the module-corresponding function code generating unit 2b, each processing from the state storage area generating unit 2c is repeated for each module, and the module-corresponding function code 3c and the module state storing area and the lock state storing area are repeated. Then, a state / lock state storage area 3d including the lock exclusion target module storage area is generated.

That is, first, the state storage area generation unit 2c
Then, an area for storing the state of the module is generated for each function. Next, the lock-time code generation unit 2d generates an area for storing a lock state for each function and an area for storing which module is to be excluded from the lock. The lock event processing code 3e as a part is embedded.

Further, the state transition code generator 2e generates a state transition code 3f for transitioning from the event and state in the source language to the next state. And finally,
The operation code generation unit 2f generates an operation code 3g corresponding to the operation in each state, and completes a module corresponding function code 3c corresponding to each module.

The outline of the source language, the target language, and the program generation method has been described above. Hereinafter, each will be described in more detail. First, the structure of a program described in a target language will be described in detail with reference to FIG.

FIG. 6 is an explanatory diagram showing an example of the overall configuration of a program generated by the automatic program generation system in FIG. Event queue storage area 3 for program 3
b is a table including four fields “destination module”, “event”, “source module”, and “argument”, and is put in and out in a FIFO (First-In-First-Out) format. That is, the first entered data is retrieved first.

The module corresponding function code 3c is “MODU
It is implemented as a function of three parameters, such as LE (event, fromWhom, args). Where the parameter "even
“t” means an event, parameter “fromWhom” means the module that sent the event, and parameter “args:” means that the arguments at the time of sending the event are arranged in an array and collected into one data.

The code 3a of the event management engine operates as shown in the PAD diagram described in FIG. That is, first, in the process of step 600, the functions of all modules are initialized. In this embodiment, the initialization method is to send a special event name "_init_" to each function,
Shall be called. As will be described later, the function of each module will execute initialization processing when the event "_init_" is sent.
That is, it is generated so as to perform an operation of transitioning to the initial state.

Next, in step 602, it is checked whether there is any event in the queue.
Take it out in process 3 and set toWhom: destination module event: event name fromWhom: source module args: argument.

Next, in the process of step 604, a function corresponding to the module “toWhom” is obtained, and “event” and “fro” are obtained.
Call the function with "mWhom" and "args" as arguments. The called function code 3c performs an internal state transition and an operation at the time of transition to the state, and performs an operation of sending an event such as send (MODULEi, EVENTA, args) as a process thereof. Is added, and the event management engine code 3a retrieves the event again and calls the function corresponding to the module.

The details of the structure of the module corresponding function code 3c generated in this manner will be described with reference to FIG. FIG. 7 is an explanatory diagram showing a detailed configuration example of the module corresponding function in FIG. The generated module-corresponding function code 3 c includes “MainMo
dule (event, fromWhom, args) ". That is, it is implemented as a function that receives three types of information: the type of event (event), the module from which the event was sent (fromWhom), and the arguments at that time arranged in an array (args). You.

Further, there is a state / lock state storage area 3d including a state, a lock state, a declaration of a lock exclusion target module storage area, and an initialization processing part. FIG. 9 shows details of this part. FIG. 9 is an explanatory diagram showing a detailed configuration example of the state / lock state storage area in FIG. In this example, it is assumed that the target language has a function capable of defining a variable that can permanently store a value for a function until an explicit assignment is made.

Here, in the declaration section 91 using the function, the state storage area of the module is set to “userStd”.
atus ", the lock status storage area is" lockStatus ", and the lock exclusion target module storage area is" moduleList ". Here, as the state initialization code, Is described. The code 3a of the event management engine in FIG. 1 makes the transition to the initial state by sending the event "_init_" to the function of each module at the same time when the system starts up.

In FIG. 7, next, as a lock event processing code 3e, a process of returning an event "LOCKED" to "toWhom" when an event is transmitted from a module which is not a lock exclusion target in a locked state. Embedded. The algorithm of this code is shown in FIG.

FIG. 8 is a PAD diagram showing an example of the procedure of the lock event process in FIG. The variable “lockStatus” in the status / lock status storage area 3d in FIG.
ed ”(step 801) and the variable“ fromWhom ”is not included in the variable“ moduleList ”(step 80).
2) The event sender (fromWhom) is locked (Lo)
cked) is returned (step 803).

In the module-corresponding function code 3c of FIG. 7, next, the current state "us
erStatus "and event" event "
The code that jumps to the code that transitions to the next event is embedded. Then, codes for transitioning to the respective states are embedded with labels 72 and 73, respectively, so that jumping can be performed from the processing of the state transition code 3f.

As shown by the label 72, the transition to each state is performed by first setting the variable “userSt
"atus" is set to a value representing the state, and then an operation (operation code 3g) generated in the target language when the state has transitioned is embedded. Here, for send (MODULE, event, arg1,...), A runtime routine call process 75 for adding this event transmission to the event queue is embedded.

For LockMeWithout (MODULE1,..., MODULEn), MODULE1,..., MODULEn are set in lockStatus = LOCKED; moduleList, and a locked state and a list of modules to be excluded are recorded. The processing 76 is embedded.

For Unlock, a process 77 for releasing the locked state with lockStatus = UNLOCK is embedded. For other operations, calls to the corresponding runtime routines of the target language are embedded.

As described above, in the operation code 3g, after everything described in the operation at the time of transition to the state is converted and embedded in this way, a return instruction 78 is placed, and this function ends. .

However, if an edge is defined from this state to another state by the event * immediate *, this means that the state immediately transits to that state without waiting for a new event. Instead of goto, embed the label name of the next state; and generate code that immediately transitions to that state.

Hereinafter, a method of generating the state transition code 3f from the state transition definition 1b and a method of generating each operation code 3g from the state definition 1c in FIG. 1 will be described in detail. First, the generation process of the code corresponding to the state transition (state transition code 3f) will be described in detail with reference to FIG.
Here, the target language is the programming language C
Will be described.

FIG. 10 is a PAD diagram showing an example of the processing procedure of the state transition code generation unit in FIG. First, in step 1001, a set of all states of the module is put in “Slist”. Next, in step 1002, a code “switch (userStatus) {” is generated. Declare the start.

Then, in the processing of the next step 1003,
Step 1 for all states "S" in "Slist"
A series of processes from 004 onward is repeated, and a jump instruction for transitioning to the next state is generated for each state when each event comes. First, in the process of step 1004, a code “name of case S:” is generated, and the operation designation start in the state “S” is declared. Next, "even
In step 1005 in order to divide by “t”,
Generates the code "switch (event) {".

Further, in the next step 1006,
A set of all the events defined in the state “S” is put in “Elist”, and “Elis”
Step 1008 for all events "E" of "t"
The following series of processing is repeated to generate jump statements. Here, since the event “* immediate *” is interpreted as an immediate transition, it is not added to the variable “Elist” that stores a set of events.

In the process of step 1008, a code “name of case E:” is generated.
In the process of step 9, “Next” is set as the label of the state to which the transition is made from the state “S” by “E”.
Generate the code "goto Next name;" Finally, in order to end the two cases, “}” is generated in the processing of step 1011, and
In step 12, "}" is generated. FIG. 11 shows the resulting code generated in this manner.

FIG. 11 is an explanatory diagram showing an example of generating the state transition code in FIG. "Switch" and "case"
As a result, a code for executing the operation of each of the states “IDOL” and “PRINTING” is generated. The state "Comple
Since there is only a transition of “* Immediate *” from “ted” or the state “Incompleted”, this state transition code does not appear as a case.

Next, the operation of generating the operation code in each state by the operation code generation unit 2f of FIG. 1 will be described with reference to FIG. FIG. 12 is a PAD showing a first processing operation example of the automatic program generation system in FIG. 1 according to the present invention.
FIG. This example shows an example of a processing procedure of the operation code generation unit in each state in FIG. 1. First, in step 1201, a set of all states of the module is set in “Slist”.

Next, in the processing of step 1202, “Slis
A series of processes from step 1203 is repeated for all states “S” of “t” to generate a code that realizes the operation when the state transits to the state. First, in the process of step 1203, a label with the name of the state “S” is created. Next, in the processing of step 1204, a code “userStatus = S” is generated, and the state of the transition destination is stored in a variable representing the state of the module.

Then, in the processing of step 1205, “Ac
ts ", put the sequence of actions defined in state" S ",
In the processing of step 1206, the operation “A” in “Acts”
In step 1207, appropriate code is generated.

In the case dividing process of step 1207,
When the operation “A” is in the form of “send (M1, E1, ARG1,...)”, First, in step 1208, the name of this module is “M2”, and then, in step 1209, , “ARGS1,..., ARGSn” into the structure “args”, and finally, in the process of step 1210,
Generate the code "send (M1, E1, M2, args)".

When the operation “A” is in the form of “LockMeWithout (M1,...)” In step 1207, the following series of processing is performed. First, step 1
In the process of 211, a code “lockStatus = LOCKED” is generated, and then in the process of step 1212, “M1,
..., Mn "is generated into" moduleList ". As a result, it is possible to set the lock state and set the module excluded from the lock target.

Further, when the operation "A" is in the form of "UnlockMe" in the case dividing process in step 1207, a code "lockStatus = UNLOCKED" is generated in step 1213 to release the lock.

In the above example, in order to simplify the explanation,
Specify "send", "LockMeWithout", "Unl
ock ". If it is desired to increase the types of operation designation here, the case of the operation designation may be added to the case classification process of step 1207, and a code generation method may be incorporated. For example, by adding a function that calls the function provided in the target language call function name (argument 1, ..., argument n), the function provided in the target language can be used, which is convenient and convenient. is there.

If it is desired to add this, the identification of this form is added to the case classification process in step 1207 as a case classification, and the generated code is a code for calling this function in the target language. good. In this way, from the state definitions of FIGS. 3, 4 and 5, FIG.
Is generated. FIG. 13 is an explanatory diagram showing a specific example of the operation code in FIG. "IDOL",
A code that performs each operation for each state of “Printing”, “Completed”, and “Incompleted” (operation code 3
g) has been generated.

Next, referring to FIG. 14, the lock state is set to three values UNLOCKED... No lock is applied. Respond to events from any module. LOCKED ........... Locked and responds only to events from a limited number of modules. LOCKED is returned to other modules. LOCKEDSHORT ...... Locked for a short time.
We will respond to limited modules immediately. Events from other modules wait until the lock is released. Event queue storage area 3b in FIG.
Will be described below.

FIG. 14 is an explanatory diagram showing an example of a procedure for managing the event queue storage area by the program in FIG. In the event queue management, when the system is started, the process is repeatedly performed in step 1401, and the process of calling the function corresponding to the module is repeated.

That is, in the process of step 1402, first, one line is fetched from the event queue storage area 3b in FIG. 1, and is set as toWhom: destination event: event fromWhom: source args: argument.

Next, in the condition judgment processing of step 1403, it is checked whether or not the locked state of “toWhom” is “LOCKEDSHORT” and “fromWhom” is not included in the exclusion list. Since the time is locked, in the processing of step 1404, "(toWhom, even
t, fromWhom, args) "back to the back of the queue, waiting for the event to be processed.

When the condition is not satisfied in the condition determination processing of step 1403, that is, when the condition is not the object of the short-time lock, “toWhom” is determined in the processing of step 1405.
Is defined as “f”, and “f (event, fromWhom, ar
gs) ". By repeating this, in the short-time lock, if the lock is released, the event stored in the event queue is executed by the function corresponding to the module.

The processing of the action generation method including the short-time lock command will be described in detail with reference to FIG. FIG. 15 is a flowchart showing a second processing operation example of the automatic program generation system in FIG. 1 according to the present invention.
It is an AD diagram. This example shows another processing procedure example of the operation code generation unit 2f in FIG. 1 shown in FIG.
This is an action generation procedure including a short-time lock command, and the loop in the processing of step 1206 in FIG. 12 is replaced with the one in FIG.

That is, the variable “Acts” is used as a list of all the operations described in the state, and a code is generated for all the operations “A” in the process of step 1502. This example is different from the example in FIG. 12 in the case of the operation “A”, and in that the case where the operation “A” is LockShortMeWithout (M1,...) Is added. In this case, in step 1508, a code “lockStatus = LOCKEDSHORT” is generated, and then, in step 1509,
Generate code to put "M1, ..., Mn" into "moduleList".

As described above with reference to FIGS. 1 to 15, in the automatic program generation system and method of the present embodiment, the description system of the state transition automaton is expanded, the lock state is incorporated in the automaton in advance, and the automaton is generated. When an event is sent to a locked automaton, a program that sends back an event indicating that it is currently locked is generated. Can be expressed by a description that issues one.

Thus, software such as a distributed system which is connected to many devices and a plurality of terminals and reacts to events of the plurality of devices and events from another system is constructed by describing the state transition automaton. In some cases,
The user (system developer) can realize complicated lock control (exclusive control: control for not receiving a request from another device or terminal while performing one job) with a simple description.

The present invention is not limited to the embodiment described with reference to FIGS. 1 to 15, and can be variously modified without departing from the gist thereof. For example, in this example, the program is provided from an optical disk, but another computer-readable recording medium such as an FD (flexible disk) may be used.

[0098]

According to the present invention, even in the description of a system requiring lock control, a state for sending back an event indicating that the event is locked with respect to all events that may be sent. A system in which one terminal has to respond to many events, such as a system for providing services to remote customers / residents via a network in a field such as finance or public, in which a user does not have to write each transition. Can be efficiently generated.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an embodiment of a configuration according to the present invention of an automatic program generation system of the present invention.

FIG. 2 is a block diagram illustrating an example of a device configuration of an automatic program generation system in FIG. 1;

FIG. 3 is an explanatory diagram showing a detailed example of a state definition in FIG. 1;

FIG. 4 is an explanatory diagram showing a detailed example of a state transition definition in FIG. 1;

FIG. 5 is an explanatory diagram showing an example of a diagram language for graphically expressing a module expressed by a state definition and a state transition definition in FIGS. 3 and 4;

FIG. 6 is an explanatory diagram showing an example of the entire configuration of a program generated by the automatic program generation system in FIG. 1;

FIG. 7 is an explanatory diagram showing a detailed configuration example of a module corresponding function in FIG. 1;

FIG. 8 is a PAD diagram showing an example of a procedure of a lock event process in FIG. 1;

FIG. 9 is an explanatory diagram showing a detailed configuration example of a state / lock state storage area in FIG. 1;

FIG. 10 is a PAD illustrating an example of a processing procedure of a state transition code generation unit in FIG. 1;

FIG. 11 is an explanatory diagram showing an example of generating a state transition code in FIG. 1;

FIG. 12 is a PAD diagram showing a first processing operation example of the automatic program generation system in FIG. 1 according to the present invention;

FIG. 13 is an explanatory diagram showing a specific example of an operation code in FIG. 1;

FIG. 14 is an explanatory diagram showing an example of a procedure for managing an event queue storage area by the program in FIG. 1;

FIG. 15 is a PAD diagram showing a second processing operation example of the automatic program generation system in FIG. 1 according to the present invention;

FIG. 16 is an explanatory diagram showing a description example of an operation definition in each state.

FIG. 17 is an explanatory diagram showing a description example of a state transition in each state.

FIG. 18 is an explanatory diagram showing an example of a diagram language for graphically expressing modules represented by the state definition and the state transition definition in FIGS. 16 and 17;

FIG. 19 is an explanatory diagram showing a description example of a state transition for lock control according to the related art.

[Explanation of symbols]

1: System description, 1a: Module definition, 1b: State transition definition, 1c: State definition, 1d: Lock designation, 2:
Program generation unit, 2a: event management engine and event queue generation unit, 2b: module corresponding function code generation unit, 2c: state storage area generation unit, 2d: lock time code generation unit, 2e: state transition code generation unit, 2f: Operation code generator, 2g: lock code generator, 3: program, 3a: event management engine code, 3b:
Event queue storage area, 3c: module corresponding function code, 3d: state / lock state storage area, 3e: locked event processing code, 3f: state transition code, 3g:
Operation code, 3h: lock code, 21: display device,
22: input device, 23: information processing device, 24: auxiliary storage device, 25: optical disk, 26: optical disk drive device,
31: state name (field), 32: initial state (field), 33: operation definition (field), 41: state name (field), 42: event name (field), 4
3: Next state name (field), 51: Initial state "IDO
L ", 52: state" Printing ", 53: operation definition, 5
4: state “Completed”, 55: operation definition, 56: state “Incompleted”, 71: header part, 72, 73: label, 74: field, 75: call processing of runtime routine, 76: locked state and exclusion Processing for recording a list of modules to be locked, 77: processing for releasing a locked state, 78: instruction (return), 91: declaration section, 1
61: state definition, 162: state name (field), 16
3: initial state (field), 164: operation definition (field), 171: state transition definition, 172: state name (field), 173: event name (field), 17
4: next state name (field), 181: module,
182: state “IDOL”, 183: operation definition, 184: state “Printing”, 185: operation definition, 186: state “Co”
mpleted ", 187: state" Incompleted ", 191:
"IDOL" state, 192: "Printing" state, 193:
"Answering LockStatus A" status, 194: "Answerin
g LockStatus B "state, 195, 196: operation definition.

Claims (5)

[Claims] 1. A program automatic generation system for automatically generating a corresponding program by computer processing based on a description of a state transition automaton, wherein a transition of a lock state for performing a predetermined exclusive control operation is described from the description of the state transition automaton. Lock code generation means for generating a program that detects and, in response to the detected transition of the lock state, returns an event indicating that it is locked to an external event is provided, and is incorporated in the state transition automaton in advance. An automatic program generation system for generating a program for performing the predetermined exclusive control operation based on the transition of the lock state. 2. The program automatic generation system according to claim 1, wherein the lock state pre-installed in the state transition automaton includes a description for specifying a predetermined external event, and the lock code generation means includes: An automatic program generation system comprising: means for generating a program for returning an event indicating that the event is locked with respect to an external event other than an external event. 3. The automatic program generation system according to claim 1, wherein the transition of the short-time lock state specifying an operation to wait for release of the lock state is described by the state transition automaton. Means for detecting the short-time lock state, and transmitting the event indicating that the external event is transmitted to the state transition automaton of the source of the external event in response to the description of the transition of the detected short-time lock state. Means for generating a program that causes the original state transition automaton to wait for the short-time lock state to be released. 4. A program automatic generation system according to claim 1, wherein a transition of an unlock state for releasing the lock state is detected from a description of the state transition automaton; Means for generating a program for releasing the locked state in accordance with the description of the detected transition of the unlocked state. 5. A program automatic generation method for automatically generating a program of the system by performing computer processing based on a description of a system using a state transition automaton and performing a predetermined exclusive control operation from the description of the state transition automaton. Detecting a transition of the lock state, identifying the predetermined external event included in the detected transition of the lock state, and specifying the external event excluding the specified external event. Generating a program that returns an event representing the lock state; and detecting, from the description of the state transition automaton, a transition of a short-time lock state designating an operation to wait for release of the lock state. Corresponding to the short-time lock state transition described above, Generating a program for sending back to the state transition automaton an event indicating that the state is locked for a short time, generating a program for causing the state transition automaton of the transmission source to wait for the release of the short-time lock state, and Detecting a transition of an unlock state for releasing the locked state from the description of the above, and generating a program for releasing the locked state corresponding to the description of the detected transition of the unlock state. And generating a program for controlling the predetermined exclusive control operation based on a description of the transition of the lock state previously incorporated in the state transition automaton.