近似的モデリングメカニズムについての考察

全文

(1)Vol.2013-SE-181 No.10 2013/7/18. 情報処理学会研究報告 IPSJ SIG Technical Report. 近似的モデリングメカニズムについての考察岸知二†1 モデルベース開発など、ソフトウェア開発においてモデリングの役割が重要性を増しているが、モデルの規模や複雑さが増す一方で、ビジネスや技術の環境の変化が激しい状況で、利用するモデル間の整合性を常に保つのは困難なことも多い。我々は常に完全な整合性を求めず、一定の不整合を許容した近似的モデリングアプローチの検討をしている。本稿では整合性議論においてモデリングアーキテクチャの重要性を指摘するとともに、近似的なモデリングを支援するモデリングメカニズムについて考察する。. On Approximation Modeling Mechanism TOMOJI KISHI†1 Advanced software development techniques such as model based development use complementary models that are expected to be consistent. However it becomes difficult to maintain consistencies among large and complex models in recent rapid changing business and technical environment. In order to improve such situation, we are examining an approximation modeling approach in which we allow some inconsistencies among models. In this paper, we point out the importance of modeling architecture for consistency management, and also examine the modeling mechanism that supports approximation modeling.. 1. はじめに. 本稿では過去の検討を踏まえ、モデル間の整合化について再考察を行う。特に近似的モデリングのためには、局所. ソフトウェア開発に UML[15]等のモデルを活用するこ. 的なモデル間の整合化議論だけではなく、開発を通じて構. とが一般化し、またモデルベーステスト[14]、モデル駆動. 築されるモデル群全体に対する全体最適という視点で戦略. 開発[2]、あるいは形式検証など、モデルの高度な活用も実. を立てることが重要であるという観測を述べ、そのために. 践面・研究面で進んできている。あわせて Eclipse/EMF[1]. モデリングアーキテクチャを踏まえた近似化戦略の必要性. などに代表されるモデリング環境の整備も進んでいる。こ. を述べる。さらにその戦略検討を支援するためのモデリン. うした傾向は結果としてモデルの精密化、厳密化、大規模. グメカニズムのあり方について検討する。. 化を引き起こし、モデルの構築コストを大きくしている。. 2 章では、我々が今までに検討してきた近似的モデリン. またモデルは関心事に応じて構築することが重要であり. グ手法について概要を紹介する。3 章では、モデルの整合. [8]、そのため異なった関心事に対応した複数のモデル間の. 化についての再考察を行う。4 章では、再考察を踏まえて、. 整合化のコストも大きくなっている。例えばプロダクトラ. モデリングアーキテクチャの重要性について述べる。5 章. イン開発[3]においては製品群に関わる数千のフィーチャ. では、近似的モデリング手法を支援するモデリングメカニ. と、それに対応したコンパイルスイッチ等の変化点を、数々. ズムについて検討し、6 章では関連した議論を行う。. のフィーチャ間や変化点間の制約を含めて管理することが必要であり、そのコストは膨大である。一方、開発期間の短縮やビジネス環境・技術環境の変化の常態化によって、変化への対応というモデルの維持のコストも増えている。. 2. 近似的モデリング手法[11] 本章では、過去に検討してきた近似的モデリング手法に. これらにどう対応するかは開発上の課題となっており、整. ついてその概要を紹介する。. 合化に関する各種の議論や検討がなされてきた[4][5][13]。. 2.1 基本的考え方. こうした背景から、我々は大規模なモデリングにおいて. 本研究では、大規模なモデリングにおいては、常にモ. は、常に整合を保った状態を維持することは困難であると. デル間の整合を保つことは困難であるという仮説を置き、. いう仮説をおき、次善の策として整合性が不十分でもそれ. 次善の策として整合性が不十分でもそれなりの運用ができ. なりに運用できるモデリング体系を作ることを目的に、近. るモデリング体系を作ることを目的としている。そこで、. 似的モデリング手法の検討を進めている。現在までに、基. 整合化に強さと範囲という概念を導入し、最初はコストの. 本的な構想やアイデア、基本概念、近似的モデリングの戦. 許す範囲で弱く狭い整合化からスタートし、コストが許す. 略などについて概念的な整理を行ってきた[9][10][11]。. 範囲でより強く広い整合化を目指すアプローチを検討している。. †1 早稲田大学 Waseda university.. ⓒ2013 Information Processing Society of Japan. 1.

