モデリング技術体系

第3回の全体像: 隣接するObject Model、Knowledge Model、文芸モデルに一つのDomain領域を重ね、混色された重なりをGlossary (用語集)のリングで接続して、目的と関心に応じた一つのDomain Model Viewを構成する方法論上の関係を示します。

第1回では、AIの登場によってDomain Modelが実装への実現経路を持つworking abstractionとなり、モデリングが開発の新しいチョークポイントになることを説明しました。第2回では、SimpleModelingがCML (Cozy Modeling Language)、Cozy、AI、TextusによってKnowledgeからExecutable Softwareへ至る経路をどのように構成してきたかを整理しました。

第3回では、その経路で何をモデル化し、既存のソフトウェア工学技術をどこへ配置するかを定めます。本稿は、以降のObject、Knowledge、Literateの各Modeling、目的別のDomain、Use Case、Applicationの各Modeling、およびModel Realizationの役割と依存関係を定める理論記事です。

前回の記事: 📄 SimpleModelingが目指してきたもの

既存技術を整理することと、開発方法を定めることは異なります。

SimpleModelingはSoftware Development Methodology (ソフトウェア開発方法論)です。知識体系に含まれる技術を網羅するのではなく、モデリング中心の開発に必要な技術を選択し、相互の役割と実現経路を定めます。

したがって、Knowledge SystemからMethodologyへの関係は、収集、整理、選択、実践という四つの同格な工程を並べたものではありません。Knowledge Systemが技術の候補と理解の地図を提供し、Methodologyがその知識に対して「何を採用し、何の役割を与え、どう使うか」を判断します。さらにDevelopment Process (開発プロセス)は、Methodologyが定めた変換や判断をプロジェクトで運用する工程です。Agile、Iterative、Stagedなどの進め方をMethodologyそのものから分離することで、同じ方法論を異なるプロジェクトへ適用できます。

以前のSimpleModelingでは、Domain ModelをObject Modelの一部として扱っていました。Knowledge Modelingと文芸モデルを併用する現在のDomain Modelは、三つのモデル全体を束ねたものではありません。図では、Object Model、Knowledge Model、文芸モデルを隣接する三つの楕円として置き、その中央に一つのDomain領域を重ねます。Domain領域とObject Modelの重なりは形式構造、Knowledge Modelとの重なりは知識構造と根拠、文芸モデルとの重なりは自然言語による文脈、意図、自由構造の寄与を示します。これらの重なりを、目的と関心に応じた問題領域の一つのViewとして読むのがDomain Modelです。

重なりを示す混色は装飾ではありません。Domain Modelが各モデルから何を受け取るかを、元のモデルの色とDomain領域の色の組み合わせで区別します。一方、重ならない部分は各モデルの全体がDomain Modelへ取り込まれるわけではないことを示します。

Application Modelも三つと並ぶ第四の構成要素ではありません。Use Caseをどの参加者、責務 (Responsibility)、協調 (Collaboration)、相互作用、状態遷移、Event (イベント)、Service、Operation (操作)によって実現するかというPurposeとConcernに応じて、Object Model、Knowledge Model、Literate Modelから必要な要素を組織した適用モデルです。

Application Modelingでは、Literate ModelのUse Case Scenario (ユースケースシナリオ)からUse Case Realization Modelを構成します。Collaborationは参加者、Role、責務の構造を示し、Interaction (モデル上の相互作用)は具体的な実行例を示します。その対応をStateMachine (状態機械)、Event、Service、Operationへ落とし込み、実行可能な部分をCMLへ接続します。この意味の構成とレビューがApplication Modelingであり、その後にCMLからプログラムと実行基盤へ進む経路はModel Realizationです。

一つのDomain領域とObject Model、Knowledge Model、文芸モデルとの重なりは、同じ問題領域の概念を異なる形式で表します。重なりの間で概念の意味や同一性 (Identity)がずれると、一つのDomain Model Viewとして読むことができません。

用語集は、用語の名称、意味、境界、同義語、識別子 (Identifier)を管理します。各モデルとの重なりに現れる概念を共通の用語へ対応付けることで、形式構造、知識構造、文芸的な語りをまたいで概念の同一性と意味を接続します。InfographicでGlossaryを矢印や後続工程ではなくリングとして描くのは、この接続が三つの重なりを同時に囲み、一つのViewとして整合させる働きだからです。

三つのモデル、Domain領域との重なり、用語集による接続は、固定順序で一度だけ確定するものではありません。Objectの構造化、知識の整理、文書による説明、実行の具体化で見つかった不足や矛盾を用語集と各モデルへ戻し、目的と関心に照らしてViewを反復的に更新します。

この2D構成では、三つのモデルからDomain Modelへ向かう合流矢印はありません。Domain Modelは変換列の末尾に生成される別の箱ではなく、一つのDomain領域と三つのモデルの重なりそのものを、一つの問題領域Viewとして捉えたものです。

