09.08.2013 Views

ソフトウェアアーキテクチャ開発とは - JEITA

ソフトウェアアーキテクチャ開発とは - JEITA

ソフトウェアアーキテクチャ開発とは - JEITA

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>JEITA</strong>組込み系ソフトウェア・ワークショップ2012<br />

日本の組込み系開発におけるアーキテクト<br />

~ アーキテクトは何を解決するか ~<br />

アーキテクトが解決すること<br />

ㄯ0ㄮㄯ年ㄮㄮ月7ㄴ日<br />

富士通株式会社 ネッットワワヸクビジネスグルヸプ<br />

共通開発本部 第一ソソフトウェア開発統括部<br />

シニア・プロフェッッショナル・エンンジニア 保土原 行彦<br />

Copyright 2012 FUJITSU LIMITED


本日の内容卣<br />

アヸキテクチャとは<br />

定義とその目的<br />

事例紹介<br />

アーキテクチャが崩れた事例<br />

改善取り組み事例<br />

崩れ防止の取り組みとアーキテクト育成<br />

1<br />

Copyright 2012 FUJITSU LIMITED


アーキテクチャとは<br />

アーキテクトのイメージ<br />

製品開発における現場の課題<br />

分かるようで解らないアーキテクチャ<br />

アーキテクチャの目的と特性<br />

2<br />

Copyright 2012 FUJITSU LIMITED


アーヸキテテククトトのイメメーヸジ<br />

アーヸキテテククチチャャのイメメーヸジ<br />

構造 仕組み 方式<br />

変化への対応という意味でのアーヸキテテククトト<br />

簡単には変え<br />

ない頑固さ<br />

変更容易性<br />

拡張性<br />

頼れる<br />

大黒柱<br />

波<br />

3<br />