(2) Vol.2013-SE-181 No.10 2013/7/18. 情報処理学会研究報告 IPSJ SIG Technical Report 2.2 モデルと整合化の近似. となる概念や概念のインスタンス数（テストにおける. 本研究でのモデルとは対象を何らかの形式性に基づい. カバレッジ的な尺度）の活用が考えられる。ここでは. て記述したものであり、モデル間の整合化とは、二つのモ. 近似度を上げれば（よりベースラインモデルに近づけ. デルが意味的に関連付けられる概念を含んでいる際に、モ. れば）コストが上がり、近似度を下げればコストが下. デルをその意味的関連に合致した表現にすることをいう。. がるということを意図している。. 前述したアプローチを実現するために、近似モデルと近似的整合化という概念を導入した。 . . 整合度：本来の意図として整合すべきモデルに対して、どの程度整合しているかを示す概念尺度。ベース. 近似モデル：本来であれば明示的な記述が意図され. ラインモデルにおける整合度を 1 として、それより小. るモデル上の概念を近似的に表現したモデルであ. さい正数を用いる。整合化対象のモデルの近似度と、. る。なお本来であれば記述が意図されたモデルをベ. 整合化の近似度と相関を持つ概念尺度であり、対象モ. ースラインモデルと呼ぶ（これは実際には作られず. デルや整合性の近似度が下がれば整合度も下がる、つ. に終わる想定的なモデルである場合が多い）。概念. まり有用性が下がるという意図である。. を近似的に記述する方法として、典型的には以下を想定している。  過大近似：記述が意図される概念を、それを包. 上述したように、近似モデルの構築や近似的整合化のた. 含するより包括的な概念の記述で置き換える。. めのコストは、ベースラインモデルを構築し、その中での. クラスの記述をスーパークラスの記述で置き. 整合化をとるためのコストよりも小さいという仮定をおい. 換える等。. ている。一方、整合度で述べたように、近似モデルや近似.  過小近似：記述が意図される概念を、それが包. . 2.3 モデルマップ. 的整合化の活用は、有用性に関してペナルティがある。直. 含するより限定的な概念の記述で置き換える。. 感的には、粗いもしくは部分的なモデルを作り粗いもしく. 例えば複数のサブクラスが存在する際に、そ. は部分的な整合化しかとらないのであるから、モデルを活. の中の一部しか記述しない等。. 用する際には情報量の不足などが発生する。それらの不足.  未定義：記述が意図される概念を記述せず、単. はそのモデルを利用する際に補う必要がある。例えばモデ. に何らかの記述が意図されていたことのみ記. ル駆動開発で、ベースラインモデルを使えば完全なソース. 述する。. コードが生成できるはずだったが、近似モデル・近似的整. 近似的整合化：本来意図された整合化を近似的に行. 合化によって生成できるコードが部分的で不完全なものと. うことである。近似的整合化を行う方法としては、. なり、生成後に不足部分や不完全部分をハンドコーディン. 典型的には以下を想定している。. グで補う必要が生じるといった状況である。.  抽象的整合化：モデル間の概念の整合を、本来. こうした追加コストを考慮しても、近似的モデリングの. 意図されたものよりも抽象度の高い概念で行. コストがベースラインモデルによるモデリングコストより. う。サブクラスレベルでの整合化をとらずに、. も小さいならば、本アプローチが成り立つことになる。し. スーパークラスでの整合化でとどめる等。. たがって近似的モデリングを行う際には、どの程度の近似.  部分的整合化：モデルが表現している情報のサ. 度・整合度のモデルを作ることが妥当であるかの検討が必. ブセットのみを対象として整合化をとる。複. 要となる。そのために、モデルの近似度や整合度を粗粒度. 数サブクラスがあるが、その中のひとつのみ. で検討するためのモデルマップという記法を提案した。. 整合をとる等。  信用：他のモデルと整合をとらずにモデルを信用する。実際には整合をとらないので、整合化の範囲を狭めることに相当する。モデルや整合化がどの程度の近似をしているのか、結果としてモデル間がどの程度整合しているのかを示すために、近似度と整合度という概念尺度を導入した。 . 近似度：近似モデルや近似的整合化がどの程度の近. (a) 仕様例示シナリオ 1 ≪approximation (partial)≫ 1 (b’) 仕様 ≪approximation≫ 一般ｽﾃｰﾄﾏｼﾝ図 1. 要求. N (c) 設計一般ｽﾃｰﾄﾏｼﾝ図. 似になっているかを示す概念尺度。ベースラインモデルを 1 として、それより小さい正数を用いる。モデル. OS仕様書. の近似度のためのメトリクスとしてはモデル要素の数、汎化階層の深さなどの活用が考えられる。整合化. (b) 仕様一般ｽﾃｰﾄﾏｼﾝ図. 図 1. モデルマップの記述例. の近似度のためのメトリクスとしては、整合化に必要. ⓒ2013 Information Processing Society of Japan. 2.

(3) Vol.2013-SE-181 No.10 2013/7/18. 情報処理学会研究報告 IPSJ SIG Technical Report 図 1 はモデルマップの記述例である。ここでは対象とし. とを表す次元である。例えば構造の側面とふるまいの. ているモデル群を実線の角丸四角、モデル間の関係が実線. 側面とはそれぞれクラス図とシーケンス図などで示. で示している。抽象度の違いは多重度で（抽象度が低い方. されるが、クラス図中のクラスのインスタンスがシー. が多）、例示・一般化の違いは矢印の向きで表している（一. ケンス図上の参加者として表されるといった関係を. 般化から例示へ方向を示す。両者が同種なら方向性なし）。. 持ちうる。. 形式性をもったモデルとしては記述されていないものはソ. . 開発の次元：開発のフェーズに応じて適したモデル. ースと呼び破線の楕円で示す。破線の矢印は依存関係であ. の表現が存在することを表す次元である。例えば要求. る。またモデルやモデル間の整合の近似をステレオタイプ. のモデル、設計のモデル、実装コードなどといったフ. で表現している。こうしたモデルマップを利用しながら、. ェーズごとでのモデルが存在する。一般に上流のモデ. 適切な近似度や整合度の検討を行うことを想定している。. ルは下流のモデルに対する制約を表すため、制約部分に関する関係を持つ。下流のモデルは上流のモデルの制約を踏まえながらも、より詳細な実現の判断が加え. 3. 整合化問題再考. られるものとなる。. 本稿ではまず、モデルの整合化の問題について再検討を. . 抽象化の次元：表現の抽象度のレベルに応じてそれ. 行う。. ぞれ異なったモデルが存在することを表す次元であ. 3.1 モデル間の関係と整合化. る。例えば設計を表現するモデルにも、特定のアプリ. 前述したようにモデルとは対象を何らかの形式性に基づ. ケーションの設計を具体的に記述するモデルもあれ. いて記述したものである（本稿ではプログラムなどもモデ. ば、方式やパターンを抽象度高く記述するモデルもあ. ルに含める）。モデルはそれぞれの関心事に基づいて記述さ. る。具体的なモデルは抽象的なモデルとの間に具現化. れるため、二つのモデル間ではすべての記述概念が対応づけられるわけではない。本稿ではモデルが関係を持つとは、. という関係を持つ。 . 可変性の次元：複数の製品群を表す包括的なモデル. 対応付ける概念が存在することをいう。なお関係は意味的. から個別の製品を表すモデルまで存在することを示. なものであり、モデルの構築者や利用者が判断するもので. す次元。例えばプロダクトライン全体を表すフィーチ. ある(図 2)。. ャモデルもあれば、それらのサブセットを表すフィーチャモデルもある。製品群を表すモデルに対してより. Aだけが持ち対応付けができない概念. 個別の製品固有の判断や制約を加えたものが、特定の. モデルBの表す概念. モデルAの表す概念モデル間でなんらかの対応づけができる概念. Bだけが持ち対応付けができない概念. 製品（群）を表すモデルになるという関係を持つ。 . メタ階層の次元：モデル記述を制約するより上位のモデルが存在するということを示す次元。例えば UML[15]のメタモデルアーキテクチャにおける M0 か. 図 2. モデル間の概念の関係. ら M3 のモデルなどがある。より上位（メタ）なモデルをインスタンス化したものが下位のモデルになる. モデル間の整合化とは、モデルの記述を意味的な対応と合致した状態にするための明示的な作業を意味する。典型. という関係を持つ。 . 時間の次元：時間軸にそったモデルの変化を示す次. 的な手段としては、検証（両者のつきあわせ、レビュー、. 元。例えばひとつの設計モデルが時間軸に沿って、修. テスト、形式検証など）や、派生（一方から他方へのマッ. 正・拡張・進化していくことによって、異なったモデ. ピング、変換や生成など）が考えられる。. ルになる。同一のモデルの変化である限り、表現上あるいは意味上で何らかの共通部分が保持されている. 3.2 モデルの次元開発において様々なモデルが作られる。こうした複数の. という関係を持つ。様々なモデルはこうした次元であらわされる空間のどこ. モデルが必要となる理由は、多様な関心事のスペクトラム. かに位置づけられる。個々のソフトウェア開発においては、. があるからと考えられる。Sutton は関心事のモデル化のス. どういう位置づけのモデルが必要かを判断し、どういうモ. キームとして Cosmos を提案し[16]、また Farve はソフトウ. デル（群）を作り、それらのモデルの間に存在する関係（群）. ェア進化を 3 次元の軸で捉えている[7]。以下は、それらを. に対して、どういう整合化を行うかを考えなければならな. 参考に、ソフトウェア開発において活用されるモデルを捉. い。. えるために、有用と考えられる次元を示したものである。. 3.3 整合化のリファレンス. . アーキテクチャビューの次元：品質特性に応じて、. 3.1 で述べたように、関係はモデルの構築者や利用者等. その理解や検討に適したモデルの表現が存在するこ. の捉え方によって決まる意味的なものであり、また整合化. ⓒ2013 Information Processing Society of Japan. 3.

(4) Vol.2013-SE-181 No.10 2013/7/18. 情報処理学会研究報告 IPSJ SIG Technical Report はモデルの表現を意味的な対応に合致した状態にするため. 群を抽出し、それをどれだけ確かに実行・比較できたか、. の明示的な作業である。図 3 はこうしたモデル間の整合. ということによって質が決まることを表している。なお関. 化を考える際のリファレンスである。. わるコストは、モデルの表現のコスト（①）、整合化（導出と対応付）のコスト（②、③）によって決まる。らして捉えられるということである。例えば、設計モデル. 意図. 関係. は方式確認のために使うという意図で記述したのであれば、. ①表現記述. ここで指摘したいのは、整合化の質はあくまで意図に照. 関心事B. 関心事A. ①表現. モデルA. モデルB. 仮に設計モデルに実装に近い情報が含まれていても、その概念を導出して対応付けることは意味がない。個々のモデルはどのような意図で使われるかという、開発全体の中での役割があるのであり、整合化はその役割に関わる対応付. ②導出意味. ②導出. 関連意味概念A. ③対応付け. 図 3. 整合化のリファレンス. けのみを行えばよい。. 関連意味概念B. 4. モデリングアーキテクチャ前章の検討を踏まえ、モデリングアーキテクチャについ. ここで 3 つのレイヤは、以下を表す。. て再検討する。. . 意図：モデルの構築者や利用者の意図. 4.1 モデル構築の意図・関心事. . 記述：その意図のモデルとしての記述. . 意味：記述されたものの意味. モデルはそれぞれなんらかの関心事に基づいて対象を. 整合化がモデル間の関係に関する意図に照らして捉えられるのは、それぞれのモデルやモデル間の関係がソフトウェア開発という目的の中で位置づけられているからである。. 表現したものである。また二つの関心事の間には何らかの. 素朴には、個々のモデルをどこまで完成させればいいか、. 関係が認識される。このリファレンスにおいて整合化は、. モデル間の整合化をどこまでとればよいか、といったこと. それぞれのモデル記述から意図された関係に関わる意味概. が明確に意識されていれば、必要十分なコストでモデル化. 念を導出し、両者を対応付けることでなされることとして. ができる。こうしたマクロなモデル化の方針を明示的に意. 示されている。. 識しないまま個々のモデリングを行うと、目的にとって不. モデルベーステストを考えると、例えばモデル A は対象. 十分なモデルができたり、過度にコストをかけて不要な詳. のふるまいを仕様レベルで表現したステートマシン図、モ. 細まで記述したモデルができたりする危険性がある。個々. デル B は対象のふるまいを特定のプログラム言語やプラッ. のモデル構築や整合化をどこまで行うかは、マクロな目的. トフォームを想定して記述したコードに相当する。整合を. に対する合目的性で判断されるということである。. 確認する際には、ステートマシン図の実行意味を踏まえて. マクロな目的とは、例えば最終的なコードの品質を良く. モデル A を解釈してテストケース（例えばパスの系列の集. したい、方式設計の質をよくしたい、エラー処理の妥当性. 合）を導出し、一方ではモデル B を解釈して実動作させて. を確認したい、あるいはコードの自動生成を行いたいなど. 観測し、その両者を対応付けて（例えば設計上のイベント. といった、モデルを活用する狙いである。これらを関心事. が実装上のどのような現象に対応づくかをつきあわせて）、. と呼ぶとすると、個々のモデルが関心事に基づいて作られ. 両者を比較することに相当する。. るのと同様に、モデル群の全体構成も関心事に基づいて行われるということである。個々のモデルをどう構築するか. 3.4 整合化の質とコストここで整合化の質は、実際に記述されたモデル間で、意. がそのモデルに関わる関心事で決まるように、モデル間をどこまで整合させるかといったことはモデル群全体に関わ. 図した関係が成立しているかどうかを、どの程度まで確か. れる関心事（マクロな目的）で決まると考えられる。. に確認できるか、ということによって捉えることができる。. 4.2 モデリング作業のマクロな捉え方. 確認の質は、関心事をどの程度適確に表現しているかと. モデル構築の意図・関心事が定義され、その意図や関心. いうモデルの記述の質（①）、対応づけるための概念をどの. 事に照らして個々のモデルの役割や必要な整合化のレベル. 程度適確に導出しているかという関連意味概念導出の質. が設定されたとすると、モデリング作業全体は、以下に対. （②）、さらに意味概念の対応付けをどれだけ適切に行って. する最適解を求める問題と捉えて戦略付けすることができ. いるかという対応付けの質（③）によって決定づけられる。. る。. モデルベーステストでは、ステートマシン図がどれだけ適. . 確に対象を表現し、そこからどれだけ妥当なテストケース. ⓒ2013 Information Processing Society of Japan. 目的関数：モデリング作業全体の目的関数は、モデル構築の意図・関心事がいかに適切に達成されるかで. 4.

(5) Vol.2013-SE-181 No.10 2013/7/18. 情報処理学会研究報告 IPSJ SIG Technical Report ある。各モデルの記述のレベルや、整合性のレベルが、. 記述し、モデル間の関係をどこまで整合化させることが合. その意図・関心事に照らして決まっているとすると、. 目的であるかが理解しやすくなる。さらにモデリングアーキテクチャの違いが、目的・関心. モデリング作業の目的は概念的に以下のように捉えることができる。. 事の達成を容易にも困難にもする。例えば、個々のモデルの規模、モデル間の関係の大きさ、相互の関係の複雑さ、. ∑（Wmi×Qmi）＋∑（Wrj×Qrj）：最大. 相互依存か単方向依存化、モデルの総数や依存関係連鎖の長さなど、モデリングアーキテクチャの構造的特徴に応じ. ここで Qmi は各モデルに設定されたモデルの質、Wmi. て、モデル構築や整合化のコストが変わってくる。したが. はそのモデルの質が全体の意図・関心事の達成に対し. って、大規模モデリングでは、目的に応じた適切なモデリ. て持つ重要度である。また Qrj は各関係に設定された. ングアーキテクチャを設計することが重要になると考えら. 整合度の質、Wrj はその整合度の質が全体の意図・関. れる。. 心事の達成に対して持つ重要度である。( i は個々のモデル、j は個々の関係を表すとする) . 5. モデリングメカニズムに対する考察. 制約：有限のコストの中で作業を行うわけなので、. 以上の検討を踏まえ、近似的モデリングを支援するため. 上記を達成するための制約は概念的に以下のように. のモデリングメカニズムについて考える。なお本稿では具. 捉えることができる。. 体的なモデリングメカニズムの定義は行わず、それに対する要件と概略的なイメージを示す。. ∑Cmi +∑Crj < 許容コスト. 5.1 要件近似的モデリングを行う際には、以下の二つを支援する. ここで Cmi は各モデルの構築コスト、Crj は各関係の. モデリングメカニズムが必要と考える。. 整合化のコストである。. . 4.3 モデリングアーキテクチャの重要性. 重要であり、その記述ができること。. 本稿では、開発を通して作られるモデル（群）とそれらモデルの間の関係をモデリングアーキテクチャと呼ぶ。上. モデリングアーキテクチャの記述：近似的モデリングを行う際には、モデリングアーキテクチャの検討が. . 個々のモデルや整合化の近似の記述：モデリングア. 述したように、モデリングを行う際にはモデル化全体の目. ーキテクチャに沿って、それを個々のモデル・整合化. 的に照らして、個々のモデルや整合化の役割が定義される。. の近似度へとブレークダウンできること。この際に、. つまりモデリングアーキテクチャに基づいて整合化が議論. 以下の記述ができることが望まれる。. されることになる。. . モデルが近似モデルであることを明示できる：モデルの構築者が、近似モデルを構築した際に、. 例えば、モデルはあくまで人間が読むためのドキュメントであり個々のモデルの間の整合性は人手で確認するとい. どのモデル要素がどう近似されているかを記述. った整合性をゆるく捉えるモデリングアーキテクチャも考. できる。. えられるし、メタモデルとメタモデルに基づく変換を定義. . モデルを近似的に利用したことを明示できる：. しコード生成を行うことを狙ったモデリングアーキテクチ. モデルの利用者が、モデルをどういう近似モデ. ャも考えられる。仮にクラス図やステートマシン図が記述. ルとみなして利用したかを記述できる。仮にモ. されたとしても、それらのモデルに対して求められる記述. デル構築者はベースラインモデルを構築したと. や整合性のレベルは、モデリングアーキテクチャに応じて. しても、整合をとる際にそれを近似モデルとし. 全く異なったものになりうる。. て利用する状況が考えられる。この場合、定義されたモデルを近似モデルとして捉えなおして. これは通常の設計において強度と結合度が重要なように、. 利用することになる。そうした利用の意図を記. モデリングアーキテクチャにおいても、その構成要素であ. 述できる。. る個々のモデルの強度や、その間の結合度という概念が重要であることを示唆している。モデリングアーキテクチャ. . 近似のレベルを変えられる：近似モデリングは、. におけるモデルの強度とは、モデル群（ひいては開発）に. コストが許せば徐々に近似度をベースラインに. おいて、そのモデルがどのような役割を果たしているかが. 近づけることを意図している。そうした近似度. 明確に定義されているかどうかということであり、モデル. のレベルの違いを表現できる。. 間の結合度とは、モデル間の関係が明示的に定義され必要. 5.2 モデリングアーキテクチャの記述. 十分な範囲に抑えられているかどうかということである。. モデリングアーキテクチャの記述には、2.3 で述べたモ. モデリングアーキテクチャにおいて、個々の強度と結合度. デルマップを活用する。なおモデルの粒度は目的に応じて. が適切に定義されているならば、個々のモデルをどこまで. 大きく捉えたり、逆に注目する一部を詳細に捉えたりする. ⓒ2013 Information Processing Society of Japan. 5.

(6) Vol.2013-SE-181 No.10 2013/7/18. 情報処理学会研究報告 IPSJ SIG Technical Report ことが必要である。例えば設計のクラス図とステートマシ. を含んでいるが、より概略的であるために導出後により限. ン図をひとまとまりのモデルという単位で捉えたり、逆に. 定化、具体化することが必要となる。図の(b)と(c)ではそれ. クラス図の中で特定の部分に関わるものとそれ以外の部分. ぞれステレオタイプを用いて、過大近似あるいは過少近似. を区別して捉えるたりすることがありうる。そうしたこと. した部分を示している。. を表現するために、モデルの集合を表すクラスタという要. 要件で述べたように、構築者は自己の構築したモデルが. 素を追加する。図 4 はクラスタ記述（クラス図とステート. 近似モデルであることを明示したいし、利用者はそのモデ. マシン図を表すモデルを包含する四角）を用いた、モデル. ルを近似的に利用したことを明確にしたい。これを表現す. マップの記述例である。. るために、近似インタフェースというモデリングメカニズムを導入する。近似インタフェースは、モデルに対する一 OS仕様書. 種のフィルタであり、あるモデルをインポートして、そのモデルをそのままあるいは近似した形でエクスポートする機能を持つ。図 6 は近似インタフェースのイメージである。. 仕様一般クラス図. 仕様例示シナリオ. 要求. 1 1. 設計一般クラス図 1. 仕様一般ｽﾃｰﾄﾏｼﾝ図. N. 設計一般ｽﾃｰﾄﾏｼﾝ図. ① 直接の参照. モデル. 図 4. 利用側. クラスタを用いたモデルマップの記述例 ② 近似インタフェースの利用. 5.3 モデルの近似表現 2 章で述べたように、モデルの近似化には、過少近似や. モデル. 過大近似を用いることを想定している。例えば図 5 は、フィーチャモデルの近似化の例を示したものである。. 近似ｲﾝﾀﾌｪｰｽ. Navi. DVD. 利用側. ③ 複数の近似インタフェース. (a) ベースラインモデル. Map. 近似ｲﾝﾀﾌｪｰｽ. モデル. Map update HD. 近似ｲﾝﾀﾌｪｰｽ. Comm. WiFi. 3G. (b) 過小近似の例. 図 6. 利用側. 近似インタフェースのイメージ. ここで①はベースラインモデルであれ近似モデルであれ、. Navi Map Map update HD. モデル構築者が作ったモデルをそのままエクスポートし、利用側がそれをインポートして参照している。一方②は、. Comm. WiFi. <<under>>. <<under>>. 構築したモデルを、利用者は近似インタフェースを介して. 凡例. (c) 過大近似の例 Navi. : フィーチャ : 代替 : 選択 : 依存(必要）. 参照している。この場合、もしも構築者が作成したモデルをそのまま公開する、あるいは利用するのであれば、近似インタフェースは単にインポートしたモデル要素をそのままエクスポートするのみである。しかし仮に構築者がベー. Map. <<over>>. Map update. 図 5. Comm.. <<over>>. フィーチャモデルの近似化の例. スラインモデルを作っても、それを近似として利用してほしいという意図がある場合には、インポートしたモデルを近似してエクスポートする。例えば図 5 の例であれば、(a) をインポートして(b)をエクスポートするような方法であ. ここで(a)がベースラインモデルとしたときに、(b)は(a). る。こうしたフィルタ的な機能を持たせることで、構築者. に包含されるがより限定的な表現しかしていないので、過. が利用のされ方を明示したり、あるいは逆に利用者が自分. 小近似である。これから導出される製品は(a)から導出され. の使い方を明示したりすることができる。さらに③のよう. る製品に含まれるが、すべてを導出することはできない。. に複数のフィルタを用意し異なった近似モデルをエクスポ. 一方(c)は(a)を包含しているが、より概要的なことしか示し. ートすることで、必要に応じて適切なレベルの近似モデル. ていない。(c)から導出される製品は(a)から導出される製品. を利用することができる。. ⓒ2013 Information Processing Society of Japan. 6.

(7) Vol.2013-SE-181 No.10 2013/7/18. 情報処理学会研究報告 IPSJ SIG Technical Report モデルマップ上で近似モデルの部分に対応して、この近似インタフェースが用意される。図 1 では、(b)のステートマシン図を近似した(b’)というステートマシン図が記述さ. 7. おわりに. れているが、この(b’)に対応した近似インタフェースを用. 本稿では近似的モデリングについて、整合性やモデリン. 意することで、モデルマップにそったモデルの利用を行う. グアーキテクチャなどに関する検討を踏まえ、モデリング. ことができる。. メカニズムに関しての考察を行った。今後メカニズムの詳. 6. 議論本稿では過去に提案した近似的モデリングについて、その整合化の意味について再検討を行い、近似的モデリングにおいて全体最適な視点が必要であることを指摘し、モデリングアーキテクチャの重要性について議論した。近似的モデリングを実践するためには、実際に個々のモデルにおいてどのように近似化を行うのか、あるいは近似化されたモデルをどう活用するのかというテクニックが必要となる。そうしたテクニックとして、例えばデルタ指向モデル[6]などの提案もあるが、本稿ではこうした個別のモデリングテクニックには立ち入らず、モデリングの戦略付というマクロな視点での議論を行った。近似を行う際には、モデル全体に対する目標・関心事に照らして個々のモデルの役割やモデル間の整合性を捉えることが重要であることを指摘し、モデリングアーキテクチャにおけるモデルの強度とモデル間結合度という議論を行った。この議論を敷衍すれば、モデルがその構造化の方法によって様々な特性を示すのと同様に、モデリングアーキテクチャもその構造によって様々な特性を示すという議論に発展する。望ましい特性をもったモデリングアーキテクチャを実現するために、モデリングアーキテクチャのためのアーキテクチャスタイルといった議論も戦略付においては重要であろう。例えば MDA[2]における PIM と PSM の分離という考え方は、モデリングアーキテクチャのためのひとつのアーキテクチャスタイルとみなすことができる。モデルのいくつかの次元を検討したが、これらの次元はそれぞれ異なった特性を持つ。例えばエンジニアリングの. 細を検討するとともに、その具現化を行いたい。. 参考文献 [1] http://www.eclipse.org/modeling/emf/ [2] http://www.omg.org/mda/. [3] http://www.splc.net/. [4] Balzer, Robert: Tolerating Inconsistency, ICSE 1991, pp158-165, 1991. [5] Bo Wang, et al.: Tolerating Inconsistency in Feature Models, LWI 2010, pp15-20, 2010. [6] Clarke, D., Helvensteijn, M., Schaefer, I.: Abstract Delta Modeling. Mathematical Structures in Computer Science (2011). [7] Favre, J.: Meta-Model and Model Co-evolution within the 3D Software Space, Proc. of ELISA workshop Evolution of Large-scale Software Evolution, (2003). [8] IEEE: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std 1471-2000, 2000. [9] 岸知二, スケーラブルなモデリング技法に関する考察, 情報処理学会ソフトウェア工学研究会, Vol2011-SE-173,No.10, pp1-8, 2011. [10] 岸知二, ソフトウェアモデル間のスケーラブルな整合化戦略について, ソフトウェア工学の基礎ワークショップ, FOSE 2011, pp97-102, 2011. [11] 岸知二, 近似的モデリング技法についての考察, 情報処理学会ソフトウェア工学研究会, Vol2011-SE-177, No.3, pp1-7, 2012. [12] Noda, Natsuko, et al.: New Challenge of Scalable Modeling, SCALE 2010, the second proc. of SPLC2010, pp191-192, 2010. [13] Nuseibeh, Basher, et al.: Leveraging Inconsistency in Software Development, IEEE Computer, pp24-29, April, 2000. [14] Mark Utting, et al. Practical Model-based Testing, Morgan Kaufmann Publisher, 2007. [15] OMG: Unified Modeling Language Specification, Version 2.4, 2010. [16] Sutton jr., s. et al., Modeling of software concerns in Cosmos. In 1st Int'l Conf. Aspect-Oriented Software Development (AOSD), ACM, 127–133, 2002.. 次元では、上位のフェーズのモデルの概念と下位のフェーズのモデルの概念とは多対多の関係になるが、傾向としては下位のモデルの概念の方が多くなると考えられる。これは一般に実装のモデルの方が詳細化しているので対応するモデル要素が増える（本稿では対応概念の増幅と呼ぶ）ことが多いためである。一方ビューの次元では、例えば構造モデルとふるまいモデルの間で対応する概念はどちらが多いかということを一般的に論じることは難しい。粗くいえば、アーキテクチャビューの次元や時間の次元では、特定の増幅の傾向はみられないが、他の次元は一般的には特定の方向へ増幅する傾向がある。こうした増幅の有無は、モデル構築や整合化のコスト議論に影響を及ぼすため、実際のモデリングアーキテクチャ検討においては、このような特性の考慮も必要になる。. ⓒ2013 Information Processing Society of Japan. 7.

(8)