オブジェクトモデリングは、元々の源流がシミュレーション向けプログラミング言語SIMULAにあることからも分かる通り、人間が認知する世界観を基本構成要素とするモデリング手法です。
ビジネスモデリング、要求分析、システム分析、システム設計、実装(プログラミング)の各作業フェーズで同じモデル(オブジェクトとオブジェクト間の関係)を持ちまわることによってフェーズ間のインピーダンスミスマッチを低減することができ、要求モデルと実装の乖離を防ぎ、反復型の開発を可能にします。
ただ、オブジェクトモデリングでモデリングの要件を全て満たせるのかというと、まだまだ力不足です。
1つは、人間の認知モデルをベースにしているため、形式的な処理が難しいということです。オブジェクト間の関係は宣言的に記述することができますが、これらのオブジェクトによって構築される協調関係を宣言的に記述したり、形式的に取り扱って検証や合成、最適化といったことはできません。
1つは、ビジネスモデリングから実装までモデルを持ちまわる事ができるのが問題領域の静的構造に限られること。動的モデルについては状態機械の範囲で部分的に持ちまわることができるだけです。これは、前述の「オブジェクトによって構築される協調関係を宣言的に記述できない」という問題に起因しています。
このため、オブジェクトモデリングというと「問題領域の静的構造」に焦点が絞られることになりがちで、たとえば、これをどう実装するのかという切り口のドメイン駆動設計のような方向に技術が伸びていきます。
それ自身は適切なアプローチですが、オブジェクトモデリング全体としてはシステムの振舞いをオブジェクト間の協調としてモデル化していく方向への拡張をしていかないと、汎用的なモデリング手法として適用範囲を広げることは難しいでしょう。
振舞いモデルについては、(単なるお絵描きではない)データして活用可能なモデルを作成することができないとなると、モデリング作業そのものが無駄な作業といえなくもありません。
「問題領域の静的構造」だけモデリングするのであれば、DOAのアプローチで十分ですし、軽量開発の場合ER図だけ用意すれば十分でしょう。
そして、振舞いモデルをモデリングできないのであれば、ER図をかいた後、いきなりプログラミングが効率のよい開発手法となります。
オブジェクトモデリングの柱の一つはユースケースです。ユースケースは「物語」によって利用者要求の暗黙知を抽出し、シナリオ分析技術によってオブジェクトの静的構造と協調を構築する技術とボクは理解しています。
振舞いモデルを宣言的、形式的に扱えない弱点を持つオブジェクトモデリングですが、このユースケースがあることによって「問題領域の静的構造」だけのモデリング手法ではなく、総合的なモデリング手法として汎用的に使用できる技術体系となっているといえます。
ただし、このユースケースはかなり難しい技術で、うまく使いこなせないのであれば背伸びしてオブジェクトモデリングをするより、ER図＋プログラミングの方が効率よく精度の高いシステム構築ができるでしょう。
オブジェクトモデリングの現状分析はこんな感じですが、これをクラウドアプリケーションに対して、どう適用していくのかというのが、ここ数年考えてきたことです。
まだまだ、試行錯誤の段階ですがいくつか切り口があります。
1つは、手堅いモデリング技術であるドメインモデルをクラウドアプリケーション向けにチューンするアプローチ。
ソーシャルグラフをどのようにモデル化するのかというアナリシスパターン的な切り口、モデル構造の雛形を定めるメタモデルやプロファイルの切り口、クラウド的なトランザクションやBigDataといったプラットフォームに落し込む手法の整備が必要です。
また、ユースケースをクラウドアプリケーションに適用する手法についても整備が必要です。
従来型のユースケースは、利用者とシステムのショートトランザクション粒度のインタラクションがターゲットでしたが、クラウド環境では非同期処理、並行処理、ロングトランザクションといった要因が重要になってくるので、そのままの形では適用が難しいでしょう。
また、UX(User Experience)技術の興隆によって、ユースケースの適用範囲も変わってきます。
従来のユースケースの運用では、ドメインモデルとの接続箇所が曖昧で、方法論としての整備も遅れていたので、この点の充実も併せて必要でしょう。
加えて、システムの振舞いモデル(オブジェクト間の協調モデル)に対してのアプローチを考える必要があります。
ここは元々従来もうまくいっていないところなので、クラウドアプリケーションでいきなり解決することは考えられません。
とはいえ、非同期、並列、分散がより重要なパーツとなってくるクラウドアプリケーションなので、何らかの対応策は考えたいところです。
アプリケーションの振舞いのアーキテクチャの側面では、要求駆動からイベント駆動への移行も重要です。
要求駆動は、たとえば画面にフォームを入力しエンターキーを押すとその延長で同期型でリクエストが発行されSQLが実行され結果が返されるといったアーキテクチャです。
それに対して、イベント駆動はクラウド上で発生する様々なイベントをアプリケーションがイベントハンドラで受けとり、都度小さな処理を自身のリソースに対して行ったり、協調動作する相方にメッセージを投げたりして処理を進めていくアーキテクチャです。
前者はシェルからCLIで動作させる単発のコマンド的な振舞い、後者は各種イベントを割り込みハンドラで拾いながら動作する制御システム的な振舞いです。
アプリケーションの振舞いが相当複雑化することが容易に推測できます。
大規模データへの対応では、DFD(データフロー図)的なアプローチが再び表舞台に出てきそうです。
エンタープライズ系の開発ではDFDは今でもよく利用されていると思いますが、実装時に手組みプログラミングになるのでその効果は限定的です。
クラウドアプリケーションで事情が変わってくるのは、大規模データの扱いにおいて手組みのプログラミングではなく、DFD的なモデルからHadoopのような大規模データ処理向けのコードを自動生成するアプローチが実用化されるかもしれないという点によります。
ここは、単なる転記を超えたプログラムが必要となるところで、手組みのプログラミングでは、Hadoopのようなフレームワーク向けに合わせる接合部のコーディングが煩雑、最適化やデバッグが難しいという問題があり、これは自動生成のコストをかけても十分に実用化できそうです。
この方面では、SQL的、関係演算的な切り口の言語で大規模データを扱うというアプローチもあり、動向が注目されます。
つらつらと書いてきましたが、現在は、こういった論点についてScala DSLモデルコンパイラSimpleModelerとサービスマッシュアップフレームワークg3を開発しながら試行錯誤を続けています。
ちょうど立ち止まっておさらいするのによいタイミングだと思うので、途中結果をブログにまとめよう思います。
投稿