実用的なソフトウェアには、業務機能だけでなく、Security (セキュリティ)、Observability、Performance (性能)、Resiliency、Availabilityなどの品質属性が必要です。品質属性は、特定のモデルだけが担当するものではありません。Object Model、Knowledge Model、Literate Model、Domain Model、Application Modelで明らかになった要求や制約 (Constraint)に対して、横断的に確認する設計課題です。

SimpleModelingでは、Domain Logicとアプリケーション固有のポリシーをアプリケーション側の責務とし、認証、計測、障害対応、実行制御 (Execution Control)などの共通機構を主にTextus側の責務とします。アプリケーションごとに同じ機構を繰り返し実装するのではなく、必要な品質水準と固有の制約をモデルで明らかにし、実現に共通する部分は実行基盤で提供します。

この分離によって、モデリングは機能の記述だけで終わらず、実際に運用できるソフトウェアへ接続されます。個々の品質属性のモデル化とTextusによる実現方法は、後半の記事で詳しく扱います。

モデリング技術体系は、技術を分類するだけでなく、SimpleModelingで採用する次の設計判断を固定します。

ソフトウェア工学には、対象や目的の異なるさまざまな既存技術があります。SimpleModelingでは、特定の技術を出発点に方法論を組み立てるのではなく、まずモデルの構成、役割、依存関係、実現経路からなる枠組みを定めます。その上で、枠組みの各部分に必要な要素技術を選び、位置付けます。

たとえば、GoFやPEAAはObject Modelingで責務と協調を設計するために使い、DDDはDomain Modelingで問題領域の概念と境界を構成するために使います。Use Case Realization、Interaction、StateMachineはApplication Modelingでシナリオを動的構造へ対応付けます。CQRSやSagaはApplication ModelingとModel Realizationの境界で、モデル上の意味と実装方式を分けて位置付けます。Knowledge GraphやRDFはKnowledge Modelingで生成AIが参照する知識を構造化します。

一つの技術が複数の役割に関係する場合もあります。技術名を一つの箱へ固定するのではなく、どのモデルのどの部分に、何の目的で適用するかを明示することが重要です。

モデルの役割と関係を定義しても、モデルが実装と分離したままでは方法論として不十分です。SimpleModelingでは、Domain Model Viewのうち、Domain領域とObject Modelの重なりが担う形式構造をCMLによって機械処理可能な構造として記述します。CozyはCMLを実行可能ソフトウェアへ変換し、AIはCozyが変換しきれない実装部分を補完します。Textusは得られたソフトウェアを実行します。

一つのDomain領域とObject Model、Knowledge Model、文芸モデルとの重なりから構成するDomain Model Viewは、抽象側で何を明らかにするかを定めます。CML、Cozy、AI、Textusは、そのうちObject Modelとの重なりによって形式化された構造を実装と実行へ接続します。モデリング技術体系は、この2Dのモデル構成と一本の実現経路を、一つの方法論の中に配置します。

この接続には品質属性の実現も含まれます。アプリケーションはDomain Logicと固有の要求を保持し、Textusは複数のアプリケーションに共通する品質属性の実現機構を提供します。これにより、モデルから実行可能ソフトウェアへの経路に、運用に必要な品質も組み込まれます。

本稿で定めるのは、各領域の詳細な技法ではありません。方法論として共有する分類原理、各領域の責務、技術を選ぶ観点、実現経路との接続です。

モデルはRealityそのものではなく、PurposeとConcernに応じたViewとして構成されます。各モデルとモデリング活動 (Activity)に共通するこの理論は、次回のView-Based Modelingで扱います。その後、Object、Knowledge、Literateの三つの構成要素、Domain、Use Case、Applicationの各Modeling、Model Realizationを順に説明します。

SimpleModelingは、新しい技術を一から定義するものではありません。既存のソフトウェア工学技術を、モデリング中心の開発に必要な構成要素として選択し、モデル間の役割、依存関係、実現経路の中へ配置します。

この体系によって、個別技術を詳しく学ぶ前でも、何を明らかにするための技術なのか、開発全体のどこで使うのかを把握できます。実際のシステム構築ではTextus技術のツールとフレームワークを利用し、その過程で各技術の背景と詳細を学べます。

モデリング技術体系は、Object Model、Knowledge Model、文芸モデルに一つのDomain領域を重ね、混色された重なりをGlossaryのリングで接続して、目的と関心に応じた一つのDomain Model Viewとして読む関係を整理しました。ただし、同じ対象からどの情報を選び、どの範囲をモデルとして表すかという共通原理は、まだ説明していません。

次回はView-Based Modelingとして、モデルをRealityそのものではなく、目的、関心、Perspectiveに基づくViewとして構成する考え方を説明します。