新人SEの学習記録

14年度入社SEの学習記録用に始めたブログです。もう新人じゃないかも…

学習記録:データモデリング(1)

[Java] Javaの学習

内容:8章 データモデリング

データモデル
  • ある特定のビジネス上の概念や、アプリケーションのデータを保持するためのオブジェクトの集合
  • このオブジェクトをデータモデルオブジェクトと呼ぶ
    • ex) Customerクラス:ビジネス上の顧客情報を格納
    • <-> Pointクラス:データを含むオブジェクトだが、特定のビジネス上の概念ではない
  • ビジネスデータは神聖であり、破壊されると多大な損失が発生=通常のオブジェクトとは区別するべき
要求仕様書
  • システムの全ての特徴を明記したもの
  • 反復プロセス
    • 以下の繰り返し
    • 顧客の望んでいるものと完全に一致しているか
    • 顧客からの変更要求
    • 仕様書に反映
  • どのような開発も、要求仕様書なしに進めてはいけない
    • 顧客が仕様書を読みたがらないときは・・・
      • 1) 「変更がなければこの通りのものを構築します」
      • 2) 承認(署名入り)を要求
  • 顧客にはビジネスのすべてを説明してもらうべき
    • 顧客はコンピュータの専門家ではなく、開発者は顧客の分野の専門家でない
    • ビジネスとコンピューティングの世界の橋渡し
    • ギャップを埋める、専門用語を使わず比喩を用いる
自然言語モデリング
  • 名詞の集合
    • データモデルはアプリケーションの名詞の集合である
    • 要求仕様書を「主要な名詞フィルタ」に流し込むと、アプリケーションのデータモデルが抽出される
  • 名詞を時化別したら、オブジェクトの階層構造に体系化(+必須でない項目を排除)
  • 書籍中の例
    • オンライン小切手口座、普通預金口座、クレジットカード口座、ローン口座
    • 振替、対外振替
    • 自動支払い
    • 取引
    • 従業員、銀行職員、口座名義人、顧客
適切なデータモデルの特徴
  • ゴーストクラス
口座 ---- 資産口座 ---- オンライン小切手口座
      |      |-------- 普通預金口座
      | 
      --  負債口座 ---- クレジットカード口座
             |-------- ローン口座
    • 資産口座は何のパラメータも持っていないが、サブクラスが資産だということを表す
    • こうすることで、ある顧客の資産のみに操作をする場合に有効
    • フラグで管理した場合、新たな種類の口座を作る際に追加が面倒
  • 適切な関係
    • 1)is a 関係
      • 「〜は〜である」「〜は〜の一種である」(継承)
      • オンライン小切手口座は、口座の一種である
      • 顧客は、人の一種ではない
    • 2)has a 関係
      • 「〜は〜を持つ」(集約)
      • 顧客は人(の情報)を持つ(人は顧客の一部を成す)
      • 人の属性:名前、性別...
      • 顧客:上記の属性に加えて、口座、メール、パスワード...
    • 3)uses a 関係
      • 「〜は〜を使用する」(普通の関連)
      • 取引には口座を使用する
  • 基本型の問題
    • 全ての基本型にラッパークラスを使用した方が良い
    • 値がnullでもエラーとして扱わない場合がある
      • booleanだとtrueかfalseをとる
      • 発生していない取引については?? falseだと失敗扱いになる
      • Booleanならnullがとれる
    • 多少の高速性より、明瞭さと柔軟性を考えるとラッパークラスの方が良い
      • ==での比較などには注意が必要
可変オブジェクト
  • すべてのオブジェクトは2つに分けられる
    • 定数オブジェクト:性別オブジェクトなど
    • 可変オブジェクト:人や口座など
  • 可変オブジェクトには共通点がたくさんある
    • イベントに対するプロパティ変更をサポートする必要
    • Mutableオブジェクトを作り、全てのデータモデルオブジェクトの基本クラスとなるようにする
  • デフォルトのequals()では、同値ではなく同一で判断
    • Mutableを拡張したサブクラスでは、equals()とhashCode()をオーバーライドする必要がある
      • オーバーライドし忘れると、重大なバグとなる可能性
      • 基本クラスのメソッドを抽象化できる仕様を活かし、Mutableクラスで下記の2つをオーバーライド
      • public abstract boolean equals(Object obj);
      • public abstract int hashCode();
      • こうすることで、サブクラスはこれらをオーバーライドしないとコンパイルエラーになる

所感

  • 前章までと打って変わって、SEっぽい仕事話に
    • 顧客との立ち回りについてのテクニックなども
    • 仕事との関連的には一番重要な章かも?
    • しかし、書籍中の仕様書例からデータモデリングできるようになるまではかなり訓練が必要そうだ…
  • 継承と集約の関係が非常にわかりにくい
    • 顧客クラスは人クラスを継承していると言いたくなるが…
    • 顧客クラスは人クラスの情報に加えて、顧客特有の情報を持つと考えると少しわかる
  • ラッパークラスの使用やabstractを付けたオーバーライドなどのテクニックも覚えておきたい