前回は、独立ツールとして考えていた構想から、Obsidianプラグインへ切り替えた理由を書いた。
今回はその続きとして、Obsidian版で最初に何を作ることにしたのか、そしてそれをどういう考え方で形にしたのかを書いてみたい。
Obsidianを土台にすると決めたあと、最初から全部を扱おうとはしなかった。
まず形にしたのは、ER図とクラス図だった。
理由は単純で、この二つは「テキストで構造を持ち、それを図として確認する」という考え方を試すにはかなり相性が良かったからだ。
ER図もクラス図も、単体の要素と、それらの関係で成り立っている。
そして人間にとっては、テキストだけで読むより、図として見た方が全体像をつかみやすい。
Model Weaveでやりたかったことを、最初に試す対象としてちょうどよかった。
まずはER図とクラス図から始めることにした
Obsidian版で最初に実装対象として絞ったのは、ERとClassだった。
Model Weaveでやりたいのは、図を手で描くことではない。
設計の意味をテキストで持ち、その内容を図や文書として見やすくすることだ。
そう考えると、ER図とクラス図は最初の題材としてかなりわかりやすい。
ERであれば、テーブル、カラム、インデックス、リレーションがある。
Classであれば、責務、属性、メソッド、関係がある。
どちらも構造化しやすく、かつ図で見たい情報でもある。
まずこの二つを扱えるようにすれば、テキストを正本にして図を派生させるという基本方針が、実際に使えるものになるか確認できる。
その意味で、最初の実装対象としてはかなり自然だった。
図より先に、単体の定義ファイルを正本にした
最初に決めたのは、図を正本にしないことだった。
ER図やクラス図というと、どうしても「図そのもの」を中心に考えたくなる。
ただ、それをやってしまうと、設計情報が図の中に閉じてしまう。
Model Weaveでは逆にした。
まず単体の定義ファイルを作る。
ERであれば er_entity、Classであれば class がそれにあたる。
そこに、カラムや属性、メソッド、関係といった意味のある情報を置く。
diagramファイルは、それらの単体定義を束ねて表示するためのビューとして扱う。
つまり、図は正本ではなく、テキストから生成される見え方の一つという位置づけになる。
この考え方にしておくと、設計資産として扱いやすい。
単体の定義ファイルはそのまま読めるし、差分も見やすい。
必要に応じて、同じ定義ファイルを別のdiagramから再利用することもできる。
図を作るためにテキストを書くのではなく、設計をテキストで残した結果として図が出る。
ここはかなり大事な考え方だった。
ERとClassは、似ているようで持ち方が少し違った
ER図とクラス図は、どちらも「箱と線」で表現できる。
だから最初は、同じような形式で扱えるようにも見える。
ただ、実際に考えていくと、情報の持ち方は少し違った。
ERでは、テーブル同士の関係はテーブル定義にかなり強く結びついている。
たとえば、注文テーブルが顧客テーブルを参照するなら、その関係は注文テーブル側の定義として持っていた方が自然だ。
そのため、ERでは er_entity 側に自分から出る関係を持たせることにした。er_diagram は直接relationを持たず、対象となるentityを並べ、各entityから関係を集約して図として表示する。
一方でClassは少し違う。
クラス単体として自分から出る関係を持たせたい場合もあるし、特定の図の中でだけ見せたい関係もある。
そのため、class 側には自分自身を起点とするrelationを持たせつつ、class_diagram 側でも図全体の関係を定義できる形にしている。
このあたりは、無理に統一しすぎない方がよかった。
ERにはERの自然な置き場所があり、ClassにはClassの自然な置き場所がある。
同じ「図を出す」機能でも、正本の置き方まで同じにする必要はない。
この判断は、後からかなり重要になってくる。
なぜなら、テキストベースのモデリングでは「どこに何を書くか」が、そのまま保守しやすさに直結するからだ。
この話は少し掘り下げたいので、次回あらためて書くつもりだ。
図を出すだけでなく、詳細もそのまま見られるようにしたかった
ER図やクラス図が表示できるようになると、次に欲しくなるのは詳細情報だった。
図で全体像を見る。
気になった要素の詳細を見る。
そこから関連する要素へ移動する。
この流れができないと、図はただの静的な画像に近くなってしまう。
Obsidian版で目指したのは、図を見るだけのビューではなく、テキストで書いた設計情報を辿れるビューだった。
たとえば、diagramで対象のオブジェクトを見て、その詳細や関連を右側で確認する。
必要なら、その定義ファイルへ移動して直接編集する。
編集した内容をまた図として確認する。
この往復ができると、図は単なる説明資料ではなく、設計作業の入口になる。
ここは、独立ツールを考えていたころのビュー設計がかなり活きた部分でもある。
一覧、詳細、図、関連表示を行き来するという考え方は、Obsidian版になってもそのまま必要だった。
作ってみると、実装より「使い勝手」の方が気になってきた
ER図とクラス図がひとまず表示できるようになると、次に気になってきたのは使い勝手だった。
図のサイズはどうするか。
最初にFit表示するのか、100%表示を優先するのか。
右ペインにどの情報を出すと読みやすいのか。
関連オブジェクトはどのくらい表示すると便利なのか。
WarningsやErrorsはどこに出すと邪魔にならないのか。
このあたりは、実際に画面を見ながらでないとわからない。
実装前は「図が出ればかなり便利になる」と思っていた。
でも実際に触り始めると、図が出ること自体は入口でしかなかった。
大事なのは、その図を見ながら設計を読み、違和感に気づき、必要な定義へすぐ戻れることだった。
つまり、表示できるかどうかより、設計を読み進める体験の方が重要だった。
この段階まで来ると、ツールとしては少しずつ面白くなってくる。
コードとして動くものを作る段階から、実際に使いながら調整する段階に入ってきたからだ。
この先は、DFDや画面仕様にも広げていきたい
ERとClassを最初に作ったことで、Model Weaveの基本的な考え方はだいぶ見えてきた。
単体定義ファイルに意味を持たせる。
diagramはそれを束ねて見やすくする。
図は正本ではなく、テキストから派生するビューとして扱う。
そして、人間がレビューしやすい形で表示する。
この考え方は、ERやClassだけで終わるものではない。
次の対象としては、DFDやdata_objectがある。
DFDでは、ERやClassよりも「流れ」が主役になる。
そのため、単体のオブジェクトだけでなく、どこからどこへ、どんなデータが流れるのかをdiagram側でどう扱うかが重要になる。
さらにその先には、画面仕様や処理、ルール、マッピングのような設計情報もある。
ここまで広げていくと、Model Weaveは単なるER図・クラス図ビューアではなく、設計情報を横断して扱うための基盤に近づいていく。
ただ、その前にもう少し整理しておきたいことがある。
それが、今回少し触れた「relationの正本をどこに置くか」という話だ。
ERではentity側に置く。
Classでは単体定義とdiagramで役割を分ける。
DFDではflowをdiagram側に置く。
この違いは、単なる実装都合ではなく、それぞれの図が何を表現したいのかに関わっている。
次回は、この「関係の正本をどこに置くか」という話を、もう少し掘り下げてみたい。
コメント