【連載】概念モデリングを習得しよう：資源の競合を解決する「割当子」と状態遷移表、リファクタリングへの活用（第24回）

これまで説明してきた果樹園にかぎらず、何らかの資源を使って作業を行うような主題では、有限の資源について、複数の作業からの割当要求に対する競合が、必ず生じます。

資源の競合を解決してやらなければ、未作業状態の放置やデッドロックが生じてしまいます。

これまでの解説に使った概念モデルは、論旨を明示するため、収穫という、ごく一部分だけを記述したものでした。実際の状況を、もっとよくよく想像してみれば、リンゴの栽培中にも、似たような競合はあるはずです。他にも、商品販売という概念ドメインでの注文に対する在庫商品の割当てや、製造管理における、製造ライン、あるいはそれに並ぶ各装置の製品組み立てへの割当てなど、さまざまな概念ドメインで頻繁に現れます。

競合解決には、これまで説明してきたように、競合する資源群の割当てを、まとめて管理する概念クラスが必要です。

概念モデリングでは、この概念クラスのことを、“割当子”または“アサイナー（Assigner）”と呼びます。競合の解決は、上から順番に処理を行っていくだけのシングルスレッドのプログラムコードや、データフローモデルによるアクション記述では解決できません。

資源要求、資源追加をイベント生起と捉えて、資源の割当てを担当するような、割当子の状態モデルが、必ず必要です。

アクションなどの詳細は、概念ドメインそれぞれの詳細によって異なりますが、収穫リソース割当の状態モデルで示した骨格は、さまざまな概念ドメインの競合解決が必要なケースで、パターンとして再利用できます。概念モデリングでは、このパターンを“アサイナーパターン”と呼んでいます。

状態モデルも含めた概念モデルのパターンは、“Art of Conceptual Modelingの虎の巻”で紹介しているので、ぜひご一読ください。

補足になりますが、競合状態が生じることを初期に見逃したのは、ただ一つだけの樹木を想定したシナリオで、シミュレーションを行ったのが原因でした。シミュレーションのシナリオを作る場合には、概念情報モデルのリレーションシップの多重度を参考にすると抜け漏れが防止できます。

今一度、状態モデルを眺めてみましょう。

一見すると、このモデルで概念インスタンスの振舞いの様相が全て記述されているように見えますが、実は、このモデル、いまだ曖昧な部分が残っています。
例えば、樹木の状態機械が、状態“4.収穫中”にあるとき、イベント“FT2:収穫予定日確定”が生起されたらこのモデルはどんな振舞いをするでしょう？
このモデルには、このことに関する一切の記述が存在していません。

“無いなら、その時々の適当な判断でいいのでは？”

いえいえ、そんな考えは、現実世界の意味の構造を忠実に記述することを目指す概念モデリングにおいて、許されるものではありません。日常生活においても、そんな判断が時に重大な事態を招くこともあります。

図に示した樹木の場合、このイベントは多分無視してかまいません。

しかし、樹木が状態“1.栽培中”にあるとき、イベント“FT3:収穫開始”が生起された場合はどうでしょう。この場合、なっているリンゴが収穫可能でもないし、収穫作業に必要なリソースも確保されておらず、プロセス的に間違ったことが生じている恐れがあります。現実世界でのこのような事象の生起は許されません。

概念モデリングでは、それぞれの状態で生起したイベントに対して、

• 遷移（遷移先の状態）
• 無視（Ignore：IG）
• 起こりえない（Can’t Happen：CH）

のどれであるかを現実世界の様相に照らし合わせて決定し、表形式で記述します。

行方向に状態を、列方向にイベントを並べます。概念インスタンスを生成する生成イベントがある場合は、最初の行に“(No State)”と書き、概念インスタンスが存在していないことを示します。それぞれのセルは、概念インスタンスが、その行の状態にあるときに、列のイベントが生起したときの遷移先の状態名を、もしくは、無視の場合は“IG”、起こりえない場合は“CH”と書き込みます。この表を状態遷移表（State Transfer Matrix）と呼びます。
状態遷移表を記述することによって、概念クラスの出来事の生起に対する厳密な振舞いの表現が可能です。
状態遷移表は、全ての状態モデルに対して一つずつ作成します。
状態遷移表を作っていく過程で、場合によっては、図の状態モデル上で遷移線として書くべきだった状態遷移を見つけるかもしれません。その時は、基になっている状態モデルを素直に見直して、抜け漏れ・間違いがある場合は、適宜、モデルを修正することになります。

