JP2015095134A - Screen coordination program and screen coordination system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique for operating a program having a GUI that includes a plurality of screens by dividing it into a plurality of independent programs.SOLUTION: A screen coordination program of the present invention coordinates first and second programs having a GUI. When receiving a request for instructing to start the second program from a first program, the screen coordination program starts the second program by using output data that is output by the first program as input data to the second program.

Description

  The present invention relates to a technology for linking a program having a GUI (Graphical User Interface).

  Examples of applications that operate on a computer include a Web application that operates on a Web browser and a stand-alone application that operates independently. Of these, the stand-alone application generally has a GUI as an interface for the user to operate.

  The GUI needs to define the type and arrangement of each screen component in a development tool for developing a stand-alone application. In addition, it is necessary to separately develop a program source code that defines the operation of each screen component. When developing a GUI with a large number of screens (for example, several hundred screens), it is considered that a plurality of developers will develop a program source code that defines the operation of these screen components.

  A stand-alone application is finally integrated as one executable file even if the program source code is developed by a plurality of developers in a distributed manner. Therefore, it is necessary to integrate the program source code developed in a distributed manner with the program source code of the main module. As described above, this situation does not change even when a plurality of developers develop a program code that defines the operation of a screen component.

  Since the operation of the screen component is directly experienced by the user of the stand-alone application, the operation of each screen component should be unified. However, when a plurality of developers develop the program source code for each screen component, adjustment work is often required to unify the operations. Also, if the internal operations such as in-program variables defined by each developer are different for each program source code, there is a possibility that problems may occur when these are integrated. Need to be removed.

  Since such work is performed manually, the work load is large. In addition, when a defect is found in the integration test of each program source code, it is necessary to re-execute the unit test of each program source code, resulting in a burden of returning to the process.

  In addition, a stand-alone application having a GUI with a large number of screens is generated by integrating a large number of program source codes corresponding to each screen component, so that the size of an executable file tends to increase. If the size of the executable file increases, the computer that executes the executable file needs to have a corresponding computing resource, which tends to increase the cost. Furthermore, since the load on the computer increases, the operation of the computer may become unstable.

  The present invention has been made in view of the above-described problems, and an object of the present invention is to provide a technique for dividing a program having a GUI including a large number of screens into a plurality of independent programs to operate.

  The screen linkage program according to the present invention is a program that links the first and second programs having a GUI. When a request instructing to start the second program is received from the first program, the output that the first program outputs The second program is activated using the data as input data for the second program.

  The screen cooperation program according to the present invention can provide the same GUI as that of a single stand-alone application as a whole by linking a plurality of programs having a GUI. Since each program can be developed as a separate application, there is no need to integrate them. Therefore, the above-mentioned problems associated with distributed development of stand-alone applications having a large number of screens can be solved.

1 is a configuration diagram of a computer 100 that executes a screen cooperation program 120 according to Embodiment 1. FIG. FIG. 3 is a diagram illustrating a GUI displayed on the screen by the first GUI program 131 when the first GUI program 131 is executed on the computer 100. It is a figure which shows the structure of a correspondence table 210, and a data example. It is a sequence diagram explaining the operation | movement which each program cooperates. FIG. 3 is a diagram illustrating a GUI displayed on the screen by the second GUI program 132 when the second GUI program 132 is executed on the computer 100. It is a figure which shows the example of data of the correspondence table 210 in Embodiment 2. FIG. FIG. 6 is a sequence diagram for explaining the operation of each program when a “Previous screen” button on the screen shown in FIG. 5 is pressed. FIG. 6 is a sequence diagram for explaining the operation of each program when a “Previous screen” button on the screen shown in FIG. 5 is pressed.

