JP2006221293A - Software design support device and storage medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a software design support device that enables even an inexperienced designer to apply any design pattern. <P>SOLUTION: The software design support device includes a means for inputting a variety of software design drawings using a notation specified by UML; a means for supporting the description of the design drawings; a means for storing the inputted design drawings in a storage device; and a means for taking detailed information about each design component out of the design drawings described. The device also includes a means for extracting the necessary information from a class drawing and a sequence drawing that are inputted by the designer, and automatically determining whether or not a Facade pattern serving as one software design pattern is applicable. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a support device and a storage medium for automatically applying a design pattern to software design.

  In recent years, the field of embedded software development such as digital multi-function peripherals has been increasing in functionality and scale. Therefore, object-oriented development is being introduced to improve maintainability and reusability. In software development using an object-oriented design technique, various design drawings are generally described using a notation called UML (Unified Modeling Language).

  However, skill is required to be able to design with excellent maintainability and reusability. In other words, even if a design drawing is created by a notation defined by UML based on an object-oriented analysis / design method, the quality of the design is not guaranteed.

  In the field of object-oriented design, there is a movement to pattern superior design know-how and put it together in a format that is easy to reuse. This patterned design know-how is called a “design pattern” (for example, Non-Patent Document 1). In other words, the design pattern is a systematic name and description added to a design that is important and repeatedly appears in software development developed based on an object-oriented analysis / design technique.

  As a conventional technique, an apparatus for creating a software specification using a design pattern (Patent Document 1), an apparatus for determining whether the application of a design pattern is appropriate (Patent Document 2), etc. are disclosed. Then, the design pattern to be applied in advance must be designated by the designer, and the design must be carried out accordingly. As a result, it is a device that can verify whether the created design drawing is in accordance with the intention of the applied design pattern, but it requires skill to select the applicable design pattern, so it is used by non-experts Therefore, there is a possibility that the merit of the design pattern cannot be fully utilized.

