状態機械

パワータイプと状態機械をScala DSLで記述する方法について試行錯誤しつつ実装。

ユースケースによって発生するドメイン・イベントとドメイン・リソースの状態機械を有機的に結びつけることができそうな感触を得た。このあたりは 汎用性を目指すUMLでは、利用者に任されているところなのだけれど、使い方をよほど真剣に考えないと実運用に適用できるレベルで具体化できないので、結 局使われないままになってしまうという結果になっていると思われる。この点をモデリング手法で定型化することで、一般で利用可能にすることが SimpleModelingの狙いの一つである。

実装を続けながら、アプリケーション開発では状態機械の置き場所が一つの論点であることに気付く。
ドメインオブジェクトの状態機械で色々なアクションを行うようにすると、ドメイン・モデルとアプリケーション・モデルが好ましくない方向で密結合 になってしまう。アプリケーション・モデルはドメイン・モデルに依存するけれども、ドメイン・モデルはアプリケーション・モデルから独立させたい。
ドメイン・モデルの状態機械で色々なことを始めると、最終的に業務プロセスの作業手順をドメイン・モデルが抱え込むことになってしまう。
この問題を解決するためには、ドメイン・オブジェクトの状態機械にアプリケーション・モデルの状態機械をかぶせるような実現方法が必要になってくるかもしれない。そういったプログラムを自動生成するには...などとつらつら考える。

業務ユースケースのextend

このところ業務ユースケースのextendの実装を続けている。今朝、なんとか疎通した。 ちょっとした勘違いで数日デバッグに費やす。プログラミングはどれだけデバッグに耐えられるかという耐性によるところが大きい。

ユースケースを扱うツールを書いてみるとよく分かるけれど、ユースケースを準形式的に書くために意識しなければならない点は多い。こういった点まで網羅した参考書は見かけたことがなく、今の専らの参考書は『The Unified Modeling Language Reference Manual 2nd』である。ここに定義しているUMLのメタ・モデルをどのようにDSLで表現するのか、という作業を続けているともいえる。

業務ユースケースフロー

SimpleModelerは業務ユースケースのフローを扱う処理を開発中。 既存の手法だと、フローは自然文で書いて後は目視のみなので、実運用上開発に必要な情報量を記述することが困難。 実際にユースケースのフローを扱う処理を書いているとかなりややっこしいことが分かる。こういうややっこしいことを手作業で開発者に強いるのは、まず機能しない。 やはり、定型フォーマットに会わせて書いた物をツールで検証しかない。

業務ユースケース

現在は業務ユースケースの実装を行っている。その中で特にScala DSLでフローを記述する手法を試行錯誤中。

task("商品を購入する") {
step_client_worker_system(DS顧客購入().operation("顧客購入")) {
event_issue(DEE顧客購入()) {
resource_update(DER商品())
}
} mark_is "buy3"
}

という定義から:

• 14 顧客は顧客担当者に商品購入依頼文書で顧客購入を依頼する。
• 15 顧客担当者はよろず販売システムに商品購入依頼文書で顧客購入を依頼する。
• 16 よろず販売システムは顧客購入の発行を実行する。
• 17 よろず販売システムは商品の更新を実行する。
• 18 よろず販売システムは顧客担当者に商品購入結果文書で顧客購入の結果を返す。
• 19 顧客担当者は顧客に商品購入結果文書で顧客購入の結果を返す。

というフローを生成できる所まできた。
次の課題は、(1)ユースケース間の関係と(2)エンティティの状態遷移の2つをどのように取り込むのかである。

TODO

この間の日曜日(11/30)にBeProudさんのモデル駆動勉強会でSimpleModeling/SimpleModelerの紹介をしてきました。とてもよいフィードバックを得られて感謝です。

以下、その中ででたコメントから、SimpleModelerでサポートするとよいと思われる機能をメモしておきます。

• 既存のデータベースからのリバース
• UML図の自動生成

また、懸念事項として、モデルと生成したソースコードのずれの問題が挙がりました。これは、11/14のUMTPでのセッションでも挙げられた問題で、モデルコンパイラのお話しをすると必ずされる質問です。

これについてはプログラマ日記にSimpleModelerの方針を書きました。