<Embodiment 1>
FIG. 1 is a configuration diagram of a computer 100 that executes a screen cooperation program 120 according to the first embodiment of the present invention. The computer 100 includes a CPU (Central Processing Unit) 110, a screen cooperation program 120, a plurality of GUI programs (here, a first GUI program 131 to a third GUI program 133), and a storage device 200.

  The first GUI program 131 to the third GUI program 133 are each configured as a stand-alone application having a GUI. These GUIs are configured to have an appearance as if they were individual operation screens included in a GUI provided by a single stand-alone application when viewed from the user. That is, by operating the first GUI program 131 to the third GUI program 133 in cooperation with each other, a user interface similar to the GUI provided by a single stand-alone application can be provided. The number of GUI programs is not limited to this, but the following three GUI programs are used for the sake of simplicity.

  Each GUI program outputs data to be delivered to the GUI program corresponding to the next operation screen as output data. The GUI program corresponding to the next operation screen uses the output data as input data for itself. As a result, data input or processed in the previous operation screen can be transferred to the GUI program corresponding to the next operation screen. The data format should be agreed in advance between the developers of each GUI program. The details of screen cooperation via input data and output data will be described again in the following drawings.

  The screen cooperation program 120 is a program responsible for mediation processing for operating the first GUI program 131 to the third GUI program 133 in cooperation with each other. The screen cooperation program 120 can be configured as a program that each GUI program is activated as necessary, or can be configured as a resident program that is always activated. In the following, it is assumed that the program is configured as a resident program.

  The storage device 200 is a device such as a hard disk device, and stores a correspondence table 210. The correspondence table 210 is a data table used by the screen linkage program 120 to link each GUI program. Details will be described later. Each program can be stored in the storage device 200, or can be stored in an internal storage device such as a ROM (Read Only Memory) (not shown). These are not particularly distinguished below.

  In the following, for convenience of description, each program may be described as an operation subject. However, it is added that the CPU 110 actually executes these programs.

  FIG. 2 is a diagram illustrating a GUI displayed on the screen by the first GUI program 131 when the first GUI program 131 is executed on the computer 100. In the example illustrated in FIG. 2, the first GUI program 131 is configured to be able to designate three operation screens to be shifted next in addition to some input items. When the user presses the “next screen” button, the screen transitions to the GUI provided by the second GUI program 132. When the user presses the “detail setting” button, the screen transitions to the GUI provided by the third GUI program 133, and the “confirmation screen” button is clicked. When pressed, it is assumed that the screen transitions to a GUI provided by a fourth GUI program (not shown).

  Since the GUIs of these transition destination screens are configured as independent stand-alone application programs, the first GUI program 131 cooperates with these programs via the screen cooperation program 120. Details will be described later.

  FIG. 3 is a diagram illustrating the configuration of the correspondence table 210 and data examples. The correspondence table 210 is data describing information necessary for linking GUI programs, and includes a transition source screen ID field 211, a transition destination screen ID field 212, a transition destination execution file field 213, and a transition destination input file field 214. Have.

  The transition source screen ID field 211 and the transition destination screen ID field 212 specify the IDs of the transition source operation screen and the transition destination operation screen, respectively, when a screen transition occurs between the operation screens provided by each GUI program. Defines screen transitions between GUI programs. For example, the data example in the first row describes that transition from the transition source screen ID = 1 (corresponding to the first GUI program 131) to the transition destination screen ID = 2 (corresponding to the second GUI program 132) is possible. .

  The transition destination execution file field 213 describes the execution file name of the GUI program that provides the GUI of the transition destination screen. The transition destination input file field 214 describes the file name of the output data of the GUI program that provides the transition source screen (that is, the file name of the input data of the GUI program that provides the transition destination screen). For example, in the data example of the first line, the execution file name of the second GUI program 132 is “GUI2.exe”, the file name of the output data of the first GUI program 131 (that is, the file name of the input data of the second GUI program 132). Is “OUTPUT1.dat”.

  A record of the correspondence table 210 needs to be created for each combination of the transition source screen and the transition destination screen. For example, according to the example shown in FIG. 2, it is necessary to provide three records corresponding to the first GUI program 131 (however, the fourth GUI is omitted in FIG. 3).

  FIG. 4 is a sequence diagram illustrating an operation in which each program cooperates. Here, the operation when the user presses the “next screen” button in FIG. 2 is illustrated. Hereinafter, each step of FIG. 4 will be described.

