前回「クラウド・アプリケーション・モデリング」ではACP(Application Cloud Platform)時代のアプリケーション開発におけるモデリングについて、開発プロセスの点から考えてみました。
今回はモデル体系(メタモデル/プロファイル)について考えてみることにします。
クラウド・アプリケーションの開発ではアプリケーション開発のみを考えるのではなくBusiness→Development→Operation→Evaluationによる一種のPDCAループをビジネススコープで回していくことが重要になります。
Business→Development→Operation→Evaluationループを回すためには持続化可能な形で各アクション間で情報を持ちまわる必要があります。この情報はDevelopmentで使用するオブジェクト・モデルと連続性のあるものが要求されるので、Businessでもオブジェクト・モデルを使用するのが自然です。
このため、ITシステム開発のアクションであるDevelopment(以下単にDevelopment)はもちろんですが、Businessアクション(以下単にBusiness)でのオブジェクト・モデルが非常に重要になってきます。
今回はこのような枠組みで開発方法論を考える上でベースとなるオブジェクト・モデルのリファレンス・モデルについて考えます。
全体像
Business ProcessによるBusinessのモデルとDevelopmentでのITシステムのモデルの全体像を整理しました。おおまかな関係を示すのが目的なので、詳細は省いて強調したい部分のみを載せる形にしています。
大きく3つの領域があります。
- Business Process Model :: ビジネス・プロセスを記述。
- IT System Model :: ITシステム向けのオブジェクト・モデルを記述。
- Domain Model :: ビジネスとITで共有するドメイン・モデルを記述。
Business Process
Businessのモデリングの方法としては色々なアプローチが考えられるところですが、ITシステム開発とのシームレスな連携を念頭に置いた場合、Business Processを用いるのがよいのではないかと考えています。
ここでは『Business Modeling with UML: Business Patterns at Work』をベースにカスタマイズしたものを用います。
Business Process Modelはざっくり以下のモデル要素で構成されています。
- Vision / Value / Goal :: ビジョン・価値・ゴールなど「何」を目標にしたいのかを記述。
- Business UseCase/UX :: ビジネス要求を物語で記述。
- Business Flow :: ビジネスの流れ/仕組みを記述。
「Vision / Value / Goal」はビジネスで「何」をするのかを記述するのに必要そうなモデル要素を代表させた項目です。ここに何を持ってくるのかはビジネス・モデリングの方法論で変わってきます。「Vision / Value / Goal」はその1例と考えてください。
IT System Modelとの連携で必要なのはBusiness UseCase/UXとBusiness Flowです。
また、Domain ModelをIT System Modelと共用する点が本質的に重要です。
要求仕様の記述にはBusiness UseCaseを使用します。UX(User Experience)とUseCaseの棲み分けは難しい課題ですが、いずれ考えてみたいと思います。ここではUseCaseを中心に、必要に応じてUXも併用、というような形でとらえて下さい。
IT System Model
IT System Modelはざっくり以下のモデル要素で構成されています。
- UseCase/UX :: 要求仕様を物語形式で記述
- Collaboration :: 物語を実現するためのシステム内外の協調動作
- Responsibility :: システムが果たすべき責務
- System/SubSystem :: システム/サブシステム。
- Module/Component :: システム/サビスシステムを構成するソフトウェア部品。
- Class/Object :: クラスとオブジェクト。オブジェクト・モデルの基本分類子。
Bisuness Processと同様にUseCaseとUXの関係は微妙ですが、ここではざっくりUseCase/UXとひとかたまりにして扱います。
IT System ModelではUseCase/UXからDomain Modelを睨みつつCollaborationを経てResponsibilityを抽出します。このResponsibityをIT System ModelおよびDomain ModelのSystem/Subsystem, Module/Component, Class/Objectに配置していきます。
基本的にオーソドックスな手順ですが、オブジェクト・モデリングは最近はロストテクノロジーになってしまっているきらいもあるので、ACPの要素も加味しつつ一度まとめる予定です。
Domain Model
Domain Modelは、Business Process ModelとIT System Modelから共用します。
- Context Map :: Bounded Contextの対応関係のマップ。
- Bounded Context :: ドメインの領域。Entityの集まり。
- Entity :: エンティティ(ドメイン・オブジェクト)。
- Relashionship :: 各種分類子間の関係。
- StateMachine :: 分類子の振る舞いを記述する状態機械。
- Business Rule :: ビジネスルール。
オブジェクト指向技術は、上流のビジネス・モデリングからオブジェクト指向プログラミングまでシームレスに連携できる点が最大の美点であるといえるでしょう。この美点の中軸となるのがDomain Modelです。
Domain ModelはBusiness ProcessとIT System Modelから共通のモデルとして共有されます。
基本的には通常のオブジェクト・モデルですが、以下の拡張を行っています。
- Context MapとBounded ContextはDDD(Domain-Driven Design)の用語を採用。
- Business Ruleを採用。
モデルの対応関係
図に示すモデル間の対応関係について説明します。
まず大事な点は、Domain ModelをBusiness Process ModelとIT System Modelから共用することです。Domain ModelはBusiness Process Modelの一部でもあり、IT System Modelの一部でもあるという関係になります。
Business Process ModelのBusiness UseCase/UXとBusiness FlowからIT System ModelのUseCase/UXを作成します。IT System ModelのUseCase/UXとDomain Modelが作成できれば、ここからは通常のオブジェクト指向開発の手順で開発を進めることができます。
まとめ
ACP向けのモデリングを考えるベースとなるオブジェクト・モデルについて整理しました。
オブジェクト・モデルをBusiness Process, IT System Model, Domain Modelの3つの領域に分類する枠組みとそれぞれの対応関係を考えてみました。
大きな枠組としては、2000年代前半に完成されたオブジェクト指向技術がベースで、セマンティクス的に大きな拡張は行っていません。業界全体でもここ10年程大きな動きはなかったと思います。
このベースに対して、ACPの登場、また関数型言語、リアクティブといった要素技術の実用化がどのようなインパクトを与えていくのかという点が1つの論点になります。
いずれにしても、新しい時代向けに開発方法論が進化するタイミングになっていると思います。本ブログでもこの観点から引き続き考察を続けていきたいと思います。