JP2013045350A - モデル変換装置、モデル変換方法、およびプログラム - Google Patents
モデル変換装置、モデル変換方法、およびプログラム Download PDFInfo
- Publication number
- JP2013045350A JP2013045350A JP2011183827A JP2011183827A JP2013045350A JP 2013045350 A JP2013045350 A JP 2013045350A JP 2011183827 A JP2011183827 A JP 2011183827A JP 2011183827 A JP2011183827 A JP 2011183827A JP 2013045350 A JP2013045350 A JP 2013045350A
- Authority
- JP
- Japan
- Prior art keywords
- class
- interface
- channel
- model
- conversion
- 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.)
- Withdrawn
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
- G06F30/3323—Design verification, e.g. functional simulation or model checking using formal methods, e.g. equivalence checking or property checking
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
【課題】煩雑な手間や時間をかけることなく、シミュレーション用インターフェースモデルと動作合成用インターフェースモデルとを等価性を保ったまま相互に変換することが可能なモデル変換装置、モデル変換方法、およびプログラムを提供する。
【解決手段】固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形し変形後の代数表現の双方が一致すれば数学的にモデルに等価性があるとして、モデルの相互変換を行う処理部を有し、処理部は、代数的に等価性を保つ以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う。ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、ｃ：プロセスリマッピング操作。
【選択図】図１
【解決手段】固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形し変形後の代数表現の双方が一致すれば数学的にモデルに等価性があるとして、モデルの相互変換を行う処理部を有し、処理部は、代数的に等価性を保つ以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う。ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、ｃ：プロセスリマッピング操作。
【選択図】図１
Description
本技術は、いわゆるシミュレーション用インターフェースモデルと動作合成用インターフェースモデルを相互に変換するモデル変換装置、モデル変換方法、およびプログラムに関するものである。
ＳｙｓｔｅｍＣで記述したシミュレーション用インターフェースモデルと動作合成用インターフェースモデルとでは記述スタイル、抽象レベルが異なっている。
シミュレーション用インターフェースモデルではチャネルでモジュールのポートを接続する。
また、動作合成用モデルはハードウェア的にワイヤ（ｓｃ ｓｉｇｎａｌチャネル）でモジュールのピン端子を接続する。
シミュレーション用インターフェースモデルではチャネルでモジュールのポートを接続する。
また、動作合成用モデルはハードウェア的にワイヤ（ｓｃ ｓｉｇｎａｌチャネル）でモジュールのピン端子を接続する。
一般的に、このようなシミュレーション用インターフェースモデルから動作合成用インターフェースモデルに変換する方法としては、次の２つの方法が採用されている。
第１の方法は、手動でモデルを書き直す方法である。
なお、第１の方法については、非特許文献１の記載が参照される。非特許文献１の１５頁、図１５において、ＳｙｓＣ/Ｃ++/Ｃ ｍｏｄｕｌｅとＳｙｎｔｈｅｓｉｚａｂｌｅ ＳｙｓＣ/Ｃ++/Ｃモデル間には手動によるリファインメントとなっている。
これは、まさに手動でモデルを書き直すことに他ならない。なお、ＳｙｓＣは非特許文献１においてＳｙｓｔｅｍＣの略記である。
なお、第１の方法については、非特許文献１の記載が参照される。非特許文献１の１５頁、図１５において、ＳｙｓＣ/Ｃ++/Ｃ ｍｏｄｕｌｅとＳｙｎｔｈｅｓｉｚａｂｌｅ ＳｙｓＣ/Ｃ++/Ｃモデル間には手動によるリファインメントとなっている。
これは、まさに手動でモデルを書き直すことに他ならない。なお、ＳｙｓＣは非特許文献１においてＳｙｓｔｅｍＣの略記である。
第２の方法は、事前に２通りの記述スタイルでモデルを構築・ライブラリ化し、ライブラリ使用の度に与えられた入力条件下でのシミュレーションによる期待値一致を確認する方法である。
第２の方法は、当業者なら容易になしえるであろう、第１の方法の運用面での派生である。
第２の方法は、当業者なら容易になしえるであろう、第１の方法の運用面での派生である。
また、ＵＭＬ（Unified Modeling Language）クラス図の形式化については非特許文献２に詳細に記載されている。
そして、ＵＭＬクラス図の意味論的整合性判定については非特許文献３〜５に記載されている。
そして、ＵＭＬクラス図の意味論的整合性判定については非特許文献３〜５に記載されている。
：SystemC Synthesizable Subset Draft 1.3 (http://www.systemc.org/downloads/drafts_reviewからダウンロード可能)
：Berardi, Calvanese, De Giacomo, "Reasoning on UML class diagrams", Artificial Intelligence Vol. 168, Issue 1
：遠城秀和, 田名部元成, 飯島淳一. クラス図間の意味論的整合性判定におけるクラス図代数への一考察, 経営情報学会2008年度春季全国研究発表大会, 経営情報学会2008年度秋季全国研究発表大会予稿集, pp. E3-3, Nov. 2008.
：遠城秀和, 飯島淳一. クラス図間の整合性判定におけるクラス図代数への一考察, 経営情報学会2008年度春季全国研究発表大会, 経営情報学会2008年度春季全国研究発表大会予稿集, pp. H4-2, Jun. 2008.
：遠城秀和, 飯島淳一. クラス図間の整合性判定におけるクラス図代数への一考察, 経営情報学会2008年度春季全国研究発表大会, 経営情報学会2008年度春季全国研究発表大会予稿集, pp. H4-2, Jun. 2008.
しかしながら、第１の方法によれば、設計の度にＳｙｓｔｅｍＣで記述したインターフェースモデルと動作合成用可能なインターフェースモデルとの２つのモデルに対するダブルメンテナンスを継続する必要がある。
あるいは、第１の方法によれば、動作合成可能なインターフェースモデルを次の設計フェーズである論理合成フェーズ以降の参照モデルとして使用しＳｙｓｔｅｍＣで記述したインターフェースモデルの保守を諦めるかしかない。
あるいは、第１の方法によれば、動作合成可能なインターフェースモデルを次の設計フェーズである論理合成フェーズ以降の参照モデルとして使用しＳｙｓｔｅｍＣで記述したインターフェースモデルの保守を諦めるかしかない。
第２の方法のライブラリ化手法を使用すると、十分に実績を積むことによりライブラリとして使用された２つのモデルの与えられた入力条件下でのシミュレーションによる期待値一致の確度を高めることは可能ではある。
しかし、第２の方法は実績値のみで判断していることから、設計の度に入力条件が実績のある入力条件の範疇にあるかを確認するか、あるいは改めてシミュレーションによる期待値一致検証を実行する必要がある。
また万一問題が生じた場合には、使用したインターフェースライブラリの入力条件下での妥当性の再検討、あるいはインターフェースライブラリを使用した箇所のユーザー記述の誤りを疑う必要があり、膨大なデバッグ時間を必要とする。
しかし、第２の方法は実績値のみで判断していることから、設計の度に入力条件が実績のある入力条件の範疇にあるかを確認するか、あるいは改めてシミュレーションによる期待値一致検証を実行する必要がある。
また万一問題が生じた場合には、使用したインターフェースライブラリの入力条件下での妥当性の再検討、あるいはインターフェースライブラリを使用した箇所のユーザー記述の誤りを疑う必要があり、膨大なデバッグ時間を必要とする。
また、ＵＭＬクラス図の形式化については上述したように非特許文献２に詳細に記載されている。
しかし、この記載はあくまでクラスの数学的な意味づけを対象としており、クラスのインスタンス、およびそのインスタンス間の接続構造を含むＵＭＬコンポーネント図の形式化については全く言及されておらず、示唆もされていない。
しかし、この記載はあくまでクラスの数学的な意味づけを対象としており、クラスのインスタンス、およびそのインスタンス間の接続構造を含むＵＭＬコンポーネント図の形式化については全く言及されておらず、示唆もされていない。
また、ＵＭＬクラス図の意味論的整合性判定については上述したように、非特許文献３〜５の記載されている。
しかし、ここでも上述のクラスのインスタンス、およびそのインスタンス間の接続構造を含むＵＭＬコンポーネント図の整合性判定については、全く言及されておらず、示唆もされていない。
さらに、数学的整合性に基づいた操作によるモデルの変換手順を開示するものではなく、単に任意操作後の整合性を判定するのみである。
しかし、ここでも上述のクラスのインスタンス、およびそのインスタンス間の接続構造を含むＵＭＬコンポーネント図の整合性判定については、全く言及されておらず、示唆もされていない。
さらに、数学的整合性に基づいた操作によるモデルの変換手順を開示するものではなく、単に任意操作後の整合性を判定するのみである。
本技術は、煩雑な手間や時間をかけることなく、シミュレーション用インターフェースモデルと動作合成用インターフェースモデルとを等価性を保ったまま相互に変換することが可能なモデル変換装置、モデル変換方法、およびプログラムを提供することにある。
本技術の第１の観点のモデル変換装置は、固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形し、変形後の代数表現の双方が一致すればモデルに等価性があるとして、モデルの相互変換を行う処理部を有し、インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルが使用され、上記処理部は、代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う。ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、ｃ：プロセスリマッピング操作。
本技術の第２の観点のモデル変換方法は、固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する変形ステップと、変形後の代数表現の双方が一致するか否かを判定する判定ステップと、変形後の代数表現の双方が一致すればモデルに等価性があるとして、モデルの相互変換を行う変換ステップと、を有し、インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルを使用し、上記変換ステップにおいては、代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う。ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、ｃ：プロセスリマッピング操作。
本技術の第３の観点は、固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する変形処理と、変形後の代数表現の双方が一致するか否かを判定する判定処理と、変形後の代数表現の双方が一致すれば（数学的に）モデルに等価性があるとして、モデルの相互変換を行う変換処理と、を有し、インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルを使用し、上記変換処理においては、代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う、ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、ｃ：プロセスリマッピング操作、を含むモデル変換処理をコンピュータに実行させるプログラムである。
本技術によれば、煩雑な手間や時間をかけることなく、シミュレーション用インターフェースモデルと動作合成用インターフェースモデルとを等価性を保ったまま相互に変換することが可能となる。
以下、本技術の実施形態を図面に関連付けて説明する。
なお、説明は以下の順序で行う。
１．第１の実施形態（モデル変換装置の第１の構成例）
２．第２の実施形態（モデル変換装置の第２の構成例）
３．第３の実施形態（モデル変換装置の第３の構成例）
４．第４の実施形態（モデル変換装置の第４の構成例）
５．モデル変換処理のより具体的処理例
６．第１実施例
７．第２実施例
８．第３実施例
９．第４実施例
１０．第５実施例
なお、説明は以下の順序で行う。
１．第１の実施形態（モデル変換装置の第１の構成例）
２．第２の実施形態（モデル変換装置の第２の構成例）
３．第３の実施形態（モデル変換装置の第３の構成例）
４．第４の実施形態（モデル変換装置の第４の構成例）
５．モデル変換処理のより具体的処理例
６．第１実施例
７．第２実施例
８．第３実施例
９．第４実施例
１０．第５実施例
＜１、第１の実施形態＞
図１は、本第１の実施形態に係るモデル変換装置の構成例を示す図である。
図１は、本第１の実施形態に係るモデル変換装置の構成例を示す図である。
図１のモデル変換装置１０は、中央処理装置１１、入出力処理装置１２、クラス解析装置１３、変換モード切替装置１４、ペイロード処理装置１５、インターフェース装置１６、およびプロセスリマッピング処理装置１７を有する。
モデル変換装置１０は、入出力処理装置１２により情報の入出力を制御されるキーボード１８、ＬＣＤ等のディスプレイ１９、および外部記憶装置２０を有する。
このモデル変換装置１０は、後述する第１実施例に適用される。
モデル変換装置１０は、入出力処理装置１２により情報の入出力を制御されるキーボード１８、ＬＣＤ等のディスプレイ１９、および外部記憶装置２０を有する。
このモデル変換装置１０は、後述する第１実施例に適用される。
そして、中央処理装置１１、入出力処理装置１２、クラス解析装置１３、変換モード切替装置１４、ペイロード処理装置１５、インターフェース装置１６、およびプロセスリマッピング処理装置１７により処理部が構成される。
なお、クラス解析装置１３、変換モード切替装置１４、ペイロード処理装置１５、インターフェース装置１６、およびプロセスリマッピング処理装置１７の各処理はプログラムにより処理を実行可能である。
なお、クラス解析装置１３、変換モード切替装置１４、ペイロード処理装置１５、インターフェース装置１６、およびプロセスリマッピング処理装置１７の各処理はプログラムにより処理を実行可能である。
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、そのデータを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルが使用される。
本実施形態の処理部は、固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する。
処理部は、変形後の代数表現の双方が一致すれば数学的にモデルに等価性があるとして、モデルの相互変換を行う。
そして、処理部は、代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う。
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作。
本実施形態の処理部は、固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する。
処理部は、変形後の代数表現の双方が一致すれば数学的にモデルに等価性があるとして、モデルの相互変換を行う。
そして、処理部は、代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う。
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作。
処理部は、シミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モード（階層チャネル検索）の際には、チャネルの束ねを解くペイロード公開、インターフェースおよびチャネル分解、並びにプロセスリマッピングを行う。
このシミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モード（階層チャネル検索）を第１の変換モードとする。
このシミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モード（階層チャネル検索）を第１の変換モードとする。
処理部は、動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モード（集約チャネル検索）の際には、チャネルの束ねるペイロード隠蔽、インターフェースおよびチャネル集約、並びに、プロセスリマッピングを行う。
この動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モード（集約チャネル検索）を第２の変換モードとする。
この動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モード（集約チャネル検索）を第２の変換モードとする。
本実施形態において、上述した代数定義として、次の４つの代数的意味定義ｅ，ｆ，ｇ，ｈを持つ。
ｅ：クラスが交換可能であることを意味するクラス等価、
ｆ：クラスが条件付きで交換可能であることを意味する条件付きクラス等価、
ｇ：クラスがあるクラスの派生であることを意味する派生クラス、
ｈ：ある関数があるクラスに属する関数であることを意味するメンバ関数
ｅ：クラスが交換可能であることを意味するクラス等価、
ｆ：クラスが条件付きで交換可能であることを意味する条件付きクラス等価、
ｇ：クラスがあるクラスの派生であることを意味する派生クラス、
ｈ：ある関数があるクラスに属する関数であることを意味するメンバ関数
本実施形態において、上述した代数定義として、ＳｙｓｔｅｍＣ言語を設計記述言語とする場合には、次の７つの代数的意味定義ｉ，ｊ，ｋ，ｌ，ｍ，ｎ，ｏを持つ。
ｉ：sc_channelとsc_moduleがクラス等価であること、
ｊ：すべてのインターフェースクラスはsc_interfaceクラスの派生クラスであること、
ｋ：すべてのポートクラスはインターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスであること、
ｌ：ポートクラスがチャネルクラスをバインドすること、
ｍ：Ｍという条件、
ｎ：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば
ｎ１：あるポートクラスがあるインターフェースクラスの派生クラスである場合のポートクラスのメンバ関数と、
ｎ２：あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスであり、かつあるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数とは等価であること、
ｏ：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価。
ｉ：sc_channelとsc_moduleがクラス等価であること、
ｊ：すべてのインターフェースクラスはsc_interfaceクラスの派生クラスであること、
ｋ：すべてのポートクラスはインターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスであること、
ｌ：ポートクラスがチャネルクラスをバインドすること、
ｍ：Ｍという条件、
ｎ：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば
ｎ１：あるポートクラスがあるインターフェースクラスの派生クラスである場合のポートクラスのメンバ関数と、
ｎ２：あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスであり、かつあるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数とは等価であること、
ｏ：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価。
このような処理部において、中央処理装置１１は、モデル変換装置１０の全体を統合的に制御する。
中央処理装置１１は、入出力処理装置１２を介しキーボード１８や外部記憶装置２０により入力される固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの情報を入力する。
中央処理装置１１は、入出力処理装置１２から入力したモデル情報をクラス解析装置１３に供給する。
中央処理装置１１は、変換モード切替装置１４の切替情報に応じた処理をペイロード処理装置１５、インターフェース装置１６、およびプロセスリマッピング処理装置１７に行わせる。
中央処理装置１１は、入出力処理装置１２を介しキーボード１８や外部記憶装置２０により入力される固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの情報を入力する。
中央処理装置１１は、入出力処理装置１２から入力したモデル情報をクラス解析装置１３に供給する。
中央処理装置１１は、変換モード切替装置１４の切替情報に応じた処理をペイロード処理装置１５、インターフェース装置１６、およびプロセスリマッピング処理装置１７に行わせる。
クラス解析装置１３は、入力したモデル情報から得られた構造情報を基にクラス解析処理を行い、データベースを作成する。このデータベース情報は入出力処理装置１２を通して、ディスプレイ１９に表示され、また、外部記憶装置２０に格納される。
変換モード切替装置１４は、第１の変換モードまたは第２の変換モードに応じた処理を行うように、中央処理装置１１、ペイロード処理装置１５、インターフェース装置１６、およびプロセスリマッピング処理装置１７に報知する。
ペイロード処理装置１５は、第１の変換モード時は、チャネルの束ねを解くペイロード公開処理を行う。
ペイロード処理装置１５は、第２の変換モード時は、チャネルの束ねるペイロード隠蔽処理を行う。
ペイロード処理装置１５は、第２の変換モード時は、チャネルの束ねるペイロード隠蔽処理を行う。
インターフェース装置１６は、第１の変換モード時は、インターフェースおよびチャネル分解（ＡＰＩ分解）処理を行う。
インターフェース装置１６は、第２の変換モード時は、インターフェースおよびチャネル集約（ＡＰＩ集約）処理を行う。
インターフェース装置１６は、第２の変換モード時は、インターフェースおよびチャネル集約（ＡＰＩ集約）処理を行う。
プロセスリマッピング処理装置１７は、第１の変換モードまたは第２の変換モードに応じたプロセスリマッピング処理を行う。
図２および図３は、本実施形態に係るモデル変換プログラムの演算処理を示すフローチャートである。
図２（Ａ）はモデル変換プログラムの全体の処理概要を示し、図２（Ｂ）は入出力処理を示し、図２（Ｃ）はクラス解析処理を示している。
また、図３（Ａ）は具体的なモデル変換処理の概要を、図３（Ｂ）は第１の変換モード処理を、図３（Ｃ）は第２の変換モード処理を示している。
図２（Ａ）はモデル変換プログラムの全体の処理概要を示し、図２（Ｂ）は入出力処理を示し、図２（Ｃ）はクラス解析処理を示している。
また、図３（Ａ）は具体的なモデル変換処理の概要を、図３（Ｂ）は第１の変換モード処理を、図３（Ｃ）は第２の変換モード処理を示している。
本実施形態のモデル変換プログラムは、全体として図２（Ａ）に示すステップＳＴ１〜ＳＴ７の処理を含んで実行される。
ステップＳＴ１〜ＳＴ７のうち、ステップＳＴ３の入出力処理、ステップＳＴ５のモデル変換処理、ステップＳＴ６の入出力処理が主処理として実行される。
ステップＳＴ１〜ＳＴ７のうち、ステップＳＴ３の入出力処理、ステップＳＴ５のモデル変換処理、ステップＳＴ６の入出力処理が主処理として実行される。
ステップＳＴ３、ＳＴ６の入出力処理は、図２（Ｂ）に示すように実行される。
ステップＳＴ３１において、入出力処理装置１２を介して入力されるシミュレーション用インターフェースモデルおよび動作合成用インターフェースモデルの情報から中央処理装置１１によりシステムの構造が読み取られる。
次に、ステップＳＴ３２において、クラス解析装置１３にてクラス解析が行われる。
ステップＳＴ３３において、入出力処理装置１２を介してファイルの出力が行われる。
そして、ステップＳＴ３４において、ディスプレイ１９にファイルが表示される。
ステップＳＴ３１において、入出力処理装置１２を介して入力されるシミュレーション用インターフェースモデルおよび動作合成用インターフェースモデルの情報から中央処理装置１１によりシステムの構造が読み取られる。
次に、ステップＳＴ３２において、クラス解析装置１３にてクラス解析が行われる。
ステップＳＴ３３において、入出力処理装置１２を介してファイルの出力が行われる。
そして、ステップＳＴ３４において、ディスプレイ１９にファイルが表示される。
ステップＳＴ３２のクラス解析処理は、図２（Ｃ）に示すステップＳＴ３２１〜ＳＴ３２５の処理を含んで実行される。
ステップＳＴ３２１〜ＳＴ３２５のうち、ステップＳＴ３２２のプリプロセッサパーサ、ステップＳＴ３２３のＣ++パーサ、およびデータベース作成処理が主処理として実行される。
ステップＳＴ３２１〜ＳＴ３２５のうち、ステップＳＴ３２２のプリプロセッサパーサ、ステップＳＴ３２３のＣ++パーサ、およびデータベース作成処理が主処理として実行される。
ステップＳＴ５のモデル変換処理は、具体的には、図３（Ａ）〜（Ｃ）に示す処理を含んで実行される。
このモデル変換処理は、主として、中央処理装置１１、変換モード切替装置１４、ペイロード処理装置１５、インターフェース処理装置１６、およびプロセスリマッピング処理装置１７により実行される。
このモデル変換処理は、主として、中央処理装置１１、変換モード切替装置１４、ペイロード処理装置１５、インターフェース処理装置１６、およびプロセスリマッピング処理装置１７により実行される。
まず、全体として、図３（Ａ）に示すように、ステップＳＴ５１において、変換モードが第１の変換モードか第２の変換モードかが判定される。
そして、第１の変換モードのときはステップＳＴ５２の処理が実行され、第２の変換モードのときはステップＳＴ５３の処理が実行される。
そして、第１の変換モードのときはステップＳＴ５２の処理が実行され、第２の変換モードのときはステップＳＴ５３の処理が実行される。
ステップＳＴ５２の第１の変換モードの処理は、図３（Ｂ）に示すステップＳＴ５２１〜ＳＴ５２７の処理を含んで実行される。
ステップＳＴ５２１〜ＳＴ５２７のうち、ステップＳＴ５２１で階層チャネルの検索が開始される。
そして、ステップＳＴ５２３のペイロード公開処理、ステップＳＴ５２４のインターフェースおよびチャネル分解（ＡＰＩ分解）処理、およびステップＳＴ５２５のプロセスリマッピング処理が主処理として実行される。
ステップＳＴ５２１〜ＳＴ５２７のうち、ステップＳＴ５２１で階層チャネルの検索が開始される。
そして、ステップＳＴ５２３のペイロード公開処理、ステップＳＴ５２４のインターフェースおよびチャネル分解（ＡＰＩ分解）処理、およびステップＳＴ５２５のプロセスリマッピング処理が主処理として実行される。
ステップＳＴ５３の第２の変換モードの処理は、図３（Ｃ）に示すステップＳＴ５３１〜ＳＴ５３７の処理を含んで実行される。
ステップＳＴ５３１〜ＳＴ５３７のうち、ステップＳＴ５３１で集約チャネルの検索が開始される。
そして、ステップＳＴ５３３のペイロード隠蔽処理、ステップＳＴ５３４のインターフェースおよびチャネル集約（ＡＰＩ集約）処理、およびステップＳＴ５３５のプロセスリマッピング処理が主処理として実行される。
ステップＳＴ５３１〜ＳＴ５３７のうち、ステップＳＴ５３１で集約チャネルの検索が開始される。
そして、ステップＳＴ５３３のペイロード隠蔽処理、ステップＳＴ５３４のインターフェースおよびチャネル集約（ＡＰＩ集約）処理、およびステップＳＴ５３５のプロセスリマッピング処理が主処理として実行される。
＜２．第２の実施形態＞
図４は、本第２の実施形態に係るモデル変換装置の構成例を示す図である。
図４は、本第２の実施形態に係るモデル変換装置の構成例を示す図である。
図４のモデル変換装置１０Ａが図１のモデル変換装置１０と異なる点は、ＵＭＬ作図装置２１、コード生成装置２２を有していることにある。
そして、中央処理装置１１はＵＭＬ作図装置２１を介して変換モード切替装置１４と通信を行う。
その他の構成は図１のモデル変換装置１０と同様である。
そして、中央処理装置１１はＵＭＬ作図装置２１を介して変換モード切替装置１４と通信を行う。
その他の構成は図１のモデル変換装置１０と同様である。
なお、ＵＭＬ作図装置２１、コード生成装置２２の各処理はプログラムにより処理を実行可能である。
このモデル変換装置１０Ａは、後述する第２実施例に適用される。
このモデル変換装置１０Ａは、後述する第２実施例に適用される。
＜３．第３の実施形態＞
図５は、本第３の実施形態に係るモデル変換装置の構成例を示す図である。
図５は、本第３の実施形態に係るモデル変換装置の構成例を示す図である。
図５のモデル変換装置１０Ｂが図４のモデル変換装置１０Ａと異なる点は、中央処理装置１１はＵＭＬ作図装置２１を介さずに、変換モード切替装置１４と直接的に通信を行うことにある。
その他の構成は図４のモデル変換装置１０Ａと同様である。
その他の構成は図４のモデル変換装置１０Ａと同様である。
＜４．第４の実施形態＞
図６は、本第４の実施形態に係るモデル変換装置の構成例を示す図である。
図６は、本第４の実施形態に係るモデル変換装置の構成例を示す図である。
図６のモデル変換装置１０Ｃが図５のモデル変換装置１０Ｂと異なる点は、ＵＭＬ作図装置２１にＨＷ（ハードウェア）・ＳＷ（ソフトウェア）インターフェース回路生成装置２３が接続されていることにある。
その他の構成は図５のモデル変換装置１０Ｂと同様である。
ＨＷ・ＳＷインターフェース回路は、アドレスデコーダ、割り込みコントローラ、チップイネーブラー等の装置である。
その他の構成は図５のモデル変換装置１０Ｂと同様である。
ＨＷ・ＳＷインターフェース回路は、アドレスデコーダ、割り込みコントローラ、チップイネーブラー等の装置である。
なお、ＨＷ・ＳＷインターフェース回路生成装置２３の処理はプログラムにより処理を実行可能である。
以上、本実施形態に係るモデル変換装置１０の機能ブロックの構成例および機能について説明した。
次に、ＵＭＬコンポーネント図、クラス図等に関連付けて本実施形態に係るモデル変換処理をより具体的に説明する。
次に、ＵＭＬコンポーネント図、クラス図等に関連付けて本実施形態に係るモデル変換処理をより具体的に説明する。
＜５．モデル変換処理のより具体的処理例＞
図７は、ＳｙｓｔｅｍＣで記述したインターフェースモデルシステムのＵＭＬコンポーネント図である。
図７は、ＳｙｓｔｅｍＣで記述したインターフェースモデルシステムのＵＭＬコンポーネント図である。
このＵＭＬコンポーネントにおいて、ソースモジュールＳＭとデスティネーションモジュールＤＭとの間に階層チャネルＨＣＨが配置されている。
ソースモジュールＳＭのポートＰＴ１と階層チャネルＨＣＨのポートＰＴ２がインターフェースＩＦ１を介して情報の授受が可能に構成されている。
階層チャネルＨＣＨのポートＰＴ３とデスティネーションモジュールＤＭのポートＰＴ４がインターフェースＩＦ２を介して情報の授受が可能に構成されている。
インターフェースＩＦ１はプット関数ｐｕｔ（Ｔ）を含み、インターフェースＩＦ２はゲット関数ｇｅｔ（）を含む。プットは送信機能を含み、ゲットは受信機能を含む。
また、ペイロードＰＹＬはレディｒｄｙ、バリッドｖｌｄ、データｄａｔを含んで構成される。
ソースモジュールＳＭのポートＰＴ１と階層チャネルＨＣＨのポートＰＴ２がインターフェースＩＦ１を介して情報の授受が可能に構成されている。
階層チャネルＨＣＨのポートＰＴ３とデスティネーションモジュールＤＭのポートＰＴ４がインターフェースＩＦ２を介して情報の授受が可能に構成されている。
インターフェースＩＦ１はプット関数ｐｕｔ（Ｔ）を含み、インターフェースＩＦ２はゲット関数ｇｅｔ（）を含む。プットは送信機能を含み、ゲットは受信機能を含む。
また、ペイロードＰＹＬはレディｒｄｙ、バリッドｖｌｄ、データｄａｔを含んで構成される。
このように、ＳｙｓｔｅｍＣによるインターフェース記述には階層チャネルＨＣＨが使用される。
前述したように、階層チャネルＨＣＨとは、内部にプロセスＰＲＣを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、そのデータを転送するための通信に必要な信号をまとめたペイロードＰＹＬと呼ばれるデータクラスから構成される。
前述したように、階層チャネルＨＣＨとは、内部にプロセスＰＲＣを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、そのデータを転送するための通信に必要な信号をまとめたペイロードＰＹＬと呼ばれるデータクラスから構成される。
図８は、階層チャネルのクラス図である。
これに対して、図９は、モデル変換後の動作合成可能なインターフェースモデルシステムのＵＭＬコンポーネント図である。
また、図１０は、モデル変換後のインターフェース部分のクラス図である。
以下、図７〜図１０に関連付けて、本実施形態に係るモデル変換装置１０が相互変換が可能であることを証明する。
これに対して、図９は、モデル変換後の動作合成可能なインターフェースモデルシステムのＵＭＬコンポーネント図である。
また、図１０は、モデル変換後のインターフェース部分のクラス図である。
以下、図７〜図１０に関連付けて、本実施形態に係るモデル変換装置１０が相互変換が可能であることを証明する。
［相互変換が可能であることの証明］
相互変換が可能であることの証明には、クラスの等価、条件付き等価、および派生に代数定義を導入する。
相互変換が可能であることの証明には、クラスの等価、条件付き等価、および派生に代数定義を導入する。
［クラス定義］
クラスの定義は、基本的に以下の通りである。
クラスの定義は、基本的に以下の通りである。
［等価］
記法：class A = class B
意味：クラスＡとクラスＢは等価で、交換可能である。
記法：class A = class B
意味：クラスＡとクラスＢは等価で、交換可能である。
［条件付き等価］
記法：＄COND｛M｝classA =$COND(N)classB
意味：Ｍが真の場合のクラスＡとＮが真の場合のクラスＢは等価で、交換可能である。
記法：＄COND｛M｝classA =$COND(N)classB
意味：Ｍが真の場合のクラスＡとＮが真の場合のクラスＢは等価で、交換可能である。
［派生クラス］
記法：class B: classA
意味：クラスＢはクラスＡの派生クラスである。
記法：class B: classA
意味：クラスＢはクラスＡの派生クラスである。
［メンバ関数］
記法：classA::Func
意味：クラスＡのメンバ関数Ｆｕｎｃである。
記法：classA::Func
意味：クラスＡのメンバ関数Ｆｕｎｃである。
また、ＳｙｓｔｅｍＣ前提からも代数定義を導入する。
［ＳｙｓｔｅｍＣ前提からの定義］
sc_channel = sc_module
意味：sc_channelは sc_moduleと等価である。
sc_channel = sc_module
意味：sc_channelは sc_moduleと等価である。
∀IF: sc_interface
意味：すべてのインターフェースクラスは、sc_intefaceクラスの派生クラスである。
意味：すべてのインターフェースクラスは、sc_intefaceクラスの派生クラスである。
∀Port:sc_port<IF>
意味：すべてのポートクラスは、インターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスである。
意味：すべてのポートクラスは、インターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスである。
∀CH:sc_channel, Port
意味：すべてのチャネルクラスは、sc_channelとポートクラスの派生クラスである。
意味：すべてのチャネルクラスは、sc_channelとポートクラスの派生クラスである。
Port $BIND CH
意味：PortポートクラスはCHチャネルクラスをバインドする。
意味：PortポートクラスはCHチャネルクラスをバインドする。
$COND{M}
意味：Ｍという条件である。
意味：Ｍという条件である。
Port $BIND CH ∧ ∃1Func⇒ $COND{Port:IF}Port::Func = $COND{Port:sc_port<IF>∧CH:IF}CH::Func
意味：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば次の意味を持つ。
すなわち、あるポートがあるポートインターフェースの派生クラスである場合のポートクラスのメンバ関数Funcと、あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスである。かつ、あるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数Funcは等価である。
意味：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば次の意味を持つ。
すなわち、あるポートがあるポートインターフェースの派生クラスである場合のポートクラスのメンバ関数Funcと、あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスである。かつ、あるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数Funcは等価である。
例：
$COND{Port : put_if} Port::put() = $COND{Port : sc_port<put_if> ∧ CH : put_if}CH::put()}
$COND{Port : get_if}Port::get() = #COND{Port : sc_port<get_if> ∧ CH : get_if}CH::get()}
＄COND{Port $BIND CH} = $COND{∀{Port::PrimitivePort∈Port $BIND CH::PrimitiveCH∈CH}}
意味：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価である。
$COND{Port : put_if} Port::put() = $COND{Port : sc_port<put_if> ∧ CH : put_if}CH::put()}
$COND{Port : get_if}Port::get() = #COND{Port : sc_port<get_if> ∧ CH : get_if}CH::get()}
＄COND{Port $BIND CH} = $COND{∀{Port::PrimitivePort∈Port $BIND CH::PrimitiveCH∈CH}}
意味：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価である。
［定式化］
図７および図８から階層チャネルの接続を定式化すると下記５式（１）〜（５）を得る。
図７および図８から階層チャネルの接続を定式化すると下記５式（１）〜（５）を得る。
（１）wait_hs : sc_channel, put_if, get_if
意味：wait_hsクラスはsc_channel, put_if, get_ifクラスの派生クラスである。
意味：wait_hsクラスはsc_channel, put_if, get_ifクラスの派生クラスである。
（２）wait_out : sc_port<put_if>
意味：wait_outクラスはput_ifクラスをテンプレートパラメータとするsc_portの派生クラスである。
意味：wait_outクラスはput_ifクラスをテンプレートパラメータとするsc_portの派生クラスである。
（３）wait_in : sc_port<get_if>
意味：wait_inクラスはget_ifクラスをテンプレートパラメータとするsc_portの派生クラスである。
意味：wait_inクラスはget_ifクラスをテンプレートパラメータとするsc_portの派生クラスである。
（４）wait_out $BIND wait_hs
意味：wait_outクラスはwait_hsクラスをバインドする。
意味：wait_outクラスはwait_hsクラスをバインドする。
（５）wait_in $BIND wait_hs
意味：wait_inクラスはwait_hsクラスをバインドする。
意味：wait_inクラスはwait_hsクラスをバインドする。
図８および図１０からモデル変換後の接続を定式化すると下記９式＜１＞〜＜９＞を得る。
＜１＞wait_hs : sc_channel
意味：wait_hsはsc_channelの派生クラスである。
意味：wait_hsはsc_channelの派生クラスである。
＜２＞wait_out : sc_module, put_if
意味：wait_outクラスはsc_module, put_ifクラスの派生クラスである。
意味：wait_outクラスはsc_module, put_ifクラスの派生クラスである。
＜３＞wait_in : sc_module, get_if
意味：wait_inクラスはsc_module, get_ifクラスの派生クラスである。
意味：wait_inクラスはsc_module, get_ifクラスの派生クラスである。
＜４＞wait_out::vld $BIND wait_hs::vld
意味：wait_out::vldはwait_hs::vldをバインドする。
意味：wait_out::vldはwait_hs::vldをバインドする。
＜５＞wait_out::rdy $BIND wait_hs::rdy
意味：wait_out::rdyはwait_hs::rdyをバインドする。
意味：wait_out::rdyはwait_hs::rdyをバインドする。
＜６＞wait_out::dat $BIND wait_hs::dat
意味：wait_out::datはwait_hs::datをバインドする。
意味：wait_out::datはwait_hs::datをバインドする。
＜７＞wait_in::vld $BIND wait_hs::vld
意味：wait_in::vldはwait_hs::vldをバインドする。
意味：wait_in::vldはwait_hs::vldをバインドする。
＜８＞wait_in::rdy $BIND wait_hs::rdy
意味：wait_in::vldはwait_hs::vldをバインドする。
意味：wait_in::vldはwait_hs::vldをバインドする。
＜９＞wait_in::dat $BIND wait_hs::dat
意味：wait_in::vldはwait_hs::vldをバインドする。
意味：wait_in::vldはwait_hs::vldをバインドする。
［図８に示された階層チャネルのクラス図と図１０に示されたモデル変換後のインターフェースクラス図が等価であることの証明］
図８に示された階層チャネルのクラス図と図１０に示されたモデル変換後のインターフェースクラス図が等価であることの証明は次の通りである。
図８に示された階層チャネルのクラス図と図１０に示されたモデル変換後のインターフェースクラス図が等価であることの証明は次の通りである。
［バインド条件］
モデル変換後の接続式から次の関係が得られる。
モデル変換後の接続式から次の関係が得られる。
wait_out::vld $BIND wait_hs::vld
wait_out::rdy $BIND wait_hs::rdy
wait_out::dat $BIND wait_hs::dat
wait_in::vld $BIND wait_hs::vld
wait_in::rdy $BIND wait_hs::rdy
wait_in::dat $BIND wait_hs::dat
wait_out::rdy $BIND wait_hs::rdy
wait_out::dat $BIND wait_hs::dat
wait_in::vld $BIND wait_hs::vld
wait_in::rdy $BIND wait_hs::rdy
wait_in::dat $BIND wait_hs::dat
定義＄COND{Port $BIND CH} = $COND{∀{Port::PrimitivePort∈Port $BIND CH::PrimitiveCH∈CH}} から次の関係が得られる。
wait_out $BIND wait_hs
wait_in $BIND wait_hs
wait_in $BIND wait_hs
これは、階層チャネル接続のバインド条件に等しい。
よって、双方のバインド条件は等価である。
よって、双方のバインド条件は等価である。
モデル変換後のクラス代数より次に関係が得られる。
wait_hs : sc_channel
wait_out : sc_module, put_if
wait_in : sc_module, get_if
wait_out : sc_module, put_if
wait_in : sc_module, get_if
バインド条件が等価∧put()およびget()はそれぞれ唯一であることから、次の関係が得られる。
定義PORT $BIND CH ∧ ∃1FUNC⇒ $COND{PORT:IF}∧PORT::FUNC = $COND{PORT:sc_port<IF>∧CH:IF}∧CH::FUNC
にPORT= wait_out, FUNC=put(), IF=put_if, CH=wait_hsを適用し
wait_out $BIND wait_hs ∧∃1put() ⇒
$COND{wait_out:put_if}∧wait_out:put()=$COND{wait_out:sc_port<put_if>∧wait_hs:put_if}∧wait_hs::put()
にPORT= wait_out, FUNC=put(), IF=put_if, CH=wait_hsを適用し
wait_out $BIND wait_hs ∧∃1put() ⇒
$COND{wait_out:put_if}∧wait_out:put()=$COND{wait_out:sc_port<put_if>∧wait_hs:put_if}∧wait_hs::put()
すなわち、次の関係が得られる。
wait_out:sc_port<put_if>
wait_hs:put_if}
wait_out:sc_port<put_if>
wait_hs:put_if}
同様に、次の関係が得られる。
wait_in:sc_port<get_if>
wait_hs:get_if}
wait_in:sc_port<get_if>
wait_hs:get_if}
まとめると次のようになる。
wait_out:sc_port<put_if>
wait_in:sc_port<get_if>
wait_hs:get_if}、put_if}
これは、階層チャネルのクラス代数と等価である。
wait_out:sc_port<put_if>
wait_in:sc_port<get_if>
wait_hs:get_if}、put_if}
これは、階層チャネルのクラス代数と等価である。
＜６．第１実施例＞
図１１（Ａ）〜（Ｃ）は、第１実施例を説明するための図である。
図１１（Ａ）〜（Ｃ）は、第１実施例を説明するための図である。
図１１（Ａ）が、階層チャネル接続が入力システムのＵＭＬコンポーネント図である。 システムのＳｙｓｔｅｍＣ記述を本装置に入力すると、図２および図３の処理フローに従って、クラスの派生クラスである、図１１（Ｂ）に示すようなモデルに変形される。
モジュール内プロセスのインライニングを進めると、図１１（Ｃ）に示すようなモデルに変換されるが、sc_methodから呼び出される場合にはインライニングできない。
モジュール内プロセスのインライニングを進めると、図１１（Ｃ）に示すようなモデルに変換されるが、sc_methodから呼び出される場合にはインライニングできない。
第１実施例はＣ++言語を解析し、継承関係、メンバ関数の場所を組み替えるインターフェースおよびＡＰＩ分解（チャネル分解）あるいは集約（チャネル集約）とプロセスリマッピング技術を使用して、モデル変換後のＣ++言語クラスを新たに出力する。
＜７．第２実施例＞
図１２は、第２実施例を説明するための図である。
図１２は、第２実施例を説明するための図である。
本モデル変換装置はシステム構造の変換装置として実施すると解析対象を抽象化することができる。
すなわち、図１１で示したＵＭＬコンポーネントダイアグラムを直接書き直すことにより実施する。
本第２実施例は前述の第１実施例と比較し遥かに高速にモデルを構築することができる。
具体的な操作手順は次のとおりである。
すなわち、図１１で示したＵＭＬコンポーネントダイアグラムを直接書き直すことにより実施する。
本第２実施例は前述の第１実施例と比較し遥かに高速にモデルを構築することができる。
具体的な操作手順は次のとおりである。
［チャネル分解手順］
チャネル分解手順は次の通りである。ディスプレイ上でマウス等を用いて行う。
階層チャネルを選択する。
右クリックによりドロップダウンメニューを開く。
分解を選択する。
この操作でＵＭＬドローツールがチャネルをチャネル内部のパラメータ群に分解し、各々ソース・デスティネーションモジュールにポートを生成する
チャネル分解手順は次の通りである。ディスプレイ上でマウス等を用いて行う。
階層チャネルを選択する。
右クリックによりドロップダウンメニューを開く。
分解を選択する。
この操作でＵＭＬドローツールがチャネルをチャネル内部のパラメータ群に分解し、各々ソース・デスティネーションモジュールにポートを生成する
［チャネル集約手順］
集約するチャネル群の選択
右クリックによりドロップダウンメニューを開く
集約を選択
集約するチャネル群の選択
右クリックによりドロップダウンメニューを開く
集約を選択
この操作で、ＵＭＬドローツールが階層チャネルを生成する。本階層チャネルは集約されたポートと集約された内部パラメータを内包する。
部分的な分解と集約を使用することもある。
部分的な分解と集約を使用することもある。
図１３は、ハードウェア側のみチャネル分解を行った設計事例を示す図である。
［チャネル・ポート（部分）分解手順］
チャネル・ポート（部分）分解手順は次の通りである。
階層チャネルのポートを選択する。
右クリックによりドロップダウンメニューを開く。
分解を選択する。
チャネル・ポート（部分）分解手順は次の通りである。
階層チャネルのポートを選択する。
右クリックによりドロップダウンメニューを開く。
分解を選択する。
この操作でＵＭＬドローツールがチャネルの選択されたポートのみチャネル内部のパラメータ群に分解される。接続されたモジュールとチャネル間に新たにポートが生成される。
［チャネル・ポート集約手順］
チャネル・ポート集約手順は次の通りである。
階層チャネルに接続したいモジュールのポート群を選択する。
右クリックによりドロップダウンメニューを開く。
集約を選択。
チャネル・ポート集約手順は次の通りである。
階層チャネルに接続したいモジュールのポート群を選択する。
右クリックによりドロップダウンメニューを開く。
集約を選択。
この操作で、ＵＭＬドローツールが階層チャネルを生成する。本階層チャネルは集約されたポートと集約されたパラメータを内包する。ただし、選択されなかったポート側は集約されない。
＜８．第３実施例＞
次に、第３実施例としてクラス簡略化について説明する。
［クラス簡略化］
第３実施例では、クラスの再利用・バージョンアップを繰り返すと冗長な実行されない記述部分が発生する可能性がある。この整理にクラス変換を使用する。
次に、第３実施例としてクラス簡略化について説明する。
［クラス簡略化］
第３実施例では、クラスの再利用・バージョンアップを繰り返すと冗長な実行されない記述部分が発生する可能性がある。この整理にクラス変換を使用する。
＜９．第４実施例＞
第４実施例としてクラス再構築について説明する。
［クラス再構築］
第４実施例では、クラスの派生クラスでインプリしたものを基底クラスに移動させて整理したり、逆に基底クラスでインプリしていたものを派生クラスに移動させて基底クラスの責務を整理したりすることができる。
第４実施例としてクラス再構築について説明する。
［クラス再構築］
第４実施例では、クラスの派生クラスでインプリしたものを基底クラスに移動させて整理したり、逆に基底クラスでインプリしていたものを派生クラスに移動させて基底クラスの責務を整理したりすることができる。
＜１０．第５実施例＞
第５実施例としてクラス等価性検証について説明する。
［クラス等価性検証］
等価なクラスには構造的な変換パターンがある。この構造的変換パターンはプログラム言語を見てもその意味は良くわからないが、ＵＭＬダイアグラムで見ると物理的意味が理解できてくる。
たとえばＣ++の純粋仮想関数、オーバーライド、派生クラスに関しては言語的意味と同時にそれぞれ次のような物理的意味が存在する。
すなわち、それぞれ「派生クラスで必ずインスタンシエーションが必要」、「基底クラスのメソッドは無効になり派生クラスのメソッドが実行される」、「基底クラスのメソッドにアクセスできる可能性がある」との物理的意味が存在する。
各変換を図示することにより等価な構造的変換パターンを準備し、等価な構造的変換パターンのみを変換に利用すれば返還後のクラスが等価であることを保証できる。
第５実施例としてクラス等価性検証について説明する。
［クラス等価性検証］
等価なクラスには構造的な変換パターンがある。この構造的変換パターンはプログラム言語を見てもその意味は良くわからないが、ＵＭＬダイアグラムで見ると物理的意味が理解できてくる。
たとえばＣ++の純粋仮想関数、オーバーライド、派生クラスに関しては言語的意味と同時にそれぞれ次のような物理的意味が存在する。
すなわち、それぞれ「派生クラスで必ずインスタンシエーションが必要」、「基底クラスのメソッドは無効になり派生クラスのメソッドが実行される」、「基底クラスのメソッドにアクセスできる可能性がある」との物理的意味が存在する。
各変換を図示することにより等価な構造的変換パターンを準備し、等価な構造的変換パターンのみを変換に利用すれば返還後のクラスが等価であることを保証できる。
［等価変換に使用するルール例］：
次に、等価変換に使用するルール例を示す。
・外部に公開されたメソッドの種類
・publicなメソッド
・friend function：関数毎の公開
・friend class：クラス毎の公開
・inheritanceによるderived classからのbase class内protectedメンバアクセス
・virtualによるbase classからのderived class内メンバアクセス
上記のルールをすべて定式化し、定理を整理する。
次に、等価変換に使用するルール例を示す。
・外部に公開されたメソッドの種類
・publicなメソッド
・friend function：関数毎の公開
・friend class：クラス毎の公開
・inheritanceによるderived classからのbase class内protectedメンバアクセス
・virtualによるbase classからのderived class内メンバアクセス
上記のルールをすべて定式化し、定理を整理する。
以上説明したように、本実施形態によれば、ＳｙｓｔｅｍＣあるいはＵＭＬで記述したインターフェースモデルと動作合成可能なインターフェースモデルとを等価性を保ったまま相互に変形することが可能となり、効果的なハードウェア開発が可能となる。
なお、本技術は以下のような構成をとることができる。
（１）固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形し、変形後の代数表現の双方が一致すれば（数学的に）モデルに等価性があるとして、モデルの相互変換を行う処理部を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルが使用され、
上記処理部は、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
モデル変換装置。
（２）上記処理部は、
シミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねを解くペイロード公開、インターフェースおよびチャネル分解、並びに、プロセスリマッピングを行う
上記（１）記載のモデル変換装置。
（３）上記処理部は、
動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねるペイロード隠蔽、インターフェースおよびチャネル集約、並びに、プロセスリマッピングを行う
上記（１）または（２）記載のモデル変換装置。
（４）上記代数定義として、次の４つの代数的意味定義ｅ，ｆ，ｇ，ｈを持つ
ｅ：クラスが交換可能であることを意味するクラス等価、
ｆ：クラスが条件付きで交換可能であることを意味する条件付きクラス等価、
ｇ：クラスがあるクラスの派生であることを意味する派生クラス、
ｈ：ある関数があるクラスに属する関数であることを意味するメンバ関数、
上記（１）から（３）のいずれか一に記載のモデル変換装置。
（５）上記代数定義として、ＳｙｓｔｅｍＣ言語を設計記述言語とする場合には、次の７つの代数的意味定義ｉ，ｊ，ｋ，ｌ，ｍ，ｎ，ｏを持つ
ｉ：sc_channelとsc_moduleがクラス等価であること、
ｊ：すべてのインターフェースクラスはsc_interfaceクラスの派生クラスであること、
ｋ：すべてのポートクラスはインターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスであること、
ｌ：ポートクラスがチャネルクラスをバインドすること、
ｍ：Ｍという条件、
ｎ：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば
ｎ１：あるポートクラスがあるインターフェースクラスの派生クラスである場合のポートクラスのメンバ関数と、
ｎ２：あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスであり、かつあるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数とは等価であること、
ｏ：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価
上記（１）から（３）のいずれか一に記載のモデル変換装置。
（６）固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する変形ステップと、
変形後の代数表現の双方が一致するか否かを判定する判定ステップと、
変形後の代数表現の双方が一致すれば（数学的に）モデルに等価性があるとして、モデルの相互変換を行う変換ステップと、を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルを使用し、
上記変換ステップにおいては、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
モデル変換方法。
（７）上記変換ステップにおいて、
シミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねを解くペイロード公開、インターフェースおよびチャネル分解、並びに、プロセスリマッピングを行う
上記（６）記載のモデル変換方法。
（８）上記変換ステップにおいて、
動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねるペイロード隠蔽、インターフェースおよびチャネル集約、並びに、プロセスリマッピングを行う
上記（６）または（７）記載のモデル変換方法。
（９）上記代数定義として、次の４つの代数的意味定義ｅ，ｆ，ｇ，ｈを持つ
ｅ：クラスが交換可能であることを意味するクラス等価、
ｆ：クラスが条件付きで交換可能であることを意味する条件付きクラス等価、
ｇ：クラスがあるクラスの派生であることを意味する派生クラス、
ｈ：ある関数があるクラスに属する関数であることを意味するメンバ関数、
上記（６）から（１０）のいずれか一に記載のモデル変換方法。
（１０）上記代数定義として、ＳｙｓｔｅｍＣ言語を設計記述言語とする場合には、次の４つの代数的意味定義ｉ，ｊ，ｋ，ｌ，ｍ，ｎ，ｏを持つ
ｉ：sc_channelとsc_moduleがクラス等価であること、
ｊ：すべてのインターフェースクラスはsc_interfaceクラスの派生クラスであること、
ｋ：すべてのポートクラスはインターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスであること、
ｌ：ポートクラスがチャネルクラスをバインドすること、
ｍ：Ｍという条件、
ｎ：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば
ｎ１：あるポートクラスがあるインターフェースクラスの派生クラスである場合のポートクラスのメンバ関数と、
ｎ２：あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスであり、かつあるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数とは等価であること、
ｏ：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価
上記（６）から（８）のいずれか一に記載のモデル変換方法。
（１１）固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する変形処理と、
変形後の代数表現の双方が一致するか否かを判定する判定処理と、
変形後の代数表現の双方が一致すれば（数学的に）モデルに等価性があるとして、モデルの相互変換を行う変換処理と、を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルを使用し、
上記変換処理においては、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
を含むモデル変換処理をコンピュータに実行させるプログラム。
（１）固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形し、変形後の代数表現の双方が一致すれば（数学的に）モデルに等価性があるとして、モデルの相互変換を行う処理部を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルが使用され、
上記処理部は、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
モデル変換装置。
（２）上記処理部は、
シミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねを解くペイロード公開、インターフェースおよびチャネル分解、並びに、プロセスリマッピングを行う
上記（１）記載のモデル変換装置。
（３）上記処理部は、
動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねるペイロード隠蔽、インターフェースおよびチャネル集約、並びに、プロセスリマッピングを行う
上記（１）または（２）記載のモデル変換装置。
（４）上記代数定義として、次の４つの代数的意味定義ｅ，ｆ，ｇ，ｈを持つ
ｅ：クラスが交換可能であることを意味するクラス等価、
ｆ：クラスが条件付きで交換可能であることを意味する条件付きクラス等価、
ｇ：クラスがあるクラスの派生であることを意味する派生クラス、
ｈ：ある関数があるクラスに属する関数であることを意味するメンバ関数、
上記（１）から（３）のいずれか一に記載のモデル変換装置。
（５）上記代数定義として、ＳｙｓｔｅｍＣ言語を設計記述言語とする場合には、次の７つの代数的意味定義ｉ，ｊ，ｋ，ｌ，ｍ，ｎ，ｏを持つ
ｉ：sc_channelとsc_moduleがクラス等価であること、
ｊ：すべてのインターフェースクラスはsc_interfaceクラスの派生クラスであること、
ｋ：すべてのポートクラスはインターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスであること、
ｌ：ポートクラスがチャネルクラスをバインドすること、
ｍ：Ｍという条件、
ｎ：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば
ｎ１：あるポートクラスがあるインターフェースクラスの派生クラスである場合のポートクラスのメンバ関数と、
ｎ２：あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスであり、かつあるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数とは等価であること、
ｏ：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価
上記（１）から（３）のいずれか一に記載のモデル変換装置。
（６）固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する変形ステップと、
変形後の代数表現の双方が一致するか否かを判定する判定ステップと、
変形後の代数表現の双方が一致すれば（数学的に）モデルに等価性があるとして、モデルの相互変換を行う変換ステップと、を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルを使用し、
上記変換ステップにおいては、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
モデル変換方法。
（７）上記変換ステップにおいて、
シミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねを解くペイロード公開、インターフェースおよびチャネル分解、並びに、プロセスリマッピングを行う
上記（６）記載のモデル変換方法。
（８）上記変換ステップにおいて、
動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねるペイロード隠蔽、インターフェースおよびチャネル集約、並びに、プロセスリマッピングを行う
上記（６）または（７）記載のモデル変換方法。
（９）上記代数定義として、次の４つの代数的意味定義ｅ，ｆ，ｇ，ｈを持つ
ｅ：クラスが交換可能であることを意味するクラス等価、
ｆ：クラスが条件付きで交換可能であることを意味する条件付きクラス等価、
ｇ：クラスがあるクラスの派生であることを意味する派生クラス、
ｈ：ある関数があるクラスに属する関数であることを意味するメンバ関数、
上記（６）から（１０）のいずれか一に記載のモデル変換方法。
（１０）上記代数定義として、ＳｙｓｔｅｍＣ言語を設計記述言語とする場合には、次の４つの代数的意味定義ｉ，ｊ，ｋ，ｌ，ｍ，ｎ，ｏを持つ
ｉ：sc_channelとsc_moduleがクラス等価であること、
ｊ：すべてのインターフェースクラスはsc_interfaceクラスの派生クラスであること、
ｋ：すべてのポートクラスはインターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスであること、
ｌ：ポートクラスがチャネルクラスをバインドすること、
ｍ：Ｍという条件、
ｎ：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば
ｎ１：あるポートクラスがあるインターフェースクラスの派生クラスである場合のポートクラスのメンバ関数と、
ｎ２：あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスであり、かつあるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数とは等価であること、
ｏ：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価
上記（６）から（８）のいずれか一に記載のモデル変換方法。
（１１）固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する変形処理と、
変形後の代数表現の双方が一致するか否かを判定する判定処理と、
変形後の代数表現の双方が一致すれば（数学的に）モデルに等価性があるとして、モデルの相互変換を行う変換処理と、を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルを使用し、
上記変換処理においては、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
を含むモデル変換処理をコンピュータに実行させるプログラム。
１０，１０Ａ〜１０Ｃ・・・モデル変換装置、１１・・・中央処理装置、１２・・・入出力処理装置、１３・・・クラス解析装置、１４・・・変換モード切替装置、１５・・・ペイロード処理装置、１６・・・インターフェース装置、１７・・・プロセスリマッピング処理装置、１８・・・キーボード、１９・・・ディスプレイ、２０・・・外部記憶装置、２１・・・ＵＭＬ作図装置、２２・・・コード生成装置、２３・・・ＨＷ・ＳＷインターフェース回路生成装置、ＨＣＨ・・・階層チャネル、ＳＭ・・・ソースモジュール、ＤＭ，ＤＭ−Ａ，ＭＤ−Ｂ，ＤＭ−Ｃ・・・デスティネーションモジュール、ＰＴ・・・ポート、ＩＦ・・・インターフェース、ＰＲＣ・・・プロセス、ＰＹＬ・・・ペイロード。
Claims (11)
- 固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形し、変形後の代数表現の双方が一致すればモデルに等価性があるとして、モデルの相互変換を行う処理部を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルが使用され、
上記処理部は、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
モデル変換装置。 - 上記処理部は、
シミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねを解くペイロード公開、インターフェースおよびチャネル分解、並びに、プロセスリマッピングを行う
請求項１記載のモデル変換装置。 - 上記処理部は、
動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねるペイロード隠蔽、インターフェースおよびチャネル集約、並びに、プロセスリマッピングを行う
請求項１記載のモデル変換装置。 - 上記代数定義として、次の４つの代数的意味定義ｅ，ｆ，ｇ，ｈを持つ
ｅ：クラスが交換可能であることを意味するクラス等価、
ｆ：クラスが条件付きで交換可能であることを意味する条件付きクラス等価、
ｇ：クラスがあるクラスの派生であることを意味する派生クラス、
ｈ：ある関数があるクラスに属する関数であることを意味するメンバ関数、
請求項１記載のモデル変換装置。 - 上記代数定義として、ＳｙｓｔｅｍＣ言語を設計記述言語とする場合には、次の７つの代数的意味定義ｉ，ｊ，ｋ，ｌ，ｍ，ｎ，ｏを持つ
ｉ：sc_channelとsc_moduleがクラス等価であること、
ｊ：すべてのインターフェースクラスはsc_interfaceクラスの派生クラスであること、
ｋ：すべてのポートクラスはインターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスであること、
ｌ：ポートクラスがチャネルクラスをバインドすること、
ｍ：Ｍという条件、
ｎ：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば
ｎ１：あるポートクラスがあるインターフェースクラスの派生クラスである場合のポートクラスのメンバ関数と、
ｎ２：あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスであり、かつあるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数とは等価であること、
ｏ：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価
請求項１記載のモデル変換装置。 - 固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する変形ステップと、
変形後の代数表現の双方が一致するか否かを判定する判定ステップと、
変形後の代数表現の双方が一致すればモデルに等価性があるとして、モデルの相互変換を行う変換ステップと、を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルを使用し、
上記変換ステップにおいては、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
モデル変換方法。 - 上記変換ステップにおいて、
シミュレーション用インターフェースモデルを動作合成用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねを解くペイロード公開、インターフェースおよびチャネル分解、並びに、プロセスリマッピングを行う
請求項６記載のモデル変換方法。 - 上記変換ステップにおいて、
動作合成用インターフェースモデルをシミュレーション用インターフェースモデルに変換する変換モードの際には、
チャネルの束ねるペイロード隠蔽、インターフェースおよびチャネル集約、並びに、プロセスリマッピングを行う
請求項６記載のモデル変換方法。 - 上記代数定義として、次の４つの代数的意味定義ｅ，ｆ，ｇ，ｈを持つ
ｅ：クラスが交換可能であることを意味するクラス等価、
ｆ：クラスが条件付きで交換可能であることを意味する条件付きクラス等価、
ｇ：クラスがあるクラスの派生であることを意味する派生クラス、
ｈ：ある関数があるクラスに属する関数であることを意味するメンバ関数、
請求項６記載のモデル変換方法。 - 上記代数定義として、ＳｙｓｔｅｍＣ言語を設計記述言語とする場合には、次の４つの代数的意味定義ｉ，ｊ，ｋ，ｌ，ｍ，ｎ，ｏを持つ
ｉ：sc_channelとsc_moduleがクラス等価であること、
ｊ：すべてのインターフェースクラスはsc_interfaceクラスの派生クラスであること、
ｋ：すべてのポートクラスはインターフェースクラスをテンプレートパラメータとするsc_portクラスの派生クラスであること、
ｌ：ポートクラスがチャネルクラスをバインドすること、
ｍ：Ｍという条件、
ｎ：あるポートクラスがあるチャネルクラスをバインドし、かつある関数が唯一存在するならば
ｎ１：あるポートクラスがあるインターフェースクラスの派生クラスである場合のポートクラスのメンバ関数と、
ｎ２：あるポートクラスがあるインターフェースクラスをテンプレートパラメータとするsc_portの派生クラスであり、かつあるチャネルがあるインターフェースクラスの派生クラスである場合のチャネルクラスのメンバ関数とは等価であること、
ｏ：あるポートクラスがあるチャネルクラスをバインドする条件は、ポートクラスに属するすべてのプリミティブポートをチャネルに属するすべてのプリミティブチャネルにバインドする条件と等価
請求項６記載のモデル変換方法。 - 固定された記述スタイルのシミュレーション用インターフェースモデルおよび固定された記述スタイルの動作合成用インターフェースモデルの各代数表現を変形する変形処理と、
変形後の代数表現の双方が一致するか否かを判定する判定処理と、
変形後の代数表現の双方が一致すれば（数学的に）モデルに等価性があるとして、モデルの相互変換を行う変換処理と、を有し、
インターフェース記述には、内部にプロセスを持つことが可能なチャネルクラスであり、転送の対象であるデータそのものと、当該データを転送するための通信に必要な信号をまとめたペイロードと呼ばれるデータクラスから形成される階層チャネルを使用し、
上記変換処理においては、
代数的に等価性を保つ、以下の３つの操作ａ，ｂ，ｃによる階層チャネルおよび集約チャネルモデル変換の相互等価変換を行う
ａ：ペイロード公開、およびペイロード隠蔽操作の相互等価変換、
ｂ：インターフェースおよびチャネル分解、およびインターフェースおよびチャネル集約、
ｃ：プロセスリマッピング操作、
を含むモデル変換処理をコンピュータに実行させるプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011183827A JP2013045350A (ja) | 2011-08-25 | 2011-08-25 | モデル変換装置、モデル変換方法、およびプログラム |
| US13/590,823 US20130054205A1 (en) | 2011-08-25 | 2012-08-21 | Model transforming device, model transforming method, and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011183827A JP2013045350A (ja) | 2011-08-25 | 2011-08-25 | モデル変換装置、モデル変換方法、およびプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2013045350A true JP2013045350A (ja) | 2013-03-04 |
Family
ID=47744873
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2011183827A Withdrawn JP2013045350A (ja) | 2011-08-25 | 2011-08-25 | モデル変換装置、モデル変換方法、およびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20130054205A1 (ja) |
| JP (1) | JP2013045350A (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11036475B2 (en) * | 2017-10-16 | 2021-06-15 | Tata Consultancy Services Limited | System and method for generation of model descriptor of a plurality of specifications |
| CN110703213B (zh) * | 2019-10-09 | 2021-12-21 | 中国舰船研究设计中心 | 一种雷达干扰环境等效物理模拟方法及装置 |
-
2011
- 2011-08-25 JP JP2011183827A patent/JP2013045350A/ja not_active Withdrawn
-
2012
- 2012-08-21 US US13/590,823 patent/US20130054205A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20130054205A1 (en) | 2013-02-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Nordstrom et al. | Metamodeling-rapid design and evolution of domain-specific modeling environments | |
| Jin et al. | Compiling onnx neural network models using mlir | |
| Broman et al. | Determinate composition of FMUs for co-simulation | |
| CN107341294B (zh) | 基于Modelica语言的航天器信息系统建模仿真方法 | |
| Sevegnani et al. | BigraphER: rewriting and analysis engine for bigraphs | |
| US7139686B1 (en) | Report generator for a mathematical computing environment | |
| Anjorin et al. | Emoflon: leveraging EMF and professional CASE tools. | |
| US20140040855A1 (en) | Optimization of a Data Flow Program Based on Access Pattern Information | |
| US20170068751A1 (en) | Manifold system and synthesis of a manifold system from input models | |
| Fischbach et al. | Semantic entity-component state management techniques to enhance software quality for multimodal VR-systems | |
| Konur et al. | kPWorkbench: A software suit for membrane systems | |
| Sangiovanni-Vincentelli et al. | Metamodeling: An emerging representation paradigm for system-level design | |
| Lehner et al. | Towards a reference architecture for leveraging model repositories for digital twins | |
| CN111176658B (zh) | 基于元对象机制的AADL到Simulink模型自动转换方法 | |
| JP2013045350A (ja) | モデル変換装置、モデル変換方法、およびプログラム | |
| US9378562B1 (en) | Management of variants in a graphical modeling environment | |
| Lu et al. | Bigraph specification of software architecture and evolution analysis in mobile computing environment | |
| Bondé et al. | Traceability and interoperability at different levels of abstraction in model-driven engineering | |
| Davis | Model integrated computing: A framework for creating domain specific design environments | |
| Zhao | Towards an architecture description language for hybrid quantum-classical systems | |
| Sheng et al. | The micro-service architecture design research of financial trading system based on domain engineering | |
| Mabrok et al. | Mathematical framework for recursive model-based system design | |
| Khan et al. | From y-chart to seamless integration of application design and performance simulation | |
| White et al. | Domain-Specific Intelligence Frameworks for Assisting Modelers in Combinatorically Challenging Domains | |
| Hatledal et al. | Co-simulation Mechanism as Digital Twins Platform |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20141104 |