電子楽器の商品価値を高めたモデルベース開発フレームワーク

～DIコンテナ技術を用いた高品質・高生産性の実現～

ヤマハ株式会社楽器開発統括部 楽器技術開発部

安立直之2- -

アジェンダ

• 対象商品/背景

• 流用開発における課題と解決策

– モデルベース開発に基づいた活動計画

• ３つのアプローチ

– アーキテクチャ上のアプローチ

• DIコンテナを用いた分割統治

– 組み込みシステムへのアプローチ

• 組み込みの実装に特化したフレームワーク

– 多機種展開のアプローチ

• プロダクトライン開発の運用

• 考察と今後の課題

3- -

対象商品/背景

4- -

ヤマハ株式会社の紹介

• 弊社は音・音楽を中心に展開する企業グループです

• 楽器、ＡＶ機器、音響設備、半導体、カーパーツ、ＦＡ、リゾート、スポーツ用品・・・を事業領域としております

• 本事例は電子楽器が対象です

ｖ

5- -

対象商品と背景

• 録音、オーディオ、カラオケなど付随機能の増加

• 電子楽器のネットワーク化

• 音楽環境の変化

進化のスピードは指数関数的6- -

流用開発における課題と解決策

7- -

流用開発で発生する問題

• モジュールの複雑化

– システムデザインを無視したパッチワーク的変更の積み重ね

• プログラムのビッグバン

– 整理・削減されることなく膨れあがった200万stepのシステム

• 設計文書と実装の乖離

– プログラムに仕様が隠蔽

– メンテナンス不可能な虫食い状態の設計文書

• 属人性の高い開発体制

– 低コスト開発戦略による人材の固定化

名ばかりの「流用開発」がその場凌ぎのプログラムを膨れあがらせる

8- -

流用開発のもたらす弊害

• 開発効率の低下

– 2005年以降生産性が下がる

– 流用率の高さに対し生産性が半減

– スパゲティコードが増大

• 新機能開発が困難に

– 新商品の付加価値が作れない

– 保守工数が莫大

再利用性・開発効率低下が顕著→機能追加もままならない状況に陥る

9- -

問題の要因分析

膨張する担当範囲

少人数戦略

機能別の担当制

効率優先の部分最適型開発スタイル

モジュール結合が強く、関数の複雑度が高い

レイヤの崩壊

作業量 作業の難易度

設計指針の不在

活用されないドキュメント

低コスト開発戦略

潜在する弊害

生産性低下要因

修正中心の開発経験

促進する

増加させる

低下させる

機能中心の設計

差分開発に

偏ったスキル

開発者のモティベーション低下

要員交替・

高齢化リスク

生産性

増加させる

低下させる

内部品質に対する意識の低さ

組織の弱み

元の品質の問題

技術面のポリシー欠如

根本原因は

「技術ポリシーの欠如」と「流用元のソフトウェア品質」 10- -

課題解決の５ヶ年計画

プロセス フレームワーク

仕様定義

品質定義構造定義

実現性検証

プロダクトライン要求分析

機能設計 評価試験

工程管理ドメイン定義

ユースケース定義

品質基準定義

テストメソッド定義

オブジェクト生成管理メカニズム定義

実装パターン定義

標準ライブラリ定義

プロトタイプ作成

評価方法定義

ハード・物理層選定

サービスコンテンツ定義

反復型開発

構成管理システム

サブシステム定義アーキテクチャ定義

タスクマッピング

技術導入基準定義

例：Networkの組込方法検討

例：ドライバ組込方法検討

例：Object管理自動化ツール

例：Class Wizard作成

例：U/I自動生成

例：コンテンツ連携ツール

例：Class Pattern Inspector作成

例：開発環境へのCppUnit組込

例：SVNと派生管理

従来のシステムデザインの範囲

活動全体の範囲

プロジェクト管理システム

例：Redmineと変更管理

11- -

５ヶ年計画の成果

• ユースケースモデリングと派生要求分析法

– 全ユースケースのモデル化と派生シナリオ記述による仕様整理

• チケット駆動の大規模反復型開発

– チケット駆動による全変更管理と反復型開発

• 文書管理とトレーサビリティ

– コードのみならず全文書のSubversion管理とRedmine連動によるトレーサビリティ実現

• 継続的インテグレーションと常時静的解析

– Jenkinsによる自動ビルドと静的解析の常時実行

• etc...

具体的な施策はボトムアップで解決

12- -

