実録オブジェクト指向開発プロセス

2006/12/07読み始め
2006/12/09読了
UMLが開発でどう使われるかを知りたくて購入。前半がRUPについての小説と後半が補足解説。
小説は、前のプロジェクトのデースマーチで後輩が帰らぬ人となってしまった40手前の毒男が、大学時代のバツイチ女性に偶然出会うも、前の旦那とよりが戻って逃げられる。小説後半の主人公の榊原氏（どっかで聞いた名前だ）が後輩の結城広志（どっかで聞いた名前だ）たちのモチベーションを下げてしまい、プロジェクト終了後にチームが半壊状態になり、常時処方されている抗うつ剤の量が増えるといった部分が印象にに残ってしまった。実話ベースらしいが、このへんは実話であってほしくない。デスマーチで帰らぬ人となった後輩が、密かに書き残した遺書（パーミッションがsuでないと読めないようになっている）ドキュメントを引用。
./forYou/testament

美しいプログラムを書きたい。
鋭利な機能美でも、装飾に彩られた美でもなく、
見ただけで、
読んだだけで、
「美しい」と感動できるプログラムを、
どうしたらかけるのだろうか。

（中略）

美しいプログラムを書きたい。
自分の納得のいくプログラムが書けたら、
そして、そのプログラムに感動してくれる人がいたら、
僕は死んでもいい。
それまでは死ぬわけにはいかない。

（中略）

もし満足のいくプログラムが書けたら、myPortrait.cというファイルにsaveする。
万一、僕が死んだら、このファイルを探してほしい。
ファイルがあれば、僕が思い残すことはなにもなかったのだと思ってほしい。
そして「美しい」と感じるか、試してみてほしい。
僕が目指したものに共感してもらえたら、僕は満足だ。

解説部分では「本文では記述されていないが」というような箇所がいくつかあった。もっと解説と結びついてほしかったな。小説中で著者の人生観を語るようなページが結構あった。解説部分はピアソンの本（『ラショナル統一プロセス入門 (Object Technology Series)/最新は『ラショナル統一プロセス入門 第3版 (ASCII Software Engineering Series)』？）の図が多く引用されていた。
小説前半をちょっとメモ

• Write Once Document（メンテされないドキュメントを揶揄する言葉）
• 機能一覧には優先順位を
• クラス図はユースケース単位のものとドメインモデルを
• 保守や管理をする人もアクタとして抽出する（システム管理者/運用管理者）
• バッチ処理のアクタはスケジューラ
• 同じ情報に対するCRUDは１つにまとめて「○○を管理する」のようにする。CRUD別にユースケースを作ってもほとんど同じオブジェクトがやり取りすることになり、後で結局まとめることになる。
• イベントフローには必ず主語を入れる。
• イベントフローではUIに依存する表現は使わない。後で修正する可能性が高いし、ユースケースの目的と要求がわかりにくくなる。
• UIに関する仕様は、画面イメージと画面仕様書を作成して明確に分ける。
• 分岐ではないフローも代替フローとして記述する。対象とするオブジェクトが同じかどうか。
• 例外フローを推敲フェーズで追加
• 裏プロセス
• ビジネスユースケース
• アクティビティを標準化/アクティビティを概念化する

実録!オブジェクト指向開発プロセス