エト エアレルロ エンドレンナ ウトゥリアン。(RubyでMDA)
はぶさんが何ゆえこの話題に興味をお持ちなのかが私にはわからないので、ますます妙なことを書いている気もするのだけれど、書いてみます。私の勝手な想像としては、はぶさんが興味をお持ちの部分は、『OOエンジニアの輪！ 〜 第 28 回 和田 周 さんの巻 〜』で述べられている:
という部分なのかなあ。はぶさんの2回目のコメントにお返事してみますが、あまりにフツウすぎて面白くもなんともないと思います――
そこで、スーパープログラマやアーキテクトと言われる人が少なかったり、いなかったりする場合でも、マッピングができたり、ドキュメントをきちんと常にメンテナンスされている形で整合性を取れるようにするための枠組みとしてあるのが、 MDA というものだと思います。
そんなことはないと思います。テスト->実コード->テストのフィードバックループが短く、簡潔な記述のできるものならよいと思います。
(ちょっと追記): そういう意味では、既存のJavaクラスをシームレスに使えるGroovyに私は大いに期待しているのですが、世間一般では早くも失望の声があがっているようで。
それに対する短い回答は「イエス」です。少し長い回答は「肝は、ドメイン分析の結果が『実行可能である』こと」です。「手続きを書けるかどうか」をパラフレーズしただけですが。
我われのチームは現在、ストーリー駆動(SDD)かつテスト駆動(TDD)で開発を行っていますが、SDDやTDDは具象です。これらに共通する抽象は「不安駆動」です。「このシステム(の機能)はユーザーに対する価値を提供するのか？」という不安を軽減するためにストーリー駆動を、「実用に即した明快なAPIを提供できるだろうか？ 機能の追加修正リファクタで、システム壊さないだろうか？」といった不安を軽減するためにテスト駆動を採用しています。
これと同様に「実装する機能について顧客とのセッションで内容は理解したつもり。でも、これで本当に動くのだろうか？」という不安を解消したいとずっと思っていました。そのためには「動かしてみる」しかないと思います。シーケンス図やコラボレーション図、なにがしかのフロー図のレビューでも可能だとは思いますが、図を順番に指でなぞって追うような仕事はコンピュータにこそやらせるべきだと思います。
状態遷移や処理のシーケンス、メッセージの応答が少し複雑なもの(私にとってはどのような処理もすぐに「複雑なもの」となります)について、これまでずっと不安だったのですが、これからは、不安になったら相棒のRubyに問い合わせてみることにしようと思っています。
- 開発者の不安と発注者の不安
上で書いた不安解消術は私の不安、すなわち「開発者の不安」の解消です。「発注者の不安」はまた性質が異なりますし、それを解消するためには究極的には「完動作する実コードを(early and oftenで)納品すること」ですが、プロジェクトによってはそうもいかないので、その場合は不安を解消するために、各種ダイアグラムを用意することは適切だと思います。
ただ、その場合でも、私は自分の作成したシーケンス図やコラボレーション図の正当性に対する不安を解消するために、Rubyでプロトを作成すると思います。クラス図に関しても同様で、トップダウンでやっても不安は解消できないです。TDDでYAGNIがRefactoring to Patternsでキマリ。もう戻れない(NO MORE NO MORE)。
- UMLについて
ちなみに個人的にはコンポーネント図と配置図はUMLの白眉だなあ、と思っています(Rubyで代替ができない)。コンポーネント図大好き!
