維持モデル
ソースコードではない抽象度の高い方法でのプログラムの表現方法のうち、長期的に維持されるもの、Keeps 対義語は臨時モデル。設計の議論や会話のために一時的に作られるもの モデルとは？
この文脈では:
会話のためのもの
共通理解のためのもの
見て会話が起こらない図解は良いモデル化ではない
そう考えると、口頭での会話や文章でのやりとりではコミュニケーションに支障がある場合に、それを補佐する目的で作られる図解だと言える これがしばしば有用なのはソフトウェアプロジェクトに限らないように思う
具体的には下記が提案された
ユースケースメカニズム: ユーザーストーリーを実現するためにソースコード上で何が行われるかの記述 コミュニケーション図、シーケンス図
設計の理由
コードは存在するが維持モデルが存在しない状態での、維持モデル作りの最初の一歩は？
用語辞書の作成
ドメインモデルに相当する
ある言葉が、このプロジェクトではどういう意味で用いられているのか、の記述
この認識にバラツキがあると
会話に支障が出る
まちまちな意味で使われてソースコードの検索に支障が出る
特に、ドキュメントに日本語で書かれて、コードに英語で書かれてる時に、その対応づけを間違えたり、定番の訳語があるのに気づかずに新しい訳語で実装して検索から漏れたりする
用語辞書の段階ではまだ「図解」ではない
用語の意味を記述していくうちに、それが別の用語で解説される
ここで「用語間の関係」が言語化される
エンティティ間のリレーションである→ER図
この段階での「用語」「概念」は必ずしもクラスに1対1対応しない