JP-A-9-237180 JP-A-9-198242 “Design Patterns for Reuse in Object Oriented”, Softbank, 1995, E. Gamma et al.

  a) In order to apply the design pattern to the object-oriented design, the skill and experience of the designer are required, so that it is difficult for the unskilled person to apply. For this reason, it is an object to detect and automatically apply a location where a Fade pattern can be applied from design information input by a designer. By applying the Facade pattern, the software component can be separated from other software components and clients, and a design with excellent independence and portability becomes possible.

  b) It is intended that non-experts can learn about application examples of design patterns and good design by using this device.

  The present invention has been made in view of the above problems, and an object of the present invention is to provide a software design support apparatus that can solve the drawbacks of the above-described conventional example and that can be applied to design patterns even by an unskilled designer.

  In order to achieve the above object, the invention described in claim 1 is characterized in that means for inputting various software blueprints defined by UML, means for supporting the description of blueprints, and input blueprints. A means for storing in a storage device and means for extracting detailed information for each design part from the described design drawing, extracting necessary information from the class diagram and sequence diagram input by the designer, and providing a software design pattern 1 Since it is possible to automatically determine whether a single Fade pattern is applicable, even a non-skilled software designer can determine whether a software design pattern is applicable.

  According to a second aspect of the present invention, in the software design support apparatus according to the first aspect, information on packages to which each class belongs in the class diagram, class related information, class operation information, and event transmission information in the sequence diagram for each scenario Therefore, the application of the Facade pattern can be automatically determined.

  According to a third aspect of the present invention, in the software design support apparatus according to the first aspect, when the judging means judges that the application of the Facade pattern is possible, the class diagram and the sequence diagram to which the Facade pattern is applied are automatically generated. Thus, even a non-skilled person in software design can create a design drawing to which a Facade pattern is applied.

  According to a fourth aspect of the present invention, in the software design support apparatus according to the first aspect, when the determination unit determines that the application of the Facade pattern is possible, the designer is notified, and the designer uses the Facade pattern. By creating a class diagram and a sequence diagram to which the Facade pattern is applied only when it is determined to apply the above, it is possible to create only a design diagram that is determined to be necessary by the designer.

  The invention of claim 5 makes it possible to operate the software design support apparatus of claim 1 on a computer.

  According to the first aspect of the present invention, means for inputting various software blueprints defined by UML, means for supporting the description of blueprints, and the inputted blueprints are stored in the storage device. And a means for extracting detailed information for each design part from the described design drawing, extracting necessary information from the class diagram and sequence diagram input by the designer, and a Facade pattern which is one of the software design patterns Since it is possible to automatically determine whether the software design pattern is applicable, it is possible to determine whether the software design pattern is applicable even for non-skilled software designers and learn about good design. The effect that it can be obtained.

  According to a second aspect of the present invention, in the software design support apparatus according to the first aspect, in the class diagram, the information on the package to which each class belongs, the class related information, the class operation information, and the sequence diagram for each scenario. Since it can be determined from the transmission information of the event, the application of the Facade pattern can be automatically determined.

  According to a third aspect of the present invention, in the software design support apparatus according to the first aspect, the class diagram and the sequence to which the Facade pattern is applied when the determination unit determines that the Facade pattern can be applied. By automatically creating a diagram, even a non-skilled person in software design can create a design diagram to which a Facade pattern is applied, and can learn about good design.

  According to a fourth aspect of the present invention, in the software design support apparatus according to the first aspect, when the determination unit determines that the Facade pattern can be applied, the designer is notified, and the designer By creating a class diagram and a sequence diagram to which the Facade pattern is applied only when it is determined that the application of the Facade pattern is performed, it is possible to create only the design diagram that the designer determines is necessary Is obtained.

  According to the invention described in claim 5, it is possible to obtain the effect that the software design support apparatus described in claim 1 can be operated on the computer.

  Hereinafter, a method for supporting application of a Facade pattern in a software design support apparatus will be described as an embodiment of the present invention.

  FIG. 1 is a diagram showing an overview of a software design support apparatus according to the present invention. A UML model editor for creating an object-oriented design drawing using a diagram defined by UML is a well-known technique and will not be described in detail.

  D1 shows the whole and is composed of D2 to D5. D2 is a drawing area for actually describing a design diagram. For example, when a class diagram is described, the drawing region is switched to a class diagram, and when a sequence diagram is described, a sequence diagram is switched appropriately. D3 is a toolbox in which a UML diagram is stored. For example, when describing a class diagram, icons for class diagrams are arranged, and when describing a sequence diagram, icons for sequence diagrams are arranged.

  When a designer describes a figure in the drawing area D2, an icon is selected from the tool box D3 and placed in the drawing area D2. D4 is a browse area for centrally managing and displaying the information of the created design drawing. If you want to create a new diagram or switch between the diagrams already described, do so now. When the figure is switched in the browse area, the drawing area D2 and the tool box D3 are also switched accordingly. Further, in the browse area D3, detailed information of the described design drawing, for example, a relation source class name, a relation destination class name, a relation direction, a relation name, and the like of a relation line between classes in the class diagram are managed. D5 is a log display unit for displaying a log. The result of the designer's operation is displayed as appropriate. Also, when the designer has to make some judgment, options are displayed on the log display unit D5.

  FIG. 2 is a block diagram showing a functional configuration of the software design support apparatus according to the embodiment.

  In FIG. 2, E1 is a holding unit for a sequence diagram for each scenario input from the designer. E2 is a holding unit for class diagram information input from the designer. E3 is a device for creating a correspondence table (E4) of classes existing in the package described in the format shown in FIG. 3 and a correspondence table (E5) with the operations held by the classes described in the format shown in FIG. It is. E6 is an apparatus for extracting an event received by a class belonging to each package and creating a package / event correspondence table (E9) described in the format shown in FIG. E7 is an apparatus for extracting a relationship in which a class belonging to a package is referenced from a class belonging to an external package and creating a package / relationship correspondence table (E11) described in the format shown in FIG.

  E8 is an apparatus that extracts events exchanged for each scenario and creates a scenario / event correspondence table (E12) described in the format shown in FIG. E10 is a device that determines whether a Facade pattern is applicable for each package from E9 and E11, and creates a Facade pattern application determination result storage table (E13) described in the format shown in FIG. E14 is a device that creates a Facade class based on E4, E5, and E6, and creates E15 and E16.

  E18 is a device that creates E17 by reflecting the Facade class in E11. E19 is a device for displaying the class diagram to which the Facade pattern is applied based on E17 on the output device. E22 is an apparatus for creating E21 by reflecting the Facade class in E12. E20 is a device for displaying a sequence diagram to which the Facade pattern is applied based on E21 on the creation output device.

  FIG. 9 is a flowchart showing a process until the Facade pattern is automatically applied to the design information input in the software design support apparatus of FIG.

  In S1, design information such as a sequence diagram divided for each class diagram and scenario is input from the designer. An example of the created class diagram is shown in FIG. 21, and an example of the sequence diagram is shown in FIG.

  In S2, information necessary for automatically applying the Facade pattern is extracted from the inputted design information, and various tables are created. Examples of various tables are shown in FIGS. The detailed algorithm is shown in FIGS. In S3, it is determined on a package basis whether the Facade pattern is applicable based on the table information created in S2. The detailed algorithm is shown in FIG. In S4, a Facade class is automatically created for each package based on the determination result in S3, and the applied class diagram and sequence diagram are generated and displayed. The detailed algorithm is shown in FIGS. Examples of class diagrams and sequence diagrams to which the Facade pattern is automatically applied using this apparatus are shown in FIGS.

  FIG. 10 is a flowchart showing a detailed algorithm of the package / class correspondence table creating apparatus E3 for creating the package / class correspondence table E4 from the class diagram information E2.

  In S5, a new package / class correspondence table E4 is created. In S6, a package belonging to a certain class is acquired from the class diagram E2 and stored in a variable called Pname. In S7 to S8, Pname is searched in the package name column of the package / class correspondence table E4. If it is not found, a new package name Pname is added as an element. In S9, the class name currently being processed is added to the Pname line. The package / class correspondence table is completed by performing S6 to S9 for all classes. An example of the package / class correspondence table E4 created from the example of the class diagram shown in FIG. 21 is shown in FIG.

  FIG. 11 is a flowchart showing a detailed algorithm of the class / operation correspondence table creating apparatus E3 that creates the class / operation correspondence table E5 from the class diagram E2.

  In S9, a new class / operation correspondence table E5 is created. In S10 to S13, the class name being processed is added to the class name item of the class / operation correspondence table E5, and all the operation names of the class being processed are added to the operation name item. By performing these processes for all classes on the class diagram E2, the class / operation correspondence table E5 is completed. An example of the class / operation correspondence table E5 created from the example of the class diagram shown in FIG. 21 is shown in FIG.

  FIG. 12 is a flowchart showing a detailed algorithm of the package / relationship correspondence table creation device E7 that creates the package / event correspondence table E9.

  In S14, a new package / event correspondence table E9 is created. Thereafter, the loop is rotated for each scenario in the sequence diagram E1 for each scenario, and the following processing is performed for each scenario. In S15, an event is found for each time series (in order from the top) of the sequence diagram E1, and for the found event, the event name is stored in EVName, the class name of the transmission source is stored in SrcClass, and the class name of the transmission destination is stored in DstClass. In A16, the class name recorded in the variable DstClass in S15 is searched in the class name column of the package / class correspondence table, and the package name to which the found class belongs is stored in the variable Pname.

  In S17, the package name stored in Pname in S16 is searched in the package name column of the package / event correspondence table E6. As a result, if Pname exists, that line is activated. If Pname does not exist, in S18, Pname is newly added to the package name column of the package / event correspondence table, and the row is activated. In S19, EVName is newly added to the item of the event name in the currently active row in the package / event correspondence table E6, SrcClass is newly added to the item of the transmission source class, and DstClass is newly added to the item of the transmission destination class. The package / event correspondence table E9 is completed by performing the processing of S15 to S19 on the sequence diagram E1 for every scenario. FIG. 25 shows an example of the package / event correspondence table E9 created from the example of the class diagram shown in FIG. 21 and the example of the sequence diagram for each scenario shown in FIG.

  FIG. 13 is a flowchart showing a detailed algorithm of the package / relationship correspondence table creation device E7 that creates the package / relationship correspondence table E11.

  In S20, a new package / relationship correspondence table E11 is created. After S21, in the loop for each package recorded in the package / class correspondence table E4 (the name of the package being processed is stored in a variable called Pname), the loop for each class belonging to that package (the class name being processed) Stored in a variable called DstClass). Further, a loop is rotated for each association that the class of DstClass has on the class diagram E2. In S21, the name of the currently processed association is stored in ACName, and the name of the related partner class is stored in a variable called SrcClass. In S22, it is checked whether the relation being processed is bidirectional. In S23, the result of S22 is determined. If the result of S23 is bidirectional, Pname is searched in the column of the package to which the package / relationship correspondence table belongs in S24. In S25, the result of S24 is determined. If the result is not found, Pname is newly added to the column of the belonging package of the package / relationship correspondence table E11 in S26.

  In S27, a new line is added to the item Pname of the package / relationship correspondence table in the package / association table, ACName is set to the related source class item, SrcClass is set to the related destination class item, and DstClass is set to the bidirectional item. Fill in ○. S28 is performed when the determination result in S23 is No, and it is checked whether the related direction is the direction from SrcClass to DstClass. In S29, the result of S28 is determined. If No, the process exits from the related loop currently being processed. If the result of S29 is Yes, Pname is searched in the column of the package to which the package / relationship correspondence table E11 belongs in S30. In S31, the result of S30 is determined. If the result is not found, Pname is newly added to the column of the package to which the package / relationship correspondence table belongs in S32.

  In S33, a new line is added to the item Pname of the package / association table belonging to the package / association table, ACName is set to the related source class item, SrcClass is set to the related destination class item, and DstClass is set to the bidirectional item. Fill in x. The package / relationship correspondence table is completed by repeating the processing of S22 to S33 for all the relationships. It is created from the package / class correspondence table shown in FIG. FIG. 26 shows an example of a package / association correspondence table created from the example of the package / class correspondence table shown in FIG.

  FIG. 14 is a flowchart showing a detailed algorithm of the scenario / event correspondence table creating apparatus E8 for creating the scenario / event correspondence table E12.

  In S34, a scenario / event correspondence table E12 is newly created. S35 and subsequent steps are repeated as long as there is a sequence diagram E1 for each unprocessed scenario. In S35, a new scenario line is added to the scenario / event correspondence table e12, and the line is selected. S36 and subsequent steps are repeated as long as there is an unprocessed event in the sequence diagram E1 for each scenario. In S36, the first event (top) is searched in the sequence diagram E1 for each scenario, and the event name is EVName, the source class name is SrcClass, and the destination class is DstClass. Store.

  In S37, a new line is added to the scenario currently selected in the scenario / event correspondence table E12, EVName is entered in the event name item, SrcClass is entered in the transmission source class item, and DstClass is entered in the transmission destination class item. The scenario / event correspondence table E12 is completed by repeating S35 to S37. FIG. 27 shows an example of the scenario / event correspondence table created from the example of the sequence diagram for each scenario shown in FIG.

  FIG. 15 is a flowchart showing details of the Facade class application determination device E10 that determines whether a Facade pattern is applicable to a model input by a designer.

In S38, a new Facade pattern application determination result table E13 is created. After S39, the process is repeated as long as there is an unprocessed package in the package name column of the package / event correspondence table E9. The name of the package currently being processed is stored in a variable called Pname. In S39, the package name column of the package / event correspondence table E9 counts the number of events of the item Pname, and evCnt
Is stored in the variable. In S40, the Pname item is searched in the package name column of the package / relationship correspondence table E11, the corresponding number of associations is counted, and stored in a variable accCnt.

  In S41, it is determined whether evCnt is 2 or more and accCnt is 2 or more. S42 is a process that is performed when the determination result of S41 is Yes, Pname is added to the package name column of the Facade pattern application determination result table E13, and a circle is entered in the item of whether or not a Facade class can be created. S43 is a process performed when the determination result of S41 is No. Pname is added to the package name column of the Facade pattern application determination result table E13, and “x” is entered in the item of whether or not the Facade class can be created.

  FIG. 28 shows an example of a pattern application determination result table created from the example of the package / event correspondence table shown in FIG. 25 and the example of the package / relationship correspondence table shown in FIG.

  FIG. 16 is a flowchart showing a detailed algorithm of the Facade class creation device E14 that creates a Facade class for a package to which the Facade pattern can be applied.

  First, the package / class correspondence table E4 is opened, and the loop is rotated for the number of packages described in the package name column. At this time, the package name is stored in the loop variable Pname. In S44, the Fadeade pattern application determination result table E13 is opened, and the Pname item is searched from the package name column. Then, it is determined whether or not the applicable package is applicable to the Facade pattern from the circles in the column indicating whether or not the Facade class can be created.

  The determination is made in S45, and if it is determined that it is possible, the process proceeds to S46. If it is determined that the Facade class cannot be created, the process proceeds to the next package. In S46, the package / class correspondence table E15 after application of the Facade class is created by rewriting the package / class correspondence table E4. As the processing contents, a class having the same name as Pname is added to the class name column corresponding to Pname.

  In S47, the class / operation correspondence table E16 after creation of the Facade class is created by rewriting the class / operation correspondence table E5. The class name having the same name as Pname is added to the column of the processing contents and class name. Example of package / class correspondence table shown in FIG. 23, example of class / operation correspondence table shown in FIG. 24, and example of package / class correspondence table after application of Fade class created from example of Fade pattern determination result shown in FIG. FIG. 29 shows an example of a class / operation correspondence table after applying the Facade class.

  FIG. 17 is a flowchart showing a detailed algorithm of the device E22 for associating the scenario / event correspondence table E12 with the Fade pattern.

  First, the scenario / event correspondence table E12 is opened, and a loop is performed with the events described in the event name column. At this time, evName is prepared as a loop variable, and the event name is stored. In S48, the source class name of the event that is currently looping in the scenario / event correspondence table E12 is stored in a variable called SrcClass, and the destination class name is stored in a variable called DstClass.

  In S49, the package / class correspondence table E15 is opened, SrcClass is searched in the class name column, and the package corresponding to SrcClass is stored in a variable SrcP. Similarly, DstClass is searched and the result is stored in a variable called DstP. In S50, it is determined whether SrcP and DstP are the same. S51 is a process executed when the determination result of S50 is No. In S51, DstP is searched for in the package name column of the Facade pattern determination result table E13, and it is checked whether or not DstP is applicable to the Facade pattern from Ox. In S53, the determination is made. S54 is a process executed when the determination result of S53 is Yes. In S54, a new row is added below the currently processed event row in the scenario / event correspondence table E12, and evName is copied to the event name column of that row and DstClass is copied to the destination class.

  In S55, the class name having the same name as DstP is added to the contents of the destination class name column in the currently processed row of the scenario / event correspondence table E12 and the source class name column in the line added in S54. To do. In S56, after applying the Facade class, the class / operation correspondence table E16 is opened, DstClass is searched in the class name column, and evName is added to the found item.

  The post-Facade class scenario / event correspondence table E21 is created by the algorithm as described above. Application of Fade class created from example of scenario / event correspondence table shown in FIG. 27, example of package / class correspondence table after application of Fade class shown in FIG. 29, and example of class / operation correspondence table after application of Fade class shown in FIG. An example of the post scenario / event correspondence table is shown in FIG.

  FIG. 18 is a flowchart showing a detailed algorithm of the device E18 for associating the package / relationship correspondence table E11 with a Facade pattern.

  First, the package / relationship correspondence table E11 is opened, and the loop is rotated for the number of packages described in the package name column. At this time, Pname is prepared as a loop variable, and the name of the package being processed is stored. In S57, the Facade pattern application determination result table E13 is opened, Pname is searched in the package name column, and it is determined from O × whether Pname is a Facade pattern application.

  This determination is made in S58. If it is determined Yes in S58, the package association correspondence table E11 is opened, and the loop is rotated by the number of association names described in the association name column. At this time, the loop variable ACName is prepared and the related name being processed is stored. In S59, a new line is added below the line of the relation name currently being processed in the package relation table E11, and the relation destination class name of the line currently being processed is copied to the column of the relation destination class of that line. In S60, a Facade class (a class having the same name as Pname) is added to the column of the association destination class name of the row currently being processed in the package association table E11 and the column of the association source class name of the row newly added in S59. .

  The post-facade class applied package / relationship correspondence table E17 is created by the algorithm as described above. FIG. 32 shows an example of the package / relationship correspondence table after application of the Facade class created from the example of the package / relationship correspondence table shown in FIG. 26 and the example of the package / class correspondence table after application of the Facade class shown in FIG.

  FIG. 19 is a flowchart showing a detailed algorithm of the device E19 that creates a class diagram to which the Facade pattern is applied.

  In S61, a new class diagram is created in the browse part D4. Subsequently, the package / class correspondence table E15 after the application of the Facade class is opened, and a loop is rotated for the number of packages described in the package name column. At this time, a loop variable Pname is prepared and the name of the package being processed is stored. In S62, a package called Pname is arranged on the class diagram newly created in S61. Subsequently, the loop is rotated by the number of classes described in the class name column corresponding to the package currently being processed in the package / class correspondence table E15 after application of the Facade class. At this time, Cname is prepared as a loop variable, and the class name being processed is stored.

In S63, Cname is included in the package arranged in S62.
Place a class named After exiting these loops, after applying the Facade class, the package / association correspondence table E17 is opened, and the loop is rotated by the number of packages described in the package name column. At this time, a loop variable Pname is prepared and the name of the package being processed is stored. Further, the loop is rotated for the number of relations described in the relation name column corresponding to the package being processed. At this time, a loop variable Aname is prepared and a related name being processed is stored.

  In S64, the association source class name is stored in a variable SrcClass, and the association destination class name is stored in a variable DstClass. In S65, a class named SrcClass and a class named DstClass are searched on the class diagram newly created in S61, a relationship is described in the direction of SrcClass → DstClass between the found classes, and the associated name is given as Aname. After exiting these loops, the class / operation correspondence table E16 after the application of the Facade class is opened, and the loop is rotated by the number of classes described in the class name column. At this time, the loop variable Cname is prepared and the class name being processed is stored.

  Further, the loop is rotated for the number of operations described in the operation column corresponding to the class being processed. At this time, a loop variable called Oname is prepared and the name of the operation being processed is stored. In S66, a class called Cname is searched on the class diagram newly created in S61, and Oname is added to the operation of the found class. When these loops are exited, the processing of S67 is executed. In S67, the corresponding class is searched from the class diagram before applying the Facade class, and the attribute of each class and the related line in the package are copied.

  A class diagram to which the Facade pattern is applied is created by the algorithm as described above.

  An example of a class diagram to which the Facade pattern is applied is shown in FIG.

  FIG. 20 is a flowchart showing a detailed algorithm of the device E20 that creates a sequence diagram to which the Fade pattern is applied.

  First, the post-facade pattern applied scenario / event correspondence table E21 is opened, and the loop is rotated for the number of scenarios described in the scenario name column. In S68, a new sequence diagram is created in the browse part D4. Subsequently, the loop is rotated for the number of events described in the event name column corresponding to the scenario currently being processed. At this time, the loop variable evNmae is prepared and the name of the event being processed is stored.

  In S69, the transmission source class of the event currently being processed is stored in a variable called SrcClass, and the transmission destination class is stored in a variable called DstClass. In S70, it is determined whether an instance icon of SrcClass is described on the sequence diagram newly created in S68. S71 is a process when the determination result of S70 is No. In S71, an instance icon named SrcClass is arranged on the sequence diagram. Similarly, in S72 and S73, a search is performed for DstClass, and if not found, a class named DstClass is arranged on the sequence diagram. In S74, an event is transmitted from the instance named SrcClass toward the instance named DstClass, and named evNmae.

  A sequence diagram to which the Facade pattern is applied is created by the algorithm as described above. An example of a sequence diagram to which the Facade pattern is applied is shown in FIG.

