JP4939007B2 - System design support program - Google Patents

Description

  The present invention relates to a system design support program used for system design of a business-oriented system, and relates to a program used for a so-called CASE (Computer Aided System Engineering) tool.

  Conventionally, a CASE tool that supports design of a system has been used in development of a system for business use. One of the CASE tools is “Xupper II (Cross Upper Two)” (registered trademark) developed by Ken System Development Co., Ltd.

In order to succeed in system development in today's drastic changes, it is necessary to accurately grasp user needs in the upstream process of design. “Xupper II” is a software tool for supporting upstream analysis design, and realizes a data-oriented approach (DOA) based on business flow diagrams and business rules that are easy to understand for end users.
Japanese Patent No. 3527658

  In general, the software development process includes a business analysis process for analyzing the client's business, a requirement definition process for defining the requirements for the client's business, a basic design process for designing the basic configuration of software that satisfies the requirements definition, and the details. The process is divided into an upstream process including a detailed design process to be designed, a program development process for creating each program constituting the software, and a downstream process including a test process for verifying the operation of the created program.

  However, since the conventional system design support tool “Xupper II” is an upstream design tool, when the program development process, which is a downstream process, is performed, the obtained design data is bridged to other downstream design tools. It must be handed over.

  In such a case, all of the created design data may not be used, and there is a problem that a great waste of time and cost occurs.

  It is an object of the present invention to solve the above-described conventional problems and to automatically perform program development as a downstream process without using a bridge and a manpower by using “Xupper II” as an upstream design tool. And

  In order to achieve the above object, the present invention adds “XupperII” from the upstream process by adding data necessary for generating source code to the repository (system-dedicated database) possessed by “XupperII”. The downstream process is automatically performed without using a bridge and manpower.

Specifically, a system design support program according to the present invention is directed to a system design support program using a data-centric approach, and includes a function A for hierarchizing an input business flow into a plurality of processes, A function B for creating a plurality of entities used in a process, an entity relation diagram representing the relationship between the entities, and a function C for creating a dictionary holding input / output data necessary for each process and field data of each entity Referring to entity relationship diagrams and dictionaries, register function D for graphical user interface design, layered data for each process, attribute data for each entity, dictionary and data for graphical user interface design. A function E for creating a repository and logic for referring to at least one of each process, each entity, data held in a dictionary and data related to a graphical user interface design, and enabling each process to be executed from the outside By inputting the definition, the function F for automatically generating and outputting the source code is realized. The function F uses the SQL syntax when inputting the logic definition, and when inputting the logic definition, When the input logic definition is defined in the SQL syntax, the interactive form by the wizard is used. On the other hand, when the input logic definition is not defined in the SQL syntax, the undefined logic definition is directly input. It is preferable to include a function for registering in the repository.

  According to the system design support program of the present invention, since it has the functions A, B, C, D and E corresponding to the functions of “Xupper II”, the data held in each process, each entity, dictionary, and the graphical user By referring to at least one of the data related to the interface design and inputting a logic definition that allows each process to be executed from the outside, the source code can be automatically generated and output.

  In the system design support program of the present invention, the Java language (registered trademark), the high-speed engine Procedure language, or the BizCRS language can be used as the source code.

  In the system design support program of the present invention, the source code in the function F has a function for executing the process for each process, and the function F includes the components of the logic statement for expanding the logic definition in the function, respectively. Is composed of a plurality of skeletons that are the source code framework, a function that decomposes a plurality of skeletons into a skeleton logic part, a generation logic part for each replacement character string, and a generation logic part for each user point. The function that replaces the generation logic part for each replacement character string with the data corresponding to the generation logic part for each replacement character string in the data registered in the repository, and the input logic for the generated generation logic part for each user point that has been disassembled It preferably includes a definition and a function to replace.

  In this case, the function F preferably includes a function that enables the skeleton logic unit to be rewritten from the outside.

System design support program of the present invention further includes a function G to register repository source code that is not automatically generated in advance as a macro function, function F, when automatically generating a source code, the macro fan click registered in the repository It is preferable to include a function of expanding the application into source code.

  In the system design support program of the present invention, the function C preferably stores the data type of the field data of each entity in the dictionary as the first master file according to the language type of the source code.

  In this case, when the function C performs at least one of data substitution, calculation, comparison, and call parameter matching executed between field data of each entity, the validity of each process to be performed It is preferable to include a function of holding a code for determining the second master file in the dictionary.

  Further, when the data type is converted to the first master file, the function C performs at least one of data assignment, comparison, and call parameter matching performed between field data of each entity. At this time, it is preferable to include a function of holding, as a third master file, a code for determining the validity of each output condition as a result of the processing performed.

  Further, when the data type is converted to the first master file, the function C is at least one of the data assignment statement, the conditional statement, the operation statement, and the parameter matching executed between the field data of each entity. When performing one process, it is preferable to include a function of holding a generation rule for each source code corresponding to the process to be performed as a fourth master file in the dictionary.

In the system design support program of the present invention, the function E includes a function for registering properties, methods, and events in a control command used for graphical user interface design in the repository as a design control command independent of the source code. Preferably, the function, method, and event include a function for generating a graphical user interface corresponding to the source code based on the design control command, the data type of the field data of each entity, and the type of the source code.

In the system design support program of the present invention, the function E includes a function for registering the return value of the control command used for the graphical user interface design in the repository as a panel variable, and the function F is a logical method that does not depend on the source code. It is preferable to include a function for acquiring and issuing panel variables and expanding the acquired panel variables into source code.

In the system design support program of the present invention, the function E is used for designing a graphical user interface, and includes a function for grouping and registering each panel variable of the same type and referred to by a plurality of control commands in the repository. , The function to convert multiple control commands into a batch command that issues one command for each grouped panel variable, and by issuing a batch command, the corresponding panel variable is acquired, and the acquired panel variable It is preferable to include a function of developing the source code as many as the bundled number.

In the system design support program of the present invention, the function E includes a function of registering a common macro instruction in which common definition information unique to each process is registered in the repository , and the function F is a logic definition when generating source code. Preferably include a function for referring to the common macro instruction.

  According to the system design support program of the present invention, the upstream design tool “Xupper II” can be used to automatically perform the program development, which is a downstream process, without using a bridge and a manpower.

(First embodiment)
A first embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 shows a block configuration of a system design support program according to the first embodiment of the present invention. Here, since the system design support program does not depend on the computer (hardware) on which it is executed, the hardware configuration is omitted.

  As shown in FIG. 1, the system design support program according to the first embodiment generates an “XupperII” 10 that is an upstream design tool and uses a data-centered approach (DOA) method, and the “XupperII” 10 Generate, update, and refer to the first repository 11 that performs update and reference, and the second repository 21 that is an extension of the first repository 11 and automatically source code of the program to be developed “MDFrame / X” 20 which is a downstream design tool to be generated. Hereinafter, the first repository 11 and the second repository 21 are referred to as an integrated repository 30.

  Data necessary for generating source code is stored in the second repository 21, and “MDFrame / X” 20 captures the integrated repository 30 as one model.

  All information (data) is set for this model, and the operating environment is implemented (implemented) by the source code generated from this model. As a result, the use of “MDFrame / X” 20 eliminates the difference between the model and the mounting environment, so that a so-called model-driven development environment can be obtained.

  The “MDFrame / X” 20 refers directly to the following information among the data stored in the first repository 11 without using a bridge or the like.