状態遷移表は、概念モデルを使ったシミュレーションにおいても使用します。シミュレーションは現実世界の動的変化の写しなので、CHのセルに出くわすことはあり得ません。現実世界で起こりえないのが CH なのですから当たり前でしょう。
しかし、実際のシミュレーションでは、CHを引き起こすイベントを表すポストイットがホワイトボードに張られる場合があります。その原因は、

• シミュレーションの手順が間違っている
• 作成したモデルが間違っている

のどちらかです。シミュレーションの実施は、かなり煩雑な作業であるため、特に人手で実施している場合には、原因が前者であることは十分考えられます。
手順を丁寧に点検し、前者が原因でないことを見極めたうえで、モデルのどこが間違っているかを考えて、モデルに対して適切な修正を施しましょう。

状態遷移表を作るうえで、状態モデル図上に遷移の記述ではないセルに対し、IG、CH のどちらなのかを決める時に、あえて、IG、CH の両方をあてはめて考察するのは良いプラクティスです。モデル化対象世界で、それがどういう様相に対応することになるのか、改めて検討してみましょう。それにより、取りこぼしていた重要事項を発見することもあります。このプラクティスは、抜け漏れや、想定外という言い訳ミスを防ぐ、良い処方箋になるでしょう。

もしかすると、モデル化対象の世界の変化が、概念モデルをひな型とした、事象の生起による圏I のモデルの変化で記述できるという説明が、腑に落ちない読者が一定数いるかもしれません。リモート制御された、空を飛行して、ある目的地に向かっている、ドローンを想像してみましょう。ドローンは、重力と空気の流れの影響を受けながら、時々刻々と位置と姿勢が変化していきます。それを眺めている人は、ある時点のドローンの位置や姿勢、目的地との相対位置を、言葉を乗り物とした思考を行うでしょう。
その思考を記述したものが圏Iのモデルです。重力や空気の流れによる位置や姿勢の変化が事象であり、リモートからの指示もまた事象です。それらの事象が生じた後の時点もまた、同様に圏Iのモデルとして思考されるでしょう。この時、眺めているものがドローンであると、なぜ思っているのでしょう。

それは、あらかじめその人がドローンに関する概念を持っている、つまり、概念モデルで記述されたスキーマを習得しているからです。そのスキーマに、リモート制御や空気の流れという事象が発生したときの変化のルールも含まれているから、ドローンの飛行の状況を追っていることになります。その人は、スキーマである概念モデルを習得していなければ、見ているものは、UFOのような未確認物体として映るでしょう。

また、事象の生起の前後の圏Iのモデルは、それぞれの時点で、網膜に映った映像がさまざまな化学・電気反応を経ながら神経細胞を通じて、人間の頭の中に作られることになります。この時、事象生起前のドローンと、生起後のドローンが、同一であると判断できている事実も、考えてみれば不思議です。ドローン以外でも、部屋に置いてあるテーブルの周りを巡りながらテーブルを見ている時、全く異なった形をしているのに、それが同じテーブルだと判断できている、あるいは、水面から突き出ている棒が、水面で折れ曲がっているのに、それがまっすぐな棒であると自然に判断できる、等々、よくよく考えると人間の思考には不思議なことがたくさんあるでしょう。実際、これらについて真剣に真摯に考察を行っている哲学の一分野もあるくらいです。大抵、この手の問題は疑似問題と言って、まともに相手にする必要はないのですが。

これらの問題は、アイデンティティの識別に関する情報も含んだ、習得済みの、スキーマたる概念モデルを使って、事象生起前の圏I のモデルが記憶として構成され、概念モデルに従って予測（シミュレーション）しながら、事象生起後の圏Iのモデルを構成しているからだと、筆者は考えています。

人間は、日常において、このような思考を意識的に、あるいは半自動的に自然に行っているものです。つまりは、概念モデリングの体系＝人間の思考の形をモデル化したものである、とご理解ください。

ここで、概念モデリングそのものからは、外れてしまいますが、ソフトウェアリファクタリングで状態モデルを活用するプラクティスを紹介しておきたいと思います。

リアルタイム機器制御にしろ IT ソリューションにしろ、ソフトウェアは一旦出来上がってしまったら、未来永劫に渡り、変更なく使えるものではないことは、皆さんご存じのことでしょう。ソフトウェアから全ての不具合を取り除くことは原理的に不可能なので、不具合が発見されれば修正が必要です。

ユーザーがソフトウェアを利用することにより、新たな機能要求も生じます。また、ソフトウェア開発当初は妥当だったサードパーティー製のミドルウェアのアップデートへの対応が生じたり、コスト・パフォーマンスの観点から別のベンダーのミドルウェアへの変更もあり得ます。これらを含めたさまざまな事由により、ソフトウェアは継続的な変更作業が必要になるものです。

万一、変更を怠れば、ユーザーに本来しなくてよいはずの障害回避作業を強いたり、他の企業との比較において相対的なパフォーマンス低下を引き起こしてしまうでしょう。既に出来上がっているソフトウェアが“ソフトウェア資産”と呼ばれているのをよく耳にしますが、必要な変更を怠っているソフトウェアは、利益を生み出す“資産”というより、相応の利息が生じる“負債”と言った方が適切でしょう。

ソフトウェアを変更する際、その都度、部分的、かつ、場当たり的な修正を加えていくと、システム全体は、いわゆる、“おんぼろ煙突”と呼ばれる状態に陥ってしまいます。それを防ぐには、修正がしやすい整然としたアーキテクチャの下でソフトウェアが開発されていなければなりません。

しかし、従来型の多数の人が同時並行で書き上げたコードの集大成で構築されたコードが、一発目で、そのような奇麗な構成になっていることは、まずありません。障害対応や機能追加の際、現状のシステム全体を見渡して、必要であれば、モジュール分割やアーキテクチャも見直して修正していくことを、“ソフトウェアのリファクタリング”と呼びます。

一応は、一定水準以上の品質で既に動作しているソフトウェアを改変するリファクタリングにおいて、リファクタリングを行う前と後で、そのソフトウェアがシステム外（ユーザー）に提供している機能は不変でなければなりません。

生成系AI がコードを生成してくれる昨今、そのうち、リファクタリング対象の全てのソースコードを生成系AIにぶち込んで、“リファクタリングされたコードを生成して”とプロンプトに入力しさえすれば、整然としたコードが短時間で得られる未来が来るかもしれません。たとえそうなったとしても、出力されたコードの妥当性をどう評価するか、課題は残り続けます。

リファクタリングを行う機会が訪れたら、以下の手順を試してみてください。

1. システムに対するユーザーの指示をリストアップする
   (ア) それぞれの指示に付帯する変数群も明らかにする
   (イ) リアルタイム機器制御の場合、ユーザーの指示は、ハードウェアからの割込み処理などに適宜読み替えてください
2. それぞれのユーザーの指示について、その指示をトリガーとしてシステム内で実行される一連の処理を洗い出す
   (ア) 処理はどこかで完了するはずなので、完了するまでを洗い出す
   　　①どんな形式でも構わないが、図示するならアクティビティ図や相互作用図が妥当
   (イ) 起動から完了まで値が変更されたデータ変数のうち、処理完了後もシステム上で保持されるデータ変数をリストアップする
   (ウ) 処理の起動から完了までの間の、システム外への応答をリストアップする
3. 結果をモデル化する
   (ア) 2. -（イ）のデータ変数のうち、ユーザーの観点から意味のあるデータ変数を収集して、概念情報モデルを作成する
   　　①ユーザーの観点ではないデータ変数については、どんな意味の場の変数化を考えて分類すればよい
   (イ) 2. -（イ）を概念情報モデルで定義された概念クラスの状態モデルとして再構成する

この作業を通じて、ユーザー（リアルタイム機器制御の場合は制御の骨格）に対して提供している機能の観点から見た、そのコード群が“何をなしているのか”に関する厳密なモデルが出来上がります。

このモデルは、このコラムで後程解説する“変換による実装”に用いることで、別の非機能要件を満たす、新たなアーキテクチャに適合するコード一式の生成も可能です。

このやり方は、リストの管理でExcel を使いながら、筆者が過去実際にやってみた経験をもとにしたものです。“変換による実装”を実践しない場合でも、リファクタリング後のソースコード一式が満たすべきテストモデルとして役立つだけでなく、システムの要求仕様書としても活用が可能です。

もちろん、大規模なコードの場合、この作業は、かなりの人手と工数を費やさなければなりませんが、負債を資産に変えるには、相応の投資が必要なのは言うまでもありません。

しかし、自然文から状態図を生成してくれるような生成系AIも実際に存在しているので、手順の1.～2. の作業は、生成系AIの活用で（半）自動化が可能なように思えます。

次回は、「ユースケース」を取り上げます。概念モデリングの視点から、より良いユースケースモデルの作り方を考察します。