Modelの構造とViewの活用

第4回の全体像: ModelをDomain ModelとUse Case Modelの二つの軸で組織し、CapabilityとAspectを構成します。形式構造はObject Modelを中心に説明し、複雑なModelはPurposeとConcernに応じたViewから扱います。

第3回では、Object Model、Knowledge Model (知識モデル)、Literate ModelとDomain Modelの関係を整理しました。第4回ではModelの構造を主題とし、Domain ModelとUse Case Modelを二つの軸として読み、その複雑な構造を目的別のViewから扱う方法を説明します。形式構造の説明ではObject Modelを中心に置き、三つのModelとの構成関係は二つの軸とView Systemを説明した後に接続します。

第4回の中心はModelの構造とViewの活用です。Object Modelを用いて形式構造を説明し、Domain ModelとUse Case Modelを二つの軸として整理した後、終盤でObject Model、Knowledge Model、Literate Modelとの構成関係、およびExecution Modeling (実行モデリング)による実装・実行への接続を示します。

前回の記事: 📄 モデリング技術体系

現実世界には、現在の状態、過去の経緯、将来の可能性、暗黙のルール、例外、複数の解釈、未観測の事実が含まれます。Modelは、そのうちBounded ContextのPurposeとConcernに必要な範囲を選択して表現します。

Modelに含める情報と省略する情報は、PurposeとConcernに基づいて決定します。省略した範囲、前提、粒度を記録することで、選択の妥当性を確認できます。Modelの境界は、そのModelが答える問いの範囲を表します。

Bounded Contextは、どの言語、意味、規則、責務を一貫して扱うかを定めるドメイン側の意味境界です。そのContextに必要な範囲を現実世界から抽出し、名称を統一し、概念と規則を整理して、実行へ接続できるModelへ蒸留します。

Bounded Contextはドメイン側の意味境界を表します。Execution Contextは、Modelを実行するruntime、resource、transaction、security、deployment条件を扱うプラットフォーム側の実行環境を表します。

Purposeは、そのモデルを何の判断、対話、変換、実行に使うかを定めます。同じ業務対象でも、用語を合意するためのモデル、業務規則を検証するモデル、状態変化を実装するモデル、運用障害を分析するモデルでは、必要な情報が異なります。

Concernは、そのPurposeを満たすためにモデルが答えるべき問いや利害です。たとえば「誰がこの規則を所有するか」「どの状態遷移が許されるか」「判断の根拠は何か」「障害時にも処理を継続できるか」は異なるConcernです。Concernを列挙すると、モデルへ含める情報と検証条件を具体化できます。

Perspectiveは、対象を見る位置と選択規則です。利用者、業務担当者、開発者、運用者といった立場だけでなく、現在と将来、構造と振る舞い、概念と実装、全体と詳細などの違いもPerspectiveになります。

Viewpointは、同種のViewを繰り返し構成し、解釈し、検証するための規約です。対象とするConcern、使用するモデル種別、表記法、分析方法、整合規則を定めます。Perspectiveが「どこから見るか」を与えるのに対し、Viewpointは「どの規約でViewを作り、読むか」を再利用可能にします。

この区別は、Architecture Viewが特定のConcernへ答え、Architecture ViewpointがViewの構成・解釈・利用の規約を定める ISO 42010:2022 の考え方と整合します。SimpleModelingでは、その考え方をArchitectureだけでなく、モデリング活動全般へ拡張して使用します。

Modelの構成とViewの構成は役割が異なります。Modelの構成では、Bounded ContextのPurposeとConcernに従って現実世界から必要なものを選択・変換し、意味、識別子、規則、振る舞いを持つ構造へ組み立てます。Modelを扱うときには、PerspectiveとViewpointに従って確認対象を選択し、Viewとして可視化します。

Model構成とView選択では、選択した情報に加えて、除外した情報、前提、粒度、時間範囲、選択規則を記録します。この記録を使って、Modelの境界と、現在のPurposeに必要なViewを確認します。Viewで見つかった不足や矛盾は、必要に応じてModelの構造と現実世界についての理解へ反映します。

Modelは、概念、関係、規則、制約に加えて、Bounded Contextに必要な状態変化、Command、Event、Workflow、Policy、Calculation、Decisionなどの機能を保持します。実装、検証、知識、運用へ接続されるworking abstractionとして使用します。

