SRMS のメソドロジー

3.5 SRMS _{のメソドロジー}

本研究では，差分開発に多く適用されているボトムアップ開発の問題点を解 決して，トップダウン開発に移行するためのメソドロジーを提案する．

 ボトムアップ開発とは，上流工程から下流工程へ段階的な詳細化を実施する こと無く，既存のシステムのソースコードを解析することを必然として，次期の システムに必要な要件や制約の多くを得ることによる開発スタイルである．ボ トムアップ開発は，段階的な詳細化を実施しないことから要件定義，アーキテ クチャ設計，システム設計に関連する仕様書などの技術資料が作成・更新され ない場合が見られる．ボトムアップ開発を製品開発の数世代に渡って繰り返す と，技術検討の結果や，適用の目的，意図，理由が共有されずに時間の経過と共 に散逸する．その結果として，設計情報の属人化と，ソースコードだけが既存 のシステムを構成する技術成果物の大勢を占める状況を招く．近年，大規模化・

図3.10 Power Moduleのステート・ダイアグラム

3.5. SRMSのメソドロジー 第 3. 基本方式の提案 複雑化している組込みシステムの開発において，ボトムアップ開発の適用には 多くの弊害が指摘されていることからトップダウン開発への移行が望まれてい る．トップダウン開発とは上流工程から下流工程へ段階的な詳細化を実施する 開発スタイルであり，モデル駆動開発を始めとして開発メソドロジーとして提 唱されている手法の大部分はこのトップダウン開発である．

ボトムアップ開発からトップダウン開発への移行

 ボトムアップ開発からトップダウン開発への移行において重要となる技術 はリバースモデリングである．リバースモデリングによって要件定義やアーキ テクチャ設計に必要な，システムが満たすべき機能や制約，構造を抽出するこ とが可能である．ソースソースコードに対してリバースエンジニアリングを適 用して，その結果をドキュメントに表す手法[70]が提案されている. この手法 を用いることでソースコードから機能や制約，構造に関連する情報を抽出する ことが可能となる．しかしながら，高い信頼性や安全性を求められる近年の組 込みシステムにおいて，機能安全等を立証するための証跡として，ドキュメン トを用いることが十分ではなくなっている．なぜならドキュメントは読み手の 解釈の影響を受けるからである．その解釈は読み手のコンピテンシーに依存す ることから，システムの信頼性を保証するためにドキュメントを用いることは 確実な手段ではない．そのため機能安全の立証には実行可能な形態での成果物 が強く推奨されている．すなわち，検証環境の上で繰返し実行と検証が可能で ある成果物として,モデルの適用が強く推奨されている．

 これらを踏まえてSysMLを用いたリバースモデリング手法とモデル・シミュ レーションを活用する開発メソドロジーを提案する．

 更にリバースモデリングによって既存システムから得られたSysMLのモデル に対して，D-Caseとの関連付けを適用する．その理由は，UMLやSysMLでは 表現できない技術検討の結果，意図などの背景情報，理由，適用の目的を明示的

にD-Caseのモデル要素として記述することが可能であることによる．D-Case

とSysML を連携することにより，長年のボトムアップ開発の適用において重

要視されていなかったにも関わらずトップダウン開発において重要となる背景，

目的，意図，理由をモデルとして表現できる．

3.5. SRMSのメソドロジー 第 3. 基本方式の提案

3.5.1 _{提案する開発フロー}

提案するメソドロジーを実現するための開発フローを(図3.11)に示す．提案 する開発フローは，要件定義(STEP1), リバースモデリング (STEP2), トップ ダウン開発(STEP3)の３つの段階によって構成する．

STEP1 - 要件定義

最初のステップである要件定義においては，既存システムに対する要求を基 にして，システムの要件定義を実施する．システムの実現すべき機能と操作を 明確化するために実現すべき機能とシステムの使用用途を確定する．次に，シ ステムの利用者と操作の関係を明確化する．ここでは，システムの利用者であ るアクターを確定し，システムの操作とシステムの境界を明確にしてユース ケース図（Usecase Diagram）に表す．次にシステムの機能，制約の要求と，そ れらの階層関係を明確化することを目的として，ユースケースから導かれる機 能要求を記述，更にそれぞれの

3.5. SRMSのメソドロジー 第 3. 基本方式の提案

!"#$%&'

()*(' +,-.)/'

01,21,3' )*345678'

9 '

:;<=>?@AB' CD;E1'

)*3' )*345678' FGHEIJ3'

KLM<NIJ3' HEIJ6O3' PQ+,-.'

CRB' KLM1S' FGCTB' UVS1;>U,CT' WX,-1<Y+V3'

Z[\]^_' `abcdef'gh#$%&' WfZd_ijdbk(' $%&'

lm'nbojip^'nbojip^' qrstB' uv+12V,'%wU,CDB' %1S;E1'

HEIJ6O3' FGHEIJ3'

KLM<NIJ3' lm'lm' :1,x1y'

!"#$%&'gh#$%&'

+,-.@A'CRB' KLM1S' :;<=>?@A' CD;E1'FGCTB' UVS1;>U,CT' z{|A' :1,x1y'

Z } ~ • Ä ' Z } ~ • Å' Z } ~ • Ç '

ÉÑ' +,-.)/'

図3.11 リバースモデリング手法とモデル・シミュレーションを活用する開 発メソドロジー

3.5. SRMSのメソドロジー 第 3. 基本方式の提案 機能要件に対して，要求から導き出される操作性，性能，信頼性等の制約や条 件を網羅的に列挙する．また要求相互の関係を付加する．この段階では既存シ ステムの制約や構造が反映されていないことから，要求図は未完成の状態であ る．未完成部分は次のステップであるリバースモデリングの結果から情報を得 る．

STEP2 - リバースモデリング

リバースモデリングが２番目のステップである．提案する開発フローにおい て用いるリバースモデリングには静的解析の結果を用いる．動的振舞解析の結 果を用いるリバースモデリングの結果として得られるモデルは，要件定義やアー キテクチャ設計の工程において品質の検証に有効である．そのモデルは抽象度 が高いことから，アーキテクチャ設計の最初の工程に用いて段階的な詳細化の 出発点として活用することが可能である．しかし，動的振舞解析の結果を用い ることからシステムの詳細な構造や，モデリングの際に捨象された情報が含ま れていないことから，段階的な詳細化の出発点にその利用が限定される．そこ で提案する開発フローでは，段階的な静的解析によってリバースモデリングを 行い，SysMLのモデル群を作成する．この際に重要な点は以下の3点である．

(i) 最下層となるソースコードもしくは実装モデルはそのままincludeする

(ii) SysMLの言語仕様に則ってリバースモデリングを適用する

(iii) 提案する順序に従ってリバースモデリングを実施する

最下層となるソースコードや実装モデルをそのままincludeする理由は，それ らが既存のボトムアップ開発において重要かつ数少ない技術資産である．しか しそれらが長年の開発によってブラックボックス化してることも考えられるこ とから，これらに手を加えることなくメソドロジーを構築することは差分開発 において極めて重要であることがその理由である．

 SysML の言語仕様に則ってリバースモデリングを適用する理由は，静的解

析によって得られたデータをモデルに表現するための内容と範囲を明確に区 別することである．リバースモデリングで用いるSysMLのモデルは，要求図

（Requirement Diagram)，ブロック定義図(Block definition diagram)，内部ブ

3.5. SRMSのメソドロジー 第 3. 基本方式の提案 ロック図(Internal block diagram)，パラメトリック図(Parametric diagram), ステートマシーン図(State Machine diagram)の5種であるが，それらのモデ ルの言語仕様に従ってリバースモデリングを行うことで，モデル間相互での重 複や誤った対象のモデルに対して，静的解析の結果として得られた情報を付加 する可能性を低くできる．

 提案する順序に従ってリバースモデリングを実施する理由は，効果的にリ バースモデリングを実施するため，加えてモデル間相互での重複や誤った対象 のモデルへの情報の付加をおこなわないためである．本研究においてはまず，

システムの構造を明らかにする．次にその構造の詳細化を行った後で，各モデ ルに必要な情報の抽出を実施する．提案する順序を以下に示す．

 まず対象となるシステムの構成，ハードウェア構成を示すドキュメント等か ら，システム構成を表すシステム構成図(Block definition diagram)を作成する．

次にソースコードを参照して離散系モデルであるステートマシーン図 (State Machine diagram)と連続系モデル(Discrete-time model)を作成する．連続系

モデルはSimulink model[74]に代表されるモデルであり，自動車の制御関連の

ソフトウェア開発に多く用いられている．

内部ブロック図はシステムの内部構成を表すモデルであり，ブロック定義図を 詳細化し，各構成要素に対して離散系のモデルと連続系のモデルをそれぞれ

Includeする．離散系もしくは連続系の実行可能なモデルをIncludeすることで

モデル群はシミュレーション・フレームワーク上で実行可能となる．よって，シ ミュレーション・フレームワークはSysMLモデルに加えて，離散系もしくは連 続系のモデルの実行環境が必要である．

パラメトリック図は制約や前提条件に関連するパラメータや数式を表すモデル である．内部ブロック図の各要素が持つパラメータや数式で表すことが可能な アルゴリズム，モデル要素間のインターフェイス求められる性能や帯域に着目 してパラメータを抽出することでパラメトリック図を作成する．

要求図はステップ１で作成した未完成のモデルであり，不足している情報はシ ステムの構成からもたらされる制約と，パラメトリック図からもたらされる制 約や制限である．システムの構成に関する情報はブロック定義図と内部ブロッ ク図から抽出する．システムの制約はパラメトリック図から抽出する．それら の抽出された情報を要求図にマッピングすることで要求図が完成する．また，

それぞれに関連のモデル要素は，各段階において関連付けを行う．