今回の発表範囲

DIコンテナを用いたフレームワークとモデルベース開発にフォーカスし、３つのアプローチについて報告致します

• システムの密結合解消のためのアプローチ

– DIコンテナを用いた分割統治による疎結合の実現

• 組み込みシステム特有の課題解決のためのアプローチ

– OS隠蔽とメモリ最適化の実際

• 多機種展開における差分管理のためのアプローチ

– プロダクトライン開発における差分管理の実際

13- -

システム密結合解消のためのアプローチ

～ＤＩコンテナを用いたモデル部品管理～

14- -

流用開発におけるシステムの課題

• 他のシステム同様、レイヤー構造は概念上存在したが・・・

• 実装定義がなく、PMの目を逃れて想定外の実装が作られる・・・

• 工数やパフォーマンスの都合のため、レイヤーを無視した実装が増加

• 機種毎に似て非なるインターフェースやモジュールを増設

Ｕ／Ｉ

Application

Mechanism

Driver

機能α

メカニズム①

ドライバ甲

ＣＰＵ

ドライバ乙

Sub System

Sub System

サービスＡ サービスＢ

機能β

機能γ

メカニズム②

ハードウェア

レイヤーを無視したモジュールの増設

レイヤーを無視したモジュールの接続

上位レイヤーのOS・ハード依存

15- -

システムの課題の実例

• レイヤー構造の崩壊

– 例：パフォーマンスを出すためにU/Iが直接ハードウェアのボリューム値を読み出して表示してしまう

– 例：ファイル層でリード対象のファイルを検索するために、U/Iの表示値を直接取得している

• 似て非なる実装の増殖

– 例：ピアノとギターの音の違いのために、引数が異なるが殆ど同じ関数が作られる

– 例：楽曲再生と楽譜表示とで、殆ど同じ音楽ファイルの解析処理が別々に作られる

16- -

モデルベース開発で解決を図るが・・・

複雑化したシステムへの対処としてモデルベース開発の導入で解決を図るが、壁にぶつかる

1. モデル化した部品を頻繁に接続・交換しなくてはならない

– U/I～HALまでを１つのモデルで表現するのは困難

– 機種毎に異なる部品を簡単に置き換える仕組みがほしい

2. 既存のソースコードが膨大で切り分けが困難

– 数百万行のシステム全体をモデル化する工数がない

– 複数機種のコードが#ifで混在していて、手をつけられない

3. 機種毎のI/Fの違いが壁

– 機種、部品毎にデータ型の扱いが異なる

複数機種開発のモデルをコントロールする上位の仕組みが必要

17- -

interfaceX

1-1.Dependency Injection(依存性注入)• Dependency Injection(依存性注入)=Javaを中心にEnterprise系で

普及した部品化技術• 部品間の関連を、部品以外（フレームワーク）で管理することで、

独立性を向上させる考え方

• 部品間の関連は「コンテナ」と呼ばれるフレームワークで定義、管理するため、関数の呼び出しはシステム管理者の手を介して行われる– 無秩序なモジュールの関連を作りにくく、レイヤーの維持に効果

functionX obj = new classB();obj.BBB_Method( ParameterB );

classA

classB

interfaceX

classAの中にclassB依存のコードが混入

classA

classB

functionX obj = container.getComponent();obj.XXXmethod( Parameter );

classAの中に記述されるのは汎用インターフェースのみ

コンテナ呼び出し関連を定義した設定ファイル

生成しclassAに渡す=依存性注入

参照

■従来の依存関係 ■DIコンテナによる疎結合

18- -

functionX obj = new classB();obj.CCC_Method( ParameterC );

1-2.DIコンテナによる実装置換

• 部品間の関連づけはコンテナが定義するため、同じインターフェースで異なる部品を追加することが可能

• 呼び出し側の実装を変更することなく、コンテナの定義を書き換えるだけで動作を変えることができる

functionX obj = new classB();obj.BBBMethod( ParameterB );

functionX obj = container.getComponent();obj.XXXmethod( Parameter );

classA

classB

interfaceX

classC

他の動作に置き換えるにはclassAの修正が必要

classA

classB

interfaceX

classC

コンテナ

classAは一切修正せず設定ファイルで動作の

置き換えが可能

依存性定義G

■従来の依存関係 ■DIコンテナによる疎結合

依存性定義F

19- -

1-3.DIコンテナによる実装置換の例

U/I 楽譜再生

コンテナobj = container.getComponent();obj.Command( PLAY_SONG );param = obj.Parameter( SONG_NO );

U/Iに記述されるのはフレームワークと「曲を再生せよ」という抽象的な命令のみ

■従来のモジュール結合

■DIコンテナによる結合

U/I楽譜再生

obj = new classB();obj.doScorePlay();obj.getScoreNo();

MP3再生obj = new classC();obj.doMp3Play();obj.getMP3No();

MP3再生

楽譜ファイルからMP3に変更するにはそれぞれの関数を直接記述する⇒派生開発では#ifだらけのスパゲティコードに！

void classC::Command( MP3No ){・・・}

void classB::Command( ScoreNo ){・・・}

20- -

1-4.DIフレームワーク「CoPaN」

• Embedded C++に準拠した独自フレームワーク「CoPaN」を開発

– ３つの基本I/Fをもつフレームワークでモデル部品を繋ぐ

• モデル部品をDIコンテナ化

– 依存性定義に従ってモデル部品の置換を簡単に実現

21- -

コンテナ

2.段階的なモデルベース化

• 旧資産とのI/FをDIコンテナ化

– モデル内に「AbstractDriver」を配置してブリッジ

– 漸次旧資産を置き換えることで開発負担を分散化

• モデル＝実装を維持するリバースエンジニアリング

– Enterprise Architectのリバースエンジニアリング機能でモデルと実装を常に一致

– 設計レビューでチェック

22

IManua lEventConvert er

+ convert(MESSAGE_TYPE*, UINT8) : MusicalSignature*

同期前の状態

同期後の状態IManua lEventConvert er

+ getParam(void) : UINT32+ convert(MESSAGE_TYPE*, UINT8) : MusicalSignature*

AbstractDriver

classA

旧資産

classB

- -

3.インターフェース抽象化

23

• 旧資産とのインターフェースとデータの取扱がネック

– 同じ意味でもモジュールによって型や扱いが異なる

• 電子楽器で扱うデータを「音楽記号」クラスにて抽象化

– システム内で流通するデータを一元化

– Translatorクラスがそれぞれの型に変換 AbstructData

DataTypeA

Translator

class Aclass B

コンテナ

class C

シリアライズデータ

表示値 内部値

「翻訳」の概念を取り入れることでモジュール間のデータの違いをならす

タスク間通信に必要なシリアライズ処理もTranslatorに機能を隠蔽

- -

アーキテクチャ構造の改善結果

• Doxygenによるモジュール間の依存性解析結果

レイヤー明確

単方向関連

構造が簡素、単方向による疎結合化で設計効率が大幅に向上

■改善前 ■改善後

24- -

ソフトウェア品質特性の改善結果

• ソフトウェア品質特性のメトリクス集計

– オージス総研様の協力の下にAdquaにて計測

• http://www.ogis-ri.co.jp/product/b-08-000001A6.html

• ソフトウェア品質５特性（信頼性、効率性、保守性、移植性、再利用性）で得点化

ソフトウェア品質特性も大幅に改善

ケース 改善前 改善後

A社 71.19 80.42E社 67.69 85.20G社 71.10 -J社 53.47 -ヤマハ 70.46 84.27平均 70.18（未掲載分も含む） 80.16（未掲載分も含む）

25- -

ソフトウェア品質特性の改善結果詳細

• より詳細に品質副特性までを従来機種と比較

– システムの堅牢さに繋がる「信頼性」、「効率性」に効果

– 保守性の中でも「試験性」が大幅に向上

• 再利用性はU/I自動生成部を含むため低く出ている（後述）

項目 改善前 改善後

信頼性成熟性 87.07 93.13障害許容性 87.43 91.87

効率性時間効率性 72.27 73.94資源効率性 71.13 87.60

保守性

解析性 81.03 83.07変更性 75.78 71.83安定性 75.60 77.10試験性 68.14 72.25

再利用性 62.56 57.43

信頼性・効率性・試験性の向上でタイミング依存の難解な不具合が激減 26- -

DIコンテナとモデル部品化の実際まとめ

1. モデルベースで部品化されたコンポーネントを繋ぐ仕組みとしてDIコンテナを導入

– モデル化された部品同士が、相互に抽象化された部品として接続、交換を可能とした

2. DIコンテナを通し新資産/旧資産を切り分け

– 段階的なモデルベース化を実現した

– 呼び出し側モジュールを修正せずに新/旧の入替が可能になりテスト工数の削減にも繋がった