(FIG. 4: Step S401)
The user of the first GUI program 131 presses the “next screen” button in FIG. 2 on the screen of the computer 100. The first GUI program 131 transmits a request for instructing to start the GUI program corresponding to the “next screen” to the screen cooperation program 120. At this time, the ID of the first GUI program 131 itself (corresponding to the transition source screen ID field 211) and the ID of the second GUI program 132 (corresponding to the transition destination screen ID field 212) are specified together with the request.

(FIG. 4: Step S401: Supplement 1)
As a means for the first GUI program 131 to transmit the request of this step to the screen cooperation program 120, for example, the screen cooperation program 120 opens a predetermined TCP port and waits for the request, and the first GUI program 131 has its port number. It is conceivable that the request is transmitted by socket communication by specifying. Other means may be used.

(FIG. 4: Step S401: Supplement 2)
It is assumed that the first GUI program 131 knows in advance which operation screen to transition to when each button is pressed. Further, it is assumed that the first GUI program 131 knows its own ID and the ID of each transition destination screen in advance. These pieces of information can be embedded as program code in the first GUI program 131, for example, or can be described in external data such as a setting data file that can be read by the first GUI program 131. The same applies to other GUI programs.

(FIG. 4: Step S402)
The first GUI program 131 issues a request in step S401, and outputs data to be transferred to the transition destination screen such as items and processed data input on the first GUI program 131 as output data. The screen cooperation program 120 acquires the output data.

(FIG. 4: Step S402: Supplement)
The file name of the output data of each GUI program can be fixedly determined according to a predetermined file name rule or the like, can be described in external data such as a setting data file, and the field in the correspondence table 210 It can also be described as As long as the screen cooperation program 120 can know the file name of the output data, specific means may be arbitrary. The file name here includes a file path. The same applies to the cases not specifically mentioned below.

(FIG. 4: Step S403)
The screen cooperation program 120 queries the correspondence table 210 using the IDs corresponding to the transition source screen ID field 211 and the transition destination screen ID field 212 specified by the first GUI program 131 in step S401 as keys. Thereby, the transition destination execution file field 213 and the transition destination input file field 214 corresponding to the combination of these IDs can be acquired.

(FIG. 4: Step S404)
The screen cooperation program 120 starts the second GUI program 132 that provides the transition destination screen of the “next screen” button using the value of the transition destination execution file field 213 acquired in step S403.

(FIG. 4: Step S404: Supplement)
Since each GUI program is configured as an independent stand-alone application, it is logically possible to directly start the second GUI program 132 without using the screen cooperation program 120. However, if this is permitted, the cooperation between the GUI programs may be interrupted, and an unexpected operation may occur. Therefore, for example, when each GUI program is started, in the initialization process in each GUI program, it is checked whether or not it is started via the screen linkage program 120, and is started without going through the screen linkage program 120. May end itself with an error. For example, a method of realizing this by acquiring the process handle of the activation source program can be considered, but the implementation means is not limited to this.

(FIG. 4: Step S405)
The screen cooperation program 120 delivers the output data of the first GUI program 131 acquired in step S402 to the second GUI program 132 as input data for the second GUI program 132. In the simplest case, the value of the transition destination input file field 214 acquired in step S 403 may be delivered as a command line argument to the second GUI program 132. In this case, steps S404 to S405 are executed integrally. Other means may be used.

(FIG. 4: Step S405: Supplement 1)
The reason why the transition destination input file field 214 is provided in the correspondence table 210 is that the data file name delivered to the GUI program on the next screen in this step is not necessarily fixed. For example, the reason why the second GUI program 132 is called is not necessarily the first GUI program 131, and in general, other GUI programs may call the second GUI program 132. That is, since the input data file name (output data file name of the GUI program corresponding to the previous screen) delivered to the second GUI program 132 in this step is not fixed, it is defined as setting data in the correspondence table 210 and is flexible. Enabled to set to.

(FIG. 4: Step S405: Supplement 2)
In this step or step S402, the screen cooperation program 120 checks whether or not the first GUI program 131 has properly output the input data. If the data cannot be acquired, the screen cooperation program 120 sends a request to the request transmission source in step S401. An error may be notified. The second GUI program 132 also performs a similar check, and may end itself with an error if input data cannot be acquired. In this case, when the screen cooperation program 120 detects that the second GUI program 132 cannot be normally started, it notifies the request transmission source in step S401 of an error in the same manner.

(FIG. 4: Step S406)
As an option, the second GUI program 132 can also acquire data uniquely held by the screen cooperation program 120 and display it on the GUI. This data is data that the screen cooperation program 120 acquires and holds in advance from the outside (Internet) of the computer 100, for example. This data can be obtained by the second GUI program 132 from its own data source, but the screen cooperation program 120 has obtained it all at once in consideration of the possibility that other GUI programs will use the same data. Is considered to be efficient. Therefore, this step is provided as an option.

<Embodiment 1: Summary>
As described above, the screen cooperation program 120 according to the first embodiment designates the transition source screen ID and the transition destination screen ID from the first GUI program 131 and instructs to start the GUI program corresponding to the next transition destination screen. A request to receive is received. The screen cooperation program 120 queries the correspondence table 210 using these IDs as keys, specifies the execution file name and input data file name of the corresponding second GUI program 132, activates the execution file, and delivers the input data. Thereby, it is possible to provide the same GUI as that of a single stand application by linking each GUI program while configuring each GUI program as an independent stand-alone application.

  Since each GUI program in the first embodiment has only one screen, the size of the execution file is relatively small and the load on the computing resources of the computer 100 is small. Therefore, even if the performance of the computer 100 is not high, a GUI application having a large number of screens can be provided. Furthermore, since the load on the computer 100 is small, the computer 100 can be operated stably.

  In addition, since each GUI program in the first embodiment operates as an independent stand-alone application, it is not necessary to unify the internal operation and mounting method of each GUI program among the GUI programs. Therefore, the adjustment work between the GUI programs, which has been conventionally performed in the integration test process, becomes unnecessary, and the development man-hour can be suppressed.