再利用性(変化への対応力ㄦ<br />

が良いもの<br />

アーヸキテテクク<br />

チチャャへの<br />

こだわり<br />

目的を俯瞰<br />

した調整力<br />

ココストト<br />

Copyright 2012 FUJITSU LIMITED


製品開発における現場の課題<br />

開発現勶場における課題匑<br />

派生開発<br />

ネットワーク機務器におけるシリーズ品厍<br />

機務器の用途に応厸じた機務能印具備厵・配備厵<br />

スケヸリンング<br />

収厓容卣する対象によるスケーリング(リンク<br />

/パス/アソシエーション)<br />

移行性<br />

デバイス統廃合を鑑みたコンポーネント<br />

インタフェースの実現勶<br />

4<br />

アーヸキテテククトト<br />

アーキテクチャで<br />

解決<br />

波<br />

固有技術専門家<br />

ププロロママネネ<br />

Copyright 2012 FUJITSU LIMITED


分かるようで解らないアヸキテクチャ<br />

目的観点でのアヸキテクチャの定義<br />

モノや構造を意図<br />

プロセッサアーキテクチャ<br />

バスアーキテクチャ<br />

OSアーキテクチャ<br />

VS<br />

機能や仕組みを意図<br />

メモリアーキテクチャ<br />

ネットワークアーキテクチャ<br />

分散処叀理アーキテクチャ<br />

アーキテクチャという⾔葉が意味するものが多種多様なため、<br />

異なるステークホルダー間で議論しても分かり合えない<br />

目的に主勢眼を置厒いた定義として<br />

ソソフトウェア開発の際に、将来変化を予測し、この変化に<br />

応じてㅎCㅁを最小限にする要素を予め設計等に仕込む<br />

こと(ㅎ:ㄷQualityㄩC:Costㄩㅁ:Deliveryㄦ<br />

5<br />

Copyright 2012 FUJITSU LIMITED


アヸキテクチャの目的と特性<br />

アヸキテクチャはㅎCㅁを解決するための手段<br />

スケーラビリティ<br />

負荷の増減に応じて、柔<br />

軟に性能や機能を対応さ<br />

せられること<br />

移⾏性<br />

環境変化に応じて、柔軟<br />

に機能を対応させられる<br />

こと<br />

拡張性<br />

利⽤環境の変化に応じて、<br />

性能・機能拡張が容易な<br />

こと<br />

変更容易性<br />

ニーズや変更要求に合う<br />

ように容易に修正・カス<br />

タマイズできること<br />

アーキテクトがこれらをいいトコ取りして、複数の目的を最大化することで解決<br />

アヸキテクチャの特性<br />

アーキテクチャ<br />

再利用性が高いもの 抽象度が高いもの<br />

6<br />

Copyright 2012 FUJITSU LIMITED


事例紹介<br />

アーキテクチャで規定しているもの<br />

アーキテクチャが崩れる時<br />

【事例1】派生開発<br />

【事例2】スケーリング<br />

アーキテクチャがなぜ崩れたか<br />

7<br />

Copyright 2012 FUJITSU LIMITED


アーキテクチャで規厶定しているもの<br />

機能分割の結果生まれる外部と内部のうち、主に外部を定義<br />

外部 内部<br />

部分間の相互作单用と各厰部分の外勭的特厣性勯<br />

アーキテクチャで規定しているもの<br />

論理的構造/時間的構造<br />

静的構造/動的構造<br />

表現するもの 内 容<br />

コンポーネント レイヤ、プロセス、タスク、モジュール<br />

コンポーネントの<br />

外勭的特厣性勯<br />

共厗有卻リソース、エラー処叀理/特厣性勯、<br />

パフォーマンス特厣性勯<br />

コンポA<br />

コンポB コンポC コンポD<br />

構造とインタフェース(実装方法は未定義)<br />

8<br />

基匼本設勳計匧<br />

詳細設勳計匧<br />

アーキテクチャでは<br />

規定していない<br />

コンポーネント内部<br />

を規定しないことで<br />

抽象度を⾼める<br />

Copyright 2012 FUJITSU LIMITED


アーキテクチャが崩れる時<br />

派生開発の繰り返し<br />

構造の劣化による再利用率の低下<br />

インンタフェヸス変更による再利用率の低下<br />

ハヸドウェア改変等でのスケヸル未達<br />

ハヸド・ソソフトインンタフェヸス変更による影響<br />

プロセッッサやㅌSㅐアヸキテクチャ変化による影響<br />

大がかりな機能追加<br />

元のアヸキテクチャ構想が解らずに機能追加する<br />

そもそも基礎工事のやり直しが必要だった?ㄼ<br />

元の構想の理解不足や、今後の変化の考慮無しに変更している<br />

9<br />

派生開発 ⇒ 事例1<br />

スケーリング ⇒ 事例2<br />

Copyright 2012 FUJITSU LIMITED


【事例1】 派生開発 ~アーキテクチャの目的~<br />

大規模開発をサブシステム分割、シリヸズ製品対応をサブシステム<br />

内で閉じようとした<br />

ユヸザインンタフェヸス系<br />

通信系<br />

コンポA<br />

コンポC コンポB コンポD<br />

リソソヸス<br />

対応制御<br />

プラッットフォヸム系<br />

通信<br />

制御<br />

ロヸドバランンス<br />

制御<br />

実行<br />

制御<br />

アクセス<br />

制御<br />

10<br />

制御系<br />

ハヸド<br />

ウェア<br />

制御<br />

目的<br />

ユヸザインンタフェヸ<br />

スのココンントロヸルを<br />

吸収<br />

実行制御やリソソヸス<br />

対応制御でスケヸリ<br />

ンング<br />

他ネッットワワヸク機器<br />

とプラッットフォヸムを<br />

共通化<br />

Copyright 2012 FUJITSU LIMITED


【事例1】 派生開発 ~変厭更によるアーキ崩れ~<br />

再利用率の低下<br />

①:ㄷ階層越えのインンタフェヸス<br />

• レスポンンス向上のためロヸドバラ<br />

ンンサに対して直接制御<br />

• 次の派生開発でレスポンンス低下<br />

②:ㄷ依存関係の増加<br />

•ココンンポCㄩㅁからの実行制御と、<br />

上位へのデヸタ依存<br />

ユヸザIㅆ/Fㅃ系<br />

通信系<br />

コンポA<br />

コンポC コンポB コンポD<br />

リソソヸス<br />

対応制御<br />

プラッットフォヸム系<br />

通信<br />

制御<br />

ロヸドバランンス<br />

制御<br />

実行<br />

制御<br />

アクセス<br />

制御<br />

制御系<br />

ハヸド<br />

ウェア<br />

制御<br />

「ココンンポB+実行制御+ロヸドバランンサ」の組み合わせによる再利用量が減少<br />

11<br />

①<br />

②<br />

②<br />

Copyright 2012 FUJITSU LIMITED


【事例2】 スケーラビリティ ~アーキテクチャの目的~<br />

プロセッッサやㅌSㅐ変更を睨み、デヸタ通信処理をスケヸラブルにしよ<br />

うとした<br />

ユニット1<br />

CㅍUㅒ<br />

CㅍUㅒ<br />

ユニット2<br />

ㅋㅍUㅒ<br />

機務器1<br />

CㅍUㅒ<br />

試去作单 製品厍<br />

ㅋㅍUㅒ<br />

・ㆀ・ㆀ・ㆀ<br />

CㅍUㅒ機能をㄮチッップに統合<br />

CㅍUㅒ機能の一部をㅋㅍUㅒにオフ<br />

ロヸド<br />

機務器間通信勼<br />

12<br />

ユニット3<br />

CㅍUㅒ<br />

ㅁSㅐㅍ<br />

機務器2<br />

ㅁSㅐㅍ<br />

試去作单 製品厍<br />

ユニッット㄰CPUはOS変更によるイ<br />

ンンタフェヸス変更あり<br />

ユニッット㄰からユニッットㄮへの機能<br />

配備変更(試作時計画ありㄦ<br />

Copyright 2012 FUJITSU LIMITED


【事例2】 スケーラビリティ ~変厭更によるアーキ崩れ~<br />

スケヸラブルで無くなった<br />

機器間、ユニッット間の通信層とのインンタフェヸス(通信方式ㄦを変更<br />

•メッッセヸジパッッシンングがオヸバヘッッドと担当が問題視、共有メモリ方式でバグ対処した<br />

•設計当初の目論見とは異なる共有メモリ方式のため、デヸタレヸスペナルティにより<br />

スケヸルしなくなった<br />

再利用性が落ちた<br />

ㅌSㅐ統合に備えていたAㅍIㅆインンタフェヸスを変更<br />

•インンタフェヸス部のオヸバヘッッド削減のための変更<br />

•ㅌSㅐのメモリモデル(仮想アドレッッシンング/リアルアドレッッシンングㄦ差分を吸収するインンタ<br />

フェヸスの変更<br />

※かなり大雑把に一般化すると<br />

複数処理を下位層に実行させる時の<br />

インンタタフフェーヸス変更ㄥ単発/ㄬ複数ㄦ<br />

13<br />

上位層機能<br />

下位層機能<br />

上位層機能<br />

下位層機能<br />

Copyright 2012 FUJITSU LIMITED


アーキテクチャがなぜ崩れたか<br />

ソフト改変したソフトウェアエンジニアによる振り返り<br />

再利用構想が解らなかった<br />

派生開発における再利用対象のココンンポヸネンントが設計書で<br />

読み取れなかった<br />

ㅌSㅐ統合の目論見がある中で、候補ㅌSㅐ毎のインンタフェヸス<br />

規定点のメリッットなどが解らなかった<br />

変更時の禁則事例が示されていると良いと思った<br />

インンタフェヸスの実現手段の目論見が解らなかった<br />

将来採用予定のプロセッッサ、ㅌSㅐにおいてメッッセヸジパッッシンン<br />

グ方式の方が有利であることを理解できていなかった<br />

実行制御の内部の仕組みを理解できていなかった<br />

仕組みによるメリッット<br />

改変による影響、デメリッット<br />

14<br />

アヸキテク<br />

チャ目的・<br />

構想<br />

インンタ<br />

フェヸス<br />

手段<br />

ココンンポ内部<br />

の仕組み<br />

Copyright 2012 FUJITSU LIMITED


アーキテクチャ取り組み事例<br />

アーキテクチャが崩れる要因<br />

アーキテクチャ崩れ防止への取り組み<br />

ドキュメント強化内容<br />

崩れ防止のためのフォーメーション<br />

アーキテクト育成の3つの方法<br />

15<br />

Copyright 2012 FUJITSU LIMITED


アヸキテクチャが崩れる要因<br />

アーキテクトの意図(目的・構想)が伝わらない<br />

親の心、子知らず<br />

その心が伝わるような設計書でない、または伝えてない<br />

目論⾒を意識せずコンポーネントインタフェースを変更<br />

場当たり的な変更で、インンタフェヸスを変えてしまう<br />

特にバグ改修や、処理性能等の改善によるプログラム改変時<br />

コンポーネント内部の仕組みの理解不⾜<br />

アヸキテクチャは抽象度を高くするため、ココンンポヸネンント内部までは言及しない<br />

設計の都合で疎結合だったものが、デヸタ関連性で密になる<br />

目的てんこ盛りのため、バランスがとれなくなる<br />

スケヸラビリティ vs 移行性<br />

16<br />

Copyright 2012 FUJITSU LIMITED


アヸキテクチャ崩れ防止への取り組み<br />

ドキュメンンテヸションンからの㄰つの取り組み<br />

アーキテクトの意図(目<br />

的・構想)が伝わらない<br />

目論⾒を意識せずコン<br />

ポーネントインタフェー<br />

スを変更<br />

コンポーネント内部の仕<br />

組みの理解不⾜<br />

目的てんこ盛りのため、<br />

バランスがとれなくなる<br />

設計意図<br />

再利用戦略<br />

17<br />

施行中<br />

変更<br />

変化に応じた変更<br />

方法を定義<br />

禁則<br />

インンタフェヸス等の<br />

変更によるアヸキ<br />

崩壊を例示<br />

再利用<br />

市場要求とソソフト<br />

ウェア実装との対<br />

応を定義<br />

Copyright 2012 FUJITSU LIMITED


ドキュメンント強化内容<br />

変更<br />

アヸキテクチャの目的・意図を示す<br />

変動要素毎に、変更方法を定義する<br />

禁則<br />

採用してはならない変更方法を定義する<br />

デメリッットも合せて示す<br />

再利用<br />

ㅊFㅃㅉ(Marketing Feature Listㄦ<br />

変化に応じた変更方法を伝える<br />

崩れる例を伝える<br />

変化に応じた再利用対象を伝える<br />

18<br />

before after<br />

詳細ㄯにて分割した<br />

機能等を定義、再利<br />

用可能なものを抽出<br />

固定部の構造やインン<br />

タフェヸスと、変動部<br />

の変動要素を定義<br />

Copyright 2012 FUJITSU LIMITED


崩れ防止のためのフォヸメヸションン<br />

ソソフトウェアアヸキテクトの役割をㄯ分割(大規模の場合ㄦ<br />

崩壊抑止要因をステヸクホルダヸ間合意事項にマッッピンング<br />

専門家およびエンンジニアが必要に応じアヸキテクトにフィヸドバッック<br />

海<br />

構造<br />

ココンンポ間<br />

機能分割<br />

方式<br />

アーヸキ<br />

テテククトト<br />

方式厚アーキテクトが定義<br />

専門家匝が変厭動要勥因に対する<br />

対応厸方法を実装アーキテク<br />

トにフィードバック<br />

ププロロママネネ<br />

再利用<br />

プロマネが定義<br />

変更 禁則<br />

ソソフフトトウェア<br />

エンンジニニア<br />

固有技術<br />

専門家<br />

実装<br />

アーヸキ<br />

テテククトト<br />

アーキテクトとともにト<br />

レードオフ 波<br />

19<br />

インンタフェヸス<br />

手段<br />

内部設計<br />

実装アーキテクトが定義<br />

専門家匝がインタフェース媒体等<br />

動向匇含め、実装アーキテクトに<br />

フィードバック<br />

Copyright 2012 FUJITSU LIMITED


アヸキテクト育成の㄰つの方法<br />

欧米との決定的な違いがある「品質を⼼配する意識」を日本<br />

の強みと認識し、これをベースに育成(⼈的擦り合わせ)<br />

上級アーキテクトによる育成<br />

いいトココ取り(トレヸドオフㄦの技術を伝承<br />

機能分割の技術を伝承<br />

固有技術の専門家による育成<br />

設計勘所の観点<br />

固有技術の将来動向<br />

プロマネによるサポート<br />

最後まで面倒を見させる<br />

ソソフトウェアの再利用戦略を教える<br />

20<br />

経験に基づく指導<br />

設計や品質の勘所を<br />

インンプッット<br />

経験させる場を提供<br />

Copyright 2012 FUJITSU LIMITED


まとめ<br />

アーキテクトが解決すること<br />

ㅎCㅁを解決するために、再利用性を高めるように仕込む(機能分割がキモㄦ<br />

継続的目的達成のためにアヸキテクチャをキヸプ、インンタフェヸスを頑固に守る<br />

アーキテクチャを崩さないようにするために<br />

変化に応じた変更方法を予め定義して設計書に織り込む<br />

市場要求とプラッットフォヸム変化を含めたソソフトウェア実装対応を定義<br />

アーキテクトの育成<br />

周りも育てる(プロマネ/上級アヸキテクト/固有技術専門家ㄦ<br />

21<br />

Copyright 2012 FUJITSU LIMITED


ご清聴ありがとうございました<br />

22 Copyright 2010 FUJITSU LIMITED

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!