JP5457761B2 - Semantic model generation program and semantic model generation apparatus - Google Patents
Semantic model generation program and semantic model generation apparatus Download PDFInfo
- Publication number
- JP5457761B2 JP5457761B2 JP2009198983A JP2009198983A JP5457761B2 JP 5457761 B2 JP5457761 B2 JP 5457761B2 JP 2009198983 A JP2009198983 A JP 2009198983A JP 2009198983 A JP2009198983 A JP 2009198983A JP 5457761 B2 JP5457761 B2 JP 5457761B2
- Authority
- JP
- Japan
- Prior art keywords
- class
- meta
- interface
- diagram
- model
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
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.
しかしながら、ソフトウェア開発においては人的能力に頼っている部分もいまだに多く残っており、ソフトウェアの生産性には改善の余地がある。そこで本発明は、ソフトウェア開発でのモデル化プロセスにおいて、ソフトウェアのモデルを表すデータを、ソースコードの自動生成に適合するように生成することで、ソフトウェアの生産性を向上させることを目的とする。 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.
一態様において提供される意味モデル生成プログラムは、コンピュータにメタモデル取得ステップとクラス図生成ステップと意味モデル生成ステップを実行させる。
前記メタモデル取得ステップは、メタモデルを取得するステップである。なお、前記メタモデルは、ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、UMLで表記された第1のクラス図により、前記ソフトウェアをメタモデル化して表すものである。
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.
前記クラス図生成ステップは、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記UMLで表記される第2のクラス図として生成するステップである。 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.
前記意味モデル生成ステップは、前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第2のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第2のクラス図の意味を所定の形式言語により表す意味モデルを生成するステップである。 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.
以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず図1〜5を参照して、メタモデルおよびモデルの例とともに第1実施形態の概要を説明し、次に図6〜12を参照して、第1実施形態に関わる各種情報や各種処理の詳細を説明する。その後、図13〜17を参照して、他のメタモデルを用いる第2・第3実施形態についても説明する。最後に、その他の実施形態についても説明する。 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.
図1は、第1実施形態によるソフトウェア開発支援の概要を説明する図である。なお、図1はUML(Unified Modeling Language)のユースケース図の形式で表現されている。 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.
プロセスP101において、ソフトウェアのメタモデル101と、メタモデル101とモデルの間の関連付けのための表記ルール102を用いて、UMLツール103とDSM(Domain-Specific Modeling)支援装置104が協働してモデル編集処理を行う。
In the process P101, the UML
なお、メタモデル101はUMLで表記されており、予め用意されている。メタモデル101の具体例は、図2とともに後述する。メタモデル101は、他の実施形態では、図13や16に示すようなものでもよい。
The
また、表記ルール102は、「ソフトウェアのモデルを表すUMLの図(クラス図やオブジェクト図など)が、メタモデル101と適合するためには、どのように表記されていなくてはならないのか」ということを表すルールである。つまり、表記ルール102は制約条件の一種である。
The
表記ルール102は、制御ロジックとしてDSM支援装置104内に予め組み込まれていていてもよい。あるいは、表記ルール102は、所定の形式のデータとして表現されて記憶装置に格納され、DSM支援装置104により読み取られてもよい。そして、DSM支援装置104が、読み取った表記ルール102にしたがって動作してもよい。
The
プロセスP101の結果、UMLで表記されたモデル図105と、XML(eXtensible Markup Language)で表記されたモデル106が出力される。すると、出力されたモデル106と、予め用意されたコード生成テンプレート107を用いて、プロセスP102において、コード生成装置108がコード生成処理を行う。
As a result of the process P101, a model diagram 105 expressed in UML and a
その結果、C、C++、Java(登録商標)などの所定のプログラミング言語によるソースコード109が出力される。なお、コード生成テンプレート107は、XSL(eXtensible Stylesheet Language)で表記されており、プログラミング言語に応じて個々に予め用意されている。
As a result,
第1実施形態によれば、メタモデル101と表記ルール102が制約条件として利用され、制約条件を満たすモデル図105が生成される。また、モデル図105が表しているモデルの意味は、メタモデル101および表記ルール102にしたがって解釈され、XML形式のモデル106として表現される。
According to the first embodiment, the
つまり、モデル106は、意味的にはモデル図105と等価であり、上記制約条件を満たす。換言すれば、意味モデルとしてのモデル106が表す内容は、図形として視覚的にモデル図105に表現されている。
That is, the
そして、コード生成装置108は、所望のプログラミング言語に応じた適切なコード生成テンプレート107を入力として受け取ることで、制約条件を満たすモデル106から、所望のプログラミング言語のソースコード109を出力することができる。つまり、第1実施形態のUMLツール103とDSM支援装置104は、ソースコード109の自動生成に適合するように制約条件のもとでモデル106を生成することで、ソフトウェアの生産性を向上させることができる。
The
続いて、図1に概要を示した第1実施形態が好適に適用される環境および分野について説明する。
第1実施形態によれば、汎用言語であるUMLを使用することの利点を活かしつつDSMによるソフトウェアの開発を行うという、従来は困難であったことが可能となる。以下、第1実施形態の特長の理解を助けるため、UMLの使用とDSMによるソフトウェア開発ついて説明する。
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.
UMLを使用したソフトウェア設計には、下記(a1)〜(a3)のような利点がある。
(a1)UMLは、ソフトウェアの設計者やプログラマ(以下まとめて「ユーザ」ともいう)の多くに受け入れられている。そのため、多くのユーザは既にUMLを使用したソフトウェア開発に関するノウハウや知識を蓄積している。
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)UMLによる各種の図を作成するためのエディタも実際に使用されている。上記(a1)に述べたノウハウや知識の中には、これらのエディタの操作方法に関するものも含まれる。 (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)UMLは汎用の言語なので、分野によらず利用可能である。例えば、車両用の組み込みシステム、医療用システム、金融システムなどの分野の違いによらず、UMLは利用可能である。 (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.
しかしながら、UMLを使用することは、必ずしもソフトウェアの生産性向上に直結する訳ではない。その理由は次のとおりである。
一般に、ソフトウェアはC、C++、Java(登録商標)等のプログラミング言語で記述され、これらのプログラミング言語はキャラクタベースのテキスト言語である。それに対し、UMLは非テキスト言語である。
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.
非テキスト言語には、例えば状態遷移を表す表(テーブル)の形でソフトウェアの構造や動作を表現する言語も含まれるが、UMLは図形の組み合わせでソフトウェアの構造や動作を表現する図形言語である。UML等の非テキスト言語をソフトウェアの設計において利用する場合においても、結局はテキスト言語のソースコードが作成される。 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.
しかし、従来の設計手法にしたがって非テキスト言語(すなわち図形や表)で表現された内容は、ソフトウェアを実装するための参照情報として存在するにすぎず、ソースコードを自動生成するには情報不足であった。そのため、従来は、たとえソフトウェア開発においてUMLが利用されているとしても、実際のソースコードを得るにはプログラマが手作業を行う必要があり、人的能力に依存する部分が残っていた。すなわち、UMLの使用が、それだけで必ずしもソフトウェアの生産性や品質の著しい向上をもたらすとは限らない。 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.
このように、UMLには様々な利点があるものの、UMLの使用が必ずしも生産性や品質の著しい向上に結びつくとは限らない。そこで、ソフトウェア開発の別の手法として、DSMが提唱されている。 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は、ソフトウェア開発の対象を、特定のドメイン(例えば車両用、医療用、金融用などの特定の分野)に絞り込む手法である。DSMでは、テキスト言語によるソースコードを自動的に生成するための情報を十分に含むように、当該特定のドメインに特化して、図形や表などの非テキスト言語が定義される。 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.
そして、DSMでは、ドメイン固有の非テキスト言語(つまりDomain-Specific Language;DSL)により、特定のドメイン用のソフトウェアの設計に関わる情報が表現される。ドメインを絞り込むことで、ドメイン固有の非テキスト言語の記述能力を、テキスト言語によるソースコードの自動生成が可能なレベルにまで引き上げられるので、DSMによればソースコードの自動生成が可能である。 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.
ところが、DSMには下記(b1)〜(b5)のような欠点がある。
(b1)ドメイン固有の非テキスト言語を編集するには、市販の汎用エディタ(例えば汎用言語であるUML用のエディタ)を利用することができないため、ドメイン固有のエディタが必要である。
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)ドメイン固有のエディタは、汎用品ではなく専用品であるがゆえに、エディタ自体の開発に多額の費用がかかる。 (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)ドメイン固有の非テキスト言語の文法(シンタックス)およびドメイン固有のエディタの操作方法を、ユーザがドメインごとに習得する必要があるため、時間的・金銭的なコストがかかる。 (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)ユーザは、UML等の汎用的な非テキスト言語を利用した開発のノウハウを蓄積しているかもしれないが、汎用的な非テキスト言語に関して蓄積された知識やノウハウは、ドメイン固有の非テキスト言語に直接適用可能なものではない。 (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)例えば、UMLを用いて設計された既存のソフトウェアと類似する部分を含む新規ソフトウェアをDSMにより開発しようとする場合であっても、既存のソフトウェアのために作成された資産(UMLで記述された設計情報など)は流用不能である。そのため、既存の資産を活かすことができず、既存の資産を移行するための費用もかかってしまう。 (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.
ここで、DSMの上記(b1)〜(b5)の欠点はすべて汎用性のなさに起因することに注目すると、UMLなどの汎用的な言語を利用してDSMによるソフトウェア開発を行うことが可能になれば、UMLとDSMの双方の利点を活かせると期待される。つまり、既存の資源(ユーザの知識やノウハウ、エディタ、設計情報など)を活かしつつ、DSMによるソースコードの自動生成によって、ソフトウェア開発の生産性を向上させ、ソフトウェアの品質を安定して高く保つことができるようになる、と期待される。第1実施形態の目的の1つは、このような期待を実現することである。 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.
UMLとDSMの両立のための具体的手法としては、第1実施形態に対する比較例として、例えば、UMLプロファイル技術によりUMLを拡張し、ドメイン固有の意味をクラスに付与するために、クラスに対してステレオタイプを指定することも考えられる。 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.
この比較例によれば、上記(b1)で述べたような専用のエディタの代用品として既存のUMLエディタを利用することができる。また、ソフトウェア設計者は、UMLの利点を活かしつつ、ステレオタイプに基づいてDSMによるソフトウェア設計を行うことができる。つまり、この比較例によれば、上記(b1)〜(b5)の欠点を克服することが可能である。 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).
しかしながら、上記比較例には、「代償として、設計の自由度が奪われてしまう」という、新たな欠点が生じる。つまり、上記比較例では、DSMによる設計のためにステレオタイプが利用されているので、設計者が他の目的でステレオタイプをクラスに付加して利用することができなくなってしまい、その分、設計の自由度がなくなってしまう。 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.
それに対し第1実施形態では、ステレオタイプとは別の仕組み(具体的にはメタモデル101と表記ルール102)によって、クラスの意味を判別可能とし、UMLを使ったDSMによる設計を可能としている。したがって、第1実施形態によれば、ユーザは任意の目的のためにステレオタイプをクラスに付加することができ、設計の自由度が保たれる。また、第1実施形態もUMLを利用するものなので、上記(b1)〜(b5)の欠点は克服される。
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
第1実施形態は、DSMによる設計にだけ適用可能なものではないが、上記のとおりUMLとDSMの両立のための具体的手法の一例である。したがって、第1実施形態によれば、上記(a1)〜(a3)のようなUMLの利点や既存資産を活かしつつ、DSMによるソフトウェア設計を可能とすることで、ソフトウェアの自動生成を可能とすることができる。 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.
その結果、第1実施形態においては、ソフトウェアの生産性向上・品質向上・品質安定化といった効果が得られる。また、上記比較例と比べると、第1実施形態にはさらに、「上記効果を奏するために設計の自由度を犠牲にせずに済む」という、有利な特徴もある。 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”.
さて、以上のような利点を有する第1実施形態について、以下ではより詳しく説明していく。
まず、図2と図3を参照して、図1のメタモデル101と表記ルール102の具体例を説明する。図2は、第1のメタモデルを表すUMLのクラス図であり、図3は、第1のメタモデルにしたがう第1のモデルを表すUMLのクラス図である。
Now, the first embodiment having the above advantages will be described in more detail below.
First, specific examples of the
なお、以下では表記の簡略化のため、「XXX」という名前のクラスを「『XXX』クラス」と呼び、「YYY」という名前のオブジェクトを「『YYY』オブジェクト」と呼ぶことがある。 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”.
図2に示す第1のメタモデル101aは、予め用意される図1のメタモデル101の一例であり、UMLのクラス図の形で図2に図示されている。
第1のメタモデル101aは、ソフトウェアが含む部品(ソフトウェア・コンポーネント)をメタモデル化したクラス(以下、一般名称として「メタ部品クラス」という)の定義を含む。また、第1のメタモデル101aは、2つの部品間の通信のインタフェースをメタモデル化したクラス(以下、一般名称として「メタインタフェースクラス」という)の定義も含む。また、以下では部品とインタフェースをモデル化したクラスをそれぞれ、一般名称として「部品クラス」および「インタフェースクラス」ということもある。
The first
The
なお、図2では、各クラスの属性やメソッドは適宜省略されている。また、図2では、各属性と各関係(relationship)の可視性(visibility)として、それぞれプライベートであることを示す「-」とパブリックであることを示す「+」が指定されているが、可視性は、実施形態に応じて適宜指定することができる。 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.
具体的には、第1のメタモデル101aは、以下の各クラスの定義を含む。
ソフトウェアの部品のメタモデル化のために、「ComponentType」クラス201と「CompositionType」クラス202と「ComponentPrototype」クラス203が定義されている。「ComponentType」クラス201と「CompositionType」クラス202には、メタモデルで定義されたクラスであることを示す<<KeyElement>>というステレオタイプが付けられている。
Specifically, the
A “ComponentType”
なお、第1実施形態では、第1のメタモデル101a内のいくつかの基本的なクラスに<<KeyElement>>というステレオタイプを付加することで、コード生成装置108がコード生成時に第1のメタモデル101aを解釈しやすいようにしている。つまり、図1のプロセスP1で、メタモデル101と表記ルール102にしたがうモデル106からソースコード109を生成するとき、コード生成装置108は、モデル106と結び付けられたメタモデル101の解釈も行う。その際に、<<KeyElement>>というステレオタイプは、コード生成装置108に対して解釈の手がかりを与える。
In the first embodiment, a stereotype << KeyElement >> is added to some basic classes in the
なお、メタモデルは個々のユーザが定義するものではない。つまり、図2の各クラスは、個々のユーザが定義するものではない。したがって、第1のメタモデル101aに含まれるクラスにステレオタイプが付与されていても、ユーザの設計の自由度を束縛することにはならない。
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
「CompositionType」クラス202は上記メタ部品クラスの一例である。「CompositionType」クラス202のスーパクラスである「ComponentType」クラス201は、メタ部品クラスをさらに抽象化したアブストラクトクラスであるから、メタ部品クラスの一種であるとも言える。「ComponentType」クラス201には、複数のインスタンスを持ってもよいか否かを示す「supportMultipleInstantiation」という名前のブール(boolean)型の変数が、属性として定義されている。「ComponentPrototype」クラス203は、部品間の入れ子関係のメタモデル化のために定義されている。
The “CompositionType”
また、部品がパラメタを有してもよいことをメタモデル化するために、「ConfigParam」クラス204が定義されている。パラメタには名前があり、値が設定されることをメタモデル化して、「ConfigParam」クラス204には、「name」という名前の文字列(string)型の変数と、「value」という名前の変数が、属性として定義されている。パラメタの型は、ユーザにより定義される個々のクラスにおいて任意に設定されうるので、第1のメタモデル101a内の「ConfigParam」クラス204内では「value」属性の型は指定されていない。
Also, a “ConfigParam”
そして、ソフトウェアの部品は実行可能な部品であるということをメタモデル化するために、実行可能な実体(エンティティ)をメタモデル化した「RunnableEntity」クラス205が定義されている。そして、実行可能な実体には当該実体を呼び出すためのシンボルが割り当てられることのメタモデルとして、「RunnableEntity」クラス205では、「symbol」という名前の文字列型の変数が属性として定義されている。
In order to metamodel that the software component is an executable component, a “RunnableEntity”
また、タスクが部品を駆動することをメタモデル化するために、「Task」クラス206と「RunnableConnector」クラス207が定義されている。「Task」クラス206にも、第1のメタモデル101a中で定義されたクラスであることを示すための<<KeyElement>>というステレオタイプが付加されている。
In addition, a “Task”
タスクが所定の周期で部品を駆動する能力があることのメタモデルとして、「Task」クラス206には、上記所定の周期を示す「elapse」という名前の整数型の変数が属性として定義されている。また、タスクが部品を駆動する最初のタイミングが任意に指定されうることのメタモデルとして、上記最初のタイミングを示す「initTimer」という名前の整数型の変数も、「Task」クラス206の属性として定義されている。
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”
また、第1のメタモデル101aにおいて部品間の通信は、通信のインタフェースと、部品が備える通信用の入出力ポートと、入出力ポート間の接続をそれぞれメタモデル化することで、メタモデル化されている。なお、第1実施形態において、部品間の「通信」とは、ソフトウェアの部品間でのメッセージパッシング、すなわちデータ入出力を意味する。また、「ポート」も、物理的存在のことではなく、ソフトウェア上の仮想的なポートを意味する。同様に、「インタフェース」も、物理的存在ではなく、「通信」におけるデータ形式を意味し、ソフトウェア上のインタフェースのことを指している。
Further, communication between components in the first
具体的には、第1のメタモデル101aにおいて、インタフェースのメタモデル化のために、「Interface」クラス208と「SenderReceiverInterface」クラス209が定義されている。「SenderReceiverInterface」クラス209は、<<KeyElement>>というステレオタイプが付けられており、上記メタインタフェースクラスの一例である。「Interface」クラス208は、「Interface」クラス208を汎化したアブストラクトクラスであるから、メタインタフェースクラスの一種であるとも言える。
Specifically, in the
また、上記のとおりインタフェースはデータ形式のことであり、より具体的には、個々のデータ要素の集合体である。そこで、インタフェースに含まれる個々のデータ要素をメタモデル化した「DataElementPrototype」クラス210も定義されている。
Further, as described above, an interface is a data format, and more specifically, an aggregate of individual data elements. Therefore, a “DataElementPrototype”
また、部品が他の部品と通信するときのソフトウェア上の仮想的な入出力ポートは、「Port」クラス211としてメタモデル化されている。そして、「Port」クラス211には2つのサブクラスがある。1つは、他の部品からのメッセージを受ける入力ポートをメタモデル化した「RequesterPort」クラス212であり、もう1つは、他の部品へのメッセージを送り出す出力ポートをメタモデル化した「ProviderPort」クラス213である。
Further, a virtual input / output port on software when a component communicates with another component is metamodeled as a “Port”
さらに、ポート間の接続は「Connecter」クラス214としてメタモデル化されている。なお、「Connecter」クラス214には2つのサブクラスがある。
1つは、入れ子関係にない部品同士のポート間の接続をメタモデル化した「AssemblyConnector」クラス215である。もう1つは、入れ子関係にある外部部品と内部部品(換言すれば親部品と子部品)のポート間の接続をメタモデル化した「DelegateConnector」クラス216である。
Furthermore, connections between ports are metamodeled as “Connecter”
One is an “AssemblyConnector”
また、上記の各クラス間には、以下のような関係が定義されている。図1には、各関係に適宜ロール名も付けて図示している。なお、関連(association)を示す線における矢印は、誘導可能性(navigability)を示し、換言すれば、参照の方向を示す。 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.
汎化(generalization)251は、「ComponentType」クラス201が「CompositionType」クラス202のスーパクラスであることを示す。関連252は、「ComponentPrototype」クラス203が「ComponentType」クラス201を「typeRef」というロール名で参照することを示し、多重度は「1」である。また、多重度が「0..*」の集約(aggregation)253は、「CompositionType」クラス202が、「component」というロール名で「ComponentPrototype」クラス203を任意の個数含みうることを示す。
A
また、多重度が「0..*」の集約254は、「ComponentType」クラス201が「ConfigParam」クラス204を任意の個数含みうることを示す。そして、多重度が「1..*」の集約255は、「ComponentType」クラス201が「RunnableEntity」クラス205を1つ以上の任意の個数含むことを示す。つまり、集約254と集約255は、部品がパラメタを含みうることと、部品が実行可能であることをメタモデル化したものである。
An
そして、実行可能な実体は、他の実行可能な実体を呼び出したり自分自身を再帰的に呼び出したりすることができる。このことをメタモデル化したものが、「RunnableEntity」クラス205から「RunnableEntity」クラス205自身への、「call」というロール名での参照を表す関連256である。
An executable entity can then call other executable entities or call itself recursively. A meta model of this is a
そして、タスクが部品を呼び出して駆動することは、タスクと部品との間の接続を表す集約257と関連258によりメタモデル化される。具体的には、集約257は、「Task」クラス206が1つ以上の任意の個数の「RunnableConnector」クラス207を含むことを示す、多重度が「1..*」の集約である。また、関連258は、「RunnableConnector」クラス207が「RunnableEntity」クラス205を「runnable」というロール名で参照することを示す、多重度が「1」の関連である。集約257と関連258により、1つのタスクが1つ以上の部品のそれぞれを呼び出して駆動することがメタモデル化されている。
Then, the task calling and driving the part is metamodeled by an
また、部品がポートを持ちうることのメタモデルとして、多重度が「0..*」の集約259は、「ComponentType」クラス201が「Port」クラス211を含みうることを示す。「ComponentType」クラス201にとっての「Port」クラス211のロール名は「ports」であり、「Port」クラス211にとっての「ComponentType」クラス201のロール名は「component」である。
Further, as a meta model that a component can have a port, an
汎化260と汎化261はそれぞれ、「RequesterPort」クラス212と「ProviderPort」クラス213が「Port」クラス211のサブクラスであることを示す。
多重度が「1」の関連262は、「Port」クラス211が「interfaceRef」というロール名で「Interface」クラス208を参照することを示す。関連262は、2つのポート間の通信が、当該2つのポートに適合する所定のインタフェースによって行われることをメタモデル化したものである。
The
An
そして、汎化263は、「Interface」クラス208が「SenderReceiverInterface」クラス209のスーパクラスであることを示す。
また、多重度が「0..*」の合成集約(composition)264は、「SenderReceiverInterface」クラス209が「DataElementPrototype」クラス210を任意の個数含みうることを示す。すなわち、合成集約264は、インタフェースが個々のデータ要素の集合体であることをメタモデル化したものである。
The
Also, a
なお、「DataElementPrototype」クラス210にとっての「SenderReceiverInterface」クラス209は「interface」というロール名を持つ。また、「SenderReceiverInterface」クラス209にとっての「DataElementPrototype」クラス210は「dataElement」というロール名を持つ。
The “SenderReceiverInterface”
そして、ポート間の接続に関しては、以下のような関係が定義されている。すなわち、汎化265と汎化266はそれぞれ、「AssemblyConnector」クラス215と「DelegateConnector」クラス216が「Connecter」クラス214のサブクラスであることを示す。
The following relationship is defined for connection between ports. That is,
また、いずれも多重度が「0..*」の集約267と集約268は、「CompositionType」クラス202が「AssemblyConnector」クラス215と「DelegateConnector」クラス216をそれぞれ任意の個数含みうることを示す。集約267と集約268は、部品同士が接続されうること(すなわち部品同士が通信可能であること)をメタモデル化したものである。
In addition, the
また、それぞれ多重度が「1」の関連269と関連270は、「AssemblyConnector」クラス215が示す接続を、当該接続の両端のポートに対応付ける。つまり、関連269は、部品間の通信のための接続を示す「AssemblyConnector」クラス215が、通信におけるデータの出力元のポートとして、「Port」クラス211を「pPortRef」というロール名で参照することを示している。同様に、関連270は、「AssemblyConnector」クラス215が、通信におけるデータの入力先のポートとして「Port」クラス211を「rPortRef」というロール名で参照することを示している。
Further, the
同様に、それぞれ多重度が「1」の関連271と関連272は、「DelegateConnector」クラス216が示す接続を、当該接続の両端のポートに対応付ける。つまり、関連271は、入れ子関係にある外部部品と内部部品の間の接続を示す「DelegateConnector」クラス216が、内部部品側のポートとして、「Port」クラス211を「innerPortRef」というロール名で参照することを示している。同様に、関連272は、「DelegateConnector」クラス216が、外部部品側のポートとして、「Port」クラス211を「outerPortRef」というロール名で参照することを示している。
Similarly, the
以上のとおり、第1のメタモデル101aによれば、部品をメタモデル化した「CompositionType」クラス202は「ComponentType」クラス201のサブクラスである。よって、「CompositionType」クラス202は、「RunnableEntity」クラス205を含み、「ConfigParam」クラス204と「Port」クラス211を含みうる。
As described above, according to the
つまり、第1のメタモデル101aは、部品は駆動可能であること、部品はパラメタを含みうること、および部品は他の部品と通信するためのポートを含みうることを表している。そして、部品が含みうるポートとは、具体的には、「RequesterPort」クラス212に対応する入力ポートか、「ProviderPort」クラス213に対応する出力ポートである。
That is, the
また、第1のメタモデル101aは、いくつかのデータ要素の集合体として定義されるインタフェースを、「SenderReceiverInterface」クラス209と「DataElementPrototype」クラス210によりメタモデル化している。そして、「SenderReceiverInterface」クラス209を汎化した「Interface」クラス208を「Port」クラス211が参照していることは、2つのポート間の通信が、何らかの所定のインタフェースを介して行われることをメタモデル化したものである。
Also, the
また、各部品は、入れ子関係にない他の部品との間がポートを介して接続されるかもしれない。このことは、「CompositionType」クラス202が「AssemblyConnector」クラス215を含みうると示す集約267により、メタモデル化されている。
In addition, each part may be connected to other parts that are not nested through a port. This is metamodeled by an
さらに、部品同士の入れ子関係が可能であるということが次のようにメタモデル化されている。すなわち、部品をメタモデル化した「CompositionType」クラス202を汎化した「ComponentType」クラス201を「ComponentPrototype」クラス203が参照しており、その「ComponentPrototype」クラス203が「CompositionType」クラス202に含まれることを集約253が示す。これにより、外部部品に内部部品が含まれる入れ子関係が可能であるということがメタモデル化される。
Further, the metamodeling that parts can be nested is possible as follows. That is, the “ComponentPrototype”
そして、外部部品と内部部品それぞれのポート間が接続されることで、外部部品と内部部品との間の通信が可能であることは、任意の部品同士がポート間の接続により通信可能であることと同様である。 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.
つまり、外部部品と内部部品それぞれのポート間の接続は、「DelegateConnector」クラス216によりメタモデル化されている。外部部品と内部部品がポートを介して接続されうることは、「CompositionType」クラス202が「DelegateConnector」クラス216を含みうることを示す集約268により、メタモデル化されている。
That is, the connection between the ports of the external component and the internal component is metamodeled by the “DelegateConnector”
続いて、図1のメタモデル101として図2の第1のメタモデル101aが使われる場合の、図1のモデル図105の具体例を、図3を参照して説明する。図3に示すのは、第1のメタモデル101aにしたがうモデル図105aであり、具体的には、第1実施形態の表記ルール102にしたがって拡張されたUMLのクラス図である。なお、以下では、拡張されたクラス図およびオブジェクト図のことも、単に「クラス図」および「オブジェクト図」という。
Next, a specific example of the model diagram 105 in FIG. 1 when the first
なお、後述するように、モデル図105はクラス図だけに限られず、オブジェクト図やシーケンス図などでもよい。また、複数のモデル図105により1つのモデルが表されてもよい。 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.
モデル図105aは、図1のプロセスP101の結果として作られる。詳細は図10とともに後述するが、プロセスP101は、UMLツール103とDSM支援装置104が協働して、制約条件のもとでユーザからの指示に応じてソフトウェアのモデルを編集する処理である。プロセスP101でUMLツール103とDSM支援装置104は、編集したモデルを、UMLデータであるモデル図105、およびXMLデータであるモデル106の形で出力する。つまり、図3のモデル図105aは、制約条件を満たすクラス図である。
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
具体的には、図3のモデル図105aは、第1のメタモデル101aに含まれる「CompositionType」クラス202と「SenderReceiverInterface」クラス209を含む。なお、図3では、第1のメタモデル101aが「メタモデル」という名のパッケージに含まれるものとして、「メタモデル::CompositionType」のようにパスを使ってクラス名を表現している。
Specifically, the model diagram 105a of FIG. 3 includes a “CompositionType”
モデル図105aは、ユーザ定義の2つのクラス、すなわち、「部品A」クラス301と「インタフェースA」クラス302を含む。「部品A」クラス301は、「受信ポート」および「送信ポート」という名前の2つのポート303と304を含む。
The model diagram 105a includes two user-defined classes: a “part A”
なお、以下ではポート303と304をそれぞれ「『受信ポート』ポート」と「『送信ポート』ポート」という。同様に、「ZZZ」という名前でインスタンス化された、「Port」クラス211のサブクラスのオブジェクトを「『ZZZ』ポート」という。
In the following description, the
第1実施形態において、第1のメタモデル101aにおける「RequesterPort」クラス212のオブジェクトは、図3の「受信ポート」ポート303のように、矩形の中に逆V字を書いた記号で表記される。そして、第1のメタモデル101aにおける「ProviderPort」クラス213のオブジェクトは、図3の「送信ポート」ポート304のように、矩形の中に黒い三角形を描いた記号で表記される。
In the first embodiment, an object of the “RequesterPort”
また、モデル図105aでは、「部品A」クラス301が「CompositionType」クラス202のサブクラスであることを示す汎化305が定義されている。同様に、モデル図105aでは、「インタフェースA」クラス302が「SenderReceiverInterface」クラス209のサブクラスであることを示す汎化306も定義されている。
Further, in the model diagram 105 a, a
さらに、モデル図105aでは、「受信ポート」ポート303から「インタフェースA」クラス302への依存307と、「送信ポート」ポート304から「インタフェースA」クラス302への依存308が定義されている。
Further, in the model diagram 105 a, a
以上のような内容を持つモデル図105aは、図2の第1のメタモデル101aおよび図1の表記ルール102に適合する。換言すれば、モデル図105aは、第1のメタモデル101aにしたがって作成されたモデルを表すUMLのクラス図であり、表記ルール102が表す制約条件を満たしている。具体的には以下の(c1)〜(c7)のとおりである。
The model diagram 105a having the above contents conforms to the first
(c1)表記ルール102は、「部品をモデル化したクラスは、『CompositionType』クラス202のサブクラスとして表記せよ」というルールを含む。モデル図105aは表記ルール102にしたがって表記されている。
(C1) The
すなわち、「部品A」クラス301が「CompositionType」クラス202のサブクラスであることが、汎化305の線によって図3のクラス図上で表記されている。その結果、モデル図105aでは、「『部品A』クラス301は、(インタフェースなどではなく)部品をモデル化したクラスである」という意味が示されている。
That is, the fact that the “component A”
(c2)第1のメタモデル101aによれば、図2に示したとおり、「ComponentType」クラス201とそこから派生するクラスは、「Port」クラス211を含みうる。よって、モデル図105aにおいて、「部品A」クラス301が「受信ポート」ポート303と「送信ポート」ポート304を含むことは、図2の第1のメタモデル101aと適合している。
(C2) According to the
(c3)表記ルール102は、「インタフェースをモデル化したクラスは、『SenderReceiverInterface』クラス209のサブクラスとして表記せよ」というルールを含む。モデル図105aは表記ルール102にしたがって表記されている。
(C3) The
すなわち、「インタフェースA」クラス302が「SenderReceiverInterface」クラス209のサブクラスであることが、汎化306の線によって図3のクラス図上で表記されている。その結果、モデル図105aでは、「『インタフェースA』クラス302は、(部品などではなく)インタフェースをモデル化したクラスである」という意味が示されている。
That is, the fact that the “interface A”
(c4)表記ルール102は、「あるインタフェースを介したポート間の通信は、通信の両端のポートに相当する2つのオブジェクトから、同じ1つのインタフェースのクラスへの依存により表記せよ」というルールを含む。モデル図105aは表記ルール102にしたがって表記されている。
(C4) The
つまり、「部品A」クラス301の「受信ポート」ポート303への入力が、「インタフェースA」クラス302によりモデル化されるインタフェースを介して行われるということが、モデル図105aでは依存307により表記されている。同様に、「部品A」クラス301の「送信ポート」ポート304からの出力が、「インタフェースA」クラス302によりモデル化されるインタフェースを介して行われるということが、モデル図105aでは依存308により表記されている。
That is, the input to the “reception port”
したがって、「部品A」クラス301のインスタンス間の通信が、「インタフェースA」クラス302によりモデル化されているインタフェースを介して行われるということが、モデル図105aにおいては依存307と308により表されている。
Accordingly, the inter-instance communication of the “component A”
(c5)表記ルール102は、「部品をモデル化したクラス内でユーザが定義した属性に対し、第1のメタモデル101aの『ConfigParam』クラス204と同名の<<ConfigParam>>というステレオタイプを付加してもよい」というルールを含む。そして、表記ルール102は、「<<ConfigParam>>というステレオタイプが付加された属性は、当該部品を利用する際に当該部品に特徴を与えるパラメタであることを意味する」という、意味の解釈に関するルールも含む。
(C5) The
モデル図105aは表記ルール102にしたがって表記されており、「部品A」クラス301において、ユーザが定義した「パラメタ」という名前の整数型の属性には、<<ConfigParam>>というステレオタイプが付加されている。なお、「部品A」クラス301自体に対してステレオタイプが付加される訳ではないので、ユーザは、「部品A」クラス301に任意のステレオタイプを付加する自由を依然として持っている。
The model diagram 105a is written according to the
(c6)表記ルール102は、「部品をモデル化したクラス内でユーザが定義したパブリックな操作に対し、第1のメタモデル101aの『RunnableEntity』クラス205と同名の<<RunnableEntity>>というステレオタイプを付加してもよい」というルールを含む。
(C6) The
そして、表記ルール102は、「<<RunnableEntity>>というステレオタイプが付加された操作は、当該部品を駆動するために外部のタスクから呼び出し可能なパブリックな操作である」という、意味の解釈に関するルールも含む。具体的には、表記ルール102によれば、<<RunnableEntity>>というステレオタイプが付加された操作は「RunnableEntity」クラス205のインスタンスとして解釈される。
The
モデル図105aは表記ルール102にしたがって表記されており、「部品A」クラス301において、ユーザが定義した「実行ポイント」という名前の、返り値を持たない関数には、<<RunnableEntity>>というステレオタイプが付加されている。なお、「部品A」クラス301自体に対してステレオタイプが付加される訳ではないので、ユーザは、「部品A」クラス301に任意のステレオタイプを付加する自由を依然として持っている。
The model diagram 105a is written in accordance with the
(c7)第1のメタモデル101aによれば、図2に示したとおり、「SenderReceiverInterface」クラス209が「DataElementPrototype」クラス210を含みうる。
よって、モデル図105aにおいて、「SenderReceiverInterface」クラス209のサブクラスである「インタフェースA」クラス302が2つのデータ要素を属性として含むことは、第1のメタモデル101aと適合している。つまり、「インタフェースA」クラス302の属性として定義された「要素1」および「要素2」という名前の整数型の2つの属性は、メタモデルにおける「DataElementPrototype」クラス210が、モデルにおいてインスタンス化されたものである。
(C7) According to the
Therefore, in the model diagram 105a, the fact that the “interface A”
以上の(c1)〜(c7)のように、表記ルール102は、メタモデル101にしたがったモデル図105における表記の文法(シンタックス)を規定する。また、メタモデル101と表記ルール102は、当該文法にしたがって表記されたUMLの図の意味(セマンティクス)も規定している。
As described above (c1) to (c7), the
そして、図1のプロセスP101において、UMLツール103とDSM支援装置104は協働して、上記の(c1)〜(c7)で説明したように制約条件に適合するようにモデル図105を作成する。以下、図4を参照して、UMLツール103、DSM支援装置104、およびコード生成装置108についてさらに詳しく説明する。
In the process P101 of FIG. 1, the
図4は、第1実施形態によるDSM支援装置およびその他の装置を示すブロック図である。図4には、図1のUMLツール103、DSM支援装置104、コード生成装置108と、その他の装置が図示されている。
FIG. 4 is a block diagram showing the DSM support device and other devices according to the first embodiment. FIG. 4 shows the
図4において、入力装置401は、キーボード、マウス等のポインティングデバイス、タッチパネル、マイクなど、ユーザからの入力を受け付けるための装置である。また、出力装置402は、UMLの各種の図(クラス図、オブジェクト図、シーケンス図など)の図形を表示するディスプレイや、これらの図を印刷するプリンタなどの装置である。
In FIG. 4, an
UMLツール103は、入力装置401および出力装置402と接続された(あるいは入力装置401と出力装置402を備える)コンピュータがプログラムを実行することで実現される。
The
具体的には、UMLツール103は、入力装置401および出力装置402との間のユーザインタフェースを提供する。そして、UMLツール103は、入力装置401とユーザインタフェースを介してユーザから与えられる指示に応じて、UMLの各種の図(クラス図、オブジェクト図、シーケンス図など)を出力装置402に出力する。UMLツール103は、例えば上記(a2)で述べたのと同様のエディタであってもよい。
Specifically, the
また、第1実施形態におけるDSM支援装置104は、具体的には、コンピュータがプログラムを実行することにより実現される。第1実施形態においてDSM支援装置104を実現するプログラムは、UMLツール103を実現するプログラムに対するアドオンプログラムである。もちろん、実施形態によっては、UMLツール103とDSM支援装置104の機能を併せて実現するプログラムをコンピュータが実行することで、UMLツール103とDSM支援装置104が1つに統合されてもよい。
Further, the
DSM支援装置104は、具体的には、図4に示すようにモデル作成ナビゲーション部403を備える。モデル作成ナビゲーション部403は、メタモデル101と表記ルール102に基づいて、UMLツール103の動作に制約をかける。
Specifically, the
具体的には、モデル作成ナビゲーション部403は、メニュー選択部404、部品用メニュー提供部405、ポート用メニュー提供部406、インタフェース用メニュー提供部407、内部部品用メニュー提供部408およびタスク用メニュー提供部409を備える。また、DSM支援装置104はさらに、XMLなどの所定の言語によって図1のモデル106を作成するモデル作成部410を備える。
Specifically, the model
なお、第1実施形態において、図1の表記ルール102は、DSM支援装置104内の各コンポーネントに、制御ロジックとして組み込まれている。DSM支援装置104の動作の詳細は、図10および11とともに後述する。
In the first embodiment, the
また、例えばハードディスク装置やRAM(Random Access Memory)などの記憶装置411が設けられている。記憶装置411は、モデル図格納部412、意味モデル格納部413、テンプレート格納部414、ソースコード格納部415およびメタモデル格納部416を備える。
Further, for example, a
モデル図格納部412は、図1のプロセスP101で作成・編集される、UMLで表記された、図1のモデル図105(具体例は、例えば図3のモデル図105a)を格納する。意味モデル格納部413は、同じくプロセスP101で作成・編集され、モデル図105の意味をXMLにより表す、図1のモデル106(具体例は、例えば図9A〜9Dのモデル106a)を格納する。
The model
テンプレート格納部414は、XSLで表されて予め用意された、図1のコード生成テンプレート107を格納する。ソースコード格納部415は、図1のプロセスP102で生成される、C++やJava(登録商標)等のプログラミング言語のソースコード109を格納する。
The
メタモデル格納部416は、UMLで表記されて予め用意された、図1のメタモデル101(具体例は、例えば図2の第1のメタモデル101a)を格納する。
以上の各部の動作は、詳しくは図10〜12とともに説明するが、概要は以下のとおりである。
The
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.
モデル作成ナビゲーション部403は、メタモデル101と表記ルール102にしたがって制約条件を満たしつつソフトウェアをモデル化するための、各種メニューを提供する。具体的には、モデル作成ナビゲーション部403は、UMLツール103の動作に制約をかけるため、UMLツール103を監視する。
The model
そして、入力装置401がユーザからの入力をUMLツール103へ渡すと、その入力を契機としてモデル作成ナビゲーション部403は、入力の内容に応じて内部の適宜のコンポーネントを呼び出して処理を行わせる。また、モデル作成ナビゲーション部403は、処理の結果に基づいてモデル106を作成あるいは編集するよう、モデル作成部410に命令し、モデル作成部410はモデル106を作成あるいは編集する。
Then, when the
具体的には、モデル作成ナビゲーション部403は、部品全般、ポート、インタフェース、内部部品、タスクそれぞれのモデル化のための各メニューと、メニュー選択のユーザインタフェースを提供する。UMLツール103が受け取った入力がメニュー選択のための入力であれば、モデル作成ナビゲーション部403においてメニュー選択部404が、選択されたメニューに対応するコンポーネントを呼び出す。
Specifically, the model
なお、モデル作成ナビゲーション部403は、例えば、後述の図11の駆動順序定義処理のためのメニューなど、上記以外の他のメニューをさらに提供してもよいが、図4では紙幅の都合上、他のメニューに関わるコンポーネントは図示を省略している。
Note that the model
さて、部品のモデル化のためのメニューを選択する入力をUMLツール103が受け取った場合、メニュー選択部404は、部品用メニュー提供部405を呼び出す。また、ポートのモデル化のためのメニューを選択する入力をUMLツール103が受け取った場合、メニュー選択部404は、ポート用メニュー提供部406を呼び出す。
When the
同様に、インタフェースのモデル化のためのメニューを選択する入力をUMLツール103が受け取った場合、メニュー選択部404は、インタフェース用メニュー提供部407を呼び出す。そして、内部部品のモデル化のためのメニューを選択する入力をUMLツール103が受け取った場合、メニュー選択部404は、内部部品用メニュー提供部408を呼び出す。また、タスクのモデル化のためのメニューを選択する入力をUMLツール103が受け取った場合、メニュー選択部404は、タスク用メニュー提供部409を呼び出す。
Similarly, when the
そして、各メニューが選択された後で、各メニューにおける詳細設定のための入力をUMLツール103が受け取った場合、モデル作成ナビゲーション部403は、当該メニューに対応するコンポーネントに入力内容を渡す。
When the
例えば、部品用のメニューが選択された後、部品をモデル化したクラスを新規作成するための入力をUMLツール103が受け取ったら、その入力をモデル作成ナビゲーション部403がフックして、部品用メニュー提供部405に渡す。そして、部品用メニュー提供部405は、入力にしたがってクラスを新規作成する。
For example, after the menu for a part is selected, when the
その際、部品用メニュー提供部405は、UMLで表記されメタモデル格納部416に格納された図1のメタモデル101を読み出す。そして、部品用メニュー提供部405は、制御ロジックとして部品用メニュー提供部405自身に組み込まれている図1の表記ルール102と、読み出したメタモデル101にしたがって、制約をかけながら、部品をモデル化したクラスを新規作成する。
At that time, the component
新規作成されたクラスの情報は、部品用メニュー提供部405を含むモデル作成ナビゲーション部403からUMLツール103へと通知される。すると、UMLツール103は、通知された情報に基づいて、新規作成されたクラスを表す図形を出力装置402に出力させる。例えば、UMLツール103は、新規作成されたクラスを示す矩形をディスプレイに描画するとともに、図3の汎化305の線をディスプレイに描画するよう、出力装置402に命令する。
Information on the newly created class is notified from the model
また、新規作成されたクラスの情報は、モデル作成部410にも通知される。すると、モデル作成部410は、通知された情報に基づいて、新規作成されたクラスに対応するXMLコードを生成することで、モデル106を随時編集してゆく。
Information on the newly created class is also notified to the
以上、部品のモデル化のためのメニューを例として部品用メニュー提供部405に関わる動作を説明したが、他のメニューについても同様である。
つまり、入力装置401からの入力がUMLツール103を介してモデル作成ナビゲーション部403に入力される。そして、各メニューに対するコンポーネントの制御下で、UMLの図形に関する情報がUMLツール103に戻され、UMLツール103が図形を出力装置402に出力させ、UMLの図形に対応する意味を表すモデル106がモデル作成部410により編集される。
The operation related to the part
That is, an input from the
以上のようにして、入力装置401とUMLツール103を介した入力に基づいて、モデルが作成され、編集される。つまり、部品、ポート、インタフェース、内部部品、タスクなどが、適宜、作成ないし編集されることで、モデル全体の編集が行われる。
As described above, the model is created and edited based on the input via the
その結果として最終的に得られたモデル図105は、UMLツール103を介してモデル図格納部412に格納される。同様に、最終的に得られたモデル106は、モデル作成部410から意味モデル格納部413に出力され、格納される。
The model diagram 105 finally obtained as a result is stored in the model
すると、図1のプロセスP102に示すように、コード生成装置108が意味モデル格納部413からモデル106を読み出し、テンプレート格納部414からコード生成テンプレート107を読み出して、ソースコード109を生成する。そして、コード生成装置108は生成したソースコード109をソースコード格納部415に格納する。
Then, as shown in process P102 of FIG. 1, the
したがって、ドメインに特有の事項を組み込んだメタモデル101が予め作成されていれば、DSM支援装置104による制約条件の適用下において、UMLツール103を介して、UMLを用いたDSMによるモデル作成が可能となる。そして、メタモデル101と表記ルール102にしたがった解釈のもとでモデル図105と意味的に等価なモデル106からは、自動的にソースコード109が生成される。
Therefore, if a
よって、第1実施形態によれば、UMLを使用する際の上記(a1)〜(a3)の利点を活かしつつ、DSMによる設計における(b1)〜(b5)のような欠点を克服することができる。 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.
また、図3に関して説明したように、第1実施形態では、ユーザ定義のクラスに対してステレオタイプを付加しなくても、例えば汎化関係などからモデル図105における矩形や線の意味が自動的に解釈可能である。したがって、第1実施形態には、上記比較例と比べて設計の自由度が大きいという利点もある。 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.
ところで、図4に示す各ブロックを実現するハードウェアは、例えば図5に示すものでもよい。例えば、図4のUMLツール103、DSM支援装置104およびコード生成装置108は、1台のコンピュータにより実現されてもよく、入力装置401、出力装置402および記憶装置411が当該コンピュータに備えられていてもよい。図5はそのような場合の例を示す。
Incidentally, the hardware for realizing each block shown in FIG. 4 may be, for example, that shown in FIG. For example, the
図5は、コンピュータの構成図である。図5のコンピュータ500は、CPU(Central Processing Unit)501と、ROM(Read Only Memory)502と、RAM503と、通信インタフェース504を備える。また、コンピュータ500は、図4に示した入力装置401と出力装置402を備える。コンピュータ500はさらに、ハードディスク装置505と、コンピュータ読み取り可能な可搬型記憶媒体506の駆動装置507を備える。
FIG. 5 is a configuration diagram of the computer. A
実施形態によっては、ハードディスク装置505のような磁気記憶装置に代えて、あるいはハードディスク装置505とともに、フラッシュメモリ等の不揮発性の半導体メモリ装置をコンピュータ500が備えていてもよい。また、可搬型記憶媒体506としては、例えば、CD(Compact Disc)やDVD(Digital Versatile Disk)などの光ディスク、光磁気ディスク、磁気ディスク、フラッシュメモリ等の半導体メモリカードなどが利用可能である。
Depending on the embodiment, the
そして、CPU501、ROM502、RAM503、通信インタフェース504、入力装置401、出力装置402、ハードディスク装置505および駆動装置507は、バス508により接続されている。また、コンピュータ500は、通信インタフェース504を介してネットワーク509に接続されている。
The CPU 501,
ネットワーク509は、LAN(Local Area Network)やインターネットなど、任意のネットワークである。ネットワーク509には、プログラム提供者510のコンピュータが接続されていてもよい。
The network 509 is an arbitrary network such as a LAN (Local Area Network) or the Internet. A computer of the
図4のUMLツール103とDSM支援装置104とコード生成装置108は、いずれも、CPU501がプログラムをRAM503にロードし、RAM503をワークエリアとして利用しながらプログラムを実行することにより、実現される。
All of the
UMLツール103とDSM支援装置104とコード生成装置108をそれぞれ実現するための各プログラムは、ROM502またはハードディスク装置505に予め記憶されていてもよい。あるいは、各プログラムは、可搬型記憶媒体506に記憶され、駆動装置507にセットされた可搬型記憶媒体506から一旦ハードディスク装置505へ読み出されてもよい。または、各プログラムは、プログラム提供者510から提供され、ネットワーク509と通信インタフェース504を介してコンピュータ500にダウンロードされてもよい。
Each program for realizing the
また、図4の記憶装置411は、ROM502、RAM503、ハードディスク装置505、上記の不図示の不揮発性の半導体メモリ装置および可搬型記憶媒体506のうち1つ以上のものを任意に組み合わせて実現することができる。
Also, the
なお、図5はハードウェア構成の一例にすぎず、実施形態によっては、UMLツール103、DSM支援装置104およびコード生成装置108が複数のコンピュータに分散されていてもよい。
Note that FIG. 5 is merely an example of a hardware configuration, and the
続いて、図6〜12を参照して、以上説明した第1実施形態について、さらに詳しく説明する。
図6は、第1のメタモデルにしたがう第2のモデルを表すUMLのクラス図である。図2の第1のメタモデル101aからは、図3のモデル図105aのほかに、例えば図6のモデル図105bのように、入れ子になった部品を定義するモデルを表すクラス図を作成することもできる。つまり、図1のプロセスP101では、第1のメタモデル101aと表記ルール102により定義される制約条件を満たすモデル図105として、図6の第2のメタモデル101bが作られてもよい。
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
モデル図105bは、図3のモデル図105aと同様に、第1のメタモデル101aに含まれる「CompositionType」クラス202と「SenderReceiverInterface」クラス209を含む。また、第2のメタモデル101bは、モデル図105aと同様に、「インタフェースA」クラス302を含む。そして、図3と同様に図6でも、「インタフェースA」クラス302が「SenderReceiverInterface」クラス209のサブクラスであることが汎化306の線により示されている。
Similar to the model diagram 105a of FIG. 3, the model diagram 105b includes a “CompositionType”
さらに、モデル図105bは、ユーザ定義の「部品B」クラス601を含む。「部品B」クラス601は、図3のモデル図105aで定義されている「部品A」クラス301の2つのオブジェクト、すなわち「P1」オブジェクト602と「P2」オブジェクト603を含む。また、「部品B」クラス601は、「入力1」ポート604および「出力1」ポート605を含む。
Further, the model diagram 105 b includes a user-defined “part B”
なお、「入力1」ポート604は、第1のメタモデル101aにおける「RequesterPort」クラス212のオブジェクトなので、矩形の中に逆V字を書いた記号で表記されている。また、「出力1」ポート605は、第1のメタモデル101aにおける「ProviderPort」クラス213のオブジェクトなので、矩形の中に黒い三角形を描いた記号で表記されている。
Since the “
図3に示すように「部品A」クラス301は2つのポートを含むので、「部品A」クラス301のインスタンスである図6の「P1」オブジェクト602と「P2」オブジェクト603も、それぞれ2つのポートを含む。すなわち、「P1」オブジェクト602は「受信ポート」ポート606と「送信ポート」ポート607を含み、「P2」オブジェクト603は「受信ポート」ポート608と「送信ポート」ポート609を含む。
As shown in FIG. 3, since the “component A”
また、モデル図105bでは、「部品B」クラス601が「CompositionType」クラス202のサブクラスであることを示す汎化610が定義されている。汎化610により、「部品B」クラス601はインタフェースなどではなく部品をモデル化したクラスであるという意味が、モデル図105b上で表される。
In the model diagram 105 b, a
そして、モデル図105bでは、「入力1」ポート604と「受信ポート」ポート606の間のリンク611が定義されている。さらに、「送信ポート」ポート607と「受信ポート」ポート608の間のリンク612と、「送信ポート」ポート609と「出力1」ポート605の間のリンク613も定義されている。
In the model diagram 105b, a
また、モデル図105bでは、「入力1」ポート604から「インタフェースA」クラス302への依存614と、「出力1」ポート605から「インタフェースA」クラス302への依存615も定義されている。
In the model diagram 105b, a
以上のような内容を持つモデル図105bは、図2の第1のメタモデル101aおよび図1の表記ルール102に適合する。換言すれば、モデル図105bは、第1のメタモデル101aにしたがって作成されたモデルを表すUMLのクラス図であり、表記ルール102が表す制約条件を満たしている。具体的には以下の(d1)〜(d8)のとおりである。
The model diagram 105b having the above contents conforms to the
(d1)図3に関する(c1)と同様に、モデル図105bでは、「『部品B』クラス601は部品をモデル化したクラスである」という意味が、汎化610により示されている。
(D1) Similar to (c1) with respect to FIG. 3, in the model diagram 105b, the
(d2)図3に関する(c2)と同様に、モデル図105bにおいて、「部品B」クラス601が「入力1」ポート604と「出力1」ポート605を含むことは、図2の第1のメタモデル101aと適合している。
(D2) As in (c2) with respect to FIG. 3, in the model diagram 105b, the “component B”
(d3)図3に関する(c3)と同様に、「『インタフェースA』クラス302はインタフェースをモデル化したクラスである」という意味が汎化306により示されている。
(D3) As in (c3) with respect to FIG. 3, the
(d4)図3に関する(c4)と同様に、「部品B」クラス601の「入力1」ポート604への入力が、「インタフェースA」クラス302によりモデル化されるインタフェースを介して行われるということが、依存614により表記されている。また、「部品B」クラス601の「出力1」ポート605からの出力が、「インタフェースA」クラス302によりモデル化されるインタフェースを介して行われるということが、依存615により表記されている。
(D4) As in (c4) with respect to FIG. 3, input to the “
(d5)図3に関する(c6)と同様に、「部品B」クラス601において、ユーザが定義した「実行ポイント」という名前の、返り値を持たない関数には、<<RunnableEntity>>というステレオタイプが付加されている。
(D5) As in (c6) with respect to FIG. 3, in the “component B”
(d6)表記ルール102は、「入れ子関係にある外部部品と内部部品の間の通信は、外部部品と内部部品各々のポートを示す2つのオブジェクト間のリンクにより表記せよ」というルールを含む。より正確には、表記ルール102は、「外部部品と内部部品の間の通信を表記する上記リンクとしては、『RequesterPort』クラス212のインスタンス同士または『ProviderPort』クラス213のインスタンス同士の間のリンクのみが許される」というルールを含む。
(D6) The
また、表記ルール102は、「外部部品と内部部品各々のポートを示す2つのオブジェクト間のリンクは、第1のメタモデル101aにおける『DelegateConnector』クラス216のインスタンスであり、外部部品と内部部品の間の通信を意味する」という、意味の解釈に関するルールも含む。
Further, the
モデル図105b中のリンク611は、外部部品のポートを示す「入力1」ポート604と、内部部品のポートを示す「受信ポート」ポート606を接続するリンクである。また、「入力1」ポート604と「受信ポート」ポート606はともに「RequesterPort」クラス212のインスタンスである。よって、リンク611は表記ルール102に適合している。
A
また、モデル図105b中のリンク613は、外部部品のポートを示す「出力1」ポート605と、内部部品のポートを示す「送信ポート」ポート609と接続するリンクである。そして、「出力1」ポート605と「送信ポート」ポート609はともに「ProviderPort」クラス213のインスタンスである。よって、リンク613は表記ルール102に適合する。
A
そして、図4のモデル作成部410は、表記ルール102にしたがって、「リンク611とリンク613は、『DelegateConnector』クラス216のインスタンスであり、外部部品と内部部品の間の通信を意味する」と解釈する。
The
(d7)表記ルール102は、「入れ子関係にない2つの部品間の通信は、一方の部品が有する『ProviderPort』クラス213のオブジェクトと、他方の部品が有する『RequesterPort』クラス212のオブジェクトとの間のリンクにより表記せよ」というルールを含む。また、表記ルール102は、上記のようなリンクを、「第1のメタモデル101aにおける『AssemblyConnector』クラス215のインスタンスであり、入れ子関係にない2つの部品間の通信を意味する」という意味に解釈するルールも含む。
(D7) The
モデル図105b中のリンク612は、入れ子関係にない「P1」オブジェクト602と「P2」オブジェクト603の間のリンクである。正確には、リンク612は、「P1」オブジェクト602が有する「送信ポート」ポート607と、「P2」オブジェクト603が有する「受信ポート」ポート608との間のリンクである。つまり、リンク612は、「P1」オブジェクト602が有する「ProviderPort」クラス213のオブジェクトと、「P2」オブジェクト603が有する「RequesterPort」クラス212のオブジェクトとの間のリンクである。よってリンク612は表記ルール102に適合する。
A
そして、図4のモデル作成部410は、表記ルール102にしたがって、「リンク612は、『AssemblyConnector』クラス215のインスタンスであり、入れ子関係にない2つの部品間の通信を意味する」と解釈する。
Then, the
(d8)表記ルール102は、「部品間の通信を表記するためのポート間のリンクは、出力元のポートと出力先のポートが同じインタフェースクラスに対して依存関係を有していなくてはならない」というルールを含む。実施形態によっては、「出力元のポートが依存する第1のインタフェースクラスまたはそのサブクラスである第2のインタフェースクラスに対して、出力先のポートが依存関係を有していなくてはならない」というルールを表記ルール102が含んでもよい。
(D8) The
モデル図105bにおいて、「P1」オブジェクト602と「P2」オブジェクト603はともに図3で定義された「部品A」クラス301のインスタンスである。よって、「受信ポート」ポート606への入力と「送信ポート」ポート607からの出力は、いずれも、図3の定義のとおり、「インタフェースA」クラス302で定義されるインタフェースによるものである。同様に、「受信ポート」ポート608への入力と「送信ポート」ポート609からの出力も、「インタフェースA」クラス302で定義されるインタフェースによるものである。
In the model diagram 105b, a “P1”
また、図6で定義されているように、「部品B」クラス601の「入力1」ポート604への入力と、「部品B」クラス601の「出力1」ポート605からの出力も、「インタフェースA」クラス302で定義されるインタフェースによるものである。
Further, as defined in FIG. 6, the input to the “
以上から、リンク611、612、613のいずれにおいても、出力元のポートと出力先のポートが同じインタフェースクラスに対して依存関係を有している。したがって、リンク611、612、613はいずれも、表記ルール102に適合する。
As described above, in any of the
以上の(d1)〜(d8)で説明した制約条件を満たすように、図1のプロセスP101において、UMLツール103とDSM支援装置104は協働して、モデル図105bを作成する。
In the process P101 of FIG. 1, the
例えば、同じ「ProviderPort」クラス213のインスタンスである「送信ポート」ポート607と「送信ポート」ポート609の間にリンクを作成しようとする入力を、図4の入力装置401を介してUMLツール103が受け取っても、その入力は無効化される。つまり、上記(d7)の表記ルール102に適合しないリンクを作成しようとする入力は、DSM支援装置104により「不正な入力である」と判断され、UMLの図には反映されない。この場合、DSM支援装置104は、「不正な入力なので入力内容はUMLの図には反映されない」という旨の警告を、UMLツール103を介して出力装置402に出力してもよい。
For example, the
続いて、図7を参照して図1のモデル図105の他の例を説明する。
図7は、第1と第2のモデルを統合したモデルにより設計されたソフトウェアの全体構造を示すUMLのオブジェクト図である。つまり、図7は、図2のモデル図105aおよび図6のモデル図105bを統合したモデルに基づくオブジェクト図の形で、第1のメタモデル101aにしたがうモデル図105cが表現されている。
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
モデル図105aは、図3のモデル図105aと同様に、第1のメタモデル101aに含まれる「CompositionType」クラス202を含む。
また、モデル図105aは、<<TopLevel>>というステレオタイプが付加された「ソフトウェア全体」クラス701を含む。「ソフトウェア全体」クラス701は、1つのソフトウェアにつき1つのインスタンスしか持たない、ソフトウェアの最上位のメインルーチンに相当する特殊なクラスである。
The model diagram 105a includes the “CompositionType”
The model diagram 105a includes an “entire software”
よって、「ソフトウェア全体」クラス701に<<TopLevel>>というステレオタイプを付加したとしても、「ソフトウェア全体」クラス701内部に含まれる個々のクラスには、依然としてユーザが自由にステレオタイプを付加することが可能である。つまり、「ソフトウェア全体」クラス701に<<TopLevel>>というステレオタイプを付加することは、上記比較例のように設計の自由度を束縛することには当たらない。
Therefore, even if the stereotype << TopLevel >> is added to the “whole software”
「ソフトウェア全体」クラス701は、図3のモデル図105aで定義された「部品A」クラス301のインスタンスである「PART1」オブジェクト702を含む。また、「ソフトウェア全体」クラス701は、図6のモデル図105bで定義された「部品B」クラス601のインスタンスである「PART2」オブジェクト703も含む。図6のとおり、「部品B」クラス601は「部品A」クラス301の2つのインスタンスを含むので、「ソフトウェア全体」クラス701は、「部品A」クラス301のインスタンスを合計で3つ含むこととなる。
The “whole software”
また、「ソフトウェア全体」クラス701は、第1のメタモデル101aで定義されている「Task」クラス206のインスタンスである「T1」オブジェクト704を含む。「T1」オブジェクト704には、第1のメタモデル101aで定義されたクラスのオブジェクトである。
The “whole software”
また、「部品A」クラス301のインスタンスである「PART1」オブジェクト702は、図3における「部品A」クラス301の定義のとおり、2つのポート(すなわち「受信ポート」ポート705と「送信ポート」ポート706)を有する。そして、「部品B」クラス601のインスタンスである「PART2」オブジェクト703は、図6における「部品B」クラス601の定義のとおり、2つのポート(すなわち「入力1」ポート707と「出力1」ポート708)を有する。
Further, the “PART1”
なお、「ソフトウェア全体」クラス701がソフトウェアの部品であることは、「ソフトウェア全体」クラス701から「CompositionType」クラス202への汎化709により表されている。
The fact that the “whole software”
また、「ソフトウェア全体」クラス701内における「PART1」オブジェクト702と「PART2」オブジェクト703の間の通信は、「送信ポート」ポート706と「入力1」ポート707との間のリンク710により表されている。図3と図6の定義から明らかなように、リンク710は、図6に関して説明した(d7)と(d8)の表記ルール102に適合する。
The communication between the “PART1”
つまり、図4のDSM支援装置104は、リンクを作成しようとする指示のための入力に対して制約をかけることで、表記ルール102に適合するリンク710の作成を許し、表記ルール102に適合しないリンクの作成を拒絶する。それにより、表記ルール102に適合するモデル図105cが作成される。
That is, the
続いて、図8を参照して図1のモデル図105のさらに別の例を説明する。
図8は、図7のオブジェクト図に対応してソフトウェアの動作を定義するUMLのシーケンス図である。UMLツール103とDSM支援装置104が協働して図1のプロセスP101で編集するUMLの図の中には、図8のモデル図105dのようなシーケンス図も含まれる。
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
図8には、図7の「T1」オブジェクト704と「PART1」オブジェクト702と「PART2」オブジェクト703それぞれのライフラインを示す破線と、それぞれの活性期間(activation)801、802および803が定義されている。
In FIG. 8, the broken lines indicating the lifelines of the “T1”
また、図8には、「T1」オブジェクト704の活性期間801の初めの方で、「T1」オブジェクト704が「PART1」オブジェクト702を呼び出すことを示す呼び出し(call)804も定義されている。そして、その後「T1」オブジェクト704が「PART2」オブジェクト703を呼び出すことを示す呼び出し805も定義されている。つまり、モデル図105dは、「PART1」オブジェクト702が先に駆動され、「PART2」オブジェクト703が後に駆動されるという駆動の順序を定義している。
8 also defines a
呼び出し804のラベルは、図3の「部品A」クラス301において<<RunnableEntity>>というステレオタイプ付きで定義されている「実行ポイント」という操作を示している。また、呼び出し805のラベルは、図6の「部品B」クラス601において<<RunnableEntity>>というステレオタイプ付きで定義されている「実行ポイント」という操作を示している。なお、呼び出し804と805のラベルが同じなのは、偶然「部品A」クラス301と「部品B」クラス601で同名の操作が定義されているからである。
The label of the
図8のモデル図105dの作成にあたってDSM支援装置104が適用する制約条件としての表記ルール102は、例えば、下記(e1)〜(e2)のようなルールである。
(e1)表記ルール102は、「シーケンス図において、呼び出しを示す矢印の呼び出し元は、第1のメタモデル101aにおける『Task』クラス206のインスタンスまたは部品クラスで定義された操作でなくてはならない」というルールを含む。
The
(E1) The
図8において、呼び出し804と805の呼び出し元は、いずれも「Task」クラス206のインスタンスである「T1」オブジェクト704である。よって、図8のモデル図105dは、表記ルール102に適合する。
In FIG. 8, the caller of the
(e2)表記ルール102は、「シーケンス図において、呼び出しのラベルは、外部から呼び出し可能であることを示す<<RunnableEntity>>というステレオタイプが付加された操作の名前でなくてはならない」というルールを含む。
(E2) The
上記のとおり、呼び出し804と805のラベルである2つの「実行ポイント」は、それぞれ、図3と図6の定義において<<RunnableEntity>>というステレオタイプが付加された操作の名前である。よって、図8のモデル図105dは、表記ルール102に適合する。
As described above, the two “execution points” that are labels of the
以上の(e1)〜(e2)で説明した制約条件を満たすように、図1のプロセスP101において、UMLツール103とDSM支援装置104は協働して、モデル図105dを作成する。
In the process P101 of FIG. 1, the
例えば、図3のモデル図105aにおいて、仮に、「部品A」クラス301にさらに別の操作が定義されているものとし、便宜上、その操作の名前が「処理a」であるとする。また、「処理a」という操作に対しては、<<RunnableEntity>>というステレオタイプが付加されていないとする。
For example, in the model diagram 105a of FIG. 3, it is assumed that another operation is defined in the “part A”
以上の仮定のもとで、呼び出し804のラベルとして「処理a」を指定しようとする入力を、入力装置401およびUMLツール103を介してDSM支援装置104が受け取るとする。すると、モデル作成ナビゲーション部403は、入力が(e2)の制約に反することを検出する。制約違反の検出に応じて、モデル作成ナビゲーション部403は、例えば、UMLツール103を介して出力装置402に「不正な入力なので、別のラベルを指定せよ」という警告を表示させてもよい。
Based on the above assumptions, it is assumed that the
続いて、図9A〜9Dを参照して、図1のモデル106の例を説明する。
図9A〜9Dは、第1と第2のモデルを統合したモデルに対応するXMLデータを示す図である。図示の都合上4枚の図に分けて示してあるが、図9A〜9D全体で、図3、6〜8を統合したモデルを表す1つのXML文書となっており、図9A〜9Dに示すモデル106aは、図1のモデル106の一例である。
Next, an example of the
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
このように、複数枚にわたるUMLのモデル図105(例えば図3、6〜8)が全体として、1つのソフトウェアのモデルを表し、1つのモデル106(例えば図9A〜9D)に対応していてもよい。なお、参照の便宜のため、図9A〜9Dでは左側に行番号を示してある。 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.
なお、実施形態に応じてモデル106aでは任意の要素名を第1のメタモデル101aの各クラスに対応付けて使うことができる。以下では、「-REF」で終わる要素名は参照を表すものとする。
In the
図9A〜9Dに示すモデル106aは、具体的には以下の(f1)〜(f35)に述べる内容を有する。
(f1)モデル106aのルート要素は、「PACKAGE」要素である(1〜86行目)。1行目に示すように、「PACKAGE」要素には、「テスト」という名前を示す「Name」属性と、最上位要素であることを示す「TopLevelPackage」属性が指定されている。
The
(F1) The root element of the
また、「PACKAGE」要素は4つの子要素を有する。最初の3つの子要素は、図2の第1のメタモデル101aの「CompositionType」クラス202に対応する「COMPOSITION-TYPE」要素である。4つ目の子要素は、第1のメタモデル101aの「SenderReceiverInterface」クラス209に対応する「SENDER-RECEIVER-INTERFACE」要素である。
The “PACKAGE” element has four child elements. The first three child elements are “COMPOSITION-TYPE” elements corresponding to the “CompositionType”
(f2)「PACKAGE」要素の子要素のうち、1つ目の「COMPOSITION-TYPE」要素は、2〜28行目に当たり、「CompositionType」クラス202のサブクラスとして定義された図7の「ソフトウェア全体」クラス701を表す。そのため、2行目では、「ソフトウェア全体」クラス701のクラス名が「COMPOSITION-TYPE」要素の「Name」属性の値として指定されている。また、「ソフトウェア全体」クラス701には<<TopLevel>>というステレオタイプが付加されているので、2行目では「COMPOSITION-TYPE」要素の「TopLevel」属性の値が「True」となっている。
(F2) Of the child elements of the “PACKAGE” element, the first “COMPOSITION-TYPE” element hits
つまり、図4のモデル作成部410は図1のプロセスP101で、図7の汎化709に基づいて、モデル106aにおいて「ソフトウェア全体」クラス701を「COMPOSITION-TYPE」要素として表現する。また、モデル作成部410は図7の<<TopLevel>>というステレオタイプに基づいて、「COMPOSITION-TYPE」要素の「TopLevel」属性を設定する。それにより、モデル作成部410は、「『ソフトウェア全体』クラス701は最上位の部品を表す」という意味をモデル106a上で表す。
4 represents the “whole software”
(f3)「PACKAGE」要素の子要素のうち、2つ目の「COMPOSITION-TYPE」要素は、29〜44行目に当たり、「CompositionType」クラス202のサブクラスとして定義された図3の「部品A」クラス301を表す。そのため、29行目では、「部品A」クラス301のクラス名が「COMPOSITION-TYPE」要素の「Name」属性の値として指定されている。
(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”
上記(f2)と同様、モデル作成部410は、図3の汎化305に基づいて、モデル106aにおいて「部品A」クラス301を「COMPOSITION-TYPE」要素として表現することで、「『部品A』クラス301は部品を表す」という意味をモデル106a上で表す。
Similar to (f2) above, the
(f4)「PACKAGE」要素の子要素のうち、3つ目の「COMPOSITION-TYPE」要素は、45〜74行目に当たり、「CompositionType」クラス202のサブクラスとして定義された図6の「部品B」クラス601を表す。そのため、45行目では「部品B」クラス601のクラス名が「COMPOSITION-TYPE」要素の「Name」属性の値として指定されている。
(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.
上記(f2)と同様、モデル作成部410は、図6の汎化610に基づいて、モデル106aにおいて「部品B」クラス601を「COMPOSITION-TYPE」要素として表現することで、「『部品B』クラス601が部品を表す」という意味をモデル106a上で表す。
Similar to (f2) above, the
(f5)「PACKAGE」要素の4つ目の子要素である「SENDER-RECEIVER-INTERFACE」要素は、75〜85行目に当たり、「SenderReceiverInterface」クラス209のサブクラスとして定義された図3と図6の「インタフェースA」クラス302を表す。そのため、75行目では、「インタフェースA」クラス302のクラス名が「SENDER-RECEIVER-INTERFACE」要素の「Name」属性の値として指定されている。
(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”
上記(f2)と同様、モデル作成部410は、図3と図6の汎化306に基づいて、モデル106aにおいて「インタフェースA」クラス302を「SENDER-RECEIVER-INTERFACE」要素として表現する。それにより、モデル作成部410は、「『インタフェースA』クラス302がインタフェースを表す」という意味をモデル106a上で表す。
Similar to (f2) above, the
(f6)上記(f2)の「COMPOSITION-TYPE」要素(2〜28行目)は、5つの子要素を持つ。
1つ目の子要素は、3行目に示す空の「SUPER-ELEMENT」要素であり、空であることによって、図7の「ソフトウェア全体」クラス701が「CompositionType」クラス202から直接派生していることを表す。2つ目と3つ目の子要素は、第1のメタモデル101aの「ComponentPrototype」クラス203に対応する2つの「COMPONENT-PROTOTYPE」要素(4〜6行目と7〜9行目)である。
(F6) The “COMPOSITION-TYPE” element (
The first child element is an empty “SUPER-ELEMENT” element shown in the third line. By being empty, the “whole software”
4つ目の子要素は、第1のメタモデル101aの「AssemblyConnector」クラス215に対応する「ASSEMBLY-CONNECTOR」要素(10〜13行目)である。5つ目の子要素は、第1のメタモデル101aの「Task」クラス206に対応する「TASK」要素(14〜27行目)である。
The fourth child element is an “ASSEMBLY-CONNECTOR” element (10th to 13th lines) corresponding to the “AssemblyConnector”
(f7)第1のメタモデル101aでは、「CompositionType」クラス202が「ComponentPrototype」クラス203を含みうることを、集約253が示している。そして図7のモデル図105cは、この第1のメタモデル101aと表記ルール102にしたがって表記されており、「ソフトウェア全体」クラス701は「PART1」オブジェクト702と「PART2」オブジェクト703を含む。
(F7) In the
以上の構造に対応して、モデル106aでは、「ソフトウェア全体」クラス701に対応する上記(f2)の「COMPOSITION-TYPE」要素(2〜28行目)が、2つのオブジェクトに対応する2つの「COMPONENT-PROTOTYPE」要素(4〜6行目と7〜9行目)を子要素として持つ。
Corresponding to the above structure, in the
(f8)上記(f6)と(f7)で述べた1つ目の「COMPONENT-PROTOTYPE」要素(4〜6行目)は「PART1」オブジェクト702に対応するので、この「COMPONENT-PROTOTYPE」要素の「Name」属性には、オブジェクト名である「PART1」が指定されている(4行目)。
(F8) Since the first “COMPONENT-PROTOTYPE” element (
また、第1のメタモデル101aの関連252は、「ComponentPrototype」クラス203が「ComponentType」クラス201を参照することを示す。よって、第1のメタモデル101aと表記ルール102にしたがって表記されたモデル図105cの意味を表すモデル106aでは、「ComponentType」クラス201への参照を示す「COMPONENT-TYPE-REF」要素を、「COMPONENT-PROTOTYPE」要素が含む。具体的には、4〜6行目の「COMPONENT-PROTOTYPE」要素は、5行目に示す「COMPONENT-TYPE-REF」要素を含む。
The
(f9)この5行目の「COMPONENT-TYPE-REF」要素は、親要素である「COMPONENT-PROTOTYPE」要素(4〜6行目)が表す「PART1」オブジェクト702のクラスを示す情報を内容として含む。
(F9) The “COMPONENT-TYPE-REF” element on the fifth line contains information indicating the class of the “PART1”
なお、「PART1」オブジェクト702は「部品A」クラス301に属し、「部品A」クラス301は「CompositionType」クラス202のサブクラスであり、「CompositionType」クラス202は「ComponentType」クラス201のサブクラスである。よって、「ComponentType」クラス201への参照を示す「COMPONENT-TYPE-REF」要素によって、モデル106a上で、「COMPONENT-PROTOTYPE」要素(4〜6行目)に対応する「PART1」オブジェクト702のクラスを示すことができる。
The “PART1”
具体的には、5行目の「COMPONENT-TYPE-REF」要素は、「/テスト/部品A」という、パッケージ名(1行目の「Name」属性の値)とクラス名(29行目の「Name」属性の値)をスラッシュで結合したパスにより、「PART1」オブジェクト702のクラスを示す。パスがスラッシュから始まっているのは絶対パスであるためである。
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”
(f10)上記(f6)と(f7)で述べた2つ目の「COMPONENT-PROTOTYPE」要素(7〜9行目)は「PART2」オブジェクト703に対応するので、この「COMPONENT-PROTOTYPE」要素の「Name」属性には、オブジェクト名である「PART2」が指定されている(7行目)。そして、上記(f8)と同様に、7〜9行目の「COMPONENT-PROTOTYPE」要素は、8行目に示す「COMPONENT-TYPE-REF」要素を含む。
(F10) Since the second “COMPONENT-PROTOTYPE” element (
また、8行目の「COMPONENT-TYPE-REF」要素は、上記(f9)と同様に、「PART2」オブジェクト703のクラスを示す情報を内容として含む。すなわち、パッケージ名(1行目の「Name」属性の値)とクラス名(45行目の「Name」属性の値)を結合した「/テスト/部品B」というパスを、8行目の「COMPONENT-TYPE-REF」要素が内容として含む。
Also, the “COMPONENT-TYPE-REF” element on the eighth line includes information indicating the class of the “PART2”
(f11)第1のメタモデル101aにおいて「AssemblyConnector」クラス215からは、「Port」クラス211への参照を示す関連269と関連270の2本の線が出ている。よって、上記(f6)で述べた、「AssemblyConnector」クラス215に対応する「ASSEMBLY-CONNECTOR」要素(10〜13行目)は、関連269と関連270に対応する2つの子要素(11行目と12行目)を持つ。
(F11) In the
そして、図7のリンク710は、上記(d7)と(d8)の表記ルール102に適合している。上記(d7)によれば、「AssemblyConnector」クラス215のインスタンスたるリンクの両端は、「ProviderPort」クラス213と「RequesterPort」クラス212のオブジェクトである。よって、「ASSEMBLY-CONNECTOR」要素(10〜13行目)の2つの子要素とは、「ProviderPort」クラス213と「RequesterPort」クラス212各々への参照を示す「PROVIDER-PORT-REF」要素(11行目)と「REQUESTER-PORT-REF」要素(12行目)である。
The
つまり、10〜13行目の「ASSEMBLY-CONNECTOR」要素は、「ProviderPort」クラス213のオブジェクトである「送信ポート」ポート706と、「RequesterPort」クラス212のオブジェクトである「入力1」ポート707の間の、リンク710を示す。そして、「PROVIDER-PORT-REF」要素(11行目)と「REQUESTER-PORT-REF」要素(12行目)という2つの子要素が、リンク710の両端のポートを示す。なお、10行目に示すように、「ASSEMBLY-CONNECTOR」要素の「Name」属性には、リンク710に割り当てられた図7には不図示の「asmConn_1」という名前が指定されている。
That is, the “ASSEMBLY-CONNECTOR” element on the 10th to 13th lines is between the “transmission port”
(f12)上記(f11)で述べた「PROVIDER-PORT-REF」要素(11行目)は、リンク710が表す通信の出力元の「送信ポート」ポート706の定義を示す情報を内容として含む。具体的には、11行目の「PROVIDER-PORT-REF」要素は上記(f9)と同様に、「/テスト/部品A/送信ポート」というパスにより、「送信ポート」ポート706の定義への参照を示す。このパスは、パッケージ名(1行目の「Name」属性の値)とクラス名(29行目の「Name」属性の値)とクラス内で定義されたポート名(41行目の「Name」属性の値)をスラッシュで結合したものである。
(F12) The “PROVIDER-PORT-REF” element (line 11) described in (f11) above includes information indicating the definition of the “transmission port”
(f13)上記(f11)で述べた「REQUESTER-PORT-REF」要素(12行目)は、上記(f12)と同様に、リンク710が表す通信の出力先の「入力1」ポート707の定義を示す「/テスト/部品B/入力1」というパスを内容として含む。このパスは、パッケージ名(1行目の「Name」属性の値)とクラス名(45行目の「Name」属性の値)とクラス内で定義されたポート名(55行目の「Name」属性の値)をスラッシュで結合したものである。
(F13) The “REQUESTER-PORT-REF” element (line 12) described in (f11) above is the definition of the “
(f14)上記(f6)で述べた「TASK」要素(14〜27行目)は、第1のメタモデル101aの「Task」クラス206のインスタンスである図7の「T1」オブジェクト704を表す。よって、14行目のとおり「TASK」要素の「Name」属性には、「T1」オブジェクト704の名前「T1」が指定されている。そして、図8に示す2つの呼び出し804と805に対応して、「TASK」要素(14〜27行目)は2つの子要素を有する。
(F14) The “TASK” element (
(f15)「TASK」要素の1つ目の子要素は、「部品A」クラス301のオブジェクトである「PART1」オブジェクト702への呼び出し804に対応する。呼び出し804により呼び出されるのは、具体的には、図3のモデル図105aにおいて「部品A」クラス301の操作として定義され、<<RunnableEntity>>というステレオタイプが付加された、「実行ポイント」という名前の関数である。
(F15) The first child element of the “TASK” element corresponds to the
ここで、<<RunnableEntity>>というステレオタイプが付加された関数は、上記(c6)の表記ルール102に基づき「RunnableEntity」クラス205のインスタンスとしてモデル作成部410により解釈される。つまり、「Task」クラス206の「T1」オブジェクト704からの「実行ポイント」という名前の関数に対する呼び出し804は、図2の第1のメタモデル101aによれば、「RunnableConnector」クラス207に相当する。
Here, the function to which the stereotype << RunnableEntity >> is added is interpreted by the
よって、「TASK」要素(14〜27行目)は、呼び出し804に対応する1つ目の子要素として、具体的には「RunnableConnector」クラス207に対応する「RUNNABLE-ENTITY-CONNECTOR」要素(15〜20行目)を有する。なお、15〜20行目の「RUNNABLE-ENTITY-CONNECTOR」要素の「Name」属性には、呼び出し804に割り当てられた図8には不図示の「runEntConn_0」という名前が指定されている(15行目)。
Therefore, the “TASK” element (14th to 27th lines) is specifically the “RUNNABLE-ENTITY-CONNECTOR” element (15 to 20) corresponding to the “RunnableConnector”
(f16)また、15〜20行目の「RUNNABLE-ENTITY-CONNECTOR」要素は、4つの子要素を有する。
1つ目の子要素は、16行目の「NO」要素であり、図8のシーケンス図の形式のモデル図105dで定義された実行順序を表す。呼び出し804は1番目の呼び出しなので、16行目の「NO」要素の内容は「1」である。
(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
2つ目の子要素は、17行目の「SYMBOL」要素であり、呼び出し先の操作の名前を表す。換言すれば、<<RunnableEntity>>というステレオタイプが付加され、「Task」クラス206のオブジェクトから呼び出し可能な関数の名前は、「RunnableEntity」クラス205の「symbol」属性の値に相当し、モデル106aでは「SYMBOL」要素により表される。呼び出し804の呼び出し先は「部品A」クラス301で定義された「実行ポイント」という名前の関数なので、17行目の「SYMBOL」要素の内容は「実行ポイント」である。
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”
3つ目の子要素は、18行目の「PARAMETER」要素であり、呼び出し先の操作に与える引数を表す。「実行ポイント」という関数は引数を持たないので「PARAMETER」要素の内容は空である。 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.
4つ目の子要素は、19行目の「COMPONENT-TYPE-REF」要素であり、呼び出し先のオブジェクトが属するクラスを表す。呼び出し804の呼び出し先の「PART1」オブジェクト702は、図7で定義されているとおり「部品A」クラス301のオブジェクトである。よって、19行目の「COMPONENT-TYPE-REF」要素は、上記(f9)で説明した5行目と同様にパス形式で表現された「/テスト/部品A」という値を内容として持つ。
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”
なお、図2の第1のメタモデル101aの集約255によれば、「RunnableEntity」クラス205は、メタ部品クラスの一種である「ComponentType」クラス201に含まれる。よって、第1実施形態では、「ComponentType」クラス201への参照を意味する「COMPONENT-TYPE-REF」要素により、呼び出し先の関数が定義されたクラス(すなわち呼び出し先のオブジェクトが属するクラス)がモデル106a上で表現される。
According to the
(f17)14〜27行目の「TASK」要素は、上記(f15)と(f16)で述べた1つ目の「RUNNABLE-ENTITY-CONNECTOR」要素(15〜20行目)と同様に、2つ目の「RUNNABLE-ENTITY-CONNECTOR」要素(21〜26行目)を含む。2つ目の「RUNNABLE-ENTITY-CONNECTOR」要素は、図8の呼び出し805に対応するので、呼び出し805に割り当てられた「runEntConn_1」という名前が「Name」属性に指定されている。
(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
また、呼び出し805は2番目の呼び出しなので、子要素たる「NO」要素(22行目)は「2」という内容を持つ。
そして、呼び出し805の呼び出し先である「PART2」オブジェクト703は、図6のモデル図105bで定義された「部品B」クラス601のオブジェクトであり、呼び出し805の呼び出し先関数の名前は「実行ポイント」である。よって、2つ目の「RUNNABLE-ENTITY-CONNECTOR」要素は、「実行ポイント」という内容を有する「SYMBOL」要素を子要素として持つ(23行目)。なお、「部品B」クラス601の「実行ポイント」という関数も引数を持たないので、「RUNNABLE-ENTITY-CONNECTOR」要素は、空の「PARAMETER」要素を子要素として持つ(24行目)。
Since the
The “PART2”
また、「部品B」クラス601を表すために上記(f10)と同様のパス形式の「/テスト/部品B」という値を内容として持つ「COMPONENT-TYPE-REF」要素(25行目)も、「RUNNABLE-ENTITY-CONNECTOR」要素に子要素として含まれる。 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)上記(f3)で簡単に述べたように、ルート要素(つまり「PACKAGE」要素)の子要素として、29〜44行目には図3の「部品A」クラス301を表す「COMPOSITION-TYPE」要素が含まれる。この「COMPOSITION-TYPE」要素は、5つの子要素を有する。
(F18) As described briefly in (f3) above, “COMPOSITION-” representing the “component A”
(f19)29〜44行目の「COMPOSITION-TYPE」要素の1つ目の子要素は、「部品A」クラス301が図3に示すように「CompositionType」クラス202から直接派生していることを表す空の「SUPER-ELEMENT」要素(30行目)であり、3行目と同様である。
(F19) The first child element of the “COMPOSITION-TYPE” element on the 29th to 44th lines is empty indicating that the “component A”
(f20)29〜44行目の「COMPOSITION-TYPE」要素の2つ目の子要素は、「部品A」クラス301において<<ConfigParam>>というステレオタイプが付加された属性を表す「COMFIG-PARAM」要素である(31〜34行目)。つまり、第1のメタモデル101aにおいて「ComponentType」クラス201が「ConfigParam」クラス204を含みうることに対応する上記(c5)の表記ルール102にしたがって、モデル作成部410は「COMFIG-PARAM」要素を生成する。
(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
具体的には、図3において「部品A」クラス301では、<<ConfigParam>>というステレオタイプが付加された属性が1つだけ定義されており、その属性に関して、名前は「パラメタ」、型は整数型、デフォルト値は未設定である。よって、31〜34行目の「COMFIG-PARAM」要素には、「Name」属性に「パラメタ」という値が設定されている(31行目)。また、「COMFIG-PARAM」要素は、「int」という値を有し整数型を示す「TYPE」要素(32行目)と、デフォルト値が未設定であることを示す空の「DEFAULT-VALUE」要素(33行目)を、子要素として持つ。
Specifically, in FIG. 3, the “component A”
(f21)29〜44行目の「COMPOSITION-TYPE」要素の3つ目の子要素は、「部品A」クラス301において<<RunnableEntity>>というステレオタイプが付加された操作を表す「RUNNABLE-ENTITY」要素である(35〜36行目)。つまり、第1のメタモデル101aにおいて「ComponentType」クラス201が「RunnableEntity」クラス205を含むことに対応する上記(c6)の表記ルール102にしたがって、モデル作成部410は「RUNNABLE-ENTITY」要素を作成する。
(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
具体的には、図3において「部品A」クラス301では、<<RunnableEntity>>というステレオタイプが付加された操作が1つだけ定義されており、その操作の名前が「実行ポイント」である。よって、35〜36行目の「RUNNABLE-ENTITY」要素には、「Name」属性に「実行ポイント」という値が設定されている。
Specifically, in FIG. 3, in the “component A”
(f22)29〜44行目の「COMPOSITION-TYPE」要素の4つ目の子要素は、「部品A」クラス301が有する「RequesterPort」クラス212のオブジェクトを表す「REQUESTER-PORT」要素(37〜40行目)である。図3のモデル図105aによれば、「部品A」クラス301は「RequesterPort」クラス212のオブジェクトを1つ含み、そのオブジェクトの名前は「受信ポート」である。よって、「REQUESTER-PORT」要素には、「Name」属性に「受信ポート」という値が設定されている(37行目)。
(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”
また、モデル図105aには、「受信ポート」ポート303から「インタフェースA」クラス302への依存307が定義されている。よって、モデル作成部410は依存307に基づいて、「REQUESTER-PORT」要素の子要素として、「INTERFACE-REF」要素(38行目)を作成する。「INTERFACE-REF」要素は、第1のメタモデル101aにおける「Port」クラス211から「Interface」クラス208への参照を示す関連262に対応する。「INTERFACE-REF」要素の内容は、5行目などと同様のパス形式で表現された「/テスト/インタフェースA」という値である。
In the model diagram 105a, a
なお、図2では省略されているが、例えば「RequesterPort」クラス212には入力キューの長さを示す整数型の属性が定義されていてもよい。すると、「RequesterPort」クラス212のインスタンスである「受信ポート」ポート303でも入力キューの長さが設定されることになる。すると、設定された長さに基づいて、モデル作成部410は「REQUESTER-PORT」要素の子要素として「QUEUE-LENGTH」要素(39行目)を作成する。図9Bの例では「QUEUE-LENGTH」要素は「0」という値を内容として持つ。
Although omitted in FIG. 2, for example, an integer attribute indicating the length of the input queue may be defined in the “RequesterPort”
(f23)29〜44行目の「COMPOSITION-TYPE」要素の4つ目の子要素は、「部品A」クラス301が有する「ProviderPort」クラス213のオブジェクトを表す「PROVIDER-PORT」要素(41〜43行目)である。図3のモデル図105aによれば、「部品A」クラス301は「ProviderPort」クラス213のオブジェクトを1つ含み、そのオブジェクトの名前は「送信ポート」である。よって、「PROVIDER-PORT」要素には、「Name」属性に「送信ポート」という値が設定されている(41行目)。
(F23) The fourth child element of the “COMPOSITION-TYPE” element on lines 29 to 44 is a “PROVIDER-PORT” element (
また、モデル図105aには、「送信ポート」ポート304から「インタフェースA」クラス302への依存308が定義されている。よって、モデル作成部410は依存308に基づいて、「PROVIDER-PORT」要素の子要素として、38行目と同様の「INTERFACE-REF」要素を作成する。
In the model diagram 105a, a
(f24)上記(f4)で簡単に述べたように、ルート要素(つまり「PACKAGE」要素)の子要素として、45〜74行目には図6の「部品B」クラス601を表す「COMPOSITION-TYPE」要素が含まれる。この「COMPOSITION-TYPE」要素は9個の子要素を有する。
(F24) As briefly described in (f4) above, “COMPOSITION−” representing the “component B”
(f25)「部品B」クラス601を示す「COMPOSITION-TYPE」要素の1つ目の子要素は、「部品B」クラス601が「CompositionType」クラス202から直接派生していることを表す空の「SUPER-ELEMENT」要素(46行目)であり、30行目と同様である。
(F25) The first child element of the “COMPOSITION-TYPE” element indicating the “component B”
(f26)「部品B」クラス601を示す「COMPOSITION-TYPE」要素の2つ目と3つ目の子要素は、「部品B」クラス601が「P1」オブジェクト602と「P2」オブジェクト603を含むことを表す2つの「COMPONENT-PROTOTYPE」要素である。1つ目(47〜49行目)は「P1」オブジェクト602に対応し、2つ目(50〜52行目)は「P2」オブジェクト603に対応する。これら2つの「COMPONENT-PROTOTYPE」要素は、上記(f7)〜(f10)で説明した2〜28行目の「COMPOSITION-TYPE」要素の子要素(4〜6行目と7〜9行目)と同じ形式なので、詳しい説明は省略する。
(F26) The second and third child elements of the “COMPOSITION-TYPE” element indicating the “component B”
(f27)「部品B」クラス601を示す「COMPOSITION-TYPE」要素の4つ目の子要素(53〜54行目)は、上記(f21)で説明した、35〜36行目の「RUNNABLE-ENTITY」要素と同様の「RUNNABLE-ENTITY」要素であるので、詳しい説明は省略する。
(F27) The fourth child element (
(f28)「部品B」クラス601を示す「COMPOSITION-TYPE」要素の5つ目の子要素(55〜58行目)は、上記(f22)で説明した、37〜40行目の「REQUESTER-PORT」要素と同様の「REQUESTER-PORT」要素であるので、詳しい説明は省略する。
(F28) The fifth child element (55th to 58th lines) of the “COMPOSITION-TYPE” element indicating the “component B”
(f29)「部品B」クラス601を示す「COMPOSITION-TYPE」要素の6つ目の子要素(59〜61行目)は、上記(f23)で説明した、41〜43行目の「PROVIDER-PORT」要素と同様の「PROVIDER-PORT」要素であるので、詳しい説明は省略する。
(F29) The sixth child element (59th to 61st lines) of the “COMPOSITION-TYPE” element indicating the “part B”
(f30)「部品B」クラス601を示す「COMPOSITION-TYPE」要素の7つ目の子要素(62〜65行目)は、10〜13行目の「ASSEMBLY-CONNECTOR」要素と類似の「ASSEMBLY-CONNECTOR」要素である。10〜13行目の「ASSEMBLY-CONNECTOR」要素は、上記(f11)〜(f13)で詳しく説明したとおりである。よって、62〜65行目の「ASSEMBLY-CONNECTOR」についての詳しい説明は省略するが、図6のモデル図105bにおける「部品B」クラス601の内部のリンク612に基づき、モデル作成部410が62〜65行目の「ASSEMBLY-CONNECTOR」要素を生成する。
(F30) The seventh child element (
なお、62〜65行目の「ASSEMBLY-CONNECTOR」要素の子要素(63行目と64行目)では、11行目と12行目とは異なり、相対パスが使われている。すなわち、63行目では、「部品B」クラス601のレベルを起点とした「P1/送信ポート」という相対パスの形でパスが表現されている。この相対パスは、「部品B」クラス601の内部部品に当たる「P1」オブジェクト602のオブジェクト名である「P1」と、「P1」オブジェクト602が含む「送信ポート」ポート607の名前である「送信ポート」をスラッシュで結合したものである。64行目でも同様に、相対パスの形式でパスが表現されている。
In the child elements (
(f31)「部品B」クラス601を示す「COMPOSITION-TYPE」要素の8つ目の子要素は、「DelegateConnector」クラス216のインスタンスとしてのリンク611を表す「DELEGATION-CONNECTOR」要素(66〜69行目)である。なお、66行目に示すように、この「DELEGATION-CONNECTOR」要素の「Name」属性には、リンク611に割り当てられた図6には不図示の「delConn_0」という名前が指定されている。
(F31) The eighth child element of the “COMPOSITION-TYPE” element indicating the “component B”
第1のメタモデル101aにおいて「DelegateConnector」クラス216からは、「Port」クラス211への参照を示す関連271と関連272の2本の線が出ている。よって、「DelegateConnector」クラス216に対応する「DELEGATION-CONNECTOR」要素(66〜69行目)は、2つの子要素(67行目と68行目)を持つ。
In the
つまり、「DELEGATION-CONNECTOR」要素は、「innerPortRef」というロール名で「Port」クラス211を参照する関連271に対応して、内部部品側のポートへの参照を表す「INNER-PORT-REF」要素(67行目)を1つ目の子要素として持つ。「INNER-PORT-REF」要素の内容は、リンク611に関わる内部部品側のポート(すなわち「受信ポート」ポート606)を特定するための「/テスト/部品B/P1/受信ポート」というパスである。
That is, the “DELEGATION-CONNECTOR” element corresponds to the
同様に、「DELEGATION-CONNECTOR」要素は、「outerPortRef」というロール名で「Port」クラス211を参照する関連272に対応して、外部部品側のポートへの参照を表す「OUTER-PORT-REF」要素(68行目)を2つ目の子要素として持つ。「OUTER-PORT-REF」要素の内容は、リンク611に関わる外部部品側のポート(すなわち「入力1」ポート604)を特定するための「/テスト/部品B/入力1」というパスである。
Similarly, the “DELEGATION-CONNECTOR” element corresponds to the
(f32)「部品B」クラス601を示す「COMPOSITION-TYPE」要素の9つ目の子要素は、「DelegateConnector」クラス216のインスタンスとしてのリンク613を表す「DELEGATION-CONNECTOR」要素(70〜73行目)である。70〜73行目の「DELEGATION-CONNECTOR」要素の内容は、上記(f31)で説明した66〜69行目の「DELEGATION-CONNECTOR」要素の内容と類似なので、詳しい説明は省略する。
(F32) The ninth child element of the “COMPOSITION-TYPE” element indicating the “component B”
(f33)上記(f5)で簡単に述べたように、ルート要素(つまり「PACKAGE」要素)の子要素として、75〜85行目には図3および図6の「インタフェースA」クラス302を表す「SENDER-RECEIVER-INTERFACE」要素が含まれる。「SENDER-RECEIVER-INTERFACE」要素の「Name」属性には、「インタフェースA」クラス302のクラス名である「インタフェースA」が指定されている。そして、この「SENDER-RECEIVER-INTERFACE」要素は、3つの子要素を有する。
(F33) As described briefly in (f5) above, the “interface A”
(f34)「SENDER-RECEIVER-INTERFACE」要素の1つ目の子要素は、「インタフェースA」クラス302が「SenderReceiverInterface」クラス209から直接派生していることを表す空の「SUPER-ELEMENT」要素であり、3行目と同様である。
(F34) The first child element of the “SENDER-RECEIVER-INTERFACE” element is an empty “SUPER-ELEMENT” element indicating that the “Interface A”
(f35)「SENDER-RECEIVER-INTERFACE」要素の2つ目と3つ目の子要素は、第1のメタモデル101aにおいて「SenderReceiverInterface」クラス209が「DataElementPrototype」クラス210を含むことに対応した「DATA-ELEMENT」要素である。具体的には、図3に示すように「インタフェースA」クラス302は、「DataElementPrototype」クラス210のインスタンスに相当する2つの属性を有する。すなわち、「要素1」という名前で整数型の属性と、「要素2」という名前で整数型の属性を、「インタフェースA」クラス302は持っている。
(F35) The second and third child elements of the “SENDER-RECEIVER-INTERFACE” element are “DATA-ELEMENT” corresponding to the fact that the “SenderReceiverInterface”
そのためモデル作成部410は、「インタフェースA」クラス302を表す「SENDER-RECEIVER-INTERFACE」要素の子要素として、「要素1」という名前の属性に対応する「DATA-ELEMENT」要素(77〜80行目)を作成する。そしてモデル作成部410は、「DATA-ELEMENT」要素の「Name」属性の値として「要素1」という名前を設定する。また、モデル作成部410は、「DATA-ELEMENT」要素の子要素として、整数型を示す「int」という内容を持つ「TYPE」要素と、デフォルト値が未設定であることを示す空の「DEFAULT-VALUE」要素を作成する。
Therefore, the
同様に、モデル作成部410は、「インタフェースA」クラス302の「要素2」という名前の属性に対応して、「SENDER-RECEIVER-INTERFACE」要素の子要素として2つ目の「DATA-ELEMENT」要素(81〜84行目)も作成する。
Similarly, the
以上(f1)〜(f35)として列挙して説明したように、モデル作成部410は、第1のメタモデル101aと表記ルール102にしたがって、モデル図105a〜105dから、モデル図105a〜105dの意味を表すXML形式のモデル106aを生成する。
As described above and described as (f1) to (f35), the
続いて、クラス図とシーケンス図を使ってモデルを定義する場合の図1のプロセスP101の詳細を、図10と図11をそれぞれ参照して説明する。なお、オブジェクト図の形でモデルを定義する場合については、DSM支援装置104が行う処理は図10の処理と類似なので詳しい説明を割愛する。いずれにしろDSM支援装置104は、メタモデル101と表記ルール102にしたがってUML図(つまりモデル図105)が作成されるように、ナビゲーションを行う。
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
図10は、第1実施形態によるモデル編集処理を説明する図である。なお、図10はUMLのアクティビティ図の形式で表現されている。
ステップS101でメニュー選択部404は、メタモデル101を選択するためのメニューを、UMLツール103を介して出力装置402に表示させる。そして、入力装置401とUMLツール103を介して、メタモデル101を選択する入力をモデル作成ナビゲーション部403が受け取る。すると、モデル作成ナビゲーション部403は、受け取った入力にしたがって、選択されたメタモデル101をメタモデル格納部416から読み出す。
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
なお、読み出されたメタモデル101は、部品用メニュー提供部405、ポート用メニュー提供部406、インタフェース用メニュー提供部407、内部部品用メニュー提供部408およびタスク用メニュー提供部409から参照可能である。
The
次のステップS102は、ステップS101からの処理の流れと後述のステップS116からの処理の流れの合流点を示すマージノードである。
続いて、ステップS103でメニュー選択部404は、処理を選択するためのメニューを、UMLツール103を介して出力装置402に表示させる。そして、処理の種類を指定する入力が、入力装置401とUMLツール103を介してモデル作成ナビゲーション部403のメニュー選択部404に与えられると、処理はステップS104に移行する。
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
ステップS104でメニュー選択部404は、ステップS103で選択された処理が部品作成処理であるか否かを判断する。部品作成処理が選択された場合、メニュー選択部404は部品用メニュー提供部405を呼び出し、処理はステップS105に移行する。他方、部品作成処理が選択されたのではない場合、処理はステップS117に移行する。
In step S104, the
ステップS105で部品用メニュー提供部405は、新たな部品クラスを作成する。例えば、図3において「部品A」クラス301を新たな部品クラスとして作成する場合を例に説明すると、ステップS105で部品用メニュー提供部405は、UMLツール103を介して次のように動作し、クラス図(つまりモデル図105a)を編集する。
In step S105, the component
すなわち、部品用メニュー提供部405は、第1のメタモデル101a内の「CompositionType」クラス202を作成中のクラス図に既にコピーしたか否かを判断する。そして、まだコピーしていなければ、部品用メニュー提供部405は、第1のメタモデル101aから「CompositionType」クラス202を読み出し、UMLツール103を介して、作成中のクラス図に「CompositionType」クラス202をコピーする。
That is, the component
そして、新たな部品のクラス用にクラスを表す矩形を作図し、当該矩形から「CompositionType」クラス202への汎化305の線を引くように、部品用メニュー提供部405はUMLツール103に命令する。その結果、UMLツール103を介して出力装置402には、上記矩形と汎化305の線が出力される。
Then, the part
また、部品用メニュー提供部405は、UMLツール103を介して、上記の矩形が表すクラスのクラス名、属性、および操作を指定する入力を受け付け、受け付けた結果を作成中のクラス図に反映して出力装置402に出力させる。
In addition, the component
部品用メニュー提供部405はさらに、作成されたクラスの情報をモデル作成部410に通知する。すると、モデル作成部410は通知された情報に対応するXMLコードを生成することでモデル106を作成および編集する。例えば、ステップS105で図3の「部品A」クラス301が作成される場合、モデル作成部410は図9Bの29、30、44行目のコードを生成してモデル106aに追加する。
The component
続くステップS106で部品用メニュー提供部405は、ステップS105で作成したクラスが表す部品が最上位部品か否かを、入力装置401からUMLツール103を介して与えられる入力に基づいて判断する。例えば、部品用メニュー提供部405は、UMLツール103を介して出力装置402にダイアログを表示させ、ステップS105で作成したクラスが表す部品が最上位部品か否かをユーザに入力させ、その入力に基づいて判断を行う。
In step S <b> 106, the part
ステップS105で作成したクラスが表す部品が最上位部品であれば、処理はステップS107に移行し、最上位部品でなければ、処理はマージノードのステップS108を経て次のステップS109へと進む。 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.
ステップS107で部品用メニュー提供部405は、最上位部品設定処理を行う。例えば、ステップS105で図7の「ソフトウェア全体」クラス701が作成される場合、ステップS106では、「ソフトウェア全体」クラス701が最上位部品であるという指示が入力される。したがって、ステップS107で部品用メニュー提供部405は、UMLツール103を介して、「ソフトウェア全体」クラス701に<<TopLevel>>というステレオタイプを付加する。
In step S107, the component
また、部品用メニュー提供部405は、ステップS105で作成したクラスが表す部品が最上位部品であることを、モデル作成部410に通知する。モデル作成部410は通知に応じてモデル106を編集する。例えば、ステップS105で「ソフトウェア全体」クラス701が作成される場合、ステップS107でモデル作成部410は、図9Aの2行目に示す「COMPOSITION-TYPE」要素に「TopLevel」属性を追加し、「TopLevel」属性に「True」という値を設定する。
In addition, the part
ステップS107の実行後、処理はステップS108に移行する。ステップS108はステップS106からの処理の流れとステップS107からの処理の流れの合流地点を示すマージノードであり、続いて処理はステップS109に移行する。 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.
ステップS109で部品用メニュー提供部405は、クラス内で定義された属性に<<ConfigParam>>というステレオタイプを指定するか否かを、入力装置401からUMLツール103を介して与えられる入力に基づいて判断する。
In step S109, the component
例えば、部品用メニュー提供部405は、UMLツール103を介して出力装置402にダイアログを表示させてもよい。つまり、部品用メニュー提供部405は、ステップS105で作成されたクラスにおいてステップS105で定義された属性の中から、<<ConfigParam>>というステレオタイプを付加する属性をユーザに選択させるためのダイアログを提供してもよい。
For example, the part
そして、<<ConfigParam>>というステレオタイプを付加する対象の属性があれば、処理はステップS110へ移行し、<<ConfigParam>>というステレオタイプをどの属性にも付加しない場合は、処理はマージノードのステップS111を経て次のステップS112へと進む。 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.
ステップS110で部品用メニュー提供部405は、パラメタ設定処理を行う。例えばステップS105で図3の「部品A」クラス301が作成され、ステップS109で「部品A」クラス301の「パラメタ」という名前の属性に対して<<ConfigParam>>というステレオタイプを付加するよう指示する入力が与えられたとする。するとステップS110で部品用メニュー提供部405は、UMLツール103を介して、指定された「パラメタ」という名前の属性に対して、<<ConfigParam>>というステレオタイプを付加する。
In step S110, the component
また、部品用メニュー提供部405は、<<ConfigParam>>というステレオタイプを付加する対象の属性をモデル作成部410に通知する。上記の「部品A」クラス301の例の場合、モデル作成部410は通知に基づいて図9Bの31〜34行のXMLコードを生成し、モデル106aに追加する。
Also, the component
そして、処理はマージノードのステップS111を経て次のステップS112へと進む。
ステップS111は、ステップS109からの処理の流れとステップS110からの処理の流れの合流地点を示すマージノードであり、続いて処理はステップS112に移行する。
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.
ステップS112で部品用メニュー提供部405は、クラス内で定義された操作に<<RunnableEntity>>というステレオタイプを指定するか否かを、入力装置401からUMLツール103を介して与えられる入力に基づいて判断する。すなわち、部品用メニュー提供部405は、クラス内で定義された操作を、外部からの呼び出しにより部品を駆動するための実行ポイントとして規定するか否かを、ステップS112で判断する。
In step S <b> 112, the component
例えば、部品用メニュー提供部405は、UMLツール103を介して出力装置402にダイアログを表示させてもよい。つまり、部品用メニュー提供部405は、ステップS105で作成されたクラスにおいてステップS105で定義された操作の中から、<<RunnableEntity>>というステレオタイプを付加する操作をユーザに選択させるためのダイアログを提供してもよい。
For example, the part
そして、<<RunnableEntity>>というステレオタイプを付加する対象の操作があれば、処理はステップS113へ移行し、<<RunnableEntity>>というステレオタイプをどの操作にも付加しない場合は、処理はマージノードのステップS114を経て次のステップS115へと進む。 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.
ステップS113で部品用メニュー提供部405は、実行ポイント設定処理を行う。例えばステップS105で図3の「部品A」クラス301が作成されたとする。そして、ステップS112で、「部品A」クラス301の「実行ポイント」という名前の操作に対して、<<RunnableEntity>>というステレオタイプを付加するよう指示する入力が与えられたとする。するとステップS113で部品用メニュー提供部405は、指定された「実行ポイント」という名前の操作に対して、UMLツール103を介して<<RunnableEntity>>というステレオタイプを付加する。
In step S113, the component
また、部品用メニュー提供部405は、<<RunnableEntity>>というステレオタイプを付加する対象の操作をモデル作成部410に通知する。上記の「部品A」クラス301の例の場合、モデル作成部410は通知に基づいて図9Bの35〜36行のXMLコードを生成し、モデル106aに追加する。
In addition, the part
そして、処理はマージノードのステップS114を経て次のステップS115へと進む。
ステップS114は、ステップS112からの処理の流れとステップS113からの処理の流れの合流地点を示すマージノードであり、続いて処理はステップS115に移行する。
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.
ステップS115で部品用メニュー提供部405は、ステップS105で作成されたクラスにポートを作成するか否かを、入力装置401からUMLツール103を介して与えられる入力に基づいて判断する。例えば、部品用メニュー提供部405は、UMLツール103を介して出力装置402にダイアログを表示させ、ポートを作成するか否かをユーザに指定させてもよい。
In step S115, the component
ポートを作成しない場合、処理はステップS116に進み、ポートを作成する場合、処理はステップS119に進む。
ステップS116では、モデル図105の編集を終了するよう指示する入力が入力装置401とUMLツール103を介して与えられたか否かをメニュー選択部404が判断する。編集を終了するよう指示する入力が与えられた場合、図10の処理は終了する。編集を終了するよう指示する入力が与えられていない場合、処理はステップS102に戻る。
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
さて、メニュー選択部404は、「ステップS103で選択された処理は部品作成処理ではない」と上記のステップS104において判断した場合、ステップS117で、「ステップS103で選択された処理がポート作成処理か否か」を判断する。ポート作成処理が選択された場合、メニュー選択部404はポート用メニュー提供部406を呼び出し、処理はステップS118に移行する。他方、ポート作成処理が選択されたのではない場合、処理はステップS126に移行する。
When the
ステップS118でポート用メニュー提供部406は、ポートのオブジェクトを作成する対象となる部品のクラスを選択する。例えば、ポート用メニュー提供部406は、ポートのオブジェクトを作成する部品のクラスを選択するようユーザに求めるダイアログを、UMLツール103を介して出力装置402に出力させる。そして、ポート用メニュー提供部406は、ダイアログに対するユーザの入力を、入力装置401とUMLツール103を介して受け取り、入力にしたがって、ポートのオブジェクトを作成する対象のクラスを選択する。そして、処理はステップS119に移行する。
In step S118, the port
ステップS119はステップS115からの処理の流れとステップS118からの処理の流れの合流地点を示すマージノードである。
なお、ステップS115からの処理の流れでは、ポートを作成する対象はステップS105で作成されたクラスであり、ステップS118からの処理の流れでは、ポートを作成する対象はステップS118で選択されたクラスである。よって、ステップS119に続いてステップS120が実行される際には、ポートを作成する対象は一意に決まっている。
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.
ステップS120では、ステップS105で作成されたか、またはステップS118で選択された部品のクラスを対象として、ポート用メニュー提供部406がポート作成処理を行う。ポート作成処理は、例えば、次の(g1)〜(g4)のような処理を含む。
In step S120, the port
(g1)作成するポートの数と種類と名前を指定するようにユーザに促すダイアログを、UMLツール103を介して出力装置402に出力させる処理。
(g2)ダイアログへの入力を、入力装置401とUMLツール103を介して受け取り、入力にしたがってポートを定義する処理。
(G1) Processing to output a dialog prompting the user to specify the number, type, and name of ports to be created to the
(G2) Processing for receiving input to the dialog through the
(g3)定義したポートを表す図形を出力装置402に出力するよう、UMLツール103に命令する処理。
(g4)定義したポートの情報をモデル作成部410に通知する処理。
(G3) Processing to instruct the
(G4) Processing for notifying the
なお、上記(g1)において、ポートの種類とは、図2の第1のメタモデル101aの例で説明すると、データを受ける側の「RequesterPort」クラス212なのか、データを出力する側の「ProviderPort」クラス213なのか、という種別のことである。また、図2において集約259の多重度が「0..*」なので、1つの部品クラスは任意の個数のポートを持つことができる。よって、ステップS120では、上記(g1)のように、作成するポートの数をダイアログにて指定可能としてもよい。
Note that in (g1) above, the type of port is the “RequesterPort”
また、上記(g4)で通知された情報に基づいて、モデル作成部410はモデル106を編集する。例えば、ステップS120で図6の「入力1」ポート604と「出力1」ポート605が作成された場合、モデル作成部410は図9Cの55、57〜59、61行のXMLコードを生成し、モデル106aに追加する。
Further, the
ステップS120に続くステップS121において、ポート用メニュー提供部406は、ステップS120で作成したポートが使うインタフェースのクラスが作成済みか否かを判断する。
In step S121 following step S120, the port
例えば、ポート用メニュー提供部406は、「ステップS120で作成したポートが使うインタフェースのクラスは作成済みか否か」をユーザに尋ねるダイアログを、UMLツール103を介して出力装置402に出力させてもよい。作成したポート用のインタフェースのクラスが作成済みの場合、処理はステップS122に移行し、未作成の場合は処理がステップS123に移行する。
For example, the port
ステップS122でポート用メニュー提供部406は、作成済みのクラスの中から、ステップS120で作成したポートが使うインタフェースのクラスを選択する。
例えば、ポート用メニュー提供部406は、インタフェースのクラスを選択するようユーザに求めるダイアログを、UMLツール103を介して出力装置402に出力させる。そして、ポート用メニュー提供部406は、ダイアログに対するユーザの入力を、入力装置401とUMLツール103を介して受け取り、入力にしたがって、ポートが使うインタフェースのクラスを選択する。
In step S122, the port
For example, the port
ステップS122の実行後、次のステップS125へと制御が移る。
また、ステップS123では、ポート用メニュー提供部406がインタフェース用メニュー提供部407を呼び出し、インタフェース用メニュー提供部407が新たなインタフェースクラスを作成する。例えば、図3において「インタフェースA」クラス302を新たに作成する場合を例に説明すると、ステップS123でインタフェース用メニュー提供部407は、UMLツール103を介して次のように動作し、クラス図(つまりモデル図105a)を編集する。
After execution of step S122, control is transferred to the next step S125.
In step S123, the port
すなわち、インタフェース用メニュー提供部407は、第1のメタモデル101a内の「SenderReceiverInterface」クラス209を作成中のクラス図に既にコピーしたか否かを判断する。そして、まだコピーしていなければ、インタフェース用メニュー提供部407は第1のメタモデル101aから「SenderReceiverInterface」クラス209を読み出し、UMLツール103を介して、作成中のクラス図に「SenderReceiverInterface」クラス209をコピーする。
That is, the interface
そして新たなインタフェースクラス用にクラスを表す矩形を作図し、当該矩形から「SenderReceiverInterface」クラス209への汎化306の線を引くように、インタフェース用メニュー提供部407はUMLツール103に命令する。その結果、UMLツール103を介して出力装置402には、上記矩形と汎化306の線が出力される。
Then, the interface
また、インタフェース用メニュー提供部407は、UMLツール103を介して、上記の矩形が表すクラスのクラス名を指定する入力を受け付け、受け付けた結果を作成中のクラス図に反映して出力装置402に出力させる。
Also, the interface
インタフェース用メニュー提供部407はさらに、作成されたクラスの情報をモデル作成部410に通知する。すると、モデル作成部410は通知された情報に対応するXMLコードを生成することでモデル106を作成および編集する。例えば、ステップS123で図3の「インタフェースA」クラス302が作成される場合、モデル作成部410は図9Dの75、76、85行のコードを生成してモデル106aに追加する。
Further, the interface
次のステップS124でインタフェース用メニュー提供部407は、ステップS123で作成したインタフェースクラスに含まれるデータ要素を作成する。
図2の第1のメタモデル101aによれば、「SenderReceiverInterface」クラス209は「DataElementPrototype」クラス210を含みうる。よって、「SenderReceiverInterface」クラス209のサブクラスとして定義されるインタフェースクラスは、データ要素を含みうる。
In the next step S124, the interface
According to the
そこで、このような第1のメタモデル101aにしたがってステップS124でインタフェース用メニュー提供部407は、ステップS123で作成したインタフェースクラスの属性として、「DataElementPrototype」クラス210のインスタンスを作成する。すなわち、インタフェース用メニュー提供部407は、ステップS123で作成したクラスの属性として、インタフェースクラスの有するデータ要素を、UMLツール103を介して作成する。
Accordingly, in step S124, the interface
例えば、インタフェース用メニュー提供部407は、データ要素の個数と、その個数分のデータ要素の名前および型をユーザに入力させるためのダイアログを、UMLツール103を介して出力装置402に出力させてもよい。そして、インタフェース用メニュー提供部407はダイアログに対する入力を、入力装置401とUMLツール103を介して受け取る。
For example, the interface
そして、インタフェース用メニュー提供部407は、ステップS123で作成したクラスに、受け取った入力にしたがって属性を設定するようUMLツール103に命令する。すると、出力装置402には、入力にしたがって属性の名前と型が出力される。
Then, the interface
実施形態によっては、名前と型だけでなく、属性のデフォルト値や可視性に関する入力をさらにインタフェース用メニュー提供部407が受け付けてもよい。また、ステップS124でデータ要素の個数として「0」が入力されても、インタフェース用メニュー提供部407は、図2の合成集約264の「0..*」という多重度に基づいて、入力は適正であると判断する。その結果、1つもデータ要素が作成されないという場合もありうる。
Depending on the embodiment, the interface
なお、ステップS124の動作の具体例を挙げれば下記のとおりである。すなわち、図3の例では、「インタフェースA」クラス302が有するデータ要素の個数として「2」が入力され、1つ目のデータ要素の名前と型として「要素1」と「int」が入力され、2つ目のデータ要素の名前と型として「要素2」と「int」が入力される。その結果、「インタフェースA」クラス302には「要素1」と「要素2」という名前の2つの属性が設定され、出力装置402には図3の「インタフェースA」クラス302のように表示される。
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”
また、ステップS124ではさらに、インタフェース用メニュー提供部407が、受け取った入力の内容をモデル作成部410に通知する。モデル作成部410は通知に応じてモデル106を編集する。例えば、図3の例では、モデル作成部410は、図9Dの77〜84行のXMLコードを生成し、モデル106aに追加する。
In step S124, the interface
以上のような一連の処理がステップS124で実行された後、次のステップS125へと制御が移る。
ステップS125でポート用メニュー提供部406は、ステップS120で作成したポートの各々を、ステップS122で選択されたか、またはステップS123で作成されたインタフェースクラスに接続する処理を行う。具体的には、ポート用メニュー提供部406は、ポートのオブジェクトからインタフェースクラスへの依存の追加をUMLツール103に命令するとともに、依存の追加をモデル作成部410に通知する。
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
例えば、図3の例で、「受信ポート」ポート303がステップS120で作成され、「インタフェースA」クラス302がステップS122で選択されるかステップS123で作成されたとする。
For example, in the example of FIG. 3, it is assumed that the “reception port”
この場合、ステップS125でポート用メニュー提供部406は、依存307を追加するようUMLツール103に命令するので、結果として、出力装置402には依存307が表示される。また、ポート用メニュー提供部406が依存307の追加をモデル作成部410に通知するので、モデル作成部410は、図9Bの38行のXMLコードを生成し、モデル106aに追加する。
以上のステップS125の実行後、処理はステップS116に移行する。
In this case, the port
After execution of the above step S125, the process proceeds to step S116.
さて、メニュー選択部404は、「ステップS103で選択された処理はポート作成処理ではない」と上記のステップS117で判断した場合、ステップS126で、「ステップS103で選択された処理がインタフェース作成処理か否か」を判断する。インタフェース作成処理が選択された場合、メニュー選択部404はインタフェース用メニュー提供部407を呼び出し、処理はステップS127に移行する。他方、インタフェース作成処理が選択されたのではない場合、処理はステップS129に移行する。
When the
ステップS127では、インタフェース用メニュー提供部407がインタフェースクラスを作成する。ステップS127はステップS123と同様なので、詳しい説明は省略する。
In step S127, the interface
ステップS127に続いて、ステップS128でインタフェース用メニュー提供部407は、データ要素作成処理を行う。ステップS128はステップS124と同様なので、詳しい説明は省略する。ステップS128の実行後、処理はステップS116に移行する。
Following step S127, in step S128, the interface
さて、メニュー選択部404は、「ステップS103で選択された処理はインタフェース作成処理ではない」と上記のステップS126で判断した場合、ステップS129で、「ステップS103で選択された処理が内部部品作成処理か否か」を判断する。内部部品作成処理が選択された場合、メニュー選択部404は内部部品用メニュー提供部408を呼び出し、処理はステップS130に移行する。他方、内部部品作成処理が選択されたのではない場合、処理はステップS134に移行する。
If the
ステップS130で内部部品用メニュー提供部408は、内部部品のクラスを選択する。
例えば、内部部品用メニュー提供部408は、定義済みの部品クラスの中から、内部部品として使う部品のクラスを選択するようユーザに求めるダイアログを、UMLツール103を介して出力装置402に出力させてもよい。そして、内部部品用メニュー提供部408は、ダイアログに対する入力を、入力装置401からUMLツール103を介して受け取り、受け取った入力にしたがって内部部品のクラスを選択してもよい。
In step S130, the internal component
For example, the internal component
例えば、図6の例において、「部品B」クラス601の内部部品である「P1」オブジェクト602が作成される場合、ステップS130では、「P1」オブジェクト602が属する図3の「部品A」クラス301が選択される。
For example, in the example of FIG. 6, when the “P1”
続いてステップS131で内部部品用メニュー提供部408は、内部部品のオブジェクトを作成する。具体的には、内部部品用メニュー提供部408は以下の(h1)〜(h5)のような処理を行う。なお、以下の(h1)〜(h5)の説明では、図6において「部品B」クラス601の内部部品として「P1」オブジェクト602が作成される場合を例として挙げる。
Subsequently, in step S131, the internal component
(h1)内部部品用メニュー提供部408は、UMLツール103に、ステップS130で内部部品のクラスとして選択されたクラスをインスタンス化してオブジェクトを作成するよう命令する。
(H1) The internal component
その結果、例えば、図3の「部品A」クラス301から図6の「P1」オブジェクト602が作成される。なお、図3のとおり「部品A」クラス301が「受信ポート」ポート303と「送信ポート」ポート304を持つことが定義されているので、図6に示すように、「P1」オブジェクト602は「受信ポート」ポート606と「送信ポート」ポート607を有する。ただし、この段階ではまだ「P1」というオブジェクト名は付けられていない。
As a result, for example, the “P1”
(h2)内部部品用メニュー提供部408は、作成したオブジェクトの名前を指定する入力を入力装置401からUMLツール103を介して受け取るとともに、作成したオブジェクトに当該名前を付けるよう、UMLツール103に命令する。例えば、「P1」という名前が図6の「P1」オブジェクト602に付けられる。
(H2) The internal component
(h3)内部部品用メニュー提供部408は、内部部品を含める外部部品を選択する。例えば、内部部品用メニュー提供部408は、上記(h1)で作成したオブジェクトを含ませる外部部品のクラスを指定するようユーザに促すダイアログを、UMLツール103を介して出力装置402に出力させる。そして、内部部品用メニュー提供部408は、UMLツール103を介してダイアログに対する入力装置401からの入力を受け取り、受け取った入力にしたがって外部部品のクラスを選択する。例えば、内部部品用メニュー提供部408は、外部部品のクラスとして図6の「部品B」クラス601を選択する。
(H3) The internal component
(h4)内部部品用メニュー提供部408は、上記(h3)で選択した外部部品のクラスに、上記(h1)で作成した内部部品のオブジェクトを含ませるよう、UMLツール103に命令する。その結果、例えば、図6のとおり「P1」オブジェクト602が「部品B」クラス601に含まれることとなり、出力装置402は「部品B」クラス601の矩形の中に「P1」オブジェクト602の矩形を表示する。
(H4) The internal component
(h5)内部部品用メニュー提供部408は、上記(h1)〜(h4)の結果定義された部品間の入れ子関係をモデル作成部410に通知し、モデル作成部410は通知に基づいてモデル106を編集する。例えば、「部品B」クラス601と「P1」オブジェクト602について通知された入れ子関係と、「P1」オブジェクト602のオブジェクト名として通知された「P1」という名前に基づいて、モデル作成部410は、モデル106aを編集する。具体的には、モデル作成部410は、図9Cの47〜49行のXMLコードを生成してモデル106aに追加する。
(H5) The internal component
例えば上記の(h1)〜(h5)のような処理がステップS131で行われると、続いて、処理はステップS132に移行する。
ステップS132で内部部品用メニュー提供部408は、デレゲートコネクタ作成処理を行う。すなわち、図2の第1のメタモデル101aの「DelegateConnector」クラス216のインスタンスとしての、外部部品のポートと内部部品のポートとの間のリンクを、内部部品用メニュー提供部408は作成する。例えば、内部部品用メニュー提供部408は、ステップS131で図6の「P1」オブジェクト602を作成した場合、ステップS132ではリンク611を作成する。
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
なお、図2の第1のメタモデル101aにおける集約259の「0..*」という多重度が示すように、内部部品と外部部品は、いずれも、ポートを持たないかもしれないし、1個以上の任意の個数のポートを持つかもしれない。よって、ステップS132では、結果的にはリンクが作成されないこともあるし、1本または複数本のリンクが作成されることもある。
As indicated by the multiplicity of “0 .. *” in the
具体的には、内部部品用メニュー提供部408は、ステップS131で作成した内部部品のポートを、上記(h3)で選択した外部部品のポートと接続するためのユーザインタフェースを、UMLツール103を介して提供する。当該ユーザインタフェースは、例えば、内部部品と外部部品のポート同士を接続するか否かをユーザに尋ねるダイアログを含んでもよい。また、当該ユーザインタフェースは、接続対象の内部部品と外部部品のポートの組を、UMLツール103を介してユーザに指定させる機能を有する。
Specifically, the internal component
内部部品用メニュー提供部408は、入力装置401からUMLツール103と上記ユーザインタフェースを介して与えられた入力を受け取り、入力が上記(d6)と(d8)の制約を満たすか否を判断する。内部部品用メニュー提供部408は、入力が(d6)と(d8)の制約を満たせば入力にしたがってリンクを作成し、逆に、入力が(d6)と(d8)の制約を満たさなければ、UMLツール103を介して出力装置402に警告を表示させる。
The internal component
以上のとおりステップS132では、場合によってはリンクが作成されず、場合によっては1本以上のリンクが作成される。リンクが作成される場合は、上記の制御により、当該リンクは(d6)と(d8)の制約を満たす。 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.
さらに、ステップS132で内部部品用メニュー提供部408は、作成したリンクの情報をモデル作成部410に通知する。モデル作成部410は通知にしたがってXMLコードを生成しモデル106を編集する。例えば、図6のリンク611が作成された場合、モデル作成部410は図9Cの66〜69行目のXMLコードを生成してモデル106aに追加する。
Further, in step S132, the internal component
次に、ステップS133で内部部品用メニュー提供部408は、アセンブリコネクタ作成処理を行う。すなわち、図2の第1のメタモデル101aの「AssemblyConnector」クラス215のインスタンスとしての、内部部品同士のポート間のリンクを、内部部品用メニュー提供部408は作成する。例えば、図6の「P1」オブジェクト602が作成済みの状況で「P2」オブジェクト603がステップS131で作成された場合、ステップS133で内部部品用メニュー提供部408は、リンク612を作成する。
Next, in step S133, the internal component
なお、図2の第1のメタモデル101aにおける集約259の「0..*」という多重度が示すように、内部部品は、ポートを持たないかもしれないし、1個以上の任意の個数のポートを持つかもしれない。よって、ステップS133では、結果的にはリンクが作成されないこともあるし、1本または複数本のリンクが作成されることもある。
As indicated by the multiplicity of “0 .. *” in the
具体的には、内部部品用メニュー提供部408は、ステップS131で作成した内部部品のポートを、上記(h3)で選択した外部部品のポート内の既存の他の内部部品のポートと接続するためのユーザインタフェースを、UMLツール103を介して提供する。当該ユーザインタフェースは、例えば、内部部品同士のポート間を接続するか否かをユーザに尋ねるダイアログを含んでもよい。また、当該ユーザインタフェースは、接続対象の2つの内部部品それぞれのポートを、UMLツール103を介してユーザに指定させる機能を有する。
Specifically, the internal component
内部部品用メニュー提供部408は、入力装置401からUMLツール103と上記ユーザインタフェースを介して与えられた入力を受け取り、入力が上記(d7)と(d8)の制約を満たすか否を判断する。内部部品用メニュー提供部408は、入力が(d7)と(d8)の制約を満たせば入力にしたがってリンクを作成し、逆に、入力が(d7)と(d8)の制約を満たさなければ、UMLツール103を介して出力装置402に警告を表示させる。
The internal component
以上のとおりステップS133では、場合によってはリンクが作成されず、場合によっては1本以上のリンクが作成される。リンクが作成される場合は、上記の制御により、当該リンクは(d7)と(d8)の制約を満たす。 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.
さらに、ステップS133で内部部品用メニュー提供部408は、作成したリンクの情報をモデル作成部410に通知する。モデル作成部410は通知にしたがってXMLコードを生成しモデル106を編集する。例えば、図6のリンク612が作成された場合、モデル作成部410は図9Cの62〜65行目のXMLコードを生成してモデル106aに追加する。
Further, in step S133, the internal component
以上の一連の処理が実行された後、処理はステップS116に移行する。
さて、メニュー選択部404は、「ステップS103で選択された処理は内部部品作成処理ではない」と上記ステップS129で判断した場合、タスク用メニュー提供部409を呼び出し、処理はステップS134に移行する。そして、ステップS134でタスク用メニュー提供部409はタスク作成処理を行う。
After the above series of processes is executed, the process proceeds to step S116.
When the
すなわち、タスク用メニュー提供部409は、第1のメタモデル101aの「Task」クラス206をインスタンス化したオブジェクトを作成することで、新たなタスクを作成する。
That is, the task
すなわち、タスク用メニュー提供部409は、UMLツール103を介して、「Task」クラス206をインスタンス化して新たなオブジェクトを作成し、入力装置401からの入力にしたがってオブジェクトに名前を付ける。そして、タスク用メニュー提供部409は、作成したタスクのオブジェクトを表す図形を、UMLツール103を介して出力装置402に出力させる。
That is, the task
例えば、タスク用メニュー提供部409は、図7の「T1」オブジェクト704を作成し、入力装置401からの入力にしたがって「T1」というオブジェクト名を付ける。そして、UMLツール103を介してタスク用メニュー提供部409は、出力装置402に、「T1」オブジェクト704を示す矩形を図7のようにモデル図105c上に表示させる。
For example, the task
また、ステップS134でタスク用メニュー提供部409はさらに、作成したタスクのオブジェクトに関する情報をモデル作成部410に通知する。モデル作成部410は通知された情報に基づいてXMLコードを生成し、モデル106を編集する。例えば、図7の「T1」オブジェクト704が作成された場合、モデル作成部410は図9Aの14行目と27行目のXMLコードを生成し、モデル106aに追加する。
In step S134, the task
以上の一連の処理の実行後、処理はステップS116に移行する。
なお、図10に関しては、説明の簡略化のため、メニューには部品作成処理、ポート作成処理、インタフェース作成処理、内部部品作成処理およびタスク作成処理のみが含まれると仮定している。そのため、ステップS129からステップS134へ上記のように処理が移行する。
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.
しかし、実施形態によっては、さらに別種の処理があってもよく、それに応じてメニュー選択部404による処理分岐制御が図10に示すフローチャートと異なっていてもよい。例えば、モデル作成ナビゲーション部403は下記(i1)〜(i3)などのメニューをさらに提供してもよい。
(i1)作成済みのインタフェースクラスにおいて、データ要素の追加・編集・削除を行うためのメニュー。
(i2)作成済みの部品クラスにおいて、ポートの追加・削除を行うためのメニュー。
(i3)リンクの追加・削除・繋ぎなおしのためのメニュー。
(i4)ポートのオブジェクトとインタフェースのクラスの間の依存を設定しなおすためのメニュー。
(i5)作成済みの部品クラス内の属性・操作・ステレオタイプに関して、追加・編集・削除を行うためのメニュー。
However, depending on the embodiment, there may be another type of processing, and the processing branching control by the
(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.
例えば上記(i1)〜(i5)のようなメニューが存在する場合、モデル作成ナビゲーション部403は上記(i1)〜(i5)のメニューにおける処理結果をモデル作成部410に通知し、モデル作成部410は通知にしたがってモデル106aを編集する。
For example, when the menus (i1) to (i5) are present, the model
また、部品作成処理、ポート作成処理、インタフェース作成処理および内部部品作成処理はクラス図の編集に関連する処理である。しかし、モデル作成ナビゲーション部403は、オブジェクト図の編集に関する各種メニューも同様に提供することができる。
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
例えば、定義済みの部品クラスをインスタンス化したオブジェクトを作成するメニュー、作成された部品のオブジェクト同士をポート間のリンクにより接続するメニューなどをモデル作成ナビゲーション部403は提供してもよい。そして、モデル作成ナビゲーション部403は、リンクの接続においては、上記(d7)と(d8)の制約条件が満たされるか否かの確認を行う。
For example, the model
また、モデル作成ナビゲーション部403は、図7の「ソフトウェア全体」クラス701のように<<TopLevel>>というステレオタイプが付加された特殊なクラスのインスタンスを、オブジェクト図内に1つ作成するメニューを提供してもよい。
Further, the model
ところで、ソフトウェアのモデルの静的な側面はクラス図やオブジェクト図により表されるが、動的な一側面は、図8のようにシーケンス図を使って表現することができる。第1実施形態のDSM支援装置104は、シーケンス図を使ったモデル化にも対応している。
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
図11は、第1実施形態による駆動順序定義処理を説明する図である。つまり、図11の駆動順序定義処理は、タスクから部品を駆動する順序を図8のようにシーケンス図を使って定義する処理である。なお、図11もUMLのアクティビティ図の形式で表現されている。 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.
図8のようにシーケンス図を使ってモデル化の作業を行うためのメニューを選択する入力を、図4の入力装置401とUMLツール103を介してDSM支援装置104のモデル作成ナビゲーション部403が受け取ると、図11の駆動順序定義処理が開始される。
As shown in FIG. 8, the model
ステップS201でモデル作成ナビゲーション部403は、作成済みのモデル図105の中からタスクを選択するようにユーザに促す表示(例えばダイアログの表示)を、UMLツール103を介して行う。そして、モデル作成ナビゲーション部403は、入力装置401とUMLツール103を介してタスクを選択する入力を受け取る。
In step S <b> 201, the model
例えば、図8の例では、図7のモデル図105cで定義済みの「Task」クラス206の「T1」オブジェクト704を指定する入力を、ステップS201でモデル作成ナビゲーション部403が受け取る。ステップS201でモデル作成ナビゲーション部403は、例えば、「Task」クラス206以外のクラスのオブジェクトが指定されたら、UMLツール103を介して出力装置402に警告を出力してもよい。
For example, in the example of FIG. 8, the model
次のステップS202は、ステップS201からの処理の流れと後述のステップS205からの処理の流れが合流するマージノードである。
ステップS202の次のステップS203で、モデル作成ナビゲーション部403は、ステップS201で選択されたタスクから駆動する部品を選択する。例えば、モデル作成ナビゲーション部403は、作成済みのモデル図105の中から駆動対象の部品のオブジェクトを選択するように、ユーザに促す表示(例えばダイアログの表示)を、UMLツール103を介して行う。そして、モデル作成ナビゲーション部403は、入力装置401とUMLツール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
例えば、図8の例では、図7のモデル図105cで定義済みの「PART1」オブジェクト702を指定する入力を、ステップS203でモデル作成ナビゲーション部403が受け取る。
For example, in the example of FIG. 8, the model
ステップS203でモデル作成ナビゲーション部403は、例えば、「CompositionType」クラス202のサブクラスのオブジェクト以外を指定する入力を不正な入力として拒絶してもよい。また、モデル作成ナビゲーション部403は、指定されたオブジェクトのクラスにおいて、<<RunnableEntity>>というステレオタイプが付けられた操作が定義されていない場合、入力が不正であると見なす。そして、モデル作成ナビゲーション部403は、不正な入力に対して、UMLツール103を介して出力装置402に警告を出力してもよい。
In step S203, the model
部品のオブジェクトが選択されると、続いてステップS204において、モデル作成ナビゲーション部403は、ステップS201で選択されたタスクとステップS203で選択された部品の接続処理を行う。すなわち、モデル作成ナビゲーション部403は、下記(j1)〜(j4)のような処理を行う。
When the part object is selected, in step S204, the model
(j1)モデル作成ナビゲーション部403は、選択されたタスクから呼び出す操作を指定するようユーザに促す表示(例えばダイアログの表示)を、UMLツール103を介して行う。そして、モデル作成ナビゲーション部403は、入力装置401とUMLツール103を介して、指定された操作の名前を受け取る。例えば、図8の「PART1」オブジェクト702がステップS203で選択された場合、モデル作成ナビゲーション部403は「実行ポイント」という操作名を受け取る。
(J1) The model
(j2)モデル作成ナビゲーション部403は、UMLツール103を介して入力装置401から、矢印の起点と終点を示す入力を受け取る。なお、モデル作成ナビゲーション部403は、ステップS201で選択したタスクの活性期間の範囲内のみが矢印の起点として指定可能なように、かつステップS203で選択した部品の活性期間の範囲内のみが矢印の終点として指定可能なように、制約をかける。
(J2) The model
例えば、呼び出し804の起点と終点を示す入力をモデル作成ナビゲーション部403は受け取る。呼び出し804の矢印の起点は、ステップS201で選択された「T1」オブジェクト704の活性期間801の範囲内であり、呼び出し804の矢印の終点は、ステップS203で選択された「PART1」オブジェクト702の活性期間802の範囲内である。
For example, the model
(j3)上記(j1)で指定された名前をラベルとして有し、上記(j2)で指定された起点から終点へ向かう矢印を、作成中のシーケンス図に追加するように、モデル作成ナビゲーション部403はUMLツール103に命令する。UMLツール103は、呼び出しを示す矢印を、命令にしたがってシーケンス図に追加し、出力装置402は追加された矢印とラベルを表示する。例えば、図8の呼び出し804の矢印とラベルが出力装置402に表示される。
(J3) The model
(j4)モデル作成ナビゲーション部403は上記(j3)で追加した呼び出しの内容および順序をモデル作成部410に通知する。するとモデル作成部410は、通知された内容にしたがってモデル106を編集する。例えば、図8の呼び出し804が追加された場合、モデル作成部410は図9Aの15〜20行目のXMLコードを生成し、モデル106aに追加する。仮に、先に呼び出し805が定義された後で呼び出し804が追加された場合には、モデル作成部410は、図9Aの既存の22行目の「NO」要素の値を「1」から「2」に書き直し、新たな16行目の「NO」要素の値を「1」に設定する。
(J4) The model
以上の(j1)〜(j4)のような処理がステップS204で行われると、処理はステップS205に移行する。
ステップS205でモデル作成ナビゲーション部403は、駆動順序定義処理を終了するよう指示する終了指示が入力装置401とUMLツール103を介して入力されたか否かを判断する。終了指示が入力された場合、シーケンス図の形で作成された最終的なモデル図105は、UMLツール103を介してモデル図格納部412に格納され、図11の駆動順序定義処理は終了する。終了指示が入力されなければ、制御はステップS202のマージノードに戻り、再度ステップS203から処理が繰り返される。
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
図12は、第1実施形態によるコード生成処理を説明する図である。なお、図12もUMLのアクティビティ図の形式で表現されている。
ステップS301でコード生成装置108は、メタモデル101と表記ルール102にしたがって作成されたモデル106の入力を受け付ける。具体的には、コード生成装置108は図4の意味モデル格納部413に格納されているモデル106を読み出す。
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
そして、ステップS302においてコード生成装置108は、モデル106を中間データ110に変換する。中間データ110は、コード生成に必要な情報を、コード生成にとって扱いやすくまとめたデータ群を含み、XMLデータである。第1実施形態では、XSLT(XSL Transformations)によるコード生成のためにステップS302が行われる。
In step S <b> 302, the
なお、モデル106の形式(すなわちXMLデータであるモデル106のスキーマ)は実施形態に応じて様々であり、スキーマによってはステップS302が省略可能なこともある。
Note that the format of the model 106 (that is, the schema of the
最後に、ステップS303でコード生成装置108はコード生成処理を行う。すなわち、コード生成装置108は、図4のテンプレート格納部414からコード生成テンプレート107を読み出し、XML形式の中間データ110にXSL形式のコード生成テンプレート107を適用することで、ソースコード109を生成する。
Finally, in step S303, the
なお、コード生成テンプレート107を差し替えることにより、生成するソースコード109の言語を変更することが可能である。例えば、Java(登録商標)用のコード生成テンプレート107を用いれば、Java(登録商標)で書かれたソースコード109が生成され、C++用のコード生成テンプレート107を用いれば、C++で書かれたソースコード109が生成される。実施形態によっては、コード生成テンプレート107を選択する入力を、ステップS303でコード生成装置108が入力装置401から受け付けてもよい。
Note that the language of the
以上のとおり詳細に説明した第1実施形態について概観すると、次のとおりである。
第1実施形態において、メタモデル101は、UMLで表記された第1のクラス図によりソフトウェアをメタモデル化して表す。そして、メタモデル101は、ソフトウェアが含む部品をメタモデル化したメタ部品クラス(例えば「CompositionType」クラス202)の定義を含む。DSM支援装置104のモデル作成ナビゲーション部403は、図10のステップS101に示すように、メタモデル101を取得するメタモデル取得ステップを実行する。
An overview of the first embodiment described in detail above is as follows.
In the first embodiment, the
さらに、モデル作成ナビゲーション部403内の部品用メニュー提供部405は、図10のステップS105に示すように、クラス図生成ステップを実行する。つまり、部品用メニュー提供部405は、ソフトウェアに含まれる部品を表す部品クラス(例えば「部品A」クラス301)を、メタ部品クラス(例えば「CompositionType」クラス202)のサブクラスとして定義する。それにより、部品用メニュー提供部405は、ソフトウェアをメタモデルにしたがってモデル化したモデルを、部品クラスを含みUMLで表記される第2のクラス図(例えばモデル図105a)として生成する。
Furthermore, the part
また、部品用メニュー提供部405は作成した部品クラスに関する情報をモデル作成部410に通知する。そして、モデル作成部410は通知された情報にしたがって、第2のクラス図(例えばモデル図105a)の意味を所定の形式言語(例えばXML)により表す意味モデル(例えばモデル106a)を生成する。意味モデルの生成は、部品クラスからメタ部品クラスへの汎化(例えば図3の汎化306)とメタモデルに基づく。また、上記「意味」とは、具体的には、「第2のクラス図における部品クラスが(インタフェースなどではなく)部品をモデル化したクラスである」という意味である。
The component
また、第1実施形態では、メタモデル101を示す第1のクラス図は、部品間の通信のインタフェースをメタモデル化したメタインタフェースクラス(例えば「SenderReceiverInterface」クラス209)の定義をさらに含む。
In the first embodiment, the first class diagram showing the
そして、第2のクラス図の生成において、インタフェース用メニュー提供部407は、部品間の通信のインタフェースをモデル化したインタフェースクラス(例えば「インタフェースA」クラス302)を、メタインタフェースクラスのサブクラスとして定義する。なお、インタフェースクラスは、第2のクラス図(例えばモデル図105a)において定義される。また、第2のクラス図の生成においてインタフェース用メニュー提供部407はさらに、インタフェースクラスとの間の関係(例えば依存307や308)を用いて、部品間の前記通信を前記第2のクラス図において表記する。
Then, in generating the second class diagram, the interface
そして、意味モデルとしてモデル106を生成するにあたり、モデル作成部410は、例えば依存307などの上記関係を、部品間のインタフェースを介した通信を意味する所定の形式言語のコード(例えば図9Bの37〜40行)で表現する。なお、このコードは、インタフェースクラスからメタインタフェースクラスへの汎化(例えば汎化306)に基づいて生成される。そして、モデル作成部410は、意味モデルとしてのモデル106に、当該コードを含める。
Then, when generating the
第1実施形態ではさらに、メタモデル101を示す第1のクラス図には、メタ部品クラス(例えば「CompositionType」クラス202)に含まれるクラスとして、メタ通信ポートクラス(例えば「Port」クラス211とそのサブクラス)が定義されている。
In the first embodiment, the first class diagram showing the
よって、上記第2のクラス図(例えばモデル図105a)の生成にあたり、ポート用メニュー提供部406は、部品クラス(例えば「部品A」クラス301)を、メタ通信ポートクラスのオブジェクトである通信ポートオブジェクトを含むように定義してもよい。通信ポートオブジェクトの具体例は、図3の「受信ポート」ポート303と「送信ポート」ポート304である。なお、実施形態によっては、通信ポートオブジェクトは、メタ通信ポートクラスのサブクラスとしてモデル図105などで定義される通信ポートクラスのオブジェクトでもよい。
Therefore, when generating the second class diagram (for example, the model diagram 105a), the port
こうして部品クラスが通信ポートオブジェクトを含むように定義される場合、ポート用メニュー提供部406は、次のように動作する。すなわち、ポート用メニュー提供部406は、通信ポートオブジェクトからインタフェースクラスへの依存(例えば依存307)を用いて、部品間のインタフェースを介した通信を第2のクラス図(例えばモデル図105a)において表記する。
When the component class is thus defined to include the communication port object, the port
また、第1実施形態では、メタモデル101を表す第1のクラス図には、部品同士が入れ子になってもよいことを示すための第1の集約関係(例えば集約253)も定義されている。さらに、第1のクラス図には、入れ子になった内部部品を有する外部部品の内部での、外部部品と内部部品との間の通信を表すためのメタ内部通信クラスとして、例えば「DelegateConnector」クラス216も定義されている。そして、メタ部品クラスにメタ内部通信クラスが含まれることを示す第2の集約関係(例えば集約268)も定義されている。
In the first embodiment, the first class diagram representing the
したがって、第1実施形態では、内部部品用メニュー提供部408が次のように動作することができる。なお、ソフトウェアのモデルを表す第2のクラス図(例えばモデル図105b)において部品クラスが複数あり、そのうち外部部品クラスの中に、内部部品クラスが入れ子になって含まれるとする。外部部品クラスの例は、「部品B」クラス601であり、内部部品クラスの例は「部品A」クラス301である。
Therefore, in the first embodiment, the internal component
このとき、内部部品用メニュー提供部408は、外部部品クラスと内部部品クラスの間に、メタ内部通信クラス(例えば「DelegateConnector」クラス216)に対応する関係である内部通信関係(例えばリンク611)を定義する。
At this time, the internal component
すると、モデル作成部410は、モデル106の生成において、内部通信関係を、外部部品クラスと内部部品クラスの間の通信を意味する所定の形式言語のコード(例えば図9Cの66〜69行目)で表現し、意味モデルに当該コードを含める。当該コードは、外部部品クラスと内部部品クラスそれぞれからのメタ部品クラスへの汎化(例えば汎化305と汎化610)とメタ内部通信クラスの定義とに基づき生成される。
Then, the
また、第1実施形態では、モデル図105aや105bのようなクラス図で定義された部品クラスのオブジェクトを定義する図7のモデル図105cようなオブジェクト図に含まれるオブジェクト間の呼び出しを定義するシーケンス図も生成される。例えば、モデル作成ナビゲーション部403が図8のようなモデル図105dを、制約をかけてナビゲーションしながら生成する。
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
すると、モデル作成部410は、シーケンス図の内容に基づいて、呼び出しの順序を所定の言語で表すコード(例えば図9Aの15〜26行目)を生成し、当該コードを意味モデルとしてのモデル106に含める。
Then, the
続いて、図2の第1のメタモデル101a以外のメタモデルを用いる他の実施形態について説明する。具体的には、図13〜15を参照して第2実施形態について説明し、図16〜17を参照して第3実施形態について説明する。
Next, another embodiment using a meta model other than the first
なお、以下に説明する第2・第3実施形態においても、第1実施形態に関して図1を参照して説明した全体的な処理の流れは変わらない。また、図4と類似のDSM支援装置104や記憶装置411により、図1のプロセスP101におけるモデル編集処理が行われる。
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
ただし、メタモデル101の違いに応じて、表記ルール102やコード生成テンプレート107の具体的内容には差があり、また、図4のモデル作成ナビゲーション部403内の各コンポーネントの動作にも、メタモデルの特徴に応じて多少の差がある。以下では、第2・第3実施形態について、第1実施形態との差を中心に説明し、第1実施形態と同様の点については説明を適宜省略する。
However, there are differences in the specific contents of the
図13は、第2のメタモデルを表すUMLのクラス図である。第2のメタモデルは第1のメタモデルの一部を変更したものなので、変更点を中心に説明し、共通点の説明は適宜省略する。 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.
図13の第2のメタモデル101bには、図2の第1のメタモデル101aのうち、「RunnableEntity」クラス205およびそれにつながる集約255、関連256、関連258が存在しない。
The
また、第1のメタモデル101aでは、「Task」クラス206と「RunnableConnector」クラス207の間の集約257の多重度が「1..*」だが、第2のメタモデル101bでは多重度が異なる。すなわち、第2のメタモデル101bでは、「Task」クラス206が1つの「RunnableConnector」クラス207を含むことを示す、多重度が「1」の集約901が、「Task」クラス206と「RunnableConnector」クラス207の間に定義されている。
In the
そして、第2のメタモデル101bでは、さらに「RunnableEntityPort」クラス902と「PrevPort」クラス903と「NextPort」クラス904が定義されている。そして、「RunnableEntityPort」クラス902が「PrevPort」クラス903のスーパクラスであることを示す汎化905と、「RunnableEntityPort」クラス902が「NextPort」クラス904のスーパクラスであることを示す汎化906も定義されている。
In the
第2のメタモデル101bではさらに、「RunnableConnector」クラス207が「RunnableEntityPort」クラス902を「prevPort」というロール名で参照することを示す関連907が定義されている。また、「RunnableConnector」クラス207が「RunnableEntityPort」クラス902を「nextPort」というロール名で参照することを示す関連908も定義されている。
The
また、第2のメタモデル101bでは、メタ部品クラスとしての「CompositionType」クラス202を汎化した「ComponentType」クラス201が「PrevPort」クラス903を1つ含みうることを示す、多重度が「0..1」の集約909が定義されている。同様に、「ComponentType」クラス201が「NextPort」クラス904を1つ含みうることを示す、多重度が「0..1」の集約910も定義されている。
In the second
以上のように定義された第2のメタモデル101bの、第1のメタモデル101aとの意味的な違いは以下のとおりである。
第1のメタモデル101aは、オブジェクトの駆動順序を図8のようなシーケンス図により定義するためのメタモデルである。それに対し、第2のメタモデル101bは、オブジェクトの駆動順序を後述の図15のようなオブジェクト図により定義するためのメタモデルである。そして、「RunnableEntityPort」クラス902は、オブジェクトの駆動順序を示すためのポートをメタモデル化したものである。
The semantic difference between the
The
すなわち、第2のメタモデル101bでは、まずタスクが起動し、部品のオブジェクトのうち最初の1つをタスクが呼び出して駆動することが、以下の(k1)〜(k3)の点によりメタモデル化されている。
(k1)集約901の多重度が「1」であること。
(k2)「Task」クラス206と集約901で結ばれた「RunnableConnector」クラス207から「RunnableEntityPort」クラス902への参照を示す関連907が定義されていること。
(k3)「CompositionType」クラス202は、関連907により「RunnableConnector」クラス207から参照される「RunnableEntityPort」クラス902のサブクラスである「PrevPort」クラス903のオブジェクトを1つ含みうること。
なお、上記(k3)の点は、「CompositionType」クラス202が「ComponentType」クラス201のサブクラスであることから明らかである。
That is, in the
(K1) The multiplicity of the
(K2) A
(K3) The “CompositionType”
The point (k3) is apparent from the fact that the “CompositionType”
そして、第2のメタモデル101bではさらに、オブジェクトが駆動順序にしたがって順次、次のオブジェクトを呼び出して駆動する能力があることが、以下の(l1)〜(l4)の点によりメタモデル化されている。
(l1)メタ部品クラスである「CompositionType」クラス202が、1つの「NextPort」クラス904を含みうること。
(l2)「NextPort」クラス904のスーパクラスである「RunnableEntityPort」クラス902は、関連908が示すように、「RunnableConnector」クラス207から「nextPort」のロール名で参照されること。
(l3)「RunnableConnector」クラス207は、関連907に示すように「prevPort」という別のロール名によっても「RunnableEntityPort」クラス902を参照すること。
(l4)メタ部品クラスである「CompositionType」クラス202は、関連907により参照される「RunnableEntityPort」クラス902のサブクラスである「PrevPort」クラス903のオブジェクトを1つ含みうること。
なお、上記(l1)と(l4)の点は、「CompositionType」クラス202が「ComponentType」クラス201のサブクラスであることから明らかである。
The
(L1) The “CompositionType”
(L2) The “RunnableEntityPort”
(L3) The “RunnableConnector”
(14) The “CompositionType”
Note that the points (l1) and (l4) are apparent from the fact that the “CompositionType”
以上を換言すれば、第2のメタモデル101bは、各オブジェクトが、当該オブジェクトを駆動する他のオブジェクト(またはタスク)と接続されるポートと、当該オブジェクトが駆動する次のオブジェクトと接続されるポートを含むことをメタモデル化している。よって、第2のメタモデル101bによれば、部品のオブジェクト間の駆動順序をポート間の接続により表すことができるので、オブジェクト図により駆動順序をモデル化することが可能となる。
In other words, in the
図14は、第2のメタモデルにしたがう第3のモデルを表すUMLのクラス図である。図3と同様に図14のモデル図105eには、メタ部品クラスおよびメタインタフェースクラスとして、図13の第2のメタモデル101bで定義された「CompositionType」クラス202と「SenderReceiverInterface」クラス209が含まれる。
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”
モデル図105aは、ユーザ定義の3つのクラス、すなわち、「部品1」クラス1001と「部品2」クラス1002と「インタフェース1」クラス1003を含む。
「部品1」クラス1001は、「RequesterPort」クラス212のオブジェクトである「in」ポート1004と、「ProviderPort」クラス213のオブジェクトである「out」ポート1005を含む。また、「部品1」クラス1001は、「PrevPort」クラス903のオブジェクトである「prev」ポート1006と、「NextPort」クラス904のオブジェクトである「next」ポート1007を含む。
The model diagram 105a includes three user-defined classes: a “
The “
同様に、「部品2」クラス1002は、「RequesterPort」クラス212のオブジェクトである「in」ポート1008と、「ProviderPort」クラス213のオブジェクトである「out」ポート1009を含む。また、「部品2」クラス1002は、「PrevPort」クラス903のオブジェクトである「prev」ポート1010と、「NextPort」クラス904のオブジェクトである「next」ポート1011を含む。
Similarly, the “
また、モデル図105eでは、「部品1」クラス1001が「CompositionType」クラス202のサブクラスであることを示す汎化1012が定義されている。同様に、「部品2」クラス1002が「CompositionType」クラス202のサブクラスであることを示す汎化1013も定義されている。さらに、「インタフェース1」クラス1003が「SenderReceiverInterface」クラス209のサブクラスであることを示す汎化1014も定義されている。
In the model diagram 105e, a
そして、モデル図105eでは、「in」ポート1004から「インタフェース1」クラス1003への依存1015と、「out」ポート1005から「インタフェース1」クラス1003への依存1016が定義されている。同様に、「in」ポート1008から「インタフェース1」クラス1003への依存1017と、「out」ポート1009から「インタフェース1」クラス1003への依存1018も定義されている。
In the model diagram 105e, a
モデル図105eは、第2のメタモデル101bおよび表記ルール102に適合するクラス図であり、具体的には図3に関して説明した(c1)〜(c4)と同様の制約条件を満たす。モデル図105eが制約条件を満たすのは、DSM支援装置104が第2のメタモデル101bと表記ルール102に基づいて制約をかけながらモデル図105eの作成および編集を行うからである。
The model diagram 105e is a class diagram that conforms to the
なお、説明の簡略化のため、図14では<<ConfigParam>>というステレオタイプと、各クラス内の属性および操作については省略して示している。しかし、図3の例と同様に、(c5)と(c7)の制約条件も満たすように、DSM支援装置104が制約をかけながらモデル図105eを作成するので、モデル図105eは(c5)と(c7)の制約条件も満たす。
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
図15は、上記の図14のモデルの利用例を示すUMLのオブジェクト図である。図15のモデル図105fは、第2のメタモデル101bにしたがうモデルをオブジェクト図の形で表現したものである。
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
モデル図105fは、第2のメタモデル101bの「Task」クラス206をインスタンス化した「T1」オブジェクト1101を含む。
また、モデル図105fは、モデル図105eで定義された「部品1」クラス1001をインスタンス化した「B1」オブジェクト1102と、「部品2」クラス1002をインスタンス化した「B2」オブジェクト1103を含む。モデル図105fはさらに、「部品1」クラス1001をインスタンス化した「B11」オブジェクト1104と、「部品2」クラス1002をインスタンス化した「B22」オブジェクト1105も含む。
The model diagram 105f includes a “T1”
The model diagram 105 f includes a “B1”
図14に示すように「部品1」クラス1001と「部品2」クラス1002はそれぞれ4つのポートを含む。したがって、「B1」オブジェクト1102は、「prev」ポート1106、「next」ポート1107、「in」ポート1108および「out」ポート1109を含む。
As shown in FIG. 14, each of the “
同様に、「B2」オブジェクト1103は、「prev」ポート1110、「next」ポート1111、「in」ポート1112および「out」ポート1113を含む。同様に、「B11」オブジェクト1104は、「prev」ポート1114、「next」ポート1115、「in」ポート1116および「out」ポート1117を含む。同様に、「B22」オブジェクト1105は、「prev」ポート1118、「next」ポート1119、「in」ポート1120および「out」ポート1121を含む。
Similarly, the “B2”
そして、モデル図105fには、部品の駆動順序を示すための複数のリンクが定義されている。すなわち、「T1」オブジェクト1101と「prev」ポート1106の間のリンク1122は、まず「T1」オブジェクト1101が「B1」オブジェクト1102を駆動することを示す。そして、「next」ポート1107と「prev」ポート1110の間のリンク1123は、次に「B1」オブジェクト1102が「B2」オブジェクト1103を駆動することを示す。
The model diagram 105f defines a plurality of links for indicating the drive order of components. That is, the
また、「next」ポート1111と「prev」ポート1114の間のリンク1124は、続いて「B2」オブジェクト1103が「B11」オブジェクト1104を駆動することを示す。さらに、「next」ポート1115と「prev」ポート1118の間のリンク1125は、最後に「B11」オブジェクト1104が「B22」オブジェクト1105を駆動することを示す。「B22」オブジェクト1105は他のオブジェクトを駆動しないので、「next」ポート1119はどこにもリンクされていない。
A
さらに、モデル図105fでは、部品間の通信(換言すればデータの流れ)を示す複数のリンクも定義されている。すなわち、モデル図105fには、「out」ポート1109と「in」ポート1112の間のリンク1126が定義されている。同様に、「out」ポート1113と「in」ポート1116の間のリンク1127、および「out」ポート1117と「in」ポート1120の間のリンク1128も定義されている。
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
これらのリンク1126〜1128は、上記(d7)と(d8)を満たす。すなわち、リンク1126〜リンク1128はいずれも、「RequesterPort」クラス212と「ProviderPort」クラス213のオブジェクト間のリンクであり、同じ「インタフェース1」クラス1003に依存するポート間のリンクである。
These
なお、駆動順序を示す上記のリンク1122〜1125は、第2のメタモデル101bと表記ルール102にしたがって、下記(m1)〜(m3)に説明する制約条件を満たすように作成されている。
The
(m1)表記ルール102は、最初にタスクが部品のオブジェクトを駆動するという意味を表すための、「『Task』クラス206のオブジェクトからリンク可能なのは、『PrevPort』クラス903のオブジェクトのみである」というルールを含む。リンク1122はこのルールに適合する。
(M1) The
また、このルールは、第2のメタモデル101bでは、「Task」クラス206に含まれる「RunnableConnector」クラス207から「PrevPort」クラス903のスーパクラスである「RunnableEntityPort」クラス902への参照(つまり関連907)に対応する。つまり、モデル作成部410は、「Task」クラス206のオブジェクトから「PrevPort」クラス903のオブジェクトへのリンクを、「RunnableConnector」クラス207のインスタンスとして解釈し、その解釈にしたがってモデル106を編集する。
Further, in the
また、モデル作成ナビゲーション部403は、「NextPort」クラス904や「RequesterPort」クラス212や「ProviderPort」クラス213のオブジェクトに「T1」オブジェクト1101を接続しようとする入力を、上記のルールに基づいて拒絶する。こうしてモデル作成ナビゲーション部403は、表記ルール102に適合するようにモデル図105fを編集する。
Further, the model
(m2)表記ルール102は、「『PrevPort』クラス903のインスタンスは、『NextPort』クラス904または『Task』クラス206のインスタンスとしかリンクすることができない」というルールを含む。表記ルール102はさらに、「『NextPort』クラス904のインスタンスは、『PrevPort』クラス903のインスタンスとしかリンクすることができない」というルールを含む。
(M2) The
モデル作成ナビゲーション部403がこの2つのルールも制約条件として用いながらモデル図105fの編集を行うので、リンク1122〜1125は、この2つのルールに適合している。
Since the model
(m3)表記ルール102は、第1のオブジェクト内の「NextPort」クラス904のインスタンスと第2のオブジェクト内の「PrevPort」クラス903のインスタンスの間にリンクがある場合の、当該リンクの意味の解釈も与える。すなわち、表記ルール102は、「当該リンクは、『RunnableConnector』クラス207のインスタンスに相当し、第1のオブジェクトが第2のオブジェクトを駆動することを示す」という解釈を規定する。
(M3) The
モデル作成部410は、この解釈にしたがって駆動順序を示すXMLコードを生成することにより、モデル106を編集する。
したがって、例えばリンク1123は、「RunnableConnector」クラス207のインスタンスとしてモデル作成部410に解釈される。また、リンク1123の一端である「next」ポート1107は、リンク1123にとっては、第2のメタモデル101bの関連908に示す「nextPort」というロール名で参照されるポートである。同様に、リンク1123の他端である「prev」ポート1110は、リンク1123にとっては、関連907に示す「prevPort」というロール名で参照されるポートである。
The
Therefore, for example, the
モデル作成部410は上記の解釈にしたがうことにより、「『B1』オブジェクト1102、『B2』オブジェクト1103、『B11』オブジェクト1104、『B22』オブジェクト1105という順序で駆動される」という意味をモデル106上に表現する。
According to the above interpretation, the
以上説明したように、第2のメタモデル101bに対応する表記ルール102の内容は、第1のメタモデル101aに対応する表記ルール102とは一部異同がある。
具体的には、第2実施形態では、第2のメタモデル101bを表すクラス図には、メタ部品クラスに含まれるクラスとして、メタ呼び出しポートクラスが集約関係を使って定義されている。例えば、図13では「RunnableEntityPort」クラス902のサブクラスである「PrevPort」クラス903と「NextPort」クラス904が、メタ呼び出しポートクラスとして、集約909と910を使って定義されている。
As described above, the content of the
Specifically, in the second embodiment, in the class diagram representing the second
よって、モデル図105eのようなクラス図の生成にあたり、部品用メニュー提供部405は、メタ呼び出しポートクラスのオブジェクトである呼び出しポートオブジェクトを1つ以上備えるように部品クラスを定義する。実施形態によっては、メタ呼び出しポートクラス(例えば「PrevPort」クラス903と「NextPort」クラス904)のサブクラスのオブジェクトを、呼び出しポートオブジェクトとして部品クラスが備えるように、部品用メニュー提供部405が定義してもよい。
Therefore, when generating a class diagram such as the model diagram 105e, the component
その結果、図14のようなクラス図で定義された1つ以上の部品クラスの合計複数個のオブジェクトを定義するオブジェクト図(例えばモデル図105f)において、各オブジェクト間の呼び出しを表記することができるようになる。すなわち、オブジェクト図内の各オブジェクトがそれぞれ備える呼び出しポートオブジェクト間の関係(リンク1123〜1125など)を用いることで、各オブジェクト間の呼び出しを表記することができる。
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 (
あわせて、モデル作成部410は、図15のようなオブジェクト図に表記された各オブジェクト間の呼び出しに基づいて、どのオブジェクトがどのオブジェクトを呼び出すかを所定の形式言語で表すコードを生成する。そして、モデル作成部410は、意味モデルとしてのモデル106に、生成した当該コードを含める。
At the same time, the
このように、順序定義の点で第1実施形態と第2実施形態には差があり、その差に応じて、表記ルール102の内容にも異動がある。しかし、メタモデル101ごとに予め決められた表記ルール102にしたがって制約をかけながら、DSM支援装置104がモデル図105とモデル106を編集するという点には、第1実施形態と第2実施形態の間で何ら変わりはない。
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
続いて、図16〜17を参照して第3実施形態について説明する。
図16は、第3のメタモデルを表すUMLのクラス図である。図16に示す第3のメタモデル101cは、例えばロボット制御のドメインに好適である。
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.
第3のメタモデル101cは、ソフトウェアのモデルを表すUMLのオブジェクト図において矩形で表される対象をメタモデル化したクラスである「ブロック」クラス1201の定義を含む。矩形で表される対象には名前を付けることができることを表すため、「ブロック」クラス1201は、「名前」という名前の属性を持つ。
The third metamodel 101c includes a definition of a “block”
また、第3のメタモデル101cは、タスクをメタモデル化した「タスク」クラス1202と、メタ部品クラスである「機能」クラス1203と、メタインタフェースクラスである「データ」クラス1204の定義も含む。換言すれば、「機能」クラス1203は、ソフトウェアの部品の様々な機能を抽象化してメタモデル化したクラスである。また、「データ」クラス1204は、部品間で入出力されるデータの形式によって部品間の通信インタフェースが規定されるという観点から、種々のデータをインタフェースとして捉えてメタモデル化したクラスである。
The third metamodel 101c also includes definitions of a “task”
なお、「タスク」クラス1202は、タスクを実行する周期と、タスクが最初に起動するタイミングを示すための2つの属性を有し、それぞれの名前は「発火周期」と「初期カウンタ」である。また、「データ」クラス1204は、「データ」クラス1204が表すインタフェースの型を示すための、「データ型」という名前の属性を有する。
The “task”
第3のメタモデル101cはさらに、ソフトウェアのモデルを表すUMLのオブジェクト図において各種の線で表される対象をメタモデル化したクラスである「コネクタ」クラス1205の定義を含む。
The third meta model 101c further includes a definition of a “connector”
より具体的には、第3のメタモデル101cは、オブジェクト図において誘導可能性を示す矢印付きのリンクにより実行順序とデータの入出力を表現することをメタモデル化している。そのため、第3のメタモデル101cは、「コネクタ」クラス1205のサブクラスとして定義される「実行順番」クラス1206と「データアクセス」クラス1207を含む。そして、「データアクセス」クラス1207は、「Read」(読み出し)か「Write」(書き込み)か、というデータアクセスのタイプを表すための「アクセスタイプ」という名前の属性を有する。
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”
また、第3のメタモデル101cは、UMLのオブジェクト図にコメントが付けられることを表す「コメント」クラス1208の定義も含む。「コメント」クラス1208は「説明文」という名前の属性を有する。すなわち、「説明文」属性の値である文字列が、コメントとしてUMLのオブジェクト図に付けられる。
The third metamodel 101c also includes a definition of a “comment”
さらに、第3のメタモデル101cは、「機能」クラス1203から直接派生したサブクラスとして、「アクチュエータ」クラス1209、「演算」クラス1210、「センサ」クラス1211各々の定義も含む。そして、第3のメタモデル101cは、「機能」クラス1203から間接的に派生したサブクラスの定義も含む。具体的には、第3のメタモデル101cは、「LCD」(Liquid Crystal Display)クラス1212、「モータ」クラス1213、「グラフ特性」クラス1214、「光センサ」クラス1215、「タッチセンサ」クラス1216各々の定義も含む。
Further, the third metamodel 101 c includes definitions of “actuator”
第3のメタモデル101cによれば、上記のクラス間に以下のような各種の関係が定義されている。
すなわち、汎化1251、1252および1253は、「タスク」クラス1202、「機能」クラス1203および「データ」クラス1204がそれぞれ「ブロック」クラス1201のサブクラスであることを示す。また、汎化1254と1255は、「実行順番」クラス1206と「データアクセス」クラス1207がそれぞれ「コネクタ」クラス1205のサブクラスであることを示す。
According to the third metamodel 101c, the following various relationships are defined between the above classes.
That is, the
さらに、汎化1256、1257および1258は、「アクチュエータ」クラス1209、「演算」クラス1210および「センサ」クラス1211がそれぞれ「機能」クラス1203のサブクラスであることを示す。
Further,
また、汎化1259と1260は、「LCD」クラス1212と「モータ」クラス1213がそれぞれ「アクチュエータ」クラス1209のサブクラスであることを示す。同様に、汎化1261は「グラフ特性」クラス1214が「演算」クラス1210のサブクラスであることを示す。また、汎化1262と1263は「光センサ」クラス1215と「タッチセンサ」クラス1216がそれぞれ「センサ」クラス1211のサブクラスであることを示す。
そして、いずれも多重度が「1」の関連1264と1265は、「実行順番」クラス1206が「ブロック」クラス1201をそれぞれ「prev」と「next」というロール名で参照可能なことを表す。関連1264と1265は、ソフトウェアのモデルを表す図において、「実行順番」クラス1206のインスタンスを表現する線の両端が「ブロック」クラス1201(またはそのサブクラス)のインスタンスであることを表す。
Each of the
多重度が「0..*」の関連1266は、「ブロック」クラス1201が「comment」というロール名で「コメント」クラス1208を参照することを表す。関連1266は、ソフトウェアのモデルを表す図において、「ブロック」クラス1201(またはそのサブクラス)のインスタンスを表す矩形には、任意の個数のコメントを付加しうることを表す。
The
同様に、多重度が「0..*」の関連1267は、「コネクタ」クラス1205が「comment」というロール名で「コメント」クラス1208を参照することを示す。関連1267は、ソフトウェアのモデルを表す図において、「コネクタ」クラス1205(またはそのサブクラス)のインスタンスを表す線には、任意の個数のコメントを付加しうることを表す。
Similarly, a
いずれも多重度が「1」の関連1268と1269は、「データアクセス」クラス1207が、「data」と「function」というロール名でそれぞれ「データ」クラス1204と「機能」クラス1203を参照可能なことを表す。関連1268と1269は、ソフトウェアのモデルを表す図で、「データアクセス」クラス1207のインスタンスを表す線が、「機能」クラス1203(またはそのサブクラス)と「データ」クラス1204のインスタンス同士を結ぶことに対応する。つまり、関連1268と1269は、(ソフトウェアの部品のモデルとしての)ある機能から、(インタフェースのモデルとしての)あるデータへのアクセスが「データアクセス」クラス1207によりメタモデル化されていることを示す。
In each of the
ところで、第3のメタモデル101cでは、「機能」クラス1203から間接的に派生している5つのクラスが、コンクリートクラスとして定義されている。すなわち、第3のメタモデル101cは、ユーザがクラスを定義する必要なしにオブジェクト図の形でソフトウェアの部品をモデル化することができるように、「光センサ」クラス1215等の具体的なクラスの定義を含んでいる。この点は、第1・第2のメタモデル101a・101bと第3のメタモデル101cとの違いである。
By the way, in the third metamodel 101c, five classes indirectly derived from the “function”
すなわち、第1・第2のメタモデル101a・101bでは、ユーザがクラス図の形でソフトウェアをモデル化すること(すなわち、メタ部品クラスから派生するユーザ定義のサブクラスにより部品がモデル化されること)が前提となっている。よって、第1・第2のメタモデル101a・101bによれば、ある程度ドメインが絞られた範囲の中でユーザにクラス設計の自由度を与えることができる。 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.
それに対し、第3のメタモデル101cにおけるメタ部品クラスは、「光センサ」クラス1215等のドメイン固有のコンクリートクラスを含み、ユーザはクラスを定義しなくても迅速にソフトウェアをモデル化することができる。
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”
換言すれば、第1・第2のメタモデル101a・101bを使ったモデル化は、ユーザがクラス定義をカスタマイズしながらDSM設計を行うこと可能とする。他方で、第3のメタモデル101cを使ったモデル化は、ドメインに合わせて予め定義されたオーダメイドのクラスを使ったDSM設計を可能とする。なお、第3実施形態においても、第3のメタモデル101cを使ってユーザが「機能」クラス1203のサブクラスとして部品クラスを定義してもよい。
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”
どのようなタイプのメタモデルが好ましいかは、設計対象のソフトウェアの適用分野などに応じて様々であるが、メタモデルのタイプに応じて、第1〜第3実施形態あるいはその変形例の中から、適した実施形態を選んで適用することが可能である。 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.
さて次に、上記の第3のメタモデル101cにしたがったソフトウェアのモデル化の例について説明する。
図17は、第3のメタモデルにしたがうモデルを表すUMLのオブジェクト図である。図17のモデル図105gは、明るさに基づいて路面上に引かれた白線を判別し、白線の右端を探してトレースしながら白線に沿って走る、後輪駆動・前輪ステアリングの自走式の車ロボットの制御用ソフトウェアのモデルを表すオブジェクト図の例である。
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.
モデル図105gは、「タスク」クラス1202の「ステアリングタスク」オブジェクト1301を含む。「ステアリングタスク」オブジェクト1301は前輪の制御用タスクをモデル化したものである。
Model diagram 105 g includes a “steering task”
モデル図105gはさらに、「光センサ」クラス1215の「LightSensor1」オブジェクト1302と、「グラフ特性」クラス1214の「ハンドル切り量」オブジェクト1303と「モータ」クラス1213の「ハンドル駆動」オブジェクト1304を含む。また、モデル図105gは、「データ」クラス1204の「路面の明るさ」オブジェクト1305と「ハンドルモータ駆動量」オブジェクト1306を含む。
The model diagram 105 g further includes a “LightSensor1”
また、モデル図105gは、「タスク」クラス1202の「タイヤ駆動タスク」オブジェクト1307も含む。「タイヤ駆動タスク」オブジェクト1307は後輪の制御用タスクをモデル化したものである。
The model diagram 105 g also includes a “tire drive task”
そして、モデル図105gは、「グラフ特性」クラス1214の「スピード制御量」オブジェクト1308と、「モータ」クラス1213の「後輪タイヤ駆動」オブジェクト1309と、「データ」クラス1204の「タイヤ駆動量」オブジェクト1310を含む。
The model diagram 105g includes a “speed control amount”
モデル図105gには、「実行順番」クラス1206のインスタンスとして矢印で示されるリンクが含まれる。矢印の根元側と先端側はそれぞれ、第3のメタモデル101cにおける関連1264と1265に対応し、矢印の根元側のオブジェクトから先端側のオブジェクトが呼び出され、駆動される。
The model diagram 105g includes a link indicated by an arrow as an instance of the “execution order”
具体的には、「ステアリングタスク」オブジェクト1301が「LightSensor1」オブジェクト1302を駆動することをリンク1321が示す。また、「LightSensor1」オブジェクト1302が「ハンドル切り量」オブジェクト1303を駆動することをリンク1322が示す。そして、「ハンドル切り量」オブジェクト1303が「ハンドル駆動」オブジェクト1304を駆動することをリンク1323が示す。
Specifically, the
同様に、「タイヤ駆動タスク」オブジェクト1307が「スピード制御量」オブジェクト1308を駆動することをリンク1324が示す。そして、「スピード制御量」オブジェクト1308が「後輪タイヤ駆動」オブジェクト1309を駆動することをリンク1325が示す。
Similarly, link 1324 indicates that the “tire drive task”
また、モデル図105gには、「データアクセス」クラス1207のインスタンスとして矢印で示されるリンクも含まれる。「データ」クラス1204のインスタンスから「機能」クラス1203のサブクラスのインスタンスへの矢印で示されるリンクは、機能がデータを読み込む「Read」アクセスを示す。逆方向の矢印で示されるリンクは、機能がデータを書き出す「Write」アクセスを示す。
The model diagram 105 g also includes a link indicated by an arrow as an instance of the “data access”
具体的には、「LightSensor1」オブジェクト1302から「路面の明るさ」オブジェクト1305への書き出しをリンク1331が表し、「路面の明るさ」オブジェクト1305の「ハンドル切り量」オブジェクト1303への読み込みをリンク1332が表す。また、「ハンドル切り量」オブジェクト1303から「ハンドルモータ駆動量」オブジェクト1306への書き出しをリンク1333が表す。そして、「ハンドルモータ駆動量」オブジェクト1306の「ハンドル駆動」オブジェクト1304への読み込みをリンク1334が表す。
Specifically, the
「ハンドルモータ駆動量」オブジェクト1306はさらに「スピード制御量」オブジェクト1308にも読み込まれ、リンク1335はその読み込みを表す、また、「スピード制御量」オブジェクト1308から「タイヤ駆動量」オブジェクト1310への書き出しをリンク1336が表し、「タイヤ駆動量」オブジェクト1310の「後輪タイヤ駆動」オブジェクト1309への読み込みをリンク1337が表す。
The “handle motor drive amount”
また、モデル図105gには、「コメント」クラス1208のインスタンスとしてのコメント1341〜1346も含まれる。例えば、コメント1341は「ハンドル切り量」オブジェクト1303に対して付加されているので、「ハンドル切り量」オブジェクト1303と点線1351で結ばれている。
The model diagram 105 g also includes
同様に、コメント1342〜1346はそれぞれ点線1352〜1356によって、「スピード制御量」オブジェクト1308、リンク1324、リンク1336、「タイヤ駆動量」オブジェクト1310、リンク1337と結ばれている。これらの点線1351〜1356は、第3のメタモデル101cにおける関連1266または関連1267に相当する。
Similarly, the comments 1342 to 1346 are connected to a “speed control amount”
以上のような図形を含むモデル図105gは、より具体的には以下のような制御のモデルである。
すなわち、前輪の制御のための「ステアリングタスク」オブジェクト1301が「LightSensor1」オブジェクト1302を呼び出し、「LightSensor1」オブジェクト1302は路面の明るさを感知し、感知した路面の明るさを「路面の明るさ」オブジェクト1305に書き出す。また、「LightSensor1」オブジェクト1302は「ハンドル切り量」オブジェクト1303を駆動する。
More specifically, the model diagram 105g including the graphic as described above is a model of the following control.
That is, the “steering task”
すると、「ハンドル切り量」オブジェクト1303は、「路面の明るさ」オブジェクト1305を読み込み、読み込んだデータからハンドルモータ駆動量を導き出す。具体的には、「ハンドル切り量」オブジェクト1303は、コメント1341に記してあるように、明るくなったら右へ、暗くなったら左へ、ハンドルを切るよう決定し、決定した結果を「ハンドルモータ駆動量」オブジェクト1306に書き出す。また、「ハンドル切り量」オブジェクト1303は、「ハンドル駆動」オブジェクト1304を駆動する。
Then, the “handle cut amount”
すると、「ハンドル駆動」オブジェクト1304は「ハンドルモータ駆動量」オブジェクト1306を読み込み、「ハンドル切り量」オブジェクト1303が決定した結果にしたがって、ハンドルのモータを駆動させる制御を行う。その結果、コメント1341に記すとおり、ロボットは路面上の白線の端に沿って進むことができる。
Then, the “handle drive”
また、前輪の制御と並行して、後輪の制御も行われる。具体的にはまず「タイヤ駆動タスク」オブジェクト1307が「スピード制御量」オブジェクト1308を呼び出す。なお、この呼び出しを示すリンク1324には、リンク1324が実行順序を表すコネクタであることを示すコメント1343が付加されている。
In addition to the front wheel control, the rear wheel control is also performed. Specifically, first, the “tire drive task”
「タイヤ駆動タスク」オブジェクト1307から呼び出された「スピード制御量」オブジェクト1308は、「ハンドルモータ駆動量」オブジェクト1306を読み込む。コメント1342に記すように、「スピード制御量」オブジェクト1308は、「ハンドルモータ駆動量」オブジェクト1306が示す量に比例してスピードを制御する(具体的には、例えば、ハンドルを増し切りするにしたがってスピードを落とすなどの制御を行う)。
The “speed control amount”
「スピード制御量」オブジェクト1308は、「ハンドルモータ駆動量」オブジェクト1306に基づいて、スピードの制御のために具体的にはタイヤの駆動量を決定し、決定した結果を「タイヤ駆動量」オブジェクト1310に書き込む。なお、この書き込みを表すリンク1336にはコメント1344が付けられている。そして、リンク1336は機能のデータに対する「Write」アクセスを表すコネクタである、ということがコメント1344として記されている。
Based on the “handle motor drive amount”
また、「スピード制御量」オブジェクト1308は、「後輪タイヤ駆動」オブジェクト1309を呼び出し、駆動する。駆動された「後輪タイヤ駆動」オブジェクト1309は、「タイヤ駆動量」オブジェクト1310を読み込む。なお、この読み込みを表すリンク1337にはコメント1346が付けられている。そして、リンク1337は機能のデータに対する「Read」アクセスを表すコネクタである、ということがコメント1346として記されている。
The “speed control amount”
「タイヤ駆動量」オブジェクト1310を読み込んだ「後輪タイヤ駆動」オブジェクト1309は、後輪のタイヤを駆動する制御を行う。すなわち、コメント1345に記すように、部品間のインタフェースとしての「タイヤ駆動量」オブジェクト1310を介して、「スピード制御量」オブジェクト1308から、決定されたタイヤ駆動量が、「後輪タイヤ駆動」オブジェクト1309に伝えられる。
A “rear wheel tire drive”
以上のようなロボットの制御ソフトウェアのモデルの編集に際して、第3実施形態のDSM支援装置104は、第1実施形態とは多少異なる振る舞いをする。以下、第1実施形態と異なる点について説明する。
When editing the robot control software model as described above, the
第3実施形態におけるDSM支援装置104は、図4に示す第1実施形態のDSM支援装置104と類似しているが、モデル作成ナビゲーション部403内の各コンポーネントの動作が第1実施形態とは異なる。
The
例えば、ソフトウェアのモデルを編集する処理において、部品用メニュー提供部405は、UMLのオブジェクト図上で、第3のメタモデル101c内で「機能」クラス1203のサブクラスとして定義されたコンクリートクラスをインスタンス化する。
For example, in the process of editing a software model, the part
例えば、部品用メニュー提供部405は、「LCD」クラス1212、「モータ」クラス1213、「グラフ特性」クラス1214、「光センサ」クラス1215および「タッチセンサ」クラス1216のみを、作成可能な部品の選択肢として提示してもよい。選択肢の提示は、UMLツール103を介して行われ、部品用メニュー提供部405は選択肢の中から1つを選択する入力を、入力装置401からUMLツール103を介して受け取ってもよい。
For example, the part
そして、部品用メニュー提供部405は、選択されたクラスをインスタンス化して新規オブジェクトを作成し、UMLのオブジェクト図に追加するようUMLツール103に命令する。また、部品用メニュー提供部405は、作成したオブジェクトのクラスを、入力装置401からUMLツール103を介して指定されるオブジェクト名とともに、モデル作成部410に通知する。
The component
例えば、「LightSensor1」オブジェクト1302の作成に際しては、新規作成されたオブジェクトは「光センサ」クラス1215のインスタンスであり「LightSensor1」という名前であるということが、モデル作成部410に通知される。
For example, when creating the “LightSensor1”
モデル作成部410は、第3のメタモデル101cから、「光センサ」クラス1215が「機能」クラス1203から間接的に派生していることを認識する。つまり、モデル作成部410は、作成された「LightSensor1」オブジェクト1302がインタフェースとしてのデータなどではなく、ソフトウェアの部品の一種であることを認識する。モデル作成部410はその認識に基づいて、「LightSensor1」オブジェクト1302を表すXMLコードを生成することでモデル106を編集する。
The
このように、第3実施形態では、第3のメタモデル101c中で定義されているメタ部品クラスでもあるコンクリートクラスが、そのままソフトウェアの部品を表す部品クラスとして使用可能である。よって、第1実施形態のように部品用メニュー提供部405が部品クラスからメタ部品クラスへの汎化を追加するといった処理は、第3実施形態では省略される。
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
インタフェースとしての「データ」クラス1204のオブジェクトの作成についても同様である。つまり、第3実施形態では、第3のメタモデル101c内の「データ」クラス1204がコンクリートクラスなので、インタフェース用メニュー提供部407は、メタインタフェースクラスへの汎化を追加する処理を行わなくてよい。
The same applies to the creation of an object of the “data”
インタフェース用メニュー提供部407は、UMLツール103を介して単に「データ」クラス1204をインスタンス化することで、例えば「路面の明るさ」オブジェクト1305をモデル図105gに追加する。そして、インタフェース用メニュー提供部407は、追加した「路面の明るさ」オブジェクト1305のオブジェクト名と所属クラスをモデル作成部410に通知する。
The interface
モデル作成部410は、第3のメタモデル101cから「データ」クラス1204がメタインタフェースクラス兼インタフェースクラスであることを認識するので、「路面の明るさ」オブジェクト1305がインタフェースをモデル化したものであると認識する。モデル作成部410はその認識に基づいて、「路面の明るさ」オブジェクト1305を表すXMLコードを生成することでモデル106を編集する。
Since the
また、第3のメタモデル101cはポートをメタモデル化したクラスを含まないので、第3実施形態ではポート用メニュー提供部406は省略されてよい。その代わり、モデル作成ナビゲーション部403は、インタフェースとしての「データ」クラス1204のオブジェクトを介した部品間のデータ入出力に関して、以下のように制約をかける。
Further, since the third metamodel 101c does not include a class obtained by metamodeling a port, the port
すなわち、モデル作成ナビゲーション部403は、ソフトウェアのモデルを表すUMLのオブジェクト図(例えば図17のモデル図105g)上において、「データ」クラス1204のオブジェクトと接続されるリンクに制約をかける。具体的には、第3のメタモデル101cの関連1268と1269が示すように、第3実施形態の表記ルール102によれば、「データ」クラス1204のオブジェクトとリンク可能なのは「機能」クラス1203から派生したクラスのオブジェクトのみである。
That is, the model
よって、モデル作成ナビゲーション部403は、第3のメタモデル101cと表記ルール102にしたがって、制約を満たすリンクを作成しようとする入力のみを許す。制約を満たさないリンクを作成しようとする入力を入力装置401からUMLツール103を介して受け取った場合、モデル作成ナビゲーション部403は、例えばUMLツール103を介して出力装置402に警告を表示させてもよい。
Therefore, the model
例えば、入力装置401からUMLツール103を介して、「路面の明るさ」オブジェクト1305と「ハンドルモータ駆動量」オブジェクト1306をリンクで接続しようとする入力を受け取った場合、モデル作成ナビゲーション部403は入力を拒絶する。
For example, when an input to connect a “road surface brightness”
また、第3実施形態におけるタスク用メニュー提供部409は、例えば、部品の駆動順序を指定するようユーザに促すダイアログを、UMLツール103を介して出力装置402に表示させてもよい。そして、タスク用メニュー提供部409は、ダイアログに対する入力にしたがってリンク1321等を追加し、追加したリンクの情報をモデル作成部410に通知し、モデル作成部410は通知された情報にしたがってモデル106を編集してもよい。
Further, the task
例えば、図17に示す各オブジェクトが作成済みの状態で、タスク用メニュー提供部409は、「タイヤ駆動タスク」オブジェクト1307、「スピード制御量」オブジェクト1308、「後輪タイヤ駆動」オブジェクト1309を順に指定する入力を受け取る。すると、タスク用メニュー提供部409は、指定された順序の先頭が「タスク」クラス1202のオブジェクトであるか否か、また、2番目以降のオブジェクトは「機能」クラス1203から派生したクラスのオブジェクトであるか否かをチェックする。
For example, with each object shown in FIG. 17 created, the task
この例ではチェックされる条件(すなわちモデル図105cと表記ルール102により示される制約条件)が満たされている。よって、タスク用メニュー提供部409は、入力にしたがって、モデル図105g上にリンク1324と1325を追加し、追加したリンク1324と1325の情報(例えばリンクの始点と終点の両オブジェクトを識別する情報)をモデル作成部410に通知する。
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
そして、モデル作成部410は、通知された情報にしたがって実行順序を示すXMLコードを生成することで、モデル106を編集する。
なお、本発明は上記の実施形態に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
Then, the
The present invention is not limited to the above-described embodiment, and can be variously modified. Some examples are described below.
メタモデル101は、上記の例に限らない。例えば、ソフトウェアの部品間の通信のインタフェースをメタモデル化することは、必ずしも必要という訳ではない。メタインタフェースクラスの定義を含まないメタモデルであっても、ユーザ定義のクラスからメタ部品クラスへの汎化により、ユーザ定義のクラスを「部品を意味するクラス」として自動的に解釈してソースコードを自動生成することを可能とする。
The
また、上記の例ではメタモデル101内の個々のクラスの詳細な属性と操作については省略したが、ドメインに応じて適宜メタモデル101内のクラスで属性と操作が定義されていてよい。
In the above example, detailed attributes and operations of individual classes in the
また、例えば図3では、第1のメタモデル101aで定義された「CompositionType」クラス202と「SenderReceiverInterface」クラス209から「部品A」クラス301と「インタフェースA」クラス302がそれぞれ直接派生している。しかし、メタモデル101中で定義されたメタ部品クラスから間接的に派生したクラスが、部品クラスとしてモデル図105で定義されてもよい。同様に、メタモデル101中で定義されたメタインタフェースクラスから間接的に派生したクラスが、インタフェースクラスとしてモデル図105で定義されてもよい。
For example, in FIG. 3, the “component A”
同様のことはポートについても言える。すなわち、図3の「受信ポート」ポート303と「送信ポート」ポート304は、第1のメタモデル101aで定義された「RequesterPort」クラス212と「ProviderPort」クラス213のオブジェクトである。しかし、「RequesterPort」クラス212や「ProviderPort」クラス213から派生したクラスのオブジェクトを、部品クラスが有するように、ソフトウェアがモデル化されてもよい。
The same is true for ports. That is, the “reception port”
つまり、モデル図105中のクラスないしオブジェクトが何をモデル化したものであるかということは、直接的な派生か間接的な派生かを問わず、メタモデル101で定義されたクラスへの汎化に基づいて自動的に解釈可能である。よって、例えば部品クラスがメタ部品クラスから間接的に派生したものであっても、上記実施形態と同様に「ソースコード109の自動生成を可能とする」という効果が得られる。
That is, what a class or object in the model diagram 105 is modeled is generalized to a class defined in the
また、メタモデル101は、ポートに関するクラスを含まなくてもよい。例えば第3実施形態のように、部品クラス(例えば「モータ」クラス1213)とインタフェースクラス(具体的には「データ」クラス1204)との間の関係を用いて、部品間のインタフェースを介した通信を表記することもできる。
Further, the
なお、上記の説明においては、理解を容易とするために、例えば図3において汎化305と306を図示している。しかし、汎化305と306は、データとしてDSM支援装置104が生成し認識してさえいればよく、実施形態によっては、出力装置402に図形として表示されなくてもよい。
In the above description, the
また、モデル106を記述する形式言語は、XMLでなくてもよい。XML以外の言語でモデル106を記述する場合は、図1のプロセスP102におけるコード生成は、XSLT技術以外の技術により行われる。
The formal language for describing the
また、上記の実施形態は、メタモデル101と表記ルール102による制約を満たすようにDSM支援装置104がUML図の作成をナビゲートする、いわば事前チェック型の実施形態である。しかし、ユーザが自由に作成したUML図を、メタモデル101と表記ルール102に基づいてDSM支援装置104が事後的にチェックし、メタモデル101と表記ルール102による制約を満たさない箇所をエラーとして警告するような実施形態も可能である。
In addition, the above-described embodiment is a so-called pre-check type embodiment in which the
その場合、モデル作成部410は、例えばエラーが検出されなくなった段階のモデル図105を入力として受け取り、モデル図105からモデル106を作成してもよい。また、この事後チェック型の実施形態においては、モデル作成部410は、モデル図105からモデル106を作成するための中間データとして、例えば、モデル図105の図形的な特徴を表すXMLデータを生成してもよい。
In that case, the
そして、モデル作成部410は、中間データとメタモデル101と表記ルール102に基づいて、最終的なモデル106を作成してもよい。中間データは、例えば、「どの矩形とどの矩形がどの線により接続されているか」といった図形的な特徴を表すものでもよい。モデル作成部410はメタモデル101と表記ルール102に基づいて、線や矩形の意味を解釈し、最終的なモデル106を作成することができる。
Then, the
例えば、部品クラスに関しては、上記の事前チェック型の実施形態では、部品用メニュー提供部405が、部品クラスを新規作成するための指示を受け取り、当該指示を契機として、メタ部品クラスのサブクラスを部品クラスとしてクラス図内に作成する。それに対し、事後チェック型の実施形態では、部品用メニュー提供部405は、クラス図内に作成された任意のクラスからメタ部品クラスへの汎化を追加するための指示を受け取り、当該指示を契機として、上記任意のクラスを部品クラスとして定義しなおす。
For example, regarding the component class, in the above-described pre-check type embodiment, the component
インタフェースクラスに関しても同様のことが言える。つまり、事前チェック型の実施形態ではインタフェース用メニュー提供部407が、インタフェースクラスを新規作成するための指示を受け取り、当該指示を契機として、メタインタフェースクラスのサブクラスをインタフェースクラスとしてクラス図内に作成する。それに対し、事後チェック型の実施形態では、インタフェース用メニュー提供部407は、クラス図内に作成された任意のクラスからメタインタフェースクラスへの汎化を追加するための指示を受け取る。そして、インタフェース用メニュー提供部407は当該指示を契機として、上記任意のクラスクラスをインタフェースクラスとして定義しなおす。
The same is true for interface classes. That is, in the pre-check type embodiment, the interface
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
(付記1)
コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、UMLで表記された第1のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記UMLで表記される第2のクラス図として生成するクラス図生成ステップと、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第2のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第2のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
(付記2)
前記第1のクラス図は、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義をさらに含み、
前記クラス図生成ステップは、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第2のクラス図において定義するインタフェース定義ステップと、
前記インタフェースクラスとの間の関係を用いて、前記部品間の前記通信を前記第2のクラス図において表記するインタフェース表記ステップと、
を含み、
前記意味モデル生成ステップは、前記第2のクラス図における前記インタフェースクラスとの間の前記関係を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語の第1のコードで表現し、前記意味モデルに前記第1のコードを含めるインタフェース解釈ステップを含む、
ことを特徴とする付記1に記載の意味モデル生成プログラム。
(付記3)
前記第1のクラス図には、前記メタ部品クラスに含まれるクラスとして、メタ通信ポートクラスが定義されており、
前記クラス図生成ステップは、前記第2のクラス図において、前記部品クラスを、前記メタ通信ポートクラスまたは前記メタ通信ポートクラスのサブクラスとして定義される通信ポートクラスのいずれかのオブジェクトである通信ポートオブジェクトを含むように定義する通信ポート定義ステップをさらに含み、
前記インタフェース表記ステップは、前記部品クラスに含まれる前記通信ポートオブジェクトから前記インタフェースクラスへの依存を用いて、前記部品間の前記インタフェースを介した前記通信を前記第2のクラス図において表記するステップである、
ことを特徴とする付記2に記載の意味モデル生成プログラム。
(付記4)
前記インタフェース表記ステップは、前記部品クラスと前記インタフェースクラスとの間の関係を用いて、前記部品間の前記インタフェースを介した前記通信を前記第2のクラス図において表記するステップである、
ことを特徴とする付記2に記載の意味モデル生成プログラム。
(付記5)
前記クラス図生成ステップは、
前記部品クラスを新規作成するための第1の指示を受け取り、前記第1の指示を契機として、前記メタ部品クラスのサブクラスを前記部品クラスとして前記第2のクラス図内に作成する部品定義ナビゲーションステップ、または
前記第2のクラス図内に作成された任意の第1のクラスから前記メタ部品クラスへの汎化を追加するための第2の指示を受け取り、前記第2の指示を契機として、前記第1のクラスを前記部品クラスとして定義しなおす部品事後定義ステップ
を含むことを特徴とする付記1〜4のいずれか1項に記載の意味モデル生成プログラム。
(付記6)
前記インタフェース定義ステップは、
前記インタフェースクラスを新規作成するための第3の指示を受け取り、前記第3の指示を契機として、前記メタインタフェースクラスのサブクラスを前記インタフェースクラスとして前記第2のクラス図内に作成するインタフェース定義ナビゲーションステップ、または
前記第2のクラス図内に作成された任意の第2のクラスから前記メタインタフェースクラスへの汎化を追加するための第4の指示を受け取り、前記第4の指示を契機として、前記第2のクラスを前記インタフェースクラスとして定義しなおすインタフェース事後定義ステップ
を含むことを特徴とする付記2〜4のいずれか1項に記載の意味モデル生成プログラム。
(付記7)
前記第1のクラス図には、
部品同士が入れ子になってもよいことを示すための第1の集約関係と、
入れ子になった内部部品を有する外部部品の内部での、前記外部部品と前記内部部品との間の通信を表すためのメタ内部通信クラスと、
前記メタ部品クラスに前記メタ内部通信クラスが含まれることを示す第2の集約関係と、
が定義されており、
前記第2のクラス図において、前記部品クラスが複数あり、複数の前記部品クラスのうち前記外部部品をモデル化した外部部品クラスの中に、複数の前記部品クラスのうち前記内部部品をモデル化した内部部品クラスが入れ子になって含まれるとき、
前記クラス図生成ステップは、前記外部部品クラスと前記内部部品クラスの間に、前記メタ内部通信クラスに対応する関係である内部通信関係を定義する内部通信定義ステップを含み、
前記意味モデル生成ステップは、前記外部部品クラスと前記内部部品クラスそれぞれからの前記メタ部品クラスへの汎化と前記メタ内部通信クラスの定義とに基づいて、前記内部通信関係を、前記外部部品クラスと前記内部部品クラスの間の前記通信を意味する前記所定の形式言語の第2のコードで表現し、前記意味モデルに前記第2のコードを含める内部通信解釈ステップを含む、
ことを特徴とする付記1〜6のいずれか1項に記載の意味モデル生成プログラム。
(付記8)
前記意味モデル生成プログラムは前記コンピュータにさらに、前記第2のクラス図で定義された前記部品クラスのオブジェクトを定義するオブジェクト図に含まれるオブジェクト間の呼び出しを定義するシーケンス図を生成するシーケンス図生成ステップを実行させ、
前記意味モデル生成ステップは、前記シーケンス図の内容に基づいて、前記呼び出しの順序を前記所定の形式言語で表す第3のコードを生成し、前記第3のコードを前記意味モデルに含める第1の順序定義ステップを含む、
ことを特徴とする付記1〜7のいずれか1項に記載の意味モデル生成プログラム。
(付記9)
前記第1のクラス図には、前記メタ部品クラスに含まれるクラスとして、メタ呼び出しポートクラスが集約関係を使って定義されており、
前記クラス図生成ステップは、前記メタ呼び出しポートクラスまたは前記メタ呼び出しポートクラスのサブクラスのいずれかのオブジェクトである呼び出しポートオブジェクトを1つ以上備えるように前記部品クラスを定義する呼び出しポート定義ステップを含み、
前記意味モデル生成プログラムは前記コンピュータにさらに、前記第2のクラス図で定義された1つ以上の前記部品クラスの合計複数個のオブジェクトを定義するオブジェクト図において、前記オブジェクト図内の各オブジェクトがそれぞれ備える前記呼び出しポートオブジェクト間の関係を用いて、前記各オブジェクト間の呼び出しを表記する呼び出し表記ステップを実行させ、
前記意味モデル生成ステップは、前記オブジェクト図に表記された前記各オブジェクト間の前記呼び出しに基づいて、どのオブジェクトがどのオブジェクトを呼び出すかを前記所定の形式言語で表す第4のコードを生成し、前記意味モデルに前記第4のコードを含める第2の順序定義ステップを含む、
ことを特徴とする付記1〜7のいずれか1項に記載の意味モデル生成プログラム。
(付記10)
コンピュータに、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義と、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義とを含み、UMLで表記されたクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記メタ部品クラスまたは前記メタ部品クラスのサブクラスをインスタンス化した少なくとも2つの部品オブジェクトと、前記メタインタフェースクラスまたは前記メタインタフェースクラスのサブクラスをインスタンス化したインタフェースオブジェクトと、前記少なくとも2つの部品オブジェクトの各々と前記インタフェースオブジェクトの間のリンクを含む、前記UMLで表記されるオブジェクト図を、前記ソフトウェアのモデルとして生成するオブジェクト図生成ステップと、
前記少なくとも2つの部品オブジェクトが前記メタ部品クラスから派生していることと、前記インタフェースオブジェクトが前記メタインタフェースクラスから派生していることと、前記リンクが存在することと、前記メタモデルとに基づいて、前記オブジェクト図は前記部品同士が前記インタフェースを介して通信することをモデル化しているという意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。
(付記11)
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、UMLで表記された第1のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを格納する格納手段と、
前記格納手段から前記メタモデルを読み出して、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記UMLで表記される第2のクラス図として生成するクラス図生成手段と、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第2のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第2のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成手段と、
を備えることを特徴とする意味モデル生成装置。
(付記12)
コンピュータが、
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、UMLで表記された第1のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得し、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記UMLで表記される第2のクラス図として生成し、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第2のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第2のクラス図の意味を所定の形式言語により表す意味モデルを生成する、
ことを特徴とする意味モデル生成方法。
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
(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
(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
(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
(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
(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
(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
(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
(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 メタモデル
102 表記ルール
103 UMLツール
104 DSM支援装置
105、105a〜105g モデル図
106、106a モデル
107 コード生成テンプレート
108 コード生成装置
109 ソースコード
110 中間データ
201〜216、301、302、601、701、902〜904、1001〜1003、1201〜1216 クラス
251〜272、305〜308、610、614、615、709、901、905〜910、1012〜1018、1251〜1269 関係(汎化、関連、依存、集約、合成集約)
303、304、604〜609、705〜708、1004〜1011、1106〜1121 ポート
401 入力装置
402 出力装置
403 モデル作成ナビゲーション部
404 メニュー選択部
405 部品用メニュー提供部
406 ポート用メニュー提供部
407 インタフェース用メニュー提供部
408 内部部品用メニュー提供部
409 タスク用メニュー提供部
410 モデル作成部
411 記憶装置
412 モデル図格納部
413 意味モデル格納部
414 テンプレート格納部
415 ソースコード格納部
416 メタモデル格納部
500 コンピュータ
501 CPU
502 ROM
503 RAM
504 通信インタフェース
505 ハードディスク装置
506 可搬型記憶媒体
507 駆動装置
508 バス
509 ネットワーク
510 プログラム提供者
602、603、702〜704、1101〜1105、1301〜1310 オブジェクト
611〜613、710、1122〜1128、1321〜1325、1331〜1337 リンク
801〜803 活性期間
804、805 呼び出し
1341〜1346 コメント
1351〜1356 点線
101, 101a-
303, 304, 604 to 609, 705 to 708, 1004 to 1011, 1106 to 1121
502 ROM
503 RAM
504
Claims (9)
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義を含み、UMLで表記された第1のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記ソフトウェアに含まれる部品を表すどの部品クラスも前記メタ部品クラスのサブクラスとして表記せよ、という制約条件のもとで、ユーザからの入力に基づいて各部品クラスを定義することにより、前記ソフトウェアを前記メタモデルに適合するようにモデル化したモデルを、各部品クラスを含み前記UMLで表記される第2のクラス図として生成するクラス図生成ステップと、
各部品クラスから前記メタ部品クラスへの、前記制約条件にしたがって表記された汎化と、前記メタモデルとに基づいて、前記第2のクラス図における各部品クラスが各部品をモデル化したクラスであるという前記第2のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。 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
前記クラス図生成ステップは、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第2のクラス図において定義するインタフェース定義ステップと、
前記インタフェースクラスとの間の関係を用いて、前記部品間の前記通信を前記第2のクラス図において表記するインタフェース表記ステップと、
を含み、
前記意味モデル生成ステップは、前記第2のクラス図における前記インタフェースクラスとの間の前記関係を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語のコードで表現し、前記意味モデルに前記コードを含めるインタフェース解釈ステップを含む、
ことを特徴とする請求項1に記載の意味モデル生成プログラム。 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:
ソフトウェアが含む部品をメタモデル化したメタ部品クラスの定義と、前記部品間の通信のインタフェースをメタモデル化したメタインタフェースクラスの定義を含み、さらに前記メタ部品クラスに含まれるクラスとしてメタ通信ポートクラスを定義しており、UMLで表記された第1のクラス図により、前記ソフトウェアをメタモデル化して表すメタモデルを取得するメタモデル取得ステップと、
前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記UMLで表記される第2のクラス図として生成するクラス図生成ステップであって、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第2のクラス図において定義するインタフェース定義ステップと、
前記第2のクラス図において、前記部品クラスを、前記メタ通信ポートクラスまたは前記メタ通信ポートクラスのサブクラスとして定義される通信ポートクラスのいずれかのオブジェクトである通信ポートオブジェクトを含むように定義する通信ポート定義ステップと、
前記部品クラスに含まれる前記通信ポートオブジェクトから前記インタフェースクラスへの依存を用いて、前記部品間の前記インタフェースを介した前記通信を前記第2のクラス図において表記するインタフェース表記ステップ
を含むクラス図生成ステップと、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第2のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第2のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成ステップであって、
前記第2のクラス図における前記インタフェースクラスへの前記依存を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語のコードで表現し、前記意味モデルに前記コードを含めるインタフェース解釈ステップ
を含む意味モデル生成ステップと、
を実行させることを特徴とする意味モデル生成プログラム。 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
前記部品クラスを新規作成するための第1の指示を受け取り、前記第1の指示を契機として、前記メタ部品クラスのサブクラスを前記部品クラスとして前記第2のクラス図内に作成する部品定義ナビゲーションステップ、または
前記第2のクラス図内に作成された任意の第1のクラスから前記メタ部品クラスへの汎化を追加するための第2の指示を受け取り、前記第2の指示を契機として、前記第1のクラスを前記部品クラスとして定義しなおす部品事後定義ステップ
を含むことを特徴とする請求項1〜3のいずれか1項に記載の意味モデル生成プログラム。 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.
前記インタフェースクラスを新規作成するための第3の指示を受け取り、前記第3の指示を契機として、前記メタインタフェースクラスのサブクラスを前記インタフェースクラスとして前記第2のクラス図内に作成するインタフェース定義ナビゲーションステップ、または
前記第2のクラス図内に作成された任意の第2のクラスから前記メタインタフェースクラスへの汎化を追加するための第4の指示を受け取り、前記第4の指示を契機として、前記第2のクラスを前記インタフェースクラスとして定義しなおすインタフェース事後定義ステップ
を含むことを特徴とする請求項2または3に記載の意味モデル生成プログラム。 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.
前記メタ部品クラスが前記メタパラメタクラスを含み得ることを示す集約と、前記メタ部品クラスが前記メタ実行可能実体クラスを含むことを示す集約が、前記第1のクラス図において定義されており、
前記クラス図生成ステップは、
前記部品クラスで定義される属性を前記メタパラメタクラスと対応づけるための第1の所定の表記を、前記第2のクラス図に付加するか否かを、前記ユーザからの入力に基づいて決める第1の決定ステップと、
前記部品クラスで定義される操作を前記メタ実行可能実体クラスと対応づけるための第2の所定の表記を、前記第2のクラス図に付加するか否かを、前記ユーザからの入力に基づいて決める第2の決定ステップ
を含み、
前記意味モデル生成ステップは、
各部品クラスで定義される各属性のうち、前記第1の所定の表記により前記メタパラメタクラスと対応づけられている属性について、当該属性が当該部品に特徴を与えることを示すコードを生成し、該生成したコードを前記意味モデルに含める属性解釈ステップと、
各部品クラスで定義される各操作のうち、前記第2の所定の表記により前記メタ実行可能実体クラスと対応づけられている操作について、当該操作が、外部から当該部品を駆動するために外部から呼び出し可能な、パブリックな操作であることを示すコードを生成し、該生成したコードを前記意味モデルに含める操作解釈ステップ
を含む
ことを特徴とする請求項1または2に記載の意味モデル生成プログラム。 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.
前記格納手段から前記メタモデルを読み出して、前記ソフトウェアに含まれる部品を表すどの部品クラスも前記メタ部品クラスのサブクラスとして表記せよ、という制約条件のもとで、ユーザからの入力に基づいて各部品クラスを定義することにより、前記ソフトウェアを前記メタモデルに適合するようにモデル化したモデルを、各部品クラスを含み前記UMLで表記される第2のクラス図として生成するクラス図生成手段と、
各部品クラスから前記メタ部品クラスへの、前記制約条件にしたがって表記された汎化と、前記メタモデルとに基づいて、前記第2のクラス図における各部品クラスが各部品をモデル化したクラスであるという前記第2のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成手段と、
を備えることを特徴とする意味モデル生成装置。 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:
前記格納手段から前記メタモデルを読み出して、前記ソフトウェアに含まれる部品を表す部品クラスを、前記メタ部品クラスのサブクラスとして定義することにより、前記ソフトウェアを前記メタモデルにしたがってモデル化したモデルを、前記部品クラスを含み前記UMLで表記される第2のクラス図として生成するクラス図生成手段であって、
前記部品間の前記通信の前記インタフェースをモデル化したインタフェースクラスを、前記メタインタフェースクラスのサブクラスとして、前記第2のクラス図において定義するインタフェース定義手段と、
前記第2のクラス図において、前記部品クラスを、前記メタ通信ポートクラスまたは前記メタ通信ポートクラスのサブクラスとして定義される通信ポートクラスのいずれかのオブジェクトである通信ポートオブジェクトを含むように定義する通信ポート定義手段と、
前記部品クラスに含まれる前記通信ポートオブジェクトから前記インタフェースクラスへの依存を用いて、前記部品間の前記インタフェースを介した前記通信を前記第2のクラス図において表記するインタフェース表記手段
を含むクラス図生成手段と、
前記部品クラスから前記メタ部品クラスへの汎化と前記メタモデルに基づいて、前記第2のクラス図における前記部品クラスが前記部品をモデル化したクラスであるという前記第2のクラス図の意味を所定の形式言語により表す意味モデルを生成する意味モデル生成手段であって、
前記第2のクラス図における前記インタフェースクラスへの前記依存を、前記インタフェースクラスから前記メタインタフェースクラスへの汎化に基づいて、前記部品間の前記インタフェースを介した前記通信を意味する前記所定の形式言語のコードで表現し、前記意味モデルに前記コードを含めるインタフェース解釈手段
を含む意味モデル生成手段と、
を備えることを特徴とする意味モデル生成装置。 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:
前記メタ部品クラスが前記メタパラメタクラスを含み得ることを示す集約と、前記メタ部品クラスが前記メタ実行可能実体クラスを含むことを示す集約が、前記第1のクラス図において定義されており、
前記クラス図生成手段は、
前記部品クラスで定義される属性を前記メタパラメタクラスと対応づけるための第1の所定の表記を、前記第2のクラス図に付加するか否かを、前記ユーザからの入力に基づいて決める第1の決定手段と、
前記部品クラスで定義される操作を前記メタ実行可能実体クラスと対応づけるための第2の所定の表記を、前記第2のクラス図に付加するか否かを、前記ユーザからの入力に基づいて決める第2の決定手段
を含み、
前記意味モデル生成手段は、
各部品クラスで定義される各属性のうち、前記第1の所定の表記により前記メタパラメタクラスと対応づけられている属性について、当該属性が当該部品に特徴を与えることを示すコードを生成し、該生成したコードを前記意味モデルに含める属性解釈手段と、
各部品クラスで定義される各操作のうち、前記第2の所定の表記により前記メタ実行可能実体クラスと対応づけられている操作について、当該操作が、外部から当該部品を駆動するために外部から呼び出し可能な、パブリックな操作であることを示すコードを生成し、該生成したコードを前記意味モデルに含める操作解釈手段
を含む
ことを特徴とする請求項7に記載の意味モデル生成装置。 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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009198983A JP5457761B2 (en) | 2009-08-28 | 2009-08-28 | Semantic model generation program and semantic model generation apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009198983A JP5457761B2 (en) | 2009-08-28 | 2009-08-28 | Semantic model generation program and semantic model generation apparatus |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2011048796A JP2011048796A (en) | 2011-03-10 |
JP5457761B2 true JP5457761B2 (en) | 2014-04-02 |
Family
ID=43835004
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009198983A Expired - Fee Related JP5457761B2 (en) | 2009-08-28 | 2009-08-28 | Semantic model generation program and semantic model generation apparatus |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5457761B2 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3370147A4 (en) | 2015-10-30 | 2019-06-26 | Kabushiki Kaisha Toshiba | System design device and method |
KR102041422B1 (en) * | 2018-09-06 | 2019-11-27 | 조용행 | Application Design Method and Apparatus |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4865323B2 (en) * | 2005-12-21 | 2012-02-01 | 三菱電機株式会社 | Graphic information processing device |
JP2008225898A (en) * | 2007-03-13 | 2008-09-25 | Toshiba Corp | Conversion device, conversion program, and conversion method |
-
2009
- 2009-08-28 JP JP2009198983A patent/JP5457761B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2011048796A (en) | 2011-03-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6489970B1 (en) | Means for specifying direct manipulation relationships on hierarchically structured visuals | |
US7089256B2 (en) | Universal data editor | |
Limbourg et al. | USIXML: A language supporting multi-path development of user interfaces | |
JP2006107478A (en) | Extensible flamework for designing work flow | |
Limbourg | Multi-path development of user interfaces | |
US20070288892A1 (en) | System and method for providing and using meta-data in a dynamically typed array-based language | |
Meixner et al. | Model-driven useware engineering | |
US20080250316A1 (en) | Mechanism to improve a user's interaction with a computer system | |
JP2010534870A (en) | Consistent method system and computer program for developing software asset based solutions | |
US20070178968A1 (en) | Displaying game asset relationship in a game development environment | |
Blouin et al. | Improving modularity and usability of interactive systems with Malai | |
JP2013518321A (en) | Pattern-based user interface | |
JP5457761B2 (en) | Semantic model generation program and semantic model generation apparatus | |
Jelinek et al. | GUI generation from annotated source code | |
Griffiths et al. | Exploiting model-based techniques for user interfaces to databases | |
Coyette et al. | Sketchixml: A design tool for informal user interface rapid prototyping | |
Meixner et al. | Udit–a graphical editor for task models | |
Crowle et al. | ISML: an interface specification meta-language | |
Smyth | Android Studio 4.0 Development Essentials-Kotlin Edition | |
Paternò et al. | User task-based development of multi-device service-oriented applications. | |
CN106445487B (en) | Processing unit, software and method for controlling an interactive component | |
Smyth | Android Studio 3.5 Development Essentials-Kotlin Edition: Developing Android 10 (Q) Apps Using Android Studio 3.5, Kotlin and Android Jetpack | |
Smyth | Android Studio 3.4 Development Essentials-Kotlin Edition | |
Mitchell et al. | DRIVE: an environment for the organised construction of user-interfaces to databases | |
Smyth | Android Studio 3.6 Development Essentials-Kotlin Edition: Developing Android 10 (Q) Apps Using Android Studio 3.6, Kotlin and Android Jetpack |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120510 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130319 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130416 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130617 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20131203 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20131212 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140107 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140110 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5457761 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |