本稿では、ユースケース間のgeneralization関係を前提としたCMLの記述方法について整理します。
設計の前提
generalizationはユースケース間の関係を表すものです。
ここでは、generalizationは「関係の宣言（マーク）」として扱います。
一方で、ユースケースのフローは、include や extend などの構造によって記述します。
したがって本稿では、
- generalization（関係の宣言）
- フロー構造（実行の記述）
を明確に分離して扱います。
記述方法
基本形
# UseCase ## PurchaseOnline ### GENERALIZATION Purchase ### INCLUDE #### Purchase
この例では、
- PurchaseOnline が Purchase と関係を持つことを宣言し
- フローは include によって記述しています
ただし、この2つの関係は現時点では直接結びつけません。
拡張を含む場合
# UseCase ## PurchaseOnline ### GENERALIZATION Purchase ### INCLUDE #### Purchase ### EXTEND #### After payment - 配送先を登録する
この場合も同様に、
- GENERALIZATION は関係の宣言
- INCLUDE / EXTEND はフロー構造
として独立に記述します。
設計の考え方
現段階ではgeneralizationとフロー構造を過度に結び付けていません。
例えば、
- generalizationしたら必ずincludeする
- 特定のフロー構造を強制する
といったルールは導入しません。
あくまで、
- GENERALIZATION は意味の手がかり
- INCLUDE / EXTEND は実際の構造
として並置します。
今後の展開
generalizationの意味（契約、状態遷移、LSPなど）や、
- どのようなフロー構造が許されるのか
- どのような実現方法が妥当なのか
といった点については、今後段階的に整理していきます。
まとめ
本稿では、generalization関係を前提としたCML記述の基本形を示しました。
現時点では、
- GENERALIZATION は関係の宣言
- INCLUDE / EXTEND はフロー構造
として扱い、両者を独立に記述するというシンプルな方針を採用します。
この段階的なアプローチにより、
- 記述のシンプルさを保ちつつ
- 将来的な意味拡張に対応できる
構造を維持することができます。
投稿