1) Process information including process hierarchy and lowest layer process 2) Entity information including identifiers, attribute items and related information between entities 3) Dictionary information including domain fields, conditions and fields 4) Graphical user interface ( GUI Device Design Information Including GUI (Graphical User Interface) Screen Layout Further, “MDFrame / X” 20 can directly perform additional editing on the dictionary included in the first repository 11.

  The system design support program according to the first embodiment includes a function for hierarchizing an input business flow into a plurality of processes on a computer, a plurality of entities used for each process, and an entity representing a relationship between the entities. A function for creating a relation diagram, a function for creating a dictionary that holds input / output data necessary for each process and field data of each entity, a function for performing GUI design with reference to the entity relation diagram and the dictionary, Layered data in the process, attribute data of each entity, dictionary and GUI design data are registered to create a first repository, and each process, each entity, data held in the dictionary and GUI design data Refer to One, by inputting the logic definitions that can execute the respective processes from the outside, to realize a function to output the automatically generated source code.

  FIG. 2 shows an example of source code that can be generated by the “MDFrame / X” 20 in the system design support program according to the first embodiment. As shown in FIG. 2, at least one source code of the BizCRS file 31, the Java source 32, and the high-speed engine procedure source 33 can be generated. As is well known, since the BizCRS file 31 is a script language, no compilation is necessary.

  Hereinafter, a specific example of automatic source code generation in “MDFrame / X” will be described with reference to the drawings.

  When “MDFrame / X” generates a predetermined function (program function), “skeleton”, “user point logic unit generation source” and “replacement string unit generation source” which are the framework of the source code are By synthesizing, automatic generation of complete source code is realized.

  FIG. 3 shows a specific example of the skeleton. A skeleton is a skeleton character string set corresponding to each function pattern. The skeleton is composed of a fixed generation content that does not depend on a function and a replacement character string that indicates a portion where the generation content varies.

  There are two types of replacement character strings: a case where “user point logic” described later is embedded and a case where “generation logic for each replacement character string” is embedded.

  The replacement character string for user point logic corresponds to, for example, <% # USER_POINT CD: U60_Main #%> described in the third line from the bottom in FIG.

  For example, <% # Java_PackageName #%> described in the first line of FIG. 3 and <% # Java_ImportPackageList #%> described in the eighth line correspond to the replacement character string for the generation logic of the replacement character string unit. . The skeleton including this ImportPackageList specifies that an import statement such as a function called by the corresponding function is generated.

  In an actual function, the user point logic means a character string obtained by performing logical coding by action diagram description for a user point set in a function pattern and converting the coded contents into a source code. The replacement character string generation logic means a character string generated by referring to information of the integrated repository in which parameters and the like are set without performing logic coding in an actual function.

  FIG. 4 shows the generation result of the skeleton source code shown in FIG. In FIG. 4, for example, <% # Java_PackageName #%> described in the first line of FIG. 3 is replaced with demo.tran, and <% # USER_POINT CD: U60_Main described in the third line from the bottom of FIG. It can be seen that #%> is replaced with my_juyuyuUpdate_i = new juyuyuUpdate_i () described in the fourth line from the bottom.

  FIG. 5 is an entity relation diagram (ERD) showing a data structure when the processes of FIGS. 3 to 4 are executed. 5, the skeleton shown in FIG. 3 is stored in “XE_skeleton.FUN skeleton” of the second repository 21 shown in FIG. Since the function is created for each “XE_function”, it can be seen that the corresponding skeleton is referred to when generating the source code.

  Thus, according to the first embodiment, manual maintenance work is not necessary for the contents directly described in the skeleton, and there is no need to modify the source generation function according to the first embodiment.

(One modification of the first embodiment)
Hereinafter, a modification of the first embodiment will be described.

  When function source code is automatically generated, code (description) that depends on the user's operating environment or project is required. For example, the database connection information acquisition method described in the seventh line in FIG. 3 and the log file writing method described in the twelfth line correspond thereto.

  Such a description depending on the operating environment of the user needs to be taken into the function of the CASE tool itself or customized by customizing the CASE tool. It is difficult to respond.

  Therefore, a mechanism that easily reflects the contents specified by the user in the automatically generated source code is required.

  In the present modification, user customization can be performed on elements that depend on the operating environment, etc., for the fixed part that does not depend on the function, such as the second, third, sixth, and seventh lines in the skeleton shown in FIG. I am doing so. As described above, by enabling the maintenance work by the administrator, it is possible to dynamically reflect the user-dependent code without changing the source generation function by “MDFrame / X”.

(Second Embodiment)
The system design support program according to the second embodiment of the present invention will be described below with reference to the drawings.

  When SQL, which is a database query language for a relational database, is used, the SQL definition is generally a method of embedding directly entered character code in a program source code.

  “MDFrame / X” according to the present invention manages the SQL definition itself as an independent object. In addition, in order to avoid syntax errors and to make it easier to analyze the impact on other parts of the program when the SQL definition is changed, the results registered in the wizard format are stored in the second repository. .

  FIG. 6 shows an example of a table (ERD) relating to the SQL definition. In FIG. 6, “XE_DLCP” located in the upper left corresponds to one unit of SQL definition.

  However, “MDFrame / X” does not correspond wizards and repositories to all the syntax of SQL92 / 99. There are a wide variety of syntaxes that SQL92 / 99 targets, and it is virtually impossible and inefficient to make wizards compatible with all of them. Therefore, only frequently used SQL syntaxes are generally targeted for wizards. Yes.

  However, there is also a syntax that greatly affects the execution efficiency of SQL despite its low frequency of use. For this reason, it is not preferable from the viewpoint of productivity in system development work to uniformly exclude important SQL definitions that are used infrequently and are not subject to management.

  Therefore, in the second embodiment, the syntax that is not the object of the wizard can be handled by registering the directly input SQL sentence in the second repository in advance and referring to it when generating the source code. .

  “MDFrame / X” basically uses SQL as one component for “receiving a predetermined value, issuing an SQL, and returning a predetermined value”. For this reason, it is necessary to define the information to be received and the information to be returned by using a wizard as in normal SQL, but for the SQL to be issued, use any syntax without being bound by the limitations of the wizard. Is possible.

  In addition, when the SQL definition is directly input, the target range to be directly input can be minimized by dividing the SQL definition sentence into two stages: directly inputting all of the SQL definition sentences and directly inputting a part thereof. It is limited.

  FIG. 7 shows an example of a table (ERD) that stores information relating to the SQL definition that is directly input. As shown in FIG. 7, it can be seen that the same setting as in the case of the normal wizard is performed for entities other than “XE_generated part SQL”. In other words, when the SQL definition is directly input, the result is held in the “XE_generation part SQL”, whereas when it is input by the wizard, the content generated by the SQL is stored.

  Here, each item of “XE_generation part SQL” will be described.

  “DLCPSGT” indicates a management number for uniquely identifying SQL.

  “Logical / physical type ST” is a code (ST: status) for identifying whether stored information is logical SQL or physical SQL. For example, the logical SQL is 1 and the physical SQL is 2. The logical SQL is SQL for confirming the SQL definition, and is not a target for generating an actual source.

  “SQL part type ST” is a code for identifying which part of SQL the stored information corresponds to. For example, the entire SQL is 0, the Select phrase is 1, the From phrase is 2, the Where phrase is 3, the OrderBy phrase is 4, the GroupBy phrase is 5, the Hving phrase is 6, the Set phrase is 7, The InsertInto phrase is set to 8, and the Values phrase is set to 9.

  In the “generated part SQL”, an SQL sentence that is directly input or an SQL sentence that is automatically generated from information stored in the second repository is stored.

  “SQL Direct Input Identification ST” identifies whether the value stored in “Generated Part SQL” (not shown) is a directly input code or a code automatically generated from an SQL definition via a wizard. Sign.

  [Table 1] and [Table 2] show examples stored in the table.

  Here, how the physical SQL is stored in the SQL identified by one “DLCPSGT” will be described using a search-type SQL definition.

  In the case of the search type, there are seven types of parts: “entire SQL”, “Select phrase”, “From phrase”, “Where phrase”, “OrderBy phrase”, “GroupBy phrase”, and “Having phrase”.

  (1) When “SQL total” is entered directly

  In this case, the content input for “entire SQL” is embedded in the source code as it is when the program is generated.

  (2) When “Where clause” and “OrderBy clause” are directly input

  In this case, the value of each part is embedded in the source code when the program is generated. The values of each part are issued after being synthesized by the logic of the generated source program.

(Third embodiment)
The system design support program according to the third embodiment of the present invention will be described below with reference to the drawings.

  As mentioned above, “MDFrame / X” eliminates personality by allowing the logic set for each function to be entered as a logical action diagram in the form of a wizard, which makes it easy to understand and prevents input errors. Can be constructed.

  However, it is difficult to cover all the instruction sets of the programming language that generates the source code.

  For example, when logic such as an application program interface (API) is described, it is necessary to manually modify the generated source code after automatically generating the source code. There is. However, if the source code is generated again in this case, the manual correction contents are overwritten and lost. This causes a discrepancy between the data registered in the integrated repository and the running program.

  Therefore, in the third embodiment, necessary source code (Native code) in the programming language to be generated is described and registered as a macro function in the second repository so that the registered macro function can be handled as a component. To.

  For example, after the source code is automatically generated, items that require manual correction are converted into parts as macro functions in advance and registered in the second repository. At the time of generating the source code, the source code is generated with reference to the componentized macro function, so that an instruction (command) that does not correspond to the action diagram is expanded to the generated source.

  FIG. 8 shows an example of the ERD of the macro function stored in the second repository. FIG. 8 is an excerpt of a portion related to a macro function in the function definition. In FIG. 8, “XE_DLCP”, “XE_BPTBL”, and “XE_function” have a one-to-one relationship, and are a unit of function.

  For a function, “XE_function variable” indicates a variable of the function. There are three types of variables, input, output, and local, and the macro function according to the third embodiment targets inputs and outputs.

  The “XE_logic line” corresponds to information for each line of the action diagram set in the function. By registering each instruction in the “XE_logic line”, the logic of the function is completed.

  The macro function is not generated by itself, but is expanded into a predetermined source code by being taken in as a part of the source code of another function that calls the macro function.

  FIG. 9 shows a state in which logic is input to a certain function. As shown in FIG. 9, the logic definition is input as an action diagram notation, and each line corresponds to an “XE_logic line”. For example, “CALL B_MACRO: C001_array element number acquisition (character string)” on line 12 in FIG. 9 is a description for calling the macro function of this embodiment. In this case, “XE_call” data is created for the “XE_logic line” in the ERD shown in FIG. 8, and the callee macrofunction is specified. After that, the result of mapping (contrast) definition between “XE_function variable” in the called macro function and “XE_function variable” in its own function is stored in “XE_parameter mapping”. .

  FIG. 10 shows a wizard corresponding to the line for calling the macro function described in the twelfth line of FIG. In FIG. 10, a call destination function is specified to create “XE_call”.

  FIG. 11 shows a wizard displayed after the “Next (F9)” button is pressed in the wizard of FIG. As shown in FIG. 11, “XE_parameter mapping” is created by displaying “XE_function variable” of the macro function of the callee as a parameter and mapping the variable of its own function to this.

  Next, the definition related to the called macro function will be described. Macro functions to be called are also created with “XEDLCP”, “XE_BP”, and “XE_function” as a unit. Further, as can be seen from the image of the parameter mapping of the call shown in FIG. 11, this example has “MD_array item” as an input parameter and “MD_array element number” as an output parameter.

  Next, FIG. 12 shows a wizard for accepting a Native statement for describing a macro entity. This is a screen image corresponding to “Native MD_array element number acquisition (Java)” on the third line in the action diagram in the upper left of FIG. The data input from this wizard is stored in “XE_Native & Comment” and “XE_Native Import Statement (JAVA)” via “XE_Logic Line” as shown in ERD of FIG. However, since no import statement is used here, no data is stored in the “XE_Native import statement (JAVA)”.

  With this definition, the following source code can be obtained, and this source code is incorporated into the caller of the macro function.

l_HairetsuYousoSuu = I_SyohinCD_arr. size ();
Similarly, when an input statement is input, the input content is incorporated in the description portion of the Import statement in the caller function.

  In this way, it is not necessary to modify the generated source code by incorporating Java instruction codes that are not supported by “MDFrame / X” as macro functions. In addition, the Java source code can be used as a shared component even for developers with low skills for the Java.

(Fourth embodiment)
The system design support program according to the fourth embodiment of the present invention will be described below with reference to the drawings.

  FIG. 13 shows an ERD for a field of data stored in a dictionary accessed by “Xupper II” according to the present invention. As shown in FIG. 13, the “field” in the lower left is subordinate to the “domain” in the upper right and the “field type” in the lower right, and the “domain” is subordinate to the “field type”.

  For example, since “Field: Customer CD” is subordinate to “Domain: Customer CD”, the same values as “Domain: Customer CD” are set for the data type, internal length, and the number of decimal places. At the same time, since “domain: supplier CD” is subordinate to “field type: code”, the same value as “field type: code” is set for the data type and the like. However, for example, “Field: Remarks for order entry screen” is not subordinate to “Domain” but subordinate to “Field type: Kanji item”.

  Thus, “Xupper II” employs a configuration in which “field type” is positioned at the top of the concept of the data type (type) for “field”. Further, the “field type” allows the user to add a new definition.

  By the way, when generating various source codes, the program language to be generated has various data types. Therefore, it is necessary to associate the “field type” stored in the “Xupper II” dictionary with the data type of each programming language.

  Therefore, in the fourth embodiment, the fixed language is eliminated from the source code generation function of the variable definition part by converting the data type of the programming language to be generated into a master file (basic file), and the variable definition part The source code generation function in can be flexibly performed. Here, a master file (basic file) refers to a data file that is prohibited from being added, changed, or deleted with respect to registered data.

  Specifically, as shown in the ERD of FIG. 14, “XE_language-specific data type” is defined in “MDFrame / X” independently of “field type” in “XupperII”, and “MDFrame / X” is further defined in “MDFrame / X”. By defining “XE_field type extension”, “field type” in “XupperII” and “XE_language-specific data type” in “MDFrame / X” are associated with each other so that each item can be one of a plurality of programming languages. The data type of the language to be generated can be set.

  For example, the contents shown in [Table 3] are set in the “XE_language-specific data type”.

  Further, by setting the contents shown in [Table 4] in “XE_field type extension”, the relationship between the data types of each programming language is defined.

  By setting the relationship shown in [Table 4], for example, when an item of the “NBR” type is generated as the program language “BizCRS”, it becomes “Number”, and when it is generated as the program language “Java” Makes it possible to extract logic that becomes “double” from the logic definition to be generated.

  As described above, the user can dynamically change the generation result of the variable definition portion without changing the generation logic only by making the data type of each programming language into a master file. Thereby, it is possible to arbitrarily add to the “field type” in “XupperII”.

  A generation example in the variable definition when order quantity is defined as a local variable is shown below.

(1) In the case of “BizCRS” Number l_order quantity = 0;
(2) In the case of “Java” private double 1_Jyutsuu Suruyou;
(3) In the case of “High-speed engine Procedure” l_Order quantity IN DECIMAL (7, 0);
The “Number”, “double”, and “DECIMAL” can be dynamically changed by referring to “XE_language-specific data type.language-specific data type generation name” shown in FIG.

(Fifth embodiment)
The system design support program according to the fifth embodiment of the present invention will be described below with reference to the drawings.

  FIG. 15 shows an example of a wizard for inputting “assignment” processing to the action diagram.

  Since “MDFrame / X” enables generation of source codes in various programming languages, it is determined whether or not “assignment” processing is appropriate for the programming language to be generated when the values of variables are substituted. There is a need.

  For example, generally, a numerical value can be assigned to a numerical item field, but a numerical value cannot be assigned to a date item field. In order to incorporate such a determination function, it is necessary to perform determination processing between “field types” in each wizard. However, depending on the language to be generated, the data type may be the same even if the “field type” is different. In such a case, it is necessary to permit the “assignment” process. Therefore, the determination rule of determining only “field type” cannot be adopted.

  Therefore, in the fifth embodiment, the association rules between the data types of the programming language to be generated are converted into a master file. Thereby, it is not necessary to describe the determination rule in a fixed manner with respect to the “assignment”, “calculation”, “comparison”, and “call parameter mapping” processes in the screen input function.

  Specifically, a new master file that defines the relevance of each data type is added to the language-specific data type described in the fourth embodiment. The wizard for various input functions can dynamically change the judgment logic of the wizard by referring to the master file.

  FIG. 16 shows ERDs of “XE_language-specific data types” and “XE_language-specific data types”. In FIG. 16, “XE_language-specific data type” is the same as that in the fourth embodiment.

  “XE_language-specific data type related” sets whether or not “substitution” processing, “calculation” processing, or “comparison” processing can be executed between two “language-specific data types CD”. As a result, the “assignment”, “calculation”, “comparison”, and “call parameter mapping” wizards obtain the “language-specific data type CD” from the processing target item, and then the “XE_ By referring to “Language-specific data type #”, the determination contents can be dynamically changed.

  For example, in the case of “assignment” processing, assignment is possible if the “assignment availability ST” is “allowed” between the data types of the left and right data types, and “assignment availability ST” is “not”. If so, the wizard (program) determines that substitution is impossible.

(Sixth embodiment)
The system design support program according to the sixth embodiment of the present invention will be described below with reference to the drawings.

  FIG. 17 shows another example of the wizard when inputting the “assignment” process to the action diagram. FIG. 17 shows a wizard for selecting a condition value to be assigned when setting a condition value in “output.MD_return code” in the assignment statement. Here, the condition value is a value for giving meaning to the value of a certain item. Here, seven condition values “* BLANK”, “* NULL”, “ERROR”, “NORMAL”, “SQL_ERROR”, “SQL_EXIST”, and “SQL_NOT_FOUND” are valid condition values for “MD_return code”. Means that can be substituted. Of these, condition values other than “* BLANK” and “* NULL” are already registered in “Xupper II”.

  Since “Xupper II” is a tool for defining logical specifications, condition values other than “* BLANK” and “* NULL” need to be registered, but “* BLANK”, “* NULL”, etc. In general, there is no logical meaning, so there is no need to register.

  However, since “MDFrame / X” is programmed in the downstream process of development, condition values such as “* BLANK” and “* NULL” are also required.

  Condition values required for such downstream processes include “* ZERO” and “* ONE” in addition to “* BLANK” and “* NULL”. However, with regard to these four kinds of new condition values, it is necessary not to register the condition in “Xupper II”.

  In addition, whether or not these four types of condition values can be used differs depending on the data type of the programming language. For example, “* ZERO” and “* ONE” are not used for the character string type. Therefore, after generating a desired source code, it is necessary to incorporate a determination function in order to make a logic definition that causes a compile error in the source code an error at the time of input.

  Therefore, in the sixth embodiment, the condition values that can be set for the data type of the programming language to be generated are converted into a master file. As a result, it is not necessary to describe the determination rule for the validity of the condition value in a fixed manner from the screen input functions related to the processes of “substitution”, “comparison”, and “call parameter mapping”.

  Specifically, the language-specific data type described in the fourth embodiment is valid among the four condition values described above, that is, “* BLANK”, “* NULL”, “* ZERO”, and “* ONE”. Add a new master file that defines the condition values. The wizard for various input functions can dynamically change the judgment logic of the wizard by referring to the master file.

  FIG. 18 shows ERDs of “XE_language-specific data type” and “XE_language-specific data type allowable CND”. In FIG. 18, “XE_language-specific data type” is the same as that in the fourth embodiment. Here, if data is set in “XE_language-specific data type allowable CND”, it means that it is a usable condition value.

  For example, one condition value of “* BLANK”, “* NULL”, “* ZERO”, and “* ONE” is set in “allowable ITEM type ST”. As a result, from the screen input functions related to the processing of “assignment”, “comparison”, and “call parameter mapping”, the judgment rules for the validity of condition values must be changed dynamically without being described in a fixed manner. Is possible.

(Seventh embodiment)
The system design support program according to the seventh embodiment of the present invention will be described below with reference to the drawings.

  For example, when generating Java source code from data for which logic definition has been performed by action diagram description, the source code generation method may differ depending on the data type. For example, a double type assignment statement and a Big Decimal type assignment statement are different as follows.

The double type is
LeftField = RightField;
The BigDecimal type is
LeftField
= New BigDecimal (RightField.toString ());
Or LeftField
= (Null == RightField)? null: new BigDecimal (RightField.toString ());
When such a generation rule is incorporated as source code generation logic, it is impossible to generate logic of a data type that is not assumed by the incorporated generation logic.

  Therefore, in the seventh embodiment, generation rules relating to “assignment statement”, “condition statement”, “calculation statement”, and “parameter mapping” in the programming language to be generated are converted into a master file. This eliminates the need for describing fixed logic as a source code generation function, thus enabling dynamic logic generation.

  Specifically, in the language-specific data type described in the fourth embodiment, the generation rules for code generation such as “assignment statement”, “condition statement”, and “calculation statement” are converted into a master file, Register in the second repository. The generation logic refers to the master file when generating the source code, and enables dynamic change of the generation logic.

  The code generation processing according to the seventh embodiment is performed by combining the corresponding partial skeleton and variable generation name.

  FIG. 19 shows an ERD relating to the partial skeleton according to the seventh embodiment. Hereinafter, the “assignment statement”, “array expression”, “condition statement”, “operation statement”, “MapSet”, and “MapGet” in the partial skeleton will be described in this order.

(1) XE_Generation Skeleton “Assignment Statement” Processing Data exists for each variation registered as an assignment statement, and a partial skeleton for generating an assignment statement is mastered in the second repository as an assignment statement skeleton. be registered. There are only 15 variations of the “assignment statement” between the left side, the right side, and the two language-specific data types, including cases where it is not allowed. [Table 5] and [Table 6] show variations of “assignment statements” and examples of skeletons, respectively.
a) In case of assignment statement between double types

