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との構成関係を示します。Use Caseの実現を動的構造として組織するApplication Modeling (アプリケーション・モデリング)と、承認済みモデルを実装・実行へ接続するModel Realization (実現関係)は区別します。

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

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

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

Bounded Contextは、どの言語、意味、規則、責務 (Responsibility)を一貫して扱うかを定めるドメイン側の意味境界です。その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に従って現実世界から必要なものを選択・変換し、意味、識別子 (Identifier)、規則、振る舞いを持つ構造へ組み立てます。Modelを扱うときには、PerspectiveとViewpointに従って確認対象を選択し、Viewとして可視化します。

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

Modelは、概念、関係、規則、制約 (Constraint)に加えて、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、テスト (Test)、実装が参照する概念の同一性 (Identity)を、この語彙と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、Application View、品質属性系Viewを相補的に構成できます。Domain Viewは問題領域の意味、構造、規則、境界に重点を置き、Application ViewはUse Caseの実現、協調 (Collaboration)、相互作用、状態遷移、Event、Service、Operation (操作)に重点を置きます。それぞれが異なる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を中心に置きます。終盤では、SimpleModelingモデルの三つの構成要素、それらから目的別に構成するDomain Model、Use Case Model、Application Model、および実現経路を整理します。

Domain Modeling (ドメイン・モデリング)は、三つの構成要素から、PurposeとConcernに必要な意味、構造、規則、境界をDomain Modelとして組織します。Use Case Modeling (ユースケース・モデリング)は、Actor、Goal、Scenario、OutcomeをUse Case Modelとして組織します。Application Modelingは、Use Caseの実現に必要な動的構造をApplication Modelとして組織します。Object Model上の共有要素とGlossaryのIDが、これらの適用モデルと各Viewを対応付けます。

Application Modelingは、Literate ModelのUse Case Scenario (ユースケースシナリオ)からUse Case Realization Modelを構成し、CollaborationとInteraction (モデル上の相互作用)を介して、StateMachine (状態機械)、Event、Service、Operationへ対応付けます。Domain Modelingが静的側面、Application Modelingが動的側面に重点を置きますが、両者を完全な排他的分類にはしません。

承認済みの実行可能な形式構造をCML、実装、テスト、実行環境へ接続する活動 (Activity)はModel Realizationです。レビュー、テスト、実行で見つかった不足は、Object Modelを中心とする構造、Knowledge Modelの根拠、Literate Modelの文脈と意図、Bounded Context、Application Model、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、Application ModelはObject、Knowledge、Literateの寄与から目的別に構成され、その複雑なModelはUPの4+1を継承・拡張したViewから扱います。Application ModelingがUse Caseの動的な実現を組織し、Model Realizationが承認済みモデルを実装と実行へ接続します。次回はObject Modelingの個別技法として、Object、型 (Type)、制約、責務、協調を詳しく扱います。