SimpleModelingの運用イメージとモデル展開
SimpleModelingでは、Object、Knowledge、Literateの三つの構成要素からDomain、Use Case、Applicationの各適用モデルを構成します。ユースケースの意図をアプリケーション・モデル (Application Model)へ具体化するApplication Modelingと、承認済みの実行可能モデル (Executable Model)をCML(Cozy Modeling Language)、Cozy、AI、Textusによって設計・実装・実行へ接続するModel Realizationを分けて扱います。
3ティア・モデル
システム・アーキテクチャには以下の3ティア・モデルを採用しています。
-
プレゼンテーション・ティア
-
アプリケーション・ティア
-
ドメイン・ティア
各ティアはサブシステムとしてモデル化され、マイクロサービスとして配備・運用されるのが基本イメージです。
ただし、SimpleModelingはCBD (Component-Based Development)(Component-Based Development)による開発であり、最近の用語法ではモジュラー・モノリス(Modular Monolith)を指向しているので、アプリケーション・ティアとドメイン・ティアを統合したマイクロサービスを配備して運用するという可能性もあります。
分析モデル
現在のSimpleModelingモデルを構成するのは、オブジェクト・モデル (Object Model)、知識モデル (Knowledge Model)、文芸モデル (Literate Model)です。分析では、この三つから目的別に次の三つの適用モデルを構成します。
ドメイン・モデルは、システムが扱う問題領域の本質的な構造とルールを記述します。
アプリケーション・モデルは、ユースケースの実現に必要な参加者、責務 (Responsibility)、協調 (Collaboration)、相互作用、アプリケーションサービス、操作 (Operation)、イベント (Event)、状態機械 (StateMachine)を記述します。
ユースケース・モデルは、アクターの目的とそれに対応するシステムの振る舞い (Behavior)をモデル化します。 SimpleModelingはユースケース駆動のアプローチを採用しており、このモデルを中核として分析モデルを構成します。
ユースケース・モデルはそれ自体はソースコードの生成の入力モデルにはなりません。 ユースケース・モデルは、アプリケーション・モデル、ドメイン・モデル作成の元ネタになるとともに、それぞれの整合性を保つ役割をになっています。
アプリケーション・モデリングでは、文芸モデルとして記述したユースケース・シナリオから、レビュー可能なユースケース実現モデル (Use Case Realization Model)を構成します。協調は参加者、役割、責務の構造を表し、相互作用は具体的な実行例を表します。AIが両者からサービス、操作、イベント、状態機械への対応を提案し、人間がその意味と対応関係を承認します。
SimpleModelingではビジネス分析については、ニュートラルな立場をとっており任意のビジネス分析手法と連携できる構成になっています。
連携の際の核となるモデルがユースケース・モデルです。
ビジネス分析の結果は、ユースケース・モデル、ドメイン・モデル、アプリケーション・モデルへ整理します。そのうち、人間が承認した実行可能なオブジェクト・モデルの部分をCML(Cozy Modeling Language)で記述し、アプリケーション開発へ接続します。
分析モデルからの展開
分析モデルは分析モデル・アップ・ダウン (Analysis Model Up/Down)によって上下2方向に展開します。
-
概念モデル
-
設計モデル
概念モデル
概念モデルは以下の目的で使用されます。
-
アプリケーションが扱う問題を概観
-
非技術系のステークホルダーと情報共有
図では代表的な成果物を挙げています。
-
アクター・ゴール・リスト
-
ユースケース図(UML (Unified Modeling Language))
-
コンポーネント図(UML)
ユースケース図はアクター・ゴール・リストをオブジェクト・モデルとして図示したものです。全体像を外観するのに適しています。
コンポーネント図はアプリケーション・モデルやドメイン・モデルを一定の基準で切り出した、サブシステムやコンポーネントの関係を図示します。 概念モデルとしては、アプリケーションのシステム構成というよりは境界化コンテキスト(Bounded Context)という扱いを意図しています。
設計モデル
アプリケーション・モデリングと、承認済みモデルをソフトウェアへ変換するモデルの実現は区別します。前者はユースケースの意図をレビュー可能なアプリケーション・モデルへ具体化する活動 (Activity)です。後者は、その実行可能な部分をCMLで記述し、CozyとAIによって設計モデル、プログラム、テスト (Test)へ変換してTextus上の実行へ接続する活動です。
設計作業分野では分析モデルから以下のティアをターゲットにした設計モデルを作成します。
-
ドメイン・ティア
-
アプリケーション・ティア
-
プレゼンテーション・ティア
ドメイン・ティア
ドメイン・ティアをターゲットにしたドメイン・モデルの設計モデルを作成します。
設計コンテキストには、実行プラットフォーム、品質属性 (Quality Attribute)などが定義されています。
アプリケーション・ティア
複数の問題領域から複数のドメイン・サブシステムが作成されます。アプリケーション・モデルは、ユースケースの実現という目的から必要な要素を選び、これらをアプリケーションとして協調させます。
ドメイン・モデルと同様に、人間が承認したアプリケーション・モデルの実行可能な部分をCMLで記述し、設計コンテキストとともにCozyへ与えます。CozyはScalaベースの設計モデルを生成し、変換しきれない部分をAIと開発者が補完します。
基本的には、CBDによってアプリケーション・モデルを操作するコンポーネントを実装し、このコンポーネントをサブシステムとして仕上げて、アプリケーション・ティアに配備します。
プレゼンテーション・ティア
プレゼンテーション技術は、技術の進歩も早く、流行の変化も大きいため、SimpleModelingの直接のターゲットにはしておらず、連携方法を定義する方式になっています。
アプリケーション・モデル、ユースケース・モデル、UIコンテキストを入力にCozyがUIシナリオを生成します。
UIシナリオ生成以降の作業はUI開発側に委ねます。 この作業にはAI支援が有効に働くでしょう。
まとめ
SimpleModelingは、オブジェクト・モデル、知識モデル、文芸モデルから目的別の適用モデルを構成します。ユースケースの意図からアプリケーション・モデルを導くアプリケーション・モデリングと、承認済みの実行可能モデルをCML、Cozy、AI、Textusによってソフトウェアと実行へ接続するモデルの実現を分けることで、分析、設計、実装の追跡可能性 (Traceability)を保ちます。
ユースケース・シナリオからユースケース実現モデル、協調、相互作用を経て、サービス、操作、イベント、状態機械へ対応付ける過程をレビュー可能にし、AIによる提案と人間の承認を組み合わせる開発スタイルを目指します。
参照
用語集
- Cozy Modeling Language (CML)
-
CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- 実現関係 (Realization)
-
Undefined
- オブジェクト (Object)
-
Objectとは、Classまたは他のClassifierによって分類され、構造、State、Behaviorを持ち得るInstanceです。Objectは、同じClassifierの他のInstanceと区別して参照できる個体として扱われます。
- アプリケーション・モデリング (Application Modeling)
-
アプリケーション・モデリング（Application Modeling）とは、ユースケースをアプリケーションが実現する振る舞いとして具体化し、アプリケーション・モデルを構成する活動です。ユースケースシナリオから、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作への対応を明らかにします。
- Cozy
-
Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。
- Textus
-
Textusは、SimpleModelingによって実現されたソフトウェアを動作させるための実行基盤です。アプリケーションに共通する実行、運用、連携の機構を提供します。
- ユースケース (Use Case)
-
UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。
- シンプルモデリング (SimpleModeling)
-
SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
- 実行可能モデル (Executable Model)
-
Undefined
- アプリケーション・モデル (Application Model)
-
アプリケーション・モデル（Application Model）とは、ユースケースをアプリケーションがどのように実現するかを、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作、結果によって表す目的別のモデルです。
- CBD (Component-Based Development)
-
CBD（コンポーネント指向開発）は、ソフトウェアを責務・契約・インターフェースを明確に定義したコンポーネント単位で構築・再利用する開発方式です。 コンポーネントは独立性と交換可能性を備え、システムを疎結合に構成することで保守性と再利用性を高めます。 論理モデルでは機能や契約を定義する抽象構造単位として、物理モデルでは実際の実装・デプロイメント単位として扱われます。
- オブジェクト・モデル (Object Model)
-
Undefined
- 知識モデル (Knowledge Model)
-
知識モデル（Knowledge Model）とは、SimpleModelingモデルに含まれる概念、意味関係、分類、規則、根拠、出典などを、主として生成AIが参照、探索、関連付け、解釈できる形で構造化したモデルです。
- 文芸モデル (Literate Model)
-
Undefined
- ドメイン・モデル (Domain Model)
-
Undefined
- ユースケース・モデル (Use Case Model)
-
ユースケース・モデル（Use Case Model）とは、利用者や外部主体がシステムを利用する目的と、その目的を達成するシナリオおよび期待する結果を、Actor、Goal、Use Case、Scenario、Outcomeによって表す目的別のモデルです。
- 協調 (Collaboration)
-
UMLにおけるCollaborationは、専門化された機能を担う参加要素のRoleが共同して、目的とする機能を達成する構造を記述するClassifierです。
- イベント (Event)
-
UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。
- 責務 (Responsibility)
-
Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- 状態機械 (StateMachine)
-
UMLにおけるStateMachineは、Eventの発生によって起動されるTransitionでStateのグラフをたどり、システム要素のevent-driven Behaviorを表すBehaviorです。
- 振る舞い (Behavior)
-
UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
- ユースケース実現モデル (Use Case Realization Model)
-
UPにおけるUse Case Realizationは、ユースケースの振る舞いを、設計モデル内で協調するモデル要素によってどのように実現するかを記述します。ユースケース実現モデルは、ユースケースのシナリオと、それを実現する参加者、責務、相互作用、操作、結果の対応を表すモデルです。
- ユースケースシナリオ (Use Case Scenario)
-
Undefined
- モデル上の相互作用 (Interaction)
-
Undefined
- 分析モデル・アップ・ダウン (Analysis Model Up/Down)
-
分析モデル・アップ・ダウンとは、分析モデルを中核に据え、そこから概念モデルや設計モデルを「上（アップ）」へ導出し、また具体的なコードやデータ定義などを「下（ダウン）」に展開する双方向的なモデリング手法です。
- 用語集 (Glossary)
-
Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。
- UML (Unified Modeling Language)
-
オブジェクト指向分析・設計のための統一モデリング言語。クラス図、シーケンス図、ユースケース図などを通じてシステム構造と動作を表現する。UPおよびCBDの基盤言語。
- クラス図 (Class Diagram)
-
Class Diagramとは、Class、Interface、Data Type、Association、Generalization、Dependencyなどを用いて、Modelの静的構造を示すUML Diagramです。
- クラス (Class)
-
Undefined
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- テスト (Test)
-
Testとは、指定した条件で対象を実行または評価し、観測した結果を期待する結果やConstraintと比較して、要求または契約への適合を確認する活動とその仕様です。
- 活動 (Activity)
-
アクティビティスペース内で実行される具体的な行為またはタスク。アルファをより進んだ状態へ移行させるために行われ、通常はワークプロダクトの生成や改良を伴う。
- 品質属性 (Quality Attribute)
-
Quality Attributeとは、ソフトウェアが機能を実行できることに加えて、どの程度の品質で要求を満たすかを表す特性です。Security、Performance、Availability、Reliability、Resilience、Observability、Maintainabilityなどが含まれます。
- Scala
-
Undefined
- 追跡可能性 (Traceability)
-
開発におけるTraceabilityとは、要求、用語、Model Element、設計判断、Test、実装、実行結果の関係を識別子と根拠によってたどれる性質です。