実践的オブジェクト指向分析・設計と実装 (続き その2)

最終日は昨日より難易度の高い例題でほぼ 1日演習でした。対象は自動通話分散システムで、複数のオペレータと外線が登場し、レースコンディションの発生する問題でした。

最初からほとんどアドバイスのない状態で 2人 1組でモデルを考えていきます。途中ランチにもでたので、分析/設計に要した時間は 3-4 時間ほどでしょうか。途中間違った方向にも進みましたが、最終的にはなんとか実装に落ちる設計にたどり着けました。

一見長いようにも感じますが、すっきりした設計にしあがり、ユースケースを満たす上で疑問になる部分がすべて解消されているので、実装に落とすのはけっこう機械的な作業になります。最初に時間はかかりますが、手戻りが少ない分、作業に無駄がないですし、分析/設計に自信ももてます。

分析/設計において重要だったのは、初日からのキーメッセージどおり、

• オブジェクトレベルで考え、
• ユースケース実現の詳細度をあげる

に尽きました。オブジェクトレベルで多重度、関連を具体的にイメージし、無駄のないもたせ方を検討します。そして、ファンクションがコールされる流れをイメージし、ユースケースがちゃんと満たされていくことを確認します。

文章にしてしまうとこれだけなのですが、実際に演習を通じて手と頭を動かしてみると、なかなか思うようにはいかないです。
もっと素振りをして身体に馴染ませる必要がありますね... (^^;

以下は、初日からのメモの抜粋です。
講義の隙間隙間で先生がいろいろな話をしてくださったので、それを含めてのメモです。

• ラーニングツリーの講座
  • 日本では PM 系が多く、技術系の講座が売れない
  • 企業でのオンサイト講座がメインで、今回のような公開講座は希少
  • 米国などでは技術者の流動性も高いので、年間 6回ほどは講座参加の支援がないと企業から離れていくらしい

• オブジェクト指向で大事なのは？
  • デザインパターン
  • オブジェクト指向分析/設計
    • この部分が十分に理解されていない (教えにくいためでもある)
  • クラスライブラリ

• C++
  • スタックに積まずにレジスタ参照するので高速
  • オブジェクト指向な設計では、アクセス経路が直接的ではなくなるのでその分は遅い
  • ただし、構造を把握しやすいのでメンテナンス性はよい

• 多重度
  • B -----> A
  • 0..*　　0..1
  • 左: 任意の A のオブジェクト 1つ "を" 参照する B のオブジェクトががいくつあるか
  • 右: 任意の B のオブジェクト 1つ "が" 参照する A のオブジェクトがいくつあるか

• オブジェクト指向分析
  • Rumbaugh の提唱した名詞抽出は役に立たない
  • Jacobson のユースケース分析
    • ちなみに彼はエリクソン出身! Joe Armstrong といい、北欧すごいな..
  • Rumbaugh、Booch、Jacobson が RUP を生みだしたが、名詞抽出は含まれていない

• RUP
  • RUP はアルゴリズムではない、魔法の杖でもない
  • 開発法のステップ間のギャップが大きいので、知識/技術/経験で埋める必要がある
  • RUP は指針であり、かなりの部分はプログラマの能力に依存
  • その旨も明記されている

• 仕様と分析/設計
  • 仕様は「what」で、分析/設計は「How」
  • 正しい/正しくないは、仕様に対しての実装
  • 仕様自体に正しい/正しくないはない、あるのは良い/悪いくらい
  • 良い/悪いは教育しにくい (フィードバックをかけづらいので)
  • ある意味才能、その才能をもつ者の発想をいかに早く実現するか

• 機会損失
  • やる/やらない、いずれも決定
  • やらないという決断をした場合の機会損失も当然ある
  • 日本ではやると決断したときの責任だけ追求、だから皆やらない

• ユースケースの単位
  • トランザクション、状態の変わる単位できるといい

• ユースケース分析/設計
  • シーケンシャルにしかできない
  • 少数精鋭で検討する
  • オブジェクトで考える
    • 頭のなかでメモリ上に展開
  • ユースケース実現の詳細度をあげる
    • インデックスサーチは高価
    • ファンクションコールは高価
  • 大事なのはモデル化できるかどうかで、UML に詳しくなってもしょうがない
  • ファンクションの中身は記述しない
    • 一度書くと (気持ち的に) 消しづらくなるので、最終段階で書く

• 上流下流の分離
  • 工場ではうまくいっていたので、丸投げ文化の助長
  • システムではうまくいかない
  • 難しい部分を実装までアーキテクト、それ以外を開発者
  • Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている

• 多態性
  • オブジェクトはインテリジェンスをもっている
  • 結合度を下げるためにメッセージパッシング

• デザインパターン
  • 継承はコンパイル時の結合
  • 関連は実行時の結合
    • コンパイル時の結合は実行時に比べて強い
  • 結城先生のデザパタ本は素晴らしい
  • あれのおかげで日本人のデザパタに対する理解は世界トップレベルかも!?

• OJT
  • 知識をつけてから OJT をすると効果的
  • そうでないと通り過ぎてしまう

• 作家
  • 小さい頃にどれだけ本を読んでいたかが重要
  • 書くことは重要ではない
    • むしろ、早くから書き過ぎると型にはまってしまう
  • プログラムも同様、綺麗なソースをたくさん読みましょう

• MINIX
  • 数万行なので読むのには手頃
  • カンザス大学の (水野先生の) 講義のなかで一番評価が高い
  • 仮想メモリは使っていないが、それ以外の基本的な OS の機能はおさえられる
  • virtual box にはいる

• アーキテクチャとは
  • キーユースケースに対する分析モデル
  • 設計モデル
  • 配布モデル
  • 実装モデル
  • 非機能要件
  • 実装して動かすことが大事

• 繰り返し開発
  • アプリに依存しない部分 (ミドルウェア)
  • キーユースケースのアプリ固有機能
  • 次のキーユースケースのサブセット
  • アーキテクチャの実装/検証/決定に、全体の 30% の時間と労力をかける

• アーキテクトの立ち位置
  • PM でない
    • PM とツートップの権限
    • リスクを見つけられないひとがリスクの管理をしてもだめ
  • 管理部門からの心からのサポートが必要 # ここが日本で弱い
  • フィードバックを受け入れる

• フェーズ
  • 方向付け (ビジネス観点、アウトライン、機能の選択)
  • 推敲 (アーキテクチャの決定、計画/費用の見積り)
  • 作成
  • 移行
    • とくに方向付けでは、分野ごとの専門家が集らないと本質的な問題の解決には至らない

• テスト
  • テストケースは仕様 (ユースケース) から導出されるべき
  • 実装コードをみてテストがつくられるのは本末顛倒
  • 仕様 → 設計/モデリング → 実装コードの流れと平行して、仕様 → テストケース → テスト実装

• 契約
  • 最初に詳細なユースケースまではやはり決まらない
  • 実装をはじめてから擦り合わせていくことも重要
    • ここで上下関係がはいってきてしまうのが日本
    • 米国の場合は、契約で縛ってしまう
    • 両者の中間的なところが落とし所か..

• デバッグ
  • できるだけしない
  • 失敗した設計のもとでは、かなりの時間がパッチあて (ハッキング)
  • 日本では優秀な人は火消しになり、米国ではアーキテクト
    • そうじゃないと市場の流動性が高いのでやめてしまう

• スーパースター
  • 理論的な知識、バックグラウンド
  • どんな環境でも動かす
  • スーパースターを育てる、権限を与える
  • 自分で提案して、自分で開発 (アイデアを具現化する能力)