JPH06274386A - Application development system for operating data base of window base - Google Patents

Abstract

PURPOSE:To reduce the man-hour of an application developing person with a graphical user interface for operating the entity relationship type data base as an object by using a pre-data preparation scenario and a data display scenario. CONSTITUTION:The graphical user interface(GUI) part 1 is composed of a pre-data preparation scenario part 2 for preparing data to be delivered to data processing and a data display scenario part 3 for displaying the result of data base processing. An application part 5 is provided with a data base management system 7 and a data base 6 which performs data-base-processing by receiving data from the pre-data preparation scenario part 2. With constitution like this, application controlling the operation of GUI by the execution of a scenario is prepared so as to improve the productivity of software.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD The present invention relates to a window-based application development system for database operation, and more specifically, to an application for GUI (Graphical User Interface) for ER (Entity-Relationship) type database operation. The present invention relates to a window-based application operating system for database operation that reduces the man-hours of developers.

[0002]

2. Description of the Related Art GUI (Graphical Us) based on a window
er Interface) is characterized by beautiful display and good operability by direct manipulation, and is especially essential for image database operation applications. However, since the window-based programming style is event-driven, it tends to be a low-level event-driven type that differs from the original processing order of the application, and as a result, the composition of the program becomes difficult to understand. The application developer describes the specification required by serially arranging a more abstract GUI action definition procedure called a callback object. Particularly in the case of a database based on the E-R model, there are various methods for expressing the many-to-many relationship between entities on the GUI, which causes difficulty in describing application specifications. In order to solve such a problem, the description method of the present invention using a callback object is also useful.

A multi-window-based GUI (Graphical User Interface) such as X Window System (registered trademark of Massachusetts Institute of Technology, USA) is widely used in database applications because of its beautiful display and good operability. It is popular. In particular, an image database application cannot perform image processing with a character-based UI (User Interface), so a GUI is essential. However, GUI software creation and maintenance is more difficult than general software, and it is difficult to improve software productivity. The following points can be considered as the cause of this. The program style is event-driven, so the structure of the program is difficult to understand. Higher degree of freedom in design than character-based UI.

As the cause of the above, this is because "the window programming style is event-driven, so low-level event-driven types such as mouse button pressing and button clicking, which are different from the original processing sequence of the application, are performed. It is because it becomes a writing style. " That is, the original control flow of the application is G
It is dragged by the UI part, and a group of functions intended by the application (for example, database search) is distributed to a plurality of GUI callbacks (Callback; procedure called by an event). Difficult to design, debug, modify and maintain.

Further, the same operation sequence may be shared between two different processes, or the operation sequences of another process may be mixed during the operation of one process. For example, the operation column that inputs search conditions in multiple text fields and the operation column that edits field values to update record occurrences both correspond to the operation column "Enter data in multiple text fields". is doing. Further, since the callbacks are flat with each other, it is difficult to set a specific mode. Flag variables are often used to set the mode, but this also only makes the program structure hard to see, and it is difficult to read the state transition from the program.

The above problems have been pointed out by many GUI researchers. As a workaround for this, "provide the user with an advanced framework that incorporates object-orientation, and the user selects an object that meets his or her needs from the class library, and the specifications are based on the user's own taste and ease of use. We will customize it to match. "

Next, regarding the above-mentioned cause, "the degree of freedom of design is higher than that of a character-based UI" must be defined by the application developer in both the screen definition and the action definition. It means that there are many elements. The X Window System refers to graphical objects that support a group of functions such as buttons, labels, and image windows.
t). Application developers can
Need to decide. Which widget to use to achieve a feature. How many variable values the widget has (variables that determine the shape of the widget, such as the margin of the frame and the background color; called widget resources). How to lay out a large number of widgets on the screen. This reflects a lot of sense and experience of application developers, and application developers need to know which widget set (OSF / Motif, XViews) to use.
Object hierarchy and restrictions between classes, and knowledge of style guides for each widget is required.

[0008]

[Purpose] The present invention has been made in view of the above circumstances, and is intended for a GUI (Graphical User Interface) for operating an ER (Entiny-Relationship) type database, thereby reducing the number of man-hours for application developers. The purpose is to provide a window-based application development system for database operation.

