JP5457761B2 - Semantic model generation program and semantic model generation apparatus - Google Patents

Description

  The present invention relates to a modeling process in software development.

Various technologies have been developed to support software development.
For example, the following techniques are known for realizing an apparatus that outputs an object diagram that can easily understand the structure of a program from a program written in an object-oriented language. That is, the class structure is extracted by the class definition information extraction process using the source program as an input. Then, the definition position of member data is determined by class method analysis processing, class information is generated, and an object diagram is obtained via an output device by object diagram output processing.

  In addition, it is not necessary to develop graphic information input means for each notation, and the following techniques are also known for the purpose of making graphic information input means common to all notations. . That is, the metamodel storage unit stores a metamodel, and the analysis rule storage unit stores a plurality of analysis rules for analyzing graphic information. Then, the model operation unit obtains graphic information in accordance with a specific notation that defines the elements included in the model, and the model generation unit generates a graphic based on the meta model and the analysis rule corresponding to the notation of the graphic information. Analyze information to generate a model.

  Furthermore, the following techniques are also known for the purpose of supporting the creation of a class diagram based on a unified policy. That is, a specification / design document receiving unit receives a created specification / design document related to software to be developed, and extracts a sequence diagram therefrom. In addition, the class generation unit classifies the sequence diagram for each type of function, and generates a class diagram having management information representing a target operated by the function in the classified sequence diagram as a class. Then, the attribute generation unit acquires a message parameter from the sequence diagram, and adds the parameter to the class diagram as an attribute of the corresponding class. Further, the relationship generation unit extracts a set of classes having the same attribute from the class diagram to which the attribute is added, and generates a relationship between these classes. As described above, the creation policy can be unified.

JP-A-9-185497 JP 2007-172228 A JP 2008-287305 A

  However, there are still many parts of software development that rely on human abilities, and there is room for improvement in software productivity. Accordingly, an object of the present invention is to improve software productivity by generating data representing a software model so as to be adapted to automatic generation of a source code in a modeling process in software development.

The semantic model generation program provided in one aspect causes a computer to execute a metamodel acquisition step, a class diagram generation step, and a semantic model generation step.
The metamodel acquisition step is a step of acquiring a metamodel. The meta model includes a definition of a meta part class obtained by meta-modeling parts included in software, and represents the software by meta-modeling using a first class diagram expressed in UML.

  The class diagram generating step includes defining a part class representing a part included in the software as a subclass of the meta part class, thereby including a model obtained by modeling the software according to the meta model. It is a step of generating as a second class diagram expressed in the UML.

  In the semantic model generation step, the part class in the second class diagram is a class obtained by modeling the part based on the generalization from the part class to the meta part class and the meta model. This is a step of generating a semantic model representing the meaning of the class diagram of 2 in a predetermined formal language.

  According to the semantic model generation program, the semantic model clearly indicates that “a component class is a class that models a component”. Therefore, according to the above semantic model generation program, the problem that “automatic generation of appropriate source code is hindered because it cannot automatically determine which class models what” is solved. Is done. That is, the semantic model generated as described above is suitable for automatic generation of source code, and the semantic model generation program can improve software productivity.

It is a figure explaining the outline | summary of the software development support by 1st Embodiment. It is a class diagram of UML showing a 1st metamodel. FIG. 3 is a UML class diagram representing a first model according to a first metamodel. It is a block diagram which shows the DSM support apparatus and other apparatus by 1st Embodiment. It is a block diagram of a computer. FIG. 3 is a UML class diagram representing a second model according to the first metamodel. It is a UML object figure which shows the whole structure of the software designed by the model which integrated the 1st and 2nd model. FIG. 8 is a UML sequence diagram that defines software operations corresponding to the object diagram of FIG. 7. FIG. 6 is a diagram (part 1) illustrating XML data representing a model obtained by integrating the first and second models. FIG. 10 is a diagram (part 2) illustrating XML data representing a model obtained by integrating the first and second models. FIG. 10 is a diagram (No. 3) illustrating XML data representing a model obtained by integrating the first and second models. FIG. 14 is a diagram (No. 4) illustrating XML data representing a model obtained by integrating the first and second models. It is a figure explaining the model edit process by 1st Embodiment. It is a figure explaining the drive order definition process by 1st Embodiment. It is a figure explaining the code generation processing by a 1st embodiment. It is a UML class diagram showing a 2nd metamodel. It is a class diagram of UML showing the model according to a 2nd metamodel. FIG. 15 is a UML object diagram illustrating a usage example of the model of FIG. 14. It is a class diagram of UML showing a 3rd metamodel. It is a UML object figure showing the model according to a 3rd metamodel.

  Hereinafter, embodiments will be described in detail with reference to the drawings. Specifically, first, an overview of the first embodiment will be described with reference to FIGS. 1 to 5 together with a meta model and an example of the model. Next, with reference to FIGS. Details of information and various processes will be described. Thereafter, second and third embodiments using other metamodels will be described with reference to FIGS. Finally, other embodiments will be described.

  FIG. 1 is a diagram for explaining the outline of software development support according to the first embodiment. Note that FIG. 1 is expressed in the form of a UML (Unified Modeling Language) use case diagram.

  In the process P101, the UML tool 103 and the DSM (Domain-Specific Modeling) support apparatus 104 cooperate with each other using the software metamodel 101 and the notation rule 102 for association between the metamodel 101 and the model. Edit processing.

  The meta model 101 is written in UML and prepared in advance. A specific example of the metamodel 101 will be described later with reference to FIG. In another embodiment, the meta model 101 may be as shown in FIGS.

  The notation rule 102 is “How UML diagrams (class diagrams, object diagrams, etc.) representing software models must be described in order to be compatible with the metamodel 101”. Is a rule representing That is, the notation rule 102 is a kind of constraint condition.

  The notation rule 102 may be incorporated in advance in the DSM support apparatus 104 as control logic. Alternatively, the notation rule 102 may be expressed as data in a predetermined format, stored in a storage device, and read by the DSM support device 104. Then, the DSM support device 104 may operate according to the read notation rule 102.

  As a result of the process P101, a model diagram 105 expressed in UML and a model 106 expressed in XML (eXtensible Markup Language) are output. Then, using the output model 106 and the code generation template 107 prepared in advance, the code generation device 108 performs code generation processing in process P102.

  As a result, source code 109 in a predetermined programming language such as C, C ++, Java (registered trademark) is output. The code generation template 107 is written in XSL (eXtensible Stylesheet Language) and is prepared in advance according to the programming language.

  According to the first embodiment, the meta model 101 and the notation rule 102 are used as constraint conditions, and a model diagram 105 that satisfies the constraint conditions is generated. Further, the meaning of the model represented by the model diagram 105 is interpreted according to the meta model 101 and the notation rule 102, and is represented as an XML model 106.

  That is, the model 106 is semantically equivalent to the model diagram 105 and satisfies the above constraint conditions. In other words, the content represented by the model 106 as the semantic model is visually represented in the model diagram 105 as a figure.

  The code generation device 108 can output the source code 109 of the desired programming language from the model 106 that satisfies the constraint conditions by receiving an appropriate code generation template 107 corresponding to the desired programming language as an input. . In other words, the UML tool 103 and the DSM support device 104 of the first embodiment improve the software productivity by generating the model 106 under the constraint condition so as to be adapted to the automatic generation of the source code 109. Can do.

Next, the environment and field to which the first embodiment outlined in FIG. 1 is preferably applied will be described.
According to the first embodiment, it is possible to develop a software that is based on DSM while taking advantage of the advantage of using UML that is a general-purpose language. Hereinafter, in order to help understanding of the features of the first embodiment, the use of UML and software development by DSM will be described.

The software design using UML has the following advantages (a1) to (a3).
(A1) UML is accepted by many software designers and programmers (hereinafter collectively referred to as “users”). For this reason, many users have already accumulated know-how and knowledge regarding software development using UML.

  (A2) An editor for creating various diagrams by UML is actually used. The know-how and knowledge described in (a1) above include those related to the operation method of these editors.

  (A3) Since UML is a general-purpose language, it can be used regardless of the field. For example, UML can be used regardless of differences in fields such as embedded systems for vehicles, medical systems, and financial systems.

However, the use of UML does not necessarily directly improve the productivity of software. The reason is as follows.
Generally, software is written in programming languages such as C, C ++, Java (registered trademark), and these programming languages are character-based text languages. In contrast, UML is a non-text language.

  Non-text languages include, for example, a language that expresses the structure and operation of software in the form of a table representing a state transition. UML is a graphic language that expresses the structure and operation of software by a combination of figures. . Even when a non-text language such as UML is used in software design, a source code of a text language is eventually created.

  However, the contents expressed in a non-text language (that is, figures and tables) according to the conventional design method exist only as reference information for implementing software, and there is not enough information to automatically generate source code. there were. Therefore, conventionally, even if UML is used in software development, it is necessary for the programmer to perform manual work to obtain the actual source code, and a portion depending on human ability remains. That is, the use of UML alone does not necessarily lead to significant improvements in software productivity and quality.

  As described above, although UML has various advantages, the use of UML does not always lead to a significant improvement in productivity and quality. Therefore, DSM has been proposed as another method of software development.

  DSM is a technique for narrowing down software development targets to specific domains (for example, specific fields such as for vehicles, medical use, and financial use). In DSM, a non-text language such as a figure or a table is defined specifically for the specific domain so as to sufficiently include information for automatically generating a source code in a text language.

  In DSM, information related to the design of software for a specific domain is expressed in a domain-specific non-text language (ie, Domain-Specific Language; DSL). By narrowing down the domain, the description ability of the non-text language unique to the domain can be raised to a level where the source code can be automatically generated by the text language, so that the source code can be automatically generated by the DSM.

However, DSM has the following drawbacks (b1) to (b5).
(B1) Since a commercially available general-purpose editor (for example, an editor for UML, which is a general-purpose language) cannot be used to edit a domain-specific non-text language, a domain-specific editor is required.

  (B2) Since the editor specific to the domain is not a general-purpose product but a dedicated product, it takes a large amount of money to develop the editor itself.

  (B3) Since the user needs to learn the domain-specific non-text language grammar (syntax) and the domain-specific editor operation method for each domain, it takes time and money.

  (B4) Although the user may have accumulated know-how of development using a general-purpose non-text language such as UML, the knowledge and know-how accumulated with respect to the general-purpose non-text language is not unique to the domain. It is not directly applicable to text languages.

  (B5) For example, even when new software including a part similar to existing software designed using UML is to be developed by DSM, an asset created for existing software (described in UML) Design information etc.) is not divertable. For this reason, existing assets cannot be utilized, and costs for transferring existing assets are also required.

  Here, paying attention to the fact that all of the above defects (b1) to (b5) of DSM are due to the lack of versatility, it is possible to develop software using DSM using a general-purpose language such as UML. If so, it is expected that the advantages of both UML and DSM can be utilized. In other words, using existing resources (user knowledge and know-how, editors, design information, etc.) and automatically generating source code using DSM to improve software development productivity and keep software quality stable and high. Is expected to be able to. One of the purposes of the first embodiment is to realize such expectations.

  As a specific method for coexistence of UML and DSM, as a comparative example for the first embodiment, for example, in order to extend UML by UML profile technology and to give domain-specific meanings to classes, It is also possible to specify a stereotype.

  According to this comparative example, an existing UML editor can be used as a substitute for the dedicated editor as described in (b1) above. In addition, the software designer can perform software design by DSM based on the stereotype while taking advantage of UML. That is, according to this comparative example, it is possible to overcome the disadvantages (b1) to (b5).

  However, the comparative example has a new drawback that “the degree of freedom of design is lost as a price”. In other words, in the above comparative example, since the stereotype is used for the design by DSM, the designer cannot use the stereotype by adding it to the class for other purposes. Will lose the degree of freedom.

  On the other hand, in the first embodiment, the meaning of the class can be determined by a mechanism different from the stereotype (specifically, the meta model 101 and the notation rule 102), and the design by DSM using UML is possible. Therefore, according to the first embodiment, the user can add a stereotype to a class for any purpose, and the degree of freedom of design is maintained. Further, since the first embodiment also uses UML, the above disadvantages (b1) to (b5) are overcome.

  Although the first embodiment is not applicable only to the design by DSM, as described above, it is an example of a specific method for achieving both UML and DSM. Therefore, according to the first embodiment, software can be automatically generated by enabling software design by DSM while taking advantage of UML and existing assets such as the above (a1) to (a3). be able to.

  As a result, in the first embodiment, effects such as software productivity improvement, quality improvement, and quality stabilization can be obtained. Further, compared with the comparative example, the first embodiment further has an advantageous feature that “the degree of freedom in design is not sacrificed in order to achieve the above-described effect”.

Now, the first embodiment having the above advantages will be described in more detail below.
First, specific examples of the meta model 101 and the notation rule 102 in FIG. 1 will be described with reference to FIGS. FIG. 2 is a UML class diagram representing the first metamodel, and FIG. 3 is a UML class diagram representing the first model according to the first metamodel.

  In the following, for simplicity of description, a class named “XXX” may be called ““ XXX ”class”, and an object named “YYY” may be called ““ YYY ”object”.

The first meta model 101a shown in FIG. 2 is an example of the meta model 101 of FIG. 1 prepared in advance, and is shown in FIG. 2 in the form of a UML class diagram.
The first metamodel 101a includes a definition of a class (hereinafter referred to as “metapart class” as a general name) obtained by metamodeling a part (software component) included in software. The first metamodel 101a also includes a definition of a class (hereinafter referred to as a “metainterface class” as a general name) obtained by metamodeling a communication interface between two components. Further, in the following, classes in which parts and interfaces are modeled may be referred to as “part classes” and “interface classes” as general names.

  In FIG. 2, the attributes and methods of each class are omitted as appropriate. In addition, in FIG. 2, “-” indicating private and “+” indicating public are specified as the visibility of each attribute and relationship, respectively. The property can be appropriately specified according to the embodiment.

Specifically, the first metamodel 101a includes definitions of the following classes.
A “ComponentType” class 201, a “CompositionType” class 202, and a “ComponentPrototype” class 203 are defined for metamodeling of software components. The “ComponentType” class 201 and the “CompositionType” class 202 have a stereo type << KeyElement >> indicating that they are classes defined in the meta model.

  In the first embodiment, a stereotype << KeyElement >> is added to some basic classes in the first metamodel 101a, so that the code generator 108 generates the first meta at the time of code generation. The model 101a is easy to interpret. That is, when the source code 109 is generated from the model 106 according to the meta model 101 and the notation rule 102 in the process P1 of FIG. 1, the code generation device 108 also interprets the meta model 101 associated with the model 106. At this time, the stereotype << KeyElement >> gives the code generation device 108 a clue for interpretation.

  Metamodels are not defined by individual users. That is, each class in FIG. 2 is not defined by individual users. Therefore, even if a stereotype is assigned to a class included in the first metamodel 101a, the degree of freedom of user design is not constrained.

  The “CompositionType” class 202 is an example of the meta component class. Since the “ComponentType” class 201 that is a super class of the “CompositionType” class 202 is an abstract class further abstracted from the meta component class, it can also be said to be a kind of meta component class. In the “ComponentType” class 201, a Boolean variable named “supportMultipleInstantiation” indicating whether or not a plurality of instances may be defined is defined as an attribute. The “ComponentPrototype” class 203 is defined for metamodeling of nested relationships between components.

  Also, a “ConfigParam” class 204 is defined to metamodel that a part may have parameters. The parameter has a name and is metamodeled that the value is set. In the “ConfigParam” class 204, a string type variable named “name” and a variable named “value” Are defined as attributes. Since the parameter type can be arbitrarily set in each class defined by the user, the type of the “value” attribute is not specified in the “ConfigParam” class 204 in the first metamodel 101a.

  In order to metamodel that the software component is an executable component, a “RunnableEntity” class 205 is defined in which an executable entity (entity) is metamodeled. As a metamodel of assigning a symbol for calling the entity to an executable entity, a “RunnableEntity” class 205 defines a character string type variable named “symbol” as an attribute.

  In addition, a “Task” class 206 and a “RunnableConnector” class 207 are defined in order to metamodel that a task drives a component. The “Task” class 206 also has a stereotype << KeyElement >> to indicate that it is a class defined in the first metamodel 101a.

  As a metamodel of the ability of a task to drive a component at a predetermined cycle, an integer variable named “elapse” indicating the predetermined cycle is defined as an attribute in the “Task” class 206 . In addition, as a metamodel that the initial timing at which a task drives a part can be arbitrarily specified, an integer variable named “initTimer” indicating the initial timing is also defined as an attribute of the “Task” class 206 Has been.

  Further, communication between components in the first meta model 101a is meta-modeled by meta-modeling the communication interface, the communication input / output port provided in the component, and the connection between the input / output ports. ing. In the first embodiment, “communication” between components means message passing between software components, that is, data input / output. Further, “port” does not mean a physical existence but means a virtual port on software. Similarly, “interface” means not a physical entity but a data format in “communication” and refers to an interface on software.

  Specifically, in the first metamodel 101a, an “Interface” class 208 and a “SenderReceiverInterface” class 209 are defined for metamodeling of an interface. The “SenderReceiverInterface” class 209 has a stereo type << KeyElement >> and is an example of the meta interface class. Since the “Interface” class 208 is an abstract class that is a generalization of the “Interface” class 208, it can also be said to be a kind of meta-interface class.

  Further, as described above, an interface is a data format, and more specifically, an aggregate of individual data elements. Therefore, a “DataElementPrototype” class 210 is also defined in which individual data elements included in the interface are metamodeled.

  Further, a virtual input / output port on software when a component communicates with another component is metamodeled as a “Port” class 211. The “Port” class 211 has two subclasses. One is a “RequesterPort” class 212 that metamodels an input port that receives a message from another component, and the other is “ProviderPort” that metamodels an output port that sends a message to another component. Class 213.

Furthermore, connections between ports are metamodeled as “Connecter” classes 214. The “Connecter” class 214 has two subclasses.
One is an “AssemblyConnector” class 215 that meta-models connections between ports of parts that are not nested. The other is a “DelegateConnector” class 216 that meta-models connections between ports of external parts and internal parts (in other words, parent parts and child parts) that are nested.

  In addition, the following relationships are defined between the above classes. In FIG. 1, each relationship is illustrated with an appropriate role name. In addition, the arrow in the line which shows association (association) shows navigability, in other words, shows the direction of reference.

  A generalization 251 indicates that the “ComponentType” class 201 is a super class of the “CompositionType” class 202. The relation 252 indicates that the “ComponentPrototype” class 203 refers to the “ComponentType” class 201 with the role name “typeRef”, and the multiplicity is “1”. An aggregation 253 with a multiplicity of “0 .. *” indicates that the “CompositionType” class 202 can include an arbitrary number of “ComponentPrototype” classes 203 with the role name “component”.

  An aggregation 254 with a multiplicity of “0 .. *” indicates that the “ComponentType” class 201 can include an arbitrary number of “ConfigParam” classes 204. An aggregation 255 with a multiplicity of “1 .. *” indicates that the “ComponentType” class 201 includes one or more arbitrary numbers of “RunnableEntity” classes 205. In other words, the aggregation 254 and the aggregation 255 are metamodels that a part can include a parameter and that the part can be executed.

  An executable entity can then call other executable entities or call itself recursively. A meta model of this is a relationship 256 representing a reference with a role name “call” from the “RunnableEntity” class 205 to the “RunnableEntity” class 205 itself.

  Then, the task calling and driving the part is metamodeled by an aggregation 257 and a connection 258 representing the connection between the task and the part. Specifically, the aggregation 257 is an aggregation of “1 .. *” indicating that the “Task” class 206 includes one or more arbitrary numbers of “RunnableConnector” classes 207. The relation 258 is a relation with a multiplicity of “1” indicating that the “RunnableConnector” class 207 refers to the “RunnableEntity” class 205 with the role name “runnable”. Aggregation 257 and association 258 meta-models that one task calls and drives each of one or more parts.

  Further, as a meta model that a component can have a port, an aggregation 259 with a multiplicity of “0 .. *” indicates that the “ComponentType” class 201 can include a “Port” class 211. The role name of the “Port” class 211 for the “ComponentType” class 201 is “ports”, and the role name of the “ComponentType” class 201 for the “Port” class 211 is “component”.

The generalization 260 and the generalization 261 indicate that the “RequesterPort” class 212 and the “ProviderPort” class 213 are subclasses of the “Port” class 211, respectively.
An association 262 with a multiplicity of “1” indicates that the “Port” class 211 refers to the “Interface” class 208 with the role name “interfaceRef”. The association 262 is a meta-modeling that communication between two ports is performed by a predetermined interface adapted to the two ports.