<Embodiment 2>
In the first embodiment, the screen configuration example that can transition from the first GUI program 131 to three or more GUI programs has been described. In the first embodiment, in order to cope with such various screen transitions, the GUI program and input data to be started next are specified by the combination of the transition source screen ID and the transition destination screen ID. However, depending on the screen configuration, there may be a case where there is no screen transition other than the screen transition to either the previous screen or the next screen. In the second embodiment of the present invention, the configuration of each program in such a case will be described.

  FIG. 5 is a diagram illustrating a GUI displayed on the screen by the second GUI program 132 when the second GUI program 132 is executed on the computer 100. In the example illustrated in FIG. 5, the second GUI program 132 is configured to be able to specify whether to return to the previous screen or to advance to the next screen. When the user presses the “previous screen” button, it is assumed that the screen transitions to the GUI provided by the first GUI program 131, and when the user presses the “next screen” button, the screen transitions to the GUI provided by the third GUI program 133.

  FIG. 6 is a diagram illustrating an example of data in the correspondence table 210 according to the second embodiment. In the second embodiment, since it is assumed that the screen transition is performed in the order of the first GUI program 131 → the second GUI program 132 → the third GUI program 133, the values of the transition source screen ID field 211 and the transition destination screen ID field 212 respectively. Are described so that ID = 1 to 3 are linked in the order shown. Further, since the second GUI program 132 calls the third GUI program 133, the input data to the third GUI program 133 is the output data (OUTPUT2.dat) of the second GUI program 132.

  Since each program in the second embodiment is the same as that in the first embodiment except that the screen configuration is different, the operation of each program is basically the same as that in the first embodiment. However, the operation for returning to the previous screen requires consideration different from that in the first embodiment. That is, when returning to the previous screen, the input items on the return source screen are not carried over to the return destination screen, so even if the operation of the first embodiment is used as it is, the operation to return to the previous screen is realized. Not.

  The operation to return to the previous screen is processed as a new screen transition based on the above problems, or as a screen transition to the previous one instead of causing a new screen transition. This can be realized. The specific operation will be described below.

  When the operation of returning to the previous screen is processed as a new screen transition, a record corresponding to the “Previous Screen” button in FIG. The record on the third line in FIG. 6 corresponds to this. That is, the transition source screen ID = 2 (corresponding to the second GUI program 132) and the transition destination screen ID = 1 (corresponding to the first GUI program 131) are designated.

  When returning to the previous screen, since the user has already input the input items on the returned screen, it is necessary to fill the input items on the returned screen with the input contents. That is, the data received as the input data from the first GUI program 131 is included in the output data of the second GUI program 132, and the first GUI program 131 needs to reflect this as the value of its own input item.

  However, it is desirable that the output data output from the second GUI program 132 is only data input or processed on the second GUI program 132. Therefore, instead of the second GUI program 132, the screen linkage program 120 holds the combination of the ID of the first GUI program 131 and its output data, and returns this when an operation to return to the previous screen occurs. Provided as input data for the previous screen. This may be provided instead of the output data of the second GUI program 132, or may be provided in addition to the output data of the second GUI program 132.

  When the operation of returning to the previous screen is processed so as to return the screen transition to the previous one instead of causing a new screen transition, the record in the third line in FIG. 6 is not necessary. This is because which screen to return to can be specified by tracing the reference relationship between records in the reverse direction. The data delivered to the return screen is the same as described above.

  FIG. 7 is a sequence diagram for explaining the operation of each program when the “previous screen” button on the screen shown in FIG. 5 is pressed. Here, the operation in the case of using the record in the third row in FIG. 6 is exemplified. Hereinafter, each step of FIG. 7 will be described.

(FIG. 7: Steps S701 to S704)
The second GUI program 132 specifies the ID of the second GUI program 132 itself and the ID of the first GUI program 131, and transmits a request similar to step S401 to the screen cooperation program 120. Other operations in steps S701 to S704 are the same as steps S401 to S404 in FIG. However, as described above, the screen cooperation program 120 needs to hold a combination of the ID of the first GUI program 131 and its output data.

(FIG. 7: Step S705)
The screen cooperation program 120 delivers the output data output when the first GUI program 131 calls the second GUI program 132 as input data to the first GUI program 131. Other operations in step S705 are the same as those in step S405 in FIG.

(FIG. 7: Step S706)
When the first GUI program 131 includes data previously output by the first GUI program 131 itself in the input data, the first GUI program 131 reflects this in input items on the first GUI program 131.

  FIG. 8 is a sequence diagram for explaining the operation of each program when the “Previous screen” button on the screen shown in FIG. 5 is pressed. Here, the operation in the case where the record in the third row in FIG. 6 is not used is illustrated. Hereinafter, each step of FIG. 8 will be described.

(FIG. 8: Steps S801 to S802)
The second GUI program 132 designates the ID of the second GUI program 132 itself and the return to the previous screen, and transmits a request similar to step S401 to the screen cooperation program 120. Other operations in steps S801 to S802 are the same as steps S701 to S702 in FIG.

(FIG. 8: Steps S803 to S806)
When the screen cooperation program 120 receives a request to return to the previous screen, the transition source screen is traced by tracing the reference relationship of each record in the correspondence table 210 using the designated transition source screen ID as a key. The screen immediately before the ID is specified. Other operations in steps S803 to S806 are the same as steps S703 to S706 in FIG.