[0009]

In order to achieve the above object, the present invention provides (1)
By using a pre-data preparation scenario for preparing data to be passed to the database processing and a data display scenario for displaying the result of the database processing, it is possible to control the operation of the graphical user interface in the execution of the scenario. Or (2) a graphical user interface unit for executing a data preparation scenario for preparing data to be passed to the database process and a data display scenario for displaying a result of the database process, An application unit having a database management system for receiving data from a data preparation scenario and performing data processing, wherein the graphical user interface unit and the application unit are separated, or (3 And designating means for selecting a logical schema of interest from the portion of the database, specifying the number of widgets and type on the screen corresponding to the selected portion,
The widget is automatically displayed on the screen by determining means for determining the size of the widget designated by the designating means using the information in the data dictionary, and determining the size and type of the widget by the designating means and the determining means. And a creating means for creating a scenario by serially arranging callback objects for defining the operation of the graphical user interface using the screen obtained by the arranging means.
Alternatively, (4) if at least two entities are displayed on the screen and the first entity is the master in order to display the many-to-many relationship between the entities, the second entity is the slave. Using a master-slave model such that the scenario that describes the behavior of the callback object is created based on the master-slave model.
Furthermore, (5) In (4), among the entities,
The elements constituting the slave entity are realized by a data table or a text field, and each element is arranged by a combination of the text field and the data table. Hereinafter, description will be given based on examples of the present invention.

FIG. 1 is a flowchart showing how an application developer creates a DB (database) operating GUI by the window-based database operating application development system according to the present invention. As an example, a GUI for operating the personnel database as shown in FIG. 2 is created. This G
The UI is composed of the following three record types. Employee (EMPLOYEE) Affiliation (DEPT) Project (PROJECT) In response to a query "Are you an employee in Tokyo who is participating in the 4GL project?" The search result of is displayed. When you click on one of the data with the mouse, detailed information about that data is displayed in the text field in the center. Until the next database operation is issued, the end user displays the desired data by moving the scroll bar of the data table or clicking the desired data.

The steps will be described below in order. step1 : The developer visually selects a portion of interest from the DB logical schema (a complete description of a database) and specifies the number and types of widgets on the screen corresponding to it. The number, types, and sizes of widgets will be described with reference to FIG. As described above, FIG. 2 is an example of a screen display of the personnel database operating GUI. In the figure, section A is an operation button area having a plurality of command buttons, section B is a text field area for displaying personal data, and section C is It is a data table which displays a personal name list. In the operation button area A, "CONDITIO
"N" (condition), "RETRIEVE" (search), "PR"
Various command buttons such as “INT” (print) are provided. In the data table C part, the names (NAME) of a plurality of employees (EMP) are listed together with the employee number (No). The specific individuals listed in this data table (eg "Yukari Shiro
If you select "ta"), detailed personal information of the person is displayed in the text field area. That is, employee number "123984", date of birth "1970/12/31", affiliation "Plannin
g ”Project“ Form Recognition, 4GL, X11R5 ”etc. is displayed.

Table 1 below shows data internally generated as a result of designating the number and types of widgets. Meaning is "G of the EMPLOYEE record type
The target of the UI is EMP #, NAME, ADD
There are five fields, R, BIRTH, SALARY, and PHOTO, which are represented on the GUI by a set of Widget TextFields (TextFieldSet). " PRO
For the JECT record type, the NAME field is represented by an array of 5 text fields of the same type. Also,
EMPLYEE record type 5 fields EMP
#, NAME, SALARY, MEMO, PHOTO
Is represented by a data table widget.

[0013]

[Table 1]

[0014] step2: the system determines the size of each widget by using the information in the data dictionary. For example, "ch
If the "ractor 14 characters" is registered in the data dictionary, the system will size the widget so that 14 characters can be displayed. If the length is long, such as variable length, set a default value in advance and follow it. step3 : Once the size and type of widget are determined, the widget is placed on the screen by the system's automatic layout function. For example, a layout as shown in FIG. 2 can be obtained. step4 : Using the resulting screen, the developer defines the behavior of the GUI by arranging the callback objects in series. This sequence of callback objects is called a scenario.

Next, as described in the section of the prior art,
Explain the problem solving approach of. First, in response to “It is difficult to understand the program structure because the program style is event-driven”, by providing a callback object, an object that realizes a set of processing intended by the user, Try to solve. To solve another problem, "the degree of freedom in design is higher than that of a character-based UI", by letting the system semi-automatically perform the ray-ite on the widget screen, Reduce the work of application developers. This automatic layout function seeks a quasi-optimal solution by performing a system evaluation on a large number of randomly-arranged candidate groups based on the visibility for humans.

For example, the process of "inputting search conditions" is executed by one callback object FillInCondition.
Will be realized in. As shown in FIG. 3, a plurality of widgets such as a text field, a toggle switch, and a list box are associated with the object, and a plurality of primitive event / callback pairs exist among them. That is, in FIG. 3, company names A to E are written in the list box (right frame), and when A company is selected, A company is written in the company name frame in the text field (upper left frame). The telephone number and the office name are displayed with a toggle switch. The end user turns on the toggle switch of the business office that desires to search.

However, as a highly functional object, Fil
When you look at lInCondition, the relationship between internal widgets is hidden and invisible from the outside. Providing such a high-performance object to the developer as an application framework improves the following points. Parts can be reused. You don't have to build from scratch, you just need to make modifications to your existing class library. Prevent the event loop from becoming huge. Improves visibility of the entire application. Application design will be formalized, and development period can be shortened.

Next, the scenario descriptive ability (descriptive
power). In order to express all UI state transitions, there should be no restrictions on the exchange of messages between objects, but in the description specifications of the system of the present invention, the good visibility of the structure for the developer is given priority. , Restricted that callback objects can only be placed in series. For this reason, the developer is UNIX
Like the pipe filter command of, the operation of the GUI can be defined by joining the callback objects. (Below margin)

The diagram shown in FIG. 4 is the GU of FIG.
Internal data generated when I is defined by the developer. The scenario type specifies data retrieval (retrieve), and the access path is DEPARTMENT ../ DEPT_EMP / .. EMP
It is specified as LOYEE ../ PROJ_WORK / .. PROJECT. The search condition input area is EMPLOYEE: TextFieldSet PROJECT: TextFieldSet. The search result is called the target, but its identifier is
Retr1 is set. The whole application process is
The following loops (a) to (e) are repeated. Of these, the application developer defines a scenario for the GUI part. These are called Prepare Data Scenario and Display Date Scenario.

This scenario defines only the relationship between widgets on the screen, and the application itself is not contacted during this period. (A) Preparation of data to be passed to database processing (GUI
Part)-> Prepare Data Scenario (b) Database front-end processor (FE)
Generation of database inquiry statement by P) (c) Database processing (application body) (d) Conversion of data structure of processing result (e) Display of processing result (GUI section) → Display Data
Scenario