The generalization 263 indicates that the “Interface” class 208 is a super class of the “SenderReceiverInterface” class 209.
Also, a composition aggregation 264 with a multiplicity of “0 .. *” indicates that the “SenderReceiverInterface” class 209 can include an arbitrary number of “DataElementPrototype” classes 210. In other words, the composite aggregation 264 is a meta-modeling that the interface is a collection of individual data elements.

  The “SenderReceiverInterface” class 209 for the “DataElementPrototype” class 210 has a role name “interface”. Further, the “DataElementPrototype” class 210 for the “SenderReceiverInterface” class 209 has a role name “dataElement”.

  The following relationship is defined for connection between ports. That is, generalization 265 and generalization 266 indicate that “AssemblyConnector” class 215 and “DelegateConnector” class 216 are subclasses of “Connecter” class 214, respectively.

  In addition, the aggregation 267 and the aggregation 268 having a multiplicity of “0 .. *” indicate that the “CompositionType” class 202 can include any number of “AssemblyConnector” classes 215 and “DelegateConnector” classes 216, respectively. The aggregation 267 and the aggregation 268 are metamodels that the components can be connected (that is, the components can communicate with each other).

  Further, the association 269 and the association 270 each having a multiplicity of “1” associate the connection indicated by the “AssemblyConnector” class 215 with the ports at both ends of the connection. In other words, the association 269 indicates that the “AssemblyConnector” class 215 indicating a connection for communication between components refers to the “Port” class 211 with a role name “pPortRef” as a data output source port in communication. Show. Similarly, the association 270 indicates that the “AssemblyConnector” class 215 refers to the “Port” class 211 with the role name “rPortRef” as a data input destination port in communication.

  Similarly, the association 271 and the association 272 each having a multiplicity of “1” associate the connection indicated by the “DelegateConnector” class 216 with the ports at both ends of the connection. In other words, in the relationship 271, the “DelegateConnector” class 216 indicating the connection between the external component and the internal component in the nested relationship refers to the “Port” class 211 with the role name “innerPortRef” as the internal component side port It is shown that. Similarly, the relationship 272 indicates that the “DelegateConnector” class 216 refers to the “Port” class 211 with the role name “outerPortRef” as a port on the external component side.

  As described above, according to the first metamodel 101a, the “CompositionType” class 202 obtained by metamodeling a component is a subclass of the “ComponentType” class 201. Therefore, the “CompositionType” class 202 includes a “RunnableEntity” class 205 and can include a “ConfigParam” class 204 and a “Port” class 211.

  That is, the first metamodel 101a represents that a part can be driven, a part can include a parameter, and a part can include a port for communicating with another part. The port that can be included in the component is specifically an input port corresponding to the “RequesterPort” class 212 or an output port corresponding to the “ProviderPort” class 213.

  Also, the first metamodel 101 a metamodels an interface defined as a collection of several data elements by a “SenderReceiverInterface” class 209 and a “DataElementPrototype” class 210. The fact that the “Port” class 211 refers to the “Interface” class 208 that is a generalization of the “SenderReceiverInterface” class 209 indicates that communication between two ports is performed via some predetermined interface. Modeled.

  In addition, each part may be connected to other parts that are not nested through a port. This is metamodeled by an aggregation 267 that indicates that the “CompositionType” class 202 can include an “AssemblyConnector” class 215.

  Further, the metamodeling that parts can be nested is possible as follows. That is, the “ComponentPrototype” class 203 refers to the “ComponentType” class 201 that generalizes the “CompositionType” class 202 that meta-models the component, and the “ComponentPrototype” class 203 is included in the “CompositionType” class 202. Is indicated by the aggregation 253. Thus, it is metamodeled that a nested relationship in which the internal part is included in the external part is possible.

  And, by connecting between the ports of the external component and the internal component, it is possible to communicate between the external component and the internal component. It is the same.

  That is, the connection between the ports of the external component and the internal component is metamodeled by the “DelegateConnector” class 216. The fact that an external component and an internal component can be connected via a port is metamodeled by an aggregation 268 indicating that the “CompositionType” class 202 can include a “DelegateConnector” class 216.

  Next, a specific example of the model diagram 105 in FIG. 1 when the first meta model 101a in FIG. 2 is used as the meta model 101 in FIG. 1 will be described with reference to FIG. FIG. 3 shows a model diagram 105a according to the first metamodel 101a. Specifically, it is a UML class diagram extended according to the notation rule 102 of the first embodiment. In the following, the extended class diagram and object diagram are also simply referred to as “class diagram” and “object diagram”.

  As will be described later, the model diagram 105 is not limited to a class diagram but may be an object diagram or a sequence diagram. One model may be represented by a plurality of model diagrams 105.

  Model diagram 105a is created as a result of process P101 of FIG. Although details will be described later with reference to FIG. 10, the process P101 is a process in which the UML tool 103 and the DSM support apparatus 104 cooperate to edit a software model in accordance with an instruction from the user under a constraint condition. In the process P101, the UML tool 103 and the DSM support apparatus 104 output the edited model in the form of a model diagram 105 that is UML data and a model 106 that is XML data. That is, the model diagram 105a in FIG. 3 is a class diagram that satisfies the constraint conditions.

  Specifically, the model diagram 105a of FIG. 3 includes a “CompositionType” class 202 and a “SenderReceiverInterface” class 209 included in the first metamodel 101a. In FIG. 3, the first metamodel 101a is included in a package named “metamodel”, and a class name is expressed using a path such as “metamodel :: CompositionType”.

  The model diagram 105a includes two user-defined classes: a “part A” class 301 and an “interface A” class 302. The “component A” class 301 includes two ports 303 and 304 named “reception port” and “transmission port”.

  In the following description, the ports 303 and 304 are referred to as ““ reception port ”port” and ““ transmission port ”port”, respectively. Similarly, an object of a subclass of the “Port” class 211 instantiated with the name “ZZZ” is referred to as ““ ZZZ ”port”.

  In the first embodiment, an object of the “RequesterPort” class 212 in the first metamodel 101a is represented by a symbol in which an inverted V character is written in a rectangle, like a “reception port” port 303 in FIG. . Then, an object of the “ProviderPort” class 213 in the first metamodel 101a is represented by a symbol in which a black triangle is drawn in a rectangle like a “transmission port” port 304 in FIG.

  Further, in the model diagram 105 a, a generalization 305 indicating that the “component A” class 301 is a subclass of the “CompositionType” class 202 is defined. Similarly, in the model diagram 105a, a generalization 306 indicating that the “interface A” class 302 is a subclass of the “SenderReceiverInterface” class 209 is also defined.

  Further, in the model diagram 105 a, a dependency 307 from the “reception port” port 303 to the “interface A” class 302 and a dependency 308 from the “transmission port” port 304 to the “interface A” class 302 are defined.

  The model diagram 105a having the above contents conforms to the first meta model 101a in FIG. 2 and the notation rule 102 in FIG. In other words, the model diagram 105 a is a UML class diagram representing a model created according to the first metamodel 101 a and satisfies the constraint condition represented by the notation rule 102. Specifically, it is as the following (c1) to (c7).

  (C1) The notation rule 102 includes a rule that “a class in which a part is modeled should be indicated as a subclass of the“ CompositionType ”class 202”. The model diagram 105 a is written according to the writing rule 102.

  That is, the fact that the “component A” class 301 is a subclass of the “CompositionType” class 202 is indicated on the class diagram of FIG. As a result, the model diagram 105a indicates the meaning that “the“ component A ”class 301 is a class that models a component (not an interface or the like)”.

  (C2) According to the first metamodel 101a, as shown in FIG. 2, the “ComponentType” class 201 and classes derived therefrom can include the “Port” class 211. Therefore, in the model diagram 105a, the fact that the “component A” class 301 includes the “reception port” port 303 and the “transmission port” port 304 is compatible with the first metamodel 101a of FIG.

  (C3) The notation rule 102 includes a rule that “a class that models an interface should be expressed as a subclass of the“ SenderReceiverInterface ”class 209”. The model diagram 105 a is written according to the writing rule 102.

  That is, the fact that the “interface A” class 302 is a subclass of the “SenderReceiverInterface” class 209 is indicated on the class diagram of FIG. As a result, the model diagram 105a indicates the meaning that “the“ interface A ”class 302 is a class that models an interface (not a component or the like)”.

  (C4) The notation rule 102 includes a rule that “communication between ports via a certain interface should be expressed by dependence on two classes corresponding to the ports at both ends of the communication depending on the class of the same interface”. . The model diagram 105 a is written according to the writing rule 102.

  That is, the input to the “reception port” port 303 of the “component A” class 301 is performed via the interface modeled by the “interface A” class 302, which is represented by the dependency 307 in the model diagram 105a. ing. Similarly, the output from the “transmission port” port 304 of the “component A” class 301 is performed via an interface modeled by the “interface A” class 302, which is represented by the dependency 308 in the model diagram 105a. Has been.

  Accordingly, the inter-instance communication of the “component A” class 301 is performed via the interface modeled by the “interface A” class 302, as represented by the dependencies 307 and 308 in the model diagram 105a. Yes.

  (C5) The notation rule 102 indicates that “the stereotype << ConfigParam >> having the same name as the“ ConfigParam ”class 204 of the first metamodel 101a is added to the attribute defined by the user in the class that models the part. It may include a rule of “may be”. The notation rule 102 relates to the interpretation of the meaning that “the attribute to which the stereotype << ConfigParam >> is added is a parameter that gives a characteristic to the component when the component is used”. Includes rules.

  The model diagram 105a is written according to the notation rule 102. In the “component A” class 301, a stereotype << ConfigParam >> is added to the integer attribute named “parameter” defined by the user. ing. Since the stereotype is not added to the “component A” class 301 itself, the user still has the freedom to add any stereotype to the “component A” class 301.

  (C6) The notation rule 102 is “a stereotype << RunnableEntity >> having the same name as the“ RunnableEntity ”class 205 of the first metamodel 101a for a public operation defined by a user in a class that models a part. May be added ".

  The notation rule 102 is a rule regarding interpretation of meaning that “the operation with the stereotype << RunnableEntity >> added is a public operation that can be called from an external task to drive the component”. Including. Specifically, according to the notation rule 102, an operation to which the stereotype << RunnableEntity >> is added is interpreted as an instance of the “RunnableEntity” class 205.

  The model diagram 105a is written in accordance with the notation rule 102. In the “component A” class 301, a function named “execution point” defined by the user and having no return value is stereo with << RunnableEntity >>. A type is added. Since the stereotype is not added to the “component A” class 301 itself, the user still has the freedom to add any stereotype to the “component A” class 301.

(C7) According to the first metamodel 101a, the “SenderReceiverInterface” class 209 can include the “DataElementPrototype” class 210 as shown in FIG.
Therefore, in the model diagram 105a, the fact that the “interface A” class 302, which is a subclass of the “SenderReceiverInterface” class 209, includes two data elements as attributes is compatible with the first meta model 101a. That is, two integer type attributes named “element 1” and “element 2” defined as attributes of the “interface A” class 302 are obtained by instantiating the “DataElementPrototype” class 210 in the meta model in the model. Is.

  As described above (c1) to (c7), the notation rule 102 defines the notation grammar (syntax) in the model diagram 105 according to the metamodel 101. Further, the metamodel 101 and the notation rule 102 also define the meaning (semantics) of the UML diagram expressed according to the grammar.

  In the process P101 of FIG. 1, the UML tool 103 and the DSM support apparatus 104 cooperate to create the model diagram 105 so as to meet the constraints as described in the above (c1) to (c7). . Hereinafter, the UML tool 103, the DSM support device 104, and the code generation device 108 will be described in more detail with reference to FIG.

  FIG. 4 is a block diagram showing the DSM support device and other devices according to the first embodiment. FIG. 4 shows the UML tool 103, the DSM support device 104, the code generation device 108, and other devices shown in FIG.

  In FIG. 4, an input device 401 is a device for receiving input from a user, such as a keyboard, a pointing device such as a mouse, a touch panel, a microphone, and the like. The output device 402 is a device such as a display for displaying various UML diagrams (class diagram, object diagram, sequence diagram, etc.) and a printer for printing these diagrams.

  The UML tool 103 is realized by executing a program by a computer connected to the input device 401 and the output device 402 (or including the input device 401 and the output device 402).

  Specifically, the UML tool 103 provides a user interface between the input device 401 and the output device 402. The UML tool 103 then outputs various UML diagrams (class diagram, object diagram, sequence diagram, etc.) to the output device 402 in accordance with instructions given from the user via the input device 401 and the user interface. The UML tool 103 may be an editor similar to that described in (a2) above, for example.

  Further, the DSM support apparatus 104 in the first embodiment is specifically realized by a computer executing a program. In the first embodiment, the program that implements the DSM support apparatus 104 is an add-on program to the program that implements the UML tool 103. Of course, depending on the embodiment, the UML tool 103 and the DSM support apparatus 104 may be integrated into one by executing a program that realizes the functions of the UML tool 103 and the DSM support apparatus 104 together.

  Specifically, the DSM support apparatus 104 includes a model creation navigation unit 403 as shown in FIG. The model creation navigation unit 403 restricts the operation of the UML tool 103 based on the meta model 101 and the notation rule 102.

  Specifically, the model creation navigation unit 403 includes a menu selection unit 404, a component menu providing unit 405, a port menu providing unit 406, an interface menu providing unit 407, an internal component menu providing unit 408, and a task menu providing. Part 409. The DSM support apparatus 104 further includes a model creation unit 410 that creates the model 106 in FIG. 1 in a predetermined language such as XML.

  In the first embodiment, the notation rule 102 in FIG. 1 is incorporated as a control logic in each component in the DSM support apparatus 104. Details of the operation of the DSM support device 104 will be described later with reference to FIGS.

  Further, for example, a storage device 411 such as a hard disk device or a RAM (Random Access Memory) is provided. The storage device 411 includes a model diagram storage unit 412, a semantic model storage unit 413, a template storage unit 414, a source code storage unit 415, and a metamodel storage unit 416.

  The model diagram storage unit 412 stores the model diagram 105 of FIG. 1 (specific example is, for example, the model diagram 105a of FIG. 3) written in UML and created / edited in the process P101 of FIG. The semantic model storage unit 413 stores the model 106 in FIG. 1 (specific examples are, for example, the models 106a in FIGS. 9A to 9D) that are created and edited in the process P101 and express the meaning of the model diagram 105 in XML.

  The template storage unit 414 stores the code generation template 107 of FIG. 1 that is expressed in XSL and prepared in advance. The source code storage unit 415 stores the source code 109 of a programming language such as C ++ or Java (registered trademark) generated in the process P102 of FIG.

The metamodel storage unit 416 stores the metamodel 101 of FIG. 1 (specific example is, for example, the first metamodel 101a of FIG. 2) prepared in advance in UML.
The operation of each unit described above will be described in detail with reference to FIGS. 10 to 12, but the outline is as follows.

  The model creation navigation unit 403 provides various menus for modeling software while satisfying the constraint conditions according to the meta model 101 and the notation rule 102. Specifically, the model creation navigation unit 403 monitors the UML tool 103 in order to restrict the operation of the UML tool 103.

  Then, when the input device 401 passes the input from the user to the UML tool 103, the model creation navigation unit 403 calls an appropriate internal component according to the content of the input to perform processing. Further, the model creation navigation unit 403 instructs the model creation unit 410 to create or edit the model 106 based on the processing result, and the model creation unit 410 creates or edits the model 106.

  Specifically, the model creation navigation unit 403 provides menus for modeling all parts, ports, interfaces, internal parts, and tasks, and a menu selection user interface. If the input received by the UML tool 103 is an input for menu selection, in the model creation navigation unit 403, the menu selection unit 404 calls a component corresponding to the selected menu.

  Note that the model creation navigation unit 403 may further provide other menus other than the above, such as a menu for driving order definition processing in FIG. 11 to be described later. However, in FIG. The components related to the menu are not shown.

  When the UML tool 103 receives an input for selecting a menu for modeling a part, the menu selection unit 404 calls the part menu providing unit 405. When the UML tool 103 receives an input for selecting a menu for port modeling, the menu selection unit 404 calls the port menu provision unit 406.

  Similarly, when the UML tool 103 receives an input for selecting a menu for modeling an interface, the menu selection unit 404 calls the interface menu provision unit 407. When the UML tool 103 receives an input for selecting a menu for modeling the internal part, the menu selection unit 404 calls the internal part menu providing unit 408. When the UML tool 103 receives an input for selecting a menu for task modeling, the menu selection unit 404 calls the task menu provision unit 409.

  When the UML tool 103 receives an input for detailed setting in each menu after each menu is selected, the model creation navigation unit 403 passes the input content to the component corresponding to the menu.

  For example, after the menu for a part is selected, when the UML tool 103 receives an input for creating a new class that models the part, the model creation navigation unit 403 hooks the input and provides the menu for the part. Part 405. Then, the parts menu providing unit 405 creates a new class according to the input.

  At that time, the component menu providing unit 405 reads the meta model 101 of FIG. 1 which is expressed in UML and stored in the meta model storage unit 416. Then, the component menu providing unit 405 models the component while applying restrictions according to the notation rule 102 of FIG. 1 incorporated in the component menu providing unit 405 itself as control logic and the read metamodel 101. Create a new class.

  Information on the newly created class is notified from the model creation navigation unit 403 including the part menu providing unit 405 to the UML tool 103. Then, the UML tool 103 causes the output device 402 to output a graphic representing the newly created class based on the notified information. For example, the UML tool 103 draws a rectangle indicating the newly created class on the display and instructs the output device 402 to draw the line of the generalization 305 in FIG. 3 on the display.

  Information on the newly created class is also notified to the model creation unit 410. Then, the model creation unit 410 edits the model 106 as needed by generating an XML code corresponding to the newly created class based on the notified information.

The operation related to the part menu providing unit 405 has been described above by taking the part modeling menu as an example, but the same applies to other menus.
That is, an input from the input device 401 is input to the model creation navigation unit 403 via the UML tool 103. Then, under the control of the component for each menu, information about the UML graphic is returned to the UML tool 103, and the UML tool 103 outputs the graphic to the output device 402, and the model 106 representing the meaning corresponding to the UML graphic is the model. Edited by the creation unit 410.

  As described above, the model is created and edited based on the input via the input device 401 and the UML tool 103. That is, the entire model is edited by appropriately creating or editing components, ports, interfaces, internal components, tasks, and the like.

  The model diagram 105 finally obtained as a result is stored in the model diagram storage unit 412 via the UML tool 103. Similarly, the model 106 finally obtained is output from the model creation unit 410 to the semantic model storage unit 413 and stored.

  Then, as shown in process P102 of FIG. 1, the code generation device 108 reads the model 106 from the semantic model storage unit 413, reads the code generation template 107 from the template storage unit 414, and generates the source code 109. The code generation device 108 stores the generated source code 109 in the source code storage unit 415.

  Therefore, if a meta model 101 incorporating domain-specific items is created in advance, it is possible to create a model by DSM using UML via the UML tool 103 under the application of the constraints by the DSM support device 104. It becomes. The source code 109 is automatically generated from the model 106 that is semantically equivalent to the model diagram 105 under the interpretation according to the meta model 101 and the notation rule 102.

  Therefore, according to the first embodiment, it is possible to overcome the disadvantages (b1) to (b5) in the design by DSM while taking advantage of the above (a1) to (a3) when using UML. it can.

  In addition, as described with reference to FIG. 3, in the first embodiment, the meaning of rectangles and lines in the model diagram 105 is automatically determined from a generalization relationship, for example, without adding a stereotype to a user-defined class. Can be interpreted. Therefore, the first embodiment also has an advantage that the degree of freedom of design is large compared to the comparative example.

  Incidentally, the hardware for realizing each block shown in FIG. 4 may be, for example, that shown in FIG. For example, the UML tool 103, the DSM support device 104, and the code generation device 108 in FIG. 4 may be realized by one computer, and the input device 401, the output device 402, and the storage device 411 are provided in the computer. Also good. FIG. 5 shows an example of such a case.

  FIG. 5 is a configuration diagram of the computer. A computer 500 in FIG. 5 includes a CPU (Central Processing Unit) 501, a ROM (Read Only Memory) 502, a RAM 503, and a communication interface 504. The computer 500 includes the input device 401 and the output device 402 shown in FIG. The computer 500 further includes a hard disk device 505 and a drive device 507 for a computer-readable portable storage medium 506.

  Depending on the embodiment, the computer 500 may include a nonvolatile semiconductor memory device such as a flash memory in place of the magnetic storage device such as the hard disk device 505 or together with the hard disk device 505. As the portable storage medium 506, for example, an optical disk such as a CD (Compact Disc) or a DVD (Digital Versatile Disk), a semiconductor memory card such as a magneto-optical disk, a magnetic disk, or a flash memory can be used.

  The CPU 501, ROM 502, RAM 503, communication interface 504, input device 401, output device 402, hard disk device 505, and drive device 507 are connected by a bus 508. The computer 500 is connected to the network 509 via the communication interface 504.

  The network 509 is an arbitrary network such as a LAN (Local Area Network) or the Internet. A computer of the program provider 510 may be connected to the network 509.

  All of the UML tool 103, the DSM support device 104, and the code generation device 108 in FIG. 4 are realized by the CPU 501 loading the program into the RAM 503 and executing the program while using the RAM 503 as a work area.

  Each program for realizing the UML tool 103, the DSM support device 104, and the code generation device 108 may be stored in the ROM 502 or the hard disk device 505 in advance. Alternatively, each program may be stored in the portable storage medium 506 and once read from the portable storage medium 506 set in the drive device 507 to the hard disk device 505. Alternatively, each program may be provided from the program provider 510 and downloaded to the computer 500 via the network 509 and the communication interface 504.

  Also, the storage device 411 of FIG. 4 is realized by arbitrarily combining one or more of the ROM 502, RAM 503, hard disk device 505, non-illustrated nonvolatile semiconductor memory device and portable storage medium 506 described above. Can do.

  Note that FIG. 5 is merely an example of a hardware configuration, and the UML tool 103, the DSM support device 104, and the code generation device 108 may be distributed over a plurality of computers depending on the embodiment.