<Embodiment 2: Summary>
As described above, when the screen transition program 120 according to the second embodiment receives a transition instruction to return to the previous screen, the output data output first by the return screen is input to the return screen. Deliver as data. Thereby, on the premise of the configuration of the first embodiment, it is possible to realize an operation for returning the screen transition.

  In the second embodiment, there may be a case where the operation of returning to the previous screen is performed a plurality of times (that is, returning to two or more previous screens). Therefore, it is desirable that the screen transition program 120 holds all combinations of the IDs of the GUI programs and their output data until the last GUI program in the series of screen transitions is completed. After the last GUI program is complete, it can be discarded. The instruction indicating that it is the last GUI program notifies the screen cooperation program 120 that the GUI program itself is the last screen instead of specifying the transition destination in step S701 (or S801). do it.

  In the second embodiment, it has been described that the output data previously output by the first GUI program 131 is retained, and the previous output data retained is reused when returning to the first GUI program 131. This operation can also be used in the configuration of the first embodiment. That is, since it is possible to return to the previously used screen in the process of the screen transition, the previous output data can be reused as input data for the return destination screen as in the second embodiment.

  100: computer, 110: CPU, 120: screen cooperation program, 131-133: first to third GUI programs, 200: storage device, 210: correspondence table.

Claims (10)

A program for causing a computer to execute a process for linking a first program having a GUI and one or more second programs having a GUI,
A request receiving step of receiving, from the first program, a request for instructing to start the second program when the first program ends;
An activation step of activating the second program according to the request;
An input data delivery step of delivering output data output from the first program to the second program as input data to the second program;
A screen linkage program characterized by causing The screen cooperation program is stored in the computer before the startup step.
Executing a step of reading a correspondence table defining a correspondence relationship between the ID of the first program, the ID of the second program, the execution file name of the second program, and the file name of the input data;
In the request receiving step, the computer
Along with the request, the ID of the first program and the ID of the second program are received,
In the startup step, the computer
By referring to the correspondence table using the ID of the first program and the ID of the second program received in the request receiving step as keys, the execution file name of the second program and the file name of the input data are obtained. After the acquisition, the execution file is started using the execution file name of the acquired second program,
In the input data delivery step, the computer
Passing the input data to the second program by specifying the file name of the input data acquired in the startup step as a command line argument when starting the second program in the startup step The screen linkage program according to claim 1. In the request receiving step, the computer
The transition instruction designating whether to proceed to the next screen or the previous screen of the screen provided by the GUI included in the first program is used as a request for instructing to start the second program. Receive from one program,
In the correspondence table, as the ID of the second program,
An ID of the second program having a GUI for providing the next screen and an ID of the second program having a GUI for providing the previous screen;
In the startup step, the computer
By referring to the correspondence table using the ID of the first program and the transition instruction received in the request reception step, the execution file name of the second program specified by the transition instruction and the file name of the input data The screen linkage program according to claim 2, further comprising: The screen cooperation program is stored in the computer.
The request reception step, the activation step, and the set of input data delivery step are executed a plurality of times,
The screen cooperation program is further stored in the computer.
A data holding step for holding a combination of output data output by the first program and the ID of the first program corresponding to the output data each time the set is executed;
In the request receiving step, when the second program that has been started in the starting step is instructed to start again, the output data stored in the data holding step is instructed to start again. 4. The screen linkage program according to claim 2, wherein the input data corresponding to the input data for the second program is used as the input data for the second program instructed to start again. In the request receiving step, the computer
Checking whether the output data to be delivered to the second program as the input data has been obtained from the first program;
A step of outputting an error notification to the effect when the output data to be delivered to the second program as the input data cannot be obtained from the first program;
The screen linkage program according to claim 1, wherein the screen linkage program is executed. The screen cooperation program is stored in the computer.
6. The screen according to claim 1, wherein a step of delivering data acquired from outside the computer to the second program is executed in response to a request from the second program. Cooperation program. The screen linkage program according to any one of claims 1 to 6, wherein the screen linkage program is configured as a resident program that is always activated on the computer. The screen linkage program according to any one of claims 1 to 7,
The first and second programs;
A screen linkage system characterized by comprising: The screen cooperation system according to claim 8, wherein the second program is configured to end itself with an error when started from a program other than the screen cooperation program. The screen cooperation system according to claim 8 or 9, wherein the second program causes the computer to display the GUI using the input data.

Images