Alloyを使って論理データモデリングやってみた。

1. ALLOYによる
論理データモデルの運用
2016年3月8日 PPL 2016 ポスター発表
IT プランニング 小笠原 啓

2. (1)論理データモデリング
 システムのエンティティを抽出し、その関係性や制約を
整理すること
 業務フローと共にシステムの基礎を成す
※ https://www.ulsystems.co.jp/topics/007より引用

3. (2)論理データモデリングの成果物
 ER図(IDEF1X)がよく用いられる.
 図や記号を駆使しているので、一覧性、視認性がよい.
 関係の重複度、依存性や一意キーを表現可能.
※ http://www.idef.com/pdf/Idef1x.pdfより引用

4. (3)問題点
 ER図(IDEF1X)で表現可能な構造と制約は限定的.
 属性の重複度、他属性との関連を表現する規定はない.
 分類関係(Categorization Relationships)があまり現場で使
われていない(ツールが対応していなかったりする).
 エンティティインスタンスの集合に対する制約は表現できな
い.
 制約の表現は自然言語でチェックは人手. レビューに頼らざ
るを得ない.
 論理データモデリングとしては不十分ではないか？
 ER図作成がRDBのテーブル設計の前段階という位置づけ
になってしまっている. （もしくは設計されたテーブルの図表
現という認識.)

5. (4) ALLOY ANALYZER
 エンティティや属性とそれら間の関係、制約をAlloy言語
で表現でき、自動small checkが可能。
 モデルの例(インスタンス)を自動で図示してくれる.

6. (5) ER図で用いる制約をALLOYで表
現
 一対一、一対多
 一意制約
 依存
sig 部署{
所属: [多重度] 従業員
}
多重度‘
部署 従業員
所属
従業員
従業員ID
氏名
所属(FK)
fact {
all a, b:従業員 |
a.従業員ID = b.従業員ID <=> a = b
}
多重度‘
注文 注文明細
詳細
fact {
all x:注文明細 | one 詳細.x
}

7. (6)実際に適用したその他の制約の例1
 属性同士の依存関係
 注文オプションの中には互いに同時に付与できないオプ
ションがある.
 その他にも、注文方法による金額指定方法の制約も同様の
構造だった.
sig 注文 {
注文番号: ID
, Aオプション : Boolean
, Bオプション : Boolean
, Cオプション : Boolean
, Dオプション : Boolean
} {
// AオプションとCオプション両方trueは禁止.
not ((Aオプション = True) && (Cオプション = True))
}

8. (7)実際に適用したその他の制約の例2
 分類関係(IDEF1Xでも可能な部分あり)
 取引銘柄の種類と種類別に特殊な属性の付与.（同様に
ユーザーの種類などにも適用した.)
abstract sig 基礎銘柄 {
銘柄コード : ID
, 銘柄名 : 文字列
}
sig A銘柄 extends 基礎銘柄 {
}
sig B銘柄 extends 基礎銘柄 {
}
sig C銘柄 extends 基礎銘柄 {
ペア銘柄 : 基礎銘柄
}
sig D銘柄 in 基礎銘柄 {
基準金利 : 利回り
}
fact {
D銘柄 = A銘柄 + C銘柄
}
継承
多重継承

9. (8)実際に適用したその他の制約の例3
 インスタンスの集合に対する制約
 成立約定のグルーピングに関するルールに適用.
sig 確定グループ {
売成立, 買成立: some 成立
}{
// 売買方向の制約
売成立.売買 in 売
買成立.売買 in 買
// 対向に同じ発注元はない.
disj[売成立.注文元, 買成立.注文元]
// 同じステージのものをグループ化
all x, y : 売成立 + 買成立 | 同じステージの成立[x, y]
// グループ毎に売買金額がバランスしていなければならない.
sum(売成立.注文金額) = sum(買成立.注文金額)
}
インスタンスの集合

10. (9)ALLOYによる論理データモデリング 考察
 ER図では直接記述できな
かった実務上の多くの制約
を明示できた.
 インスタンスを見ながらの試
行錯誤は設計に有効だった.
 ただし、実数や日時に関す
る制約はAlloyでも書きにく
い. (順序に関する性質なら
可能.)
 図に比べると一覧性に劣る.
 Alloyを改造してなんとかし
たい. 今後の課題.
 （Alloyの普及コストが必要）
 書籍の紹介.
 自作のテキスト(既存)を配布.
 データモデル説明会の実施.
GOOD BAD

11. (10)おまけ
 データ構造があると状態遷移を記述したくなるが、本格
的にはモデルチェッカーを利用した方がよいかも.
 インスタンス数が多くなりすぎてAlloyでは数ステップ程度し
か追えない。
 状態遷移の記述はAlloyは得意ではない. (変化しない条件
を全て記載しないといけない)
 テストデータの生成にもあまり向かないかもしれない
 実数や日時を扱うのが難しいため.