Next, the first embodiment described above will be described in more detail with reference to FIGS.
FIG. 6 is a UML class diagram representing a second model according to the first metamodel. From the first metamodel 101a in FIG. 2, in addition to the model diagram 105a in FIG. 3, for example, a class diagram representing a model that defines nested parts is created as in the model diagram 105b in FIG. You can also. That is, in the process P101 of FIG. 1, the second metamodel 101b of FIG. 6 may be created as a model diagram 105 that satisfies the constraint conditions defined by the first metamodel 101a and the notation rule 102.

  Similar to the model diagram 105a of FIG. 3, the model diagram 105b includes a “CompositionType” class 202 and a “SenderReceiverInterface” class 209 included in the first metamodel 101a. The second metamodel 101b includes an “interface A” class 302 as in the model diagram 105a. As in FIG. 3, the generalization 306 line also indicates that the “interface A” class 302 is a subclass of the “SenderReceiverInterface” class 209 in FIG. 6.

  Further, the model diagram 105 b includes a user-defined “part B” class 601. The “part B” class 601 includes two objects of the “part A” class 301 defined in the model diagram 105 a of FIG. 3, that is, a “P1” object 602 and a “P2” object 603. The “component B” class 601 includes an “input 1” port 604 and an “output 1” port 605.

  Since the “input 1” port 604 is an object of the “RequesterPort” class 212 in the first metamodel 101a, it is represented by a symbol in which an inverted V character is written in a rectangle. Since the “output 1” port 605 is an object of the “ProviderPort” class 213 in the first metamodel 101a, it is represented by a symbol depicting a black triangle in the rectangle.

  As shown in FIG. 3, since the “component A” class 301 includes two ports, the “P1” object 602 and the “P2” object 603 in FIG. 6 which are instances of the “component A” class 301 also have two ports, respectively. including. That is, the “P1” object 602 includes a “reception port” port 606 and a “transmission port” port 607, and the “P2” object 603 includes a “reception port” port 608 and a “transmission port” port 609.

  In the model diagram 105 b, a generalization 610 is defined that indicates that the “component B” class 601 is a subclass of the “CompositionType” class 202. By the generalization 610, the meaning that the “component B” class 601 is a class in which a component is modeled instead of an interface or the like is represented on the model diagram 105b.

  In the model diagram 105b, a link 611 between the “input 1” port 604 and the “reception port” port 606 is defined. Further, a link 612 between the “transmission port” port 607 and the “reception port” port 608 and a link 613 between the “transmission port” port 609 and the “output 1” port 605 are also defined.

  In the model diagram 105b, a dependency 614 from the “input 1” port 604 to the “interface A” class 302 and a dependency 615 from the “output 1” port 605 to the “interface A” class 302 are also defined.

  The model diagram 105b having the above contents conforms to the first metamodel 101a in FIG. 2 and the notation rule 102 in FIG. In other words, the model diagram 105b is a UML class diagram representing a model created according to the first metamodel 101a, and satisfies the constraint condition represented by the notation rule 102. Specifically, it is as the following (d1) to (d8).

  (D1) Similar to (c1) with respect to FIG. 3, in the model diagram 105b, the generalization 610 indicates that “the“ part B ”class 601 is a class that models a part”.

  (D2) As in (c2) with respect to FIG. 3, in the model diagram 105b, the “component B” class 601 includes the “input 1” port 604 and the “output 1” port 605. Compatible with model 101a.

  (D3) As in (c3) with respect to FIG. 3, the generalization 306 indicates that “the“ interface A ”class 302 is a class that models an interface”.

  (D4) As in (c4) with respect to FIG. 3, input to the “input 1” port 604 of the “component B” class 601 is performed via an interface modeled by the “interface A” class 302. Is represented by dependency 614. The dependency 615 indicates that the output from the “output 1” port 605 of the “component B” class 601 is performed via an interface modeled by the “interface A” class 302.

  (D5) As in (c6) with respect to FIG. 3, in the “component B” class 601, a function defined by the user named “execution point” and having no return value has a stereotype << RunnableEntity >>. Is added.

  (D6) The notation rule 102 includes a rule that “communication between an external part and an internal part in a nesting relationship should be indicated by a link between two objects indicating ports of the external part and the internal part”. More precisely, the notation rule 102 states that “the link for notifying communication between an external component and an internal component is only a link between instances of“ RequesterPort ”class 212 or between instances of“ ProviderPort ”class 213. Is included.

  Further, the notation rule 102 is that “the link between the two objects indicating the ports of the external part and the internal part is an instance of the“ DelegateConnector ”class 216 in the first metamodel 101a, and the link between the external part and the internal part. It also includes a rule regarding interpretation of meaning “meaning communication”.

  A link 611 in the model diagram 105b is a link connecting an “input 1” port 604 indicating a port of an external component and a “reception port” port 606 indicating a port of an internal component. The “input 1” port 604 and the “reception port” port 606 are both instances of the “RequesterPort” class 212. Therefore, the link 611 conforms to the notation rule 102.

  A link 613 in the model diagram 105b is a link connecting an “output 1” port 605 indicating a port of an external component and a “transmission port” port 609 indicating a port of an internal component. The “output 1” port 605 and the “transmission port” port 609 are both instances of the “ProviderPort” class 213. Therefore, the link 613 meets the notation rule 102.

  The model creation unit 410 in FIG. 4 interprets according to the notation rule 102 as “link 611 and link 613 are instances of“ DelegateConnector ”class 216 and mean communication between an external component and an internal component”. To do.

  (D7) The notation rule 102 indicates that “communication between two parts that are not nested is between the“ ProviderPort ”class 213 object of one part and the“ RequesterPort ”class 212 object of the other part. Include a rule that says “Use a link for”. In addition, the notation rule 102 interprets the link as described above to mean “an instance of the“ AssemblyConnector ”class 215 in the first metamodel 101a and means communication between two components that are not nested”. Includes rules to do.

  A link 612 in the model diagram 105b is a link between the “P1” object 602 and the “P2” object 603 which are not nested. More precisely, the link 612 is a link between a “sending port” port 607 included in the “P1” object 602 and a “receiving port” port 608 included in the “P2” object 603. That is, the link 612 is a link between the “ProviderPort” class 213 object included in the “P1” object 602 and the “RequesterPort” class 212 object included in the “P2” object 603. Therefore, the link 612 conforms to the notation rule 102.

  Then, the model creation unit 410 of FIG. 4 interprets according to the notation rule 102 as “link 612 is an instance of the“ AssemblyConnector ”class 215 and means communication between two components that are not nested”.

  (D8) The notation rule 102 is: “The link between ports for indicating communication between components must have a dependency relationship between the output source port and the output destination port for the same interface class. Is included. Depending on the embodiment, a rule that “the output destination port must have a dependency relationship with respect to the first interface class on which the output source port depends or the second interface class that is a subclass thereof”. May be included in the notation rule 102.

  In the model diagram 105b, a “P1” object 602 and a “P2” object 603 are both instances of the “part A” class 301 defined in FIG. Therefore, both the input to the “reception port” port 606 and the output from the “transmission port” port 607 are based on the interface defined by the “interface A” class 302 as defined in FIG. Similarly, the input to the “reception port” port 608 and the output from the “transmission port” port 609 are also based on the interface defined by the “interface A” class 302.

  Further, as defined in FIG. 6, the input to the “input 1” port 604 of the “component B” class 601 and the output from the “output 1” port 605 of the “component B” class 601 are also “interface”. A ”is based on the interface defined by the class 302.

  As described above, in any of the links 611, 612, and 613, the output source port and the output destination port have a dependency relationship with respect to the same interface class. Accordingly, all of the links 611, 612, and 613 meet the notation rule 102.

  In the process P101 of FIG. 1, the UML tool 103 and the DSM support apparatus 104 cooperate to create the model diagram 105b so as to satisfy the constraint conditions described in the above (d1) to (d8).

  For example, the UML tool 103 inputs an input to create a link between a “transmission port” port 607 and a “transmission port” port 609, which are instances of the same “ProviderPort” class 213, via the input device 401 in FIG. If received, the input is invalidated. That is, an input that attempts to create a link that does not conform to the notation rule 102 in (d7) is determined as “illegal input” by the DSM support apparatus 104 and is not reflected in the UML diagram. In this case, the DSM support device 104 may output a warning to the output device 402 via the UML tool 103 that “the input content is not reflected in the UML diagram because it is an illegal input”.

Next, another example of the model diagram 105 in FIG. 1 will be described with reference to FIG.
FIG. 7 is a UML object diagram showing the overall structure of software designed by a model in which the first and second models are integrated. That is, FIG. 7 represents a model diagram 105c according to the first metamodel 101a in the form of an object diagram based on a model obtained by integrating the model diagram 105a of FIG. 2 and the model diagram 105b of FIG.

The model diagram 105a includes the “CompositionType” class 202 included in the first metamodel 101a, similar to the model diagram 105a of FIG.
The model diagram 105a includes an “entire software” class 701 to which a stereotype << TopLevel >> is added. The “whole software” class 701 is a special class corresponding to the highest-level main routine of software having only one instance per software.

  Therefore, even if the stereotype << TopLevel >> is added to the “whole software” class 701, the user can still freely add a stereotype to each class included in the “whole software” class 701. Is possible. In other words, adding the stereotype << TopLevel >> to the “whole software” class 701 does not constrain the freedom of design as in the comparative example.

  The “whole software” class 701 includes a “PART1” object 702 that is an instance of the “part A” class 301 defined in the model diagram 105a of FIG. The “whole software” class 701 also includes a “PART2” object 703 that is an instance of the “part B” class 601 defined in the model diagram 105b of FIG. As shown in FIG. 6, the “part B” class 601 includes two instances of the “part A” class 301, so that the “whole software” class 701 includes a total of three instances of the “part A” class 301. Become.

  The “whole software” class 701 includes a “T1” object 704 that is an instance of the “Task” class 206 defined in the first metamodel 101a. The “T1” object 704 is an object of a class defined in the first metamodel 101a.

  Further, the “PART1” object 702 which is an instance of the “component A” class 301 has two ports (ie, “receive port” port 705 and “transmit port” port) as defined in the “component A” class 301 in FIG. 706). Then, the “PART2” object 703 which is an instance of the “component B” class 601 has two ports (ie, “input 1” port 707 and “output 1” port as defined in the “component B” class 601 in FIG. 6). 708).

  The fact that the “whole software” class 701 is a software component is represented by the generalization 709 from the “whole software” class 701 to the “CompositionType” class 202.

  The communication between the “PART1” object 702 and the “PART2” object 703 in the “whole software” class 701 is represented by a link 710 between the “transmission port” port 706 and the “input 1” port 707. Yes. As is clear from the definitions of FIGS. 3 and 6, the link 710 conforms to the notation rule 102 of (d7) and (d8) described with reference to FIG.

  That is, the DSM support apparatus 104 of FIG. 4 allows the creation of the link 710 that conforms to the notation rule 102 by restricting the input for the instruction to create the link, and does not conform to the notation rule 102. Reject link creation. As a result, a model diagram 105c conforming to the notation rule 102 is created.

Next, still another example of the model diagram 105 in FIG. 1 will be described with reference to FIG.
FIG. 8 is a UML sequence diagram that defines software operations corresponding to the object diagram of FIG. The UML diagram edited by the process P101 in FIG. 1 in cooperation with the UML tool 103 and the DSM support device 104 includes a sequence diagram such as a model diagram 105d in FIG.

  In FIG. 8, the broken lines indicating the lifelines of the “T1” object 704, the “PART1” object 702 and the “PART2” object 703 in FIG. 7 and the activation periods 801, 802 and 803 are defined. Yes.

  8 also defines a call 804 indicating that the “T1” object 704 calls the “PART1” object 702 at the beginning of the activation period 801 of the “T1” object 704. Then, a call 805 indicating that the “T1” object 704 calls the “PART2” object 703 is also defined. In other words, the model diagram 105 d defines a driving order in which the “PART1” object 702 is driven first and the “PART2” object 703 is driven later.

  The label of the call 804 indicates the operation “execution point” defined with the stereotype << RunnableEntity >> in the “component A” class 301 of FIG. The label of the call 805 indicates an operation “execution point” defined with a stereotype << RunnableEntity >> in the “component B” class 601 of FIG. The reason why the labels of the calls 804 and 805 are the same is because an operation with the same name is defined in the “component A” class 301 and the “component B” class 601 by chance.

The notation rule 102 as a constraint condition applied by the DSM support apparatus 104 in creating the model diagram 105d of FIG. 8 is, for example, the following rules (e1) to (e2).
(E1) The notation rule 102 is “in the sequence diagram, the call source of the arrow indicating the call must be an operation defined in the instance of the“ Task ”class 206 or the component class in the first metamodel 101a” Including the rule.

  In FIG. 8, the caller of the calls 804 and 805 is a “T1” object 704 that is an instance of the “Task” class 206. Therefore, the model diagram 105d in FIG.

  (E2) The notation rule 102 is a rule that in the sequence diagram, the label of the call must be the name of an operation to which the stereotype << RunnableEntity >> indicating that the call can be made from outside is added. including.

  As described above, the two “execution points” that are labels of the calls 804 and 805 are the names of operations to which the stereotype << RunnableEntity >> is added in the definitions of FIGS. Therefore, the model diagram 105d in FIG.

  In the process P101 of FIG. 1, the UML tool 103 and the DSM support apparatus 104 cooperate to create a model diagram 105d so as to satisfy the constraint conditions described in (e1) to (e2) above.

  For example, in the model diagram 105a of FIG. 3, it is assumed that another operation is defined in the “part A” class 301 and the name of the operation is “processing a” for convenience. Further, it is assumed that the stereotype << RunnableEntity >> is not added to the operation “processing a”.

  Based on the above assumptions, it is assumed that the DSM support apparatus 104 receives an input for specifying “processing a” as the label of the call 804 via the input apparatus 401 and the UML tool 103. Then, the model creation navigation unit 403 detects that the input violates the constraint (e2). In response to the detection of the constraint violation, for example, the model creation navigation unit 403 may display a warning “Please specify another label because it is an illegal input” on the output device 402 via the UML tool 103.

Next, an example of the model 106 in FIG. 1 will be described with reference to FIGS.
9A to 9D are diagrams showing XML data corresponding to a model obtained by integrating the first and second models. Although it is divided into four figures for convenience of illustration, the whole of FIGS. 9A to 9D is one XML document representing a model in which FIGS. 3 and 6 to 8 are integrated, as shown in FIGS. 9A to 9D. The model 106a is an example of the model 106 in FIG.

  As described above, the UML model diagram 105 (for example, FIGS. 3 and 6 to 8) covering a plurality of sheets represents one software model as a whole, and corresponds to one model 106 (for example, FIGS. 9A to 9D). Good. For convenience of reference, row numbers are shown on the left side in FIGS.

  In the model 106a, an arbitrary element name can be used in association with each class of the first metamodel 101a according to the embodiment. In the following, element names ending with “-REF” represent references.

The model 106a shown in FIGS. 9A to 9D specifically has the contents described in the following (f1) to (f35).
(F1) The root element of the model 106a is a “PACKAGE” element (1st to 86th lines). As shown in the first line, the “PACKAGE” element has a “Name” attribute indicating the name “test” and a “TopLevelPackage” attribute indicating the top element.

  The “PACKAGE” element has four child elements. The first three child elements are “COMPOSITION-TYPE” elements corresponding to the “CompositionType” class 202 of the first metamodel 101a of FIG. The fourth child element is a “SENDER-RECEIVER-INTERFACE” element corresponding to the “SenderReceiverInterface” class 209 of the first metamodel 101a.

  (F2) Of the child elements of the “PACKAGE” element, the first “COMPOSITION-TYPE” element hits lines 2 to 28 and is defined as a subclass of the “CompositionType” class 202 in “Whole Software” in FIG. Class 701 is represented. Therefore, on the second line, the class name of the “whole software” class 701 is specified as the value of the “Name” attribute of the “COMPOSITION-TYPE” element. Further, since the stereotype << TopLevel >> is added to the “whole software” class 701, the value of the “TopLevel” attribute of the “COMPOSITION-TYPE” element is “True” in the second line. .

  4 represents the “whole software” class 701 as a “COMPOSITION-TYPE” element in the model 106a based on the generalization 709 in FIG. 7 in the process P101 in FIG. Further, the model creation unit 410 sets the “TopLevel” attribute of the “COMPOSITION-TYPE” element based on the stereotype << TopLevel >> of FIG. As a result, the model creation unit 410 represents on the model 106a the meaning that “the“ whole software ”class 701 represents the highest component”.

  (F3) Of the child elements of the “PACKAGE” element, the second “COMPOSITION-TYPE” element hits lines 29 to 44 and is defined as a “component A” in FIG. 3 defined as a subclass of the “CompositionType” class 202. Class 301 is represented. Therefore, on the 29th line, the class name of the “component A” class 301 is specified as the value of the “Name” attribute of the “COMPOSITION-TYPE” element.

  Similar to (f2) above, the model creation unit 410 expresses the “component A” class 301 as a “COMPOSITION-TYPE” element in the model 106a based on the generalization 305 in FIG. The meaning of “class 301 represents a part” is expressed on the model 106a.

  (F4) Among the child elements of the “PACKAGE” element, the third “COMPOSITION-TYPE” element hits the 45th to 74th lines and is defined as a “class B” in FIG. Class 601 is represented. Therefore, in the 45th line, the class name of the “component B” class 601 is specified as the value of the “Name” attribute of the “COMPOSITION-TYPE” element.

  Similar to (f2) above, the model creation unit 410 expresses the “component B” class 601 as a “COMPOSITION-TYPE” element in the model 106a based on the generalization 610 in FIG. The meaning of “class 601 represents a part” is expressed on the model 106a.

  (F5) The “SENDER-RECEIVER-INTERFACE” element, which is the fourth child element of the “PACKAGE” element, hits the 75th to 85th lines and is defined as a subclass of the “SenderReceiverInterface” class 209 in FIG. 3 and FIG. A "represents class 302. Therefore, in the 75th line, the class name of the “Interface A” class 302 is specified as the value of the “Name” attribute of the “SENDER-RECEIVER-INTERFACE” element.

  Similar to (f2) above, the model creation unit 410 represents the “interface A” class 302 as a “SENDER-RECEIVER-INTERFACE” element in the model 106a based on the generalization 306 in FIG. 3 and FIG. As a result, the model creation unit 410 represents on the model 106 a the meaning that “the“ interface A ”class 302 represents an interface”.

(F6) The “COMPOSITION-TYPE” element (line 2 to 28) of (f2) has five child elements.
The first child element is an empty “SUPER-ELEMENT” element shown in the third line. By being empty, the “whole software” class 701 in FIG. 7 is directly derived from the “CompositionType” class 202. Represents. The second and third child elements are two “COMPONENT-PROTOTYPE” elements (lines 4-6 and 7-9) corresponding to the “ComponentPrototype” class 203 of the first metamodel 101a.

  The fourth child element is an “ASSEMBLY-CONNECTOR” element (10th to 13th lines) corresponding to the “AssemblyConnector” class 215 of the first metamodel 101a. The fifth child element is a “TASK” element (14th to 27th lines) corresponding to the “Task” class 206 of the first metamodel 101a.

  (F7) In the first metamodel 101a, the aggregation 253 indicates that the “CompositionType” class 202 can include the “ComponentPrototype” class 203. The model diagram 105c in FIG. 7 is described according to the first metamodel 101a and the notation rule 102, and the “whole software” class 701 includes a “PART1” object 702 and a “PART2” object 703.

  Corresponding to the above structure, in the model 106a, the “COMPOSITION-TYPE” element (line 2 to 28) of (f2) corresponding to the “whole software” class 701 corresponds to two “ It has “COMPONENT-PROTOTYPE” elements (lines 4-6 and 7-9) as child elements.

  (F8) Since the first “COMPONENT-PROTOTYPE” element (lines 4 to 6) described in (f6) and (f7) above corresponds to the “PART1” object 702, the “COMPONENT-PROTOTYPE” element In the “Name” attribute, “PART1” that is an object name is designated (line 4).

  The association 252 of the first metamodel 101 a indicates that the “ComponentPrototype” class 203 refers to the “ComponentType” class 201. Therefore, in the model 106 a representing the meaning of the model diagram 105 c expressed according to the first meta model 101 a and the notation rule 102, the “COMPONENT-TYPE-REF” element indicating the reference to the “ComponentType” class 201 is changed to “COMPONENT”. -PROTOTYPE "element. Specifically, the “COMPONENT-PROTOTYPE” element in the 4th to 6th lines includes the “COMPONENT-TYPE-REF” element shown in the 5th line.

  (F9) The “COMPONENT-TYPE-REF” element on the fifth line contains information indicating the class of the “PART1” object 702 represented by the parent “COMPONENT-PROTOTYPE” element (lines 4 to 6). Including.

  The “PART1” object 702 belongs to the “component A” class 301, the “component A” class 301 is a subclass of the “CompositionType” class 202, and the “CompositionType” class 202 is a subclass of the “ComponentType” class 201. Therefore, the “PART1” object 702 class corresponding to the “COMPONENT-PROTOTYPE” element (lines 4 to 6) on the model 106a by the “COMPONENT-TYPE-REF” element indicating the reference to the “ComponentType” class 201 Can be shown.

  Specifically, the “COMPONENT-TYPE-REF” element on the 5th line contains the package name (value of the “Name” attribute on the 1st line) and the class name (“29th line”), “/ test / part A”. The class of the “PART1” object 702 is indicated by a path in which the “Name” attribute value) is combined with a slash. The path starts with a slash because it is an absolute path.

  (F10) Since the second “COMPONENT-PROTOTYPE” element (lines 7 to 9) described in (f6) and (f7) above corresponds to the “PART2” object 703, the “COMPONENT-PROTOTYPE” element In the “Name” attribute, “PART2” that is an object name is designated (seventh line). Similarly to the above (f8), the “COMPONENT-PROTOTYPE” element in the 7th to 9th lines includes the “COMPONENT-TYPE-REF” element shown in the 8th line.

  Also, the “COMPONENT-TYPE-REF” element on the eighth line includes information indicating the class of the “PART2” object 703 as the content, as in (f9) above. That is, the path “/ test / part B” obtained by combining the package name (value of the “Name” attribute on the first line) and the class name (value of the “Name” attribute on the 45th line) is changed to “ The "COMPONENT-TYPE-REF" element contains as content.

  (F11) In the first metamodel 101a, from the “AssemblyConnector” class 215, there are two lines, a relation 269 and a relation 270, which indicate a reference to the “Port” class 211. Therefore, the “ASSEMBLY-CONNECTOR” element (line 10 to 13) corresponding to the “AssemblyConnector” class 215 described in (f6) above has two child elements (line 11 and line) corresponding to the relation 269 and relation 270. 12th line).

  The link 710 in FIG. 7 conforms to the notation rule 102 of (d7) and (d8) above. According to (d7) above, both ends of the link as an instance of the “AssemblyConnector” class 215 are objects of the “ProviderPort” class 213 and the “RequesterPort” class 212. Therefore, the two child elements of the “ASSEMBLY-CONNECTOR” element (10th to 13th lines) are “PROVIDER-PORT-REF” elements (11 that indicate references to the “ProviderPort” class 213 and the “RequesterPort” class 212, respectively. Line) and "REQUESTER-PORT-REF" element (line 12).

  That is, the “ASSEMBLY-CONNECTOR” element on the 10th to 13th lines is between the “transmission port” port 706 that is an object of the “ProviderPort” class 213 and the “input 1” port 707 that is an object of the “RequesterPort” class 212. The link 710 is shown. Then, two child elements of “PROVIDER-PORT-REF” element (11th line) and “REQUESTER-PORT-REF” element (12th line) indicate the ports at both ends of the link 710. As shown in the 10th line, the name “asmConn_1” (not shown in FIG. 7) assigned to the link 710 is specified in the “Name” attribute of the “ASSEMBLY-CONNECTOR” element.

  (F12) The “PROVIDER-PORT-REF” element (line 11) described in (f11) above includes information indicating the definition of the “transmission port” port 706 that is the output source of the communication represented by the link 710. Specifically, the “PROVIDER-PORT-REF” element in the eleventh line is added to the definition of the “transmission port” port 706 by the path “/ test / component A / transmission port”, as in (f9) above. Indicates a reference. This path includes the package name (value of the “Name” attribute on the first line), the class name (value of the “Name” attribute on the 29th line), and the port name defined in the class (“Name” on the 41st line). Attribute values) combined with a slash.

  (F13) The “REQUESTER-PORT-REF” element (line 12) described in (f11) above is the definition of the “input 1” port 707 that is the output destination of the communication represented by the link 710, as in (f12) above. The path includes “/ test / part B / input 1” indicating “”. This path consists of the package name (value of the “Name” attribute on the first line), the class name (value of the “Name” attribute on the 45th line), and the port name defined in the class (“Name” on the 55th line). Attribute values) combined with a slash.

  (F14) The “TASK” element (lines 14 to 27) described in (f6) above represents the “T1” object 704 in FIG. 7 which is an instance of the “Task” class 206 of the first metamodel 101a. Therefore, as shown in the 14th line, the name “T1” of the “T1” object 704 is specified in the “Name” attribute of the “TASK” element. Then, corresponding to the two calls 804 and 805 shown in FIG. 8, the “TASK” element (14th to 27th lines) has two child elements.

  (F15) The first child element of the “TASK” element corresponds to the call 804 to the “PART1” object 702 that is an object of the “part A” class 301. Specifically, what is called by the call 804 is defined as an operation of the “component A” class 301 in the model diagram 105a of FIG. 3 and is called “run point” with a stereotype << RunnableEntity >> added. Name function.

  Here, the function to which the stereotype << RunnableEntity >> is added is interpreted by the model creation unit 410 as an instance of the “RunnableEntity” class 205 based on the notation rule 102 in (c6) above. That is, the call 804 to the function named “execution point” from the “T1” object 704 of the “Task” class 206 corresponds to the “RunnableConnector” class 207 according to the first metamodel 101a of FIG.

  Therefore, the “TASK” element (14th to 27th lines) is specifically the “RUNNABLE-ENTITY-CONNECTOR” element (15 to 20) corresponding to the “RunnableConnector” class 207 as the first child element corresponding to the call 804. Line). In the “Name” attribute of the “RUNNABLE-ENTITY-CONNECTOR” element on the 15th to 20th lines, the name “runEntConn — 0” (not shown in FIG. 8) assigned to the call 804 is specified (15th line). Eye).