b) In case of assignment statement between BigDecimal types

  In [Table 5] and [Table 6], there are the following replacement character strings embedded in each substitution skeleton.

  <% # L_Fld #%>: Replaced with a variable generation name for the left side.

  <% # R_Fld #%>: Replaced with a variable generation name for the right side.

  <% # L_aFld #%>: Replaced with a variable generation name for the array on the left side.

  <% # R_aFld #%>: Replaced with a variable generation name for the array on the right side.

  <% # L_aIdx #%>: Replaced with a variable generation name for the array index on the left side.

  <% # R_aIdx #%>: Replaced with a variable generation name for the array index on the right side.

  <% # Cnd #%>: Replaced with the internal value for the condition on the right side.

(2) “Array representation” processing of XE_generated skeleton For example, when performing a condition determination, a certain item is referred to, and if the referenced item is an array element, a description (logic) is described to refer to the array element. Need to change. In this case, after converting the array elements so as to be referred to in advance using a skeleton, the conditions and the like are converted.
[Table 7] shows an example of the data type (type) and skeleton of the “array element representation”.

  In [Table 7], the replacement character strings embedded in the array representation skeleton are as follows.

  <% # AFld #%>: Replaced with the variable generation name for the sequence.

  <% # AIdx #%>: Replaced with the variable generation name for the sequence index.

