連載 次世代開発基盤技術“Software Factories”詳解 第4回 フィーチャの実現法とサブジェクト指向パラダイム マイクロソフト株式会社　萩原 正義 2005/07/02
Page1 Page2 Page3

◆可変性を実現する先進的な開発手法「サブジェクト指向パラダイム」

　ドメインクラスは、OOパラダイムによる機能要求の論理レベル表現である。分析レベルでトップダウンにより決める「概念の名前」と、ボトムアップにより決める「概念の属性」を持ち、ユースケースの振る舞いを、論理レベルでのオブジェクト間のシーケンス図の協調パターンを見ながらドメインクラスの「操作」として割り当てる。いわゆる責務の配置である。協調パターンはデザインパターンの適用や特定アーキテクチャの利用を前提として決定する。

●ドメインクラスに見られるOOパラダイムの弱点

　だがこのドメインクラスは、同時にOOパラダイムの弱点を表している。システムが外部に提供するサービスや機能であるユースケースは、複数のドメインクラスを連携して提供される。また、1つのドメインクラスは、複数のユースケースの実行で共有して使用される（図7）。

図7 OOパラダイムの弱点：散乱（scattered）ともつれ合い（tangled）

システムが外部に提供するサービスや機能であるユースケースは、複数のドメインクラスを連携して提供される。図では2つのユースケースを例としている。いずれも複数のクラスのオブジェクトが連携して実現されている。これを散乱（scattered）という。また、1つのクラスは、複数のユースケースの実行で共有して使用される。図のクラス2に相当し、もつれ合い（tangled）という。OOパラダイムでは、この散乱ともつれ合いがプロジェクト管理を困難とする。

　通常、大規模開発チームの構成は、外部サービスであるユースケースの実現を単位とするため、ドメインクラスのコード共有管理の発生で、開発チーム間での調整が不可避となる。これが、開発のプロジェクト管理を難しくし、プロジェクトの成功確率を下げてしまうのである。

●OOパラダイムの弱点「散乱」と「もつれ合い」の解決策

　この問題を解決するには、プロジェクト管理的側面で対応するか、ドメインクラスのコード共有による依存性を回避する技術的側面で対応するかしかない。後者の対応では、ドメインクラスの設計を前提としない開発手法を選択するほかない。

　例えば、ユースケースを提供する際のシステムの役割を定義し、その役割をドメインクラスから分離する手法である。これが「ロール・モデル」と呼ばれる分析手法で、例えるなら、映画のシナリオ（サービス内容）では登場人物の演じる役割だけを先行して決定し、俳優へのキャスティングをシナリオの完成まで遅らせることに似ている。

　シナリオとしてのサービス内容の仕様が完全に確認できた後、その役割を演じる俳優（ドメインクラス）を選択する。もし俳優に問題があれば置き換え可能とする。確かに役割を演じることができる俳優には一定の資格が存在する。しかし、その資格は従来のドメインクラスの持つ操作よりも緩い条件で、シナリオ（サービス内容）に依存せず役割を持たない最小限の基本的な属性と操作だけを持つドメインクラスとする。これにより、従来のロジック・コードを実装するドメインクラスでのコード共有を最小化し、コード共有をプロジェクトの後半にずらすことができる。

　具体的にロール・モデルを使い、論理レベルのクラス図を設計した例が図8である。この例は、レンタル・ビデオ店でのビデオ貸し出し業務を示している。分かりやすくするために、各ビデオ・タイトルは1セットとしている。

図8 サブジェクト指向パラダイムによる設計の例（レンタル・ビデオ店）

図のドメインクラス、例えば、Customerクラス、VideoクラスからOOパラダイムの弱点である散乱ともつれ合いの問題を取り除くために、ユースケースに依存する操作を分離する。分離のためには、クラスがオブジェクトとして振舞う役割（ロール）を識別し、業務内容の意味的単位にまとめて1つの「サブジェクト」を構成する。サブジェクトとドメインクラスは開発チームを分けるなどして別々に開発し、開発プロセスの遅い段階で複合化技術を使ってマージすることで、従来のドメインクラスへの操作の割り当てによるコード共有管理の問題を回避すると同時に、サブジェクト単位の並行開発を実現する。サブジェクトを単位にして、ソフトウェア・プロダクトラインのフィーチャを提供する。現在では複合化技術の観点で、サブジェクト指向パラダイムはアスペクト指向パラダイムの一部となっている。

　この図では、ロールを業務内容の意味的単位にまとめて1つの「サブジェクト」を構成している。サブジェクトはユースケースを実現する機能のまとまりとなる。ユースケースはサブジェクトを組み合わせて実現する。

　例えば、「貸し出し」や「返却」をサブジェクトとする。サブジェクト（主観）とは、ステークホルダー*5（アクター）ごとの視点でのシステム表現であり、従来のオブジェクト（客観）がステークホルダーの視点に依存しない共通のシステム表現であることと対比される。

*5 システムの利害関係者。例えば、製品を購入する顧客や、利用するユーザー、製品を設計するアーキテクト、開発する開発者など、システムにかかわる人々。

●サブジェクト指向パラダイムの特徴

　サブジェクトとドメインクラスを分離して、それぞれに適切な振る舞いを割り当てることで、ドメインクラスへの操作の割り当てによるコード共有管理の問題を回避する。

　サブジェクトはほかのサブジェクトやドメインクラスと独立して開発可能なので、サブジェクト単位に開発チームを編成して並行開発を行うことが可能である。また、特定のサブジェクトを開発プロセスの遅い段階に定義し、追加することで、要求の決定を遅延させることが可能である。