機能が増えるにつれて、Modelに含まれる概念、振る舞い、制約、品質の関係も増えます。一つの図に含める情報量が多いと、目的に必要な抽象を読み取りにくくなります。PurposeとConcernに応じたViewを使い、確認対象を限定します。

SimpleModelingでは、Domain ModelとUse Case ModelをModel構成の二つの軸として扱います。Domain Modelは概念、関係、規則、判断という意味の軸を、Use Case ModelはActor、Goal、Scenario、Outcomeという意図の軸を与えます。二つを直交する同格の軸として読み合わせ、同じModelの要素を異なる方向から構成・確認します。本稿では形式構造を具体化し、UPとの連続性を示すためにObject Modelを中心に説明します。

二つの軸から、CapabilityとAspectを明示的なModel要素として構成します。Capabilityは「Modelが何をできるか」を表し、Command、Event、Workflow、Policy、Decisionなどの機能を一つの識別可能な単位へまとめます。Aspectは「どの条件でそのCapabilityが成立するか」を表し、Performance、Observability、Security、Reliabilityなどの品質条件を重ねます。AspectはCapabilityの成立条件として、Capabilityと同時に設計・検証します。

Glossary (用語集)は、Ubiquitous Languageの用語名、意味、境界、同義語、識別子を管理し、Domain ModelとUse Case Modelの両方へ同じ語彙とIDを供給します。自然文、形式的なModel要素、複数のView、テスト、実装が参照する概念の同一性を、この語彙とIDで追跡します。

共有IDは、表示名が変わった場合や、Viewごとに異なる情報だけが見える場合にも、概念の同一性を保ちます。Glossaryは、Domain ModelとUse Case Modelの二つの軸、Model要素、View Systemを接続する意味上の背骨です。

Viewは、複雑なModelを理解・検証・利用するときに、PurposeとConcernに必要な要素、関係、振る舞い、品質を取り出すための確認可能な表現です。図、文章、表、CML (Cozy Modeling Language)、用語集、Knowledge Graph、実行トレースを表現手段として使用できます。Viewの意味と同一性は、ModelとGlossaryを参照します。

Domain Viewは、Domain Modelの意味軸から、Bounded Context内で一貫して使うUbiquitous Language、概念、関係、規則、境界をPurposeに応じて可視化します。他のViewに現れるActor、Goal、Capability、状態、Event、品質上の対象をModel内の同じ要素へ対応付ける、View間の意味上の参照点として使用します。

各ViewはPurposeに必要な抽象を示し、名称、識別子、規則、境界をDomain ViewとGlossaryへ対応付けます。この対応によって、各Viewが同じModelのどの部分を扱うかを追跡できます。

Use Case Viewは、ActorのGoalからScenarioをたどり、Modelが提供するCapability、観測可能なOutcome、例外を結びます。Domain Viewは対象の意味を示し、Use Case Viewは誰のために何を達成し、Modelの機能をどのように使うかを示します。Use Case Viewは、他のViewと同格に位置付けます。

品質属性系Viewは、Reliability、Performance、Security、Operability、Observability、Evolvabilityなど、複数の機能を横断する条件をConcernごとに可視化します。Domain ViewとUse Case Viewへ品質属性系Viewを重ね、Capabilityが成立する負荷、障害 (defect)、権限、運用、変更の条件を確認します。

Use Case Viewと開発全体の接続は、元になるUse Case Modelの情報構造によって成立します。Use Case ModelはActor、Goal、Scenario、Outcomeを一つの物語とUse Case IDとして保持します。OutcomeをCapabilityと実装へ、ScenarioとOutcomeを受入基準とテストケースへ、ActorとScenarioをマニュアルへ、Use Case IDを開発工程の作業単位と進捗管理へ直接対応付けます。

たとえば UC-ORDER-01 というUse Case IDを持つ注文確定の物語では、自然文のGoalとScenarioをCapability、Code、Acceptance、Test、Manual、Development Process (開発プロセス)へ接続します。この対応は、変更の影響を開発全体で追跡する軸になります。Use Case Modelは、要求の説明と、物語から実装成果物への対応付けを担います。

View Catalogは、Modelを確認する目的に応じて拡張する開いた集合です。Domain ViewやUse Case Viewに加え、Performance、Observability、Security、Reliability、Availability、Testabilityなどの品質属性系Viewを登録できます。PurposeとConcernが必要なViewpointを選び、その規約に従ってModelからViewを構成します。

Viewは、Purposeに必要なものを選んで構成します。View GroupとViewpointについても、必要な交点だけをViewとして具体化します。