(3) “Conditional Statement” Processing of XE_Generated Skeleton Data exists for each variation registered as an assignment statement, and a partial skeleton for generating a conditional statement is converted into a master file in the second repository as a conditional statement skeleton. . There are only 36 variations of the “condition sentence” between the “condition operator” and the “right-side condition item”, including cases where it is not allowed.

Table 8 shows variations of “conditional statements” and examples of skeletons.
a) In case of assignment between double types

  In [Table 8], the replacement character string embedded in each condition skeleton is the same as the “assignment statement” described above.

(4) XE_Generation Skeleton “Calculation Statement” Processing Data exists for each variation registered as an operation statement, and a partial skeleton for generating the operation statement is converted into a master file in the second repository as an operation statement skeleton. . There are only 18 variations of the “computation statement” between the left and right sides, the two language-specific data types, and the computation operator. Here, the calculation operators include “+ (addition)”, “− (subtraction)”, “* (multiplication)”, “/ (division)”, “++ (increment)”, and “−− (decrement)”. There are six.
[Table 9] shows variations of “operational statements” and examples of skeletons.
a) In the case of a BigDecimal type operation statement

  In [Table 9], <% # O_Fld #%> in the replacement character string embedded in each operation skeleton is replaced with a variable generation name for the operation result field. Other replacement character strings are the same as the above-mentioned “assignment statement”.