The processes (b) and (d) above are performed by the GU
This is the interface between the I part and the application itself. Multiple database management systems (D
BMS), the database front-end processor (DB FEP) absorbs the difference in the language interface of the DBMS. The DB FEP generates an inquiry sentence suitable for each DBMS from the data passed from the GUI unit. In addition, the result of database processing is
In order not to depend on the data model of BMS, G
Convert everything to a theoretical tabular format before passing it to the UI section. The protocol between the GUI part and the application body, including the notification of errors, will be standardized.

FIG. 5 is a system configuration diagram corresponding to the operation of the GUI for operating the personnel database shown in FIG. 2, where 1 is a GUI unit and 2 is a Prepare Data Scenario.
(Data preparation scenario) section, 3 is Display Data Scena
rio (data display scenario) section, 4 a database front-end processor (DB FEP), 5 an application (database) section, 6 a database (D)
B) and 7 are database management systems (DB)
MS). As shown here, the control flow is largely divided into two parts, the GUI part 1 and the application part 5. In the GUI part 1, the above-mentioned Prepare Date Sc
Two of enario and Display Data Scenario are executed. That is, the GUI unit 1 includes a Prepare Data Scenario unit 2 and a Display Data Scenario unit 3, and the application unit 5 includes a database 6 and a DBMS 7.

