Cozyモデル駆動開発/ユースケース/generalize

Pieris Books（ブックカフェ併設のセレクトショップ販売店）のシステム開発プロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法を検討しています。

現在はユースケース間の関係をCML（Cozy Modeling Language）でどのように記述するかという観点で整理を進めています。前回は extend を検討しました。

今回は generalize（汎化） を取り上げます。

generalize

• マージモード : TypeRefinement
• マージ点 : N/A（フロー非依存）
• 機能 : 契約包含（仕様精緻化）
• 由来 : UML generalization

generalizeの基本方針

Cozyモデルでは、ユースケース間のgeneralizationを

• ユースケース間の型的関係（契約関係）

として定義します。

具体的なフロー継承方法やsuper展開規則は、generalizationの仕様外とします。

ユースケースの意味定義

Cozyモデルでは、ユースケースを

• 状態遷移モデルの断片

とみなします。

その意味は、主に次の契約によって定義されます。

• 事前条件（Pre）
• 事後条件（Post）

ユースケース U は、

• ある状態が Pre(U) を満たすとき実行可能であり
• 実行後の状態は Post(U) を満たす

という仕様を持つものとします。

抽象状態機械は明示的には定義しませんが、

• 暗黙の抽象状態機械 ＝ ユースケース集合

という位置付けを取ります。

generalizationの定義

UseCase C が UseCase P を generalize するとは、

• C が P の契約を包含し、意味を精緻化する関係

と定義します。

具体的には、LSP（リスコフの置換原則）的に次を満たすことを要件とします。

事前条件の包含

親の事前条件を満たす状態では、子も実行可能でなければならない。

すなわち、

• C は P の事前条件を弱めない
• 子は親より実行可能範囲を狭めてはならない

事後条件の保存

子は、親が保証する結果を壊してはならない。

• C の事後条件は P の事後条件を包含するか、より強い保証を与える

直観的整理

• 親が約束することは、子でも必ず成り立つ
• 子は親より具体的であってよいが、意味を破壊してはならない

このとき、

• generalization ＝ 状態遷移断片の refinement（仕様精緻化）

とみなすことができます。

フローとの関係

前述した通りCozyモデルでは「generalizationはフローの継承方法を規定しない」というアプローチを取ります。

• MainFlowは契約を実現するシナリオである
• 契約が保持される限り、フロー構造は自由である

したがって、

• super展開の位置
• テンプレート的骨格継承
• 差分オーバーライド

といったgeneralization関係にあるユースケース間のフローの関係は仕様としては定めておらず自由な構造を選択することができます。

include / extendとの違い

観点	include	extend	generalize
対象	フロー構造	フロー変形	契約（意味）
本質	構造合成	条件付き拡張	仕様精緻化
型関係	なし	なし	あり
LSP制約	なし	なし	あり

include や extend が

• シナリオ構造の操作

であるのに対し、generalize は

• 意味（契約）の包含関係

です。

記述例

usecase Purchase pre: - 顧客が商品を選択している post: - 注文が確定している - 支払いが登録されている

usecase PurchaseOnline generalize Purchase pre: - 顧客が商品を選択している - 顧客がログインしている post: - 注文が確定している - 支払いが登録されている - 配送先が登録されている

このとき、

• 子は親の事前条件を包含し
• 親の事後条件を壊していない

ため、generalization関係が成立します。

まとめ

本稿では、generalizeを

• ユースケース間の型的関係 ＝ 契約包含関係 ＝ 状態遷移断片の精緻化

として定義しました。

generalizationは、

• フロー構造の継承を規定するものではなく
• 契約レベルでの意味関係を定義するもの

と位置付けます。

具体的なフロー実現方法（テンプレート的継承、差分オーバーライドなど）は、

• generalizationを実現するための設計戦略

として、次回検討します。

Cozyモデル駆動開発/ユースケース/extend

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

ユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行い、CML(Cozy Modeling Language)で記述する方法について考えました。

