モデル駆動開発 - SWEST · 開発スタイルの変化: モデル駆動開発以前以降分析設計テスト 16 モデルコンパイラが設計時は製品ドメインの知識を

©2014 Shintaro Hosoai

２

モデル駆動開発細合晋太郎

本資料は，前年度のモデル駆動開発（久住准教授）の資料を一部利用させて頂いております．

http://creativecommons.org/licenses/by-sa/3.0/deed.ja



２組込みシステム開発の現状(1)組込みソフトウェア開発の危機

2

組込みソフトウェア技術者数の指数的増大

2004 2006 年2005 2007 2008 2009

60

40

20

技術者数（万人）

不足数

技術者供給

技術者需要

開発手法改善

出典：経済産業省組込みソフトウェア産業実態調査(2006年度版)

100M

50M

1995 2000

オブジェクトサイズ

年

情報家電：ＴＶ

携帯電話

出典: 組込みソフトウェア開発力強化推進フォーラム(2004年6月)

日経エレクトロニクス 2000 9-1(no.778) をベース

組込みソフトウェア開発量の指数的増大

自動車：カーナビ

100M

50M

1995 2000

オブジェクトサイズ

年

情報家電：ＴＶ

携帯電話

出典: 組込みソフトウェア開発力強化推進フォーラム(2004年6月)

日経エレクトロニクス 2000 9-1(no.778) をベース

組込みソフトウェア開発量の指数的増大

自動車：カーナビ




２組込みシステム開発の現状(2)

3

61.9%!!

開発コスト！




２組込みシステム開発の現状(3)

4

ソフトのテストがたいへん

(たぶん)ソフトのテストが

システムテストにまで影響している

61.9%!!




２ソフトウェアとモデリング

• ソフトウェアは超複雑．

• 100万行のコードだと，単純換算で400pの文庫本×100冊．複数人で一切の誤字なく，不整合なく，書き上げる必要がある．

• コードだけ見て全体の関係や流れを把握するのは難しい．というか無理．

• 様々な観点と抽象度からソフトウェアを分析・整理することが必要

5




２観点と抽象度（１）

6

合意が取れているつもりでも，そのままコーディングすると，

ヒアリング

開発会議

顧客




２観点と抽象度（２）

7

要求はなに？

全体の構造は？

どうやりとりする？

具体的な構造は？

・ユースケース・要求図

・パッケージ図・構造図

・コミュニケーション・アクティビティ

・オブジェクト・クラス

具体的な振舞いは？

・シーケンス・ステートマシン

複雑でモヤっとした要求を様々な観点と抽象度で分析




２UML図

• ソフトウェア開発で使いやすい図をまとめたもの．

• すべての図を使う必要はない．

• 観点と抽象度の枠組み

• 個人のスケッチレベルであれば，好きに描いてよい．

• 複数人での開発であれば，表記ルールは守ること．（共通言語の意味がなくなる．）

• ステークホルダーの合意が取れているのであれば，独自形式でもよい．ー＞DSLなど

8




２モデルとコードの乖離

9

要求はなに？

全体の構造は？

どうやりとりする？

具体的な構造は？

・ユースケース・要求図

・パッケージ図・構造図

・コミュニケーション・アクティビティ

・オブジェクト・クラス

具体的な振舞いは？

・シーケンス・ステートマシン

コード

コードレベルで修正

不整合

手動でコーディング




２モデルからコードへの変換〜人間が実行

• クラスのソースコードへの変換を考えると・・・• 決まりきったソースコードのパターンがある

10

モデル要素ソースコード

クラス構造体

属性構造体のメンバ変数

操作関数

struct Tracer {int is_tracing;

};

void do_trace (void) {…

}

クラス→構造体

属性→メンバ変数

操作→関数

操作の中身については未定義




２モデルからコードへの変換〜コンピュータが実行

• 決まり切ったパターンがあるならば、コンピュータに実行させることができるのでは？• 人間が行う「実装のパターン」を「変換ルール」としてとらえる

• 「変換ルール」が十分に形式的 (= プログラムにできる)であれば、機械化できる

• 「変換ルール」が汎用的ならば、再利用できる

• どこかで聞いたことのあるような話のような・・・。

11

モデル

ソースコード

変換ルール

モデルコンパイラ




２モデルの抽象度と生産性

12

アイデア製品

解決すべき問題を整理

アセンブラ

コード

UMLモデル

