JP2007094453A - Program development support system, program development support method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a program development support system for automatically generating a form of source code from one piece of design information obtained by collecting dynamic design information and static design information, an external file, and a test item. <P>SOLUTION: A class dependency relation analysis part 15 analyzes the dependency relation between classes of static design information, specifies a screen transition information specification key, and narrows static design information related to screen transition corresponding to the screen transition information specification key. A screen transition information specification key analysis part 18 determines the same key as the screen transition information specification key in the static design information from dynamic design information. The static design information narrowed by the analysis part 15 and the dynamic design information related to the screen transition corresponding to the screen transition information specification key determined by the analysis part 18 are collected as one piece of design information, and the form of source code, the external file and the test item are generated from the one piece of design information. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a program development support system, a program development support method, and a program for generating a source code template, an external file, and test items from program static design information and dynamic design information.

  There is a technique for automatically generating source code from a model such as UML (Unified Modeling Language) in the upstream design stage of software (for example, Patent Document 1). According to such a known technique, a program / source code of a static part is generated from a class diagram including static design information, while a program / source code of a dynamic part is generated from a state chart including dynamic design information. These program source codes can be combined to automatically generate a program source code as a final product.

  Static design information is design information that describes objects and static relationships (structures) between them. Typical examples include class diagrams and object diagrams. The class diagram describes the relationship between classes constituting the system, and the object diagram describes the relationship of objects at a certain point in the system. The dynamic design information is design information describing a dynamic relationship between objects, and includes, for example, a sequence diagram and a state chart diagram. The sequence diagram describes the message transmission / reception relationship between objects in time series, and the state chart diagram describes the state transitions of objects.

  However, this known technique is specialized in automatic generation of source code, and no consideration is given to generation of external files and test items described later.

  Here, the external file is setting information necessary for supplementing the operation of the program that is the final product, such as information relating to screen transitions. Information related to screen transition includes a combination of a class name (logic name) and a screen name (screen program name) used for screen transition. This is because in the upstream design stage of software, it would be an enormous amount of work if an attempt was made to describe static design information and dynamic setting information in a structure that takes into account the call relationship on the actual platform. . Therefore, in order to develop a program that operates on the target platform, an external file as described above is required in addition to the source code generated from the static design information and the dynamic setting information.