　コンポーネント・モデルのインターフェイス定義が、インターフェイスを実装するクラスの提供する機能（提供インターフェイス）やほかのクラスを利用する機能（必要インターフェイス）の契約を定義するのと異なり、サブジェクトはクラスがオブジェクトとして実行される際のほかのオブジェクトとの関係で決まる役割を示す。すなわち、1つのクラスが複数の役割を実行し、その役割が動的に変化する場合に、サブジェクトを適宜実行することで対応可能である。

　このようなシステム開発を可能とするパラダイムが「サブジェクト指向」である。

　サブジェクト指向パラダイムは、OOパラダイムのドメインクラスと併存するので、OOパラダイムと組み合わせて用いられるマルチパラダイム・デザインの一種である。サブジェクト指向は、クラスと、クラスが持つメソッドを分離管理する発想であり、DOA（データ中心アプローチ）のエンティティ・タイプとデータ項目の分離管理に類似した、大規模システムに有効なドメインクラスに対する正規化技術である。

　すなわち、同一の意味を持つメソッドを論理的に統合する。大規模システムでは、同一メソッド定義（＝必ずしも実装は同一ではないが、シグネチャ定義が同一である）を持つ複数のドメインクラスが出現するので、メソッド定義を論理的に1カ所で定義することで数を減らして管理可能とするのは有効な方法である。

　サブジェクト指向はクラスとサブジェクトのウィービングの1技術であるので、現在はアスペクト指向の一部として発展しているが、厳密には両者が解決を目指す課題は異なる。サブジェクト指向の開発手法を実現するにはプログラミング・パラダイムとしてサブジェクト指向言語が必要であるが、サブジェクト指向言語が利用可能でないときは、より抽象レベルの高いDSL（ドメインに特化したモデル言語）がコード生成を行い、サブジェクト相当のコードを提供する。

　Software Factoriesは、プロダクトライン開発プロセスでサブジェクト指向パラダイムを強制しているわけではなく、サブジェクト単位のチーム・モデルもまた強制しないが、サブジェクト指向は開発手法としてOOパラダイムを補完する技術であり、アスペクト指向による複合化技術の一種として可変性の実現技術の選択肢となり得る。

◆残された問題

●ステークホルダーの多次元性の問題

　フィーチャ・モデルは、アーキテクチャ要求の可変性に着目したモデル表現でもある。しかし、アーキテクチャはその規模と適用範囲の大きさから多くのステークホルダーがかかわり、多くのステークホルダーの視点での表現が必要である。

　ステークホルダーごとに異なる関心の表現を、特定のドメイン分割を前提としたフィーチャ・モデルで表現できるだろうか？ 選択的なフィーチャにより可変性の表現ができるにしても、ステークホルダーごとの異なる視点で「関心の分離」を表現するには単純化しすぎていると思われる。個々のステークホルダーの視点での関心の分離の表現は、短期的視点のユースケースに対して長期的視点のフィーチャ・モデルを分離した要求定義の解決法とは別問題である。

　この視点の問題は、ステークホルダーの多次元性という。多次元性は現在のソフトウェア開発の要求の多様化に対応するために取り組まなければならない課題である。多次元性の問題は多次元的な視点を持っていないフィーチャ・モデルでは残念ながら解決できない。そのためにSoftware Factoriesはアーキテクチャ定義の「ビュー・ポイント」を使う。ビュー・ポイントの先進性については、次回で説明する予定である。

●問題領域のドメイン分割の決定法の問題

　もう1つの問題は、フィーチャ・モデルを作るための問題領域のドメイン分割の決定法である。

　先のドメイン分割の例では、業務内容に従った分割を行った。ドメイン分割では、視点やスコープの明確化、粒度（意味のまとまりの単位）の決定、抽象レベルの一貫性、できるだけ分割単位間で依存関係やオーバーラップがない直交関係を持つドメイン間の整合性や変更追跡性などを考慮する。

　ドメイン分割の決定は、フィーチャ・モデルに適合したアーキテクチャの品質に大きな影響を与える。Software Factoriesのプラットフォーム技術、開発環境の提供がなされても、問題領域に対する深い経験や知識を持ち合わせていなければ、有効となるドメイン分割法、フィーチャ・モデルの指針は決定できない。

　Software Factoriesではドメイン分割の一例として、発注、調達、製造、物流、会計、金融、取引先管理、顧客管理などの基本的な業務内容において、特定企業の業務プロセスに依存しない業務内容をサービス単位として切り出したビジネス能力（Business Capability）による決定法を現在検討中である。

萩原 正義 Software Architect

1993年マイクロソフト入社。北海道大学、早稲田大学非常勤講師。.NET開発、アーキテクチャの調査研究と技術啓蒙に従事。アスペクト指向、フレームワーク実装技術、開発方法論、データ中心アプローチとオブジェクト指向分析／設計との融合、モデル駆動型アーキテクチャ、サービス指向アーキテクチャなどが現在の興味対象。趣味は、IT業界の著名人との雑談とウインター・スポーツ。ソフトウェア技術の発展に貢献することが夢。

　

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第4回 フィーチャの実現法とサブジェクト指向パラダイム
	1．フィーチャ・モデルによるアーキテクチャの構築
	2．フィーチャ・モデルによる可変性の実現
	3．可変性を実現する先進的な開発手法「サブジェクト指向パラダイム」

　

「次世代開発基盤技術“Software Factories”詳解」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）