In the example of FIG. 5, Prepare Data Scenario section 2
In, when the “CONDITION” button is pressed, “FillinCondition” is executed next. Therefore, "EMPLOYEE", "PROJEC
Search conditions are entered in the "T" text field set,
Next, when the end user presses the "RETRIEVE" button, the search is started. When a query sentence is input to the DBMS 7 via the DB front-end processor 4, the DB
The MS 7 performs processing using the DB 6, the processing result is input to the Display Data Scenario section 3 on the GUI section 1 side, and a list of "EMPLOYEE" is displayed in the data table. Select one of them (SelectOn
e), the employee's information is displayed in the EMPLOYEE text field set.

In slaveDisplay, "EMPLOYE
"E" is the master (main), "DEPARTMENT"
And “PROJECT” have a relationship of “slave” (subordinate), in which the affiliation name and the project name are described. The master / slave model will be described later. The following shows how to write the scenario shown in FIG.

[0025]

[Table 2]

The search condition is input from the specified condition input area. The search condition input start is started with the "CONDITION" button, and the signal of the condition input end is "RETRIEE".
Depressing the "VE" button.

[0027]

[Table 3]

Target is a search result. Generally, since there are multiple search results, multiple data are displayed in the EMPLOYEE data table (select). Next, select one data with selectOne and display it in the EMPLOYEE text field set in the center of the screen.
After that, EMPLOYEE is used as a master, and its slaves, DEPARTMENT and PROJECT, are displayed (slaveDisplay). There will be the following two master-slave relationships. (1) Master: EMPLOYEE (text field set) Slave: DEPARTMENT (text field set) (2) Master: EMPLOYEE (text field set) Slave: PROJECT (text field array)

Next, the master / slave model will be described. Although many user interfaces for ER type DB operation have been proposed, "It is convenient to handle a schema using an ER diagram, but it lacks the ability to express many-to-many relationships. Since it is sufficient, it is not suitable for query processing and browsing of processing results. " The end user's demands for displaying and operating a many-to-many relationship are various, and it is desired to display a multi-step many-to-many relationship at one time for efficient operation. It is much more complicated than the above example, and there are many things that the current description ability of 4GL products cannot cover.

For example, assume there are two sets of many-to-many relationships as shown in the ER diagram of FIG. This means "an employee may belong to multiple departments, and each department owns multiple workstations". That is, "EMPLOYEE" (entity)
Between "DEPT" (entity) and "DEPT_EMP"
, "DEPT" (entity) and "WOR"
There is an association of “HAS” with “KSTATION” (entity). Then, in FIG. 6, “EMPLOYE
When looking at "DEPT" from "E", it is shown that the employee may belong to the M departments, and conversely, there may be N employees viewed from a department. ing. The same applies to the relationship between "DEPT" and "WORKSTATION".

FIGS. 7A to 7C are GUI representations of the above-mentioned many-to-many relationship. In FIG. 7 (a),
Three departments of "Bob Brown" (name) who is an employee of "4562" are displayed in "DEPARTMENT",
When "plannning" which is the department of data No. 2 is selected, the data table "WORKSTATIO" is selected.
N ”, data NO and workstation name (ella
Etc.) is written. Thus, some developers
As in the example of (a), display the affiliation in the data table,
The workstation owned by one of the selected departments is displayed in the adjacent data table.

In FIG. 3A, "DEPARTME
"NT" is displayed in the data table and one of them is selected and the corresponding "WORKSTATION" is displayed, while in Fig. (B), "DEPAR" is displayed.
All of "TMENT" are displayed at one time, and the corresponding "WORKSTATION" is displayed. That is, this is realized by the arrangement of the text field and the element 3 of the data table. In the figure (c), "W
ORKSTATION "is displayed on the data No. Only one or two is used. That is, WORKSTATI
ON is also represented by an array of two elements of the text field.

In the development system of the present invention, a master / slave model is introduced in order to clearly define the operation of the many-to-many relationship, and the operation of the callback object is defined based on this. In order to display a many-to-many relationship, it is necessary to limit either one to one occurrence,
That side is called the master side and the other side is called the slave. The example of FIGS. 7A to 7C is described by the following scenario as shown in FIG. The name written in italic font in the table below is the callback object name. Assume that the access path in this example is EMPLOYEE ../ DEPT_EMP / .. DEPT ../ HAS / .. WORKSTATION.