現在はユースケース間の関係のモデルについて、ユースケース間の関係のどのようにCMLで記述するか、という観点で具体的な記述方式を検討しています。前回はincludeの検討を行いました。

今回はextendを取り上げます。

extend

• マージモード : Extend
• マージ点 : 条件付きStep
• 機能 : 例外的・追加的振る舞いの付与
• UML extend

extendの意味

extendは、あるユースケースの実行中に、

• 特定の条件が成立した場合にのみ
• 追加の振る舞いが挿入される

ことを表す関係です。

UMLにおけるextendは、

• 基本ユースケースの振る舞いを前提とし
• 条件付きで拡張ユースケースが実行される

という意味を持ちます。

典型的な例としては、次のようなものがあります。

• 「商品を購入する」を拡張する「クーポン適用」
• 「会員登録」を拡張する「年齢確認」
• 「注文処理」を拡張する「高額購入時の本人確認」

extendされる側のユースケースは、

• 常に実行されるわけではなく
• 基本ユースケースの一部を補足する

という性質を持ちます。

includeとの違い

includeとextendの違いを整理すると次のようになります。

観点	include	extend
実行条件	常に実行	条件付き
主目的	共通処理の再利用	例外・オプションの追加
基本フロー	前提	独立して完結
位置づけ	合成	拡張

includeは「分解と再利用」、extendは「基本フローを壊さない条件付き拡張」と整理できます。

Cozyモデルにおけるextendの位置づけ

Cozyモデルでは、extendを

• 図上の関係指定

ではなく、

• ユースケース・シナリオ内における
• 条件付きステップ合成

として扱います。

この観点からextendは、

• 基本ユースケースを中心に据え
• 例外や追加要件を独立したユースケースとして定義し
• 条件に応じて合成する

ための仕組みと位置づけられます。

Cozyモデルにおけるextendは、

• 条件付きでステップ列を合成する関係

として捉えることができます。

記述方式

シナリオ中のextendの記述方式は以下の通りです。

- extend <UseCaseName> when <Condition>

• extendディレクティブで拡張であることを示します
• when句で拡張が発生する条件を明示します

条件は、業務ルールや状態など、要求レベルで意味を持つ表現を用います。

記述例

- 顧客: 商品を選択する。
- 顧客: 支払い方法を指定する。
- extend ApplyCoupon when クーポンが指定されている
- 顧客: 注文を確定する。

この記述は、

• ApplyCouponユースケースのMainFlowに定義された
• ステップ列を
• 「クーポンが指定されている」場合にのみ
• この位置に合成する

ことを意味します。

基本フロー自体はクーポンを前提とせず、拡張として自然に切り出されています。

基本方針

CMLにおけるextendは、

• 基本ユースケースの理解を妨げない
• 例外やオプションを明示的に分離する

ことを重視します。

そのため、以下の方針を取ります。

• extendは必ず条件を伴う
• 基本ユースケースは単体で完結できる
• 拡張ユースケースは意味的に独立した要求単位とする
• マージ点をステップとして明示する

これにより、

• 読めば分かる基本フロー
• 必要に応じて追える拡張

という二層構造の要求モデルを実現します。

UML extendとの対応

UML	Cozy / CML
extend関係	条件付きステップ合成
拡張ポイント	シナリオ内の明示的マージ点
条件	when句
図表現	テキストによる構造表現

UMLでは拡張ポイントという概念が図中に現れますが、Cozy/CMLではそれをステップ位置と条件として直接記述できます。

これにより、

• 抽象的な関係指定に留まらず
• 実行順・条件・意味を同時に表現できる

点が特徴です。

まとめ

今回は、ユースケース間の関係の一つであるextendについて、

• UMLにおける意味
• includeとの違い
• Cozyモデルとしての解釈
• CMLによる記述方針と具体例

を整理しました。

extendは、

• 基本ユースケースを安定させたまま
• 例外やオプション要求を切り出し
• 条件付きで合成する

ための仕組みです。

includeとextendを使い分けることで、ユースケースの振る舞いを過不足なく・構造的に記述でき、図に依存しない、意味的に明確な要求モデルを構築できます。