The test item is information such as a method / procedure necessary for testing the program that is the final product.
JP 2002-116911 A

  FIG. 19 shows a mechanism for generating source code, external files, and test items from various documents obtained by upstream design of software.

  Here, the static design information 401 and the dynamic design information 402 are design information (PSM) in a format depending on each platform. The source code 403 is a template of source code automatically generated from static design information. Hereinafter, what is simply described as “source code” is also synonymous. The external file 404 is automatically generated by the external file automatic generation device 405 under the input of static design information by the application developer. The test item 406 is automatically generated by the test item automatic generation device 408 under the input of the dynamic design information by the application developer and the input of the test item generation rule 407 in the selection format by the application developer. The test item generation rule 407 is rule format data for generating a test item. FIG. 20 shows a sequence related to generation of the source code 403, the external file 404, and the test item 406 by the above mechanism.

  FIG. 21 is a diagram showing a configuration when the above-described mechanism is made compatible with MDA (Model Driven Architecture) that has been attracting attention as a program development technique in recent years.

  MDA is a development method that does not depend on a platform (a specific programming environment), models an application function using a standard modeling technique such as UML, and further automatically generates code based on the model information. In MDA, business processes are analyzed in a manner independent of mounting technology, a platform independent model (PIM) is created, and then PSM is a model specialized for individual platforms based on PIM. (Platform Specific Model) is generated. Further, the PIM or PSM information is converted into actual source code 301 using a tool, and the mounting work proceeds.

  In the mechanism of FIG. 21, static design information (PIM) 411 that does not depend on the platform is converted into static design information (PSM) 401 specialized for an individual platform by a model compiler 412 for static design information. Source code 403 is generated based on information (PSM) 401. On the other hand, the platform-independent dynamic design information (PIM) 413 is converted into dynamic design information (PSM) 402 specialized for an individual platform by the dynamic design information model compiler 414, and the dynamic design information (PSM) ) 402 and an external file 404 are generated from the previous static design information (PSM) 401. Also, a test item 406 is generated from the dynamic design information (PSM) 402 and a test item generation rule (not shown).

  However, the above mechanism has the following problems.

  1. The creation of the external file 404 requires static design information and dynamic design information. However, since standard modeling techniques such as UML do not have diagrams (diagrams) that can describe static design information and dynamic design information at the same time, the necessary information is extracted from at least two diagrams when the external file 404 is created. There must be.

  2. As shown in FIG. 22, the platform-independent dynamic design information (PIM) 413 cannot describe information such as class names and screen transition conditions used during screen transition. However, in the case of dynamic design information (PSM) 402 specialized for an individual platform, information such as the class name used during screen transition and screen transition conditions such as “Press the“ Search ”button” is required. Therefore, it is practically difficult to automatically generate dynamic design information (PSM) 402 specialized for each platform from platform-independent dynamic design information (PIM) 413. In addition, test item 406 is difficult. In addition, the dynamic design information (PIM) 413 that does not depend on the platform is not sufficient, and information such as a class name and a screen transition condition used during screen transition is necessary.

  3. 2. It is possible for application developers to solve the problem by manually adding information such as class names and screen transition conditions. However, the two diagrams of static design information and dynamic design information are finally managed, and management becomes complicated.

  In view of such circumstances, the present invention obtains design information obtained by combining static design information and dynamic design information into one, and automatically generates a source code template, an external file, and test items based on the design information. An object of the present invention is to provide a program development support system, a program development support method, and a program that can be generated.

  In order to solve the above problems, a program development support system according to the present invention includes screen transition information related to screen transition of a program, dynamic design information including a key for specifying the screen transition information, and classes constituting the program A program design information holding unit for holding information indicating a relationship between the keys and static design information including the key, and analyzing a dependency relationship between classes of the static design information held in the program design information holding unit A class dependency analysis unit that determines the key and narrows down static design information related to the screen transition corresponding to the determined key; and a key included in the dynamic design information held in the program design information holding unit. Screen transition information specifying key analysis unit to be determined, static design information narrowed down by the class dependency analysis unit, and the screen transition information Based on the design information output unit that outputs the dynamic design information related to the screen transition corresponding to the key determined by the constant key analysis unit as one design information, and the design information output by the design information output unit And a generation unit that generates at least one of a source code template, an external file, and a test item.

  According to the present invention, since one design information in which dynamic design information and static design information related to a common screen transition are collected is obtained, a source code template, an external file, Test items can be automatically generated.

  In addition, if you need information such as screen transition conditions such as “Press the“ Search ”button” when generating test items, you can incorporate the screen transition conditions in the dynamic design information in advance. When the transition information identification key analysis unit narrows down the necessary dynamic design information, the screen transition condition may be included in the narrowed down result, and the dynamic design information and the static design information are managed as one design information. This can also reduce the burden on management.

  Furthermore, the present invention includes a display unit that displays design information output by the design information output unit, and an input support unit that performs editing based on an input from an application developer for the design information displayed on the display unit. It may have an added configuration.

  According to the present invention, it is possible to obtain design information in which static design information and related dynamic design information are combined into one, and based on this design information, a source code template, an external file, a test Items can be automatically generated.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a diagram showing a configuration of an application development support system 100 and its peripheral part according to an embodiment of the present invention.

  In the figure, the application development support system 100 of the present embodiment is a portion surrounded by a dotted line. The application development support system 100 according to the present embodiment includes a source code / external file / test item generation apparatus 1. This source code / external file / test item generation apparatus 1 is a static design information specialized for an individual platform, converted from a platform-independent static design information (PIM) 201 by a model compiler 202 for static design information. (PSM) 203, platform-independent dynamic design information (PIM) 204, and test item generation rules 205, which are data expressing know-how regarding test viewpoints and judgment criteria in a rule format, are input, and source code 301, It is a device that automatically generates an external file 302 and test items 303.

  The source code / external file / test item generation apparatus 1 is configured by a typical computer configuration, that is, a central processing unit, a main memory, an input unit, an output unit, and the like. The main memory stores a source code, an external file, a processing procedure (program) of the test item generating apparatus 1, and the like. The central processing unit executes the processing procedure stored in the main memory.

  FIG. 2 is a block diagram showing the configuration of the source code / external file / test item generation apparatus 1 in the application development support system 100 of this embodiment.

  In the figure, the display / input unit 11 of the source code / external file / test item generating device 1 is a design information that combines various inputs from the application developer, static design information and dynamic design information. It is a man-machine interface that displays and the like. The display / input unit 11 includes a storage unit that stores design information to be displayed on the screen.

  The static design information generation control unit 12 performs control related to generation of static design information displayed on the display / input unit 11.

  The dynamic design information generation control unit 13 performs control related to generation of dynamic design information displayed on the display / input unit 11.

  The program design information holding unit 14 reads and holds static design information (PSM) 203 and dynamic design information (PIM) 204 in accordance with an instruction from the dynamic design information generation control unit 13.

  The class dependency analysis unit 15 reads the static design information held in the program design information holding unit 14, analyzes the dependency between the classes of the static design information, and incorporates the static design information into the static design information. The screen transition information identification key is determined, and the static design information related to the screen transition corresponding to the determined screen transition information identification key is narrowed down.

  The screen transition information specifying key analyzing unit 18 uses the same key as the screen transition information specifying key in the static design information determined by the class dependency relationship analyzing unit 15, in the dynamic design held in the program design information holding unit 14. Judge from information.

  The design information output unit 16 includes dynamic design related to the static design information narrowed down by the class dependency analysis unit 15 and the screen transition corresponding to the screen transition information identification key determined by the screen transition information identification key analysis unit 18. By outputting the design information to the display / input unit 11, the static design information and the dynamic design information related to the common screen transition are combined as one design information.

  The input support unit 17 edits the static design information narrowed down by the class dependency relationship analysis unit 15 based on the input from the application developer.

  The source code generation control unit 19 controls the generation of the source code 301 for the design information displayed on the display / input unit 11.

  The test item generation control unit 20 controls the generation of the test item 303 for the design information displayed on the display / input unit 11.

  The external file generation control unit 21 controls the generation of the external file 302 with respect to the design information displayed on the display / input unit 11.

  The program design information acquisition unit 22 acquires design information from the storage unit of the display / input unit 11 under the control of the source code generation control unit 19, the test item generation control unit 20, or the external file generation control unit 21.

  The program design information analysis unit 23 analyzes the design information held in the program design information acquisition unit 22 so that the source code 301, the test item 303, and the external file 302 can be generated.

  The template holding unit 24 is a part that holds a template for generating the source code 301 and the external file 302.

  The test item generation rule 205 is rule format data for generating a test item.

  The output unit 25 receives the analysis result of the design information by the program design information analysis unit 23, and uses the template and the test item generation rule 205 held in the template holding unit 24 to use the source code 301, the external file 302, the test An item 303 is generated and output.

  FIG. 3 is an example of a class diagram which is static design information.

  The class diagram describes the relationship between the classes that make up the system. Here, tag information 32 is added to the sampleProcessAction class 31 which is a class whose process stereotype is << process >>, and a key 33 for specifying screen transition information is included in the tag information 32. (Hereinafter referred to as “screen transition information identification key”) is set.

  FIG. 4 describes the static design information of FIG. 3 in XML. Reference numeral 41 denotes a description part of a class name (class ID). 42 is a description part of the dependency relationship between classes, client is a class ID of a dependency source, and supplier is a class ID of a dependency destination. 43 is a description part of the tag information of the class, and “registUser” and “showList” are set as the screen transition information specifying key 33 described above.

  FIG. 5 is an example of a state chart that is dynamic design information.

  As shown in the figure, the state chart diagram describes the state transition of the screen. In each screen transition, a screen transition condition 51 and a screen transition information specifying key 52 are described. The screen transition information identification key 52 corresponds to the screen transition information identification key 33 described in the class diagrams shown in FIGS. In the state chart diagram of this example, when the “Register” button is pressed on the index.jsp screen 53, the screen transitions to the registUserForm.jsp screen 54 and the “Search” button is pressed on the index.jsp screen 53. This represents that transition to the screen 55 of showList.jsp is performed. Here, “press the“ register ”button” and “press the“ search ”button” are the screen transition conditions 51. The screen transition information specifying key 52 is added corresponding to each screen transition condition 51. The incorporation of the screen transition information identification key 52 into the dynamic design information may be performed in a format selected by the application developer from the displayed candidates.

  FIG. 6 describes the dynamic design information of FIG. 5 in XML. The request 61 is transition information of the showList, in which “showList” is described as the screen transition information specifying key, and “push“ search ”button” is described as the screen transition condition. 62 is the transition information of the request registUser, in which “registUser” is described as the screen transition information specifying key, and “Press the“ Search ”button” is described as the screen transition condition.

  Next, the operation of the application development support system 100 of this embodiment will be described.

  FIG. 7 is a sequence diagram relating to reading of static design information by the source code / external file / test item generation apparatus 1 of the application development support system 100 of this embodiment.

  First, a static design information display command is input on the application developer 300 screen (S1). The static design information display command is given to the static design information generation control unit 12 through the display / input unit 11 (S2), and the static design information generation control unit 12 sends a static design information to the program design information holding unit 14. An information read command is issued (S3). The program design information holding unit 14 receives and holds the static design information (PSM) 203 in response to a static design information read command (S4, S5).

  Next, the static design information generation control unit 12 issues a class dependency relationship analysis command of the read static design information to the class dependency relationship analysis unit 15 (S6). Upon receiving this analysis instruction, the class dependency relationship analysis unit 15 issues a static design information acquisition instruction to the program design information holding unit 14 (S7), acquires static design information (S8), and Static analysis related to the screen transition corresponding to the determined screen transition information specific key by analyzing the class dependency described in the static design information and determining the screen transition information specific key embedded in the static design information The design information is narrowed down (S9).

  Thereafter, the static design information generation control unit 12 issues a design information output command to the design information output unit 16 (S10). Upon receiving this instruction, the design information output unit 16 issues a static design information narrowing result acquisition command to the class dependency relationship analyzing unit 15 (S11), and acquires the static design information narrowing result (S12). ).

  Next, the design information output unit 16 calls the input support unit 17, and passes the obtained static design information narrowing result to the input support unit 17 (S13). Under the input from the application developer 300, the input support unit 17 edits the static design information narrowing result, such as correction based on human judgment, addition, and screen transition narrowing (S14). The edited static design information is transferred to the design information output unit 16 (S15), output from the design information output unit 16 to the display / input unit 11 as display data (S16), and displayed to the application developer 300. (S17).

  FIG. 8 shows an example of narrowing down the static design information.

  The results of narrowing down the static design information are mapped in Table 81. The record in this table 81 is created for each screen transition, that is, for each screen transition information specifying key 33 in the tag information 32 of the class 31 whose stereotype is << process >>. Therefore, in the example of FIG. 8, records corresponding to the screen transition information specifying keys 33 of “registUser” and “showList” are created.

  The record in Table 81 is composed of a plurality of items in which the results of narrowing down static design information and dynamic design information are entered. In the item that contains the static design information refinement result, the class name of the class whose stereotype is << process >> is set, and the class name of the class whose stereotype is << dataSet >> is set. Action form, class name of the class whose stereotype is << servicePackage >> is set, the class whose operation is set to the operation of the web layer service, class whose stereotype is << DAO >> There are an entity in which a class name is set, a processing result data set in which a class name of a class whose stereotype is << valueObject >> is set, and the like. Items containing the dynamic design information narrowing result include items such as a request generation screen, a request containing a screen transition condition, a request path containing a screen transition information identification key, and a transition destination screen.

  The following interface is prepared for the application developer to narrow down the static design information to be displayed on the display / input unit 11 from the static design information narrowed down by the class dependency analysis unit 15. .

  FIG. 9 is a diagram showing an example of this interface. In each item of Table 81, class information corresponding to this item can be displayed in a pull-down menu format. By selecting desired class information from the pull-down menu 91 by, for example, a mouse click operation, the selected class information is determined as item information. The information of the other items corresponding to one screen transition including the information of the selected class is automatically set. Thereby, the static design information to be displayed on the display / input unit 11 can be easily selected and narrowed down under the judgment of the application developer.

  Next, reading of dynamic design information will be described.

  FIG. 10 is a sequence diagram relating to reading of dynamic design information.

  First, the application developer 300 inputs a dynamic design information display command on the display / input unit 11 (S1). This dynamic design information display command is given to the dynamic design information generation control unit 13 through the display / input unit 11 (S2), and the dynamic design information generation control unit 13 sends the dynamic design information generation control unit 13 to the dynamic design information generation unit 14 for dynamic design. An information read command is issued (S3). The program design information holding unit 14 receives and holds dynamic design information (PIM) 204 in response to a dynamic design information read command (S4, S5).

  Next, the dynamic design information generation control unit 13 issues a screen transition information identification key analysis command to the screen transition information identification key analysis unit 18 (S6). When the screen transition information specifying key analysis unit 18 receives this analysis instruction, it acquires dynamic design information from the program design information holding unit 14 (S7, S8), and subsequently the analysis result (static) of the class dependency relationship analysis unit 15 is obtained. (S9, S10), and the screen transition information specifying key that is the same as the screen transition information specifying key of the static design information is determined from the dynamic design information (S11).

  Thereafter, the dynamic design information generation control unit 13 issues a design information output command to the design information output unit 16 (S12). When the design information output unit 16 receives this instruction, it acquires the screen transition information specifying key from the screen transition information specifying key analysis unit 18 (S13, S14), and then acquires the dynamic design information from the program design information holding unit 14. (S15, S16), the dynamic design information related to the screen transition corresponding to the screen transition information specifying key is narrowed down from the acquired dynamic design information (S17), and the result is output to the display / input unit 11 (S18), displayed to the application developer 300 (S19).

  FIG. 11 shows an example of narrowing down dynamic design information.

  As shown in the figure, the dynamic design information narrowing result is the request of each record for each screen transition, the request generation screen, the request path, and the transition destination in the table 81 in which the static design information narrowing result is already set. Recorded in each item on the screen. At this time, since the record for each screen transition corresponding to each screen transition information specifying key 33 has already been created in the table 81 by analyzing the class dependency relationship of the static design information, the design information output unit 16 In the design information, the screen transition condition 51 described corresponding to the same screen transition information specifying key 52 as the screen transition information specifying key 33 is detected, and the screen transition information specifying key 52 is set in the request path item of the corresponding record. The screen transition condition 51 is set in each request item of the corresponding record.

  Next, an operation when the source code 301 is generated based on the static design information displayed on the display / input unit 11 will be described.

  FIG. 12 is a sequence diagram relating to the generation of the source code 301.

  First, the application developer 300 inputs a generation instruction of the source code 301 on the display / input unit 11 (S1). The generation instruction of the source code 301 is given to the source code generation control unit 19 (S2), and the source code generation control unit 19 issues an acquisition instruction of static design information to the program design information acquisition unit 22 (S3). When receiving the static design information acquisition command, the program design information acquisition unit 22 acquires and holds the static design information from the storage unit of the display / input unit 11 (S4).

  Thereafter, the source code generation control unit 19 issues a static design information analysis command to the program design information analysis unit 23 (S5). When receiving the analysis instruction, the program design information analysis unit 23 acquires static design information from the program design information acquisition unit 22 (S6, S7), analyzes the static design information, and generates the source code 301. Necessary information is acquired as an analysis result (S8).

  Next, the source code generation control unit 19 instructs the output unit 25 to output the source code 301 (S9). Upon receiving this output instruction, the output unit 25 acquires the analysis result from the program design information analysis unit 23 (S10, S11), and acquires the template of the source code 301 corresponding to the analysis result from the template holding unit 24 (S12, S11). S13). Then, the output unit 25 generates the source code 301 of the static design information based on the obtained analysis result of the static design information and the template of the source code 301 (S14), and outputs it (S15).

  As a result, a template of the source code 301 as shown in FIG. 13 is generated. This figure is an example of a template of the source code 301 generated for the static design information shown in FIG.

  Next, an operation when the external file 302 is generated based on the static design information and the dynamic design information displayed on the display / input unit 11 will be described.

  FIG. 14 is a sequence diagram relating to generation of the external file 302.

  First, the application developer 300 inputs a generation command for the external file 302 on the display / input unit 11 (S1). This external file 302 generation command is given to the external file generation control unit 21 (S2), and the external file generation control unit 21 issues a static / dynamic design information acquisition command to the program design information acquisition unit 22 (S3). . When receiving the static / dynamic design information acquisition command, the program design information acquisition unit 22 acquires and holds the static design information and dynamic design information from the storage unit of the display / input unit 11 (S4).

  Next, the external file generation control unit 21 issues a static / dynamic design information analysis command to the program design information analysis unit 23 (S5). When receiving the analysis instruction, the program design information analysis unit 23 acquires the static design information and the dynamic design information from the program design information acquisition unit 22 (S6, S7). Analysis is performed to obtain information necessary for generating the external file 302 as an analysis result (S8).

  Thereafter, the external file generation control unit 21 instructs the output unit 25 to output the external file 302 (S9). Upon receiving this output instruction, the output unit 25 acquires the analysis result of the static design information and the dynamic design information from the program design information analysis unit 23 (S10, S11), and the external corresponding to the analysis result from the template holding unit 24. The template of the file 302 is acquired (S12, S13). Then, the output unit 25 generates the external file 302 based on the obtained static design information and dynamic design information analysis results and the template of the external file 302 (S14), and outputs it (S15).

  Thereby, an external file 302 as shown in FIG. 15 is generated. This figure is an example of the external file 302 generated for the static design information and the dynamic design information shown in FIG.

  Next, an operation when the test item 303 is generated based on the dynamic design information displayed on the display / input unit 11 will be described.

  FIG. 16 is a sequence diagram relating to the generation of the test item 303.

  First, the application developer 300 inputs a generation command for the test item 303 on the display / input unit 11 (S1). The test item 303 generation command is given to the test item generation control unit 20 (S2), and the test item generation control unit 20 issues a dynamic design information acquisition command to the program design information acquisition unit 22 (S3). When receiving the dynamic design information acquisition command, the program design information acquisition unit 22 acquires and holds the dynamic design information from the display / input unit 11 (S4).

  Next, the test item generation control unit 20 issues a dynamic design information analysis command to the program design information analysis unit 23 (S5). Upon receiving the analysis instruction, the program design information analysis unit 23 acquires dynamic design information from the program design information acquisition unit 22 (S6, S7), analyzes the dynamic design information, and generates a test item 303. Necessary information is acquired as an analysis result (S8).

  Thereafter, the test item generation control unit 20 instructs the output unit 25 to output the test item 303 (S9). Upon receiving this output instruction, the output unit 25 acquires the analysis result of the dynamic design information from the program design information analysis unit 23 (S10, S11), and acquires the test item generation rule 205 (S12, S13). And the output part 25 produces | generates the test item 303 based on the analysis result of the acquired dynamic design information, and the test item production | generation rule 205 (S14), and outputs it (S15).

  Thereby, a test item 303 as shown in FIG. 17 is generated. This figure is an example of the test item 303 generated for the dynamic design information (Table 81) shown in FIG.

  As described above, according to the present embodiment, it is possible to obtain design information in which static design information and dynamic design information related to a common screen transition are combined into one, and based on this design information. The template of the source code 301, the external file 302, and the test item 303 can be automatically generated. In addition, by incorporating the screen transition condition in the dynamic design information in advance, it becomes possible to generate the test item 303 including the screen transition condition. Furthermore, since dynamic design information and static design information can be managed as a single piece of design information, an effect of reducing the burden on management can be obtained.

(Other embodiments)
FIG. 18 is a diagram showing another embodiment of an interface for the application developer to narrow down the static design information to be displayed on the display / input unit 11 from the static design information narrowed down by the class dependency analysis unit 15. It is.

  As shown in the figure, in this example, for each item of the static design information, a list of class information extracted from the static design information by the class dependency analysis unit 15 is displayed in the list display box 181; Information on the class selected by the application developer 300 by a mouse click operation or the like is displayed in the input box 182 and determined as class information on the item. When the information of this item is confirmed, the information of the other item corresponding to one screen transition including the information of the selected class is automatically set in the input box 182 of the other item. Note that it is also possible for the application developer 300 to directly input class information in the input box 182. Thereby, static design information corresponding to one screen transition can be collectively input while comparing each item, and input efficiency can be increased. The input boxes for each item do not have to be filled in, and may be left blank if there are undecided classes at the design stage.

  It should be noted that the present invention is not limited to the illustrated examples described above, and it is needless to say that various modifications can be made without departing from the scope of the present invention.

It is a figure which shows the structure of the application development assistance system 100 concerning one Embodiment of this invention, and its periphery part. FIG. 2 is a block diagram illustrating a configuration of a source code / external file / test item generation apparatus 1 in the application development support system 100 of FIG. 1. It is an example of a class diagram which is static design information. FIG. 4 is a diagram describing the static design information of FIG. 3 in XML. It is an example of the state chart figure which is dynamic design information. FIG. 6 is a diagram describing the dynamic design information of FIG. 5 in XML. It is a sequence diagram regarding reading of static design information by the source code / external file / test item generation device of the application development support system of the present embodiment. It is a figure which shows the example regarding narrowing-down of static design information. It is a figure which shows the interface for an application developer itself to narrow down the static design information displayed on a display and input part from the static design information narrowed down by the class dependence analysis part. It is a sequence diagram regarding reading of dynamic design information. It is a figure which shows the example regarding narrowing-down of dynamic design information. It is a sequence diagram regarding generation of source code. It is a figure which shows the example of the template of the produced | generated source code. It is a sequence diagram regarding generation of an external file. It is a figure which shows the example of the produced | generated external file. It is a sequence diagram regarding the production | generation of a test item. It is a figure which shows the example of the produced | generated test item. It is a figure which shows other embodiment of the interface for an application developer itself to narrow down the static design information displayed on a display and input part from the static design information narrowed down by the class dependence analysis part. It is a figure which shows the structure which produces | generates a source code, an external file, and a test item from the various documents obtained by the upstream design of software. FIG. 20 is a sequence diagram relating to generation of a source code, an external file, and a test item according to the mechanism of FIG. It is a figure which shows the structure at the time of making the structure of FIG. 19 respond | correspond to MDA. It is a figure for demonstrating the subject of FIG.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Source code / external file / test item generation device, 100 ... Display / input unit, 12 ... Static design information generation control unit, 13 ... Dynamic design information generation control unit, 14 ... Program design information holding unit, 15 ... Class dependency analysis unit, 16 ... design information output unit, 17 ... input support unit, 18 ... screen transition information identification key analysis unit, 19 ... source code generation control unit, 20 ... test item generation control unit, 21 ... external file generation Control unit, 22 ... Program design information acquisition unit, 23 ... Program design information analysis unit, 24 ... Template holding unit, 25 ... Output unit, 33, 52 ... Screen transition information identification key, 51 ... Screen transition condition, 100 ... Application development Support system 203 ... Static design information (PSM) 204 ... Dynamic design information (PIM) 205 ... Test item generation rule 301 ... Source code De, 302 ... external file, 303 ... test items.