設計・実装

設計・実装

設計生成 or 実装

コンパイル




２モデルを動作させてテスト

• 設計段階で動かすことはできないか？• 実装する前にモデル上で振る舞いをシミュレーションしてテストでき

れば、問題の早期発見につながる• 実装を待たなくてもテストが可能

• 形式的な(= コンピュータが解釈可能な)モデルを利用

13




２従来型開発とモデル駆動開発の比較

•従来型開発 (aka ソースコード中心の開発)• 要求仕様書、設計文書をもとにソースコードを開発

• 上流での要求仕様書や設計文書の正しさを担保するのはレビュー

• 実際の製品の品質保証をするのは「テスト」• 開発の半分以上がテスト・・・

• 要求仕様書・設計文書とソースコードの一貫性を保つのは困難

•モデル駆動開発• 要求レベル、設計レベルのモデルを作成

• モデルから（ある程度は）自動的にソースコードを生成

• 上流での検証が比較的容易• 機械可読なモデルがあるのでシミュレーションが可能

• 自動的にソースコードを生成するので、モデルとコードの一貫性保持が容易

14




２開発スタイルの変化: モデル駆動開発以前

分析設計実装テスト

15

不具合を見つける度に、設計、実装、テストを「手動で」回さな

ければならない！

製品ドメインの知識実装ドメインの知識

開発者は両者ともに必要




２開発スタイルの変化: モデル駆動開発以前以降

分析設計テスト

16

モデルコンパイラが設計から自動コード生成設計時は製品ドメインの知識を

実装ドメインの知識は「ルール」として与える

関心の分離ができる！

モデル上で動作させて問題の早期発見ができる




２モデルの様々な利用方法

•スケッチとしてのUML•コミュニケーションの道具

•設計図としてのUML•設計 → スケルトン生成•コードの可視化

•プログラミング言語としてのUML•コード生成•シミュレーションによる検証

17




２モデルからコードへの変換〜様々なレベル

•コード生成（というかモデリング）には構造と振る舞いの両面が必要

•クラス図などからスケルトンコードの生成• 詳細な振る舞いはソースコード中に手で記述

• →簡単に出来そう。一貫性保持が困難。

•クラス図にコード断片を埋込みコード生成• 振る舞いはコード断片の形でクラス図に埋込み

• 完全なコード生成が可能

• →抽象度が上がっていない。

•クラス図とステートマシン図からコード生成• 構造はクラス図、振る舞いはステートマシン図で記述

• より詳細な振る舞いはコード断片としてステートマシン図に埋込み

• 完全なコード生成が可能

18




２様々なモデルの利用

19

コード

製品

コード

製品

モデル

コード

製品

モデル

コード

製品

モデル

コード

製品

モデル

コードのみモデルが乖離リバースモデリング

ラウンドトリップモデル駆動




２FAQ

•性能が大幅に低下するんじゃないの？• ほとんど性能低下はありません。

• Cでの記述とほぼ同等の性能が得られます。

• パレートの法則。

•メモリを無駄に消費するんじゃないの？• 確かに増えますが大規模ではほとんど問題になりません。

• たいてい同様のコードを手でコーディングしてます。

• 大規模開発では手でのコーディングよりもサイズダウンという事例もあるようです。

• 小規模開発にはちょっときついかもしれません。

•デバッグはできるの？コンパイラのバグに対応出来るの？• 手でのコード開発とほぼ同等の可読性が得られます。

• MDDしている8割の会社はモデルコンパイラに手を入れてません。

20




２

64© 2010 Mentor Graphics Corp. Company Confidential

www.mentor.com64

Memory

MDD

ROM ROM

ROMRAM RAM

RAM

Legacy Bridge Point

100,000

200,000

300,000

byte

(dynamic)(static)

Legacy Bridge Point

ROM 57,232byte 62,071byte 214,289byte

RAM(static) 1,176byte 12,676byte 1,934byte

RAM(dynamic) approx. 45,000byte

21© MentorGraphics




２MDDに利用できるツール

• Clooca

• BridgePoint• Executable UML、組込み向けの高品質コード生成

• クラス図、ステートマシン図、アクション言語による完全なるMDD

• Enterprise Architect• Professonal版:コード埋込みクラス図

• Ultimate版: コード埋込みクラス図/ステートチャート図

• 体験版あり

• Rhapsody• コード埋込みクラス図/ステートチャート図

