ICONIX

ちょっと思うところあって ICONIX プロセスについて調べてみた。

ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series)

分析クラスを boundary、control、entity (BCE) と分類することがよくあります。
自分は、ユースケースをどのようなコンポーネント構成で実現するか、また各コンポーネントが果たすべき責務は何かを整理する道具として、BCE のクラスを使用するのですが、ICONIX の手法はちょっと異なるようです。
ICONIX では、ユースケース記述から機能を抽出する道具として、BCE のクラスを使用しているようです (ロバストネス図)。各オブジェクトの粒度も細かく、画面のボタンも個別の boundary となっており、control も個々の処理レベルでクラスが抽出されています。ICONIX では、このように抽出した BCE のクラスを、次の工程でシーケンス図を書きながら、あらためて設計クラスに割り当てていきます。control は残しても良いけれど、テキストの例では、boundary、entity のいずれかに割り当てるのが正攻法のようです。
また、ロバストネス図とは別に静的なクラス図を書いており、こちらは属性と関係だけを記述し、操作は、シーケンス図を書くまで記入してはいけないとのことです。
BCE というと、ICONIX が有名ですが、個人的には少し違和感がありました。

ではでは、そもそも boundary、control、entity と言いはじめた Jacobson は何といっているのか? 原典の OOSE の該当箇所を読んでみた。

オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ (アジソン ウェスレイ・トッパン情報科学シリーズ)

しかし、より複雑な use-case ではこの2つの種類のオブジェクト (boundary と entity のこと) に当てはまらない振舞いが存在する。そのような振舞いは制御オブジェクト (control) に置かれる。
(中略)
制御オブジェクトは1つの use-case を形成するオブジェクトを結び付ける糊のような働きをする。
(中略)
最初のドラフトでは、それぞれの抽象 use-case とそれぞれの具象 use-case に対して1つの制御オブジェクトを割り当てる。

自分の使い方はこちらに近いかなと思いました。ただし、OOSE でもボタンを boundary としていたり、control のライフサイクルを、1つのユースケースの実行中としている点は自分と違いますが。

以上、自己流で使うのは別にかまわないと思うけれど、ちゃんと原典は押さえておいた方が良いですね。