つながる世界の安心で安全な ソフトウエアのテスト4...
TRANSCRIPT
つながる世界の安心で安全なソフトウエアのテスト
© 2018 LDRA Ltd
1
https://www.fuji-setsu.co.jp/
セキュア(安心)なソフトウエアは脅威への防御のために、高品質でなければならない。そして高品質のソフトウエアを構築するために必要な同じ開発ライフサイクルの厳格さが要求される。
そこで航空システムのソフトウェア安全規格に精通する検証支援ツールが、セキュリティ品質を確保するためにも活用され「Swiss Cheeseモデル」の防御の一翼を担うことや、要件トレーサビリティがメンテナンスの要になることを紹介する。
概要
2
▪独語ではSecurity も Safety も
Sicherheit (ズィッヒャーハイト)
▪日本語では安心やセキュリティなど、安全とは分けて表現されるが、モノがつながる時代に区別することはできない
▪セキュリティの脆弱性が、安全上の潜在的な脅威なら、機能安全の範疇で考慮される
Security と Safety について
http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
3
このような事態は様々な領域で、、
http://www.bbc.co.uk/news/technology-15817335
http://www.bbc.co.uk/news/technology-30575104
http://www.computerworld.com/article/2473402/cybercrime-hacking/pacemaker-
hacker-says-worm-could-possibly--commit-mass-murder-.html#tk.drr_mlt
https://www.wired.com/2016/11/sf
s-transit-hack-couldve-way-worse-
cities-must-prepare/
上水道インフラ
プラントの溶鉱炉
交通機関
ペースメーカ
4
▪仮に機能安全が求められていない製品であっても、つながる世界で他への攻撃の踏み台にされるようではブランド価値の低下を免れない
Internet of Things and Services
https://www.informationweek.com/government/leadership/internet-of-things-8-cost-cutting-ideas-for-government/d/d-id/1113459
5
脆弱性とは
情報セキュリティ早期警戒パートナーシップガイドライン - IPA
• 脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、その機能や性能を損なう原因となり得るセキュリティ上の問題箇所
https://www.ipa.go.jp/security/ciadr/partnership_guide.html
国民のための情報セキュリティサイト - 総務省
• 脆弱性とは、コンピュータのOSやソフトウェアにおいて、プログラムの不具合や設計上のミスが原因となって発生した情報セキュリティ上の欠陥のこと
http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/risk/11.html
6
Thinking Safety vs Security
Understanding Quality and Security
Wifi接続されるヘッドユニットへのパスワードを解読して侵入
ヘッドユニットにつながるCANバス上のコントローラのファームウエアを変更（権限が不要であった）
CANバス上のコンポーネントを制御下に
7
・高品質であるとしても必ずしもセキュアなソフトウェアとは言えない
・セキュアなソフトウェアは現在知られているあるいは将来の脅威への防御のために高品質でなければならない
・高品質のソフトウエアを構築するために必要な同じ開発ライフサイクルの厳格さを要求する => プログラムの不具合や設計上のミスを排除
航空業界標準：LDRA社テストツール
コーディングスタンダードチェック
コード品質の尺度
カバレッジ解析
データフロー、コントロールフロー解析
単体テスト
統合テスト要件トレーサビリティ
テストの管理 認証プロセスの支援
最も厳密なことで知られる航空業界のDO-178スタンダード認証に標準的に採用されるテストツールの各種機能が防御の一翼を担う
8
The Swiss Cheese model…
• セキュアブートにより正しいイメージが
ロードされる（不正な改ざんを検知）
• ドメイン分離でシステムのクリティカル
な領域を保護
• 最小限の権限 (Least Privilege) の設計原
則で脆弱性を最小限に抑える（Multiple
Independent Levels of Securityのコアとなる原則）
• 攻撃対象領域を特定して最小限に抑える
• セキュアコーディング標準
• セキュリティテスト
And after release
• 新たに発見される脆弱性に対処するため
のレスポンシブなメンテナンスプロセス
https://www.ncbi.nlm.nih.gov/pmc/
articles/PMC1117770/
セキュリティへの単一解は無く複数の対策（多重防御）が施される
スイスチーズモデル：事故は多重防護壁の穴をすべて貫通したときに生じるというもの。穴は潜在的にも存在するし、即発的にも発生する。
事故を防ぐには穴の有無を常に監視し、発見したら直ぐに塞ぐ必要がある
アクセスが困難で脆弱性が最小限に抑えられるように、コード自体が安全であることが重要
9
▪ハイパーバイザーなど仮想化による分離は有効な防御策
ではあるもののセキュリティを保証する完全策ではない
▪ハイパーバイザードメインの分離は、仮想化を実装するプロセッ
サー（IntelのVT-xやArmの仮想化拡張など）に制限される
▪ DMAエンジンやGPUなど、システム内の他のバスマスタは、ハイ
パーバイザによって提供される保護をバイパスできる
▪分離されるドメイン間の通信にアプリケーションコードが必要
Separation Technologies are just one slice of “Swiss Cheese”!
10
Secure Application Code
防御技術にかかわらず、アプリケーションはシステムの重要な役割を果たす
安全性が求められる領域は、よりセキュアなコードの必要性が高まる
システムへの全てのアクセスがドメイン分離によって保護されるわけではない
セキュアなコードは防御に
必要不可欠
11
Code Reviews
– Secure Coding
12
Coding Standards
ソフトウェアの欠陥の約80％は、言語の約20％の誤った使用によって引き起こされる
言語の使用を制限することで、問題のあることが分かっているサブセットを避けることができるなら、ソフトウェアの品質は大幅に向上する
未規定の動作 / 未定義の動作
処理系定義の動作 コーディングエラー
ランタイムエラー13
Common Weakness Enumeration -CWETM
14
▪共通脆弱性タイプ一覧 https://cwe.mitre.org/
National Institute of Security Technologyの調査によると、ソフトウェアの脆弱性の64％はプログラミングエラーに由来する。 CWEプロジェクトは、ソフトウェアの欠陥をより深く理解し、その欠陥を特定、修正、防止するための自動ツールを作成することを目的とする。 CWEの共通脆弱性リストは、米国国土安全保障省の国家サイバーセキュリティ部門が共同で主催するソフトウェア保証戦略イニシアチブの一環として作成される。
共通脆弱性タイプ一覧CWE概説 https://www.ipa.go.jp/security/vuln/CWE.html
14
▪JPCERT/CCに日本語版公開https://www.jpcert.or.jp/sc-rules/
▪CERT’s Top 10 Secure Coding Practices
IPAのセキュア･プログラミング講座（P12~）
https://www.ipa.go.jp/files/000059838.pdf
▪By Robert C. Seacord
CERT® セキュアコーディング
15
DARPA(《米》国防総省国防高等研究事業局)が中心となってカーネギーメロン大学内に設置されたCERT/CC (Computer Emergency
Response Team/Coordination
Center) により公開
CERT’s Top 10 Secure Coding Practices
https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices16
1. 入力を検証する2. コンパイラの警告に注意を払う3. セキュリティポリシーのための設計4. シンプルを維持する5. 拒否をデフォルトにする6. 最小権限の原則に従う7. 外部に渡すデータを無害化する8. 多重防御を行う9. 効果的な品質保証テクニックを使う10. セキュアコーディング標準を採用する
問題のあるコードをツールで自動検出
17
CERT 対応で他を圧倒！
システムワイドにコントロールフローとデータフローを解析できることが優位性のひとつ
MISRA C:2012 /AMD1/ADD2
MISRA C:2012 Addendum 2
ISO/IEC TS 17961:2013 の「Cセキュアコーディング」に対するMISRA C:2012のカバレッジ
x46 の C SecureルールのどれがMISRA C:2012のガイドラインの対象であるかを示す
MISRA C:2012 Amendment 1
ISO C セキュアガイドラインへのカバレッジを強化する14の新しいCコーディングルール
特に「信頼されていないデータの使用」というセキュリティ上の脆弱性に付き物の具体的な問題へ取り組む
セキュアでないコーディングの例https://www.fuji-setsu.co.jp/files/MISRA_C_2012_AMD1.pdf
19
MISRA C:2012 Amendment 1 違反を自動検出
このルールは、ハッカーが巧妙に作成したメッセージを使って、クリアテキストで保存されたパスワードを含むデータを、インターネット経由で抜き取ることができるHeartbleed型の脆弱性に対する保護となる
20
▪ IPA/SECの組込みソフトウェア開発向けコーディング作法ガイド ESCR［C言語版］Ver.3.0 の発刊
～セキュアコーディングへの対応～
IPA ESCR
22
Coding Standards Models
22
リスクベースのアプローチ
23
Building Security into the SDLC
System Design
Architecture
Design
Acceptance
Testing
System
Testing
Integration
Testing
Coding
Module DesignUnit Testing
Requirements
静的解析は実装の早期段階から行うことで費用対効果を最大化:
- 潜在的な脆弱性やエラーを事前に排除- テスト容易性を高めてV&V作業工数を最適化
24
Code Reviews
– Keep it simple
– Use effective
quality assurance
25
可読性が低下して脆弱性が奥に潜んでしまう
テストは容易で無くなり余計な作業が必要
保守性が低く新たな脆弱性への迅速な対応が困難
複雑さがもたらす問題
26
コード品質を自動解析
可読性
メンテナンス性
テスト容易性
27
コントロールカップリング
System Callgraph 関数間の相互関係を視覚化
Extended Control Coupling Graph 特定関数にフォーカス
28
フローグラフ
• フローグラフ内のブロックやブランチに該当するコード領域をハイライト表示
29
Static Callgraph – デッドコードの検出
30
Test Coverage
31
▪ Entry points coverage
▪ Statement coverage
▪ Branch decision coverage
▪ Modified Condition / Decision Coverage (MC/DC)
▪ Data coupling and control coupling coverage
▪ Object code coverage
▪ Linear Code Sequence And Jump coverage (LCSAJ)
▪セキュアコーディングの実践により「防御的」ソフトウエアを得られたとして、それが動作することをテストする必要がある
▪そのテストの十分性は？
▪安全性レベルに応じた各種カバレッジレベルに対応
テストのカバレッジ
32
CWE-912 隠れた機能
https://cwe.mitre.org/data/definitions/912.html
http://jvndb.jvn.jp/ja/contents/2015/JVNDB-2015-006032.html
隠れた機能は、アプリケーションの攻撃面を増加させ、意図した機能を弱体化させかねない
対策として、構造化カバレッジにより、実行されていないソースコードを検出することによって隠された機能を突き止めることができる
33
▪一般に、例外的な処理をするコードは十分にテストされていない可能性が高く、めったにない条件下で、安全性やセキュリティの問題を引き起こすことになる
▪例えばポインタがNULLでない場合など、ディフェンシブなプログラムはシステムテストでは確認できない
▪この例で100％カバレッジを満たすには単体テストによる評価が必要
100％テストカバレッジの重要性
34
Importance of Structural Coverage
HLT_0001
HLT_0001
…..
HLT_000m
HLR_0001
HLR_0002
…..
HLR_000n
LLR_0001
LLR_0002
…..
LLR_000n
LLT_0001
LLT_0001
…..
LLT_000m
35
あらゆるターゲット環境に対応
ロータバッハ社デバッガはハイパーバイザOSにも対応済みhttp://www.lauterbach.com/frames.html?hypervisor_j.html
36
あらゆるターゲット環境に対応
37
Keil uVision5 ARM の µVision® Debugger にも対応
MC/DC テストケース解析
MC/DC 100% に必要なテストケースをレポート
38
• 関数内のパス密度：メンテナンス性の尺度
• 到達不能やテスト不能なパスを検出
• 最も厳しいカバレッジ基準（欧州の空軍関連や原子力関連で要求される）
Linear Code
Sequence
And Jump
LCSAJ (Linear Code Sequence And Jump)
39
▪Consider this example code:
LCSAJ
40
▪２つのテストケース実行でステートメントカバレッジとブランチカバレッジを100％にできる
これで十分にテストされていて、安全といえるか？
100% Statement & Branch Coverage
41
▪ステートメントとブランチカバレッジは100％満たされたが、まだ実行されていない2通りのパスが存在する
▪そのうちの１つはゼロ割
NO!
42
オブジェクトコードレベルカバレッジの要求
DO-178B/C Object Code Verification
43
Object Code Coverage
• アセンブラレベルのフローグラフから、追加テストが必要な未実行領域（青色）がわかる
• コードが要件通りで、それ以上でも以下でもないことを明確にすることでデッドコードが無いことや機能不足が無いことの証明
Assembler CodeSource Code
44
DO-178C section
6.4.4.2 c states:
“Analysis to confirm that the
requirements-based testing has
exercised the data and control coupling
between code components”
Control coupling coverage は関数のすべての呼び出しが実行さ
れていることを保証
Data coupling coverage はデータへのすべてのアクセスが確実に実
行されていることを保証
Data and Control Coupling Coverage
45
要件ベースのテストがコードコンポーネント間のデータと制御の両方の結合を実行したことを確認するための分析
コントロールカップリングカバレッジ
多くのスタンダードで関数間の呼び出し関係も確認することが要求される46
変数が何処でどのように使用されたかを動的解析できる
データカップリングカバレッジ
47
Robustness Testing
http://jvndb.jvn.jp/ja/cwe/CWE-78.html (日本語)
対策として、ロバストネステスト(頑健性のテスト)や、フォールトインジェクション(エラーをわざと起こすテスト)等、多種多様な入力を持つ膨大なテストケースを使用してソフトウェアを分析する、動的なツールや技術を用いて検出することが可能
OSコマンドインジェクション
48
Robustness Testing ：テストケース自動生成
IEEEは「堅牢性」を「無効な入力やストレスの多い環境条件が存在する場合にシステムまたはコンポーネントが正しく機能する程度」と定義
49
Test for
Security
Requirements
50
要件トレーサビリティ
Security Requirements
Safety Requirements
すべての機能、安全およびセキュリティの要件が正しく実装され検証されることを保証するメカニズム
要件にはないコードの存在が欠陥や脆弱性の原因になることは多い。利用されないなら削除されるべき
双方向のトレーサビリティにより、すべての要件を満たすためのコードが存在することが保証される
51
Bonus Secure Coding Practices
https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices52
セキュリティ要求を定義する
▪開発ライフサイクルの早期段階でセキュリティ要件を特定し文書化して、後続の開発成果物がそれら要件に従っていることを評価する。セキュリティ要件が定義されない場合、そのシステムのセキュリティを効果的に評価することはできない。
脅威をモデル化する
▪脅威をモデリングすることで、ソフトウェアが受ける脅威を予測する。脅威のモデリングでは、主要な資産の特定、アプリケーションの分類、各資産またはコンポーネントへの脅威の特定と分類、脅威をリスクレベルで格付け、そして脅威を緩和するための戦略を、設計・コード・テストケースで実装する。
Bonus Secure Coding Practices
https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices53
要件トレーサビリティ
要件
設計
コード
テスト
システム要件から、ソフトウエア要件、設計、ソースコード、テストケースに至るリンク 54
動画デモhttps://www.fuji-setsu.co.jp/demo/WindRiverLDRA/diabPPC2.html
要件 => ソースコードをマップ
55
安全性レベルに応じた検証プラン
56
要件に割当てられた検証タスクを直接実行
57
要件～テスト結果のトレーサビリティを確保
要件にマップされたコードの単体テスト実行やテストカバレッジの検証タスクが満たされる
58
Traceability Reports
System Requirements
Software Requirements
Design Requirements
Source Code Test Cases 要件トレースはシステムが要件通りで、それ以上でも以下でもないことを明確にする最善策。デッドコードが無いことや機能不足が無いことを証明。
59
Maintenance
60
Secure Application Maintenance Phase
つながる世界の安心で安全なソフトウエアには終わり
がない
脆弱性が見つかるたびにコードや要件の変更を強い
られる
どのような危険にさらされているのか？コードを再テストする必要があるか？
Automated
Bi-
Directional
Traceability
is KEY!
各開発フェーズ間のトレーサビリティを取ることで、問題を特定し、迅速かつコスト効率良く対処できるようになる
61
Automated Bi-Directional Traceability
要件～コード、テストまで変更のインパクトを成果物間で追跡
62
CI(継続的インテグレーション)でテストを自動化
• コマンドラインインターフェイスで、
静的解析、単体テストの実行、カバレッジ解析等を自動化
• 継続的インテグレーション（Jenkins 等）に統合
テスト実行用のバッチファイル
63
CI(継続的インテグレーション)でテストを自動化
▪全てのレポートが、
Jenkins のワークスペースからアクセスできる
64
まとめ
65
セキュリティを組み込む
セキュリティ対策に単一解
は無い
防御技術にかかわらず、アプリケーションはシステムの重要な役割を果たす
つながる世界の安心で安全なソフトウエアには、多重防御が必要
セキュアなコードはスイスチーズモデルの防御に不可欠
66
トレーサビリティ
双方向のトレーサビリティは機能安全スタンダードの要件
変更のインパクトを成果物間で双方向に
追跡
全ての要件が正しく実装され検証されることを保証するメカニズム
新たな脅威への取り組みを支援
67
▪静的解析：コーディングスタンダード準拠、コード品質のメトリクス▪ MISRA 、CERT C、IPA/SEC ESCR 等各種サポート。ユーザ定義ルール集も編集できる▪ コードの視覚化（コールグラフ、フローグラフ、クロスリファレンス）
▪動的解析：構造化カバレッジ▪ 関数コール、ステートメント、ブランチ、MC/DC 、LCSAJ (path coverage).
▪ アセンブラレベルカバレッジ (DO-178C Level A)
▪ あらゆる組込みコンパイラ、実行環境をサポート
▪単体テスト（Unit/low-level testing）▪ テストハーネス、スタブ、グローバル宣言などの自動生成▪ 堅牢性テストのためのテストケース自動生成
▪データフロー・コントロールフローの静的・動的解析▪ DO-178C で認定可能な唯一の汎用ツール
▪要件トレーサビリティに検証実行・オブジェクティブ管理を統合
▪ツール認定キットを提供（DO-178Cに必要）
▪ TUVの事前認定
各機能が有機的につながる
https://www.fuji-setsu.co.jp/products/LDRA/68
開発ライフサイクルにわたる検証作業を支援
69
RequirementsTraceability
TBmanager®
IBM® Rational®
DOORS®
Polarion ALM,ReqIF,
MS Word & Excel
Requirements
Analysis &
Specification
Static AnalysisQuality Metrics
Coding Standards ComplianceTBvision®
Automated Unit TestingTBrun®
TBeXtreme®
Programming standards checking and metrication
TBvision®
Detailed
Software
Design
Coding
Acceptance &
Maintenance
Software
Integration
Unit
Module
Test
Model Based Development
IBM®
Rational®
Rhapsody®
Mathworks SimulinkEsterel SCADE
Test VerificationLDRA Testbed®
Integrated and Model Driven TestingTBvision®
Compliance Management
スタンダード認証取得を目的に広く採用
70
航空システム 防衛システム 医療機器
産業機器電力プラント
鉄道システム 車載システム
LDRA 社は各種国際スタンダードに貢献
71
Professor Mike Hennell
Bill St Clair Andrew Banks
Member of SC-205 / WG-71 (DO-178C) formal
methods subgroup
Member of MISRA C committee and MISRA
C++ committee
Member of the working group drafting a proposed secureC annex for the C
language definition (SC 22 / WG14)
Member of SC-205 / WG-71 (DO-178C) Object
Oriented Technology subgroup
MISRA Committee Chair
Committee Member for Second Edition of ISO 26262
Chair of BSI IST/15/-/26
for Software Testing
MISRA representative to BSI IST/15 for Software and
Systems Engineering
Member of BSI IST/15-/20 for
Bodies of Knowledge and
Professionalization
LDRA 社は各種国際スタンダードに貢献
72
Dr Clive Pygott Liz Whiting Chris Tapp
Member of ISO software vulnerabilities working group (SC 22 / WG 23)
Member of MISRA C++ committee
Member of the working group drafting a proposed secureC annex for the C
language definition (SC 22 / WG14)
Member of MISRA C committee language
definition
Chairman of MISRA C++ committee
Member of MISRA C committee language
definition
LDRA Overview
ISO 9001認証取得
1975年設立 => 40年以上の実績とブランド
IEC 61508, IEC 62304, EN 50128,
ISO 26262, IEC 60880 のツール認定取得
スタンダード認証プロセスを支援する
ソフトウエアテスト、管理支援ツールを提供
各種スタンダード委員会に貢献
e.g. DO-178C,
MISRA C/C++, CERT
Liverpool
73
その他のソリューション
コンパイラのテスト
ドメインスペシフィックモデリング
定理証明とテスト入力と期待値の自動生成
74
形式手法による仕様・設計の定理証明と
テスト入力と期待値の自動生成
https://www.fuji-setsu.co.jp/products/T-VEC/
Copyright © 2017 T-VEC Technologies, Inc.
スマートカードの事例
Test Driver
mapping
schema
Interfaces for Personal
Identity Verification
T-VEC Tabular Modeler
Test Vectors T-VEC Test Driver Generator
Interfaces
Data Types
Variables
Constants
Behavior
Conditions
Events
State machines
Functions
+
Java – T-VEC Java Package
Modeler Role
T-VEC Test Vector Generator
Generate test vectors
to automate test case design
Reference
Implementation
76Copyright © 2017 T-VEC Technologies, Inc.
◼ システムの入出力間のリレーションシップ
◼ プログラミング言語と同等の記述で表にモデル化
Behavior
Conditions Events Mode Machines
Inte
rfaces
Data Types
Constants
Variables
製品/コンポーネントのインターフェイス
振舞いをデシジョンテーブル（コンディションとイベント）とステートマシンで定義
Interfaces for Personal
Identity Verification
仕様をモデル化
77Copyright © 2017 T-VEC Technologies, Inc.
テキストベースの要求仕様書
モデル検査＋テスト入力・期待値自動生成
仕様・設計のモデル化
要件開発 設計/実装 システム
テストドライバー生成
テスト結果
time
インターフェイス
TAF T-VECTTM
6
5
4
3
2
1
1. 早期段階からセキュリティ要件を含む仕様をモデル化2. モデル化の過程で漏れ・抜け・曖昧さを排除して仕様を洗練3. モデルをT-VEC形式に変換4. 各要件を満たす入力/期待値を自動生成。生成できない仕様から欠陥を検出（定理証明）5. 入力・期待値を基にテスト実行するパターンをスキーマに定義6. テスト実行結果と期待値を比較してコードの一致制を検証
仕様の定理証明とテスト自動生成
78Copyright © 2017 T-VEC Technologies, Inc.
コンパイラのテスト
79
For Compiler Security, it is the Generated Code that Matters
Application
Source
Code
Compiler+ Flaw
Security
Hazard
80
SuperTest Qualifies Compilers Based on the V-Model
Requirements
Language Definition
Implementation Unit Testing
SuperTest
Validation
Proof
81
フロントエンドだけではなく、コンパイラバックエンドもテストする
https://www.fuji-setsu.co.jp/files/JP_Code_generator_validation.pdf
コンパイラのクオリフィケーション
• 安全性とセキュリティの両方について、コンパイラに関する主な懸念事項は、ターゲットデバイスにロードされるコードが正しく生成されないこと
• C、C ++コンパイラが言語仕様で定義された動作を正しく実装していることの検証が、SuperTestの主なタスク
• SuperTestは、テストスイートの言語仕様へのトレーサビリティにより、コンパイラの正しい実装を実証する
• SuperTestの自己検査テストで、生成されたコードが正しいことを確認できる
• 安心で安全なソフトウエア開発プロジェクトで使用するコンパイラの資格認定にも活用される
82
https://www.fuji-setsu.co.jp/files/SuperTestCase.pdf
https://www.fuji-setsu.co.jp/products/SuperTest/83
ドメインスペシフィックモデリングの事例
MetaEdit+
1. Modeling: ドメイン固有の制約を用いてセキュリティを組み込む
2. Generators: 自動生成機能を使用してセキュリティを確保する
https://www.fuji-setsu.co.jp/products/MetaEdit/
◼ 列車制御システムの制御フローやデータフローを
鉄道や列車のコンセプトでモデル化
例１:列車制御システム専用言語
The Model-Driven openETCS Paradigm for Secure, Safe and Certifiable Train Control Systems
https://www.igi-global.com/gateway/chapter/66666
スタンドバイ状態：自己診断、外部デバイスのテスト実行、列車が動かないことをチェック
ミッションの開始
85
例２:鉄道のトラックコントロール
Mewes, K., Domain-specific Modelling of Railway Control Systems with Integrated Verification and Validation, Univ. of Bremen, 2009.
"MetaEdit+ has been proven the most stable of the available frameworks and provides the best support for defining concrete syntax," Kirsten Mewes, Verified Systems International GmbH
86
◼ ドメイン固有のコンセプトを用いて高い抽象度でモデル化
◼ 独自の制約やルールを持たせてモデリング時に自動検査
◼ フォーマルなモデルからあらゆる成果物を自動生成
列車制御システムのモデル
ソースコード
シミュレーションデータ
テストデータ
ドメインの制約をモデリング時に自動検査
ドメインスペシフィック言語 ジェネレータ
ドメインスペシフィックモデリング言語
87
◼典型的な実装上の問題を排除– タイプミス：有効ではあるが誤った変数名などコンパイラによっ
てキャッチされないとランタイムエラーの原因になりえる
– 非効率的なアドホックコード
– 不要または冗長なコード
– リップル効果：ある場所の変更が、どこかを壊してしまう
– リソース管理の問題（予約されたメモリを解放するなど）
– 論理エラー
◼ アーキテクチャ/プラットフォーム/フレームワークの問題– アーキテクチャまたはフレームワークの無効な使用または放棄
– プラットフォーム/フレームワークへの準拠：コード生成機能が最新バージョンと連携し、それを活用することを保証する
– コーディングガイドラインに則したジェネレータ
自動生成の効果
Kelly, S., Tolvanen, J-P, Domain-Specific Modeling: Enabling Full Code Generation, Wiley, 2008. http://www.dsmbook.com
88