(F16) The “RUNNABLE-ENTITY-CONNECTOR” element on the 15th to 20th lines has four child elements.
The first child element is the “NO” element on the 16th line, and represents the execution order defined in the model diagram 105d in the format of the sequence diagram of FIG. Since the call 804 is the first call, the content of the “NO” element on the 16th line is “1”.

  The second child element is a “SYMBOL” element on the 17th line and represents the name of the operation of the call destination. In other words, the stereotype << RunnableEntity >> is added, and the name of the function that can be called from the object of the “Task” class 206 corresponds to the value of the “symbol” attribute of the “RunnableEntity” class 205, and the model 106 a This is represented by the “SYMBOL” element. Since the call destination of the call 804 is a function named “execution point” defined in the “component A” class 301, the content of the “SYMBOL” element on the 17th line is “execution point”.

  The third child element is a “PARAMETER” element on the 18th line and represents an argument given to the operation of the call destination. Since the function “execution point” has no argument, the content of the “PARAMETER” element is empty.

  The fourth child element is a “COMPONENT-TYPE-REF” element on the 19th line and represents the class to which the called object belongs. The “PART1” object 702 that is the destination of the call 804 is an object of the “part A” class 301 as defined in FIG. Therefore, the “COMPONENT-TYPE-REF” element on the 19th line has the value “/ test / component A” expressed in the path format as in the 5th line described in the above (f9).

  According to the aggregation 255 of the first meta model 101a in FIG. 2, the “RunnableEntity” class 205 is included in the “ComponentType” class 201 which is a kind of meta component class. Therefore, in the first embodiment, a class in which a call destination function is defined by a “COMPONENT-TYPE-REF” element that means a reference to a “ComponentType” class 201 (that is, a class to which a call destination object belongs) is a model. 106a.

  (F17) The “TASK” element on the 14th to 27th lines is the same as the first “RUNNABLE-ENTITY-CONNECTOR” element (15th to 20th lines) described in (f15) and (f16) above. The first "RUNNABLE-ENTITY-CONNECTOR" element (21st to 26th lines) is included. Since the second “RUNNABLE-ENTITY-CONNECTOR” element corresponds to the call 805 in FIG. 8, the name “runEntConn_1” assigned to the call 805 is designated in the “Name” attribute.

Since the call 805 is the second call, the “NO” element (22nd line) as a child element has the content “2”.
The “PART2” object 703 that is the call destination of the call 805 is an object of the “part B” class 601 defined in the model diagram 105b of FIG. 6, and the name of the call destination function of the call 805 is “execution point”. It is. Therefore, the second “RUNNABLE-ENTITY-CONNECTOR” element has a “SYMBOL” element having the content “execution point” as a child element (line 23). Since the function “execution point” of the “component B” class 601 also has no argument, the “RUNNABLE-ENTITY-CONNECTOR” element has an empty “PARAMETER” element as a child element (line 24).

  In addition, a “COMPONENT-TYPE-REF” element (25th line) having a value of “/ test / component B” in the same path format as the above (f10) to represent the “component B” class 601 (line 25) It is included as a child element in the “RUNNABLE-ENTITY-CONNECTOR” element.

  (F18) As described briefly in (f3) above, “COMPOSITION-” representing the “component A” class 301 in FIG. 3 is displayed as a child element of the root element (ie, “PACKAGE” element) on the 29th to 44th lines. Contains a "TYPE" element. This “COMPOSITION-TYPE” element has five child elements.

  (F19) The first child element of the “COMPOSITION-TYPE” element on the 29th to 44th lines is empty indicating that the “component A” class 301 is directly derived from the “CompositionType” class 202 as shown in FIG. "SUPER-ELEMENT" element (30th line), which is the same as the 3rd line.

  (F20) The second child element of the “COMPOSITION-TYPE” element on lines 29 to 44 is a “COMFIG-PARAM” element that represents an attribute to which a stereotype of << ConfigParam >> is added in the “component A” class 301 (Lines 31-34). That is, in accordance with the notation rule 102 in (c5) above, which corresponds to the fact that the “ComponentType” class 201 can include the “ConfigParam” class 204 in the first metamodel 101a, the model creation unit 410 changes the “COMFIG-PARAM” element. Generate.

  Specifically, in FIG. 3, the “component A” class 301 defines only one attribute to which the stereotype << ConfigParam >> is added. The name is “parameter” and the type is Integer type, default value is not set. Therefore, in the “COMFIG-PARAM” elements on the 31st to 34th lines, the value “parameter” is set in the “Name” attribute (31st line). In addition, the “COMFIG-PARAM” element includes a “TYPE” element (line 32) having a value “int” and indicating an integer type, and an empty “DEFAULT-VALUE” indicating that a default value is not set. It has an element (33rd line) as a child element.

  (F21) The third child element of the “COMPOSITION-TYPE” element in the 29th to 44th lines is an “RUNNABLE-ENTITY” element representing an operation to which a stereotype of << RunnableEntity >> is added in the “component A” class 301 (Lines 35-36). That is, the model creation unit 410 creates the “RUNNABLE-ENTITY” element in accordance with the notation rule 102 in (c6) above corresponding to the “ComponentType” class 201 including the “RunnableEntity” class 205 in the first metamodel 101a. To do.

  Specifically, in FIG. 3, in the “component A” class 301, only one operation to which the stereotype << RunnableEntity >> is added is defined, and the name of the operation is “execution point”. Therefore, in the “RUNNABLE-ENTITY” elements on the 35th to 36th lines, a value “execution point” is set in the “Name” attribute.

  (F22) The fourth child element of the “COMPOSITION-TYPE” element on lines 29 to 44 is a “REQUESTER-PORT” element (lines 37 to 40) representing an object of “RequesterPort” class 212 of “part A” class 301 Eyes). According to the model diagram 105a of FIG. 3, the “component A” class 301 includes one object of the “RequesterPort” class 212, and the name of the object is “reception port”. Therefore, in the “REQUESTER-PORT” element, a value “reception port” is set in the “Name” attribute (line 37).

  In the model diagram 105a, a dependency 307 from the “reception port” port 303 to the “interface A” class 302 is defined. Therefore, the model creation unit 410 creates an “INTERFACE-REF” element (38th line) as a child element of the “REQUESTER-PORT” element based on the dependency 307. The “INTERFACE-REF” element corresponds to an association 262 indicating a reference from the “Port” class 211 to the “Interface” class 208 in the first metamodel 101a. The content of the “INTERFACE-REF” element is a value “/ test / interface A” expressed in the same path format as the fifth line.

  Although omitted in FIG. 2, for example, an integer attribute indicating the length of the input queue may be defined in the “RequesterPort” class 212. Then, the length of the input queue is also set in the “reception port” port 303 which is an instance of the “RequesterPort” class 212. Then, based on the set length, the model creation unit 410 creates a “QUEUE-LENGTH” element (39th line) as a child element of the “REQUESTER-PORT” element. In the example of FIG. 9B, the “QUEUE-LENGTH” element has a value of “0” as the content.

  (F23) The fourth child element of the “COMPOSITION-TYPE” element on lines 29 to 44 is a “PROVIDER-PORT” element (lines 41 to 43) representing an object of the “ProviderPort” class 213 included in the “component A” class 301 Eyes). According to the model diagram 105a of FIG. 3, the “component A” class 301 includes one object of the “ProviderPort” class 213, and the name of the object is “transmission port”. Therefore, in the “PROVIDER-PORT” element, the value “transmission port” is set in the “Name” attribute (line 41).

  In the model diagram 105a, a dependency 308 from the “transmission port” port 304 to the “interface A” class 302 is defined. Therefore, the model creation unit 410 creates an “INTERFACE-REF” element similar to the 38th line as a child element of the “PROVIDER-PORT” element based on the dependency 308.

  (F24) As briefly described in (f4) above, “COMPOSITION−” representing the “component B” class 601 in FIG. 6 is displayed on the 45th to 74th lines as a child element of the root element (ie, “PACKAGE” element). Contains a "TYPE" element. This “COMPOSITION-TYPE” element has nine child elements.

  (F25) The first child element of the “COMPOSITION-TYPE” element indicating the “component B” class 601 is an empty “SUPER-” indicating that the “component B” class 601 is directly derived from the “CompositionType” class 202. ELEMENT "element (line 46), which is the same as line 30.

  (F26) The second and third child elements of the “COMPOSITION-TYPE” element indicating the “component B” class 601 indicate that the “component B” class 601 includes a “P1” object 602 and a “P2” object 603. Two "COMPONENT-PROTOTYPE" elements to represent. The first (47th to 49th lines) corresponds to the “P1” object 602, and the second (50th to 52nd lines) corresponds to the “P2” object 603. These two “COMPONENT-PROTOTYPE” elements are child elements of the “COMPOSITION-TYPE” elements on lines 2 to 28 described in (f7) to (f10) above (lines 4 to 6 and lines 7 to 9). Detailed description is omitted.

  (F27) The fourth child element (lines 53 to 54) of the “COMPOSITION-TYPE” element indicating the “component B” class 601 is the “RUNNABLE-ENTITY” on lines 35 to 36 described in (f21) above. Since it is a “RUNNABLE-ENTITY” element similar to the element, a detailed description is omitted.

  (F28) The fifth child element (55th to 58th lines) of the “COMPOSITION-TYPE” element indicating the “component B” class 601 is the “REQUESTER-PORT” on the 37th to 40th lines described in (f22) above. Since it is the “REQUESTER-PORT” element similar to the element, a detailed description is omitted.

  (F29) The sixth child element (59th to 61st lines) of the “COMPOSITION-TYPE” element indicating the “part B” class 601 is the “PROVIDER-PORT” on the 41st to 43rd lines described in (f23) above. Since it is a “PROVIDER-PORT” element similar to the element, a detailed description is omitted.

  (F30) The seventh child element (lines 62 to 65) of the “COMPOSITION-TYPE” element indicating the “component B” class 601 is an “ASSEMBLY-CONNECTOR” similar to the “ASSEMBLY-CONNECTOR” element on the 10th to 13th lines. Element. The “ASSEMBLY-CONNECTOR” element in the 10th to 13th lines is as described in detail in the above (f11) to (f13). Therefore, a detailed description of “ASSEMBLY-CONNECTOR” on lines 62 to 65 is omitted, but the model creation unit 410 is based on the link 612 inside the “part B” class 601 in the model diagram 105b of FIG. The “ASSEMBLY-CONNECTOR” element on the 65th line is generated.

  In the child elements (lines 63 and 64) of the “ASSEMBLY-CONNECTOR” elements on lines 62 to 65, a relative path is used, unlike the 11th and 12th lines. That is, in the 63rd line, the path is expressed in the form of a relative path “P1 / transmission port” starting from the level of the “component B” class 601. This relative path includes “P1” that is an object name of the “P1” object 602 corresponding to an internal part of the “part B” class 601 and “transmission port” that is the name of the “transmission port” port 607 included in the “P1” object 602. "Is connected with a slash. Similarly, in the 64th line, the path is expressed in a relative path format.

  (F31) The eighth child element of the “COMPOSITION-TYPE” element indicating the “component B” class 601 is a “DELEGATION-CONNECTOR” element (lines 66 to 69) representing the link 611 as an instance of the “DelegateConnector” class 216. It is. As shown in the 66th line, in the “Name” attribute of the “DELEGATION-CONNECTOR” element, the name “delConn — 0” (not shown in FIG. 6) assigned to the link 611 is specified.

  In the first metamodel 101a, two lines of a relation 271 and a relation 272 indicating a reference to the “Port” class 211 are output from the “DelegateConnector” class 216. Therefore, the “DELEGATION-CONNECTOR” element (66th to 69th lines) corresponding to the “DelegateConnector” class 216 has two child elements (67th and 68th lines).

  That is, the “DELEGATION-CONNECTOR” element corresponds to the association 271 that refers to the “Port” class 211 with the role name “innerPortRef”, and the “INNER-PORT-REF” element represents a reference to the port on the internal component side. (Line 67) as the first child element. The content of the “INNER-PORT-REF” element is a path “/ test / component B / P1 / reception port” for specifying the internal component side port (ie, “reception port” port 606) related to the link 611. is there.

  Similarly, the “DELEGATION-CONNECTOR” element corresponds to the relationship 272 that refers to the “Port” class 211 with the role name “outerPortRef”, and represents “OUTER-PORT-REF” that represents a reference to the port on the external component side. It has the element (68th line) as the second child element. The content of the “OUTER-PORT-REF” element is a path “/ test / component B / input 1” for specifying the port on the external component side related to the link 611 (that is, “input 1” port 604).

  (F32) The ninth child element of the “COMPOSITION-TYPE” element indicating the “component B” class 601 is a “DELEGATION-CONNECTOR” element (lines 70 to 73) representing the link 613 as an instance of the “DelegateConnector” class 216. It is. Since the contents of the “DELEGATION-CONNECTOR” element in the 70th to 73rd lines are similar to the contents of the “DELEGATION-CONNECTOR” element in the 66th to 69th lines described in the above (f31), detailed description thereof is omitted.

  (F33) As described briefly in (f5) above, the “interface A” class 302 of FIGS. 3 and 6 is represented in the 75th to 85th lines as a child element of the root element (ie, “PACKAGE” element). Contains a "SENDER-RECEIVER-INTERFACE" element. In the “Name” attribute of the “SENDER-RECEIVER-INTERFACE” element, “Interface A” that is the class name of the “Interface A” class 302 is specified. This “SENDER-RECEIVER-INTERFACE” element has three child elements.

  (F34) The first child element of the “SENDER-RECEIVER-INTERFACE” element is an empty “SUPER-ELEMENT” element indicating that the “Interface A” class 302 is directly derived from the “SenderReceiverInterface” class 209, The same as the third line.

  (F35) The second and third child elements of the “SENDER-RECEIVER-INTERFACE” element are “DATA-ELEMENT” corresponding to the fact that the “SenderReceiverInterface” class 209 includes the “DataElementPrototype” class 210 in the first metamodel 101a. Element. Specifically, as illustrated in FIG. 3, the “interface A” class 302 has two attributes corresponding to instances of the “DataElementPrototype” class 210. That is, the “interface A” class 302 has an integer type attribute named “element 1” and an integer type attribute named “element 2”.

  Therefore, the model creation unit 410 uses the “DATA-ELEMENT” element (lines 77 to 80) corresponding to the attribute named “element 1” as a child element of the “SENDER-RECEIVER-INTERFACE” element representing the “interface A” class 302. Eye). Then, the model creation unit 410 sets the name “element 1” as the value of the “Name” attribute of the “DATA-ELEMENT” element. The model creation unit 410 also includes a “TYPE” element having the content “int” indicating the integer type as a child element of the “DATA-ELEMENT” element and an empty “DEFAULT” indicating that the default value is not set. -VALUE "element.

  Similarly, the model creation unit 410 corresponds to the attribute named “element 2” of the “interface A” class 302 and the second “DATA-ELEMENT” as a child element of the “SENDER-RECEIVER-INTERFACE” element. An element (81st to 84th lines) is also created.

  As described above and described as (f1) to (f35), the model creation unit 410 changes the meanings of the model diagrams 105a to 105d from the model diagrams 105a to 105d according to the first metamodel 101a and the notation rule 102. An XML format model 106a is generated.

  Next, details of the process P101 in FIG. 1 when defining a model using a class diagram and a sequence diagram will be described with reference to FIGS. 10 and 11, respectively. In the case of defining a model in the form of an object diagram, the process performed by the DSM support apparatus 104 is similar to the process of FIG. In any case, the DSM support apparatus 104 performs navigation so that a UML diagram (that is, a model diagram 105) is created according to the meta model 101 and the notation rule 102.

FIG. 10 is a diagram illustrating model editing processing according to the first embodiment. Note that FIG. 10 is expressed in the form of a UML activity diagram.
In step S <b> 101, the menu selection unit 404 displays a menu for selecting the metamodel 101 on the output device 402 via the UML tool 103. The model creation navigation unit 403 receives an input for selecting the metamodel 101 via the input device 401 and the UML tool 103. Then, the model creation navigation unit 403 reads the selected metamodel 101 from the metamodel storage unit 416 in accordance with the received input.

  The read metamodel 101 can be referred to from the component menu providing unit 405, the port menu providing unit 406, the interface menu providing unit 407, the internal component menu providing unit 408, and the task menu providing unit 409. is there.