Claims (7)

Screen transition information relating to program screen transition and dynamic design information including a key for specifying the screen transition information, information indicating a relationship between classes constituting the program, and static design information including the key, respectively A program design information holding unit to hold;
Class dependence that narrows down static design information related to screen transition corresponding to the determined key by analyzing the dependency relationship between classes of static design information held in the program design information holding unit and determining the key A relationship analysis unit;
A screen transition information specifying key analyzing unit for determining a key included in the dynamic design information held in the program design information holding unit;
The static design information narrowed down by the class dependency analysis unit and the dynamic design information related to the screen transition corresponding to the key determined by the screen transition information specifying key analysis unit are output as one design information A design information output unit,
A program development support system comprising: a generation unit that generates at least one of a source code template, an external file, and a test item based on the design information output by the design information output unit. A display unit for displaying the design information output by the design information output unit;
The program development support system according to claim 1, further comprising: an input support unit that edits the design information displayed on the display unit based on an input from an application developer. The dynamic design information includes a condition for causing a screen transition,
2. The program development support system according to claim 1, wherein the dynamic design information narrowed down by the screen transition information specifying key analysis unit includes at least the condition. The program design information holding unit includes screen transition information related to program screen transition and dynamic design information including a key for specifying the screen transition information, information indicating a relationship between classes constituting the program, and the key. Holding static design information; and
The class dependency analysis unit analyzes the dependency relationship between the classes of the static design information held in the program design information holding unit, determines the key, and relates to the screen transition corresponding to the determined key. A step to narrow down static design information,
Determining the key included in the dynamic design information held in the program design information holding unit by the screen transition information specifying key analysis unit;
Static design information narrowed down by the class dependency analysis unit by the design information output unit, and dynamic design information related to the screen transition corresponding to the key determined by the screen transition information specifying key analysis unit Outputting as one piece of design information;
Generating a program based on the design information output by the design information output unit by the generation unit, at least one of a template of a source code, an external file, and a test item. Support method. Displaying the design information output by the design information output unit by a display unit;
6. The program development support method according to claim 5, further comprising: a step of editing the design information displayed on the display unit based on an input from an application developer in the input support unit. . The dynamic design information includes a condition for causing a screen transition,
6. The program development support method according to claim 5, wherein the dynamic design information narrowed down by the screen transition information identification key analysis unit includes at least the condition. Computer
Holds screen transition information related to program screen transitions, dynamic design information including a key for specifying the screen transition information, information indicating a relationship between classes constituting the program, and static design information including the key A program design information holding unit for
Class dependence that narrows down static design information related to screen transition corresponding to the determined key by analyzing the dependency relationship between classes of static design information held in the program design information holding unit and determining the key A relationship analysis unit;
A screen transition information specifying key analyzing unit for determining a key included in the dynamic design information held in the program design information holding unit;
The static design information narrowed down by the class dependency analysis unit and the dynamic design information related to the screen transition corresponding to the key determined by the screen transition information specifying key analysis unit are output as one design information A design information output unit,
A program that functions as a generation unit that generates at least one of a source code template, an external file, and a test item based on design information output by the design information output unit.

Images