日々の破片

_ はじめよう! プロセス設計を眺めて

技評の細谷さんから羽生さんの「はじめよう! プロセス設計」を頂いたのでパラパラ読んだ。

とにかく図が多くて、明解だ。

ターゲットはビジネスプロセスを明らかにすることにある。そのために図を使いまくって仕事（語り得ぬもの）をプロセス（語り得るもの）に落とし込んでいく。

そうやって明らかになったビジネスプロセスはシステム化の射程に入る。(何気なくあとがきを読んだら、まさにそう書いてあった)

はじめよう! プロセス設計 ~要件定義のその前に(羽生 章洋)

ビジネスプロセスと言えば、以前Enterprise Architecture Using the Zachman Frameworkを読んだのを思い出した。

「はじめよう! プロセス設計」を読めば上位2層（最上位のスコープは自然とカバーされるので）については十分と思う（体感としての規模感）。

Enterprise Architecture Using the Zachman Framework (MIS)(O'Rourke, Carol)

で、本書の図を眺めているうちにいろいろ考えた（というわけで、以降は本書とはあまり関係ない）。

最近、あまりUMLという文字を見かけないが、どのくらい使われているんだろうか？

見かけないのは、あまりに当たり前に使われるようになったので、誰もあえて何かを言う必要がない（啓蒙期が過ぎた）ということなのか、それとも誰も使っていない（衰退期に入ったか過ぎたか）のか、どちらなんだろう。

UMLがおもしろいのは、えらくまちまちな粒度の図表が定義されているところで、そこがとても便利なわけだ。

ユースケース図を使って、何が何をさせるのかを定義する。

アクティビティ図を使って、「何をさせる」の内部の動作を定義する。

シーケンス図を使って、上から目線でおおざっぱなインタラクションを定義し、下から目線で細かな同期/非同期のインタラクションを定義する。

アクティビティの内部の状態変化をステートチャートで詳細化する。

その一方で、モデル図を使って実装用のモジュール分割を定義する（その前に配置図を使って、コンポーネントを定義（あるいは選択）していくというのもあったが、先にパッケージを決めるのか、パッケージの中身のクラスを決めるのかは、どうも流儀によるように見える。おれは関連するクラスを同一パッケージに入れて同一スコープで配置するべきと考えているが、もっと孤立させるのが好きな場合は、細かくパッケージを分けるのだろう）。

実際には、どの粒度でアクティビティ図を書くのか、シーケンス図を書くのか、配置図を書くのかは、ケースバイケースで相当異なるのだが、図がたくさん用意されていることは、いろいろな方向からシステムの全体像を考えるのにきわめて有用だ。