The next step S102 is a merge node that represents a merging point between the flow of processing from step S101 and the flow of processing from step S116 described later.
Subsequently, in step S <b> 103, the menu selection unit 404 displays a menu for selecting a process on the output device 402 via the UML tool 103. Then, when an input designating the type of processing is given to the menu selection unit 404 of the model creation navigation unit 403 via the input device 401 and the UML tool 103, the processing proceeds to step S104.

  In step S104, the menu selection unit 404 determines whether the process selected in step S103 is a component creation process. When the component creation process is selected, the menu selection unit 404 calls the component menu providing unit 405, and the process proceeds to step S105. On the other hand, if the component creation process is not selected, the process proceeds to step S117.

  In step S105, the component menu providing unit 405 creates a new component class. For example, in the case where the “part A” class 301 is created as a new part class in FIG. 3, the part menu providing unit 405 operates as follows via the UML tool 103 in step S105. The class diagram (that is, the model diagram 105a) is edited.

  That is, the component menu providing unit 405 determines whether the “CompositionType” class 202 in the first metamodel 101a has already been copied to the class diagram being created. If not yet copied, the part menu providing unit 405 reads the “CompositionType” class 202 from the first metamodel 101a, and adds the “CompositionType” class 202 to the class diagram being created via the UML tool 103. Copy.

  Then, the part menu providing unit 405 instructs the UML tool 103 to draw a rectangle representing the class for the new part class and draw a generalization 305 line from the rectangle to the “CompositionType” class 202. . As a result, the lines of the rectangle and the generalization 305 are output to the output device 402 via the UML tool 103.

  In addition, the component menu providing unit 405 receives input specifying the class name, attribute, and operation of the class represented by the rectangle via the UML tool 103, and reflects the received result on the class diagram being created. Output to the output device 402.

  The component menu providing unit 405 further notifies the model creation unit 410 of information on the created class. Then, the model creation unit 410 creates and edits the model 106 by generating an XML code corresponding to the notified information. For example, when the “component A” class 301 in FIG. 3 is created in step S105, the model creation unit 410 generates the codes on the 29th, 30th, and 44th lines in FIG. 9B and adds them to the model 106a.

  In step S <b> 106, the part menu providing unit 405 determines whether the part represented by the class created in step S <b> 105 is the top part based on an input given from the input device 401 via the UML tool 103. For example, the part menu providing unit 405 causes the output device 402 to display a dialog via the UML tool 103, and allows the user to input whether or not the part represented by the class created in step S105 is the top-level part. Make a decision based on this.

  If the part represented by the class created in step S105 is the top part, the process proceeds to step S107. If the part is not the top part, the process proceeds to step S109 through step S108 of the merge node.

  In step S107, the component menu providing unit 405 performs the highest-level component setting process. For example, when the “whole software” class 701 in FIG. 7 is created in step S105, an instruction that the “whole software” class 701 is the highest-level component is input in step S106. Accordingly, in step S <b> 107, the component menu providing unit 405 adds the stereotype << TopLevel >> to the “whole software” class 701 via the UML tool 103.

  In addition, the part menu providing unit 405 notifies the model creation unit 410 that the part represented by the class created in step S105 is the highest order part. The model creation unit 410 edits the model 106 in response to the notification. For example, when the “whole software” class 701 is created in step S105, the model creation unit 410 adds the “TopLevel” attribute to the “COMPOSITION-TYPE” element shown in the second line of FIG. Set the value "True" to the "TopLevel" attribute.

  After execution of step S107, the process proceeds to step S108. Step S108 is a merge node indicating the merge point of the process flow from step S106 and the process flow from step S107, and then the process proceeds to step S109.

  In step S109, the component menu providing unit 405 determines whether or not the stereotype << ConfigParam >> is designated as the attribute defined in the class based on the input given from the input device 401 via the UML tool 103. Judgment.

  For example, the part menu providing unit 405 may display a dialog on the output device 402 via the UML tool 103. That is, the component menu providing unit 405 displays a dialog for allowing the user to select an attribute to which the stereotype << ConfigParam >> is added from the attributes defined in step S105 in the class created in step S105. May be provided.

  If there is an attribute to which the stereotype << ConfigParam >> is added, the process proceeds to step S110. If the stereotype << ConfigParam >> is not added to any attribute, the process is a merge node. After step S111, the process proceeds to next step S112.

  In step S110, the component menu providing unit 405 performs parameter setting processing. For example, the “component A” class 301 of FIG. 3 is created in step S105, and an instruction to add the stereotype << ConfigParam >> to the attribute named “parameter” of the “component A” class 301 in step S109. Suppose an input is given. In step S <b> 110, the component menu providing unit 405 adds a stereotype << ConfigParam >> to the specified attribute named “parameter” via the UML tool 103.

  Also, the component menu providing unit 405 notifies the model creation unit 410 of the attribute to which the stereotype << ConfigParam >> is added. In the case of the “component A” class 301 described above, the model creation unit 410 generates the XML code of lines 31 to 34 in FIG. 9B based on the notification, and adds it to the model 106a.

Then, the process proceeds to step S112 through step S111 of the merge node.
Step S111 is a merge node indicating the merge point of the process flow from step S109 and the process flow from step S110, and then the process proceeds to step S112.

  In step S <b> 112, the component menu providing unit 405 determines whether or not to specify the stereotype << RunnableEntity >> for the operation defined in the class based on the input given from the input device 401 via the UML tool 103. Judgment. That is, the part menu providing unit 405 determines in step S112 whether or not to define an operation defined in the class as an execution point for driving the part by an external call.

  For example, the part menu providing unit 405 may display a dialog on the output device 402 via the UML tool 103. That is, the component menu providing unit 405 displays a dialog for allowing the user to select an operation for adding the stereotype << RunnableEntity >> from the operations defined in step S105 in the class created in step S105. May be provided.

  If there is a target operation to which the stereotype << RunnableEntity >> is added, the process proceeds to step S113. If the stereotype << RunnableEntity >> is not added to any operation, the process is a merge node. The process proceeds to step S115 through step S114.

  In step S113, the component menu providing unit 405 performs an execution point setting process. For example, it is assumed that the “component A” class 301 of FIG. 3 is created in step S105. In step S112, it is assumed that an input instructing to add a stereotype of << RunnableEntity >> is given to the operation named "execution point" of the "component A" class 301. Then, in step S <b> 113, the component menu providing unit 405 adds a stereotype << RunnableEntity >> via the UML tool 103 to the designated operation named “execution point”.

  In addition, the part menu providing unit 405 notifies the model creation unit 410 of an operation to which a stereotype << RunnableEntity >> is added. In the case of the “component A” class 301 described above, the model creation unit 410 generates the XML code of lines 35 to 36 in FIG. 9B based on the notification and adds it to the model 106a.

Then, the process proceeds to step S115 through step S114 of the merge node.
Step S114 is a merge node indicating the merge point of the process flow from step S112 and the process flow from step S113, and then the process proceeds to step S115.

  In step S115, the component menu providing unit 405 determines whether to create a port in the class created in step S105, based on an input given from the input device 401 via the UML tool 103. For example, the part menu providing unit 405 may display a dialog on the output device 402 via the UML tool 103 and allow the user to specify whether to create a port.

If a port is not created, the process proceeds to step S116. If a port is created, the process proceeds to step S119.
In step S <b> 116, the menu selection unit 404 determines whether an input for instructing to finish editing the model diagram 105 is given via the input device 401 and the UML tool 103. When an input for instructing to end editing is given, the processing in FIG. 10 ends. If no input is given to end editing, the process returns to step S102.

  When the menu selection unit 404 determines in step S104 that “the process selected in step S103 is not a part creation process”, in step S117, “whether the process selected in step S103 is a port creation process or not. Judgment is made. When the port creation process is selected, the menu selection unit 404 calls the port menu provision unit 406, and the process proceeds to step S118. On the other hand, if the port creation process is not selected, the process proceeds to step S126.

  In step S118, the port menu providing unit 406 selects a class of parts for which a port object is to be created. For example, the port menu providing unit 406 causes the output device 402 to output a dialog requesting the user to select a part class for creating a port object via the UML tool 103. The port menu providing unit 406 receives user input to the dialog via the input device 401 and the UML tool 103, and selects a target class for creating a port object according to the input. Then, the process proceeds to step S119.

Step S119 is a merge node indicating a merge point of the process flow from step S115 and the process flow from step S118.
In the process flow from step S115, the target for creating the port is the class created in step S105, and in the process flow from step S118, the target for creating the port is the class selected in step S118. is there. Therefore, when step S120 is executed subsequent to step S119, the target for creating the port is uniquely determined.

  In step S120, the port menu providing unit 406 performs port creation processing for the part class created in step S105 or selected in step S118. The port creation process includes, for example, the following processes (g1) to (g4).

(G1) Processing to output a dialog prompting the user to specify the number, type, and name of ports to be created to the output device 402 via the UML tool 103.
(G2) Processing for receiving input to the dialog through the input device 401 and the UML tool 103 and defining a port according to the input.

(G3) Processing to instruct the UML tool 103 to output a graphic representing the defined port to the output device 402.
(G4) Processing for notifying the model creation unit 410 of the information of the defined port.

  Note that in (g1) above, the type of port is the “RequesterPort” class 212 on the data receiving side or the “ProviderPort” on the data output side, as described in the example of the first metamodel 101a in FIG. "Class 213". In FIG. 2, since the multiplicity of the aggregation 259 is “0 .. *”, one component class can have an arbitrary number of ports. Therefore, in step S120, the number of ports to be created may be specified in the dialog as in (g1) above.

  Further, the model creation unit 410 edits the model 106 based on the information notified in (g4). For example, when the “input 1” port 604 and the “output 1” port 605 in FIG. 6 are created in step S120, the model creation unit 410 generates XML codes of lines 55, 57 to 59, and 61 in FIG. Add to model 106a.

  In step S121 following step S120, the port menu providing unit 406 determines whether an interface class used by the port created in step S120 has been created.

  For example, the port menu providing unit 406 may cause the output device 402 to output a dialog asking the user whether or not the interface class used by the port created in step S120 has been created, via the UML tool 103. Good. If the created interface class for the port has been created, the process proceeds to step S122. If not created, the process proceeds to step S123.

In step S122, the port menu providing unit 406 selects an interface class used by the port created in step S120 from the created classes.
For example, the port menu providing unit 406 causes the output device 402 to output a dialog requesting the user to select an interface class via the UML tool 103. The port menu providing unit 406 receives user input to the dialog via the input device 401 and the UML tool 103, and selects an interface class used by the port according to the input.

After execution of step S122, control is transferred to the next step S125.
In step S123, the port menu providing unit 406 calls the interface menu providing unit 407, and the interface menu providing unit 407 creates a new interface class. For example, the case where a new “Interface A” class 302 is created in FIG. 3 will be described as an example. In step S123, the interface menu providing unit 407 operates as follows via the UML tool 103, and the class diagram ( That is, the model diagram 105a) is edited.

  That is, the interface menu providing unit 407 determines whether the “SenderReceiverInterface” class 209 in the first metamodel 101a has already been copied to the class diagram being created. If not yet copied, the interface menu providing unit 407 reads the “SenderReceiverInterface” class 209 from the first metamodel 101a, and adds the “SenderReceiverInterface” class 209 to the class diagram being created via the UML tool 103. make a copy.

  Then, the interface menu providing unit 407 instructs the UML tool 103 to draw a rectangle representing the class for the new interface class and draw a generalization 306 line from the rectangle to the “SenderReceiverInterface” class 209. As a result, the lines of the rectangle and the generalization 306 are output to the output device 402 via the UML tool 103.

  Also, the interface menu providing unit 407 receives input specifying the class name of the class represented by the rectangle via the UML tool 103, and reflects the received result in the class diagram being created to the output device 402. Output.

  Further, the interface menu providing unit 407 notifies the model creation unit 410 of information on the created class. Then, the model creation unit 410 creates and edits the model 106 by generating an XML code corresponding to the notified information. For example, when the “interface A” class 302 of FIG. 3 is created in step S123, the model creation unit 410 generates the code of lines 75, 76, and 85 of FIG. 9D and adds it to the model 106a.

In the next step S124, the interface menu providing unit 407 creates data elements included in the interface class created in step S123.
According to the first metamodel 101 a of FIG. 2, the “SenderReceiverInterface” class 209 can include a “DataElementPrototype” class 210. Accordingly, the interface class defined as a subclass of the “SenderReceiverInterface” class 209 can include data elements.

  Accordingly, in step S124, the interface menu providing unit 407 creates an instance of the “DataElementPrototype” class 210 as an attribute of the interface class created in step S123 according to the first meta model 101a. That is, the interface menu providing unit 407 creates the data element of the interface class via the UML tool 103 as the attribute of the class created in step S123.

  For example, the interface menu providing unit 407 may cause the output device 402 to output a dialog for allowing the user to input the number of data elements and the name and type of the data elements corresponding to the number of data elements via the UML tool 103. Good. The interface menu providing unit 407 receives an input to the dialog via the input device 401 and the UML tool 103.

  Then, the interface menu providing unit 407 instructs the UML tool 103 to set the attribute in the class created in step S123 according to the received input. Then, the attribute name and type are output to the output device 402 according to the input.

  Depending on the embodiment, the interface menu providing unit 407 may accept not only the name and type, but also an input related to a default value and visibility of the attribute. Further, even if “0” is input as the number of data elements in step S124, the interface menu providing unit 407 makes an appropriate input based on the multiplicity of “0 .. *” of the composite aggregation 264 of FIG. It is judged that. As a result, no data element may be created.

  A specific example of the operation in step S124 is as follows. That is, in the example of FIG. 3, “2” is input as the number of data elements included in the “interface A” class 302, and “element 1” and “int” are input as the name and type of the first data element. “Element 2” and “int” are input as the name and type of the second data element. As a result, two attributes named “element 1” and “element 2” are set in the “interface A” class 302 and displayed on the output device 402 as the “interface A” class 302 in FIG. .

  In step S124, the interface menu providing unit 407 notifies the model creation unit 410 of the content of the received input. The model creation unit 410 edits the model 106 in response to the notification. For example, in the example of FIG. 3, the model creation unit 410 generates the XML code of lines 77 to 84 in FIG. 9D and adds it to the model 106a.

After a series of processes as described above are executed in step S124, control is transferred to the next step S125.
In step S125, the port menu providing unit 406 performs processing for connecting each of the ports created in step S120 to the interface class selected in step S122 or created in step S123. Specifically, the port menu providing unit 406 instructs the UML tool 103 to add dependency from the port object to the interface class, and notifies the model creation unit 410 of the addition of dependency.

  For example, in the example of FIG. 3, it is assumed that the “reception port” port 303 is created in step S120 and the “interface A” class 302 is selected in step S122 or created in step S123.

In this case, the port menu providing unit 406 instructs the UML tool 103 to add the dependency 307 in step S125, and as a result, the dependency 307 is displayed on the output device 402. Further, since the port menu providing unit 406 notifies the model creation unit 410 of the addition of the dependency 307, the model creation unit 410 generates the XML code of 38 lines in FIG. 9B and adds it to the model 106a.
After execution of the above step S125, the process proceeds to step S116.

  When the menu selection unit 404 determines in step S117 that “the process selected in step S103 is not a port creation process”, in step S126, “whether the process selected in step S103 is an interface creation process or not. Judgment is made. When the interface creation process is selected, the menu selection unit 404 calls the interface menu providing unit 407, and the process proceeds to step S127. On the other hand, if the interface creation process is not selected, the process proceeds to step S129.

  In step S127, the interface menu providing unit 407 creates an interface class. Since step S127 is the same as step S123, detailed description is omitted.

  Following step S127, in step S128, the interface menu providing unit 407 performs data element creation processing. Since step S128 is the same as step S124, detailed description is omitted. After execution of step S128, the process proceeds to step S116.

  If the menu selection unit 404 determines in step S126 that "the process selected in step S103 is not an interface creation process", in step S129, "the process selected in step S103 is an internal component creation process". Whether or not. When the internal component creation process is selected, the menu selection unit 404 calls the internal component menu providing unit 408, and the process proceeds to step S130. On the other hand, if the internal part creation process is not selected, the process proceeds to step S134.

In step S130, the internal component menu providing unit 408 selects a class of internal components.
For example, the internal component menu providing unit 408 causes the output device 402 to output a dialog requesting the user to select a component class to be used as an internal component from the predefined component classes via the UML tool 103. Also good. Then, the internal component menu providing unit 408 may receive an input to the dialog from the input device 401 via the UML tool 103, and may select a class of the internal component according to the received input.

  For example, in the example of FIG. 6, when the “P1” object 602 that is an internal part of the “part B” class 601 is created, in step S130, the “part A” class 301 of FIG. 3 to which the “P1” object 602 belongs. Is selected.

  Subsequently, in step S131, the internal component menu providing unit 408 creates an internal component object. Specifically, the internal component menu providing unit 408 performs the following processes (h1) to (h5). In the following description of (h1) to (h5), a case where a “P1” object 602 is created as an internal component of the “component B” class 601 in FIG.

  (H1) The internal component menu providing unit 408 instructs the UML tool 103 to instantiate the class selected as the internal component class in step S130 and create an object.

  As a result, for example, the “P1” object 602 in FIG. 6 is created from the “component A” class 301 in FIG. As shown in FIG. 3, since it is defined that the “component A” class 301 has a “reception port” port 303 and a “transmission port” port 304, the “P1” object 602 includes “ It has a “receive port” port 606 and a “transmit port” port 607. However, the object name “P1” has not yet been assigned at this stage.

  (H2) The internal component menu providing unit 408 receives an input designating the name of the created object from the input device 401 via the UML tool 103 and instructs the UML tool 103 to give the created object the name. To do. For example, the name “P1” is assigned to the “P1” object 602 in FIG.

  (H3) The internal component menu providing unit 408 selects an external component including the internal component. For example, the internal component menu providing unit 408 causes the output device 402 to output a dialog prompting the user to specify the class of the external component that includes the object created in (h1) above, via the UML tool 103. Then, the internal component menu providing unit 408 receives an input from the input device 401 to the dialog via the UML tool 103, and selects an external component class according to the received input. For example, the internal component menu providing unit 408 selects the “component B” class 601 in FIG. 6 as the class of the external component.

  (H4) The internal component menu providing unit 408 instructs the UML tool 103 to include the internal component object created in (h1) in the external component class selected in (h3). As a result, for example, as shown in FIG. 6, the “P1” object 602 is included in the “Part B” class 601, and the output device 402 adds the rectangle of the “P1” object 602 to the rectangle of the “Part B” class 601. indicate.

  (H5) The internal component menu providing unit 408 notifies the model creation unit 410 of the nesting relationship between the components defined as a result of the above (h1) to (h4), and the model creation unit 410 determines the model 106 based on the notification. Edit. For example, based on the nesting relationship notified about the “part B” class 601 and the “P1” object 602 and the name “P1” notified as the object name of the “P1” object 602, the model creation unit 410 106a is edited. Specifically, the model creation unit 410 generates the XML code of lines 47 to 49 in FIG. 9C and adds it to the model 106a.

For example, when the processes (h1) to (h5) described above are performed in step S131, the process proceeds to step S132.
In step S132, the internal component menu providing unit 408 performs a delegate connector creation process. That is, the internal component menu providing unit 408 creates a link between the port of the external component and the port of the internal component as an instance of the “DelegateConnector” class 216 of the first metamodel 101a of FIG. For example, if the “P1” object 602 of FIG. 6 is created in step S131, the internal component menu providing unit 408 creates the link 611 in step S132.

  As indicated by the multiplicity of “0 .. *” in the aggregation 259 in the first metamodel 101a in FIG. 2, neither the internal part nor the external part may have a port, and one or more May have any number of ports. Therefore, in step S132, a link may not be created as a result, and one or a plurality of links may be created.

  Specifically, the internal component menu providing unit 408 provides, via the UML tool 103, a user interface for connecting the internal component port created in step S131 to the external component port selected in (h3). To provide. The user interface may include, for example, a dialog asking the user whether to connect the ports of the internal part and the external part. In addition, the user interface has a function of allowing the user to specify a set of ports of internal components to be connected and ports of external components via the UML tool 103.

  The internal component menu providing unit 408 receives an input given from the input device 401 via the UML tool 103 and the user interface, and determines whether the input satisfies the constraints (d6) and (d8). The internal component menu providing unit 408 creates a link according to the input if the input satisfies the constraints of (d6) and (d8). Conversely, if the input does not satisfy the constraints of (d6) and (d8), A warning is displayed on the output device 402 via the UML tool 103.

  As described above, in step S132, a link is not created in some cases, and one or more links are created in some cases. When a link is created, the link satisfies the restrictions (d6) and (d8) by the above control.

  Further, in step S132, the internal component menu providing unit 408 notifies the model creation unit 410 of information on the created link. The model creation unit 410 generates an XML code according to the notification and edits the model 106. For example, when the link 611 in FIG. 6 is created, the model creation unit 410 generates the XML code on lines 66 to 69 in FIG. 9C and adds it to the model 106a.

  Next, in step S133, the internal component menu providing unit 408 performs assembly connector creation processing. That is, the internal component menu providing unit 408 creates a link between ports of internal components as an instance of the “AssemblyConnector” class 215 of the first metamodel 101a of FIG. For example, when the “P1” object 602 in FIG. 6 has been created and the “P2” object 603 is created in step S131, the internal component menu providing unit 408 creates the link 612 in step S133.

  As indicated by the multiplicity of “0 .. *” in the aggregation 259 in the first metamodel 101a in FIG. 2, the internal component may not have a port, and one or more arbitrary numbers of ports May have. Therefore, in step S133, a link may not be created as a result, or one or a plurality of links may be created.

  Specifically, the internal component menu providing unit 408 connects the port of the internal component created in step S131 to the port of another existing internal component in the external component port selected in (h3). The user interface is provided via the UML tool 103. The user interface may include, for example, a dialog asking the user whether or not to connect between ports of internal components. The user interface has a function of allowing the user to specify the ports of the two internal components to be connected via the UML tool 103.

  The internal component menu providing unit 408 receives an input given from the input device 401 via the UML tool 103 and the user interface, and determines whether or not the input satisfies the restrictions (d7) and (d8). The internal component menu providing unit 408 creates a link according to the input if the input satisfies the constraints of (d7) and (d8), and conversely, if the input does not satisfy the constraints of (d7) and (d8), A warning is displayed on the output device 402 via the UML tool 103.

  As described above, in step S133, a link is not created in some cases, and one or more links are created in some cases. When a link is created, the link satisfies the restrictions (d7) and (d8) by the above control.

  Further, in step S133, the internal component menu providing unit 408 notifies the model creation unit 410 of information on the created link. The model creation unit 410 generates an XML code according to the notification and edits the model 106. For example, when the link 612 in FIG. 6 is created, the model creation unit 410 generates the XML code on lines 62 to 65 in FIG. 9C and adds it to the model 106a.

After the above series of processes is executed, the process proceeds to step S116.
When the menu selection unit 404 determines in step S129 that “the process selected in step S103 is not an internal component creation process”, the menu selection unit 409 is called, and the process proceeds to step S134. In step S134, the task menu providing unit 409 performs task creation processing.

  That is, the task menu providing unit 409 creates a new task by creating an object that instantiates the “Task” class 206 of the first metamodel 101a.

  That is, the task menu providing unit 409 instantiates the “Task” class 206 via the UML tool 103 to create a new object, and names the object according to the input from the input device 401. Then, the task menu providing unit 409 causes the output device 402 to output a graphic representing the created task object via the UML tool 103.

  For example, the task menu providing unit 409 creates the “T1” object 704 in FIG. 7 and assigns the object name “T1” according to the input from the input device 401. Then, the task menu providing unit 409 causes the output device 402 to display a rectangle indicating the “T1” object 704 on the model diagram 105c as illustrated in FIG. 7 via the UML tool 103.

  In step S134, the task menu providing unit 409 further notifies the model creating unit 410 of information related to the created task object. The model creation unit 410 generates an XML code based on the notified information and edits the model 106. For example, when the “T1” object 704 in FIG. 7 is created, the model creation unit 410 generates the XML codes on the 14th and 27th lines in FIG. 9A and adds them to the model 106a.