3. DIコンテナに加えデータ翻訳機構を取り込む

– DIコンテナの効用である実装置換をしやすくした

– 翻訳機構をＰＭが掌握することで抽象的なI/Fを確実に作らせた

27- -

組み込みシステム特有の課題解決のためのアプローチ

～OS隠蔽とメモリ最適化の実際～

28- -

組み込みシステムにおける課題

1. ハードウェア制約による個別チューニング

– 機種Ａはタスク間通信でもよいが、低コストなシステムの機種Ｂは割り込みで直接アクセスしないと間に合わない

2. リアルタイム性の確保

– µsecオーダーのリアルタイム性が必須条件

– C++でDIなんて仕組みを入れて、重厚長大なフレームワークにならないのか？

3. ROM/RAMの制約

– コスト重視と機種毎の厳しいROM/RAMの制約

組み込みシステム要件を満たす仕組みが必要

29- -

1.DIコンテナとOS依存性の排除

class A class B

task I/F

semaphoreOS

利用する

異なるタスクを利用する

■OS依存のモジュール結合

■OS機能を隠蔽したDIコンテナ

class A class B

コンテナ

OS

obj = container.getComponent();obj.XXXMethod();

I/Fを直接記述するだけでなくOSのAPIも埋め込む

必要がある

FactoryMethod+StrategyPatternにより事前にID毎に割り当てたプロセスを提供する

OSシステムコールはDIコンテナの中で暗黙的に使われる

cre_mbx( ID, MailBox);snd_msg( ID, pMessage );

rcv_msg( pMessage, ID );classB obj = new classB();obj.XXXMethod( pMessage );

依存性を定義した

設定ファイル

task I/F

semaphore30- -

2.依存性定義に沿ったインスタンス管理

• 依存性定義に従って自動的にコンパイル・リンク対象を選択＆インスタンス生成

– 起動時に全てのインスタンスを生成して準備しておくことで実行時の呼び出しが高速になる

要求機能×コンポーネントのマトリクス表から自動生成

31- -

3.FactoryMethodとメモリ最適化

• uITronのヒープは固定長/可変長の違いがパフォーマンスに影響する

• 実動作ログからヒープ構成を最適化

– 固定長メモリプール/placement_newを使った最適化

– 起動時間・発音速度とも前機種同等の性能確保通常のメモリプールの使用方法

確保・解放

提供

最適化されたメモリプールの使用

実測例（イメージ）

heap size 個数 必要容量8 8282 66256

16 2410 38560確保・解放 64 784 50176

128 248 31744256 1012 259072

提供 512 894 4577281024 73 747522048 86 1761284096 19 77824

10240 17 17408040960 18 737280

コンポーネント ＯＳ

heap

バッファ

要求に応じてheapから必要量を与える

確保・解放に時間が掛かる

コンポーネント ＯＳ

heapバッファ

予め必要量を計測し、そのサイズに合わせheapを細切れにしておく

heap

heap

heap

要求に応じてheapから必要量を与える

コンポーネントはインスタンス生成・解放を気にせず実装できる 32- -

組み込み特有の課題対応の実際まとめ

1. DIコンテナにOSを隠蔽しハードウェアの差異を吸収

– CPU/ハード違いによるシステムコール呼び替えが簡単

– 開発者へのフレームワークの強制力も高まる

– 組込特有のリアルタイム性・タイミングの問題が減った

2. 依存性定義によるリンク・インスタンス生成を自動化

– 機種毎のROM/RAM制約にたやすく対応できた

– 起動時に全インスタンスを生成することで実行時のパフォーマンスを確保できた

3. 固定長メモリ・placement_newを用いたメモリ最適化

– RAMの最小化に加え、起動時のインスタンス生成が高速になり起動時間が短縮した

33- -

多機種展開における差分管理のためのアプローチ

～プロダクトライン開発における差分管理～

34- -

プロダクトライン開発における課題

1. 派生モデルの差分管理

– 派生モデルを作る度に増える差分

– バリエーション・バリアントの集約と管理

2. プロダクトラインの維持コスト

– コア資産開発と機種開発両方の開発者が必要

– コア資産と機種との要求調整に時間が掛かる

3. 派生モデル毎に異なる開発期間への対応

– 限られたリソースで如何に多数の機種の品質確保を行うか

軽量プロダクトライン開発を模索

35- -

classA

classB

interfaceX

classC

コンテナ機種①用