• Astah• コード生成プラグインを利用

22




２

コード生成の仕組み

23




２Astah Plugin

• AstahはPluginを作成することで，独自に拡張可能

• 今回は，Astah用のコード生成プラグインを作成しました

24http://astah.change-vision.com/ja/plugin-tutorial/




２Astah m2t

25

AstahAstah m2t

Groovy Engine

Groovy Template

Engine

Code Template

UMLモデル（クラス・

ステートマシン）

プラグインで，Astahで記述したモデルを抜き出して，Groovyのテンプレートエンジンに流し込んでるだけ

コード

なんでGroovy?Astah Pluginは通常Javaで作成する．このため提供後はプラグイン機能を変更できない．モデル変換やコード生成のためのあれやこれやは，ドメインに応じて変更が必要なため，スクリプトを実行時評価したかった．JVMスクリプトならなんでもよかった．




２コード生成の仕組み

26

クラス

ステートマシン

クラス

ステートマシン

クラス

.ino・下記CPPクラス

の初期化と，メインルーチン

.ino(Arduino)用テンプレート

.h用テンプレート

.cpp用テンプレート

.h・下記.cpp用ヘッダ

.cpp

・クラス・メソッド定義とステートマシン定義

include

include

クラス名，関数

クラス名関数

ステートマシン定義

モデルテンプレートコード




２ステートマシンのコード

27

//.inoClass clazz; //各クラスのインスタンス生成setup(){}

loop(){//各クラスの状遷移clazz.transition();//各クラスのアクションclazz.doAction();

}

//.h普通のクラス定義＋enum{状態の定義}，{イベント定義}

//.cppClass::transition(){

switch(state){case 状態名:

if(event & gurad){state = 次状態;

}...}Class::doAction(){

switch(state){case状態名:

action();...}

}




２モデル変換の基盤

•メタモデル• モデルの性質を表現したモデル

• クラス図、etc.

• モデルの文法を定義するために使用する• モデル中の要素、それらの関係を定義

• モデルの要素をクラス図で表現したもの• メタモデルのインスタンスが，モデル

•メタモデルとモデル• クラスとインスタンス

• メタモデルとモデル

28




２モデル変換の基盤

モデル階層具体例

モデル

メタモデル

29




２

呼出

手書きソースコードの関数宣言群

コード生成の仕組み1

30

モデル

手書きソースコードの関数宣言群

モデルから生成されたソースコード

手書きのソースコード

外部公開関数群

イベント外部公開関数群

呼出

モデルの世界コードの世界

手書きソースコードが提供する関数の宣言をモデルの世界に教える

変換ルール

モデルコンパイラ




２

Further more

31




２Further Moreモデル地図

32

ドメイン特化度合い

アーキテクチャ記述制御工学（モデルベース）言語理論

SysML

UML

MARTE

MATLAB/SimulinkModelica, ...

自プロジェクト開発ドメイン特化言語 / モデル

(モデル駆動)

状態遷移図・表




２Further Moreモデル地図

33

ドメイン特化度合い

(抽象度?)

アーキテクチャ記述制御工学（モデルベース）言語理論

SysML

UML

MARTE

MATLAB/Simulink

自プロジェクト開発ドメイン特化言語 / モデル

(モデル駆動)

状態遷移図・表

システムの全体像を把握して，解決策を探るシステムの離散的な振る

舞いをモデル化する

システムの連続的な振る舞いをモデル化する

ドメインの用語で要求をモデル化する

モデル駆動開発(MDD; Model Driven Development)

モデルベース開発(MBD; Model Base Development)

ドメイン特化型開発(DSD; Domain-Specific Development)




２Further Moreモデル駆動開発の守破離

•守•既存のツール・文法を使って仕事をする

•破•依然、既存のツール・文法を利用しているが、自分たちの分野で使い易いようにカスタマイズする

•離•自分たちの分野で利用しやすい独自言語を定義して、ツールを開発する

34

モデル駆動開発を開発出来るのは，モデル駆動研究者でなく，そのドメインのスペシャリスト



Documents

モデル駆動開発 - SWEST · 開発スタイルの変化: モデル駆動開発以前以降 分析 設計 テスト 16 モデルコンパイラが 設計時は製品ドメインの知識を

モデル駆動開発 - SWEST · 開発スタイルの変化: モデル駆動開発以前以降分析設計テスト 16 モデルコンパイラが設計時は製品ドメインの知識を