satoshis 式ユースケース図のかきかた

ちょうどユースケース図をかいているところなので、ユースケースをかくときの思考パターンを紹介する。
会社では出入管理システムというのをあちこちに納入している。要は、カードリーダや指紋などで認証すると錠が解錠されるとか自動ドアが開くとかして入室/退室できるという、よくあるシステム。ドアとドアの錠(または自動ドア)と、ドアの両側にある認証機器をひとまとめにしてゲートと呼んでいる。ホストコンピュータからは、遠隔操作でゲートの開閉を行ったり、認証機器の有効化や無効化ができるようになっている。(この程度の話なら会社の製品紹介でも分かる範囲なので、ここに書いても問題無いだろう)
例えば、このシステムについてのユースケース図をかくとする。ユースケース図をかき始めたころは、思いつくままにたくさんの機能をユースケース図にかき出していた。例えば、出入管理システムの場合だと、
「ドアの開閉状態を表示する」
「錠の施解錠状態を表示する」
「認証機器との通信状態を監視する」
「認証機器との通信異常で警報を出す」
「ドアを施錠する」
「ドアを解錠する」
などなど。でも、そういう図をかいてもごちゃごちゃしてわかりにいだけだ。特に仕様書の最初にごちゃごちゃしたユースケース図があると、読む人の気分を害してしまう可能性が高い。
そこで。まずはシステムが達成しようとしている目的をひとつだけあげる。これができなきゃシステムの目的を理解していないということだ。出入管理システムの場合ではどうか。まず第一にあげるべきユースケースは、出入管理システムというシステムの名の通り
「人々の移動を管理する」
だろう。
前述した細かいユースケースたちは、「人々の移動を管理する」という親玉ユースケースの子分達だ。
では、最初に「人々の移動を管理する」ユースケースの次に、いきなり前述した細かいユースケースに分類するのもよろしくない。「人々の移動を管理する」というユースケースを、管理の手段である監視系と制御系に分類するのがよさそうに思う。というわけで「ゲートの状態を監視する」と「ゲートを制御する」という二つに分類する。
そうすると次の段階が見えてくる。ゲートはひとつドアと入室用と退室用のふたつの認証機器で構成しているから、「ゲートの状態を監視する」は、
「ドア状態を監視する」
「入室用認証機器の状態を監視する」
「退室用認証機器の状態を監視する」
に分類でき、「ゲートの状態を制御する」は、
「ドアを施錠する」
「ドアを解錠する」
「認証機器を有効化する」
「認証機器を無効化する」
などに分類できる。
ゲートを通過する対象を忘れている。人々がゲートを通過するんだけど、人々の移動を管理するためには、ひとりひとりがどこを通過できるのかを管理しなきゃいけないわけで、そのためには「人を管理する」というユースケースがあることがわかる。人を管理するには、
「個人データを登録する」
「指紋を登録する」
「通過可能なゲートを設定する」
などのユースケースが必要なことが分かる。
読み手にわかりやすい、整理されたユースケース図をかこうとすると、結局は構造化分析と同じようなことをやってたりする。