After execution of the above series of processes, the process proceeds to step S116.
10, for the sake of simplification of description, it is assumed that the menu includes only component creation processing, port creation processing, interface creation processing, internal component creation processing, and task creation processing. Therefore, the process proceeds from step S129 to step S134 as described above.

However, depending on the embodiment, there may be another type of processing, and the processing branching control by the menu selection unit 404 may be different from the flowchart shown in FIG. 10 accordingly. For example, the model creation navigation unit 403 may further provide menus such as the following (i1) to (i3).
(I1) A menu for adding, editing, and deleting data elements in the created interface class.
(I2) A menu for adding / deleting a port in a created part class.
(I3) Menu for adding / deleting / reconnecting links.
(I4) A menu for resetting the dependency between the port object and the interface class.
(I5) A menu for adding / editing / deleting the attribute / operation / stereotype in the created part class.

  For example, when the menus (i1) to (i5) are present, the model creation navigation unit 403 notifies the model creation unit 410 of the processing results in the menus (i1) to (i5), and the model creation unit 410 Edits the model 106a according to the notification.

  The part creation process, port creation process, interface creation process, and internal part creation process are processes related to class diagram editing. However, the model creation navigation unit 403 can also provide various menus related to editing object diagrams.

  For example, the model creation navigation unit 403 may provide a menu for creating an object that instantiates a defined part class, a menu for connecting the created part objects to each other by a link between ports, and the like. Then, the model creation navigation unit 403 confirms whether or not the constraint conditions (d7) and (d8) are satisfied in the link connection.

  Further, the model creation navigation unit 403 creates a menu for creating one instance of a special class to which a stereotype << TopLevel >> is added in the object diagram as in the “whole software” class 701 in FIG. May be provided.

  By the way, the static side of the software model is represented by a class diagram or an object diagram, but one dynamic side can be expressed by using a sequence diagram as shown in FIG. The DSM support device 104 of the first embodiment also supports modeling using a sequence diagram.

  FIG. 11 is a diagram for explaining drive order definition processing according to the first embodiment. That is, the drive order definition process of FIG. 11 is a process of defining the order of driving components from a task using a sequence diagram as shown in FIG. FIG. 11 is also expressed in the form of a UML activity diagram.

  As shown in FIG. 8, the model creation navigation unit 403 of the DSM support device 104 receives an input for selecting a menu for performing modeling work using the sequence diagram via the input device 401 and the UML tool 103 of FIG. Then, the drive order definition process of FIG. 11 is started.

  In step S <b> 201, the model creation navigation unit 403 performs display (for example, display of a dialog) prompting the user to select a task from the created model diagram 105 via the UML tool 103. The model creation navigation unit 403 receives an input for selecting a task via the input device 401 and the UML tool 103.

  For example, in the example of FIG. 8, the model creation navigation unit 403 receives an input specifying the “T1” object 704 of the “Task” class 206 defined in the model diagram 105c of FIG. 7 in step S201. In step S <b> 201, for example, when an object of a class other than the “Task” class 206 is designated, the model creation navigation unit 403 may output a warning to the output device 402 via the UML tool 103.

The next step S202 is a merge node where the flow of processing from step S201 and the flow of processing from step S205 described later merge.
In step S203 subsequent to step S202, the model creation navigation unit 403 selects a component to be driven from the task selected in step S201. For example, the model creation navigation unit 403 performs display (for example, display of a dialog) prompting the user to select an object of a part to be driven from the created model diagram 105 via the UML tool 103. The model creation navigation unit 403 receives an input for selecting a part object via the input device 401 and the UML tool 103, and selects the object according to the input.

  For example, in the example of FIG. 8, the model creation navigation unit 403 receives an input designating the “PART1” object 702 defined in the model diagram 105c of FIG. 7 in step S203.

  In step S203, the model creation navigation unit 403 may reject, for example, an input that specifies an object other than an object of a subclass of the “CompositionType” class 202 as an illegal input. In addition, the model creation navigation unit 403 considers that the input is invalid when the operation with the stereotype << RunnableEntity >> is not defined in the class of the specified object. Then, the model creation navigation unit 403 may output a warning to the output device 402 via the UML tool 103 for unauthorized input.

  When the part object is selected, in step S204, the model creation navigation unit 403 performs connection processing between the task selected in step S201 and the part selected in step S203. That is, the model creation navigation unit 403 performs the following processes (j1) to (j4).

  (J1) The model creation navigation unit 403 performs display (for example, display of a dialog) prompting the user to specify an operation to be called from the selected task via the UML tool 103. The model creation navigation unit 403 receives the name of the specified operation via the input device 401 and the UML tool 103. For example, when the “PART1” object 702 in FIG. 8 is selected in step S203, the model creation navigation unit 403 receives the operation name “execution point”.

  (J2) The model creation navigation unit 403 receives input indicating the starting point and the ending point of the arrow from the input device 401 via the UML tool 103. It should be noted that the model creation navigation unit 403 indicates that only the range of the active period of the task selected in step S201 can be designated as the starting point of the arrow, and only the range of the active period of the component selected in step S203 has an arrow. Constraints can be specified as the end point.

  For example, the model creation navigation unit 403 receives an input indicating the start and end points of the call 804. The starting point of the call 804 arrow is within the activation period 801 of the “T1” object 704 selected in step S201, and the end point of the call 804 arrow is the activation of the “PART1” object 702 selected in step S203. It is within the range of the period 802.

  (J3) The model creation navigation unit 403 has the name specified in (j1) as a label and adds an arrow from the start point to the end point specified in (j2) to the sequence diagram being created. Commands the UML tool 103. The UML tool 103 adds an arrow indicating a call to the sequence diagram according to the instruction, and the output device 402 displays the added arrow and label. For example, the arrow and label of call 804 in FIG.

  (J4) The model creation navigation unit 403 notifies the model creation unit 410 of the contents and order of the call added in (j3) above. Then, the model creation unit 410 edits the model 106 according to the notified contents. For example, when the call 804 in FIG. 8 is added, the model creation unit 410 generates the XML code on the 15th to 20th lines in FIG. 9A and adds it to the model 106a. If the call 804 is added after the call 805 is defined first, the model creation unit 410 changes the value of the “NO” element in the existing 22nd line in FIG. 9A from “1” to “2”. And the value of the “NO” element in the new 16th line is set to “1”.

When the processes (j1) to (j4) above are performed in step S204, the process proceeds to step S205.
In step S <b> 205, the model creation navigation unit 403 determines whether an end instruction for instructing to end the drive order definition process is input via the input device 401 and the UML tool 103. When an end instruction is input, the final model diagram 105 created in the form of a sequence diagram is stored in the model diagram storage unit 412 via the UML tool 103, and the drive order definition process in FIG. If no end instruction is input, control returns to the merge node in step S202, and the process is repeated from step S203.

FIG. 12 is a diagram illustrating the code generation process according to the first embodiment. FIG. 12 is also expressed in the form of a UML activity diagram.
In step S <b> 301, the code generation device 108 receives an input of the model 106 created according to the meta model 101 and the notation rule 102. Specifically, the code generation device 108 reads the model 106 stored in the semantic model storage unit 413 in FIG.

  In step S <b> 302, the code generation device 108 converts the model 106 into the intermediate data 110. The intermediate data 110 is XML data including a data group in which information necessary for code generation is easily collected for code generation. In the first embodiment, step S302 is performed for code generation by XSLT (XSL Transformations).

  Note that the format of the model 106 (that is, the schema of the model 106 that is XML data) varies depending on the embodiment, and step S302 may be omitted depending on the schema.

  Finally, in step S303, the code generation device 108 performs code generation processing. That is, the code generation device 108 reads the code generation template 107 from the template storage unit 414 in FIG. 4 and applies the XSL format code generation template 107 to the XML format intermediate data 110 to generate the source code 109.

  Note that the language of the source code 109 to be generated can be changed by replacing the code generation template 107. For example, if the code generation template 107 for Java (registered trademark) is used, the source code 109 written in Java (registered trademark) is generated, and if the code generation template 107 for C ++ is used, the source code written in C ++ is generated. Code 109 is generated. Depending on the embodiment, the code generation device 108 may accept an input for selecting the code generation template 107 from the input device 401 in step S303.

An overview of the first embodiment described in detail above is as follows.
In the first embodiment, the metamodel 101 represents software as a metamodel by using a first class diagram expressed in UML. The meta model 101 includes a definition of a meta part class (for example, “CompositionType” class 202) obtained by meta-modeling the parts included in the software. The model creation navigation unit 403 of the DSM support apparatus 104 executes a metamodel acquisition step of acquiring the metamodel 101 as shown in step S101 of FIG.

  Furthermore, the part menu providing unit 405 in the model creation navigation unit 403 executes a class diagram generation step as shown in step S105 in FIG. That is, the component menu providing unit 405 defines a component class (for example, “component A” class 301) representing a component included in the software as a subclass of the meta component class (for example, “CompositionType” class 202). Thereby, the part menu providing unit 405 generates a model obtained by modeling the software according to the meta model as a second class diagram including the part class and expressed in UML (for example, the model diagram 105a).

  The component menu providing unit 405 notifies the model creating unit 410 of information related to the created component class. Then, the model creation unit 410 generates a semantic model (for example, model 106a) that represents the meaning of the second class diagram (for example, model diagram 105a) in a predetermined formal language (for example, XML) in accordance with the notified information. The generation of the semantic model is based on the generalization from the component class to the metacomponent class (for example, generalization 306 in FIG. 3) and the metamodel. The above “meaning” specifically means that “the component class in the second class diagram is a class that models a component (not an interface or the like)”.

  In the first embodiment, the first class diagram showing the meta model 101 further includes a definition of a meta interface class (for example, a “SenderReceiverInterface” class 209) obtained by meta-modeling an interface for communication between components.

  Then, in generating the second class diagram, the interface menu providing unit 407 defines an interface class (for example, “Interface A” class 302) that models the interface of communication between components as a subclass of the meta interface class. . The interface class is defined in the second class diagram (for example, the model diagram 105a). In generating the second class diagram, the interface menu providing unit 407 further uses the relationship with the interface class (for example, the dependency 307 or 308) to communicate the communication between components in the second class diagram. write.

  Then, when generating the model 106 as a semantic model, the model creation unit 410 uses a code in a predetermined formal language (for example, 37 in FIG. (-40 lines). This code is generated based on generalization (for example, generalization 306) from the interface class to the meta interface class. Then, the model creation unit 410 includes the code in the model 106 as a semantic model.

  In the first embodiment, the first class diagram showing the meta model 101 further includes a meta communication port class (for example, “Port” class 211 and its class) as classes included in the meta part class (for example, “CompositionType” class 202). Subclass) is defined.

  Therefore, when generating the second class diagram (for example, the model diagram 105a), the port menu providing unit 406 converts the component class (for example, the “component A” class 301) into a communication port object that is an object of the meta communication port class. May be defined to include. Specific examples of the communication port object are a “reception port” port 303 and a “transmission port” port 304 in FIG. In some embodiments, the communication port object may be a communication port class object defined in the model diagram 105 or the like as a subclass of the meta communication port class.

  When the component class is thus defined to include the communication port object, the port menu providing unit 406 operates as follows. In other words, the port menu providing unit 406 uses the dependency from the communication port object to the interface class (for example, the dependency 307) to indicate communication via the interface between components in the second class diagram (for example, the model diagram 105a). To do.

  In the first embodiment, the first class diagram representing the metamodel 101 also defines a first aggregation relationship (for example, aggregation 253) for indicating that components may be nested. . Further, the first class diagram includes, for example, a “DelegateConnector” class as a meta internal communication class for representing communication between an external component and an internal component within an external component having a nested internal component. 216 is also defined. A second aggregation relationship (for example, aggregation 268) indicating that the meta internal communication class is included in the meta component class is also defined.

  Therefore, in the first embodiment, the internal component menu providing unit 408 can operate as follows. It is assumed that there are a plurality of component classes in the second class diagram (for example, model diagram 105b) representing the software model, and the internal component classes are nested in the external component class. An example of the external part class is “part B” class 601, and an example of the internal part class is “part A” class 301.

  At this time, the internal component menu providing unit 408 establishes an internal communication relationship (for example, link 611) that is a relationship corresponding to the meta internal communication class (for example, “DelegateConnector” class 216) between the external component class and the internal component class. Define.

  Then, the model creation unit 410 sets the internal communication relationship in the generation of the model 106 by using a code in a predetermined formal language that means communication between the external component class and the internal component class (for example, lines 66 to 69 in FIG. 9C). This code is included in the semantic model. The code is generated based on the generalization (for example, generalization 305 and generalization 610) to the metacomponent class from the external component class and the internal component class, respectively, and the definition of the meta internal communication class.

  In the first embodiment, a sequence for defining calls between objects included in an object diagram such as the model diagram 105c in FIG. 7 that defines an object of a part class defined in a class diagram such as the model diagrams 105a and 105b. A diagram is also generated. For example, the model creation navigation unit 403 generates a model diagram 105d as shown in FIG. 8 while performing navigation with restrictions.

  Then, the model creation unit 410 generates a code (for example, the 15th to 26th lines in FIG. 9A) that represents the calling order in a predetermined language based on the contents of the sequence diagram, and uses the code 106 as a semantic model. Include in

  Next, another embodiment using a meta model other than the first meta model 101a of FIG. 2 will be described. Specifically, the second embodiment will be described with reference to FIGS. 13 to 15 and the third embodiment will be described with reference to FIGS.

  In the second and third embodiments described below, the overall processing flow described with reference to FIG. 1 for the first embodiment does not change. Further, the model editing process in the process P101 of FIG. 1 is performed by the DSM support device 104 and the storage device 411 similar to those in FIG.

  However, there are differences in the specific contents of the notation rule 102 and the code generation template 107 depending on the difference in the metamodel 101, and the operation of each component in the model creation navigation unit 403 in FIG. There are some differences depending on the characteristics. In the following, the second and third embodiments will be described with a focus on differences from the first embodiment, and description of points similar to those of the first embodiment will be omitted as appropriate.

  FIG. 13 is a UML class diagram representing the second metamodel. Since the second metamodel is obtained by changing a part of the first metamodel, the description will focus on the changed points, and the description of the common points will be omitted as appropriate.

  The second metamodel 101b in FIG. 13 does not include the “RunnableEntity” class 205 and the aggregation 255, the relationship 256, and the relationship 258 connected to the “RunnableEntity” class 205 in the first metamodel 101a in FIG.

  In the first metamodel 101a, the multiplicity of the aggregation 257 between the “Task” class 206 and the “RunnableConnector” class 207 is “1 .. *”, but the multiplicity is different in the second metamodel 101b. In other words, in the second metamodel 101b, an aggregation 901 having a multiplicity of “1” indicating that the “Task” class 206 includes one “RunnableConnector” class 207 includes the “Task” class 206 and the “RunnableConnector” class. 207.

  In the second metamodel 101b, a “RunnableEntityPort” class 902, a “PrevPort” class 903, and a “NextPort” class 904 are further defined. A generalization 905 indicating that the “RunnableEntityPort” class 902 is a super class of the “PrevPort” class 903 and a generalization 906 indicating that the “RunnableEntityPort” class 902 is a super class of the “NextPort” class 904 are also defined. Has been.

  The second metamodel 101b further defines an association 907 indicating that the “RunnableConnector” class 207 refers to the “RunnableEntityPort” class 902 with the role name “prevPort”. In addition, a relation 908 indicating that the “RunnableConnector” class 207 refers to the “RunnableEntityPort” class 902 with the role name “nextPort” is also defined.

  In the second meta model 101b, a “ComponentType” class 201 that is a generalization of the “CompositionType” class 202 as a meta component class can include one “PrevPort” class 903, and the multiplicity is “0. .1 "is defined. Similarly, an aggregation 910 with a multiplicity of “0..1” indicating that the “ComponentType” class 201 can include one “NextPort” class 904 is also defined.

The semantic difference between the second metamodel 101b defined as described above and the first metamodel 101a is as follows.
The first metamodel 101a is a metamodel for defining the driving order of objects by a sequence diagram as shown in FIG. On the other hand, the second metamodel 101b is a metamodel for defining the driving order of objects by an object diagram as shown in FIG. The “RunnableEntityPort” class 902 is a meta model of a port for indicating the driving order of objects.

That is, in the second metamodel 101b, the task is first activated, and the task calls and drives the first one of the parts objects. The metamodel is formed by the following points (k1) to (k3). Has been.
(K1) The multiplicity of the aggregation 901 is “1”.
(K2) A relationship 907 indicating a reference from the “RunnableConnector” class 207 connected to the “Task” class 206 to the “RunnableEntityPort” class 902 is defined.
(K3) The “CompositionType” class 202 can include one object of the “PrevPort” class 903 that is a subclass of the “RunnableEntityPort” class 902 that is referenced from the “RunnableConnector” class 207 by the association 907.
The point (k3) is apparent from the fact that the “CompositionType” class 202 is a subclass of the “ComponentType” class 201.

The second metamodel 101b is further metamodeled by the following points (l1) to (l4) that the object has the ability to call and drive the next object sequentially in the driving order. Yes.
(L1) The “CompositionType” class 202 which is a meta part class can include one “NextPort” class 904.
(L2) The “RunnableEntityPort” class 902, which is a super class of the “NextPort” class 904, is referred to by the role name “nextPort” from the “RunnableConnector” class 207 as indicated by the relation 908.
(L3) The “RunnableConnector” class 207 refers to the “RunnableEntityPort” class 902 by another role name “prevPort” as shown in the relation 907.
(14) The “CompositionType” class 202 that is a meta part class can include one object of “PrevPort” class 903 that is a subclass of the “RunnableEntityPort” class 902 referred to by the association 907.
Note that the points (l1) and (l4) are apparent from the fact that the “CompositionType” class 202 is a subclass of the “ComponentType” class 201.

  In other words, in the second metamodel 101b, each object has a port connected to another object (or task) that drives the object and a port connected to the next object that the object drives. Metamodeling to include. Therefore, according to the second metamodel 101b, the driving order between the objects of the parts can be expressed by the connection between the ports, so that the driving order can be modeled by the object diagram.

  FIG. 14 is a UML class diagram representing a third model according to the second metamodel. Similar to FIG. 3, the model diagram 105 e in FIG. 14 includes a “CompositionType” class 202 and a “SenderReceiverInterface” class 209 defined in the second metamodel 101 b in FIG. 13 as meta part classes and meta interface classes. .

The model diagram 105a includes three user-defined classes: a “part 1” class 1001, a “part 2” class 1002, and an “interface 1” class 1003.
The “component 1” class 1001 includes an “in” port 1004 that is an object of the “RequesterPort” class 212 and an “out” port 1005 that is an object of the “ProviderPort” class 213. The “component 1” class 1001 includes a “prev” port 1006 that is an object of the “PrevPort” class 903 and a “next” port 1007 that is an object of the “NextPort” class 904.

  Similarly, the “component 2” class 1002 includes an “in” port 1008 that is an object of the “RequesterPort” class 212 and an “out” port 1009 that is an object of the “ProviderPort” class 213. The “component 2” class 1002 includes a “prev” port 1010 that is an object of the “PrevPort” class 903 and a “next” port 1011 that is an object of the “NextPort” class 904.

  In the model diagram 105e, a generalization 1012 is defined that indicates that the “component 1” class 1001 is a subclass of the “CompositionType” class 202. Similarly, generalization 1013 indicating that the “component 2” class 1002 is a subclass of the “CompositionType” class 202 is also defined. Furthermore, a generalization 1014 indicating that the “interface 1” class 1003 is a subclass of the “SenderReceiverInterface” class 209 is also defined.

  In the model diagram 105e, a dependency 1015 from the “in” port 1004 to the “interface 1” class 1003 and a dependency 1016 from the “out” port 1005 to the “interface 1” class 1003 are defined. Similarly, a dependency 1017 from the “in” port 1008 to the “interface 1” class 1003 and a dependency 1018 from the “out” port 1009 to the “interface 1” class 1003 are also defined.

  The model diagram 105e is a class diagram that conforms to the second metamodel 101b and the notation rule 102, and specifically satisfies the same constraint conditions as (c1) to (c4) described with reference to FIG. The model diagram 105e satisfies the constraint condition because the DSM support apparatus 104 creates and edits the model diagram 105e while applying constraints based on the second metamodel 101b and the notation rule 102.

  For simplification of explanation, FIG. 14 omits the stereotype << ConfigParam >> and the attributes and operations in each class. However, as in the example of FIG. 3, the DSM support apparatus 104 creates the model diagram 105e while applying the constraints so that the constraint conditions (c5) and (c7) are also satisfied. The constraint condition (c7) is also satisfied.

  FIG. 15 is a UML object diagram showing an example of use of the model shown in FIG. A model diagram 105f in FIG. 15 represents a model according to the second metamodel 101b in the form of an object diagram.

