2012年3月29日木曜日

メタモデル

3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。

今回「メタモデル」として用意した以下のスライドを説明します。

以前からSimpleModelingというOOADの開発手法の一環でDSL駆動開発向けのOOADメタモデルを整備しています。この本の内容はクラウド・プラットフォーム登場前のものですが、クラウド・プラットフォーム向けにいくつか拡張を行ってきました。

また、今回スライドを作りながらOOADと関数型言語の関係を考えてきたわけですが、その考察の中で鍵となるモデルとして浮かび上がってきたデーターフローというモデル要素を追加することにしました。

まとめると、クラウド以降に以下のモデル要素が追加されたことになります。これらのモデル要素は図では白抜き文字にしています。

  • UX
  • サマリー
  • データフロー
  • メッセージフロー
  • データフロー

以下で順に説明します。

ここまでの拡張

このSimpleModelingに対してここまでクラウド向けモデリング向けに追加してきたモデル要素は以下のものです。

  • UX
  • サマリー
  • データフロー
  • メッセージフロー
UX

「OFADの要素技術/関連技術」でも説明しましたが、Ajaxやスマートデバイスの興隆によるリッチなGUIのニーズの高まりを背景にUCD(User Centered Design)、UX(User Experience)という技法が注目されています。以前から要求仕様の一環として画面設計を行うケースはあったわけですが、UCD/UXはそのアプローチを利用者視点でより理論的に進めたものということができます。

UXは比較的最近の言葉ですが、UCDは「ユーザー中心設計」にもある通り、かなり古くからあるモデリング技術です。一般消費者向け商品のモデリングとして発展してきたものが、Webシステムによる一般消費者向けのサービスが大きなマーケットに育ってくる中で、ITシステムの要求仕様のためのモデリング技法として注目されてきているという流れだと思います。

今後は、エンタープライズ・システムでも、ソーシャルメディアといった軸でビジネス的な意味での顧客とのコラボレーションを設計していかなければならないと考えられ、そのなかでUCD/UXが利用されていくのではないかと思います。

こういったモデリング技術の動向を取り入れるために、UX(User Experience)をユースケースの前段に配置しています。ここでのUXは、Ajaxやスマートデバイスを対象とした比較的狭い範囲のUCD向けを想定していますが、ソーシャルメディア上のコラボレーションという意味では、図の右側ビジネスモデルの所にUCDを持ってくることも考えられます。従来からあるビジネス・プロセス、ビジネス・ユースケースのアプローチとUCDの関係をどのように整合させていくのかはまだイメージが湧いておらず、ジャストアイデアというところなのでメタモデルの図には載せていません。

UXとユースケースは、「OFADの要素技術/関連技術」で説明した「(2)Ajaxやスマート・デバイスなどのリッチなGUI向けのUIデザイン(+要求仕様)」について、「従来のユースケースと部分的に技術がかぶってくるので、役割分担を考えていかなくてはなりません。利用者とのインタラクションはUXを用い、システム側はエッセンシャル・ユースケースに徹するという分担が考えられます。」というアプローチを考えています。たとえば、UXでペルソナを作成し、これをエッセンシャル・ユースケースに落とすという連携です。

ただ、通常の定型業務向けの業務アプリケーションは、ビジネス・ユースケース(や業務フロー上)でロールを抽出し、このロールの責務を明確にするという従来からあるOOADのモデリングの方が向いていると思われるので、必ずしもUXの導入がよいというわけでもなさそうと考えています。 その場合でも、ロール・モデリング後に、要求仕様としての画面設計(ちょっと言葉が変ですが、画面モックアップぐらいがよいかも)の中でUX的な技法を適用していくのは有効そうです。

サマリー

サマリーは、「要約エンティティ」という記事で説明したエンティティです。

従来から企業システムは、(1)同期型のオンラインシステムと(2)非同期型のバッチの2つのサブシステムから構成されています。ERモデルでは、summaryエンティティという非同期型バッチが計算した要約情報を格納するのに適したエンティティを使うこともあります。

クラウド・プラットフォームでは、こういったバッチ的な非同期処理(さらにストリームも入ってきます)が大前提になるので、サマリーというエンティティを第一級市民のモデル要素として扱っていくことにしました。

メッセージフロー

メッセージフローは、ユースケースから責務の抽出とオブジェクトへのアロケーションを行うために使用するロバストネス図のクラウド・アプリケーション向けの代替、発展形として導入したモデルです。また、クラウド・アプリケーションの全体像を簡潔に記述する目的にも使用できます。

クラウド・アプリケーションでは、非同期処理が重要な構成要素になります。また業務端末からのデータエントリ処理、夜間バッチといった定型ジョブの起動だけでなく、企業顧客や、消費者からの様々なイベントが高頻度にあがってくるようになるので、アプリケーション・アーキテクチャもイベント駆動型アーキテクチャ(EDA)に変わってくることになるでしょう。

アプリケーション・アーキテクチャがEDAになってくると、従来からあるロバストネス図では、機能不足のためモデルを記述するのが難しくなってきます。この問題を解決するために考案したのがメッセージフロー図です。

メッセージフロー図は、制御フローとデータフローを同じモデル内に記述するために考えたモデル図です。基本的にロバストネス図の発展形であり、宣言的、演繹的なモデルではなくて、実例ベースの帰納的なモデルです。このため、DSL駆動によってプログラムの生成を行うためのソースとして使用することは想定しておらず、ユースケースを実現(realization)するための補助線として使用するラフスケッチという運用になります。

今回の拡張

今回の関数型に関する一連の考察でデーターフローを新規に追加することにしました。

このデーターフローは、アプリケーション・モデルの実現モデルに入ります。

スライドで用いた図では、イベント→状態遷移→データフローのパスになっていますが、「EDAとオブジェクトと関数」で考えたように、実用的には状態遷移を飛ばしてイベント→EDA→データフローにしてしまう方式にしていこうと思います。

この場合、イベント処理エージェントやイベントコンシュマーの実装の中で、必要に応じて状態機械を使用することになります。また、現在OOADやOOPで用いられているDbCの事前条件、事後条件による状態遷移の記述を活用し、状態機械を間接的にモデル化していくアプローチも併用していくことになります。

イベント

従来からイベント・エンティティはSimpleModelingの中軸となる非常に重要なモデル要素です。永続的なビジネス・イベントはエンティティでもあるので、ドメイン・モデルとアプリケーションを接続するハブとして機能します。

今回の図には直接見えてきませんが、イベント・エンティティの実現方法として、「EDAとオブジェクトと関数」で説明したように、ちょっと実装よりになりますが、状態機械ではなくEDA的なアーキテクチャを導入するのが現実解ではないかと考えています。

何故このあたりを細かく考えているのかというと、メタモデルの精度がDSL駆動開発の基盤になるからです。イベント&EDA周りでどのようなDSLを定義していくのかは今後の課題ですが、クラウド・アプリケーションにおけるイベントの実現方式もかなり視界が開けてきました。

諸元

当日使用したスライドは以下のものです。(PDF出力ツールの関係で、当日は非表示にしたスライドも表示されています)

このスライド作成の様子は以下の記事になります。

回顧は以下の記事になります。

投稿者 時刻:
ラベル: , , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)