データモデリングと状態遷移図

連載第5回の記事を本格的に考え始めた。とはいえ締め切りが2週間後なので、今日の段階では気持ちも文章も極めてノリが悪い。

第4回はイベントのモデリングの基本編をテーマにした。今回は応用編として、在庫や後続イベントを取り上げる予定である。記事を書くのは毎回苦しむが、今回はいつにも増して難所になりそうな予感がする。理由は取り上げる2つのパターンが、同僚の河野さんの指摘で追加したものだからである。(id:ahirasawa:20050523)

もっとも最近は連載を書くペースもある程度固まってきた。最初の週末で3つの練習問題の題材を考えて、パターン以外で議論すべきネタを1つか2つ仕込む。次の週末は練習問題を記述する。しかし3つは無理で、最初の2つぐらいで力尽きる。とはいえここまで来るとエンジンがかかっているので、続く平日5日間の通勤電車の中で3つ目の練習問題は書けてしまう。最後の週末は余裕で推敲して終わる。だいたいこんな感じだ。

そして今日は、最初の週末の日曜日である。しかし3つの練習問題のアイデア出しで行き詰まった。題材はいくつか思いついたものの、記事全体の話がつながらない。ブツ切りの話3つで終わりにするのはイマイチである。加えて、イベントをモデリングするときの自分の思考回路をアウトプットできる気がしない。

いろいろ考えた末に、状態遷移のモデリングを説明しないことが原因とわかった。データモデリングの場面でも、イベントは時間の経過で状態が変化することがしばしばある。たとえば、受注が売上や失注になったり、予約が販売になったりキャンセルされたりするケースだ。そんな場合には状態遷移図（UML2.0ではステートマシン図と呼ぶらしい）を書いて仕様を確認するのが常套手段である。

自分の中では、第1回の記事で「この連載ではクラス図しか使わない」と書いたことが引っかかっている。さかのぼって嘘をついてしまうことになるが、この際仕方がない。あの文章を書いたとき、「もしかしてステートマシン図は使うかも知れないけど、まぁいいか」と思ったことを今さらながら思い出した。やっぱり連載を書くのは難しい。

昔、大作家が十年以上かけて書いた大河小説を1週間ぐらいで一気に読んだ時、話のつじつまが微妙にずれているのに気づいたことがあるが、こういうことだったのかー。