(5) “MapSet” Processing of XE_Generation Skeleton When one function calls another function, a parameter to be passed to the callee is executed by passing parameters to the caller's Setter method. In “MapSet”, a partial skeleton for generating a part for calling a Setter method is registered as a master file in the second repository. There is data for each variation that performs parameter mapping, and there are only 8 variations of “MapSet” depending on the type of items to be passed for each data type by language on the receiving side and the passing side, including cases where it is not allowed. . [Table 10] shows a variation of “MapSet” and an example of a skeleton, respectively.
a) In the case of delivery between Big Decimal types

  In [Table 10], replacement character strings embedded in each MapSet skeleton include the following.

  <% # Call Fun #%>: Replaced with the generation name of the called function.

  <% # T_Fld #%>: Replaced with the physical name of the item set as a parameter of the callee function.

  <% # T_aFld #%>: Replaced with the generation name of the array item set as a parameter of the callee function.

  <% # M_Fld #%>: Replaced with the generation name of the item to be delivered.

  <% # M_aFld #%>: Replaced with the generation name of the array to be delivered.

  <% # M_aIdx #%>: Replaced with the generation name of the index variable indicating the array element to be delivered.

  <% # Cnd #%>: Replaced with the generation name of the index variable indicating the array element to be delivered.

(6) “MapGet” Processing of XE_Generation Skeleton When one function calls another function, a parameter received from the call destination is executed by parameter passing to the Getter method of the call destination. In “MapGet”, a partial skeleton for generating a part for calling a Getter method is registered as a master file in the second repository. Data exists for each variation for which parameter mapping is performed, and there are only three variations of “MapGet” depending on the types of items to be transferred for each of two data types by language on the receiving side and the passing side. Table 11 shows variations of “MapGet” and examples of skeletons.
a) In the case of delivery between Big Decimal types

  In [Table 11], the replacement character string embedded in each MapGet skeleton is the same as “MapSet” (excluding <% # Cnd #%>).

(Eighth embodiment)
The system design support program according to the eighth embodiment of the present invention will be described below with reference to the drawings.

  As described above, “MDFrame / X” is a downstream process CASE tool specialized in “Xupper II” in the upstream design portion. Therefore, the basic user interface (UI) is intended for GUI design in “Xupper II”.

  By the way, “MDFrame / X” according to the present invention can generate a plurality of types of program languages (source codes). For example, the script language for BizBrowser has been developed, and Microsoft. The net C # language, VisualBasic, and the like can also be generated. These programming languages have GUI controls (control commands) supported by the respective languages, and it is necessary to assume that the GUI controls are different for each language. Also, the GUI control for each language has a different method name and the like.

  However, although the GUI control has different event names and property types depending on the language, it is composed of three elements: properties, methods, and events. It is common.

  Therefore, “MDFrame / X” according to the eighth embodiment introduces “design GUI control” that does not depend on a specific language. Specifically, the properties, methods, and events of various controls on the GUI screen are converted into a master file, registered and managed in the second repository, and these elements are made independent from the GUI screen logic input function.

  FIG. 20 shows the relationship between the GUI control handled by “Xupper II”, the “design GUI control” handled by “MDFrame / X” according to the eighth embodiment, and the GUI control to be generated.

  The correspondence between the GUI control handled by “Xupper II” and the “design GUI control” handled by “MDFrame / X” is determined by “XE_Language Default GUI Control Assignment by Language” shown in the ERD of FIG. That is, “MDFrame / X” determines the design GUI control type according to “field type”, “language type ST” and “control type” to be generated in the GUI control handled by “XupperII”.

  Thereby, for example, the following determination is made.

  When a GUI screen in which the “control type” is set to “EDIT type” in the “Xupper II” CDE type field is used as the screen for the BizBrowser, the corresponding GUI GUI for designing the control is “EditBox”. Become.

  “MDFrame / X” sets properties and describes event logic for the design GUI control. FIG. 22 shows the ERD related to the design GUI control. From FIG. 22, it can be seen that the design GUI control includes three elements: property (upper second column), method (middle second column), and event (middle first column). When the source code is generated, the “property”, “method”, and “event” in the design GUI control are converted into the GUI controls for the language to be generated.

  FIG. 23 shows an ERD in which an entity for storing information related to each generated name is added to the three elements of the property, method, and event shown in FIG. As can be seen from FIG. 23, four types of “XE_design GUIICT property generation name”, “XE_design GUIICT method generation name”, “XE_design GUIICT event generation name”, and “XE_design GUIICT type generation name”. An entity is added.

  In this way, by creating information on properties, methods, events, and generation names related to them as master files, individual logic for each of these elements can be eliminated from the GUI screen logic input function. Therefore, the processing function can be simplified, and a new GUI control command can be handled by creating a master file.

  By the way, the button displayed on the GUI control screen of “Xupper II” is processed as the button for the design GUI control in “MDFrame / X”.

  In “MDFrame / X”, the presence of the logical event “OnClick” is recognized by the “XE_design GUIICT event” shown in FIG. 23, and the logic input function for this event can be used.

  For example, when the logic input to “OnClick” is generated as a script language of “BizBrowser”, it is generated as “OnTouch () event” of “BizBrowser” by referring to “XE_design GUIICT event generation name”. Is done. On the other hand, when it is generated as a source code of “Microsoft.Net”, it is generated as a “Click event” by referring to “XE_design GUIICT event generation name”.

(Ninth embodiment)
Hereinafter, a system design support program according to a ninth embodiment of the present invention will be described with reference to the drawings.

  The GUI control has various values (return values) storage methods depending on the implementation method. Therefore, the programmer needs to perform various types of coding while paying attention to the difference in the return value storage method.

  FIG. 24 shows an implementation example of GUI control in “BizBrowser”. FIG. 24 shows the extracted definition parts when the logically identical items exist as text boxes and as combo boxes.

  FIG. 25 shows logic used to determine whether the return value of each item in the text box and the combo box is “SQL_EXIST”. For example, the return value “2” as a comparison target in the case of the combo box has no meaning of the data itself, and merely indicates that it is positioned at the second of the elements of the combo box. In this way, even if the value has the same meaning, such as “SQL_EXIST”, the method of referring to the return value differs depending on the type of control command, so source codes such as “assignment” and “calculation” are automatically generated. The generation logic when doing so becomes complicated.

  Therefore, in the ninth embodiment, a panel variable is introduced into an element on the GUI screen and registered in the second repository, and a return value reference method that does not depend on the command type of the GUI control is employed.

  FIG. 26 shows the definition of the panel variable according to the ninth embodiment. As shown in FIG. 26, the definition part of the GUI control is equivalent to the source shown in FIG. All return values on the screen are referenced and updated via this panel variable rather than referencing the control command directly. In this case, although it is necessary to describe the logic to be captured in the panel variable, “MDFrame / X” defines a logical method that does not exist in the generated program language.

  This mechanism is shown in FIG. As shown in FIG. 27, “control on the screen” involves checking the validity of the control command by issuing the logical method “GetAndValidate” according to the ninth embodiment to “panel variable”. Is read into the “Panel Variable”. The "panel variable" that has read the method issues the "Put" method to the "control on the screen", and the "control on the screen" changes its state in response to the return value from the "panel variable" Is done.

  FIG. 28 and FIG. 29 show respective generation examples of the “GetAndValidate” method and the “Put” method according to the ninth embodiment. As shown in FIG. 29, logic such as substitution and calculation is expanded as if it were a simple logic for a work field without being affected by screen control, so that the configuration becomes simple and the readability is improved. Thereby, the determination logic regarding the return value of the item on the panel is as shown in FIG. 30, and it can be seen that the same determination condition is developed regardless of the type of the control command.

(Tenth embodiment)
Hereinafter, a system design support program according to a tenth embodiment of the present invention will be described with reference to the drawings.

  Generally, a GUI screen is composed of a collection of a plurality of display items having the same use. FIG. 31 shows an example of a screen image in a slip input format. In FIG. 31, there are a plurality of display items in each of the “slip header part”, “detail line edit area”, and “detail line list display area” grouped by broken lines, and the same within each group. It is necessary to perform the process. For example, when the determination result is an error, an initialization process may be performed to restore the background color of a display item whose background color of the display screen has been changed. In this case, the same command is generally repeated for a predetermined number of times for each display item.

  FIG. 32 shows the initialization process of the background color of each display item in the “slip header portion” when “BizBrowser” is the generation target language. As shown in FIG. 32, it is necessary to repeatedly describe the same logic for each display item. Although the logic itself is simple, productivity in program development can be greatly improved by making automatic generation processing a target of describing such repeated operations collectively.

  In the tenth embodiment, a configuration is adopted in which batch commands are issued to a plurality of grouped display items by grouping the aforementioned panel variables. Here, a group of panel variables is called a “variable group”.

  The instruction set issued collectively for each item of the variable group is shown below.

  (1) “GetAndValidate”: After checking the validity of the display items on the screen, the control command is taken into the panel variable.

  (2) “Check Required”: A mandatory input check is performed on the input command.

  (3) “SetOriginalState”: The background color of the display item is returned to the initial value.

  (4) “Put”: Writes the value of the panel variable to the display item on the screen.

  Each instruction of (1) to (4) is described for one line for each variable group on the action diagram. When generating the source code, a predetermined number of display items included in the variable group are described. Is generated repeatedly.

  As a result, since it is possible to eliminate a simple repetitive coding operation, productivity in program development can be improved.

  FIG. 33 shows an ERD related to display items on the GUI screen according to the tenth embodiment. In FIG. 33, data of a “GUI form” entity is created for each GUI screen. In addition, data of a “GUI control” entity is created for each display item on one GUI screen.

  “GUI form”, “XE_GUI form extension”, “XE_DLCP”, “XE_BPTBL”, and “XE_function” are created one-on-one and registered in the second repository. For example, “XE_function variable group” is created in units of “slip header part”, “detail line edit area”, and “detail line list display area” in the screen image shown in FIG. By issuing a batch instruction such as the above-mentioned “GetAndValidate” command to this “XE_function variable group”, the source code generation logic is subordinate to the “XE_function variable group”. A predetermined process is executed for each of the display items, and a plurality of control commands are expanded into the source code.

  FIG. 34, FIG. 35, FIG. 36, and FIG. 37 show respective generation examples of the “GetAndValidate” command, the “Put” command, the “SetOriginalState” command, and the “CheckRequired” command.

  Since the logic is generated in a subroutine state, redundancy when issued from a plurality of locations is avoided.

(Eleventh embodiment)
Hereinafter, a system design support program according to an eleventh embodiment of the present invention will be described with reference to the drawings.

  Among a plurality of items used by the system, there is an item for managing a division value for dividing a business. These items generally include an external value indicating meaning and an internal value that is an actually stored value. For example, as shown in [Table 12], there is a case of having “payment method classification” for identifying “cash sale” and “payment sale” to the customer.

  Internal values are used in the processing in the program, but when displaying the corresponding item on the screen, it is common to convert the internal value to an external value and display it so that people can understand the meaning of the internal value. Is. To achieve this, it is usually necessary to describe the conversion logic individually.

  Although the conversion logic of this internal value to an external value is simple, such simple work is the target of automatic generation processing, so that mistakes caused by simple work and productivity in program development are reliably improved. be able to.

  Therefore, “MDFrame / X” according to the eleventh embodiment expands the referenced definition information as a common macro instruction when referring to definition information stored in the first repository, for example, instead of actual data. Take a way.

  FIG. 38 shows an ERD related to the common macro according to the eleventh embodiment. 38. Information for one line of the action diagram is stored in “XE_logic line” in FIG. At this time, when the external value conversion process of [Table 12] is performed, a value of “instruction type ST: condition name acquisition” is set in the logic line. In the “XE_built-in function parameter” corresponding to the instruction type, an item for which the condition name is to be acquired and an item for which the condition name is to be returned are registered.

  In addition, information that maps (associates) items corresponding to “XE_built-in function parameters” to “XE_built-in function parameter mapping” corresponding to the logic row is stored.

  FIG. 39 shows a screen image for performing parameter mapping for a common macro instruction by an actual action diagram. In FIG. 39, a value obtained by converting the value of “input.MD_program mode” into an external value is stored in “local.U_mode # display”.

  FIG. 40 shows how four types of source code are generated from one line of macro instructions input to the action diagram shown in FIG. Specifically, referring to the contents of the first repository, logic for determining whether or not to set one of the external values of “search”, “delete”, “add”, and “change” Is expanded.

  As described above, when the source code is generated, the fixed logic can be automatically generated by referring to the first repository, so that the development efficiency of the program can be improved.

  The system design support program according to the present invention can automatically perform program development as a downstream process without using a bridge and a manpower by using “Xupper II” as an upstream design tool. It is useful as a program used for a system design support program (CASE tool) used for system design.

It is a schematic block diagram which shows the system design support program which concerns on the 1st Embodiment of this invention. It is a block diagram which shows a mode that "MDFrame / X" in the system design support program which concerns on the 1st Embodiment of this invention produces | generates a some source code. It is a code diagram which shows an example of the skeleton in the system design support program which concerns on the 1st Embodiment of this invention. FIG. 4 is a code diagram showing an example of a source code generation result by the skeleton shown in FIG. 3. FIG. 5 is an entity relation diagram (ERD) showing a data structure when the processes of FIGS. 3 to 4 are performed. It is a figure which shows an example of the table (ERD) regarding SQL definition in the system design assistance program which concerns on the 2nd Embodiment of this invention. It is a figure which shows an example of the table (ERD) which stored the information regarding the SQL definition directly input in the system design assistance program which concerns on the 2nd Embodiment of this invention. It is a figure which shows an example of ERD of the macrofunction stored in the 2nd repository in the system design support program which concerns on the 3rd Embodiment of this invention. It is the figure which input the logic (macro function) to a certain function in the system design support program which concerns on the 3rd Embodiment of this invention. It is a figure which shows the wizard corresponding to the line which calls the macro function shown in FIG. FIG. 11 is a diagram showing a wizard displayed after a “Next (F9)” button is pressed in the wizard shown in FIG. 10. It is a figure which shows the wizard which receives the Native sentence for describing the substance of a macro in the system design support program which concerns on the 3rd Embodiment of this invention. It is a figure which shows an example of ERD which shows the entity regarding the field of the data stored in the dictionary which "XupperII" which concerns on the 4th Embodiment of this invention accesses. In the system design support program which concerns on the 4th Embodiment of this invention, it is a figure which shows an example of ERD which mutually associates "Field type" in "XupperII" and "Data type according to XE_language" in "MDFrame / X" . It is a figure which shows an example of the wizard at the time of inputting "assignment" processing with respect to an action diagram in the system design support program which concerns on the 5th Embodiment of this invention. In the system design support program concerning a 5th embodiment of the present invention, it is a figure showing an example of ERD of "XE_language data type" and "XE_language data type relation". It is a figure which shows an example of the wizard at the time of inputting "assignment" processing with respect to an action diagram in the system design support program which concerns on the 6th Embodiment of this invention. In the system design support program concerning a 6th embodiment of the present invention, it is an example of ERD of "XE_language data type" and "XE_language data type permissible CND". It is a figure which shows an example of ERD regarding the partial skeleton in the system design assistance program which concerns on the 7th Embodiment of this invention. The relationship between the GUI control handled by “Xupper II”, the “design GUI control” handled by “MDFrame / X”, and the GUI control to be generated in the system design support program according to the eighth embodiment of the present invention is shown. It is a block diagram. It is a figure which shows an example of ERD regarding "XE_language omission default GUI control allocation" in the system design support program which concerns on the 8th Embodiment of this invention. It is a figure which shows an example of ERD regarding the design GUI control in the system design support program which concerns on the 8th Embodiment of this invention. It is a figure which shows an example of ERD to which the entity which stores the information regarding each generation name was added with respect to three elements of a property, a method, and an event shown in FIG. It is a code figure which shows the implementation example of GUI control in the case of making "BizBrowser" into a production | generation object language in the system design support program which concerns on the 9th Embodiment of this invention. Logic used for determining whether or not the return value of each item in the case of the text box and the case of the combo box in the system design support program according to the ninth embodiment of the present invention is “SQL_EXIST”. FIG. It is a figure which shows the definition of the panel variable in the system design assistance program which concerns on the 9th Embodiment of this invention. It is a block diagram which shows the method of accessing the panel variable in the system design assistance program which concerns on the 9th Embodiment of this invention. It is a code figure showing an example of 1 generation of a “GetAndValidate” method in a system design support program concerning a 9th embodiment of the present invention. It is a code figure showing an example of 1 generation of the "Put" method in the system design support program concerning a 9th embodiment of the present invention. It is a code figure which shows an example of the determination logic regarding the return value of the item on the panel in the system design support program which concerns on the 9th Embodiment of this invention. It is a figure which shows an example of the screen image of the slip input format in the system design support program which concerns on the 10th Embodiment of this invention. In the system design support program which concerns on the 10th Embodiment of this invention, it is a code figure which shows the initialization process of the background color of each display item in the "slip header part" when making "BizBrowser" into a production | generation object language. It is a figure which shows an example of ERD regarding the display item of the GUI screen in the system design support program which concerns on the 10th Embodiment of this invention. It is a code figure showing an example of 1 generation of a “GetAndValidate” method in a system design support program concerning a 10th embodiment of the present invention. It is a code figure showing an example of 1 generation of the "Put" method in the system design support program concerning a 10th embodiment of the present invention. It is a code figure showing an example of 1 generation of a “SetOriginalState” method in a system design support program concerning a 10th embodiment of the present invention. It is a code diagram showing an example of generation of a “Check Required” method in the system design support program according to the tenth embodiment of the present invention. It is a figure which shows an example of ERD regarding the common macro in the system design support program which concerns on the 11th Embodiment of this invention. It is a figure showing the screen image which performs parameter mapping with respect to a common macro instruction by the actual action diagram in the system design support program which concerns on the 11th Embodiment of this invention. FIG. 40 is a code diagram generated as four types of source code from one line of macro instructions input to the action diagram shown in FIG. 39.

Explanation of symbols

10 Xupper II
11 First repository 20 MDFrame / X
21 Second repository 30 Integrated repository 31 BizCRS file 32 Java source 33 Procedure source

Claims (13)

A system design support program using a data-centric approach,
On the computer,
Function A that stratifies the input business flow into multiple processes,
A plurality of entities used for each of the processes, and a function B for creating an entity relation diagram representing a relation between the entities;
A function C for creating a dictionary holding input / output data necessary for each process and field data of each entity;
A function D for designing a graphical user interface with reference to the entity relation diagram and the dictionary;
A function E for creating a repository by registering hierarchical data in each process, attribute data of each entity, data related to the dictionary and the graphical user interface design, respectively;
Reference is made to at least one of each process, each entity, data held in the dictionary, and data related to the graphical user interface design, and a logic definition that enables the processes to be executed from the outside is input. By realizing the function F that automatically generates and outputs the source code ,
The function F uses the SQL syntax when inputting the logic definition, and when the logic definition is input, if the input logic definition is defined in the SQL syntax, an interactive form by the wizard is used. On the other hand, when the input logic definition is not defined in the SQL syntax, the system design support program includes a function of directly inputting an undefined logic definition and registering it in the repository.   The system design support program according to claim 1, wherein the source code is a Java language, a high-speed engine Procedure language, or a BizCRS language. The source code in the function F has a function for executing the process for each process,
In the function, the function F is a function that configures a component of a logic statement that expands the logic definition by a plurality of skeletons, each of which is a framework of source code, and a plurality of skeletons, a skeleton logic unit, A function for decomposing into a generation logic unit for each replacement character string and a generation logic unit for each user point, and generating the decomposed generation logic unit for each replacement character string into the replacement character string among the data registered in the repository 3. The function according to claim 1, further comprising a function of replacing data corresponding to a logic part and a function of replacing the decomposed generation logic part by user point with the input logic definition. System design support program.   The system design support program according to claim 3, wherein the function F includes a function that allows the skeleton logic unit to be rewritten from the outside. A function G for registering source code not automatically generated in the repository as a macro function in advance;
The function F includes a function of expanding the macro function registered in the repository into the source code when the source code is automatically generated. The described system design support program. 6. The function C according to claim 1, wherein the data type of field data of each entity is stored in the dictionary as a first master file according to a language type of the source code. The system design support program described in the section. The function C determines the validity of each process to be performed when performing at least one of data assignment, calculation, comparison, and call parameter matching performed between field data of each entity. The system design support program according to claim 6, further comprising a function of storing a code to be stored in the dictionary as a second master file . When the function C performs at least one of data substitution, comparison, and call parameter matching executed between the field data of the entities, the function C is output for each output condition as a result of the processing performed. The system design support program according to claim 6 or 7, further comprising a function of holding a code for determining validity as a third master file in the dictionary . The function C is a source corresponding to a process to be performed when performing at least one of a data assignment statement, a conditional statement, an operation statement, and parameter matching executed between field data of the entities. The system design support program according to any one of claims 6 to 8 , further comprising a function of holding a generation rule for each code as a fourth master file in the dictionary . The function E includes a function of registering properties, methods, and events in a control command used for the graphical user interface design in the repository as a design control command independent of the source code,
The function F includes a graphical user interface corresponding to the source code based on the property, method, and event, the design control command, the field data type of each entity, and the type of the source code. system design support program according to any one of claims 1 to 9, characterized in that it comprises a function of generating. The function E includes a function of registering a return value of a control command used for the graphical user interface design in the repository as a panel variable,
11. The function F includes a function of acquiring the panel variable by issuing a logical method independent of the source code, and expanding the acquired panel variable into the source code. The system design support program according to claim 1. The function E includes the function of grouping each panel variable that is used for the graphical user interface design and that is referred to by a plurality of control commands and registered in the repository.
The function F is a function of converting the plurality of control commands into a batch command for issuing one command for each of the grouped panel variables;
12. The function according to claim 1 , further comprising a function of acquiring the corresponding panel variable by issuing the batch command, and expanding the acquired panel variable into the source code by the number of the panel variables. The system design support program according to claim 1. The function E includes a function of registering, in the repository, a common macro instruction in which definition information unique to each process is shared.
The system design support program according to claim 1, wherein the function F includes a function in which the logic definition refers to the common macro instruction when generating the source code. .