はてなはスターウォーズおたくの巣窟

それから僕にとっての「業務としてのスターウォーズ」の日々が始まり、昨日ようやく「II」を見終えました。そして今日は午後から休みをとって妻と二人で、はてなの皆より先に「III」を見てきます。

業務としてのスターウォーズって。。。(^^;
別に熱烈なスターウォーズファンじゃないけど、ここで紹介されてる「スター・ウォーズ トリロジー DVD-BOX」って、エピソードの IV・V・VI と特典ディスクがセット。ちょっと興味があるなぁ。

ぼやき

なんだか、次々に仕事が入ってきて、コードを書けない日々が続いてたりする。
書くのは仕様書と取説と設定ファイルばかりなり。
つまらん。。。
もうかるけどつまらない仕事ともうからないけどおもしろい仕事があれば、会社はもうかるほうを選択するのだ。
その仕事の中でなんとかモチベーションにつながるのは、JUDE でユースケース図や配置図などを描いて仕様書の中に埋め込んでいく作業くらいか。社内への UML普及促進のためのささやかな努力。

Happy Hacking Keyboard Lite2

そういえば。。。
昨日の午後、某協力会社の人と打合せをしたときのこと。とあるバカアプリのバカっぷりを見せてあげるのに、開発用パソコンの前に連れてきて見せていた。そのとき、その協力会社の人が
「いいキーボード使ってますね」
なんて、言ってたのを思い出した。彼は HHK のことを知ってて言ったんだろうか？

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

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

annex

別館という意味だったのか。今まで気にしてなかったよ。