前置き
以下のイベントで【エアコン】を題材にしたモデリングを各自で行ってそれを見せ合いっこして、各々プレゼンするという演習をおこなってみた。
あえて今回は前提条件をそろえない という状況下でのモデリングを行った。
というのも前提条件をそろえないことによっての発見があるからだ。
モデルから前提の範囲を類推する
実際の案件でも体験していて思ったことだが、
前提条件がそろうまでモデリングができないなんてことをしていると、時間だけが過ぎ去って何も進まないからだ。
そこで出来上がったモデル図を通して、その作成者が置いている前提のスコープの範囲
を類推するという練習は非常に効果的であると独自に思っている。
成果物を通しての練習
私は今回エアコンの物理的な周辺環境との関係性という側面に着目してモデリングをした。
下図のマスター側と書かれた方のエアコンは、知識レベルに該当するエアコンの方だ。
そして実態側のエアコンの方は私たちがリモコンを使って実際に操作をする方。
これは【知識レベルと操作レベルの分離】というアナリシスパターンでは有名な手法だ。
そして大体多くの家では、一部屋に０もしくは１台のエアコンがある。
そのため、多重度は「０もしくは１」とした。
ここでなぜ室外機という概念を出さなかったというと、
室外機はたいてい室内ではなく、必ず外という空間にあるからだ。
そのためこのモデルには登場させなかった。
また、エアコンの冷風からドライモードや暖房に変えられるのが、
大半のエアコンであるため、Stateパターンを使った状態変更による振る舞いの変化をinterfaceで表現した。
この部分はほかの参加者の方と一緒であった。
前提の検証を常に
こうやって自分の置いている前提条件のあいまいな部分を明らかにしつつ、
常に検証を行えると、上級モデラーに近づいていける。
今回でいうと私は前提条件に「エアコンの配置された部屋という空間、コンテキスト境界内におけるエアコン」という前提条件を置いていることになる。
しかしながらそうすると、マスター側のエアコンはその境界内には通常存在しえないものであるため、このモデル図からは削除してあげた方がよりベターであるといえる。
なぜなら１枚の切り口(コンテキスト境界内)と思っていたモデル図に、
「エアコンの配置された部屋という空間」という切り口だけでなく、
「マスター側のエアコンと、実体のエアコンという関係性」という切り口の
計２枚のモデル責務が混在しているので、２重責務なモデル図となっているからだ。
１つのモデル図には、必ず１つの責務の切り口を描く
これをセオリーにすべきである。
こんな風にして前提条件を常に明確にしながら、
「でもその前提条件だとしたらここがおかしいよね」と批判的な思考を持っておこう。
揺さぶり
「揺さぶりをかけてみる」というモデルレビュアーのセリフをよく耳にしないだろうか？
あれの正体は前提条件を他のコンテキストに変えても、今のモデルは成立するか？
ということを検証する活動を指している。
マスター側が仮にもしも
マスター側のデータであるエアコンが仮に、操作レベルのエアコンの方と連携しており、マスター情報が更新されると、それに連動して操作レベルのエアコンの方にもその情報が反映されるって場合ならどうだろうか？
この場合には２通り考えられる。
結果整合性でいいような場合
もしも連携が遠隔式で連携しているような場合には、絶対にリアルタイムな整合は不可能。
コンテキストとして知識レベルのエアコンと操作レベルのエアコンは分かれている。
同じモデル図には描かないのが正解である。
リアルタイムに整合する場合
マスター情報が更新されたらリアルタイムに操作レベルのエアコンの方に反映されるならどうだろう？
この場合には遠隔でネットワークを通じての連携とかではなく、
そこには【強い整合性】が働いているので、密な結合がそこには存在する。
そこを別のコンテキストに切り離すデメリットの方が強い。
なので、マスター情報である知識レベルのエアコンの方と、操作レベルのエアコンの方は
同じコンテキスト上に存在しなくてはいけない。
ということは、マスター側であるエアコンと物理的にも近い距離間にあって
リアルタイムに整合する必要がある。
室外機は？
室外機は、前提条件である「エアコンの配置された部屋という空間」の要素ではない。
ただし、室外機とエアコンは切っても切り離せないものである。
エアコンが吸い込んだ熱い空気を吸って、配管を通して室外機から外に出していたり。
エアコン内を液体スプレーで洗浄すると、室外機の配管からその液体が出てくる。
つまり、室外機とエアコンは相当密に関連しあっている。
では、室外機も同じモデル図に登場させるのか？
しかしそうするともともと仮定として置いた「エアコンの配置された部屋という空間」という前提条件には反する。
この場合には、この前提条件がそもそも間違っていることが発見されたので修正するということだ。
これが今回の記事で私が最も言いたかった、モデリングを通しての概念モデルの
前提スコープに対する批判的な思考をもってして、モデリングを通して解像度が上がり、前提スコープの誤りに気づいたら速やかに前提の更新を行うということだ。
今回でいうと、コンテキスト境界は、部屋という物理的な壁を境界だと思い込んでいたが、
実は室外機までを含めて１つの境界であるという発見をしたことになる。
浴室乾燥機はエアコンなのか？
我が家の浴室には、浴室の冷風機能や乾燥機能がついている。
仮にもしも浴室乾燥機もエアコンと仮定したら、何が言えるだろうか？
まず我が家の浴室乾燥機は、そもそも温度とかは設定できない。
経年数や使用期限なるものは製品に表記されていたが、
温度の設定ができない時点で、このモデルの属性部分に反しているため、
このモデル図を浴室乾燥機には適用できないことが証明できる。
１部屋に複数台エアコンがあったら？
私は今回置いた前提条件に
「一般的な家庭では、１部屋に最大でも１台しかエアコンはない」という前提を置いている。
だがもしもめちゃくちゃ広い会議室とかで、
その１部屋に１台以上のエアコンがあるようなケースではどうだろうか？
このモデルのままでは部屋からエアコンへの多重度が妥当ではない。
想定される不確実さに対処
こんな風に揺さぶりとは、事前に想定される不確定要素に対して、
事前に机上のモデル図でどの部分に不確実さが存在しているのか？をあらかじめ
明らかにしておくことで、どの要素に対して変更リスクが波紋しそうなのか？
を想定しておくために存在しているともいえる。
補足
この前提の検証活動などは【脅威モデリング】でも同様にして使える大事な思想である。
大事なのはあくまでも今のモデル図は、
「現時点でのスナップショット」であって、コンテキストが変わったら
当然前提条件が変わるのだから、モデルだって変化するということを頭に入れておくこと。
概念スキーマ
こうやって議論してきて判明した前提の境界が、
データの側面での境界、データドメインを形成してくる。
マイクロサービスにするのかどうかとかは一切おいておいて、
その境界で概念スキーマで境界を張っておいたりすることで、
データのコンテキスト境界が明確になっている状態を維持できる。