********************************************************************** セッションS2-c チュートリアルテーマ：入門ソフトウェアプロダクトラインコーディネータ: 岸知二（早稲田大学）日時：9/3 9:00〜10:20 参加人数：約30人 ********************************************************************** 再利用：あるソフトウェエアの一部、設計や、要求のすぺくを含めて広い意味での資産を別のソフトウェアの開発に利用する。再利用は古い歴史がある。いろんな技術がある。再利用をしない開発というのはあまり考えられないが、苦労している。フレームワークとかどう使うのかがわからないと難しい、そこに行き着くまでが難しい。再利用への期待、開発リソースの有効利用、上流の考え方を再利用しないと企業が回らない。期待感が増す。保守コストが増えるとはどういう意味でいってるか、再利用部分のソースコードが利用できない場合には保守コストが増加する。再利用のジレンマソフトウェアの設計や部品を他のソフトウェアに使う。部品を作ってる人にとっては多くの人に使ってもらいたい。より汎用性、抽象性を高くする必要がある。しかし汎用過ぎると生産性はそこまで揚がらない。逆に特定利用にすると、使う側はすごくメリットがあるが、多くの人には利点がない汎用性と特定のトレードオフが大事。使う側と使われる側のアーキテクチャが不整合だとあまり意味がない。再利用を解決するのは大変アドホックな再利用をしても有効性に限界がある →思いつきで再利用している限り・・・アーキテクチャ上の不整合 →再利用側と開発側を整合させないとだめプロダクトラインの開発に期待すべての再利用曲面に使えるわけではない。組込み系の事例が多い。エンプラ系でも増えてる・ソフトウェアプロダクトライン SEIでの定義：プロダクトラインとは共通の管理された特徴を持ち、特定のマーケットやミッションのために、共通の再利用資産に基づいて作られる、システム集合。プロダクトライン上の製品は共通のアーキテクチャ上で作られる。・開発の全体像図、上部分が再利用資産を作る、下の方が資産を作って個別のプロダクトを作る。左要求、アーキテクチャ→個別のスコーピング：プロダクトラインの範囲をきめる上部分ドメインエンジニアリング、下部分アプリケーションエンジニアリング再利用資産のことをコア資産という。・共通性と可変性プロダクトラインで大事なこと共通性(commonality)と可変性(variability) プロダクトラインでは可変性の管理が大事。製品によっては違うかもしれないところ、可変性。 SEIの人は可変性を別に使ってる、製品ごとのアビリティーと定義してる、製品ごとの違う能力。何が共通性で何が可変性かを捕らえて、概念的なものをモデル化して、作りこむ。わかるだろう、という思い込みは危険。明示化していく。認識できたらまずモデル化する。・内部的な/外部的な可変性外部的な可変性 →顧客から見える可変性 →最初はそこから決まっていく内部的な可変性 →技術的側面、外部的/内部的な可変性のリファイン・開発の流れ RUPにおけるスコープ：自分の作ってるものの範囲範囲とは：与えられたスペック以外を考えないのは稀、言われたもの以外にこの範囲まで適用できるようにしようという範囲がスコープ。・プロダクトラインに置けるスコーププロダクトの内側と外側をきめる。プロダクトライン中のプロダクトがやりとりする実態や共通性や可変性を決定する。・スコーピング技術者が勝手にやるってことではない、技術者の独断で決めない。技術者のプライドが高いので作ったプロダクトを少しでもいいものにしたい。ビジネス的にみると毎回芸術作品を作られても仕方ない。いろんな人の立場で考えないといけない。スコーピング：Boschは3種類のスコーピングを提案プロダクトポートフォリオスコーピング →開発されるべき製品やキーとなるフィーチャを決めるドメインスコーピング →ドメインの協会を決めるアセットスコーピング →再利用のためのコンポーネントを決める・FODA フィーチャを識別し共通性・可変性をモデル化する手法スコーピングすると範囲が見える捕らえた共通性と可変性はきっちり明示化例：フィーチャーモデルでフィーチャの可変性・共通性を階層的に表すモデル・フィーチャカテゴリフィーチャの観点で領域をわけて階層化したり構造化したり・フィーチャインタラクションシステムへのフィーチャの追加・削除が、他のフィーチャへ影響を及ぼすフィーチャモデル作って簡単にいけばいいけどそうはいかないフィーチャは独立した問題ではなく、根深い問題・OVM フィーチャモデルだけではないクラスコールなどはOVMというのを提唱してる全部フラットに書けなくて階層化できないヨーロッパではこっちも使われるこっちがでてくる可能性もあるかも・PLA：プロダクトラインアーキテクチャソフトウェアアーキテクチャ →ソフトウェアおよびその開発を支配するソフトウェア構造や構造化の原則すべてのプロダクトラインの包括的なアーキテクチャ・概念フレームワークパワーポイントアーキテクチャ、レイアウト書いてるけど、意味がわからないこれじゃいけない。 4 + 1ビュー 4つの重要なビュー論理構造：実行構造：ランタイム開発構造：どういうものを作ってるかプログラム自身配置構造：どう配置するかもう一つ大事なのはアーキテクチャは動かなさないとわからないが、後から修正できない部分もあるので予め決めないといけない部分がある。実証をしていかないといけない。実証メインで、リスク管理や今ある情報の中でどの方法が安全かを選ばないといけない。・プロダクトラインアーキテクチャの設計スコーピングを十分かつ明示的にする。製品だけでなくプロダクトラインへの要求の考慮する。可変性管理や再利用アプローチ。・アーキテクチャスタイル、大事なキーワードアーキテクチャを設計するときにどこに悩んだポイントがあるのが大事再利用のアプローチ →いろんなやり方、いろんな形態があるプラットフォームをそろえる →共通部分に注目する →共通部分だけじゃなくて可変部分に注目する →組み合わせれば次々とプロダクトラインができる可変点と実現と結合タイミング →考え方が一貫していることが大事 →設計は一貫性が大事・製品の導出概念的なフィーチャモデルからアーキテクチャ設計してコンポーネントできるのが大事・MDD モデルを中心に吸えた開発形態一つの捕らえ方高級言語から、より抽象度があがった感じ。 MDDの適用例：普通のアプリモデルに変化点を持ったモデルを組みあわせる。段階的な構成、段階的なステップ。 MDAは徐々に制約を強くしていきコード生成する。 ●質疑応答Ａ現在、プラットフォーム化をしているのですが、25ページのプラットフォーム →プロダクトライン→ファミリの順でやるのか岸さん Boschはそのつもりだと思います。Ａプラットフォームかするにはドメインを決めないといけないけれどプロダクトラインをきめないとだめでは？岸さんドメインの意味が少し違う、そこのドメインは共通機能を認識するという意味のドメイン。Ａあまり実感がわかない。岸さん同じ作ってるものを整理しましょうという意味。プロダクトラインは10個のうち3個は違うけれどそういう可変性のあるものもやっていこうということ。Ｂ山口長期的なビジョンをもってればいいが、次がわからないような状況だと適用できるのか。岸さん程度問題、製品計画がみえてなくてもどういうテクノロジー領域でいくのかがわかっていればあるていどプロダクトライン的な開発ができるかも。以上。