依存性定義表機種②用

依存性定義表

1-1.DIコンテナでソフトウェア資産管理

• DIコンテナにより機種間の差異はインスタンスの差し替えで実現

• 依存性定義表に従って自動的にコンパイル・リンク対象を選択＆インスタンス生成

– #ifによる差分実装を完全排除

36- -

UI

1-2.DIコンテナのU/I自動生成への展開

• U/Iは表示コンポーネント化

• DIコンテナ＆I/F抽象化で「振る舞い」まで自動生成対象に

Application

State Trigger

Parameter

View

Command

更新通知

イベント

設定

設定設定

AdapterComponent

表示更新

37- -

1-3.自動生成とコーディングレス開発

• U/Iは機種毎の状態遷移表だけで構築

• 自社開発の自動化ツールにより約30万行を自動生成

– U/I起因のバグは１プロジェクト通しで0.022件/klocに減少

依存性定義＆状態遷移表の入替だけで差分管理38- -

2.少人数でのプロダクトライン開発

• 本来ならばコア資産＋機種開発で倍の開発者が必要

• 機種毎に必要なclassを作成、インスタンス割当

– 渡り鳥のように次々と機種開発の中でコア資産（候補）を開発

– 機種開発後にコア化することで「使える」ものだけが資産化

機種A

ベース機種

機種B 機種B+

機種C

機種C+ 機種C++

機種D 機種D++

機種E

機種A#

機種B#

3.反復型開発による動作モデルの維持

• 機種開発を数週間～2,3ヶ月のイテレーションに分割

• 常に製品レベルの動作を確保しつつ、要求分析の漏れとテスト作成の手戻りを最小限に抑える

コンポーネント

開発

要求分析

システム分析

ドメイン分析

モデリング

実装/単体テスト

結合テスト(モデル)

U/I開発

ドライバ開発

結合テスト(機能)

システムテスト

統合テスト結合テスト

(機能l)・・・

コンポーネント単位で常に

検証しながらモデルベース

に置き換える１サイクル２ヶ月

２ヶ月サイクルの繰り返し

40- -

プロダクトライン開発の品質結果

年度 総工数 新規行数 バグ数(個) バグ密度

初年度 195.8% 95.6% 119.7% 125.2%２年目 101.1% 96.5% 22.2% 44.0%３年目 64.3% 154.0% 27.3% 25.5%４年目 35.9% 79.1% 62.5% 73.5%５年目 85.5% 127.0% 31.7% 17.9%

• ５年間で全６シリーズ/21機種に適用

• 各機種について旧機種開発時とのメトリクスを比較

生産量を維持しつつ工数・バグとも減少

２年目以降はU/I自動生成部を除いた数字！

41- -

プロダクトライン開発の実際のまとめ

1. DIコンテナの実装置換機構を用いて差分管理

– 依存性定義表から自動でインスタンス生成＆リンクを実現

– U/Iをコンポーネント化し、全コード自動生成を果たした

2. コア開発者を置かない軽量プロダクトライン体制

– 機種開発後に実装差分をマージする方式で開発・調整の工数を抑制できた

3. 開発プロセスとして反復型開発を取り入れることで手戻りを抑制

– システム全体の骨組みとなるコンポーネントから短期間で実装・結合し、検証を繰り返すことで結合時のビッグバンが発生しなかった

– 派生製品向けのコンポーネントを漸次リリースできた

42- -

考察

43- -

考察

• DIコンテナを活用したフレームワークの適用に加え、インターフェース抽象化＆抽象データ型で疎結合を実現

– データ型の一元管理で運用崩壊も防止

• DIコンテナにOS機能の取り込みを行う事で、移植性向上と組み込みシステムでの制約を同時に解決

– 将来のシステム変更にも対応

• コーディングレスのための徹底した自動化

– モデルベース以外も自動化・コードレス化を推進

• 限られたリソースでシステム刷新するための反復型開発

– 段階的に改善を進めるためのDIコンテナの活用

44- -

ボトムアップからの継続的改善の実現

• DIコンテナのフレームワーク導入は最初の一歩

• 翻訳機構のアイデアやU/I自動化、プロダクトラインの施策は全て開発者からのボトムアップ

• 最初に描いた大きなビジョンを共有したことが５年間の継続に繋がった

– 誰に・何をお願いすることなく、自主的に改善領域を決めて取りかかってくれた

ビジョン

45- -

ご清聴ありがとう御座いました

46- -