The model diagram 105f includes a “T1” object 1101 that instantiates the “Task” class 206 of the second metamodel 101b.
The model diagram 105 f includes a “B1” object 1102 that instantiates the “part 1” class 1001 defined in the model diagram 105 e and a “B2” object 1103 that instantiates the “part 2” class 1002. The model diagram 105 f further includes a “B11” object 1104 that instantiates the “part 1” class 1001 and a “B22” object 1105 that instantiates the “part 2” class 1002.

  As shown in FIG. 14, each of the “component 1” class 1001 and the “component 2” class 1002 includes four ports. Accordingly, the “B1” object 1102 includes a “prev” port 1106, a “next” port 1107, an “in” port 1108, and an “out” port 1109.

  Similarly, the “B2” object 1103 includes a “prev” port 1110, a “next” port 1111, an “in” port 1112, and an “out” port 1113. Similarly, the “B11” object 1104 includes a “prev” port 1114, a “next” port 1115, an “in” port 1116 and an “out” port 1117. Similarly, the “B22” object 1105 includes a “prev” port 1118, a “next” port 1119, an “in” port 1120, and an “out” port 1121.

  The model diagram 105f defines a plurality of links for indicating the drive order of components. That is, the link 1122 between the “T1” object 1101 and the “prev” port 1106 indicates that the “T1” object 1101 first drives the “B1” object 1102. Then, the link 1123 between the “next” port 1107 and the “prev” port 1110 indicates that the “B1” object 1102 then drives the “B2” object 1103.

  A link 1124 between the “next” port 1111 and the “prev” port 1114 indicates that the “B2” object 1103 subsequently drives the “B11” object 1104. Further, the link 1125 between the “next” port 1115 and the “prev” port 1118 indicates that the “B11” object 1104 finally drives the “B22” object 1105. Since the “B22” object 1105 does not drive other objects, the “next” port 1119 is not linked anywhere.

  Furthermore, in the model diagram 105f, a plurality of links indicating communication between components (in other words, data flow) are also defined. That is, in the model diagram 105 f, a link 1126 between the “out” port 1109 and the “in” port 1112 is defined. Similarly, a link 1127 between the “out” port 1113 and the “in” port 1116 and a link 1128 between the “out” port 1117 and the “in” port 1120 are also defined.

  These links 1126 to 1128 satisfy the above (d7) and (d8). That is, each of the links 1126 to 1128 is a link between objects of the “RequesterPort” class 212 and the “ProviderPort” class 213, and is a link between ports that depend on the same “interface 1” class 1003.

  The links 1122 to 1125 indicating the driving order are created so as to satisfy the constraint conditions described in (m1) to (m3) below, according to the second metamodel 101b and the notation rule 102.

  (M1) The notation rule 102 indicates that the task first drives the object of the part. “Only the object of the“ PrevPort ”class 903 can be linked from the object of the“ Task ”class 206”. Includes rules. Link 1122 conforms to this rule.

  Further, in the second metamodel 101b, this rule is a reference from the “RunnableConnector” class 207 included in the “Task” class 206 to the “RunnableEntityPort” class 902 which is a super class of the “PrevPort” class 903 (that is, the relationship 907). ). That is, the model creation unit 410 interprets a link from an object of the “Task” class 206 to an object of the “PrevPort” class 903 as an instance of the “RunnableConnector” class 207, and edits the model 106 according to the interpretation.

  Further, the model creation navigation unit 403 rejects an input to connect the “T1” object 1101 to the objects of the “NextPort” class 904, the “RequesterPort” class 212, and the “ProviderPort” class 213 based on the above rules. . In this way, the model creation navigation unit 403 edits the model diagram 105 f so as to conform to the notation rule 102.

  (M2) The notation rule 102 includes a rule “an instance of the“ PrevPort ”class 903 can only be linked with an instance of the“ NextPort ”class 904 or the“ Task ”class 206”. The notation rule 102 further includes a rule “an instance of the“ NextPort ”class 904 can be linked only with an instance of the“ PrevPort ”class 903”.

  Since the model creation navigation unit 403 edits the model diagram 105f while using these two rules as constraint conditions, the links 1122 to 1125 conform to these two rules.

  (M3) The notation rule 102 interprets the meaning of a link when there is a link between an instance of the “NextPort” class 904 in the first object and an instance of the “PrevPort” class 903 in the second object. Also give. In other words, the notation rule 102 defines an interpretation that “the link corresponds to an instance of the“ RunnableConnector ”class 207 and indicates that the first object drives the second object”.

The model creation unit 410 edits the model 106 by generating an XML code indicating the driving order according to this interpretation.
Therefore, for example, the link 1123 is interpreted by the model creation unit 410 as an instance of the “RunnableConnector” class 207. Further, the “next” port 1107 which is one end of the link 1123 is a port referred to by the role name “nextPort” shown in the relation 908 of the second metamodel 101b for the link 1123. Similarly, the “prev” port 1110 which is the other end of the link 1123 is a port referred to by the role name “prevPort” shown in the association 907 for the link 1123.

  According to the above interpretation, the model creation unit 410 has the meaning of “driven in the order of“ B1 ”object 1102,“ B2 ”object 1103,“ B11 ”object 1104, and“ B22 ”object 1105” on the model 106. To express.

As described above, the content of the notation rule 102 corresponding to the second metamodel 101b is partially different from the notation rule 102 corresponding to the first metamodel 101a.
Specifically, in the second embodiment, in the class diagram representing the second meta model 101b, a meta call port class is defined as a class included in the meta part class using an aggregation relationship. For example, in FIG. 13, “PrevPort” class 903 and “NextPort” class 904 that are subclasses of “RunnableEntityPort” class 902 are defined using aggregations 909 and 910 as meta call port classes.

  Therefore, when generating a class diagram such as the model diagram 105e, the component menu providing unit 405 defines a component class so as to include one or more call port objects which are meta call port class objects. Depending on the embodiment, the component menu providing unit 405 may define an object of a subclass of a meta call port class (for example, “PrevPort” class 903 and “NextPort” class 904) as a call port object. Also good.

  As a result, the call between each object can be expressed in an object diagram (for example, model diagram 105f) that defines a plurality of objects in total of one or more part classes defined in the class diagram as shown in FIG. It becomes like this. In other words, by using the relationship between the call port objects provided in each object in the object diagram (links 1123 to 1125, etc.), the call between the objects can be expressed.

  At the same time, the model creation unit 410 generates a code that expresses which object calls which object in a predetermined formal language based on the call between the objects represented in the object diagram as shown in FIG. Then, the model creation unit 410 includes the generated code in the model 106 as a semantic model.

  As described above, there is a difference between the first embodiment and the second embodiment in terms of order definition, and the contents of the notation rule 102 are also changed according to the difference. However, the point that the DSM support device 104 edits the model diagram 105 and the model 106 while applying restrictions according to the notation rule 102 determined in advance for each meta model 101 is that the first embodiment and the second embodiment. There is no change between them.

Subsequently, a third embodiment will be described with reference to FIGS.
FIG. 16 is a UML class diagram representing the third metamodel. The third metamodel 101c shown in FIG. 16 is suitable for a robot control domain, for example.

  The third metamodel 101c includes a definition of a “block” class 1201 that is a class obtained by metamodeling a target represented by a rectangle in a UML object diagram representing a software model. The “block” class 1201 has an attribute named “name” in order to indicate that an object represented by a rectangle can be given a name.

  The third metamodel 101c also includes definitions of a “task” class 1202 obtained by metamodeling a task, a “function” class 1203 that is a meta part class, and a “data” class 1204 that is a meta interface class. In other words, the “function” class 1203 is a class obtained by abstracting various functions of software components into a meta model. Further, the “data” class 1204 is a class that meta-models various data as an interface from the viewpoint that a communication interface between components is defined by a format of data input / output between the components.

  The “task” class 1202 has two attributes for indicating the cycle of executing the task and the timing at which the task is first activated, and the names are “ignition cycle” and “initial counter”. The “data” class 1204 has an attribute named “data type” for indicating the type of interface represented by the “data” class 1204.

  The third meta model 101c further includes a definition of a “connector” class 1205 that is a class obtained by meta-modeling a target represented by various lines in a UML object diagram representing a software model.

  More specifically, the third metamodel 101c is a metamodel that expresses the execution order and data input / output by links with arrows indicating navigability in the object diagram. Therefore, the third metamodel 101 c includes an “execution order” class 1206 and a “data access” class 1207 defined as subclasses of the “connector” class 1205. The “data access” class 1207 has an attribute named “access type” for indicating the type of data access, “Read” (read) or “Write” (write).

  The third metamodel 101c also includes a definition of a “comment” class 1208 indicating that a comment is attached to the UML object diagram. The “comment” class 1208 has an attribute named “description”. That is, a character string that is the value of the “description” attribute is attached as a comment to the UML object diagram.

  Further, the third metamodel 101 c includes definitions of “actuator” class 1209, “calculation” class 1210, and “sensor” class 1211 as subclasses directly derived from “function” class 1203. The third metamodel 101 c also includes a definition of a subclass derived indirectly from the “function” class 1203. Specifically, the third metamodel 101c includes an “LCD” (Liquid Crystal Display) class 1212, a “motor” class 1213, a “graph characteristic” class 1214, an “light sensor” class 1215, and a “touch sensor” class 1216. Each definition is also included.

According to the third metamodel 101c, the following various relationships are defined between the above classes.
That is, the generalizations 1251, 1252, and 1253 indicate that the “task” class 1202, the “function” class 1203, and the “data” class 1204 are subclasses of the “block” class 1201, respectively. Generalizations 1254 and 1255 indicate that the “execution order” class 1206 and the “data access” class 1207 are subclasses of the “connector” class 1205, respectively.

  Further, generalizations 1256, 1257, and 1258 indicate that “actuator” class 1209, “calculation” class 1210, and “sensor” class 1211 are subclasses of “function” class 1203, respectively.

  Generalizations 1259 and 1260 indicate that the “LCD” class 1212 and the “motor” class 1213 are subclasses of the “actuator” class 1209, respectively. Similarly, the generalization 1261 indicates that the “graph characteristic” class 1214 is a subclass of the “operation” class 1210. Also, generalizations 1262 and 1263 indicate that the “light sensor” class 1215 and the “touch sensor” class 1216 are subclasses of the “sensor” class 1211, respectively.

  Each of the relations 1264 and 1265 having a multiplicity of “1” indicates that the “execution order” class 1206 can refer to the “block” class 1201 with role names “prev” and “next”, respectively. Associations 1264 and 1265 indicate that in the diagram representing the software model, both ends of a line representing an instance of the “execution order” class 1206 are instances of the “block” class 1201 (or a subclass thereof).

  The relationship 1266 with the multiplicity “0 .. *” indicates that the “block” class 1201 refers to the “comment” class 1208 with the role name “comment”. The association 1266 indicates that in the diagram representing the software model, an arbitrary number of comments can be added to a rectangle representing an instance of the “block” class 1201 (or a subclass thereof).

  Similarly, a relationship 1267 with a multiplicity of “0 .. *” indicates that the “connector” class 1205 refers to the “comment” class 1208 with the role name “comment”. The association 1267 indicates that an arbitrary number of comments can be added to a line representing an instance of the “connector” class 1205 (or a subclass thereof) in the diagram representing the software model.

  In each of the relations 1268 and 1269 with multiplicity “1”, the “data access” class 1207 can refer to the “data” class 1204 and the “function” class 1203 with role names “data” and “function”, respectively. Represents that. Associations 1268 and 1269 represent software models, and a line representing an instance of the “data access” class 1207 connects the instances of the “function” class 1203 (or its subclass) and the “data” class 1204. Correspond. That is, associations 1268 and 1269 indicate that access from a function (as a model of software parts) to some data (as a model of the interface) is metamodeled by the “data access” class 1207. .

  By the way, in the third metamodel 101c, five classes indirectly derived from the “function” class 1203 are defined as concrete classes. That is, the third metamodel 101c is a specific class such as the “light sensor” class 1215 so that the user can model software components in the form of an object diagram without having to define the class. Contains definitions. This is the difference between the first and second metamodels 101a and 101b and the third metamodel 101c.

  That is, in the first and second metamodels 101a and 101b, a user models software in the form of a class diagram (that is, a part is modeled by a user-defined subclass derived from the metapart class). Is the premise. Therefore, according to the first and second metamodels 101a and 101b, the user can be given a degree of freedom in class design within a range in which the domain is narrowed to some extent.

  On the other hand, the meta part class in the third meta model 101c includes a domain-specific concrete class such as the “light sensor” class 1215, and the user can quickly model the software without defining the class. .

  In other words, modeling using the first and second metamodels 101a and 101b allows the user to perform DSM design while customizing the class definition. On the other hand, modeling using the third metamodel 101c enables DSM design using a custom-made class that is predefined according to the domain. Also in the third embodiment, the user may define a component class as a subclass of the “function” class 1203 using the third metamodel 101c.

  What type of metamodel is preferable varies depending on the application field of the software to be designed, etc., but depending on the type of the metamodel, from the first to third embodiments or variations thereof. It is possible to select and apply a suitable embodiment.

Now, an example of software modeling according to the third metamodel 101c will be described.
FIG. 17 is a UML object diagram representing a model according to the third metamodel. The model diagram 105g in FIG. 17 is a self-propelled rear-wheel drive / front-wheel steering type that determines the white line drawn on the road surface based on the brightness, runs along the white line while searching for the right end of the white line and tracing it. It is an example of the object figure showing the model of the software for vehicle robot control.

  Model diagram 105 g includes a “steering task” object 1301 of “task” class 1202. A “steering task” object 1301 models a front wheel control task.

  The model diagram 105 g further includes a “LightSensor1” object 1302 of the “light sensor” class 1215, a “handle cut amount” object 1303 of the “graph characteristic” class 1214, and a “handle drive” object 1304 of the “motor” class 1213. Further, the model diagram 105 g includes a “road surface brightness” object 1305 and a “handle motor drive amount” object 1306 of the “data” class 1204.

  The model diagram 105 g also includes a “tire drive task” object 1307 of a “task” class 1202. A “tire driving task” object 1307 models a task for controlling the rear wheels.

  The model diagram 105g includes a “speed control amount” object 1308 of a “graph characteristic” class 1214, a “rear wheel drive” object 1309 of a “motor” class 1213, and a “tire drive amount” of a “data” class 1204. Contains object 1310.

  The model diagram 105g includes a link indicated by an arrow as an instance of the “execution order” class 1206. The root side and the tip side of the arrow correspond to the relations 1264 and 1265 in the third metamodel 101c, respectively, and the tip side object is called from the arrow side object and driven.

  Specifically, the link 1321 indicates that the “steering task” object 1301 drives the “LightSensor1” object 1302. The link 1322 indicates that the “LightSensor1” object 1302 drives the “handle cut amount” object 1303. The link 1323 indicates that the “handle cut amount” object 1303 drives the “handle drive” object 1304.

  Similarly, link 1324 indicates that the “tire drive task” object 1307 drives the “speed control amount” object 1308. The link 1325 indicates that the “speed control amount” object 1308 drives the “rear wheel drive” object 1309.

  The model diagram 105 g also includes a link indicated by an arrow as an instance of the “data access” class 1207. A link indicated by an arrow from an instance of the “data” class 1204 to an instance of a subclass of the “function” class 1203 indicates “Read” access from which the function reads data. A link indicated by a reverse arrow indicates a “Write” access by which the function writes data.

  Specifically, the link 1331 represents writing from the “LightSensor1” object 1302 to the “road brightness” object 1305, and the reading of the “road brightness” object 1305 to the “handle cut amount” object 1303 is a link 1332. Represents. A link 1333 represents writing from the “handle cut amount” object 1303 to the “handle motor drive amount” object 1306. A link 1334 represents reading of the “handle motor drive amount” object 1306 into the “handle drive” object 1304.

  The “handle motor drive amount” object 1306 is also read into the “speed control amount” object 1308, and the link 1335 indicates the reading, and the “speed control amount” object 1308 writes to the “tire drive amount” object 1310. Is represented by the link 1336, and the link 1337 represents the reading of the “tire drive amount” object 1310 into the “rear wheel tire drive” object 1309.

  The model diagram 105 g also includes comments 1341 to 1346 as instances of the “comment” class 1208. For example, since the comment 1341 is added to the “handle cut amount” object 1303, it is connected to the “handle cut amount” object 1303 by a dotted line 1351.

  Similarly, the comments 1342 to 1346 are connected to a “speed control amount” object 1308, a link 1324, a link 1336, a “tire drive amount” object 1310, and a link 1337 by dotted lines 1352 to 1356, respectively. These dotted lines 1351-1356 correspond to the relation 1266 or the relation 1267 in the third metamodel 101c.

More specifically, the model diagram 105g including the graphic as described above is a model of the following control.
That is, the “steering task” object 1301 for controlling the front wheels calls the “LightSensor1” object 1302, the “LightSensor1” object 1302 senses the brightness of the road surface, and the sensed road surface brightness is changed to “the brightness of the road surface”. Write to object 1305. Further, the “LightSensor1” object 1302 drives the “handle cut amount” object 1303.

  Then, the “handle cut amount” object 1303 reads the “road brightness” object 1305 and derives the handle motor drive amount from the read data. Specifically, as described in the comment 1341, the “handle cut amount” object 1303 determines to turn the handle to the right when it becomes brighter and to the left when it becomes darker. Write to the Quantity object 1306. Further, the “handle cut amount” object 1303 drives the “handle drive” object 1304.

  Then, the “handle drive” object 1304 reads the “handle motor drive amount” object 1306 and performs control to drive the handle motor according to the result determined by the “handle cut amount” object 1303. As a result, as described in the comment 1341, the robot can move along the edge of the white line on the road surface.

  In addition to the front wheel control, the rear wheel control is also performed. Specifically, first, the “tire drive task” object 1307 calls the “speed control amount” object 1308. Note that a comment 1343 indicating that the link 1324 is a connector indicating the execution order is added to the link 1324 indicating this call.

  The “speed control amount” object 1308 called from the “tire driving task” object 1307 reads the “handle motor driving amount” object 1306. As described in the comment 1342, the “speed control amount” object 1308 controls the speed in proportion to the amount indicated by the “handle motor drive amount” object 1306 (specifically, for example, as the handle is fully increased) Control such as reducing the speed).

  Based on the “handle motor drive amount” object 1306, the “speed control amount” object 1308 specifically determines the tire drive amount for speed control, and the determined result is the “tire drive amount” object 1310. Write to. A comment 1344 is attached to the link 1336 representing this writing. A comment 1344 indicates that the link 1336 is a connector indicating “Write” access to function data.

  The “speed control amount” object 1308 calls and drives the “rear wheel drive” object 1309. The driven “rear wheel tire drive” object 1309 reads the “tire drive amount” object 1310. A comment 1346 is attached to the link 1337 representing this reading. The comment 1346 indicates that the link 1337 is a connector representing “Read” access to the function data.

  A “rear wheel tire drive” object 1309, which has read the “tire drive amount” object 1310, controls to drive the tires of the rear wheels. That is, as described in the comment 1345, the determined tire driving amount from the “speed control amount” object 1308 via the “tire driving amount” object 1310 as an interface between parts is the “rear wheel tire driving” object. 1309.

  When editing the robot control software model as described above, the DSM support apparatus 104 of the third embodiment behaves slightly differently from the first embodiment. Hereinafter, differences from the first embodiment will be described.

  The DSM support apparatus 104 in the third embodiment is similar to the DSM support apparatus 104 in the first embodiment shown in FIG. 4, but the operation of each component in the model creation navigation unit 403 is different from that in the first embodiment. .

  For example, in the process of editing a software model, the part menu providing unit 405 instantiates a concrete class defined as a subclass of the “function” class 1203 in the third metamodel 101c on the UML object diagram. To do.

  For example, the part menu providing unit 405 can generate only “LCD” class 1212, “motor” class 1213, “graph characteristic” class 1214, “light sensor” class 1215, and “touch sensor” class 1216. It may be presented as an option. The option is presented via the UML tool 103, and the part menu providing unit 405 may receive an input for selecting one of the options from the input device 401 via the UML tool 103.

  The component menu providing unit 405 then instantiates the selected class, creates a new object, and instructs the UML tool 103 to add it to the UML object diagram. Also, the part menu providing unit 405 notifies the model creation unit 410 of the created object class together with the object name designated via the UML tool 103 from the input device 401.

  For example, when creating the “LightSensor1” object 1302, the model creation unit 410 is notified that the newly created object is an instance of the “light sensor” class 1215 and is named “LightSensor1”.

  The model creation unit 410 recognizes that the “light sensor” class 1215 is indirectly derived from the “function” class 1203 from the third metamodel 101c. That is, the model creation unit 410 recognizes that the created “LightSensor1” object 1302 is a kind of software component, not data as an interface. Based on the recognition, the model creation unit 410 edits the model 106 by generating an XML code representing the “LightSensor1” object 1302.

  As described above, in the third embodiment, a concrete class that is also a meta part class defined in the third meta model 101c can be used as a part class representing a software part as it is. Therefore, the process in which the part menu providing unit 405 adds generalization from the part class to the meta part class as in the first embodiment is omitted in the third embodiment.

  The same applies to the creation of an object of the “data” class 1204 as an interface. That is, in the third embodiment, since the “data” class 1204 in the third metamodel 101c is a concrete class, the interface menu providing unit 407 does not have to perform a process of adding generalization to the metainterface class. .

  The interface menu providing unit 407 instantiates the “data” class 1204 via the UML tool 103 to add, for example, a “road surface brightness” object 1305 to the model diagram 105g. Then, the interface menu providing unit 407 notifies the model creation unit 410 of the object name and affiliation class of the added “road brightness” object 1305.

  Since the model creation unit 410 recognizes from the third metamodel 101c that the “data” class 1204 is a meta interface class / interface class, the “road brightness” object 1305 models the interface. Recognize. Based on the recognition, the model creation unit 410 edits the model 106 by generating an XML code representing the “road brightness” object 1305.

  Further, since the third metamodel 101c does not include a class obtained by metamodeling a port, the port menu providing unit 406 may be omitted in the third embodiment. Instead, the model creation navigation unit 403 places the following restrictions on data input / output between parts via an object of the “data” class 1204 as an interface.

  That is, the model creation navigation unit 403 constrains links connected to objects of the “data” class 1204 on the UML object diagram (for example, the model diagram 105g in FIG. 17) representing the software model. Specifically, as indicated by the relations 1268 and 1269 of the third metamodel 101c, according to the notation rule 102 of the third embodiment, it is possible to link an object of the “data” class 1204 from the “function” class 1203. Only objects of derived classes.

  Therefore, the model creation navigation unit 403 allows only an input to create a link that satisfies the constraints in accordance with the third metamodel 101c and the notation rule 102. When an input for creating a link that does not satisfy the constraints is received from the input device 401 via the UML tool 103, the model creation navigation unit 403 may display a warning on the output device 402 via the UML tool 103, for example. Good.

  For example, when an input to connect a “road surface brightness” object 1305 and a “handle motor drive amount” object 1306 via a link is received from the input device 401 via the UML tool 103, the model creation navigation unit 403 inputs Reject.

  Further, the task menu providing unit 409 according to the third embodiment may display, for example, a dialog prompting the user to specify the component driving order on the output device 402 via the UML tool 103. Then, the task menu providing unit 409 adds the link 1321 and the like according to the input to the dialog, notifies the model creation unit 410 of the added link information, and the model creation unit 410 displays the model 106 according to the notified information. You may edit it.

  For example, with each object shown in FIG. 17 created, the task menu providing unit 409 sequentially designates a “tire drive task” object 1307, a “speed control amount” object 1308, and a “rear wheel tire drive” object 1309. To receive input. Then, the task menu providing unit 409 determines whether or not the head of the designated order is an object of the “task” class 1202, and the second and subsequent objects are objects of a class derived from the “function” class 1203. Check if it exists.

  In this example, the condition to be checked (that is, the constraint condition indicated by the model diagram 105c and the notation rule 102) is satisfied. Therefore, the task menu providing unit 409 adds links 1324 and 1325 to the model diagram 105g according to the input, and information on the added links 1324 and 1325 (for example, information for identifying both the link start point and end point objects). Is notified to the model creation unit 410.