FIG. It is a block diagram which shows the whole structure. It is a figure which shows the format of a package / class correspondence table. It is a figure which shows the format of a class / operation correspondence table. It is a figure which shows the format of a package / event corresponding table. It is a figure which shows the format of a class / relationship correspondence table. It is a figure which shows the format of a scenario / event corresponding table. It is a figure which shows the Facade pattern application determination result storage table. It is a flowchart showing the outline | summary of operation | movement. It is a flowchart of package / class correspondence table creation. It is a class / operation correspondence table creation flowchart. It is a flowchart of package / event correspondence table creation. It is a flowchart of package / relationship table creation. It is a flowchart of scenario / event correspondence table creation. It is a flowchart of Fadede pattern application determination. It is a flowchart of Facade class creation. It is a flowchart which makes a scenario / event correspondence table correspond to Fade. It is a flowchart which makes a package / association correspondence table correspond to Fade. It is a flowchart which displays the class diagram to which a Facade pattern is applied. It is a flowchart which displays the sequence diagram which applied the Facade pattern. It is a class diagram. It is a sequence diagram for every scenario. It is a figure which shows the example of a package / class correspondence table. It is a figure which shows the example of a class / operation correspondence table. It is a figure which shows the example of a package / event corresponding table. It is a figure which shows the example of a package / relationship correspondence table. It is a figure which shows the example of a scenario / event correspondence table. It is a figure which shows the example of a Facade pattern application determination result table. It is a figure which shows the example of the package / class correspondence table after Fadede class application. It is a figure which shows the example of a class / operation corresponding | compatible table after a Facade class application. It is a figure which shows the example of a scenario / event corresponding table after Fadede class application. It is a figure which shows the example of the package / relationship correspondence table after Fadede class application. It is a figure which shows the example of the class diagram to which the Facade pattern was applied. It is a figure which shows the example of the sequence diagram to which the Facade pattern was applied.

Explanation of symbols

D1 Device overview D2 Drawing area D3 Tool box D4 Browse section D5 Log display section

Claims (5)

  A means for inputting various software blueprints using a notation stipulated by UML, a means for supporting the description of blueprints, and a means for storing the input blueprints in a storage device. It is possible to extract the necessary information from the class diagram and sequence diagram input by the designer, and to apply the Facade pattern which is one of the software design patterns. A software design support apparatus comprising means for automatically making a determination.   2. The determination unit according to claim 1, wherein the determination unit is determined from information on a package to which each class belongs in a class diagram, class related information, class operation information, and event transmission information in a sequence diagram for each scenario. Software design support equipment.   2. The method according to claim 1, further comprising means for automatically creating a class diagram and a sequence diagram to which the Facade pattern is applied when it is determined by the determining means that the Facade pattern can be applied. Software design support device.   If the determination means determines that the application of the Facade pattern is possible, the class diagram to which the Facade pattern is applied only when the designer is notified and the designer determines to apply the Facade pattern; 2. The software design support apparatus according to claim 1, further comprising means for creating a sequence diagram.   A storage medium for operating the software design support apparatus according to any one of claims 1 to 4 on a computer.

Images