Comments
Transcript
Domain-Specific Modeling For Full Code Generation
間違いだらけの ＭＤＤ、形式手法、プロダクトライン開発 実践で上手く活用されない課題と それらを克服した事例について ソフトウエア開発は変換と検証作業の積重ね 多くの成果物が人手により生み出されている それら成果物間で 設計から 要求仕様へ コードから 設計へ Test Results & Defects Test Results & Defects Tier 1 要求の仕様化 一貫性を保証する 要件へのトレーサビリティ・マトリクス Tier 2 仕様実現のための設計 （モデリングツール、レガシーコード、ソフトウエア仕様書） 要件へのトレーサビリティ・マトリクス Tier 3 設計に基づいたコンピュータ言語への変換 実装 (ソースコード / アセンブラ) 要件へのトレーサビリティ・マトリクス Tier 4 要求に対する デザインレビュー デザインに対する コードレビュー クオリティレビュー 設計に対する テストケース ホスト環境でのテスト実行 要件へのトレーサビリティ・マトリクス Tier 5 ターゲット環境でのテスト実行 Copyright © 2008 Liverpool Data Research Associates Limited 設計に対する テストケース 規模が大きくなると複数の利害関係者間で、 Software Requirements & Defect Reports 要求仕様 に対する Model or Design Specification Code Base デザイン コード実装 人手による 要件からテスト へのマップ 人手による デザインから テストへのマップ Test Cases テスト開発 人手による コードから テストへのマップ Requirements Traceability Matrix (RTM) Copyright © 2008 Liverpool Data Research Associates Limited 人手によるマップ 作業は、階層を追 う毎に複雑性を増 し、管理できないレ ベルにまでなる 開発に変更・追加は付き物、、 « How do I allocate (assign) this requirement…? » « What if I change a requirement; what’s the インパクトは? » « If I change an associated test case, what about regression testing…? » Specs Design (Model) Code Tests Copyright © 2008 Liverpool Data Research Associates Limited 派生開発（差分の開発）が主流となっている 大規模・複雑化する製品を一から開発することは少なくなり、 既存モジュールを組み合わせたり、過去の製品をベースに新 たな製品を開発する 製品ファミリー間で正しく変更修正できている ことを確認できる状態が求められる！ バージョン地獄に陥ってしまう Product 1 Product 2 Product 3 Product 4 Component A 1.0 1.1 1.3 2.0 Component B 1.0 1.2 2.1 2.4 Component C 1.0 1.0 2.3 4.0 異なったバージョンのコンポーネントで構成され、違う時期にリリースされた、 異なった製品間の保守が困難、、 そこで、 ＭＤＤ、形式手法、SPL など、開発の速度向上・工数削 減や高信頼性確保を目的に期待され、多くの研究成 果が提供されるが、産業界で実践的に採用される例 は少ない。 その理由を明らかにし、課題を克服できた成功事例と 適用されたツールを紹介する。 形式手法（フォーマルメソッド） 実装やテストの参照となる仕様・設計は、、 これは様々なフォーマットで提供される – – – – – Old Tests 要求仕様 インターフェイスコントロール仕様 ＡＰＩ仕様 デザインモデル 前回製品のテストスクリプト SRS Experience ICDs 現実は、これらは十分な記述が無かったり、 その内容が矛盾していたりする これらに起因するエラーや誤解が、 実装上のエラーの元になり、 後工程でのやり直し・改訂を招いている APIs Design Models Implementation Error Fault Test Development Revealing Mechanism Combining Mechanism Failure Copyright © 2008 T-VEC Technologies, Inc. 形式手法の目的 多種多様な側面があるが一般に知られるのは １：形式的仕様記述（厳密な言語で正確に表現する） 仕様や設計の曖昧さを排除する （要件やデザインなど開発上流工程での不具合混入を防ぐこと） ２：形式検証 形式的仕様記述の正しさを数学的に証明 （形式的に記述するだけでは判らない論理的な矛盾を明らかにする、 モデル検査ツールの使用） ソースコードレベルで適応される例もある 形式手法の課題 １：形式的仕様記述は難しい！ そのレビューも困難。追加の工数。 ２：形式検証、モデル検査は仕様や設計の正しさの証明だけしかできない！ 下流のＶ＆Ｖ作業が無くなる訳ではない。 結果の判定も難しい。 （上流工程での不具合混入を防ぐことから下流のデバッグとそれによる上流の仕 様・設計改訂削減には役立つが、、） 仕様や設計の正しさを証明することができても 検証には多くのマニュアル作業を伴う 形式手法や モデルベース開発 テスト結果解析 モデル 仕様や設計の モデリング 期待出力値 テストドライバー スクリプト 自動生成される コード 実行環境 マニュアルで 生成されるコード IO/Data Processor テスト結果 （出力値） Graphics Processor LCD Interface Image Integrity Monitor Copyright © 2008 T-VEC Technologies, Inc. テストについて共通の課題 ５０％以上のエラーの原因は要求仕様、デザインに起因 開発の７５％もの時間をテストに費やしている – テスト担当者によるテストで５０％ – 開発者の５０％の時間がユニットテスト（全体の２５％） システムが複雑になり、欠陥の検出が困難になっている テストケースの生成には、多大なコストがかかる – マニュアルによる作業で、間違いを起こしやすい – 良いテストケースの生成をサポートするツールが少ない テスト実行の為に、更なる開発コストの支出 – テストスクリプトの開発には、ソフトウエア開発と同じ問題が起る テストスクリプトの開発もソフトウエア開発。 結果、テスト期間の半分がテストスクリプトのデバッグに費やされている！ 形式手法の課題克服には １：簡単にできる形式的仕様記述 仕様、設計を簡単にモデル化し、自動生成させる ２：仕様や設計の検査だけで終わらないこと – 仕様、設計上の欠陥の排除し欠陥混入を阻止 – テストケース生成を自動化 – テストスクリプト、ドライバーの生成を自動化 表形式に仕様や設計をモデル化 表形式なら使いやすく、理解しやすい 正確な振舞いの要件、インターフェイス情報の形式化 テストのプランニングが可能になる 定義 製品/コンポーネント のインターフェイス Function List SRS Data Types Change Request Functions Constants Behavior Conditions Events Mode Machines Interfaces 要求仕様 (いろんな形式で提供される) 要求のモデル化と、 解釈 Variables テストエンジニアがテスト対象コンポーネントの、特定インターフェイスに対してテストを開発することに類似している 既存プロセスへの拡張は容易 コンポーネントの機能要求をモニターされる変数とコントロールされる変数でテーブルを用いて表現 例：温度変化によってバルブが開閉される Temp Range [-100…300] 100% 180 Valve 120 Electronic Regulator Sensor 0% Operational Summary Temp（温度） が 120 以下なら バルブはClosed Temp が、 180 以上になったらバルブはOpen そして、 120 以下になるまでOpen Open Closed 例：表形式による仕様、設計のモデル化 バルブの出力は以下のモードテーブルから導かれる valve sensorMode temperature Condition Table (valve) Mode Tables (sensorMode) モードマシン sensorMode のテーブルを生成 – ３種のモードを定義: Low, normal, high – low を初期値に Simulink の設計モデル 形式的仕様記述言語へ自動変換するので簡単 形式手法の課題克服には １：簡単にできる形式的仕様記述 仕様、設計を簡単にモデル化し、自動生成させる ２：仕様や設計の検査だけで終わらないこと – 仕様、設計上の欠陥の排除し欠陥混入を阻止 – テストケース生成を自動化 – テストスクリプト、ドライバーの生成を自動化 モデル検査により正しさが証明された仕様や設計から、 テストを自動生成させること！ 形式手法や モデルベース開発 テスト結果解析 形式的 仕様記述 モデル 仕様や設計の モデリング モデルの 自動変換 T-VEC モデル検証 モデルカバレッジ テスト結果 自動生成される コード 実行環境 マニュアルで 生成されるコード テストベクタ、 ドライバー の自動生成 IO/Data Processor Graphics Processor LCD Interface Image Integrity Monitor Copyright © 2008 T-VEC Technologies, Inc. 形式的仕様記述言語へ自動変換するので簡単 モデル検査で全ての入出力パスを抽出し（DNF） 1 2 3 1. 処理結果の値が LOW_TEMP_LIMIT と HIGH_TEMP_LIMIT以内 2. 処理結果の値が LOW_TEMP_LIMIT 未満 3. 処理結果の値が HIGH_TEMP_LIMIT より大きい LOW_TEMP_LIMIT = -100, HIGH_TEMP_LIMIT = 300 モデル検査で全ての入出力パスを抽出し（DNF） 2 3 4 1. No Forcing Constraints (Default) 2. Saturation_GTLimt 上限値以上 3. Saturation_LTLimit 下限値以下 4. Saturation_BetweenLimits 上下限値以内 1 パスごとに、上流から伝播されてくる 入力に対して期待値があるかを評価することで モデルを検査 （結果テストベクタを自動生成） 期待値 入力値 要件ID テストベクタの生成は、 ＊境界値分析、同値分割などテスト技法を融合し ＊フローティング、ダブルなど、あらゆるデータタイプに対応 （インテジャー、ブーリアンのみでは無い） ＊組込みターゲットなどあらゆる環境に適用される IO/Data Processor Graphics Processor LCD Interface ホストシミュレーション Image Integrity Monitor ターゲットテスト 組込みシステム対応事例 ルネサスSH/Hew ターゲット＋ロータバッハ社ＪＴＡＧデバッガ 事例紹介：億単位で儲かりました “Lockheed Martin社ではTest Automation Framework (TAF) を採用し、要求 仕様に基づいたテストを効率良く実現することに成功した。これは、JSF/F-35, F2, C5等最新機種開発のみならず、T-50, F-16などの既存ソフトウエアに対する 機能追加にも有効である事が評価された。機能追加部分をT-VEC社の表形式モデ ル化ツール(TTM)で記述し、TAFに高度に統合しうることも確認した。Flight Control LAWSアプリケーションでは、6~12回に及ぶリリースごとのテストを効 率化し、テスト費用だけで6億円以上の削減を得た。更に重要なのは、結果として リリーススケージュールが短縮され、これ以上の効果が得られた事である。 ま た、開発後半でないと顕著にならないような（ゼロ割など）問題をデザインフェ ーズで明らかにすること、自動ソースコード生成ツール使用におけるエラーの早 期検出など、開発後半では解決に相当なコストや時間、労力が割かれる問題に対 する成果は我々の製品のソフトウエアにとっては億単位の成果になった” （2005年初頭） 事例紹介：次期有人宇宙船で採用 次期有人宇宙船（スペースシャトルの代わり） CEV (Project Orion)の主契約企業であるロッキードマーチン 社は，このプロジェクトにT-VECのTTM要求仕様モデル とSimulinkのモデル検証機能をサブコントラクタも含め て採用することを表明している． 新しく発見されたバグ Rockwell Collins：奥に潜んだ欠陥を検出 Model Analysis Technique/Tool 25 27 6 2 TAF 1.0/ T-VEC Offutt Tool 33 SCRtool Analysis マニュアルインスペクション モデル で、３３ の問題を発見 シミュレーション TAF 2.0/ T-VEC Approx. 9 Revisions FGS Textual Requirements FGS CoRE Text-based Model 1995 FGS SCR Model V9 FGS SCR Model V1 1997 1998 1999 2001 Rockwell Collins Pilot: Flight Guidance System (FGS) - Flight Critical Embedded System マニュアルインスペクションでは判らなかった問題をモデル検証から得られた事例 火星探査機の欠陥を発見 - Lockheed Martin 火星探査機 着陸軌道 Mars Polar Lander は、1/3/99 5 KM に打ち上げられ、12/3/99 に消失 TDM_started = TRUE 35 million milesの飛行, コストは約 $165m 着陸までおおよそ 40メータ において タッチダウンモニタソフトウエアの設計上の欠陥により 無視されるべき偽りの信号を検出し、早すぎるエンジン 停止を引起した mission failure どんなコンポーネント であれ、問題の要因になりうる 40 Meters TDM shuts down engine ~35 million miles Mars 火星探査機の欠陥を発見 - Lockheed Martin 火星探査機のバグを発見 早期段階に於ける要求の欠陥検出は、作業のやり直しを削減 テスト可能な要求仕様は、作業のやり直しを削減 * テスト計画時間を50%削減 * 自動生成されるテストは手作業を90%削減 * テストケース開発と実行は効率化され、テストの冗長性、繰返しを削減 * 要求レベルカバレッジを計画し、測定することができた * 多大なコスト削減効果 *Source: Safford, Key applications of Test Automation Framework (TAF) , Twelfth Annual Software Technology Conference, 2000. Kelly, et. al., Requirements Testability and Test Automation, Lockheed Martin Joint Symposium, June 2001. 派生開発：既存テストシナリオからモデル化し 検査とテスト自動生成（医療機器） 既存プロダクトラインに良いテストシナリオがある しかし派生開発時に、コードの変更にあわせたテストスクリプトの変更に多くの時間 を要し、エラーの基にもなっている そこで、テストシナリオ内のテストベクタ情報を基に、より良く定義されたシステムの インターフェイスをTTMにモデル化 そして、テストシナリオのロジック、算術式を用いて、システムの振舞いをTTMにモ デル化 以上によりTTMにモデル化されたシステムは、T-VEC/VGSによりモデル検査され 、テストベクタ、ドライバーを自動生成できるようになった この事例は、既存成果物（ソースコードやテストシナリオ）を基にして、ベリフィケーシ ョンモデルを構築し、テストの自動化を図った良い例 再利用され派生開発で重荷になっていたテストの工数を飛躍的に削減 http://www.fuji-setsu.co.jp/products/T-VEC/TTM_Interface.html 実践的に産業界で採用されている • FAA/DO-178(A,B,C) Federal Aviation Administration 《米》連邦航空局 • NIST National Institute of Standards and Technology 《米》国立標準技術研究所 • Systems And Software Consortium Inc. (SSCI) http://www.software.org/ 早期段階で欠陥の識別と予防：儲かる！ 早期に欠陥を発見し、対処することで、高くつく手戻りを減らし、コストの削減が 得られた事例 * 欠陥の検出レート 問題が早期に発見されれば、 スケジュールや予算は 損なわれることは無い 旧来の手法 後工程に於ける欠陥の 遭遇は、多くの作業の やり直しを強いられる 予防できる 欠陥 T-VECを使えば 欠陥 欠陥 時間 デザイン、 ビルドなど 要求仕様 出荷前 テスト 出荷 100X ものコスト削減が得られた *Source: Ed Safford - Lockheed Martin, Software Technology Conference, 2000. テストと品質を高め、工数を30％削減 インテグレーション とテスト 要求仕様と デザイン ~60% の 作業削減 追加 ~30% の作業 開発ライフサイクル内では、 ~30% の削減と、 V&Vサイクルの削減 Component Build & Test 産業界からの教訓 1. あらゆる環境で実行できる完全なテストを自動生成すること 2. モデリング言語は簡単で表現力豊かでありながら、複雑で大規模になるシステムに も対応し、マルチユーザ対応になっている 3. 要求からテストにいたるトレーサビリティを提供し、構成管理などを介して開発サイ クルに完全に統合されうる 4. プロジェクト管理をサポートする為のデータ収集と解析ができる 5. 短期的に成果が見込まれる テストエンジニアが数百、数千行ものテストスクリプトを書く代わりに、製品の要求 仕様（多くの場合不十分なドキュメントから）をモデル形式にすることで、テストベク タとテストドライバーが自動生成される。 イテレーティブな開発において、コンポーネントの振舞いや、インターフェイス、ある いは要件の変更に応じて、モデルは修正されテストベクタやテストドライバーを再生 成し、再実行できる。 仕様・設計モデルベース検証の効果 １. リンク付けを意識して要求をモデル化する作業 モデルにリンクされていない要求は見出され，まだモデル化されていない だけなのか，あるいはモデル化できない・テストできないなど改善が必要 かを考察できる ２. 漠然とした要求は，モデル化段階で明らかにされる 例えばある要件をモデルの1テーブル全体や，複数のテーブルに渡ってリ ンクしないといけない場合は複雑になるので，テーブルの一要素ごとへ リンクできるように要件を効率的に分解・整理する作業を通じて ３. 要求へのリンクが存在しないモデルが明らかになる デザインサイクル以降で追加された，要求仕様書へ含められるべき要件 仕様・設計モデルベース検証の効果 ４. 要件がテストケースとリンクする 実装のテスト結果が要求仕様にリンクされるので，テストで明らかになった エラーの解析にかかる時間とコストを飛躍的に削減できる．要求モデル ，デザインモデルにハイパーリンクされる機能は，更なる効率に貢献す る ５. プロジェクト，プロセスを計測し管理する． モデルベース開発，テストで得られる成果物をメトリクスとし，それらの要 求へのトレーサビリティは進捗管理の重要な情報となる 追記：ソースコードの解析から形式手法 システムワイドなコントロールフローモデルとデータフローモデル をソースコードをリバースして自動生成し、以下の解析を行う データフロー ファイルハンドリング ポインター、ヌルポインター ゼロ割 配列境界 メモリアロケーション デッドコード LCSAJ パス インフォメーションフロー アサーションによる Exact Semantic サイドエフェクト データカップリング 参考資料：Formal Methods by Stealth: MCDC テストケースプランナー Formal Methods Implemented in the LDRA Tool Suite http://www.ldra.com/completedownload.asp?id=291 ＭＤＤ モデルを使用して開発を自動化すること 開発速度向上・工数削減や高信頼性の確保を目的に、 モデルによってプログラミングすることにフォーカスします ＭＤＤの目的 ・仕様をモデル記述して、開発利害関係者間の意思疎通を図る （ドキュメントと比較して、下流工程に問題を持ち込まない） ・仕様モデルから、コードを自動生成させる （そうすることで変換・検証作業が軽減されて、 開発の速度向上・工数削減や高信頼性の確保） そしてそれは、派生開発のプロセスを支援できること ！ （コードを clone & own するのではなく、 モデル＝仕様レベルで変更・追加を検討し、コードは自動生成） ＭＤＤの課題 汎用のＭＤＤツールでは成果は上がらない 1/2 ・抽象度を上げないと生産性は上がらないので！ 汎用のモデルから、個々のターゲットやプラットフォームに適したコードを 生成させるには、モデルの抽象度をコードレベルに下げる必要がある （ＵＭＬなどの汎用モデリング言語によるコード生成では、コードを絵で描 くに等しい） しかし、モデルを描くことの目的は、コードレベルから抽象度を上げて基本 概念を表現し、情報を伝え合うための共通手段にすること （相反するのである！） 生産性を向上させるには抽象度を上げること 抽象度のレベルを上げる事 （例：ASMからC言語で5倍の生産性） しかしながら、近年のプログラミング言語では もう生産性は上げられない モデル言語であっても、UML のような コード の視覚化では、生産性の向上に寄与しない *Software Productivity Research & Capers Jones, 2002 ＭＤＤの課題2/2 汎用のＭＤＤツールでは成果は上がらない 2/2 ・完全なコードを自動生成させないと効率が悪い！ テンプレートだけの生成では、追加のコーディングが必要。 また修正がコードに行なわれることによって、モデル側にそれを反映させ る必要がある（ラウンドトリップ） コード変更ーモデル修正ーコード変更と繰返しにより効率が悪くなり、メン テナンスされなくなり、モデルはただのドキュメントと化してしまう ＭＤＤへの解 ドメインスペシフィックなモデリング言語を作ることで ・抽象度を上げる （汎用ではなく、狭いドメインに特化すること） （しかも十二分な正確性を持って with sufficient precision ） ・個別製品ファミリー専用の完全なコード生成 （汎用プラットフォームではなく、 製品専用プラットフォーム・フレームワークを意図したコードを生成させる） ・変更修正はモデル言語や、コード生成ツールに対して行なう （生成されるコードには変更・修正しないこと！ コンパイラが生成したオブジェクトコードを変更しないのと同じ） （汎用ツールにプロジェクトを合わせるのではなく、プロジェクトに合わせた専用ツールを作る） ドメインスペシフィックモデリングなら アプリケーションにフォーカスした、 抽象度の高い、専用のモデル言語から、 完全なコードを自動生成させて、 生産性・品質を飛躍的に向上できる。 汎用言語に比べて、5∼10倍の生産性向上！ 秘訣は、 ソフトウエアファクトリ プロダクトライン開発 体系的なソフトウエアの再利用技術 *Software Productivity Research & Capers Jones, 2002 Domain Idea ドメインの アイデア から Solve problem in domain terms 製品機能をダイレクトにモデル化して変換 Map to code, implement Map to code, implement Assembler 製品 への実装 Code Generate, Add bodies Map to UML No need to map! Model in DSM language UML Model Generate code Finished Product Domain Framework ドメインスペシフィックモデリングとは？ ドメインの知識をモデルに （コードではなく） – – – – – コード実装レベルから、抽象度を向上させる ドメインの抽象概念を利用 ドメインのコンセプトやルールをモデリング言語に組込む 設計の範囲を限定し、 共通の製品系列にフォーカスする 実装担当者には、ドメイン専門用語を用いて開発してもらう Î 慣れ親しんだ専門用語で開発できる Î システムの課題解決に集中できる Î 修正・改善など、問題への対処は一極集中で！ – 直接モデルから反映。コード実装やラウンドトリップを繰り返さない ドメインスペシフィックモデリング環境 Domain Idea Finished Product 熟練者 (few) アプリ開発者 (many) Easy! DSM 専用モデル言語 コード ジェネレータ フレームワーク 環境 DSM 専用モデル言語 で設計に集中 Generate code Domain Framework ドメインスペシフィックモデリングで生産性向上 ホームオートメーション J2EE Web アプリケーション アダプティブ・クルーズコントロール コールプロセッシングサービス 電話交換機機能 メッセージ翻訳・検証システム 組込みシステムのＵＩ *従来の開発手法との比較データ 産業界に於ける事例紹介 携帯電話のアプリケーション => ノキア社のスマートフォン 金融・保険のeコマース => J2EE site EADS社 松下電工 インフォテイメントシステム（カーナビ） Case1: Enterprise apps in Smartphone Symbian のエンタープライズアプリケーション開発 プラットフォームにより基本処理が提供されているターゲット 基本処理を用いる為のアプリケーションロジックをモデル化 モデルからコード生成、システムへのダウンロード、実行までの処 理を完全に自動化 ¾ ¾ ¾ ¾ ¾ 生産性が10倍向上 100％のコードが自動生成できる デザインドキュメントも生成してレビューに利用 新メンバーの研修期間が6ヶ月から2週間に短縮 製品機能にフォーカスして開発が出来た（コード実装で は無く） Symbian/Series 60 例 携帯からの登録申込み、メッセージの送信などを高い抽象度でモデル化 Case2: 金融・保険のeコマース 金融、保険製品のポータルサイトの開発 数百もの金融製品を特定する必要が有った 保険業務のエキスパートが視覚的に保険製品を指定し、ポータ ルのコードを自動生成 ¾ Ｊａｖａによるプログラミングに比較して開発速度が少なくとも 3倍になった Case3: ＥＡＤＳ社 Ｔｅｔｒａターミナル向けのＤＳＭ – 以前の開発はＳＤＬと手作業のコーディング 開発スピードの向上 – ＭｅｔａＥｄｉｔ＋で広範囲の再利用が可能になり、製品バリエーションにも 簡単に対応できた為、開発速度が明らかに速くなった。 製品コードの品質が改善された – ＤＳＭのルールが設計段階で埋め込まれる為、エラーが排除される 複雑さを隠す事で開発が簡単になる – Ｃ言語の知識に乏しい開発者でも、ＤＳＭを使って効果的に開発できた * MetaCase, EADS case study, 2006 Case4: パナソニック電工 独自のアプリケーションフレームワーク上の組み込みＵＩ向けの ＤＳＭ 生産性が３∼５倍向上 – ソフトウェアの設計・実装フェーズをカバーする 学習と教育が容易 – 半日のトレーニングで快適に開発が出来る – エキスパートによる手書きのコードと同じ品質の組み込みＵＩアプリ を開発 * Safa, L., The making of UI Designer, DSM Workshop, OOPSLA, 2007 Case5: インフォテインメントシステム ハイレベルのHMI（ヒューマン・マシン・インタフェース）コンセプ トを用いたシステム – ノブ、表示、イベント、対話式メニュー等 プロトタイピングによる早期のフィードバックが可能 HMIの一貫性を改善し、バリエーションに対応 製品のソースコードの品質を改善 チーム内の複数の役割をまとめる 手書きのコードとコード生成を一体化させるために、既存のフレ ームワークとリンクする マルチ言語、マルチユーザー対応 Ergonomen Designer GUI-Builder: Layout Technical Expert Developer Ergonomen Ergonomen DSM Tool: Behaviour DSM tool: Content Main Main generate ANTENNE1 ANTENNE1 D1-Telefon D1-Telefon 22°C 22°C 13:12 13:12 18.04.05 18.04.05 Main ANTENNE1 D1-Telefon 22°C 13:12 18.04.05 Formal specification Formal specification XML XML Formal spesification Code generator Domain Framework DDS left links D D Case Study: Lucent 5ESS 電話交換機と様々なＤＳＭ* ３∼１０倍の生産性向上 – 様々なケースで – 様々なDSMで 製品リリースのインターバルの短縮 製品バリアント間の一貫性が向上 – “３種以上のバリアントがあれば、ＤＳＭを使用すべき” * D. Weiss et al, Software Product-Line Engineering, Addison-Wesley What companies say “開発プロセス、顧客とのコミュニケーションが、非 常に迅速化できるようになった” “Symbian の C++ UIアプリケーション開発が、 MetaEdit+ を用いてこれほど容易にできること に衝撃を受けた” “従来のアプローチと比較して、開発速度が7.5倍 速くなった” What companies say 標準的な開発手法に比較して、5倍の生産性向 上が得られました MetaEdit+ を用いることで、ソフトウエア開発の 外部委託を削減できるようになった AUTOSAR のバージョンが変更されても、それに 対する修正が簡単に行えるようになった。また、 実装とテストの作業が短縮された MetaEdit+ によるモデル化は、Eclipse に比べて 非常に簡単で効果的であった ＭＤＤ（DSM）の課題 ＤＳＭ（あるいはDSL）には、専用ツールが必須！ ＵＭＬでDSMを作ることは実践的ではない ・ＵＭＬは、オブジェクト指向設計の基本概念を表現するための共通手段 としては良いのだが、意味的に不正確で限定的なので、ＤＳＬ、ＤＳＭな ど、モデリング言語の開発基盤としては向いていない ・ＵＭＬは汎用モデリング言語 ・ＵＭＬメタモデルを定義するＭＯＦは、モデリングの概念をサポートして いない。 ＭＤＤ（DSM）の課題 ＤＳＭ（あるいはDSL）には、専用ツールが必須！ ＵＭＬで相当な費用をかければ作れなくないが、、、 −非常に複雑なシステムとなるので言語開発工数・費用がかさむ −しかも課題は、メンテナンス 派生開発で起こる変更・修正・進化への対処。 （モデリング言語を更新させた時に、既存アプリモデルは生き延びられる か？） モデル言語の更新に合わせて相当なメンテナンスがアプリモデ ルに強いられる ＭＤＤ（DSM）の課題 ＤＳＭ（あるいはDSL）には、専用ツールが必須！ Eclipse でも、相当な費用をかければ、、の話 −ＩＤＥツールの制限として、モデルのエレメントが１ファイルで変更され ると、それを用いてる全てのファイルをアップデートさせなければならな い。モデリング言語の修正・変更による、既存モデルへのインパクトをメ ンテナンスすることは尋常ではない。 http://www.fuji-setsu.co.jp/products/MetaEdit/blogs.html (DSL、DSM の構築にどれだけの工数が必要か？) ＤＳＬ、ＤＳＭの構築に必要な機能は？ ・モデリング環境に加え、メタモデリング、コード生成機能 完全に融合され、既存ツールチェインと統合できること ・進化を支援できること ＤＳＭ言語の修正、拡張が容易で、既存アプリモデルが破壊されることなくアップデートできる ・マルチユーザの支援 異なるプラットフォーム、アクセス権限のユーザが協調してモデリングできる ・特定ツールベンダーに固定されないこと モデルやメタモデルは、ＸＭＬなど標準のファイル形式でインポート・エクスポートできるなど ・あらゆる言語やフォーマットを自動生成できる仕組み プログラミング言語、一般ドキュメントなど、 ドメインスペシフィックモデリング環境 開発専用ツール （ダイアグラム、マトリクス、テーブル）エディタ、ブラウザー、ジェネレータ 、マルチユーザー、マルチプロジェクト、マルチプラットフォーム環境 プロパティで派生を追加できる 保守や共有が簡単で安全に行える方式 – 言語の新しいバージョンを共有でき、既存のモデルをアップデートする DSM 構築に要した期間 63 の言語コンセプト XML のジェネレータ コールプロセッシング 60 の言語コンセプト C, HTML, ビルドスクリプト のジェネレータ タッチスクリーンのＵＩ 36の言語コンセプト Assemblerのジェネレータ 音声制御マイコン 77の言語コンセプト Pythonのジェネレータ 携帯電話のアプリ シミュレーション用の Javaのジェネレータ 自動車インフォメーションシステム 143の言語コンセプト J2EEのジェネレータ 保険製品の定義と管理 青がＤＳＭ言語開発期間 赤がコードジェネレータ開発期間 人/日 DSMの経済効果 30 Current DSM以前: １∼４ヶ月目: ＤＳＭ言語構築期間 ‒ 1 人がＤＳＭ言語とコードジェネレータを構築 – 残り5人は従来通りに開発（１ユニット/月） ¾ トータル２０アプリケーション （従来通りに6人でやれば２４アプリケーション） 5ヶ月目: ＤＳＭの展開 – 5倍 の生産性 ‒ 1 人はＤＳＭ言語のメンテナンス専任 ‒ 5 人がＤＳＭ活用、 ５ユニット/1人月 ¾ 45 のアプリケーションユニット （従来通り6人でやれば３０アプリケーション） 6ヶ月目 ¾ 70 のアプリケーションユニット （従来通り6人でやれば３６アプリケーション） DSM 20 App units ‒ 6 人の開発者 – １ユニット/1人月のアプリケーション開発 App units in month 25 15 10 5 0 1 2 3 4 Month 5 6 ＤＳＭの経済効果: ROI １アプリユニットの価値 = 5000€ – 主に開発者の人件費 開発者は効率を上げることができた ‒ 25 000€ /月の成果を上げる ‒ 20 000€ /月の上積み効果 6 月: 34 上積みされたアプリ 170 000 上積みされた価値 2 500 追加必要経費 6700% 投資収益率 12 148 740 000 10 000 7300% 開発者の一人当たりの費用: ‒ MetaEdit+ のレンタル費 250€/月 ‒ 4ヵ月後からレンタル開始 １アプリユニットに掛かる単価は75%ダウン ‒ 5000€ から 1250€ – 人件費とレンタル費用の合計 6人月の人件費 1ヶ月のDSMツールレンタル費 DSMツール込みの総費用 DSMによる月間総ユニット数 DSMによる１ユニットの単価 30 000 1 250 31 250 25 1 250 実現可能にするためには? 製品ファミリー、開発チームにのみ適合する専用環境 製品ファミリーの熟練者がインハウスのスタイルガイド・フレームワークの 説明書を書く代わりに、モデルからのコードジェネレータを定義できる （そして皆で熟練者のノウハウを活用する） ドメインスペシフィックに、モデリングする – １つのアプリケーションドメイン、フレームワーク、製品ファミリへの適応 – 慣れ親しんだ製品コンセプトでモデリング言語を構成 – 製品、システムを意識したモデルにする（ＵＭＬのようなコードの視覚化ではなく） ドメインスペシフィックなコードを生成させる – モデルから、完全なコードを生成 • そのまま製品に用いることの出来る完全なコード • マニュアル実装、改修などを不要にする • モデルとコード、それぞれで修復しなくても済むような仕組みにする – 既存のコード、コンポーネント、プラットフォームを利用してコードを自動生成 – いかなる言語でも生成 C、C++、Java、Assembler、3GL、object-oriented、XML、デザインドキュメ ントなど何でも。 徐々に進化させること（一度に完全な言語を作ろうとしないこと） DSM に適するのは 反復、繰返しのあるところに適応すること (ROI) – 複数の製品や機能、開発者、ターゲットなど そのドメインに経験があること – – – – 複数のアプリケーションが既に開発されていること 既存バージョンがある ソースコード、ライブラリ、コンポーネントがある インハウスのフレームワークがある そのドメインの熟練者が居ること – 最初の製品を開発したトップ３の誰か – 熟練者：コードジェネレータを担当できる ソフトウエアの開発プロセスが成熟していること – 成熟しているべき、でも厳密に過ぎないこと ＤＳＭを構築するためのリソース １∼３名のエキスパートによりＤＳＭは構築できる – 質を重視。量的な作業ではない ‒ MetaEdit+ Workbench なら容易に開発できる • 5-500倍 以上の開発効率（他のツールと比較して） ＤＳＭ環境構築には、通常２∼３週間、大規模システムでも２∼３人月。 従来のモデル駆動開発では準備に少なくとも１∼２年はかかると言われ ていますが 実績と経験から御社のＤＳＭ構築を支援 – 御社の専門知識: ‒ • ドメイン • 生成されるべきコード MetaCase 社の専門知識: • ツールとその活用 • ベストプラクティス：ドメイン分析、言語、コードジェネレータ （加えて、多くのワーストプラクティス） 手順 ＤＳＭによる抽象化を最初のステップに（コードや手引きは定義しない） – 数日で設定できる ドメインの製品が進化するかのようにＤＳＭを進化させる – 柔軟に更新・変更ができる仕組み モデル化言語を公開し、コードジェネレータを定義 – チームごとのドメインエキスパートによる定義 （ツールベンダが提供する汎用のお仕着せではなく） – モデル化言語、ジェネレータ、ツールの設定など ツールチェインへの統合（他のモデリングツール、テストツール、要求 管理、モデルのインポート・エクスポートなど） – XML, SVG, SOAP/Webservices まとめ 生産性は抽象度を上げる事で実現できる モデリング言語、コードジェネレータ をカスタマイズする事で自動化を実現できる DSM 環境による組織の役割 – チーム内のエキスパートがＤＳＭ環境を構築する – チームメンバーにより真のモデル駆動開発が達成される （エキスパートのノウハウを共有することにもなる） ＤＳＭ環境構築はエキスパートの意欲をかきたてる （モチベーションの向上） MetaEdit+ は、15年以上に渡って評価され証明されてきた手法 – 100以上の実績 IEEE Software 特集記事 ドメインスペシフィックモデリング Vol. 26, No. 4 July/August 2009 ドメインスペシフィックモデリングの ワーストプラクティス（良くない事例集） http://www.metacase.com/papers/WorstPrac ticesForDomain-SpecificModeling_JA.html ベストプラクティスの留意に加えて、共通の落 とし穴や避けるべきことを知ることは有用。 著者は、広範な76 例のDSM を分析しワース トプラクティスを分類した。 15 年間で、4 カ国、様々なツール、100 人にも 及ぶ言語開発者、プロジェクト内のモデル担 当者が３人から300 人の規模まで。 ソフトウェア・プロダクトライン開発 開発成果物を体系的に管理して再利用する工業化策 ・開発スピードの加速 ・生産性向上によるコスト削減 ・高い品質の確保 体系的な再利用技術が求められる A software product line (SPL) is … a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. (Clements and Northrop, SEI, 2002) “特定マーケットや業務・使命で固有 の要件を満たす共通の管理された機能 を共有する一連のソフトウェア集約シ ステムであり， 共通のコア資産を用いて所定の方法で 開発される” 再利用はしていますがコストは、、 ・安くついていない！ 9 – – – 製品2 は、製品1 の90%の機能を共有し、10%が新機能 しかしながら製品2 の開発費は、製品1 の80% その内訳：人件費、リリースの遅延、品質問題 ・理由は、 9–– コンポーネント同士に強い相互依存関係がある 新機能に対する市場ニーズは、ソフトウエアのバライアビリティ、 9 相互依存、複雑性を指数関数的に増大させている 9–– 既存のツールでは、バライアビリティの扱いが考慮されない 製品ライフサイクルにおいて、バライアビリティに対する認識、 9 プロセスが、よりよく管理されていない ・現状、どうやってるの..？ – – 既存ツールでなんとか、、 サイロ型 開発コストの削減に、アウトソースやオフショアを採用、、 一製品だけでも変更・追加の管理は厄介、、 « How do I allocate (assign) this requirement…? » « What if I change a requirement; what’s the インパクトは…? » « If I change an associated test case, what about regression testing…? » Specs Design (Model) Code Tests Copyright © 2008 Liverpool Data Research Associates Limited 派生開発される製品間でも 変更・追加を管理することが必要！ （変更による製品間のインパクト） プロダクトの相関パターン：プロダクトフォレスト ユーザーに見える機能は似通っているが、、 共有するコア資産が殆ど無い （UIの部品や、計算処理程度） P3 P2 P1 P''1 P'''1 P0 P'0 PはProductと、それらのバージョン 同じドメインで、同時期に、別々に開発されている プロダクトの相関パターン：プロダクトブッシュ 再利用資産として基になる製品があり、 開発経路の分岐により、プロダクトバリエーションが作成されている あるブランチの変更を全てに反映させるには、手作業で同じ変更を加える 必要がある 安上がりに見えるが、後からのしっぺ返しが大きい P2 P1 P3 P''1 P'''1 P0 P'0 以前の製品をコピーして、要件に合わせて調整している プロダクトの相関パターン：プロダクトギャング コア資産をプラットフォームで共有したが、 製品個々にバージョン管理されている状態！ PFの各メンバー（部品）は個々に進化、独立し、 ある部分のプログラムの修正が、他のどの部分に影響するか わからない、、 PFは、プラットフォーム ' '' PV PV PVは、プロダクトバリアント 2 2 PV'''3 PV1 PV'0 PV0 PF0 PF01 ' PV'''0 ' '' PF 01 PF 012 PF ''' 012 PF 012 PF'''012 3 ギャングと同じで、メンバー間の結びつきは強いが、個々の素性は謎につつまれて、、、 バージョン地獄 Product 1 Product 2 Product 3 Product 4 Component A 1.0 1.1 1.3 2.0 Component B 1.0 1.2 2.1 2.4 Component C 1.0 1.0 2.3 4.0 異なったバージョンのコンポーネントで構成され、 違う時期にリリースされた異なった製品間の保守が困難、、 プロダクトの相関パターン：プロダクトファミリー コア資産を共有 体系的なバリアント管理 製品間に渡ってバージョン管理・変更管理 どこかに対する変更が、全ての製品に正しく反映される仕組み PFは、プラットフォーム PVは、プロダクトバリアント PV0 PF0 PV'''3 PV'2 PV''2 PV'''2 PV'''2 PV1 PV'1 PV'1 PV''1 PV'''1 PV'''1 PV0 PV'0 PV'0 PV''0 PV'''0 PV'''0 ' '' PF01 ' PF 01 PF 012 PF ''' 012 PF 012 PF'''012 3 ファミリーメンバー間の素性が明確で、製品と資産が双方向にリンク バージョンとバリアントの直交性 Variants v1.0 v1.2 v1.3 v1.4 v2.0 v2.2 プロダクトラインのVersion / Time 顧客が必要としなければ、この図の上から三つ目のように、バリアントが無いこともある 改めて必要になったときには、いつでも追加できる バージョンとバリアントの直交性 プロダクトラインのVersion / Time 顧客が必要としなければ、この図の上から三つ目のように、バリアントが無いこともある 改めて必要になったときには、いつでも追加できる バグの影響を受ける製品を抽出 バリアント間のバグ管理： 特定コンポーネント間のバグの影響を受ける製品を抽出 バリアント管理により得られる効果 SEI: "Product Line State of the Practice Report" 製品化までの時間を短縮 Reduction Time-to-market 30% Improved Ability to React on Customer Specific Requirements 39% Productivity Improvement 39% 顧客特有の要求に 対して迅速に対処できる 生産性の向上 コスト削減 Cost reduction 品質向上 Quality Improvement 55% 52% 0% 10% 20% 30% 40% 50% 60% バリアント管理により得られる効果 SEI: „Software Product Lines State of the Practice Report“ Benefits for a DoD Project Department of Defense、《米》国防総省 Quality 1/10 of normal level of errors Performance comparable to conventionally developed systems Development Time integration in weeks insted of months, only 15 instead of 100 developers System Size Productivity 76% lesser than planned 50% less cost 50% shorter project duration than planned 品質： 通常レベルのエラーは1/10 に 性能： 従来開発製品と匹敵 開発工数： 統合は数ヶ月から数週間へ。100人の開発者は、15人に。 システムのサイズ： 予定サイズの76% 生産性： 50%コストダウン。予定の50%（半分）の期間 バリアント管理ツールに必要なこと ・ツールに合わせる必要の無いこと 既存のプロジェクトの構成、成果物をベースに、それらをツールやその手法に合わせること なく、インクリメンタルにバリアント管理を、安全に取り入れることが出来ること。 既存のビルドやその他のプロセスの変更は最小限に ・大規模・複雑なシステムへの対応 追加のフィーチャにより、取り得るバリアントは簡単に倍増することを考慮に入れて、複雑 で規模の大きいバライアビリティのモデリングにも対応できること ・派生開発（差分開発）への対応 資産・プラットフォームなどの変更・修正・進化に順応できること ＊Eclipse のような共通のツールプラットフォーム、ユーザインターフェイス バグ管理・追跡ツールのようなツールとは、リアルタイムな協調が取れること ＊APIを介して、あらゆるツールとの統合が誰にでも出来ること バリアント管理ツール pure::variants 要件管理 MKS デザインツール Simulink openArchitectureWare 構成管理 変更・バグ管理 MKS Source MKS Integrity Requirements Rational SW. Architect Rational Rational Borland Caliber Rhapsody ClearCase ClearQuest CVS Atlassian JIRA Subversion Bugzilla ... Softtest RM Telelogic DOORS Artisan Studio Enterprise Architect. 各種ツールを統合 プロダクトライン・ライフサイクル・マネジメント を支援 バリアント管理ツール モデル化し Problem Space Solution Space フィーチャーとリレーションの集合 資産コード、ファミリー部品の集合 マッピングします Feature Model Family Model Production Plan そして！ Single Problem Single Solution 必要なフィーチャーを選択し バリアントが自動生成されます Variant Model Variant Realization バリアント管理ツール 既存の開発プロセスへ統合が容易 • 既存のコード、ツールチェーンを使い続けられる • バージョン管理をサポート • テクノロジーに依存しない（C、Javaなど、あらゆる言語や、HWの管理にも） 効果的なバリアントモデリング • フィーチャーの組み合わせに関するノウハウを蓄積し、共有できる • バリアントの構成を検証 自動的にリソースを活用して、バリアントを生成 • ソースコードをパッケージに（例：バージョン管理ツールから） • コード、ドキュメント、部品表の生成 バリアント管理ツール z z プロブレムとソリューションの両モデルを完全に分離。再利用、構成を促進。 自動的に機能間の矛盾、不一致を検出。 バリアントモデリング時に実施し、早期段階に問題を排除できる − z z 最新鋭の技術で論理的ルールを解釈 低い導入障壁： − 既存資産、ファイルシステム構造を変えることなく導入できる − 製品バリアントは 制約無しに自在に生成できる。複数のバリアントを同時に 生成できる。（ファイル構造などの仕組みに依存することなく、完全に独立し た部品としてコア資産を管理し、利用できる） エクリプス、クライアント/サーバアーキテクチャをベースに、柔軟に拡張できる − ローカル、あるいはサーバ管理してマルチユーザでモデルを管理できるの で、大規模システムにもフィットする − 多くのエクステンションにより、既存開発環境への統合や改善が行える 適応範囲・導入アプローチ 顧客・市場 からの要求 要求仕様書 顧客・市場 からの要求 モデリング・ シミュレーション 要求仕様書 開発・実装 モデリング・ シミュレーション 開発・実装 テスト 出荷 テスト 出荷 プロダクトライン・ライフサイクルで、一貫してバリアントを管理 トップダウン – 再利用の為のデザイン − プラットフォーム、アーキテクチャ、コンポーネントを 再利用を意図して設計 − PLE, SPL で提唱される戦略に習う − プロセスの開始次期からバリアント管理を用いる ボトムアップ – 再利用の為にリファクタリング − 開発チームによる課題への取組み − 既存ツールの統合Integrating existing tools − 既存のレガシーコード、成果物をリファクタリン グ Siemens Medical（ジーメンスの医療関係）: 新しいプラットフォームの共有資産、バライアビリティ機能を、トップダウン・アプローチ で、pure::variants にモデル化 Danfoss Drives（モータ制御用インバータ）: ボトムアップ・アプローチで、4つのマーケットのコードを共通プラットフォームに統合 Danfoss 社の例 問題 – ４種類の市場の為に、幾つかの、ワールドワイドに展開したチーム（ 約７０人）によって、 ソフトウェアが提供されている。ソフトウェアは、非 常に似通ったハードウェアをベースに開発されている。 – 再利用は殆ど場当たり的 – コストと開発労力が高かった 課題 – 共通プラットフォームをベースにした、体系的にコントロールされた再 利用に移行 Danfoss 社の例 我々の役割 – プロセスの定義に参加 – 新たに作られたプラットフォームチームの評価と指導 – pure::variantsへの移行のサポート 結果 – 最初の段階への移行は６ヶ月後に成功：全てのプロジェクトは共通プラットフォーム上で開 発されるようになった – ２番目の段階への移行（ pure::variantsの実製品開発への導入）はほぼ完了 – ほぼ同じ開発能力で扱えるプロジェクトが２倍になった http://www.fuji-setsu.co.jp/files/pure_variants_Daimler_Simulink%20success.pdf に和文資料があります。 ソフトウエアのモノづくり リバースエンジニアリングをされると、製品に作り込まれた技術は真似されてしまいます。では 逆に考えましょう。製品に跡形も残らないような技術であれば、真似はされません。そんな技 術はあるんでしょうか。それが生産技術です。いかに早く安くきちんとモノづくりをするか、という 技術を磨き上げることが競争力の源泉になるわけです。 では、ソフトウェアで真似されない技術とは何でしょう。その一つが、テスト技術です。テストを いかに早く安くきちんと行うか、という技術を磨き上げても、その技術は決して製品に残りませ ん。製品に残るのは、バグが無いという事実だけですから。テスト技術は、リバースエンジニアリ ングによって真似されることもありません。すなわちテスト技術は、ソフトウェアのモノづくりを支え る重要な技術になるわけです。 テスト工程は、ソフトウェア開発のボトルネックになっています。現状のソフトウェアの開発工程 は、最低でも3割、多い場合には9割近くもテストに割いています。テストの改善は大きなコス トダウンの源泉であり、ひいては競争力の源泉にもなるのですね。ぜひ自社のテスト工程を見 直して、改善を図ってみてください。 電気通信大学 西 康晴先生 http://blues.se.uec.ac.jp/mt/swtest/archives/cat_cat5.html More Information このスライドや各種資料へのリンクを以下のページで公開しています。 http://www.fuji-setsu.co.jp/event/et2009.html 富士設備工業株式会社 電子機器事業部 TEL：072-252-2128 http://www.fuji-setsu.co.jp 担当：浅野 E-Mail： [email protected]