Then, the model creation unit 410 edits the model 106 by generating an XML code indicating the execution order according to the notified information.
The present invention is not limited to the above-described embodiment, and can be variously modified. Some examples are described below.

  The metamodel 101 is not limited to the above example. For example, it is not always necessary to meta-model communication interfaces between software components. Even in a meta model that does not include a meta interface class definition, generalization from user-defined classes to meta-part classes will automatically interpret user-defined classes as "classes that mean parts" and source code Can be automatically generated.

  In the above example, detailed attributes and operations of individual classes in the metamodel 101 are omitted. However, attributes and operations may be appropriately defined in the classes in the metamodel 101 according to the domain.

  For example, in FIG. 3, the “component A” class 301 and the “interface A” class 302 are directly derived from the “CompositionType” class 202 and the “SenderReceiverInterface” class 209 defined in the first metamodel 101a. However, a class indirectly derived from the meta part class defined in the meta model 101 may be defined in the model diagram 105 as a part class. Similarly, a class indirectly derived from the meta interface class defined in the meta model 101 may be defined in the model diagram 105 as an interface class.

  The same is true for ports. That is, the “reception port” port 303 and the “transmission port” port 304 in FIG. 3 are objects of the “RequesterPort” class 212 and the “ProviderPort” class 213 defined in the first metamodel 101a. However, the software may be modeled so that the component class has objects of classes derived from the “RequesterPort” class 212 and the “ProviderPort” class 213.

  That is, what a class or object in the model diagram 105 is modeled is generalized to a class defined in the metamodel 101 regardless of direct derivation or indirect derivation. Can be automatically interpreted based on Therefore, for example, even if the component class is indirectly derived from the meta component class, the effect of “enabling automatic generation of the source code 109” is obtained as in the above embodiment.

  Further, the metamodel 101 may not include a class related to a port. For example, as in the third embodiment, communication is performed via an interface between components using a relationship between a component class (for example, “motor” class 1213) and an interface class (specifically, “data” class 1204). Can also be written.

  In the above description, the generalizations 305 and 306 are illustrated in FIG. 3, for example, for easy understanding. However, the generalizations 305 and 306 need only be generated and recognized by the DSM support apparatus 104 as data, and may not be displayed as graphics on the output apparatus 402 in some embodiments.

  The formal language for describing the model 106 may not be XML. When the model 106 is described in a language other than XML, code generation in the process P102 in FIG. 1 is performed by a technique other than the XSLT technique.

  In addition, the above-described embodiment is a so-called pre-check type embodiment in which the DSM support apparatus 104 navigates the creation of the UML diagram so as to satisfy the restrictions of the meta model 101 and the notation rule 102. However, the DSM support device 104 checks the UML diagram freely created by the user based on the meta model 101 and the notation rule 102 afterwards, and warns as an error of a location that does not satisfy the constraints of the meta model 101 and the notation rule 102 Such an embodiment is also possible.

  In that case, the model creation unit 410 may receive, for example, the model diagram 105 at a stage where no error is detected as an input, and create the model 106 from the model diagram 105. In this post-check type embodiment, the model creation unit 410 generates, for example, XML data representing the graphical features of the model diagram 105 as intermediate data for creating the model 106 from the model diagram 105. May be.

  Then, the model creation unit 410 may create the final model 106 based on the intermediate data, the meta model 101, and the notation rule 102. The intermediate data may represent, for example, a graphic feature such as “which rectangle and which rectangle are connected by which line”. The model creation unit 410 can interpret the meaning of lines and rectangles based on the metamodel 101 and the notation rule 102 to create the final model 106.

  For example, regarding the component class, in the above-described pre-check type embodiment, the component menu providing unit 405 receives an instruction for creating a new component class, and the subclass of the meta component class is used as a component in response to the instruction. Create as a class in the class diagram. On the other hand, in the post-check type embodiment, the part menu providing unit 405 receives an instruction for adding generalization from an arbitrary class created in the class diagram to the meta part class, and triggers the instruction. Then, the above arbitrary class is redefined as a part class.

  The same is true for interface classes. That is, in the pre-check type embodiment, the interface menu providing unit 407 receives an instruction for creating a new interface class, and uses the instruction as a trigger to create a subclass of the meta interface class as an interface class in the class diagram. . On the other hand, in the post-check type embodiment, the interface menu providing unit 407 receives an instruction for adding generalization from an arbitrary class created in the class diagram to the meta interface class. Then, the interface menu providing unit 407 redefines the arbitrary class class as an interface class, triggered by the instruction.

Finally, the following additional notes are disclosed regarding the various embodiments described above.
(Appendix 1)
On the computer,
A metamodel acquisition step of acquiring a metamodel that includes a definition of a metapart class obtained by metamodeling a part included in the software and metaclassifies the software according to a first class diagram expressed in UML;
By defining a part class representing a part included in the software as a subclass of the meta part class, a model obtained by modeling the software according to the meta model is included in the UML including the part class. A class diagram generation step for generating a class diagram of 2;
Based on the generalization from the component class to the meta component class and the meta model, the meaning of the second class diagram is that the component class in the second class diagram is a class that models the component. A semantic model generation step for generating a semantic model expressed in a predetermined formal language;
A semantic model generation program characterized in that
(Appendix 2)
The first class diagram further includes a definition of a meta interface class that meta-models an interface of communication between the components,
The class diagram generating step includes:
Defining an interface class that models the interface of the communication between the components as a subclass of the meta-interface class in the second class diagram;
Using the relationship between the interface classes, an interface notation step for notifying the communication between the components in the second class diagram;
Including
In the semantic model generation step, the relationship between the interface class in the second class diagram is made via the interface between the components based on generalization from the interface class to the meta interface class. An interface interpretation step of expressing the first code in the predetermined formal language meaning the communication and including the first code in the semantic model;
The semantic model generation program according to Supplementary Note 1, wherein
(Appendix 3)
In the first class diagram, a meta communication port class is defined as a class included in the meta component class,
In the second class diagram, the class diagram generation step includes a communication port object that is an object of either the communication port class defined as the meta communication port class or a subclass of the meta communication port class in the second class diagram. Further including a communication port defining step for defining to include
The interface notation step is a step of expressing the communication via the interface between the components in the second class diagram by using the dependency from the communication port object included in the component class to the interface class. is there,
The semantic model generation program according to supplementary note 2, characterized by:
(Appendix 4)
The interface notation step is a step of notifying the communication between the components via the interface in the second class diagram using a relationship between the component class and the interface class.
The semantic model generation program according to supplementary note 2, characterized by:
(Appendix 5)
The class diagram generating step includes:
A component definition navigation step of receiving a first instruction for newly creating the part class and creating a subclass of the meta part class as the part class in the second class diagram with the first instruction as a trigger Or receiving a second instruction for adding generalization from an arbitrary first class created in the second class diagram to the meta-part class, and using the second instruction as a trigger, The semantic model generation program according to any one of appendices 1 to 4, further comprising: a component post-definition step for redefining a first class as the component class.
(Appendix 6)
The interface definition step includes
Interface definition navigation step of receiving a third instruction for newly creating the interface class and creating a subclass of the meta interface class as the interface class in the second class diagram with the third instruction as a trigger Or a fourth instruction for adding generalization from an arbitrary second class created in the second class diagram to the meta interface class, and triggered by the fourth instruction, The semantic model generation program according to any one of appendices 2 to 4, further comprising an interface post-definition step for redefining a second class as the interface class.
(Appendix 7)
In the first class diagram,
A first aggregation relationship to indicate that parts may be nested;
A meta-internal communication class for representing communication between the external part and the internal part within an external part having a nested internal part; and
A second aggregation relationship indicating that the meta internal communication class is included in the meta part class;
Is defined,
In the second class diagram, there are a plurality of the component classes, and the internal component of the plurality of component classes is modeled in the external component class that models the external component among the plurality of component classes. When internal part classes are nested,
The class diagram generation step includes an internal communication definition step for defining an internal communication relationship that is a relationship corresponding to the meta internal communication class between the external component class and the internal component class,
In the semantic model generation step, based on the generalization of the external component class and the internal component class to the meta component class and the definition of the meta internal communication class, the internal communication relationship is expressed as the external component class. An internal communication interpretation step including expressing the communication between the internal component class and a second code of the predetermined formal language, and including the second code in the semantic model.
The semantic model generation program according to any one of supplementary notes 1 to 6, characterized in that:
(Appendix 8)
The semantic model generation program further includes a sequence diagram generation step of generating a sequence diagram defining calls between objects included in an object diagram defining an object of the part class defined in the second class diagram on the computer. And execute
The semantic model generation step generates a third code representing the order of the calls in the predetermined formal language based on the contents of the sequence diagram, and includes the third code in the semantic model. Including a sequence definition step,
The semantic model generation program according to any one of appendices 1 to 7, characterized in that:
(Appendix 9)
In the first class diagram, as a class included in the meta part class, a meta call port class is defined using an aggregation relationship,
The class diagram generation step includes a call port definition step of defining the component class so as to include one or more call port objects that are objects of either the meta call port class or a subclass of the meta call port class,
The semantic model generation program further includes: an object diagram defining a plurality of objects of one or more of the part classes defined in the second class diagram; Using a relationship between the call port objects comprising, causing a call notation step to represent a call between the objects,
The semantic model generation step generates, based on the call between the objects described in the object diagram, a fourth code representing which object calls which object in the predetermined formal language, Including a second order defining step of including the fourth code in a semantic model;
The semantic model generation program according to any one of appendices 1 to 7, characterized in that:
(Appendix 10)
On the computer,
A metapart class definition that metamodels the parts included in the software and a metainterface class definition that metamodels the communication interface between the parts. A metamodel acquisition step for acquiring a metamodel to be modeled and represented;
At least two component objects that instantiate the meta-part class or a sub-class of the meta-part class, an interface object that instantiates the meta-interface class or a sub-class of the meta-interface class, and each of the at least two part objects An object diagram generation step for generating an object diagram represented in the UML including a link between the interface objects as a model of the software;
Based on the at least two part objects being derived from the meta part class, the interface object being derived from the meta interface class, the existence of the link, and the meta model. And a semantic model generation step of generating a semantic model that expresses in a predetermined formal language the meaning that the object diagram models the parts communicating with each other via the interface;
A semantic model generation program characterized in that
(Appendix 11)
Storage means for storing a metamodel that includes a definition of a metapart class obtained by metamodeling a part included in software and that represents the software by metamodeling according to a first class diagram expressed in UML;
A model obtained by modeling the software according to the metamodel by reading the metamodel from the storage unit and defining a part class representing a part included in the software as a subclass of the metapart class, A class diagram generating means for generating a second class diagram including a component class and expressed in the UML;
Based on the generalization from the component class to the meta component class and the meta model, the meaning of the second class diagram is that the component class in the second class diagram is a class that models the component. Semantic model generation means for generating a semantic model expressed in a predetermined formal language;
A semantic model generation device comprising:
(Appendix 12)
Computer
Including a meta part class definition obtained by meta-modeling parts included in software, and obtaining a meta model that represents the software by meta-modeling according to a first class diagram expressed in UML;
By defining a part class representing a part included in the software as a subclass of the meta part class, a model obtained by modeling the software according to the meta model is included in the UML including the part class. Generated as a class diagram of 2,
Based on the generalization from the component class to the meta component class and the meta model, the meaning of the second class diagram is that the component class in the second class diagram is a class that models the component. Generate a semantic model represented by a given formal language,
A semantic model generation method characterized by that.

101, 101a-101c Meta model 102 Notation rule 103 UML tool 104 DSM support device 105, 105a-105g Model diagram 106, 106a Model 107 Code generation template 108 Code generation device 109 Source code 110 Intermediate data 201-216, 301, 302, 601, 701, 902-904, 1001-1003, 1201-1216 Class 251-272, 305-308, 610, 614, 615, 709, 901, 905-910, 1012-1018, 1251-1269 (generalization, Association, dependency, aggregation, synthetic aggregation)
303, 304, 604 to 609, 705 to 708, 1004 to 1011, 1106 to 1121 Port 401 Input device 402 Output device 403 Model creation navigation unit 404 Menu selection unit 405 Component menu provision unit 406 Port menu provision unit 407 For interface Menu providing unit 408 Internal component menu providing unit 409 Task menu providing unit 410 Model creation unit 411 Storage device 412 Model diagram storage unit 413 Semantic model storage unit 414 Template storage unit 415 Source code storage unit 416 Meta model storage unit 500 Computer 501 CPU
502 ROM
503 RAM
504 Communication interface 505 Hard disk device 506 Portable storage medium 507 Drive device 508 Bus 509 Network 510 Program provider 602, 603, 702-704, 1101-1105, 1301-1313 Object 611-613, 710, 1122-1128, 1321 1325, 1331 to 1337 Link 801 to 803 Active period 804 and 805 Call 1341 to 1346 Comment 1351 to 1356 Dotted line

Claims (9)

On the computer,
A metamodel acquisition step of acquiring a metamodel that includes a definition of a metapart class obtained by metamodeling a part included in the software and metaclassifies the software according to a first class diagram expressed in UML;
By defining each part class based on an input from a user under a constraint that any part class representing a part included in the software should be expressed as a subclass of the meta part class, the software is A class diagram generation step of generating a model modeled so as to conform to the meta model as a second class diagram including each component class and expressed in the UML;
Each part class in the second class diagram is a class in which each part is modeled based on the generalization described in accordance with the constraint condition from each part class to the meta part class and the meta model. A semantic model generation step for generating a semantic model representing the meaning of the second class diagram in a predetermined formal language;
A semantic model generation program characterized in that The first class diagram further includes a definition of a meta interface class that meta-models an interface of communication between the components,
The class diagram generating step includes:
Defining an interface class that models the interface of the communication between the components as a subclass of the meta-interface class in the second class diagram;
Using the relationship between the interface classes, an interface notation step for notifying the communication between the components in the second class diagram;
Including
In the semantic model generation step, the relationship between the interface class in the second class diagram is made via the interface between the components based on generalization from the interface class to the meta interface class. An interface interpretation step of expressing the code in the predetermined formal language meaning the communication and including the code in the semantic model;
The semantic model generation program according to claim 1, wherein: On the computer,
Includes meta-part class definition that meta-models parts included in software, meta-interface class definition that meta-models communication interface between the parts, and meta-communication port class as a class included in the meta-part class A meta model acquisition step of acquiring a meta model that represents the software by meta-modeling according to a first class diagram expressed in UML;
By defining a part class representing a part included in the software as a subclass of the meta part class, a model obtained by modeling the software according to the meta model is included in the UML including the part class. A class diagram generation step for generating a class diagram of 2,
Defining an interface class that models the interface of the communication between the components as a subclass of the meta-interface class in the second class diagram;
In the second class diagram, communication that defines the component class to include a communication port object that is an object of either the meta communication port class or a communication port class defined as a subclass of the meta communication port class. A port definition step;
Class diagram generation including an interface notation step for expressing the communication between the components via the interface in the second class diagram by using the dependency from the communication port object included in the component class to the interface class. Steps,
Based on the generalization from the component class to the meta component class and the meta model, the meaning of the second class diagram is that the component class in the second class diagram is a class that models the component. A semantic model generation step for generating a semantic model represented by a predetermined formal language,
The predetermined format means the communication between the components via the interface based on the generalization from the interface class to the meta interface class, the dependence on the interface class in the second class diagram A semantic model generation step including an interface interpretation step of expressing in a language code and including the code in the semantic model;
A semantic model generation program characterized in that The class diagram generating step includes:
A component definition navigation step of receiving a first instruction for newly creating the part class and creating a subclass of the meta part class as the part class in the second class diagram with the first instruction as a trigger Or receiving a second instruction for adding generalization from an arbitrary first class created in the second class diagram to the meta-part class, and using the second instruction as a trigger, The semantic model generation program according to any one of claims 1 to 3, further comprising: a part post-definition step for redefining a first class as the part class. The interface definition step includes
Interface definition navigation step of receiving a third instruction for newly creating the interface class and creating a subclass of the meta interface class as the interface class in the second class diagram with the third instruction as a trigger Or a fourth instruction for adding generalization from an arbitrary second class created in the second class diagram to the meta interface class, and triggered by the fourth instruction, The semantic model generation program according to claim 2 or 3, further comprising an interface post-definition step for redefining a second class as the interface class. The first class diagram further includes a definition of a meta-parameter class that meta-models a parameter that gives a characteristic to the component, and a definition of a meta-executable entity class that meta-models an executable entity,
Aggregation indicating that the meta-part class can include the meta-parameter class and aggregation indicating that the meta-part class includes the meta-executable entity class are defined in the first class diagram;
The class diagram generating step includes:
Whether to add a first predetermined notation for associating an attribute defined in the component class with the metaparameter class to the second class diagram is determined based on an input from the user. 1 decision step;
Based on the input from the user, whether or not a second predetermined notation for associating an operation defined in the component class with the meta-executable entity class is added to the second class diagram. A second decision step to decide,
The semantic model generation step includes:
For each attribute defined in each component class, for the attribute associated with the metaparameter class by the first predetermined notation, a code indicating that the attribute gives a feature to the component is generated, An attribute interpretation step of including the generated code in the semantic model;
Of the operations defined in each component class, for the operations associated with the meta-executable entity class by the second predetermined notation, the operation is performed from the outside in order to drive the component from the outside. callable generates a code indicating that it is a public operation, meaning model generation program according to claim 1 or 2, characterized in that it comprises an operation interpretation step of including the code thus generated to the semantic model. Storage means for storing a metamodel that includes a definition of a metapart class obtained by metamodeling a part included in software and that represents the software by metamodeling according to a first class diagram expressed in UML;
Each component based on the input from the user under the constraint that the metamodel is read from the storage means and any component class representing the component included in the software should be expressed as a subclass of the metacomponent class. Class diagram generating means for generating a model obtained by modeling the software so as to conform to the meta model by defining a class as a second class diagram including each component class and represented by the UML;
Each part class in the second class diagram is a class in which each part is modeled based on the generalization described in accordance with the constraint condition from each part class to the meta part class and the meta model. Semantic model generation means for generating a semantic model expressing the meaning of the second class diagram in a predetermined formal language;
A semantic model generation device comprising: Includes a meta part class definition that meta-models the parts included in the software, a meta interface class definition that meta-models the communication interface between the parts, and a meta communication port as a class included in the meta part class A storage means for defining a class and storing a metamodel that represents the software by metamodeling according to a first class diagram expressed in UML;
A model obtained by modeling the software according to the metamodel by reading the metamodel from the storage unit and defining a part class representing a part included in the software as a subclass of the metapart class, Class diagram generation means for generating a second class diagram including a component class and expressed in the UML,
An interface defining means for defining an interface class modeling the interface of the communication between the components as a subclass of the meta interface class in the second class diagram;
In the second class diagram, communication that defines the component class to include a communication port object that is an object of either the meta communication port class or a communication port class defined as a subclass of the meta communication port class. Port definition means;
Class diagram generation including interface notation means for notifying the communication between the components via the interface in the second class diagram using the dependency from the communication port object included in the component class to the interface class Means,
Based on the generalization from the component class to the meta component class and the meta model, the meaning of the second class diagram is that the component class in the second class diagram is a class that models the component. Semantic model generation means for generating a semantic model expressed in a predetermined formal language,
The predetermined format means the communication between the components via the interface based on the generalization from the interface class to the meta interface class, the dependence on the interface class in the second class diagram A semantic model generating means including an interface interpreting means for expressing in a language code and including the code in the semantic model;
A semantic model generation device comprising: The first class diagram further includes a definition of a meta-parameter class that meta-models a parameter that gives a characteristic to the component, and a definition of a meta-executable entity class that meta-models an executable entity,
Aggregation indicating that the meta-part class can include the meta-parameter class and aggregation indicating that the meta-part class includes the meta-executable entity class are defined in the first class diagram;
The class diagram generating means includes:
Whether to add a first predetermined notation for associating an attribute defined in the component class with the metaparameter class to the second class diagram is determined based on an input from the user. 1 determination means;
Based on the input from the user, whether or not a second predetermined notation for associating an operation defined in the component class with the meta-executable entity class is added to the second class diagram. A second determining means for determining,
The semantic model generation means includes
For each attribute defined in each component class, for the attribute associated with the metaparameter class by the first predetermined notation, a code indicating that the attribute gives a feature to the component is generated, Attribute interpretation means for including the generated code in the semantic model;
Of the operations defined in each component class, for the operations associated with the meta-executable entity class by the second predetermined notation, the operation is performed from the outside in order to drive the component from the outside. The semantic model generation apparatus according to claim 7 , further comprising: an operation interpretation unit that generates a code indicating a public operation that can be called, and includes the generated code in the semantic model.

Images