[0034]

[Table 4]

First, the master is EMPLOYEE and the slave is
It is DEPT. Generally, there are multiple search results, so select one data item and display it in EMPLOYEE.
This is the role of the callback object selectOne. A slave D for this EMPLOYEE data
Display EPT data. That is the operation of slaveDisplay. The display destination is DEPT: DataTable. Next, DEPT will be the master side and WORKSTATION will be its slave side.

[0036]

[Table 5]

Next, in Table 5, the point different from Table 4 is EMP.
The display destination of DEPT, which is a slave of LOYEE, is that there are three text fields. Then, for each text field, one data table is attached for slave display.

[0038]

[Table 6]

In Table 5, WORKS that became a DEPT slave
The display widget of TATION was a data table, but in Table 6, it is different in that it is an array of the text field of element 2. In the case of the examples of Table 5 and Table 6, the number of slave data may be larger than the number of widgets prepared on the screen. At this time, there are two ways of dealing with the following, but it is possible to describe such specifications. Error: After displaying DEPT, execution is stopped there and waits for a user command. Warning: DEPT and WORKSTAT as much as possible
Displays ION and does not stop execution.

[0040]

[Effect] As is clear from the above description, a database operation GUI aiming at improving application productivity
I explained the development system. And the following effects are produced. (1) The GUI operation can be abstracted by the callback object. (2) It is possible to clarify the specification description on the many-to-many relationship by the master / slave model. (3) Screen layout work can be reduced by the automatic layout function.

[Brief description of drawings]

FIG. 1 is a flowchart for creating a GUI of an application development system for operating a window-based database according to the present invention.

FIG. 2 is a personnel database operating G that is an example developed using the application development system according to the present invention.
It is a figure which shows the example of a screen display of UI.

FIG. 3 is a diagram showing an example of highly functionalized objects of the application development system according to the present invention.

FIG. 4 is a diagram showing internal data generated after defining a scenario of the application development system according to the present invention.

5 is a system configuration diagram corresponding to the operation of the GUI in FIG.

FIG. 6 is a diagram of a many-to-many relationship for explaining the master / slave model of the application development system according to the present invention.

FIG. 7 is a diagram showing various representation methods on the GUI of the many-to-many relationship of the application development system according to the present invention.

[Explanation of symbols]

1 ... GUI part, 2 ... Prepare Data Scenario part, 3 ... Display Data Scenario part, 4 ... Database front-end processor (DB FEP), 5 ... Application (database) part, 6 … Database (DB), 7…
Database management system (DBMS).

Claims (5)

[Claims] 1. By using a data preparation scenario for preparing data to be passed to a database process and a data display scenario for displaying a result of the database process, the graphical user interface of a graphical user interface A window-based application development system for database operation, which is characterized by creating an application that controls operations. 2. A graphical user interface unit for executing a data preparation scenario for preparing data to be passed to the database processing and a data display scenario for displaying a result of the database processing, and data from the data preparation scenario. A window-based application development system for database operation, comprising: an application section having a database management system for receiving and processing data; wherein the graphical user interface section and the application section are separated. 3. A selection means for selecting a target portion from a logical schema of a database and designating the number and types of widgets on the screen corresponding to the selected portion, and information of a data dictionary, Deciding means for deciding the size of the widget designated by the designating means; arranging means for automatically laying out the widget on the screen by deciding the size and type of the widget by the deciding means and the deciding means; A window-based application development application for database operation, characterized by comprising a creating means for arranging callback objects for defining the behavior of the graphical user interface in series using the screen obtained by the means to create a scenario. system. 4. The first entity is a master, and the second entity is a slave in order to have at least two or more entities displayed on the screen, and to display a many-to-many relationship between the entities. A window-based application development system for database operation, characterized by using a master-slave model such that and creating a scenario that describes the behavior of a callback object based on the master-slave model. 5. An element constituting a slave entity among the entities is realized by a data table or a text field, and each element is arranged by a combination of the text field and the data table. Item 4. An application development system for operating a window-based database according to Item 4.