機能要求を仮のドメインとし、各仮ドメインを実現するのに必要な知識領域を洗い出し、あらためてドメイン候補とした。
1で得られたドメイン候補の内容を定義した。具体的には、ドメインごとにそのドメインの定義、機能要求のマッピング、（明らかであれば）非機能要求との関係をリストアップした。また、その情報を基にドメイン候補間の依存関係を図式化し、類似したドメインをグループ化した。
おのおののドメイン候補を精査した。具体的には、処理そのものと、1つの知識領域とはいい難いドメイン候補がないかをチェックし、必要なものを分割した。また、ドメインとすべきでないものが混入していないかを確認した。

手順：ドメイン定義

　なお、必要な知識を洗い出す作業は、結果的にドメイン内のエンティティ候補を洗い出すエンティティ分析に近い作業となります。そうすると、サブシステム分割より前に実質的なエンティティ分析を行ったことになりますが、この順序の方が、エンティティ（＝データ）の取り扱いが重要な設計課題であるSoC開発に合う手順である可能性が高いとも考えられます。

　さて、このドメイン定義で得られたものは、

ドメイン定義リスト
ドメイン間の関係図

となります。

　通常のeUMLではデバイスを制御する組み込みソフトウェアを対象としていることが多いため、ドメインはある程度定型化されています。これは、先にも述べたとおり、組み込みソフトウェア本体、ユーザーインターフェイス、（デバイスとの通信）メカニズム、デバイスの各ドメインのことです。

　しかしながら、SoCのこの段階での分析では、ハードウェア／ソフトウェアの分割が確定していない（と仮定している）ことに加えて、必要とされる知識がより多岐にわたるため、定型にはめ込む形でのドメイン分割は避けました。この結果、先々得られるであろうサブシステムとドメインが必ずしも多対一関係とはなりません。欠点として、このことが、ドメインの境界のあいまいさを招き、機能のドメインへの割り当てを難しくしてしまいました。

　このドメイン定義での問題は、ドメイン境界のあいまいさのようなやむを得ない問題だけでしょうか。ドメイン境界があいまいであるという認識が、モデリングをする開発者間の共通認識とはなっていないという別の問題が発生する危険性があります。この問題は後々の分析作業に混乱を引き起こす可能性を高めますので、せめて定義の誤解を避けるためにドメインに明確な名前を付ける、話し合いであいまいさを共通認識としておくなどの工夫が必要になります。

ドメインの例：
メモリカードIF
ステータス管理
画像バッファ管理
表示
現像処理
JPEG処理
RAW処理
色
内部メモリ
バス

一覧：ドメインの例

　これらは、ドメインの一例です。繰り返しになりますが、ドメイン名だけでは分かりにくいものが多いため、ドメイン定義リストを用意し、その中できちんと中身を定義しておく必要があります。

サブシステム分割

　サブシステム分割では、ドメイン定義で得られたドメインのうち、開発単位として大き過ぎるものについて、それらを開発しやすい単位（サブシステム）に分割します。分割のポリシーはデータ構造や機能ごとなど、さまざまな方法が選択できますが、サブシステム同士がなるべく疎になるようなポリシーを選択して、それに従って分割することがポイントとなります。サブシステムは、ドメイン定義と同様にクラス図のパッケージで表します。

　サブシステム分割での実際の作業は、次のとおりです。

ドメインごとに、分割ポリシーを選択した。選択した分割ポリシーは下記の3種類。
　a）データ構造に着目し分割
　b）機能に着目し分割
　c）分割しない
ドメインをサブシステムに分割。
得られたサブシステムをレビューし、必要に応じて前工程にフィードバックした。

手順：サブシステム分割

　1について、少し詳しく説明します。a）のデータ構造に着目した分割は、ドメインを取り扱うデータ（＝エンティティ）と、それらに対する機能（＝制御）の観点から整理しました。データはステレオタイプが<<entity>>のクラスとしてエンティティ・サブシステムにまとめ、機能は機能ごとにサブシステム化して<<control>>クラスを格納しました。

　b）の機能に着目した分割では、機能のアルゴリズムに着目し、その処理手順をそれぞれサブシステム化しました。例えば、先ほどのドメインの例におけるJPEG処理では、DCT変換や間引き、ハフマン圧縮などがそれぞれサブシステムとなります。

　そして、特に分割する必要がないものはc）の分割しないを選択しました。この基準は、ドメインの段階ですでに開発を進めるのに支障のない大きさ、つまり開発チームのスキルから見て、ドメインの規模がまとめて開発するには大き過ぎないサイズであることとしました。

　ただし、隣のドメインとの境界があいまいな場合は、境界を明確にするために最低限どちらかをサブシステムに分割しました。

　3では、ドメインへの機能要求割り当ての見直しをしています。見直しの1つ目は、洗い出されたサブシステムの動作を開始するきっかけ（トリガ）がドメイン内に見当たらないことによって発覚したケースです。このケースは主として機能に着目したポリシーで分割した際に起きました。2つ目は、サブシステムの属性を洗い出す過程で、その情報を取得する機能の不足が明らかになったケースです。このような場合には、ドメインの機能要求を見直す必要がありました。

　ドメイン以外へのフィードバックとしては、ユースケースへのフィードバックがありました。サブシステム分割の結果、複数ドメインで同じクラスが登場するケースがありました。この時点で、なぜ重複が発生したかを議論した結果、1つのユースケースが複数のドメインに割り当てられているために機能も重複してしまったというものでした。

　このケースについての対処方法は、重複した機能のどちらかを削除するのではなく、ユースケースをドメインごとに分割することでした。ユースケースにナンバリングし、それを使ってドメインとの対応を明示することもサブシステム分割で行いましたが、これはモデリングをする開発者間でのコミュニケーション上、とても重要な役割を果たしました。

　サブシステム分割で得られたものは、

サブシステムを表現したパッケージ図

となります。

　サブシステム分割の進め方、分割ポリシーなどは、通常のeUMLとの差異は特にありません。ただし、この作業のスタートポイントとなるドメインの在り方は大きく異なるため、主に前工程へのフィードバックの作業が大きく違うという結果となりました。

　最大の違いは、今回のサブシステム分割は実質的にドメインごとの境界の再定義作業を含んでいたという点です。すなわち、ドメイン定義の段階では明確にできなかったドメイン間の境界を、サブシステムレベルまで具体化するという手法で分析、明確化したことです。この良しあしは別として、これが今回のサブシステム分割の最大の特徴となりました。