維持モデル

• ソースコードではない抽象度の高い方法でのプログラムの表現方法のうち、長期的に維持されるもの、Keeps

  • 対義語は臨時モデル。設計の議論や会話のために一時的に作られるもの

• モデルとは？

  • この文脈では:
    • 会話のためのもの
    • 共通理解のためのもの
    • 見て会話が起こらない図解は良いモデル化ではない
  • そう考えると、口頭での会話や文章でのやりとりではコミュニケーションに支障がある場合に、それを補佐する目的で作られる図解だと言える
    • これがしばしば有用なのはソフトウェアプロジェクトに限らないように思う

• アジャイル時代のモデリングでこの言葉を知った

• 具体的には下記が提案された

  • アーキテクチャ　パッケージ図、クラス図
  • ドメインモデル　クラス図、ER図
  • キーユースケース
    • ユーザ視点のもの: 代表的な使い方(ユーザーストーリー)　ユースケース図
    • ユースケースメカニズム: ユーザーストーリーを実現するためにソースコード上で何が行われるかの記述　コミュニケーション図、シーケンス図
  • 設計の理由

• コードは存在するが維持モデルが存在しない状態での、維持モデル作りの最初の一歩は？

  • 用語辞書の作成
    • ドメインモデルに相当する
    • ある言葉が、このプロジェクトではどういう意味で用いられているのか、の記述
    • この認識にバラツキがあると
      • 会話に支障が出る
      • まちまちな意味で使われてソースコードの検索に支障が出る
      • 特に、ドキュメントに日本語で書かれて、コードに英語で書かれてる時に、その対応づけを間違えたり、定番の訳語があるのに気づかずに新しい訳語で実装して検索から漏れたりする
    • 用語辞書の段階ではまだ「図解」ではない
    • 用語の意味を記述していくうちに、それが別の用語で解説される
      • ここで「用語間の関係」が言語化される
      • エンティティ間のリレーションである→ER図
      • この段階での「用語」「概念」は必ずしもクラスに1対1対応しない
        • オントロジー図という言葉で表現されてた
    • 意味を記述すべき単語を見つけるための手段としてソースコードの単語頻度を分析することが提案された