MindmapModelingと集合知(10) - トレイト

前回はマインドマップではなく、通常の仕様書ライクな文書によるSimpleModeler DSLであるSmartDox DSLを紹介しました。

SmartDox DSLを用いることで、マインドマップモデルでは難しかった本格的なシステム開発をターゲットにしたコード生成を行うことができます。

さて、SmartDox DSLでモデリングを始めてみると、あるモデル要素が無性に使いたくなってきました。そのモデル要素とは「トレイト」です。

ここで言うトレイトはScalaが提供しているミックスイン用のクラス断片で、通常のクラス継承の機能を緩めることで、多重継承的なモデリングを可能にします。scalaプログラミングではトレイトを用いたCakeパターンが非常に便利ですが、これをオブジェクト・モデリングの段階でも使いたいと考えたわけです。

そこで、ここ数日SimpleModelerにトレイトを追加する拡張を行なっていたのですが、何とか動くようになりました。

以下の文書がトレイトを用いたSmartDox DSLです。

#+title: Table

SmartDox DSLを使って記述したモデルの
サンプル文書です。

文書でサンプルモデルの定義をします。
本来は文書中の仕様記述の文書は
定義するモデルに対するものになります。

しかし、この文書ではSmartDox DSLの記述例として
SmartDox DSL文法の説明を記述することにします。

* サンプル文書の目的

このサンプル文書は表を中心にしてクラス定義するサンプルです。

表を中心にトレイトを使ったモデリングのサンプルです。

* 特色

** Master

** Transaction

** LogicalDeletable

** ImageHolder

** Tagable

* 登場人物

** 顧客

#+caption: 性質一覧
| 項目 | 値                                          |
|------+---------------------------------------------|
| 特色 | Master,LogicalDeletable,ImageHolder,Tagable |

#+caption: 属性一覧
| 名前   | 型     | カラム  | SQL型        |
|--------+--------+---------+--------------|
| 顧客ID | token  | ID      | CHAR(16)     |
| 名前   | token  | NAME    | VARCHAR(64)  |
| 住所   | string | ADDRESS | VARCHAR(256) |

* 道具

** 商品

#+caption: 性質一覧
| 項目 | 値                                          |
|------+---------------------------------------------|
| 特色 | Master,LogicalDeletable,ImageHolder,Tagable |

#+caption: 属性一覧
| 名前   | 型    | ID | カラム | SQL型       |
|--------+-------+----+--------+-------------|
| 商品ID | token | ○ | ID     | CHAR(16)    |
| 名前   | token |    | NAME   | VARCHAR(32) |
| 定価   | money |    | PRICE  | LONG        |

* 出来事

** 購入

#+caption: 性質一覧
| 項目 | 値                           |
|------+------------------------------|
| 特色 | Transaction,LogicalDeletable |

#+caption: 特性一覧
| 特性 | 名前   | 型    | 多重度 | 派生        | カラム      | SQL型    |
|------+--------+-------+--------+-------------+-------------+----------|
| ID   | 購入ID | token |        |             | ID          | CHAR(16) |
| 属性 | 日付   | date  |        |             | DATE        | DATE     |
| 関連 | 顧客   | 顧客  |      1 |             | CUSTOMER_ID | CHAR(16) |
| 属性 | 顧客名 | token |        | 顧客.名前   |             |          |
| 関連 | 商品   | 商品  |      1 |             | GOOD_ID     | CHAR(16) |
| 属性 | 数量   | int   |        |             | AMOUNT      | INT      |
| 属性 | 商品名 | token |        | 商品.名前   |             |          |
| 属性 | 単価   | money |        | 商品.定価   |             |          |
| 属性 | 総額   | money |        | 数量 * 単価 |             |          |

以下の5つのトレイトを定義しています。例題なので中身は定義していませんが、以下のような用途を想定しています。

Master

マスターテーブル

Transaction

トランザクションテーブル

LogicalDeletable

論理削除

ImageHolder

イメージと関連付け

Tagable

タグと関連付け

ポイントとなるのは、顧客はMaster, LogicalDeletable, ImageHolder, Tagable、商品はMaster, LogicalDeletable, ImageHolder, Tagable、購入はTransaction, LogicalDeletableといったように必要な特色(トレイト)を自由にミックスインすることができる点です。

クラス図

上記のDSLからSimpleModelerを使って以下のクラス図を生成することができます。

実装

モデリング時にトレイトを使う場合、Scalaでは特に問題なくそのまま実現できるのは明らかです。それでは、JavaやRDBMSの場合はどうなるでしょうか。

Java

Javaの場合は、複数のトレイトを合体させた実装をクラスとして生成し、トレイトに対応するインタフェースとimplementsしておけばよいでしょう。手動でトレイト相当を実装すると大変ですが、コード生成であれば特に難しかったり煩雑だったりするところはありません。

RDBMS

RDBMSのテーブルは、単純に元のテーブル定義にトレイトを合体させたテーブルを生成すればよいでしょう。これもコード生成であれば難しいところはありません。

以上のようにトレイトはモデリング上も有効な上に、コード生成を前提にすればJavaやRDBMSといった既存のプラットフォームでも問題なく展開することができます。

UML時代には存在していなかったトレイトですが、SimpleModelerを使ったモデル駆動開発では非常に有効に使えそうです。