WO2017072969A1 - システム設計装置及び方法 - Google Patents

システム設計装置及び方法 Download PDF

Info

Publication number
WO2017072969A1
WO2017072969A1 PCT/JP2015/080818 JP2015080818W WO2017072969A1 WO 2017072969 A1 WO2017072969 A1 WO 2017072969A1 JP 2015080818 W JP2015080818 W JP 2015080818W WO 2017072969 A1 WO2017072969 A1 WO 2017072969A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
class
metamodel
system design
meta
Prior art date
Application number
PCT/JP2015/080818
Other languages
English (en)
French (fr)
Inventor
蘭 王
Original Assignee
株式会社 東芝
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社 東芝 filed Critical 株式会社 東芝
Priority to JP2017547331A priority Critical patent/JP6427687B2/ja
Priority to EP15907332.9A priority patent/EP3370147A4/en
Priority to PCT/JP2015/080818 priority patent/WO2017072969A1/ja
Publication of WO2017072969A1 publication Critical patent/WO2017072969A1/ja
Priority to US15/914,231 priority patent/US10732938B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven

Definitions

  • Embodiments described herein relate generally to a system design apparatus and method.
  • UML Unified Modeling Language
  • SysML System Modeling Language
  • UML is a general-purpose modeling language that can design software and automatically generate source code.
  • SysML is an extension of UML, and a requirement diagram (Requirement diagram) for defining a function request and a parametric diagram (Parametric diagram) for defining a dynamic model are added to UML.
  • a dynamic model for example, a model for simulation or optimal calculation
  • the current specifications of the metamodel that defines the grammar and specifications that describe UML and SysML models have the following four model description deficiencies.
  • Third, the requirement definition model definition has a problem that it is not possible to define a decomposition relationship between requirements, that is, a so-called “OR” disjunction relationship.
  • Fourth, the relationship class (Trace) has a problem that it is impossible to weight the relationship between each model element and the request. Note that the non-patent document 1 is referred to for the relation class (Trace) and the first, third, and fourth thereof, and the second is referred to the non-patent document 2.
  • a system design device includes a metamodel definition unit, a model construction unit, and a script file generation unit.
  • the meta model definition unit generates a second meta model based on the first meta model described in the modeling language.
  • the second metamodel includes the first metamodel, the constraint model metamodel describing the constraint condition, and the relation class (Trace) in order to distinguish the presence or absence of the constraint condition, And a metamodel that defines associations between relationship classes.
  • the model construction unit constructs a model according to the second meta model.
  • the script file generation unit generates a script file corresponding to the model.
  • Embodiments of the system design apparatus will be described with reference to FIGS. First, the concept of the model in this embodiment will be described.
  • FIG. 1 is a diagram showing a relationship between a meta model, a model, and data (instances).
  • the metamodel 201 is a high-level model that defines grammar and specifications for describing the model 202.
  • the meta model 201 is referred to as a model of a model.
  • the definition example 204 is an example of a class metamodel definition.
  • the definition example 204 indicates that a name is essential for a class, and an attribute (Property) and an operation (Operation) are defined.
  • the model 202 corresponds to a design drawing of a system such as software, and includes various diagrams (model elements) such as a request diagram and a block diagram.
  • the model 202 is constructed according to the definition of the metamodel 201.
  • the definition example 205 is an example of the definition of a class (model) defined according to the definition example 204.
  • the name of the class is “two-wheeled vehicle”, “color” and “maximum speed” are defined as attributes for this class, and “calculate distance to run ()” is defined as an operation. Show.
  • Data 203 is actual data defined according to the definition of the model 202.
  • the definition example 206 is an example of the definition of actual data of the motorcycle class defined according to the definition example 205.
  • the definition example 206 indicates that the name of the data is “Hanako's motorcycle”, the “color” is red, and the “maximum speed” is 50 km / h.
  • FIG. 2 is a diagram showing the relationship between classes, attributes, and attributes.
  • attributes are defined for classes. Classes and attributes have definition items such as names and data types. Hereinafter, individual definition items of classes and attributes are referred to as attributes, and a set of attributes is referred to as an attribute set. Classes and attributes are defined using their respective attribute sets.
  • the class 301 is defined using an attribute set 303 including attributes such as ID, Name, and description.
  • the entity 302 of the class 301 is defined by the attribute set 303.
  • the attributes of the class 301 are defined using an attribute set 305 including attributes such as ID, Name, and description.
  • the attribute entity 304 of the class 301 is defined by the attribute set 305.
  • version included in the attribute sets 303 and 304 in FIG. 2 is an attribute that can be newly defined by the system design apparatus according to the present embodiment. Details of version will be described later.
  • FIG. 3 is a diagram illustrating a functional configuration of the system design apparatus.
  • the system design device includes a metamodel definition unit 1, a model construction unit 2, a model description language generation unit 3, a script file generation unit 4, a dynamic model execution unit 5, and a change analysis.
  • Unit 6 model update unit 7, conversion rule generation unit 8, table construction unit 9, and DB (database) 10.
  • the metamodel definition unit 1 generates an extended metamodel (second metamodel) based on the input existing metamodel (first metamodel).
  • the existing metamodel is an existing metamodel that defines a description specification of a model described in UML or SysML.
  • An extended metamodel is a metamodel that is an extension definition of an existing metamodel.
  • the metamodel definition unit 1 generates an extended metamodel by extending and defining classes and attributes in the existing metamodel.
  • the model construction unit 2 constructs (defines) a model according to the extended metamodel generated by the metamodel definition unit 1.
  • the model constructed by the model construction unit 2 is referred to as an extended model.
  • the model construction unit 2 can edit the extended model.
  • the model description language generation unit 3 generates a model description language based on the extended metamodel generated by the metamodel definition unit 1.
  • the model description language defines a description format for describing an extended model defined according to the extended metamodel as an executable script language.
  • the script file generation unit 4 executes an executable script file (Script File) corresponding to the extension model based on the extension model constructed by the model construction unit 2 and the model description language created by the model description language generation unit 3. ) Is generated.
  • Script File executable script file
  • the dynamic model execution unit 5 executes the script file generated by the script file generation unit 4. Executing the script file corresponds to executing the extended model.
  • the change analysis unit 6 analyzes the change contents of the extended model edited by the model construction unit 2.
  • the model update unit 7 updates the extended model based on the analysis result of the change content by the change analysis unit 6.
  • the conversion rule generation unit 8 generates a conversion rule for storing the extended model constructed by the model construction unit 2 in the relational DB.
  • the table construction unit 9 constructs a table corresponding to the extended model according to the conversion rule generated by the conversion rule generation unit 8.
  • the DB 10 is a relational database that stores the table constructed by the table construction unit 9.
  • the system design apparatus according to the present embodiment is configured by a computer 100.
  • the computer 100 includes a server, a client, a microcomputer, a general-purpose computer, and the like.
  • FIG. 4 is a diagram illustrating an example of the computer 100. 4 includes a CPU (central processing unit) 101, an input device 102, a display device 103, a communication device 104, and a storage device 105.
  • the processor 101, the input device 102, the display device 103, the communication device 104, and the storage device 105 are connected to each other via a bus 106.
  • the processor 101 is an electronic circuit including a control device and a calculation device of the computer 100.
  • the processor 101 performs arithmetic processing based on data or a program input from each device (for example, the input device 102, the communication device 104, and the storage device 105) connected via the bus 106, and outputs a calculation result and a control signal. And output to each device (for example, the display device 103, the communication device 104, and the storage device 105) connected via the bus 106.
  • the processor 101 executes an OS (operating system) of the computer 100, a system design program, and the like, and controls each device constituting the computer 100.
  • OS operating system
  • the system design program is a program that causes the computer 100 to realize the above-described functional configurations of the system design apparatus.
  • the system design program is stored in a non-transitory tangible computer readable storage medium.
  • the storage medium is, for example, an optical disk, a magneto-optical disk, a magnetic disk, a magnetic tape, a flash memory, or a semiconductor memory, but is not limited thereto.
  • the processor 101 executes the system design program, the computer 100 functions as a system design apparatus.
  • the input device 102 is a device for inputting information to the computer 100.
  • the input device 102 is, for example, a keyboard, a mouse, and a touch panel, but is not limited thereto.
  • the user can input information such as an existing metamodel by using the input device 102.
  • the display device 103 is a device for displaying images and videos.
  • the display device 103 is, for example, an LCD (liquid crystal display), a CRT (CRT), and a PDP (plasma display), but is not limited thereto.
  • the display device 103 includes data input to the system design device (existing metamodel, etc.), data generated by the system design device (extended metamodel, extended model, model description language, script file, etc.), and the user's system A GUI (Graphical User Interface) for operating the design apparatus is displayed.
  • system design device existing metamodel, etc.
  • data generated by the system design device extended metamodel, extended model, model description language, script file, etc.
  • GUI Graphic User Interface
  • the communication device 104 is a device for the computer 100 to communicate with an external device wirelessly or by wire.
  • the communication device 104 is, for example, a modem, a hub, and a router, but is not limited thereto.
  • the storage device 105 is a storage medium that stores the OS of the computer 100, a system design program, data necessary for executing the system design program, data generated by executing the system design program, and the like.
  • the storage device 105 includes a main storage device and an external storage device.
  • the main storage device is, for example, a RAM, a DRAM, or an SRAM, but is not limited thereto.
  • the external storage device is, for example, a hard disk, an optical disk, a flash memory, and a magnetic tape, but is not limited thereto.
  • the DB 10 may be built on the storage device 105 or may be built on an external server.
  • the computer 100 may include one or more processors 101, input devices 102, display devices 103, communication devices 104, and storage devices 105, and is connected to peripheral devices such as printers and scanners. Also good.
  • system design apparatus may be configured by a single computer 100 or may be configured as a system including a plurality of computers 100 connected to each other.
  • system design program may be stored in advance in the storage device 105 of the computer 100, may be stored in a storage medium external to the computer 100, or may be uploaded on the Internet.
  • the function of the system design apparatus is realized by installing and executing the system design program in the computer 100.
  • Methods for extending an existing metamodel (method for generating an extended metamodel) by the metamodel definition unit 1 will be described.
  • each of the four expansion methods will be described.
  • a meta model is provided with a meta model of a relation class (Trace) that defines a relationship between a request diagram and another diagram (a block diagram or a parametric diagram).
  • Trace relation class
  • FIG. 5 is a diagram illustrating an example of a meta model of a relation class.
  • a relation class (Trace) 401 and DerivedReqt, Copy, Verify, and Satisfy are provided as existing metamodels and subordinate classes thereof. Satisfy (hereinafter referred to as “satisfying relationship”) indicates a relationship between a request and a model element that satisfies the request.
  • the metamodel definition unit 1 defines (adds) a metamodel of the constraint condition class (Condition) as shown in 402 of FIG. Therefore, the meta model of the relationship between the constraint condition class and the relation class is extended and defined.
  • the constraint condition class (Condition) is a class for describing a constraint condition for a request.
  • the attribute set (Condition_attribute) of the constraint condition class 402 includes a constraint condition variability (constantCondition), a name (Name), and a constraint condition type (Type).
  • Constraint variability is of the boolean type, and is defined as, for example, True when it does not change on the time axis (that is, when it does not change over time), and False otherwise.
  • ConditionType (choice type), and includes pre_cal_condition, pre_env_condition, trigger, post_cal_condition, post_env_condition, and functional_type as choices.
  • the metamodel definition unit 1 extends and defines the metamodel of the constraint condition class so that the existing metamodel, the metamodel of the constraint class describing the constraint condition, the request and the request are satisfied, etc.
  • An extension that includes a meta model that defines the relationship between the constraint class and the relationship class to distinguish the presence or absence of the constraint condition for the relationship class (Trace) that defines the relationship between the model elements A metamodel is generated. Note that the attribute and attribute of the constraint condition class are not limited to the example of FIG. 5 and can be arbitrarily designed.
  • FIG. 6 is a diagram illustrating an example of an extension model constructed according to the extension metamodel generated by the first extension method.
  • a satisfying relationship (satisfyWithCondition) 502 with a constraint condition is defined between the request diagram 501 and the block diagram 503.
  • the relation 502 to be satisfied with the constraint condition refers to the constraint condition class 504 (Condition 1).
  • the constraint condition class 504 (Condition 1), the name of each attribute, the description of the attribute, and the constraint condition are described.
  • the constraint condition class 504 refers to a parametric diagram 505 for performing calculation.
  • Parametric diagram 505 defines input (l, t, v), output (a), and calculation formula.
  • the calculation formula is described by, for example, MathML (Mathematical Markup Language).
  • the model building unit 2 can satisfy the relationship that satisfies no constraints (satisfy) and the relationship that satisfies the constraints (satisfyWithCondition).
  • Each defined extension model can be built. As a result, it is possible to distinguish whether there is a constraint condition for each request or to define the contents of the constraint condition.
  • the metamodel extension unit 1 extends (adds) the version information of the metamodel to the attribute of the metamodel of the highest class of the existing metamodel. As a result, an extended metamodel in which version information is included in the attributes of the metamodel of the highest class is generated.
  • FIG. 7 is a diagram illustrating an example of an extended metamodel generated by the second extension method.
  • the highest class is Classifier, and Datatype, Class, Association, and the like are defined in the existing metamodel as lower classes.
  • version information version is extended and defined in Classifier as an attribute.
  • FIG. 8 is a diagram illustrating an example of an extended model constructed according to the extended metamodel generated by the second extension method.
  • version information is described in each of the model elements 501 to 505 of the extended model. This is because the version information additionally defined in the top class is inherited.
  • version information can be defined for each element defined in 501 to 505, for example, “airPressure” of an attribute defined in 504. A description example is shown in line 10 of FIG.
  • the model construction unit 2 can construct an extension model in which each model element has version information.
  • the extension model can be updated and managed efficiently.
  • the metamodel definition unit 1 extends (adds) a metamodel of a decomposition relation class (Decompose).
  • the decomposition relation class is a class that defines a decomposition relation (logical sum) of requirements, and is added as a lower class of the relation class as shown in FIG.
  • an extended metamodel including the existing metamodel and the metamodel of the decomposition related class is generated.
  • FIG. 9 is a diagram illustrating an example of an extended model constructed according to the extended metamodel generated by the third extension method.
  • the request 4201 (Re1) is broken down into a request 4202 (Re2) and a request 4203 (Re3). This indicates that the request 4201 is satisfied by satisfying the request 4202 or the request 4203.
  • the model construction unit 2 can construct an extended model in which a decomposition relationship of requirements is defined.
  • the metamodel definition unit 1 extends (adds) a metamodel of a contribution class (Contribution) as shown in FIG.
  • the contribution class is a class that defines the contribution of each relationship such as DerivedReqt, Copy, Verify, Satisfy, satisfactionWithCondition, and Decompose, and is associated with the relationship class as shown in FIG.
  • weight is defined as an attribute. The weight is, for example, the change cost of each relationship, but is not limited thereto.
  • FIG. 10 is a diagram illustrating an example of an extended model constructed according to the extended metamodel generated by the fourth extension method.
  • x is the weight of the decomposition relationship 4204
  • y is the weight of the decomposition relationship 4205.
  • m is the weight of the relationship 4207 that is satisfied between the functional block 4206 (Block 2) and the request 4203 (Re3)
  • n is between the functional block 4208 (Block 3) and the request 4203 (Re3).
  • Each weight can be set arbitrarily. For example, the weight may be selectable from an integer of 1 to 10.
  • the model construction unit 2 can construct an extended model in which the weight of each relationship is defined. If the change cost of each relationship is defined as a weight, the change cost of the model can be easily calculated, and the change management efficiency can be improved.
  • metamodel definition unit 1 may use the first to fourth extension methods described above individually or in combination of two or more.
  • the metamodel definition unit 1 and the model construction unit 2 may display an existing metamodel, an extended metamodel, an extended model, and the like on the display device 103. Further, the model construction unit 2 may construct a model according to the existing meta model and display the constructed model on the display device 103.
  • FIG. 11 is a diagram illustrating an example of MTL4Sys. Hereinafter, each row of MTL4Sys in FIG. 11 will be described.
  • the first line defines that each request diagram is described as a request type class.
  • the second line defines that each block diagram is described as a block class.
  • the third line defines that the relationship between the request class and the block class is described as a satisfying relationship (satisfy) or a conditional satisfying relationship (satisfyWithConstraint).
  • the conditional relation is defined together with the ID of the constraint condition class to be referred to, for example, Condition1.
  • the fourth line defines that the constraint condition is described as a constraint condition class.
  • the fifth line defines that the attribute (definition item) of the constraint condition is described as the attribute (property) of the constraint condition class.
  • the 6th line defines that the constantType attribute of the constraint condition is described as the constantType attribute of the constraint condition class.
  • the seventh line defines that the Type attribute of the constraint condition is described as the attribute of the conditionType of the constraint condition class.
  • the eighth line defines that a parametric diagram describing an operation or the like is described as a function class.
  • Line 9 defines that the operation input is described as a function class parameter.
  • the 10th line defines that the operation output is described as the function class output.
  • the eleventh line defines that the operation pre-calculation formula (formula.preCal) is a function class pre-calculation formula using parameters and pre-calculation conditions (pre_cal_condition), and the pre-calculation result is described as pre_result.
  • the 12th line defines that the calculation formula (formula) of the operation is a calculation formula of a function class that uses a parameter and a pre-calculation result (pre_result), and that the calculation result is described as a result.
  • the 13th line defines that the post-calculation formula of the operation is a post-calculation formula of a function class using parameters and pre-calculation conditions, and the post-calculation result is described as after_result.
  • the 14th line defines that the version information (version) given to all model elements of UML is described as the version information of the corresponding model element.
  • the model description language generation unit 3 can automatically generate such MTL4Sys based on the extended metamodel.
  • model description language generation unit 3 may cause the display device 103 to display the MTL4Sys thus generated.
  • FIG. 12 is a diagram illustrating an example of a script file generated by the script file generation unit 4.
  • the script file in FIG. 12 corresponds to the extended model in FIG.
  • each line of the script file of FIG. 12 will be described.
  • Line 1 describes the description specification (MTL4Sys) of this script file and its version information (version).
  • the second to fourth lines describe the request diagram 501.
  • the fifth to eighth lines describe the block diagram 503.
  • Lines 9 to 29 describe the constraint condition class 504 and the parametric diagram 505. Specifically, it is as follows.
  • Line 9 defines the constraint condition class.
  • Lines 10 to 14 define the airPressure attribute of constraint class 504. More specifically, the eleventh line describes the value of constantType of the airPressure attribute, the twelfth line describes the value of conditionType, and the thirteenth line describes the constraint value and unit.
  • Lines 15 to 20 define the attribute 1 of the constraint condition class 504. More specifically, the fifteenth line defines the name (name), name language (lang), and id of the attribute l.
  • the 16th line describes the value of attribute description of attribute l.
  • the 17th line describes the value (false) of the attribute constantType.
  • the 18th line describes the value (pre_cal_condition) of the attribute conditionType.
  • the 19th line describes the constraint condition (> 1000) and its unit (m).
  • Lines 21 and 22 show outlines describing the attributes t and v of the constraint condition class 504, respectively.
  • the description specifications of the attributes t and v are the same as the description specifications of the attribute l shown in the 15th to 20th lines.
  • Lines 23 to 28 describe the parametric diagram 505. More specifically, line 23 defines the parametric diagram 505 class, and line 24 describes the parametric diagram 505 input parameters. In line 24, the ID of an attribute that defines each parameter is used.
  • the 25th line describes the output of the parametric diagram 505.
  • Lines 26 and 27 describe examples of formulas that define mathematical expressions.
  • the formula formula1 is directly described using MathML, and in the 27th line, the ID of a separately defined formula (Math1) is referred to.
  • Math1 the mathematical expression Math1 to be referenced is defined in the 30th line.
  • the formula that defines the mathematical expression is described using either the 26th or 27th specification.
  • the script file generation unit 4 can automatically generate the script file as described above based on the MTL4Sys and the extended model.
  • the script file generated by the script file generation unit 4 is executed by the dynamic model execution unit 5.
  • the dynamic model execution unit 5 may display the execution process and execution result of the script file on the display device 103.
  • the version information of each model element may be omitted.
  • the version information of MTLSys in the first line can be used as default version information.
  • the script file generation unit 4 may cause the display device 103 to display the script file generated in this way.
  • the script file is described using the XML (eXtensible Markup Language) format, but using another model description language (description format) such as RDF (Resource Description Framework). May be described.
  • FIG. 13 is a diagram illustrating an example of a GUI operation screen on which the user can select a model description language.
  • the operation screen of FIG. 13 is displayed on the display device 103.
  • the user executes various GUI operations using the input device 102.
  • a method for generating a script file using the operation screen of FIG. 13 will be described.
  • model description language to be used from among selectable description formats (model description languages).
  • a list of selectable model description languages is displayed as a pull-down list 1202.
  • MTL4Sys and XMI (XML Metadata Interchange) describing SysML are displayed as selectable model description languages.
  • XMI XML Metadata Interchange
  • the script file generation unit 4 When the user clicks the execute button 1203, the script file generation unit 4 generates a script file as shown in FIG. 12 according to the model description language selected by the user.
  • the generated script file is stored in the storage device 105.
  • default values may be set for selectable extension models and model description languages.
  • FIG. 14 is a flowchart illustrating an example of a change analysis process performed by the change analysis unit 6.
  • the change analysis unit 6 first creates a change content set ⁇ M ⁇ (step S801).
  • the change content set ⁇ M ⁇ is a set including all changed content (classes, attributes, relationships between classes, etc.).
  • the change analysis unit 6 determines whether the class or relationship defining satisfyG is included in the change content set ⁇ M ⁇ (step S802).
  • satisfyG is satisfy (satisfying relationship) or satisfyWithCondition (conditional satisfying relationship).
  • step S802 If the class or relationship defining satisfyG is not included in the change content set ⁇ M ⁇ (no in step S802), the change analysis unit 6 ends the analysis process. On the other hand, when the class or relationship defining satisfyG is included in the change content set ⁇ M ⁇ (Yes in step S802), the analysis process proceeds to step S803.
  • the satisfyG set ⁇ is a set including the extracted class ID (cls_i).
  • the change analysis unit 6 selects one class cls_i from the satisfyG set ⁇ (step S804).
  • the change analysis unit 6 determines whether the selected class cls_i includes the class cls_i ′ (step S805).
  • the class cls_i ′ here is a class that is not included in the satisfyG set ⁇ among the classes in which the relationship of satisfyG is defined for the class cls_i.
  • step S807 If there is no class cls_i ′ (No in step S805), the analysis process proceeds to step S807.
  • step S805 when there is a class cls_i ′ (yes in step S805), the change analysis unit 6 adds the class cls_i ′ to the change candidate class set ⁇ cls_tbm ⁇ (step S806). Thereafter, the analysis process proceeds to step S807.
  • step S807 the change analysis unit 6 determines whether the processes in steps S805 and S806 have been completed for all classes cls_i included in the satisfyG set ⁇ . If there is an unprocessed class cls_i (no in step S807), the analysis process returns to step S804, and the change analysis unit 6 selects a class cls_i to be processed next. On the other hand, when the process is completed for all classes cls_i (Yes in step S807), the analysis process proceeds to step S808.
  • step S808 the change analysis unit 6 determines whether there is a class in which the relationship of satisfactionWithCondition is defined in the change candidate class set ⁇ cls_tbm ⁇ . If there is no class in which the satisfyWithCondition relationship is defined (No in step S808), the change analysis unit 6 ends the analysis process. On the other hand, when there is a class in which the relationship of satisfiedWithCondition is defined (yes in step S808), the analysis process proceeds to step S809.
  • step S809 the change analysis unit 6 extracts a class in which the relationship of satisfiedWithCondition is defined from the change candidate class set ⁇ cls_tbm ⁇ , and creates a constraint condition set ⁇ Condition_cls ⁇ .
  • the constraint condition set ⁇ Condition_cls ⁇ is a set of constraint class that defines satisfactionWithCondition of each extracted class.
  • the change analysis unit 6 extracts classes included in the constraint set ⁇ Condition_cls ⁇ and not included in the change content set ⁇ M ⁇ , and adds the extracted classes to the change candidate class set ⁇ cls_tbm ⁇ ( Step S811), the analysis process is terminated.
  • the change analysis unit 6 outputs a change candidate class set ⁇ cls_tbm ⁇ as an analysis result.
  • the change candidate class set ⁇ cls_tbm ⁇ includes a general class such as a relation class, which is affected by the change of the extended model, and a constraint condition class.
  • the change analysis unit 6 can automatically extract these classes as change targets.
  • Model update unit 7 updates (changes) the change target extracted by the change analysis unit 6 among the extended models edited by the model construction unit 2.
  • the model update unit 7 may update all the change targets, or may update only the change target selected by the user.
  • FIG. 15 is a diagram illustrating an example of a GUI operation screen on which the user can select an update target.
  • the operation screen of FIG. 15 is displayed on the display device 103.
  • the user executes various GUI operations using the input device 102.
  • an extension model update method using the operation screen of FIG. 15 will be described.
  • the user first selects a class to be updated from the change candidate class set ⁇ cls_tbm ⁇ displayed on the operation screen.
  • general class candidates 901 and constraint condition class candidates 902 are displayed as lists.
  • Class candidates 901 include, for example, class1, class3, and class6.
  • the constraint condition class candidate 902 includes, for example, Condition_class1, Condition_class3, and Condition_classX.
  • class1, Condition_class1 associated with class1, and Condition_classX selected by the user are selected.
  • the general class and the constraint class may be selected by the user, respectively, and the constraint class (or general class) associated with the general class (or the constraint class) selected by the user is the model update unit 7. May be selected automatically.
  • the update target (class1, Condition_class1, Condition_classX) selected by the user is displayed on the right side of the operation screen in FIG.
  • the model update unit 7 changes the selected update target according to the editing content of the extended model. In the example of FIG. 15, class1 and Condition_class1 are selected and changed.
  • the model update unit 7 adds the content to be updated to the edited extended model. Thereby, the extended model is updated. At this time, it is preferable that the model update unit 7 automatically updates the version information of the updated class. For example, when the version before the change is N, it can be considered that the version of the class after the change is N + 1. Further, the model update unit 7 may update the version information of the lower class of the changed class. For example, all the versions of the lower class of the changed class may be set to 1.
  • the conversion rule generation unit 8 generates a conversion rule for storing a request diagram, a block diagram, a constraint condition class, and a parametric diagram included in the extended model in a relational database based on the extended meta model.
  • 16 and 17 are diagrams illustrating an example of the specification of the conversion rule generated by the conversion rule generation unit 8.
  • the request table (re_tbl) 1001 stores a request diagram (RE) described according to the extended metamodel.
  • the request table 1001 has columns of ID, name, description, superRequirement, and version.
  • the ID of the request diagram is stored in the ID column.
  • the name column stores the name of the request diagram.
  • the description column stores a description of the request diagram.
  • the superRequirement column a parent requirement whose requirement diagram has an inheritance relationship is stored.
  • the version column stores version information of the request diagram.
  • the parametric table (parametric_tbl) 1002 stores a parametric diagram (Parametric) described according to the extended metamodel.
  • the parametric table 1002 has columns of ID (PK), name, description, Input, Output, formula, and version.
  • the column of IDP (PK) stores the ID of the parametric diagram.
  • the ID column can be set as a prime key.
  • the name column stores the name of the parametric diagram.
  • the description column stores the description of the parametric diagram.
  • the Input column stores information related to parametric diagram input.
  • a variable name (val1), a variable type (datatype), and a unit (unit) are stored as information related to input.
  • Information about the output of the parametric diagram is stored in the Output column.
  • FIG. 1 the example of FIG.
  • variable name (val2), the variable type (datatype), and the unit (unit) are stored as information related to output.
  • the formula column stores the parametric diagram formula.
  • the calculation formula is stored in the MathML format.
  • the version column stores version information of the parametric diagram.
  • the block table (block_tbl) 1003 stores a block diagram (block) described according to the extended metamodel.
  • the block table 1003 has columns of ID (PK), name, Condition (id, FK), Operation (id, FK), attribute, description, super, and version.
  • the ID column stores the ID of the block diagram.
  • the ID column can be set as a prime key.
  • the name column stores the name of the block diagram.
  • an ID of a constraint condition table 1004 described later is stored.
  • the column of Operation stores the ID of the parametric table 1002.
  • the attribute column stores a list of IDs of an attribute table 1005 described later.
  • the description column stores a description of the block diagram.
  • the super column stores the ID of a parent block (super) whose block diagram has an inheritance relationship.
  • the version column stores version information of the block diagram.
  • Constraint condition table (Condition_tbl) 1004 stores constraint conditions (Condition) described according to the extended metamodel.
  • the constraint condition table 1004 has columns of ID (PK), name, description, Attribute, Formula (id, FK), super, and version.
  • the ID column stores the constraint ID.
  • the ID column can be set as a prime key.
  • the name column stores the name of the constraint condition.
  • the description column stores a description of the constraint condition.
  • the Attribute column stores an ID list (List_of_id) of the attribute table 1005.
  • the ID of the parametric table 1002 is stored.
  • the super column stores the ID of a parent block (super) whose block diagram has an inheritance relationship.
  • the version column stores version information of the block diagram.
  • Attribute table (attribute_tbl) 1005 stores constraints described according to the extended metamodel and attributes described in the block diagram.
  • the attribute table 1005 has columns of ID (PK), name, description, constantType, ConditionType, and version.
  • the ID column stores the attribute ID.
  • the ID column can be set as a prime key.
  • the name column stores the name of the attribute.
  • the description column stores a description of the attribute.
  • the constantType column stores the variability of constraint conditions.
  • the ConditionType column stores the type of constraint condition.
  • the version column stores attribute version information.
  • Table construction unit 9 The table construction unit 9 automatically constructs various tables corresponding to the extended model in accordance with the conversion rules having the specifications as described above, and stores the constructed tables in the DB 10.
  • FIG. 18 is a diagram illustrating an example of a table corresponding to the model element constructed by the table construction unit 9. The table in FIG. 18 corresponds to the extended model in FIG.
  • the definition of the block 503 is stored in the first row of the block table 1101.
  • the definition of the constraint condition class 504 is stored in the first row of the constraint condition table 1102.
  • Definitions of airPressure and l that are attributes of the constraint condition class 504 are stored in the first and second lines of the attribute table 1103, respectively.
  • the definition of the parametric diagram 505 is stored in the first line of the parametric table 1104.
  • the ID (attr1, Attr2) of the attribute table 1103 is stored in the attribute column of the constraint condition table 1102.
  • the ID (Para_001) of the parametric table 1104 is stored.
  • the table constructed by the table construction unit 9 is stored in the DB 10.
  • the DB 10 may store a plurality of extended models as a table.
  • FIG. 19 is a diagram illustrating an example of a GUI operation screen on which a user can construct a table.
  • the operation screen of FIG. 19 is displayed on the display device 103.
  • the user executes various GUI operations using the input device 102.
  • a table construction method using the operation screen of FIG. 19 will be described.
  • a metamodel display unit 1302 is provided on the operation screen.
  • an extended meta model for example, an extended meta model in a block diagram
  • the extended metamodel displayed on the metamodel display unit 1302 may be editable by a user operation.
  • the user inputs the name of the table to be constructed in the table name input field 1303.
  • the name of the table is specified as block_tbl.
  • an SQL statement (Structured
  • the conversion rule generation unit 8 generates a conversion rule according to the content specified by the user.
  • the generated conversion rule may be displayed in the conversion rule column 1304.
  • the conversion rule displayed in the conversion rule column 1304 may be editable by a user operation.
  • the table construction unit 9 constructs a table corresponding to the model element selected by the user according to the conversion rule displayed in the conversion rule column 1304.
  • the table constructed in this way is stored in the DB 10.
  • the system design apparatus distinguishes the presence / absence of the constraint condition from the existing meta model and the constraint class meta model describing the constraint condition and the relation class.
  • Extended definition of metamodel that defines association between the constraint class and the relation class, version information metamodel, decomposition relation class metamodel, contribution class metamodel, etc. can do.
  • the description capability by modeling languages, such as UML and SysML can be improved.
  • the above-mentioned extended definition facilitates model update management and integrated design, so the system can be developed efficiently, and development and maintenance costs can be reduced.
  • the present invention is not limited to the above-described embodiments as they are, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage.
  • various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above embodiments. Further, for example, a configuration in which some components are deleted from all the components shown in each embodiment is also conceivable. Furthermore, you may combine suitably the component described in different embodiment.

Abstract

【課題】　メタモデルを拡張定義することにより、モデリング言語による記述能力を高めることができるシステム設計装置及び方法を提供する。 【解決手段】　一実施形態に係るシステム設計装置は、メタモデル定義部と、モデル構築部と、スクリプトファイル生成部と、を備える。メタモデル定義部は、モデリング言語により記述された第１のメタモデルに基づいて、第２のメタモデルを生成する。第２のメタモデルは、第１のメタモデルと、制約条件を記述する制約条件クラスのメタモデルと、関係クラス（Trace）に対して、制約条件の有無を区別するため、制約条件クラスと関係クラスとの間の関連（Association）を定義するメタモデルと、を含む。モデル構築部は、第２のメタモデルに従ってモデルを構築する。スクリプトファイル生成部は、モデルに対応するスクリプトファイルを生成する。

Description

システム設計装置及び方法
　本発明の実施形態は、システム設計装置及び方法に関する。
　近年、システムの設計のために、ＵＭＬ（Unified Modeling Language）やＳｙｓＭＬ（System Modeling Language）などのモデリング言語が利用されている。ＵＭＬは、汎用モデリング言語であり、ソフトウェアの設計や、ソースコードの自動生成が可能である。ＳｙｓＭＬは、ＵＭＬを拡張したものであり、ＵＭＬに対して、機能要求を定義する要求図（Requirement diagram）や、動的モデルを定義するパラメトリック図（Parametric diagram）が追加されている。ＳｙｓＭＬを利用することにより、動的モデル（例えば、シミュレーションや最適計算のためのモデル）を設計することができる。
　しかしながら、ＵＭＬやＳｙｓＭＬのモデルを記述する文法や仕様を定義するメタモデルの現状仕様は、下記の４つのモデル記述不足点を挙げられる。その１、要求モデルとその要求を満たす（Satisfy）等のモデル要素間の関係を定義する関係クラス（Trace）には、制約条件のあり・なしを区別して定義することはできない問題がある。その２、全てのモデル要素にバージョン情報を付与できない問題がある。その３、要求定義モデル定義には、要求間の分解関係、所謂、“ＯＲ”の論理和（Disjunction）関係を定義できない問題がある。その４、前記関係クラス（Trace）には、それぞれのモデル要素と要求間の関係の重み付けをできない問題がある。なお、関係クラス（Trace）及びその１、その３、その４については非特許文献１を参照し、その２は非特許文献２を参照する。
特開２０１０－９２２２８号公報
OMG Systems Modeling Language Version1.3 ISO/IEC 19505-2：UML Superstructure version2.4
　モデリング言語のメタモデルを拡張定義することにより、モデリング言語による記述能力を高めることができるシステム設計装置及び方法を提供する。
　一実施形態に係るシステム設計装置は、メタモデル定義部と、モデル構築部と、スクリプトファイル生成部と、を備える。メタモデル定義部は、モデリング言語により記述された第１のメタモデルに基づいて、第２のメタモデルを生成する。第２のメタモデルは、第１のメタモデルと、制約条件を記述する制約条件クラスのメタモデルと、関係クラス（Trace）に対して、制約条件の有無を区別するため、前記制約条件クラスと関係クラス間の関連（Association）を定義するメタモデルと、を含む。モデル構築部は、第２のメタモデルに従ってモデルを構築する。スクリプトファイル生成部は、モデルに対応するスクリプトファイルを生成する。
メタモデル、モデル、及びデータ（インスタンス）の関係を示す図。 クラス、属性、アトリビュートの関係を示す図。 システム設計装置の機能構成を示す図。 システム設計装置を構成するコンピュータの一例を示す図。 関係クラスのメタモデルの一例を示す図。 第１の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図。 第２の拡張方法により生成された拡張メタモデルの一例を示す図。 第２の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図。 第３の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図。 第４の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図。 モデル記述言語の一例を示す図。 スクリプトファイルの一例を示す図。 ユーザがモデル記述言語を選択可能なＧＵＩの操作画面の一例を示す図。 変更内容の分析処理の一例を示すフローチャート。 ユーザが更新対象を選択可能なＧＵＩの操作画面の一例を示す図。 変換ルールの仕様の一例を示す図。 変換ルールの仕様の一例を示す図。 モデル要素に対応するテーブルの一例を示す図。 ユーザがテーブルを構築可能なＧＵＩの操作画面の一例を示す図。
　以下、本発明の実施形態について図面を参照して説明する。
　システム設計装置の実施形態について、図１～図１９を参照して説明する。まず、本実施形態におけるモデルの概念について説明する。
　図１は、メタモデル、モデル、及びデータ（インスタンス）の関係を示す図である。
　メタモデル２０１は、モデル２０２を記述するための文法や仕様を定める上位モデルである。メタモデル２０１は、モデルのモデルと称される。定義例２０４は、クラスのメタモデルの定義の一例である。定義例２０４は、クラスには、名称が必須であり、属性（Property）及び操作（Operation）が定義されることを示している。
　モデル２０２は、ソフトウェアなどのシステムの設計図に相当するものであり、要求図やブロック図などの各種の図（モデル要素）により構成される。モデル２０２は、メタモデル２０１の定義に従って構築される。定義例２０５は、定義例２０４に従って定義されたクラス（モデル）の定義の一例である。定義例２０５は、クラスの名称が「二輪車」であり、このクラスには属性として「色」及び「最高速度」が定義され、操作として「走る距離を計算（）」が定義されていることを示している。
　データ２０３は、モデル２０２の定義に従って定義された実際のデータである。定義例２０６は、定義例２０５に従って定義された二輪車クラスの実際のデータの定義の一例である。定義例２０６は、データの名称が「花子さんの二輪車」であり、「色」が赤、「最高速度」が５０ｋｍ／ｈであることを示している。
　図２は、クラス、属性、アトリビュートの関係を示す図である。
　上述の通り、クラスには、属性が定義される。クラス及び属性は、名称やデータ型などの定義項目を有する。以下、クラス及び属性の個々の定義項目をアトリビュートと称し、アトリビュートの集合をアトリビュートセットと称する。クラス及び属性は、それぞれのアトリビュートセットを用いて定義される。
　図２の例では、クラス３０１は、ID，Name，descriptionなどのアトリビュートを含むアトリビュートセット３０３を用いて定義される。具体的には、クラス３０１のエンティティ３０２は、アトリビュートセット３０３により定義される。
　また、クラス３０１の属性は、ID，Name，descriptionなどのアトリビュートを含むアトリビュートセット３０５を用いて定義される。具体的には、クラス３０１の属性のエンティティ３０４は、アトリビュートセット３０５により定義される。
　なお、図２のアトリビュートセット３０３，３０４に含まれるversionは、本実施形態に係るシステム設計装置により新たに定義可能となったアトリビュートである。versionについて、詳しくは後述する。
　次に、本実施形態に係るシステム設計装置について、図３を参照して説明する。図３は、システム設計装置の機能構成を示す図である。図３に示すように、システム設計装置は、メタモデル定義部１と、モデル構築部２と、モデル記述言語生成部３と、スクリプトファイル生成部４と、動的モデル実行部５と、変更分析部６と、モデル更新部７と、変換ルール生成部８と、テーブル構築部９と、ＤＢ（データベース）１０と、を備える。
　メタモデル定義部１は、入力された既存メタモデル（第１のメタモデル）に基づいて、拡張メタモデル（第２のメタモデル）を生成する。既存メタモデルとは、ＵＭＬやＳｙｓＭＬで記述されるモデルの、記述仕様を定義する既存のメタモデルのことである。拡張メタモデルとは、既存メタモデルを拡張定義したメタモデルのことである。メタモデル定義部１は、既存メタモデルにクラスや属性を拡張定義することにより、拡張メタモデルを生成する。
　モデル構築部２は、メタモデル定義部１が生成した拡張メタモデルに従って、モデルを構築（定義）する。以下、モデル構築部２が構築したモデルを、拡張モデルと称する。モデル構築部２は、拡張モデルを編集することができる。
　モデル記述言語生成部３は、メタモデル定義部１が生成した拡張メタモデルに基づいて、モデル記述言語を生成する。モデル記述言語は、拡張メタモデルに従って定義された拡張モデルを、実行可能なスクリプト言語として記述するための記述様式を定義したものである。
　スクリプトファイル生成部４は、モデル構築部２が構築した拡張モデルと、モデル記述言語生成部３が生成したモデル記述言語と、に基づいて、拡張モデルに対応する、実行可能なスクリプトファイル（Script File）を生成する。
　動的モデル実行部５は、スクリプトファイル生成部４が生成したスクリプトファイルを実行する。スクリプトファイルの実行は、拡張モデルの実行に相当する。
　変更分析部６は、モデル構築部２により編集された拡張モデルの変更内容を分析する。
　モデル更新部７は、変更分析部６による変更内容の分析結果に基づいて、拡張モデルを更新する。
　変換ルール生成部８は、モデル構築部２が構築した拡張モデルを、リレーショナルＤＢに格納するための変換ルールを生成する。
　テーブル構築部９は、変換ルール生成部８が生成した変換ルールに従って、拡張モデルに対応するテーブルを構築する。
　ＤＢ１０は、テーブル構築部９が構築したテーブルを格納するリレーショナルデータベースである。
　なお、システム設計装置の各機能構成について、詳しくは後述する。
　次に、本実施形態に係るシステム設計装置のハードウェア構成について、図４を参照して説明する。本実施形態に係るシステム設計装置は、コンピュータ１００により構成される。コンピュータ１００には、サーバ、クライアント、マイコン、及び汎用コンピュータなどが含まれる。
　図４は、コンピュータ１００の一例を示す図である。図４のコンピュータ１００は、ＣＰＵ（中央演算装置）１０１と、入力装置１０２と、表示装置１０３と、通信装置１０４と、記憶装置１０５と、を備える。プロセッサ１０１、入力装置１０２、表示装置１０３、通信装置１０４、及び記憶装置１０５は、バス１０６により相互に接続されている。
　プロセッサ１０１は、コンピュータ１００の制御装置及び演算装置を含む電子回路である。プロセッサ１０１は、バス１０６を介して接続された各装置（例えば、入力装置１０２、通信装置１０４、記憶装置１０５）から入力されたデータやプログラムに基づいて演算処理を行い、演算結果や制御信号を、バス１０６を介して接続された各装置（例えば、表示装置１０３、通信装置１０４、記憶装置１０５）に出力する。具体的には、プロセッサ１０１は、コンピュータ１００のＯＳ（オペレーティングシステム）や、システム設計プログラムなどを実行し、コンピュータ１００を構成する各装置を制御する。
　システム設計プログラムとは、コンピュータ１００に、システム設計装置の上述の各機能構成を実現させるプログラムである。システム設計プログラムは、一時的でない有形のコンピュータ読み取り可能な記憶媒体に記憶される。上記の記憶媒体は、例えば、光ディスク、光磁気ディスク、磁気ディスク、磁気テープ、フラッシュメモリ、半導体メモリであるが、これに限られない。プロセッサ１０１がシステム設計プログラムを実行することにより、コンピュータ１００がシステム設計装置として機能する。
　入力装置１０２は、コンピュータ１００に情報を入力するための装置である。入力装置１０２は、例えば、キーボード、マウス、及びタッチパネルであるが、これに限られない。ユーザは、入力装置１０２を用いることにより、既存メタモデルなどの情報を入力することができる。
　表示装置１０３は、画像や映像を表示するための装置である。表示装置１０３は、例えば、ＬＣＤ（液晶ディスプレイ）、ＣＲＴ（ブラウン管）、及びＰＤＰ（プラズマディスプレイ）であるが、これに限られない。表示装置１０３は、システム設計装置に入力されたデータ（既存メタモデルなど）、システム設計装置により生成されたデータ（拡張メタモデル、拡張モデル、モデル記述言語、及びスクリプトファイルなど）、及びユーザがシステム設計装置を操作するためのＧＵＩ（Graphical User Interface）などを表示する。
　通信装置１０４は、コンピュータ１００が外部装置と無線又は有線で通信するための装置である。通信装置１０４は、例えば、モデム、ハブ、及びルータであるが、これに限られない。
　記憶装置１０５は、コンピュータ１００のＯＳや、システム設計プログラム、システム設計プログラムの実行に必要なデータ、及びシステム設計プログラムの実行により生成されたデータなどを記憶する記憶媒体である。記憶装置１０５には、主記憶装置と外部記憶装置とが含まれる。主記憶装置は、例えば、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭであるが、これに限られない。また、外部記憶装置は、例えば、ハードディスク、光ディスク、フラッシュメモリ、及び磁気テープであるが、これに限られない。ＤＢ１０は、記憶装置１０５上に構築されてもよいし、外部のサーバ上に構築されてもよい。
　なお、コンピュータ１００は、プロセッサ１０１、入力装置１０２、表示装置１０３、通信装置１０４、及び記憶装置１０５を、それぞれ１つ又は複数備えてもよいし、プリンタやスキャナなどの周辺機器を接続されていてもよい。
　また、システム設計装置は、単一のコンピュータ１００により構成されてもよいし、相互に接続された複数のコンピュータ１００からなるシステムとして構成されてもよい。
　さらに、システム設計プログラムは、コンピュータ１００の記憶装置１０５に予め記憶されていてもよいし、コンピュータ１００の外部の記憶媒体に記憶されていてもよいし、インターネット上にアップロードされていてもよい。いずれの場合も、システム設計プログラムをコンピュータ１００にインストールして実行することにより、システム設計装置の機能が実現される。
　以下、システム設計装置の各機能構成について、図５～図１９を参照して詳細に説明する。
（メタモデル定義部１及びモデル構築部２）
　メタモデル定義部１による既存メタモデルの拡張方法（拡張メタモデルの生成方法）について説明する。以下では、４つの拡張方法について、それぞれ説明する。
（第１の拡張方法）
　一般に、メタモデルには、要求図と、他の図（ブロック図（Block diagram）やパラメトリック図）と、の間の関係を定義する関係クラス（Trace）のメタモデルが設けられている。
　図５は、関係クラスのメタモデルの一例を示す図である。図５の例では、既存メタモデルとして、関係クラス（Trace）４０１とその下位クラスとして、DerivedReqt，Copy，Verify，Satisfyが設けられている。Satisfy（以下、「満たす関係」という）は、要求と、その要求を満足させるモデル要素と、の関係を示している。
　従来、満たす関係では、モデル要素が満足させる要求に対して、制約条件があるか否か区別できなかった。そこで、第１の拡張方法では、メタモデル定義部１は、図５に４０２示すように、制約条件クラス（Condition）のメタモデルを定義（追加）し、関係クラスに対する制約条件の有無を区別するため、制約条件クラスと関係クラス間の関連のメタモデルを拡張定義する。制約条件クラス(Condition)は、要求に対する制約条件を記述するためのクラスである。
　図５の例では、制約条件クラス４０２のアトリビュートセット（Condition_attribute）には、制約条件の可変性（constantCondition）と、名称（Name）と、制約条件の種類（Type）と、が含まれる。
　制約条件の可変性は、boolean型であり、例えば、時間軸に不変な場合（すなわち、経時的に変化しない場合）にTrue、それ以外の場合にFalseと定義される。
　制約条件の種類は、ConditionType（選択肢型）であり、選択肢として、pre_cal_condition，pre_env_condition，trigger，post_cal_condition，post_env_condition，functional_typeを含んでいる。
　このように、メタモデル定義部１が制約条件クラスのメタモデルを拡張定義することにより、既存メタモデルと、制約条件を記述する制約条件クラスのメタモデルと、要求とその要求を満たす等のためのモデル要素間との関係を定義する関係クラス（Trace）に対して、制約条件の有無を区別するため、制約条件クラスと関係クラス間の関連（Association）を定義するメタモデルと、を含む拡張メタモデルが生成される。なお、制約条件クラスの属性及びアトリビュートは、図５の例に限られず、任意に設計可能である。
　図６は、第１の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図である。図６の例では、要求図５０１とブロック図５０３との間には、制約条件付きの満たす関係（satisfyWithCondition）５０２が定義されている。制約条件付きの満たす関係５０２は、制約条件クラス５０４（Condition1）を参照している。制約条件クラス５０４（Condition1）には、各属性の名称、属性の説明、及び制約条件が記述されている。また、制約条件クラス５０４は、計算を行うパラメトリック図５０５を参照している。
　パラメトリック図５０５は、入力（ｌ，ｔ，ｖ）と、出力（ａ）と、計算式と、を定義している。計算式は、例えば、ＭａｔｈＭＬ（Mathematical Markup Language）により記述される。
　このように、第１の拡張方法により生成された拡張メタモデルを用いることにより、モデル構築部２は、制約条件がない満たす関係（satisfy）と、制約条件付きの満たす関係（satisfyWithCondition）と、がそれぞれ定義された拡張モデルを構築することができる。これにより、各要求に対して、制約条件があるか否か区別したり、制約条件の内容を定義したりすることができる。
（第２の拡張方法）
　第２の拡張方法では、メタモデル拡張部１は、既存メタモデルの最上位クラスのメタモデルのアトリビュートに、メタモデルのバージョン情報を拡張定義（追加）する。これにより、最上位クラスのメタモデルのアトリビュートにバージョン情報が含まれた拡張メタモデルが生成される。
　図７は、第２の拡張方法により生成された拡張メタモデルの一例を示す図である。図７において、最上位クラスは、Classifierであり、その下位クラスとして、Datatype，Class，Associationなどが既存メタモデルに定義されている。第２の拡張方法によってClassifierには、アトリビュートとしてバージョン情報（version）が拡張定義されている。
　図８は、第２の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図である。図８に示すように、拡張モデルの各モデル要素５０１～５０５には、いずれもバージョン情報が記載されている。これは、最上位クラスに追加定義されたバージョン情報が継承されたためである。また、５０１～５０５に定義する各要素、例えば、５０４に定義する属性の“airPressure”にもバージョン情報を定義できる。記述例は、図１２の行１０に示す。
　このように、第２の拡張方法により生成された拡張メタモデルを用いることにより、モデル構築部２は、各モデル要素がバージョン情報を有する拡張モデルを構築することができる。これにより、拡張モデルの更新や管理を効率的に行うことができる。
（第３の拡張方法）
　第３の拡張方法では、メタモデル定義部１は、分解関係クラス（Decompose）のメタモデルを拡張定義（追加）する。分解関係クラスは、要求の分解関係（論理和）を定義するクラスであり、図５に示すように、関係クラスの下位クラスとして追加される。これにより、既存メタモデルと、分解関係クラスのメタモデルと、を含む拡張メタモデルが生成される。
　図９は、第３の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図である。図９の例では、要求４２０１（Re1）は、要求４２０２（Re2）と、要求４２０３（Re3）と、に分解されている。これは、要求４２０１は、要求４２０２又は要求４２０３を満足することにより、満たされることを示している。
　このように、第３の拡張方法により生成された拡張メタモデルを用いることにより、モデル構築部２は、要求の分解関係が定義された拡張モデルを構築することができる。
（第４の拡張方法）
　第４の拡張方法では、メタモデル定義部１は、図５に示すように、貢献度クラス（Contribution）のメタモデルを拡張定義（追加）する。貢献度クラスは、DerivedReqt，Copy，Verify，Satisfy，satisfyWithCondition，Decomposeなどの各関係の貢献度を定義するクラスであり、図５に示すように、関係クラスに関連づけられる。貢献度クラスには、属性として、重み（Weight）が定義される。重みは、例えば、各関係の変更コストであるが、これに限られない。これにより、既存メタモデルと、貢献度クラスと、を含む拡張メタモデルが生成される。
　図１０は、第４の拡張方法により生成された拡張メタモデルに従って構築された拡張モデルの一例を示す図である。図１０において、ｘは分解関係４２０４の重みであり、ｙは分解関係４２０５の重みである。また、ｍは、機能ブロック４２０６（Block2）と要求４２０３（Re3）と、の間の満たす関係４２０７の重みであり、ｎは、機能ブロック４２０８（Block3）と要求４２０３（Re3）と、の間の満たす関係４２０９の重みである。各重みは、任意に設定可能である。重みは、例えば、１以上１０以下の整数の中から選択可能であってもよい。
　このように、第４の拡張方法により生成された拡張メタモデルを用いることにより、モデル構築部２は、各関係の重みが定義された拡張モデルを構築することができる。重みとして、各関係の変更コストを定義すると、モデルの変更コストを容易に計算し、変更の管理効率を向上させることができる。
　なお、メタモデル定義部１は、上述の第１の拡張方法乃至第４の拡張方法を、個々に利用してもよいし、２つ以上組み合わせて利用してもよい。
　また、メタモデル定義部１及びモデル構築部２は、既存メタモデル、拡張メタモデル、拡張モデルなどを、表示装置１０３により表示させてもよい。さらに、モデル構築部２は、既存メタモデルに従ってモデルを構築し、構築したモデルを表示装置１０３により表示させてもよい。
（モデル記述言語生成部３）
　モデル記述言語生成部３は、拡張メタモデルに基づいて、モデル記述言語を生成する。以下では、モデル記述言語を、ＭＴＬ４Ｓｙｓ（Model Transformation Language for SysML）と称する。図１１は、ＭＴＬ４Ｓｙｓの一例を示す図である。以下、図１１のＭＴＬ４Ｓｙｓの各行について説明する。
　第１行は、各要求図を、要求型のクラスとして記述することを定義している。
　第２行は、各ブロック図を、ブロック型のクラスとして記述することを定義している。
　第３行は、要求クラスと、ブロッククラスと、の間の関係を、満たす関係（satisfy）又は条件付きの満たす関係（satisfyWithConstraint）として記述することを定義している。第３行において、条件付きの満たす関係は、参照先となる制約条件クラスのＩＤ、例えばCondition1と共に定義されている。
　第４行は、制約条件を、制約条件クラスとして記述することを定義している。
　第５行は、制約条件のアトリビュート（定義項目）を、制約条件クラスの属性（property）として記述することを定義している。
　第６行は、制約条件のconstantTypeアトリビュートを、制約条件クラスのconstantType属性として記述することを定義している。
　第７行は、制約条件のTypeアトリビュートを、制約条件クラスのconditionTypeのアトリビュートとして記述することを定義している。
　第８行は、操作（operation）などを記述するパラメトリック図を、機能（Function）クラスとして記述することを定義している。
　第９行は、操作の入力（input）を、機能クラスのパラメータとして記述することを定義している。
　第１０行は、操作の出力（output）を、機能クラスの出力（return）として記述することを定義している。
　第１１行は、操作の事前計算数式（formula.preCal）を、パラメータ及び事前計算条件（pre_cal_condition）を用いる機能クラスの事前計算数式とし、事前計算結果をpre_resultとして記述することを定義している。
　第１２行は、操作の計算数式（formula）は、パラメート及び事前計算結果（pre_result）を用いる機能クラスの計算数式とし、計算結果をresultとして記述することを定義している。
　第１３行は、操作の事後計算数式を、パラメータ及び事前計算条件を用いる機能クラスの事後計算数式とし、事後計算結果をafter_resultとして記述することを定義している。
　第１４行は、ＵＭＬの全てのモデル要素に付与するバージョン情報（version）を、対応するモデル要素のバージョン情報として記述することを定義している。
　このように、ＭＴＬ４Ｓｙｓでは、スクリプト言語による拡張モデルの記述仕様が定義されている。モデル記述言語生成部３は、拡張メタモデルに基づいて、このようなＭＴＬ４Ｓｙｓを自動的に生成することができる。
　なお、モデル記述言語生成部３は、こうして生成したＭＴＬ４Ｓｙｓを、表示装置１０３に表示させてもよい。
（スクリプトファイル生成部４）
　図１２は、スクリプトファイル生成部４により生成されたスクリプトファイルの一例を示す図である。図１２のスクリプトファイルは、図６の拡張モデルに対応している。以下、図１２のスクリプトファイルの各行について説明する。
　第行１は、このスクリプトファイルの記述仕様（ＭＴＬ４Ｓｙｓ）と、そのバージョン情報（version）と、を記述する。
　第２行～第４行は、要求図５０１を記述している。
　第５行～第８行は、ブロック図５０３を記述している。
　第９行～第２９行は、制約条件クラス５０４と、パラメトリック図５０５と、を記述している。具体的には、以下の通りである。
　第９行は、制約条件クラスを定義している。
　第１０行～第１４行は、制約条件クラス５０４のairPressure属性を定義している。より詳細には、第１１行は、airPressure属性のconstantTypeの値を記述し、第１２行は、conditionTypeの値を記述し、第１３行は、制約値及び単位を記述している。
　第１５行～第２０行は、制約条件クラス５０４の属性ｌを定義している。より詳細には、第１５行は、属性ｌの名称（name）、名称言語（lang）、及びｉｄを定義している。第１６行は、属性ｌのアトリビュートdescriptionの値を記述している。第１７行は、アトリビュートconstantTypeの値（false）を記述している。第１８行は、アトリビュートconditionTypeの値（pre_cal_condition）を記述している。第１９行は、制約条件（＞１０００）と、その単位（ｍ）と、を記述している。
　第２１行及び第２２行は、それぞれ、制約条件クラス５０４のアトリビュートt，vを記述する概要を示す。アトリビュートt，vの記述仕様は、第１５行～第２０行に示す属性ｌの記述仕様と同様である。
　第２３行～第２８行は、パラメトリック図５０５を記述している。より詳細には、第２３行は、パラメトリック図５０５のクラスを定義し、第２４行は、パラメトリック図５０５の入力パラメータを記述している。第２４行では、各パラメータを定義するアトリビュートのＩＤが用いられている。
　第２５行は、パラメトリック図５０５の出力を記述している。第２６行及び第２７は、数式を定義するformulaの例を記述している。第２６行では、MathMLを利用して数式formula1が直接記述され、第２７行では、別途定義された数式（Math1）のＩＤを参照している。図１２の例では、参照する数式Math1は、第３０行で定義されている。数式を定義するformulaは、第２６行と第２７行のいずれかの仕様を利用して記述する。
　スクリプトファイル生成部４は、ＭＴＬ４Ｓｙｓと、拡張モデルと、に基づいて、上記のようなスクリプトファイルを自動的に生成することができる。スクリプトファイル生成部４が生成したスクリプトファイルは、動的モデル実行部５により実行される。動的モデル実行部５は、スクリプトファイルを実行する際、スクリプトファイルの実行過程や実行結果を、表示装置１０３に表示させてもよい。
　なお、各モデル要素のバージョン情報は省略されてもよい。その際は、ディフォールトのバージョン情報として、例えば、第１行におけるMTLSysのバージョン情報を利用することが出来る。また、スクリプトファイル生成部４は、こうして生成したスクリプトファイルを、表示装置１０３に表示させてもよい。さらに、図１２の例では、スクリプトファイルは、ＸＭＬ（eXtensible Markup Language）形式を利用して記述されているが、ＲＤＦ（Resource Description Framework）などの、他のモデル記述言語（記述形式）を用いて記述されてもよい。
　図１３は、ユーザがモデル記述言語を選択可能なＧＵＩの操作画面の一例を示す図である。図１３の操作画面は、表示装置１０３に表示される。ユーザは、入力装置１０２により、ＧＵＩの各種の操作を実行する。ここで、図１３の操作画面を利用したスクリプトファイルの生成方法について説明する。
　ユーザは、参照釦１２０１をクリックし、選択可能な拡張モデルを表示させ、表示された拡張モデルの中からスクリプトファイルの生成対象となる拡張モデルを選択する。
　次に、ユーザは、選択可能な記述形式（モデル記述言語）の中から、使用するモデル記述言語を選択する。図１３の例では、選択可能なモデル記述言語の一覧が、プルダウンリスト１２０２で表示されている。図１３の例では、選択可能なモデル記述言語として、ＭＴＬ４Ｓｙｓと、ＳｙｓＭＬを記述するＸＭＩ（XML Metadata Interchange）と、が表示されているが、上述の通り、ＲＤＦやＸＭＬが選択可能であってもよい。
　そして、ユーザが実行釦１２０３をクリックすると、ユーザに選択されたモデル記述言語に従って、スクリプトファイル生成部４が、図１２に示したようなスクリプトファイルを生成する。生成されたスクリプトファイルは、記憶装置１０５に保存される。なお、図１３において、選択可能な拡張モデルやモデル記述言語は、ディフォールト値が設定されていてもよい。
（変更分析部６）
　変更分析部６は、モデル構築部２が、構築済みの拡張モデルを編集すると、拡張モデルの変更内容を分析する。図１４は、変更分析部６による変更内容の分析処理の一例を示すフローチャートである。
　モデル構築部２が拡張モデルを編集すると、変更分析部６は、まず、変更内容集合｛Ｍ｝を作成する（ステップＳ８０１）。変更内容集合｛Ｍ｝は、変更された全内容（クラス、属性、及びクラス間の関係など）を含む集合である。
　次に、変更分析部６は、変更内容集合｛Ｍ｝に、satisfyGを定義するクラス又は関係が含まれているか判定する（ステップＳ８０２）。ここでいうsatisfyGは、satisfy（満たす関係）またはsatisfyWithCondition（条件付きの満たす関係）のことである。
　変更内容集合｛Ｍ｝に、satisfyGを定義するクラス又は関係が含まれていない場合（ステップＳ８０２のｎｏ）、変更分析部６は、分析処理を終了する。一方、変更内容集合｛Ｍ｝に、satisfyGを定義するクラス又は関係が含まれている場合（ステップＳ８０２のｙｅｓ）、分析処理は、ステップＳ８０３に進む。
　ステップＳ８０３において、変更分析部６は、変更内容集合｛Ｍ｝から、satisfyGが定義されたクラスを抽出し、satisfyG集合φ＝｛cls_1, cls_2,…,cls_n｝を作成する。satisfyG集合φは、抽出されたクラスのＩＤ（cls_i）を含む集合である。
　次に、変更分析部６は、satisfyG集合φから１つのクラスcls_iを選択する（ステップＳ８０４）。
　そして、変更分析部６は、選択したクラスcls_iに、クラスcls_i’があるか判定する（ステップＳ８０５）。ここでいうクラスcls_i’とは、クラスcls_iに対してsatisfyGの関係を定義されたクラスのうち、satisfyG集合φに含まれないクラスのことである。
　クラスcls_i’がない場合（ステップＳ８０５のｎｏ）、分析処理はステップＳ８０７に進む。
　一方、クラスcls_i’がある場合（ステップＳ８０５のｙｅｓ）、変更分析部６は、クラスcls_i’を、変更候補クラス集合｛cls_tbm｝に追加する（ステップＳ８０６）。その後、分析処理は、ステップＳ８０７に進む。
　ステップＳ８０７において、変更分析部６は、satisfyG集合φに含まれる全てのクラスcls_iについて、ステップＳ８０５，Ｓ８０６の処理が終了したか判定する。未処理のクラスcls_iがある場合（ステップＳ８０７のｎｏ）、分析処理はステップＳ８０４に戻り、変更分析部６は、次に処理するクラスcls_iを選択する。一方、全てのクラスcls_iについて、処理が終了した場合（ステップＳ８０７のｙｅｓ）、分析処理はステップＳ８０８に進む。
　ステップＳ８０８において、変更分析部６は、変更候補クラス集合｛cls_tbm｝に、satisfyWithConditionの関係が定義されたクラスがあるか判定する。satisfyWithConditionの関係が定義されたクラスが無かった場合（ステップＳ８０８のｎｏ）、変更分析部６は、分析処理を終了する。一方、satisfyWithConditionの関係が定義されたクラスがあった場合（ステップＳ８０８のｙｅｓ）、分析処理はステップＳ８０９に進む。
　ステップＳ８０９において、変更分析部６は、変更候補クラス集合｛cls_tbm｝から、satisfyWithConditionの関係が定義されたクラスを抽出し、制約条件集合｛Condition_cls｝を作成する。制約条件集合｛Condition_cls｝は、抽出された各クラスのsatisfyWithConditionを定義する制約条件クラスの集合である。
　その後、変更分析部６は、制約条件集合｛Condition_cls｝に含まれ、かつ、変更内容集合｛Ｍ｝に含まれないクラスを抽出し、抽出したクラスを変更候補クラス集合｛cls_tbm｝に追加し（ステップＳ８１１）、分析処理を終了する。
　以上の分析処理により、変更分析部６は、分析結果として、変更候補クラス集合｛cls_tbm｝を出力する。以上の説明からわかるように、変更候補クラス集合｛cls_tbm｝には、拡張モデルの変更によって影響される、関係クラスなどの一般のクラスと、制約条件クラスと、が含まれる。変更分析部６は、これらのクラスを変更対象として自動的に抽出することができる。
（モデル更新部７）
　モデル更新部７は、モデル構築部２により編集された拡張モデルのうち、変更分析部６により抽出された変更対象を更新（変更）する。モデル更新部７は、全ての変更対象を更新してもよいし、ユーザにより選択された変更対象のみを更新してもよい。図１５は、ユーザが更新対象を選択可能なＧＵＩの操作画面の一例を示す図である。図１５の操作画面は、表示装置１０３に表示される。ユーザは、入力装置１０２により、ＧＵＩの各種の操作を実行する。ここで、図１５の操作画面を利用した拡張モデルの更新方法について説明する。
　ユーザは、まず、操作画面に表示された変更候補クラス集合｛cls_tbm｝の中から、更新したいクラスを選択する。図１５の例では、一般のクラス候補９０１と、制約条件クラス候補９０２と、がそれぞれリストとして表示されている。クラス候補９０１には、例えばclass1，class3，class6が含まれている。また、制約条件クラス候補９０２には、例えばCondition_class1，Condition_class3，Condition_classXが含まれている。
　図１５の例では、class1と、class1に関連づけられたCondition_class1と、ユーザにより選択されたCondition_classXと、が選択されている。一般クラスと、制約条件クラスと、はそれぞれユーザにより選択されてもよいし、ユーザにより選択された一般クラス（又は制約条件クラス）に関連づけられた制約条件クラス（又は一般クラス）がモデル更新部７により自動的に選択されてもよい。ユーザは、選択釦９０３をクリックすることにより、選択内容を決定する。
　図１５の操作画面の右側には、ユーザにより選択された更新対象（class1，Condition_class1，Condition_classX）が表示されている。ユーザがこれらの更新対象を選択すると、モデル更新部７は、選択された更新対象を、拡張モデルの編集内容に応じて変更する。図１５の例では、class1と、Condition_class1と、が選択され、変更されている。
　その後、ユーザが更新釦９０４をクリックすると、モデル更新部７は、更新対象の変更内容を、編集された拡張モデルに追加する。これにより、拡張モデルが更新される。この際、モデル更新部７は、更新したクラスのバージョン情報を自動的に更新するのが好ましい。例えば、変更前のバージョンがＮである場合、変更後のクラスのバージョンをＮ＋１にすることが考えられる。また、モデル更新部７は、変更したクラスの下位クラスのバージョン情報を更新してもよい。例えば、変更したクラスの下位クラスのバージョンを全部プラス１にしてもよい。
（変換ルール生成部８）
　変換ルール生成部８は、拡張メタモデルに基づいて、拡張モデルに含まれる要求図、ブロック図、制約条件クラス、及びパラメトリック図を、リレーショナルデータベースに保存するための変換ルールを生成する。図１６及び図１７は、変換ルール生成部８が生成した変換ルールの仕様の一例を示す図である。
　図１６に示すように、要求テーブル（re_tbl）１００１は、拡張メタモデルに従って記述される要求図（RE）を保存する。要求テーブル１００１は、ID，name，description，superRequirement，versionのコラムを有する。IDのコラムには、要求図のＩＤが格納される。nameのコラムには、要求図の名称が格納される。descriptionのコラムには、要求図の説明が格納される。superRequirementのコラムには、要求図が継承関係を有する親要求が格納される。versionのコラムには、要求図のバージョン情報が格納される。
　パラメトリックテーブル（parametric_tbl）１００２は、拡張メタモデルに従って記述されるパラメトリック図（Parametric）を保存する。パラメトリックテーブル１００２は、ID (PK)，name，description，Input，Output，formula， versionのコラムを有する。ID (PK)のコラムには、パラメトリック図のＩＤが格納される。また、ＩＤコラムはプライムキーとして設定することができる。Nameのコラムには、パラメトリック図の名称が格納される。descriptionのコラムには、パラメトリック図の説明が格納される。Inputのコラムには、パラメトリック図の入力に関する情報が格納される。図１６の例では、入力に関する情報として、変数名（val1）と、変数の型（datatype）と、単位（unit）と、が格納されている。Outputのコラムには、パラメトリック図の出力に関する情報が格納される。図１６の例では、出力に関する情報として、変数名（val2）と、変数の型（datatype）と、単位（unit）と、が格納されている。formulaのコラムには、パラメトリック図の計算式が格納される。図１６の例では、計算式はMathMLの形式で格納される。versionのコラムには、パラメトリック図のバージョン情報が格納される。
　図１７に示すように、ブロックテーブル（block_tbl）１００３は、拡張メタモデルに従って記述されるブロック図（block）を保存する。ブロックテーブル１００３は、ID（PK），name，Condition（id，FK），Operation（id，FK），attribute，description，super，versionのコラムを有する。IDのコラムには、ブロック図のＩＤが格納される。また、ＩＤコラムはプライムキーとして設定することができる。nameのコラムには、ブロック図の名称が格納される。Conditionのコラムには、後述する制約条件テーブル１００４のIDが格納される。Operationのコラムには、パラメトリックテーブル１００２のIDが格納される。attributeのコラムには、後述するアトリビュートテーブル１００５のIDのリストが格納される。descriptionのコラムには、ブロック図の説明が格納される。superのコラムには、ブロック図が継承関係を有する親ブロック（super）のIDが格納される。versionのコラムには、ブロック図のバージョン情報が格納される。
　制約条件テーブル（Condition_tbl）１００４は、拡張メタモデルに従って記述される制約条件（Condition）を保存する。制約条件テーブル１００４は、ID（PK），name，description，Attribute，Formula（id，FK），super，versionのコラムを有する。IDのコラムには、制約条件のＩＤが格納される。また、ＩＤコラムはプライムキーとして設定することができる。nameのコラムには、制約条件の名称が格納される。descriptionのコラムには、制約条件の説明が格納される。Attributeのコラムには、アトリビュートテーブル１００５のIDのリスト（List_of_id）が格納される。Formulaのコラムには、パラメトリックテーブル１００２のIDが格納される。superのコラムには、ブロック図が継承関係を有する親ブロック（super）のIDが格納される。versionのコラムには、ブロック図のバージョン情報が格納される。
　アトリビュートテーブル（attribute_tbl）１００５は、拡張メタモデルに従って記述される制約条件及びブロック図に記述するアトリビュートを保存する。アトリビュートテーブル１００５は、ID（PK），name，description，constantType，ConditionType，versionのコラムを有する。IDのコラムには、アトリビュートのＩＤが格納される。また、ＩＤコラムはプライムキーとして設定することができる。nameのコラムには、アトリビュートの名称が格納される。descriptionのコラムには、アトリビュートの説明が格納される。constantTypeのコラムには、制約条件の可変性が格納される。ConditionTypeのコラムには、制約条件の種類が格納される。versionのコラムには、アトリビュートのバージョン情報が格納される。
（テーブル構築部９）
　テーブル構築部９は、上記のような仕様を有する変換ルールに従って、拡張モデルに対応する各種のテーブルを自動的に構築し、構築したテーブルをＤＢ１０に格納する。図１８は、テーブル構築部９により構築された、モデル要素に対応するテーブルの一例を示す図である。図１８のテーブルは、図８の拡張モデルに対応している。
　図１８に示すように、ブロック５０３の定義は、ブロックテーブル１１０１の１行目に格納されている。制約条件クラス５０４の定義は、制約条件テーブル１１０２の１行目に格納されている。制約条件クラス５０４のアトリビュートであるairPressure，lの定義は、それぞれアトリビュートテーブル１１０３の１行目，２行目に格納されている。パラメトリック図５０５の定義は、パラメトリックテーブル１１０４の１行目に格納されている。
　上述の通り、制約条件テーブル１１０２のattributeのコラムには、アトリビュートテーブル１１０３のID（attr1，Attr2）が格納されている。また、制約条件テーブル１１０２のFormulaのコラムには、パラメトリックテーブル１１０４のID（Para_001）が格納されている。
　テーブル構築部９が構築したテーブルは、ＤＢ１０に格納される。なお、ＤＢ１０には、複数の拡張モデルが、テーブルとして格納されてもよい。
　図１９は、ユーザがテーブルを構築可能なＧＵＩの操作画面の一例を示す図である。図１９の操作画面は、表示装置１０３に表示される。ユーザは、入力装置１０２により、ＧＵＩの各種の操作を実行する。ここで、図１９の操作画面を利用したテーブルの構築方法について説明する。
　ユーザは、選択釦１３０１をクリックし、選択可能な拡張モデルのモデル要素（要求図、ブロック図など）を表示させ、表示されたモデル要素の中から、テーブルを構築するモデル要素を選択する。
　図１９の例では、操作画面にはメタモデル表示部１３０２が設けられている。メタモデル表示部１３０２には、１３０１で選択されたモデル要素に対応する拡張メタモデル（例えば、ブロック図の拡張メタモデルなど）が表示される。メタモデル表示部１３０２に表示された拡張メタモデルは、ユーザの操作により編集可能であってもよい。
　次に、ユーザは、構築するテーブルの名称を、テーブル名入力欄１３０３に入力する。図１９の例では、テーブルの名称はblock_tblに指定されている。
　続いて、１３０１で選択したモデル要素に対して、前述の変換ルールに従ってテーブル生成のＳＱＬ文（Structured Query Language）を自動的に生成し、変換ルール欄１３０４において表示と編集をする。変換ルール生成部８は、ユーザにより指定された内容に従って、変換ルールを生成する。また、ユーザにより指定された変換ルールが生成済みの場合、変換ルール欄１３０４に、生成済みの変換ルールが表示されてもよい。さらに、変換ルール欄１３０４に表示された変換ルールは、ユーザの操作により編集可能であってもよい。
　そして、ユーザが保存釦１３０５をクリックすると、テーブル構築部９は、変換ルール欄１３０４に表示された変換ルールに従って、ユーザに選択されたモデル要素に対応するテーブルを構築する。こうして構築されたテーブルは、ＤＢ１０に格納される。
　以上説明した通り、本実施形態に係るシステム設計装置は、既存メタモデルに対して、制約条件を記述する制約条件クラスのメタモデルと、関係クラスに対して、前記制約条件の有無を区別するため、前記制約条件クラスと前記関係クラスとの間の関連（Association）を定義するメタモデルと、バージョン情報のメタモデルと、分解関係クラスのメタモデルと、貢献度クラスのメタモデルなどを、拡張定義することができる。これにより、ＵＭＬやＳｙｓＭＬなどのモデリング言語による記述能力を高めることができる。
　また、上記の拡張定義により、モデルの更新管理や統合設計が容易になるため、システムを効率的に開発したり、開発コストや保守コストを削減したりすることができる。
　なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。
１：メタモデル定義部、２：モデル構築部、３：モデル記述言語生成部、４：スクリプトファイル生成部、５：動的モデル実行部、６：変更分析部、７：モデル更新部、８：変換ルール生成部、９：テーブル構築部、１０：ＤＢ、１００：コンピュータ、１０１：プロセッサ、１０２：入力装置、１０３：表示装置、１０４：通信装置、１０５：記憶装置

Claims (13)

  1. 　モデリング言語により記述された第１のメタモデルに基づいて、前記第１のメタモデルと、制約条件を記述する制約条件クラスのメタモデルと、関係クラス（Trace）に対して、前記制約条件の有無を区別するため、前記制約条件クラスと前記関係クラスとの間の関連（Association）を定義するメタモデルと、
    を含む第２のメタモデルを生成するメタモデル定義部と、
    　前記第２のメタモデルに従ってモデルを構築するモデル構築部と、
    　前記モデルに対応するスクリプトファイルを生成するスクリプトファイル生成部と、
    を備えるシステム設計装置。
  2. 　前記第２のメタモデルは、前記制約条件クラスの属性として、前記制約条件の種類と、前記制約条件の可変性と、の少なくとも一方を含む
    請求項１に記載のシステム設計装置。
  3. 　前記第２のメタモデルは、最上位クラスの属性として、バージョン情報を含む
    請求項１又は請求項２に記載のシステム設計装置。
  4. 　前記第２のメタモデルは、要求の分解関係を定義する分解関係クラスのメタモデルを含む
    請求項１乃至請求項３のいずれか１項に記載のシステム設計装置。
  5. 　前記第２のメタモデルは、各関係の貢献度を定義する貢献度クラスのメタモデルを含む
    請求項１乃至請求項４のいずれか１項に記載のシステム設計装置。
  6. 　前記第２のメタモデルに従って定義された前記モデルを、スクリプト言語として記述するための記述様式を定義する、モデル記述言語を生成するモデル記述言語生成部を備える
    請求項１乃至請求項５のいずれか１項に記載のシステム設計装置。
  7. 　前記スクリプトファイルを実行する動的モデル実行部を備える
    請求項１乃至請求項６のいずれか１項に記載のシステム設計装置。
  8. 　前記モデルの変更内容を、前記関係クラスに対する前記制約条件の有無に基づいて分析する変更分析部を備える
    請求項１乃至請求項７のいずれか１項に記載のシステム設計装置。
  9. 　前記変更分析部による分析結果に基づいて、前記モデルを更新するモデル更新部を備える
    請求項８に記載のシステム設計装置。
  10. 　前記モデルをリレーショナルデータベースに格納するための変換ルールを生成する変換ルール生成部を備える
    請求項１乃至請求項９のいずれか１項に記載のシステム設計装置。
  11. 　前記変換ルールに従って、前記モデルに対応するリレーショナルデータベースのテーブルを構築するテーブル構築部を備える
    請求項１０に記載のシステム設計装置。
  12. 　前記モデルを表示する表示装置を備える
    請求項１乃至請求項１１のいずれか１項に記載のシステム設計装置。
  13. 　モデリング言語により記述された第１のメタモデルに基づいて、前記第１のメタモデルと、制約条件を記述する制約条件クラスのメタモデルと、関係クラス（Trace）に対して、制約条件の有無を区別するため、前記制約条件クラスと関係クラス間の関連（Association）を定義するメタモデルと、を含む第２のメタモデルを生成する工程と、
    　前記第２のメタモデルに従ってモデルを構築する工程と、
    　前記モデルに対応するスクリプトファイルを生成する工程と、
    を備えるシステム設計方法。
PCT/JP2015/080818 2015-10-30 2015-10-30 システム設計装置及び方法 WO2017072969A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2017547331A JP6427687B2 (ja) 2015-10-30 2015-10-30 システム設計装置及び方法
EP15907332.9A EP3370147A4 (en) 2015-10-30 2015-10-30 SYSTEM DESIGN DEVICE AND METHOD
PCT/JP2015/080818 WO2017072969A1 (ja) 2015-10-30 2015-10-30 システム設計装置及び方法
US15/914,231 US10732938B2 (en) 2015-10-30 2018-03-07 System design apparatus and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/080818 WO2017072969A1 (ja) 2015-10-30 2015-10-30 システム設計装置及び方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/914,231 Continuation US10732938B2 (en) 2015-10-30 2018-03-07 System design apparatus and method

Publications (1)

Publication Number Publication Date
WO2017072969A1 true WO2017072969A1 (ja) 2017-05-04

Family

ID=58631472

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/080818 WO2017072969A1 (ja) 2015-10-30 2015-10-30 システム設計装置及び方法

Country Status (4)

Country Link
US (1) US10732938B2 (ja)
EP (1) EP3370147A4 (ja)
JP (1) JP6427687B2 (ja)
WO (1) WO2017072969A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220206760A1 (en) * 2019-09-23 2022-06-30 Denso Create Inc. Design assistance tool
US20220206761A1 (en) * 2019-09-23 2022-06-30 Denso Create Inc. Design assistance tool

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3370147A4 (en) * 2015-10-30 2019-06-26 Kabushiki Kaisha Toshiba SYSTEM DESIGN DEVICE AND METHOD

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011048796A (ja) * 2009-08-28 2011-03-10 Fujitsu Computer Technologies Ltd 意味モデル生成プログラムおよび意味モデル生成装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6904598B2 (en) * 2000-08-08 2005-06-07 International Business Machines Corporation COBOL metamodel
US6775680B2 (en) * 2000-08-08 2004-08-10 International Business Machines Corporation High level assembler metamodel
US8104017B2 (en) 2001-10-25 2012-01-24 The Mathworks, Inc. Traceability in a modeling environment
EP1387260A1 (de) * 2002-07-25 2004-02-04 The Rationalizer Intelligent Software AG Verfahren und Vorrichtung zur Erzeugung von Software
US8122106B2 (en) 2003-03-06 2012-02-21 Microsoft Corporation Integrating design, deployment, and management phases for systems
CN1570860B (zh) 2003-03-06 2012-03-21 微软公司 用于系统设计期间的验证的方法
NZ525409A (en) * 2003-04-17 2005-04-29 Auckland Uniservices Ltd Software design system and method
US7823120B2 (en) * 2004-03-02 2010-10-26 Metaphor Vision Ltd. Device, system and method for accelerated modeling
JP4524750B2 (ja) * 2004-11-11 2010-08-18 日本電気株式会社 モデル駆動開発装置、モデル駆動開発方法及びモデル駆動開発プログラム
US7512942B2 (en) * 2005-08-24 2009-03-31 International Business Machines Corporation Model-driven software deployment in an application server
DE102006050112A1 (de) 2006-10-25 2008-04-30 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Erstellung einer Anforderungsbeschreibung für ein eingebettetes System
US8112738B2 (en) * 2007-09-26 2012-02-07 Sap Ag Apparatus and method of customizable model import and export to and from XML schema formats
US20090093901A1 (en) * 2007-10-03 2009-04-09 International Business Machines Corporation Method and apparatus for using design specifications and measurements on manufactured products in conceptual design models
WO2009108943A2 (en) * 2008-02-29 2009-09-03 Doyenz Incorporated Automation for virtualized it environments
US8578324B2 (en) 2008-03-17 2013-11-05 International Business Machines Corporation Variability layer for domain-specific modeling languages
US8375370B2 (en) * 2008-07-23 2013-02-12 International Business Machines Corporation Application/service event root cause traceability causal and impact analyzer
JP5172585B2 (ja) 2008-10-07 2013-03-27 インターナショナル・ビジネス・マシーンズ・コーポレーション オブジェクト・モデルに対するアクセスを制御するシステム、方法、およびプログラム
US8413109B2 (en) * 2010-01-20 2013-04-02 Sap Ag Systems and methods for metamodel transformation
GB201008332D0 (en) * 2010-05-19 2010-07-07 Bae Systems Plc System validation
JP5284403B2 (ja) 2011-03-28 2013-09-11 株式会社東芝 オントロジ更新装置、方法、およびシステム
US9117028B2 (en) * 2011-12-15 2015-08-25 The Boeing Company Automated framework for dynamically creating test scripts for software testing
US9158503B2 (en) 2013-10-08 2015-10-13 King Fahd University Of Petroleum And Minerals UML model integration and refactoring method
EP3370147A4 (en) * 2015-10-30 2019-06-26 Kabushiki Kaisha Toshiba SYSTEM DESIGN DEVICE AND METHOD

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011048796A (ja) * 2009-08-28 2011-03-10 Fujitsu Computer Technologies Ltd 意味モデル生成プログラムおよび意味モデル生成装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HAJIME HORIUCHI ET AL.: "Current Trends on Metamodel Standardization : Part-1: Basic Concept and Historical Evolution of Metamodel", IPSJ MAGAZINE, vol. 43, no. 11, 15 November 2002 (2002-11-15), pages 1246 - 1252, XP009504795, ISSN: 0447-8053 *
See also references of EP3370147A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220206760A1 (en) * 2019-09-23 2022-06-30 Denso Create Inc. Design assistance tool
US20220206761A1 (en) * 2019-09-23 2022-06-30 Denso Create Inc. Design assistance tool

Also Published As

Publication number Publication date
EP3370147A4 (en) 2019-06-26
US10732938B2 (en) 2020-08-04
EP3370147A1 (en) 2018-09-05
JPWO2017072969A1 (ja) 2018-06-07
US20180196646A1 (en) 2018-07-12
JP6427687B2 (ja) 2018-11-21

Similar Documents

Publication Publication Date Title
US8326795B2 (en) Enhanced process query framework
US8056047B2 (en) System and method for managing resources using a compositional programming model
US9978024B2 (en) Workflow integration with Adobe™ Flex™ user interface
US9471213B2 (en) Chaining applications
WO2017162024A1 (zh) 组件和模板的可视化开发方法及系统、存储介质、设备
US10114619B2 (en) Integrated development environment with multiple editors
US20120159437A1 (en) Managing lifecycle of objects
US11128721B2 (en) Action flow fragment management
US8869105B2 (en) Extensibility integrated development environment for business object extension development
US10732938B2 (en) System design apparatus and method
US20120282586A1 (en) User customizable queries to populate model diagrams
US20160292305A1 (en) System, method, and program for storing and analysing a data graph
Wardhana et al. Transformation of sysml requirement diagram into owl ontologies
US20200167049A1 (en) Context menu fragment management
US20140214731A1 (en) Method and System for Automated Computer Program Generation
US8972927B2 (en) Method and system for providing modeled components
US9405514B1 (en) Process fragment management
Mouheb et al. Unified modeling language
Abdelmalek et al. A Bimodal Approach for the Discovery of a View of the Implementation Platform of Legacy Object-Oriented Systems under Modernization Process.
Saeki et al. Model metrics and metrics of model transformations
US20240036831A1 (en) An extensible binding mechanism for translating between application programming interface description languages
US20240111922A1 (en) System and method for managing simulation artifacts
JP2010165205A (ja) モデルのテンプレート自動生成システム、方法及びプログラム
JP2016224623A (ja) 画面ｕｉ検証装置、画面ｕｉ検証方法、及びプログラム
Chebanyuk et al. An Approach of Behavioral Software Models Comparison by Means of Their Formal Representation Analysis

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15907332

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017547331

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE