ドメイン特化モデルのモデル作成効率評価
川上真澄
†小川秀人
† モデルベース開発の効率を向上させるために対象ドメインに特化したドメイ ン特化モデル(DSM, Domain-Specific Model)を定義し，ソフト開発に用いる手法が 普及している。このとき，対象ドメインの特性に適した DSM を定義しなければ， 開発効率を向上することができないが，定義された DSM がどの程度対象ドメイ ンに適しているかを評価する手法は確立されていない。本論文では，定義された DSM が，UML に代表される汎用的なモデル記法よりもどの程度モデル記述効率 が良いかの評価を行える評価フレームワークを提案する。評価フレームワークは 定式化を基に行うため，対照実験を行なわずとも実用的な規模の開発対象を評価 可能である。Evaluation of Modeling Efficiency Using
Domain-Specific Model
Masumi Kawakami
†and Hideto Ogawa
†Software development approach using Domain-Specific Model (DSM) defined for target domain spreads to improve efficiency of Model-based Development. If we do not define the DSM suitable for the characteristic of the target domain, we cannot improve development efficiency; but the technique to evaluate how suitable defined DSM is for target domain is not established. In this article, we propose evaluation framework that we can evaluate how well is model description efficiency for DSM and general-purpose modeling language such as UML. The evaluation framework does not have to perform control experiment, because it based on formulation. And we can apply it for practical scale problem.
1.
はじめに 組込みソフトウェアの開発効率を向上させる手段としてモデルベース開発が普及 している[1][2]。モデルベース開発の効率をさらに向上させるために，開発対象のドメ インに適したドメイン特化モデル(DSM, Domain-Specific Model)を定義し，ソフト開発 † 株式会社日立製作所 横浜研究所Hitachi, Ltd., Yokohama Research Laboratory
に用いる手法が普及してきた[3][4][5][6]。現在は様々なドメインに対して様々な DSM が提案されている段階である[7][8][9]。 DSM を定義する場合，対象ドメインと開発対象の特性を分析し，それらに適した記 法を定義し DSM として採用する。このときドメインに適した DSM を定義しなければ 開発効率を向上することができず，モデル作成効率の低下や，開発に必要な情報の表 現不足が起こる。 定義された DSM を用いる前に，DSM がどの程度対象ドメインに適合しているかど うかの評価を行いたい。通常，被験者とトイ問題を用いた対照実験を行う手法が一般 的であるが，実用規模の問題で対照実験を行うと工数が大きくなりすぎるという課題 がある。 そこで本提案では，実用規模の問題に DSM を適用した場合のモデル化コストを定 式化し，UML に代表される汎用の設計手法に対してモデル化効率が向上するかどうか 評価を行う。本手法により，様々な DSM の評価を机上で行うことが可能となる。
2.
アプローチ DSM のモデル化効率を評価するために，対象となるドメインを設定し，汎用的なモ デル記法である UML[10]と DSM のモデル化効率の比較を行う。UML は基本的に様々 なドメインに適用できるため本比較フレームワークの基準として適用できると考えた。 しかしながら，UML を用いた場合，設計者にスキルに依存してモデル化効率の良い モデルになったり，悪いモデルになったりする可能性がある。この場合のモデル化効 率とは，モデル作成コスト，モデル変更コスト，モデル検証コストが低いことを指す。 設計者の持つモデル化方針が悪いとモデル作成コストやモデル変更コスト等が悪くな る。これをここでは悪い UML モデルと呼ぶ。逆に良いモデル化方針に基づいて作成さ れた UML モデルを良い UML モデルと呼ぶ。DSM を用いる場合，対象ドメインに特化 した記法となっているため，設計者のスキルに依存せず，設計されるモデルの質はほ ぼ一定となる。この分布イメージを図 1 に示す。モデル化効率 度数 UMLによる設計分布 悪いUML モデル 中間的な UMLモデル 良いUML モデル DSMによる設計分布 図 1 設計者のスキルによるモデル化効率のばらつき そこで，ある特定の対象ドメインの仕様と開発プロセスを前提として定義し，悪い UML モデル，良い UML モデル，DSM によるモデルによる設計を行い，モデル作成 コスト，モデル変更コスト，モデル検証コストの比較を行う。 コスト比較は定式化を基に行う。具体的にはモデル化作業の手順を細分化して定義 し，各手順においてモデル図にどのような操作を行うかを定義する。次に，この操作 を行うときに，作業コストに大きく影響するパラメタを抽出する。具体的には，操作 の対象となるモデル図のモデル要素数等が，作業コストのオーダに影響する。このパ ラメタを用いて，各作業における作業コストを定義する。 次に，対象ドメインにおいて実用的に使われると推測されるモデル要素数を設定し， 定式化した作業コストのパラメタに代入し，トータルの作業コストの総計を求める。 最終的に，設計者のスキルのばらつきを考慮した場合に，UML と DSM のモデル化 コストに差が現れるかどうかを評価する。図 2 にモデル化コストの比較結果のイメー ジを示す。本来であれば UML と DSM の比較を行いたいが，UML には実現されるモ デルによってモデル化コストの幅があるため，三者を並べて比較する。通常のスキル を持つ設計者は悪い UML と良い UML の中間のどこかの値を取るものとし，UML の 中間値と比べて DSM が良いかどうかで DSM の対象ドメイン適合度を測る。 悪いUML モデル 中間的な UMLモデル DSM モデル化 コスト 良いUML モデル 図 2 モデル化コストの比較評価 図 3 に評価フレームワークを示す。このフレームワークは DSM の種別に関わらな いため，どのような DSM も同じ手法で評価が行えると考える。 対象ドメインの プロセスを定義 モデルを作成するため作業と、 作業への入出力を定義 評価対象の DSMモデルを定義 同等の情報を表す UMLモデルを定義 特定の製品仕様を想定して コスト計測に用いるモデルを作成 想定される開発プロセスに対して 良い/悪いUMLモデルを作成 作業コスト 評価式の定義 開発プロセスを細分化し、モデルに対する操作と、 作業コストに影響するパラメタを抽出 作業コスト比率の 算出 作業コスト評価式をもちいて、 特定ケースでの作業コスト比率を算出 DSMのモデル化 効率評価 UMLに対して、DSMがどの程度 モデル化効率が良いかを評価 図 3 評価フレームワーク
3.
対象ドメインのプロセス定義 評価に用いる対象ドメインを，ソフト開発量の多いデジタル家電とする。モデルベ ース開発を適用する工程を製品仕様検討から設計工程とし，モデル化する対象は製品 仕様とする。既存の製品に対して新機能を追加する派生形開発を想定する。新機能は 商品企画者が提案し，製品設計者は既存製品仕様に追加可能か検討し，最終的に整合 性のとれた製品仕様を定義する。 商品企画者と製品設計者の役割を図 4 に示す。 【商品企画】 【製品設計】 新機能案作成 新機能設計 新機能確認 新機能修正 全体製品設計 後工程 既存 製品仕様 新機能 案 1～n 新機能 仕様 x 新機能 修正案 x 新機能 仕様 x 採用された 新機能仕様 1～n 全体 製品仕様 図 4 製品仕様検討プロセス 商品企画者： 新機能を考案し，機能概要と画面遷移案を作成する 製品設計の結果を確認し，製品の魅力やユーザビリティの観点から，製品仕 様の修正を指示する 製品設計者： 機能概要と画面遷移案から，新機能の画面レイアウトと画面遷移を設計する 新機能のシミュレーションを作成し，商品企画の製品仕様確認を行ってもらう 機能の技術的な実現可能性や開発コストを確認する 新機能追加による，既存機能の製品仕様の変更を行う 製品仕様全体に対する記述整合性(定義誤り，画面遷移不具合等)の確認を行う 以上の状況を想定し，製品仕様設計作業を UML および DSM で行った場合のモデル 化効率の評価を行う。4.
評価対象のモデル化 DSM のモデル化効率を評価するために，汎用的な記法である UML との比較を行う。 しかしながら，UML を用いてモデル化を行った場合には，設計者のスキルに依存して， 機能追加や保守のしやすさが異なるモデル化が行われる。そこで本比較では，最も派 生開発において最もモデル化効率の悪い UML モデルと，最もモデル化効率が良い UML モデルを用意する。 4.1 DSM によるモデル まず，対象ドメインを表現する DSM を定義する。DSM は既報 11)で述べたデジタ ル家電向け DSL を採用する。詳細は既報にて述べられているため，ここでは概要を説 明する。DSM の体系を図 5 に示す。ここで主に用いるモデルは画面遷移図，画面遷 移表，分岐決定表，内部状態定義，の 4 種類である。 画面遷移図 画面状態 ユーザ操作 イベント 内部状態定義 状態 画面遷移表 分岐条件 画面遷移先 値更新 分岐決定表 デジタル家電 向けDSL 画面デザイン定義 三項 関連 図 5 デジタル家電向け DSM 体系 まず，商品企画者が考案した新機能の単位で画面遷移図を作成する。新機能の初期 検討は画面遷移図上に変更を加えながら行う。新機能案が固まった後，画面遷移図を 画面遷移表に変換を行う(図 6)。画面遷移表は，画面遷移図に登場する画面を状態列 に，リモコン等のユーザインタフェースから起こりえる割り込みイベントをイベント 行に並べた状態遷移表である。s1 e1 s2 e2 s3 e3 e3 画面 イベント s1 s2 s3 e1 →s2 →s3 e2 →s3 e3 →s1 →s1 e1 画面 デザイン 定義 s1 画面 デザイン 定義 s2 画面 デザイン 定義 s3 図 6 画面遷移図と画面遷移表 画面とイベントの交点のセルには次に遷移する画面を示すが，条件によって行き先 が分岐する場合には行き先を複数表示し，別途分岐決定表を作成する(図 7)。 # 分岐条件 画面 遷移 値更新 c1 c2 c1 1 * * →s2 -2 a1 * →s3 a2 3 a2 b1 →s3 a1 画面 イベント s1 s2 s3 ie1 →s2 →s3 ie2 →s3 ie3 →s1 →s1 … 図 7 画面遷移表と分岐決定表 分岐決定表はシステムの内部状態を参照し，画面遷移先と内部状態の値更新を行う。 分岐決定表は画面遷移の分岐数分作成されるが，分岐決定表が参照する内部状態は， システムで共通に定義される。 # 分岐条件 画面 遷移 値更新 c1 c2 c1 1 * * →s2 -2 a1 * →s3 a2 3 a2 b1 →s3 a1 a1 a2 b1 b2 c1 c2 図 8 分岐決定表と内部状態定義 画面遷移表は機能単位に分割されており，新機能追加のたびに追加される。 画面遷移図から変換されたばかりの画面遷移表は，割込みイベントを定義されてい ないため，製品設計者は，この画面遷移表に対して不定となっている挙動を定義する。 次に，既存部分から新機能に関連する部位があれば修正を行う（新機能の呼び出し方 法や，他機能での割り込み動作の変更等）。最後にシミュレーションを行い，ユーザビ リティ等の確認を行う。 4.2 モデル化効率の悪い UML モデル モデル化の対象となるデジタル家電の製品仕様は画面遷移の検討が主である。デジ タル家電はリモコン等の割り込みイベントを発生するユーザインタフェースを持つた め，通常の画面遷移に加えて割り込みに対する挙動を定義する。この設計作業を最も 行いにくいモデルとして，全ての画面の遷移が一つのクラスに集中して定義されてお り，何のクラス分割もされていないモデルを定義する。図 9 にモデル化効率の悪い UML モデルのイメージを示す。悪い UML モデルは，画面遷移管理クラスがすべての 画面遷移を表した状態遷移図を持つ。画面遷移分岐がある場合は巨大な状態遷移図に 記述するが，参照する内部状態は画面遷移管理クラスの属性として保持する。画面レ イアウトは画面毎にクラスを作成し，画面遷移管理クラスが保持する。シミュレーシ ョンを行う場合には，画面遷移管理クラスが状態遷移を動かしながら，表示の切り替 えを行う。 このモデル化効率の悪い UML モデルに機能を追加する場合には，新機能の状態遷 移図を巨大な既存機能の状態遷移図にマージし，全ての状態に対してイベント線を引 き直さなければならない。また設計の整合性を確認するため，全てのイベントに対し て，整合のとれた挙動になっているかどうか確認を行う作業を，巨大な状態遷移図上 で行う。 s7 画面遷移管理 s11 c1 = {a1, a2} c2 = {b1, b2} s12 s1 s2 s3 s4 s5 s8 s9 s10 s6 c1=a1 c1=a2 画面遷移管理 s1 s2 s3 図 9 モデル化効率の悪い UML モデル
4.3 モデル化効率の良い UML モデル 良い UML モデルには色々な考え方があり一意には決まらないが，ここでは対象ド メインの設計作業に対してモデル化コストが低くなることを意識し，図 10 のように 定義した。画面，割込み，内部状態をクラスで参照し，画面遷移管理が保持する。画 面遷移管理から複数の機能を保持し，画面遷移図を機能毎に分割する。画面遷移管理 は機能間の画面遷移を管理する。内部状態クラスの状態遷移図に内部状態遷移を定義 する。画面遷移図が機能毎に分割されるため見通しが良く，割込みに対する挙動は状 態のグループ化と機能レベルの状態遷移で表現できる。 逆に悪い面としては，各々の状態図に登場するイベント，状態名，内部状態の整合 性を手動で保つ必要があり，機能を跨ぐ遷移イベントの編集には少し手間がかかる。 a1 a2 c1 画面 s1 s2 s3 画面遷移管理 内部状態 割込み c1 c2 e1 e2 e3 機能 b1 b2 c2 機能1 s1 s2 s3 e1 e2 e3 e3 e1 e0 機能1 機能2 画面遷移管理 機能1 機能2 e1 e3 e0
H
e1 図 10 モデル化効率の良い UML モデル5.
モデル化コスト比較 モデル化コストの比較を行うにあたり，モデル内の要素数を以下と定義する。要素 数の定義毎に実際の値の例を示すが，実際の開発でありえる平均的な値の例である。 表 1 モデル内要素数の定義 モデル内の要素 要素数の定義 実際の値の例 既存画面数 Sn 400 既存機能数 Fn 20 新機能画面数 Snew 20 仕様修正画面数 Schng 5 イベント数 En 50 内部状態数 In 50 コストの比較は，前述の開発プロセスにおける各作業を洗い出し，各作業における コストを総計して求める。総計によって求めるコストは，悪い UML モデルによる作 業コスト CbadUML，良い UML モデルによる作業コスト CgoodUML，および，DSM による作業コスト CDSMである。各作業コストは，モデル要素数に比例して大きくものをパ ラメタとして定式化する。モデル要素数間の大小は比較できるため，各作業コストの 大まかな大小も比較できる 。 いくつかの作業について詳細を述べる。 「画面の追加」を行う場合，追加する Snewに比例した作業コストが発生する。この とき悪い UML では，全画面状態が登録されている状態遷移図 Snに対して新しい画面 遷移 Snewを追加し，イベント線の追加やレイアウトの再配置を行うため作業が煩雑と
なる。これをCadd(Snew, Sn)と表す。良い UML の場合，機能間の遷移を示した画面遷移
管理に対して新機能を追加し，既存機能とは独立した画面遷移図に Snewの追加を行う ため，既存機能数 Fnのみが影響し，既存機能の大きさは無視できる。これを Cadd(Snew, Fn)と表す。DSM の場合，機能を管理する部位はなく，新規に追加された画面遷移の 単位でそのまま機能となるため，既存機能数も意識しない。これをCadd(Snew, 0)と表す。 「画面のレイアウト設計」作業の場合，新規追加画面数に比例し，どのモデルであ っても等しく行う。これをClayout(Snew)と表す。 以下同様に各作業のコストを算出した結果を表 2 に示す。各作業のコストは，基本 的に悪い UML>良い UML>DSM という傾向となる。唯一「整合性の確認」についての み，評価が逆転しているが，悪い UML には機能という概念がなく，整合性を取る箇 所が減るためである。
表 2 コスト比較
分類 作業 悪い UML 良い UML DSM 新機能の
新規作成 画面遷移の追加 画面レイアウト設計 CCadd(Snew, Sn) > Cadd(Snew, Fn) > Cadd(Snew, 0) layout(Snew) = Clayout(Snew) = Clayout(Snew)
シミュレーション Csim2(Snew) > Csim2(0) = Csim2(0) 割込み設計 Cint(Snew, Sn) > Cint (Snew, Fn) = Cint (Snew, Fn)
既存部の修正 Cimpact(Sn, In) = Cimpact(Sn, In) = Cimpact(Sn, In) 整合性確認 Cconsist(Sn,En,In) < Cconsist(Fn, Sn,
En, In)
= Cconsist(Fn, Sn, En, In) シミュレーション Csim2(0) = Csim2(0) = Csim2(0) 新機能の
仕様変更
画面遷移の変更 Cchange(Schng) > Cchange(Schng) > Cchange(Schng)
画 面 レ イ ア ウ ト 設 計
の変更 Clay(Schng) = Clay(Schng) = Clay(Schng) シミュレーション Csim2(Schng) > Csim2(0) = Csim2(0) 割込み設計の修正 Cint(Schng, Sn) > Cint (Schng, Fn) = Cint (Schng, Fn)
既存部の修正 Cimpact(Sn, In) = Cimpact(Sn, In) = Cimpact(Sn, In) 整合性確認 Cconsist(Sn, En, In) = Cconsist(Fn, Sn, En, In) = Cconsist(Fn, Sn, En, In) シミュレーション Csim2(0) = Csim2(0) = Csim2(0)
総計 CbadUML > CgoodUML > CDSM
各 コ ス ト の 比 率 を 見 る た め に ， 各 作 業 コ ス ト に 対 し て パ ラ メ タ に 比 例 す る 式 (Cadd(Snew, Sn) = a・Snew＋b・Sn 等)を設定する。本来は，作業に対する影響度を各パラメ
タの係数(a, b 等)として設定すべきだが，ここでは各コストの絶対値ではなく比率をみ る目的なので，各係数は各モデルのコストに対しては均等に影響するとして 1 で計算 を行う。この式に，実際の開発であり得そうなモデル内要素数を設定し，コストの比 率計算を行う。ここでは表 1 の「実際の値の例」に示した値を用いた。コスト比率の 結果を表 3 に示す。 表 3 コスト比率 CbadUML CgoodUML CDSM コスト比率 3200 > 2075 > 2055 コスト比率の結果は，CbadUML > CgoodUML >≒ CDSMという結果になった。これらの関係 を図 11に示す。 CbadUML CmidUML CDSM モデル化 コスト CgoodUML DSM導入によって 削減可能なコスト 図 11 コスト評価結果 この結果から，DSM は，モデル化効率の悪い UML モデルよりも効率が良いが，モ デル化効率の良い UML とは大きな差は無いと言える。UML は設計者のもつ設計スキ ルに大きく依存するが，DSM は設計者のスキルによるブレは少ないため，設計者のス キル幅があるときは DSM が有利と言える。
6.
考察 コスト比率の解釈について述べる。 悪い UML は，クラス分割をまったく行わず，モデル要素が一か所に集まることで 複雑になり，メンテナンス性が悪くなるモデルを想定した。実際の開発においては， 意図の分からないクラス分割を行ったモデル図を他の人がメンテナンスするケースの 方が，よりモデル化コストが掛かる可能性があるが，今回は定式化を単純にするため 除外している。 また良い UML は，同じ対象ドメインに対してモデル化効率が良くなるよう定義さ れた DSM の構成に非常に似てくるため，DSM によるモデル化コストに非常に近づく。 但し，UML 記法としての整合性を保つ必要性があるため，細かい部分の省略が行えず， DSM よりも若干コストが大きくなる。（具体的には，機能間状態遷移と画面間状態遷 移図間のイベント名の合せ込み等） DSM を用いる場合，開発時のモデル化コストは最小となるが，実際にはその他のコ ストを考慮する必要がある。DSM の定義や，DSM の教育，DSM をサポートしたツー ルの開発等が必要になる。良い UML モデルと DSM のモデル化コストは大差ないため， 良い UML を書ける設計者が多くいる場合には DSM を導入するメリットは少ない。ス キルにバラツキのある組織に対してのみメリットがあると言える。7.
議論 本論文では，定義された DSM のドメイン適合性を評価することが目的であったが， この目的に対して UML と DSM を比較する手法を採択した。本来の目的からすると複 数の異なる DSM を同一尺度でもってドメイン適合度を計測したいのだが，本手法で は基準点となる UML の方に幅があるため絶対的な尺度としては利用できない。また あるドメインにおいて計測した DSM および UML のモデル化効率は，他のドメインで 計測した DSM および UML のモデル化効率とは共通性がなく，ドメイン毎の比較とな ってしまう。 また，コストの比率を算出するときに，各作業コストパラメタに掛かる係数を 1 と しているが，本来は各作業コストへの影響度を実験的な手法なり何なりで確定しなけ れば，コスト差が実際の値よりも開いてしまうという課題がある。しかしながら，実 験を行わずにコスト評価を行いたいという元々のモチベーションから，大幅な割りき りを行っている。この部分に関しては基礎データを実験で蓄積した後，コスト計算を 行った方がよい結果が得られる可能性がある。 また「実際の値の例」としてモデル要素数を設定したうえでコスト比率を算出して いるが，実際の値にもバラツキ幅がある。例えば，機能数 1 のシステムであれば悪い UML と DSM の差は非常に小さくなる。元々ドメインの特性として大規模な機能を持 つシステムを対象としているので，極端な値は評価の対象外としているが暗黙的に DSM に有利な前提を置いてしまっている懸念はある。 また，今回は DSM を設計した人間が DSM の評価を行っているが，DSM の知識が ない第三者が評価を行った場合に同じ結果を得られない可能性がある。評価に必要な 対象ドメインのプロセス定義を行い，各作業に影響するパラメタを抽出することは， 対象ドメインを理解していないと困難である。特に今回は DSM の設計が終了した後 に評価手法を検討しているため，無意識のうちに DSM に有利なパラメタを抽出して いる懸念がある。また，対象とするドメインに対して良い UML モデルと悪い UML モ デルを用意できなければ比較が行えないという課題があるが，これも対象ドメインの 知識がなければ難しい。8.
おわりに 本提案では，DSM が対象ドメインに適合しているかどうかを評価することを目的と して，汎用的なモデル記法である UML と DSM のモデル化コストの評価を行った。 モデル化コストの評価は定式化をベースとしているため，対照実験を行えない実用 規模の問題に対しても適用できると考える。また，この評価手法は特定の DSM に特 化していないため，様々な DSM に適用可能であると考える。 今後は，複数の DSM への適用評価を行い，本手法の妥当性の検証を行いたい。参考文献
1) Frankel, S., 日本アイ・ビー・エム TEC-J MDA 分科会 : MDA モデル駆動アーキテクチャ, エ スアイビーアクセス，2003
2) デビッド・Ｓ・フランケル，ジョン・パロディ他：MDA マニフェスト--巨匠たちの論点:エッ センス，および現状と未来，エスアイビー・アクセス，2005
3) Mernik, M., Heering, J. Sloane, A. : When and How to Develop Domain-Specific Languages, ACM Computing Surveys, Vol. 37, No. 4, December 2005, pp. 316-344, 2005.
4) Tolvanen, J., Kelly, S. : Integrating Models with Domain-Specific Modeling Languages, The 10th Workshop on Domain-Specific Modeling, http://www.dsmforum.org/events/DSM10/Papers/Tolvanen.pdf, (2010)
5) Hermans, F. and Pinzger, M. and Deursen, A.: Domain-Specific Languages in Practice: A User Study on the Success Factors, MoDELS 2009 LNCS, Vol.5795, pp.423-437, (2009).
6) Kelly, K. and Pohjonen, R.: Worst Practices for Domain-Specific Modeling, IEEE Software, Vol. 26, no. 4, pp. 22-29, July/Aug. 2009
7) Svendsen, A. Olsen, G., Endresen, J. et al.:The Future of Train Signaling, MoDELS 2008 LNCS, Vol.5301, pp.128-142, (2008).
8) Trask, B. and Paniscotti, D. et. al. : Using model-driven engineering to complement software product line engineering in developing software defined radio components and applications, Proc.
OOPSLA '06 Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications, pp. 846 - 853, (2006)
9) Vokáč, M. and Glattetre, J. : Using a Domain-Specific Language and Custom Tools to Model a Multi-tier Service-Oriented Application — Experiences and Challenges, MoDELS, LNCS 2005, Vol. 3713, 492-506
10) OMG: UML2.0, http://www.omg.org/spec/UML/2.0/ (2005).
11) 川上真澄，小川秀人：デジタル家電ドメインに特化したモデルベース開発環境，情報処理 学会論文誌， Vol.52 No.12，pp3184-3191，2011 12) 川上真澄，大脇隆志，小泉忍：組込みシステムの擦り合わせ型並行開発プロセスに対する モデルベース開発技法の適用，組込みシステムシンポジウム 2009(ESS 2009), 情報処理学会 組 込みシステム研究会，pp.87-92，2009． 13) 川上真澄，吉田敦，磯田定宏：専用ソフトウェアアーキテクチャ型のモデル化効率の評価， 電子情報通信学会論文誌，Vol. J82-D-I No.12，Dec. 1999．