SimpleModelingはUP（Unified Process）を土台とし、Logical、Process、Development、Deployment、Scenarioからなる4+1 Viewを、選択可能な五つのArchitecture View Groupとして継承します。View GroupはArchitectureを構成する関心領域のまとまりであり、各Groupの具体的なViewはPurposeに応じて選びます。

SimpleModelingの差分は、Domain、Performance、ObservabilityなどのViewpointを複数のView Groupへ横断的に適用できることです。たとえばPerformance Viewpointから、目的に必要なLogical、Process、DeploymentなどのPerformance Viewを構成し、それらをComposite Performance Viewとして合成できます。UPの構成要素を保持したまま、Domainと品質属性 (Quality Attribute)のConcernをGroup横断で追跡できるView Systemへ拡張します。

同じModelに対して、Domain View、Use Case View、品質属性系View、Execution Modelingが生成する実行具体化Viewを相補的に構成できます。それぞれが異なるConcernを扱います。

複数Viewが共有する概念、境界、規則、識別子は、対応関係を明示します。Glossaryは名称と意味を接続し、対応表や参照リンクはModel要素間の関係を示します。対応できない項目は、現実世界の理解、Viewの選択条件、Modelの表現を再確認する対象になります。

SimpleModelingでは、ModelとViewの品質をClarity、Consistency、Validity、Accuracyの四つの尺度で評価します。

ツールやAIは、明確性と一貫性の確認を広く支援できます。妥当性と正確性には、Purposeを持つ利用者、ドメインエキスパート、観測結果、実行結果が必要です。SimpleModelingは、構造を厳密にすることと、現実世界に対する正しさを保証することを区別します。

この四つはModelとViewの評価尺度です。品質属性系Viewは、ReliabilityやSecurityなど、Modelが実現する性質を可視化します。評価尺度と可視化対象の品質属性は、それぞれ別の役割を持ちます。

ModelとViewは反復的に更新します。Bounded ContextのPurposeとConcernに従って現実世界からModelを蒸留し、PerspectiveとViewpointに従ってViewを構成し、シナリオ、レビュー、テスト、実行結果で検証します。見つかった不足や矛盾は、View、Model、Bounded Contextの境界、Concern、Viewの選択規則、現実世界についての理解へ反映します。

この循環により、Modelは知識と実行結果を取り込みながら更新されるworking abstractionとして機能します。

第4回ではModelを主題とし、形式構造の説明ではObject Modelを中心に置きます。終盤では、Domain ModelとUse Case Modelを構成する三つのModelの寄与と、実行への具体化を次のように整理します。

Domain Modeling (ドメイン・モデリング)は、三つのModelに重なるDomain領域から、PurposeとConcernに必要なDomain Model Viewを構成します。Use Case Modelingも同じ三つのModelから、Actor、Goal、Scenario、Outcomeに必要なUse Case Modelを構成します。Object Model上の共有要素とGlossaryのIDが、二つの構成と各Viewを対応付けます。

Execution Modelingは、Domain ModelとUse Case Modelから選択した形式構造をCML、実装、テスト、実行環境へ具体化・接続します。レビュー、テスト、実行で見つかった不足は、Object Modelを中心とする構造、Knowledge Modelの根拠、Literate Modelの文脈と意図、Bounded Context、View選択へ反映します。

AIは、依頼で指定されていないPurpose、Concern、Perspective、粒度を推定して補います。利用者はこれらの選択条件を明示し、AIが採用した条件と照合します。生成結果は、どの問いに答えるViewとして構成されたかを含めて確認します。

Bounded Context、Purpose、Concern、Perspective、Viewpoint、除外範囲、求めるViewを明示すると、AIは選択条件に沿ってModelを探索し、候補となる抽象と対応関係をViewとして提示できます。人間は、その選択のPurposeに対する妥当性と、現実世界に対する正確性をレビューします。レビュー対象には、生成結果、参照したBounded ContextのModel、構成したViewを含めます。

本稿ではModelの構造とViewの活用を整理し、形式構造の説明ではObject Modelを中心に置きました。Domain ModelとUse Case ModelはObject、Knowledge、Literateの寄与から目的別に構成され、その複雑なModelはUPの4+1を継承・拡張したViewから扱い、Execution Modelingによって実装と実行へ接続します。次回はObject Modeling (オブジェクト・モデリング)の個別技法として、Object、型、制約、責務、協調を詳しく扱います。