ツリーで分析するときはクラスベースでも考えよう

 以下でツリーモデルで物事を分析する難しさが少し触れられていたので、ツリーモデルの記法上の制約について書きたい(一応の前置きとして、今回書くのは主に記法上の制約のみで、ツリーによる分析の進め方にはあまり言及しない)。

http://togetter.com/li/1047939

 クラシフィケーションツリー法等を使っていて、ツリーモデルで分析を行う際は、クラスベースモデルでも考えたほうが良い場合が多い。お互いメリット・デメリット両方あり、うまく補完しあえるためだ。
 具体的には、複雑なis-aの関係性を持つもの、has-a/is-aの関係性が混在するものは、ツリーでは表現しにくいが、クラス図ではすっきり表現できることが多い。例えば具体例としては以下。

 他にも、前述の例と似てるけれど、概念モデルでも設計モデルでもよく出てくるBridgeパターンも、ツリーによる表現のしにくさが問題化する。
 これらの問題は概ね、「抽象的なhas-a/is-aの関係を、抽象的に表現できない記法上の制約」に起因して、「要素や関係性の重複が発生」した形になる。

 ツリーベースのモデリングにはこういう制約があるので、モデリングのやりにくさを感じたら、クラスベースで考えるのは有効だと思う。より本質的な要素や関係性を適切に表現できて、分析がやりやすくなることがある。

 なおツリーを使ってうまくモデリングできないという問題は、ソフトウェアテストのテスト条件分析でよく見る。失礼な表現になってしまうかもしれないが、これはモデリング力不足でクラスベースのモデルをかけないことに起因している場合が多いように思う。

対象のドメインを意識してモデリングしよう

 またモデルの記法上の制約以外の原因として、プラクティスや慣習の蓄積も少しあると感じる。

 例えば、分析モデリングがごちゃごちゃになってしまう原因の一つに、複数のドメインをごちゃごちゃにまとめて扱ってしまう問題がある。
 クラスベースモデルでは、この原因を避ける慣習が一般化している。クラスベースモデルの実質的標準となっているUMLで、ドメインモデルと設計モデルの区別、システムモデルとサブシステムモデルの区別を明確にしてモデリングする方法論やプロセス、プラクティスが普及しているためだ。
 対してツリーベースモデルではUMLとくらべてそのような慣習が弱くて、適切なモデリング・不適切なモデリングの基準が曖昧なまま、各人自由にやることが多くなっていると思う。

 そのため、ツリーベースでモデリングする際も、「ドメインごとに分けてモデリングする」「ドメインモデルと設計モデルを分けてモデリングする」といった一般的なクラスベースモデリングの心がけを適用すると、やりやすくなる場合があると感じる。