オブジェクト指向分析設計の問題点とあるべき姿

Kenichiro Ota @oota_ken

満期の計算ならまだしも、金利やポジションの計算とかになるとよほどうまく抽象化しないとポリモルフィズムの恩恵にはあずかれなくて、しかし、そこまでの努力が本当に労力に見合ったものであるかというのが難しいところなのです。

Kenichiro Ota @oota_ken

もちろん、デリバティブや多通貨会計、外国為替みたいに本質的にオブジェクト指向とマッチングしやすい分野もあるわけで、やっぱりドメインごとに適用するテクノロジーは異なるという結論にならざろうえないのです。

Masayoshi Hagiwara @masayh

この時点でこの技術（OO）の限界を感じます。どんなに優れた技術でも扱いにくいものは適切とは言えません。デザインパターンの導入なくしていい設計ができないのも同じ理由。@oota_ken よほどうまく抽象化しないとポリモルフィズムの恩恵にはあずかれなくて

Kenichiro Ota @oota_ken

@masayh そうですね。OOの業務のドメインモデルは少なくとも今はあまりに俗人性が高すぎます。それが技術の成熟度によるものなのか、そもそも技術として不適切なのかは僕には判別がうまくついていないのですが。

Masayoshi Hagiwara @masayh

僕はOO自体よりOOADの問題だと思ってます。分析方法が論理学や代数などによらないで経験だけで構成されていい加減なこと。真の工学ではないこと。 @oota_ken OOの業務のドメインモデルは...技術の成熟度によるものなのか、そもそも技術として不適切なのか

Kenichiro Ota @oota_ken

@masayh それはおっしゃるとおりだと思います。たとえば、OOADで継承一つとっても、ある新しい概念を他のサブクラスにすべきかどうかの判断があまりに俗人的です。メイヤー教授の継承12分類とかは多少よくはなっていますが、工学といえるレベルではないですね。

Masayoshi Hagiwara @masayh

OOADやその方法論を作ってきた技術者の責任は重いと思います。一方ではOOPのマルチパラダイム化、AOP、MDDなどで実装技術を進化させてきたのに、それらを適切に使い切るための設計法をいい加減にしてきた。それでどれだけのシステム構築が失敗し、大きな損失を出したか。

Masayoshi Hagiwara @masayh

OOADの問題はTony Hoare氏のNull Referencesの問題よりも深刻かもしれません。http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

Masayoshi Hagiwara @masayh

結局、開発言語やフレームワーク、デザインパターンを作る方が分析設計法を作るよりは好まれるということでしょう。これはRDBMSやKBSを作る方が、関係モデルや正規化を作るよりは好まれるということ。論理学や数学の素養がソフトウェア技術者には不十分だからでしょうか？

Masayoshi Hagiwara @masayh

フレームワーク化とその支援ツールを進めることで、分析設計法を真摯に捉えなくてもアジャイルのようなアプローチで何とかできると考えるのでしょうか。しかし、それは問題の本質を解決しているとは思えない。もっとも分析設計法だけでも問題は解決しない。

Kenichiro Ota @oota_ken

でも、古典であるオブジェクト指向入門をもってしてもやっぱり僕が今直面しているビジネス・エンティティへの責務の振り方、適切なOOADっていうのは良く分からなかった。というか、ますます分からなくなったｗ

Kenichiro Ota @oota_ken

しかし萩原さんもおっしゃっていたけど、実装技術の進歩に対して、要求、分析、設計の技術の進歩があまりにも遅れすぎていて、うまく実装技術を使いこなせていないという感は僕にも強くあるなあー。

Kenichiro Ota @oota_ken

未だにドメインモデルを名詞抽出法からはじめるとか40年前より後退すらしている感があるのに、それを現場では平然と是とする・・・名詞は簡単に動詞になりうる、動詞は簡単に名詞になりうるから名詞抽出法は罠に嵌りやすいアプローチだというのに。

Masayoshi Hagiwara @masayh

だからそれはOOADの欠点だと思います。僕の作った述語論理のを見てください。明確です。述語は常にエンティティの間にしか存在しないんですから。@oota_ken ビジネス・エンティティへの責務の振り方、適切なOOADっていうのは良く分からなかった。

Kenichiro Ota @oota_ken

後、ユースケースって本質的にオブジェクト指向と関係ないのに、OOSEやRUP、ICONIXが前面に出してきたからなんかオブジェクト指向分析やるときには必須のように思われているけど、むしろこれまた罠の方が多い。ユースケースをシーケンス図で分析して責務を振るとかもね

Kenichiro Ota @oota_ken

これはオブジェクト指向入門でも書かれていて前から僕も疑問だったところだけど、ユースケースとそれをシーケンス図化して責務を振るという方法を使うと、本質的な計算依存ではなく、単なる記述上の前後関係を依存関係と勘違いしてしまう可能性があり責務の粒度が適切でなくなる可能性大。

Masayoshi Hagiwara @masayh

最近要求開発だけは行き過ぎているきらいもある。アジャイルや要求開発だけで解決するのも誤りでしょう。分析設計法と対にならないとだめ。工学的基盤の上にプラクティスの載せないといつまでもコストを払い続けることに@oota_ken 要求、分析、設計の技術の進歩があまりにも遅れすぎていて、

Kenichiro Ota @oota_ken

もっと恐ろしいのが、その本質的な計算依存ではない、単に書き手が良く考えないで記述した記述上の前後関係に対するシーケンス図による分析は「トランザクション・スクリプト」になりがちで、まったくドメインモデルじゃなくなってしまうこと。

Masayoshi Hagiwara @masayh

はい。ユースケースは機能要求の検証可能な定義化、進捗管理、テストの生成に使いましょう。分析設計は別の方法がいいと思います。クラウドではユースケースではなくUoWの単位を別に設けましょう。私は述語にします@oota_ken ユースケースって本質的にオブジェクト指向と関係ない

Kenichiro Ota @oota_ken

@masayh だんだん、おっしゃっていることが分かってきました！そ、そうなんですよねー。そもそも誰か特定のエンティティに振るっていう発想自体がビジネス・エンティティの世界では無理あり・・・

Kenichiro Ota @oota_ken

＞述語は常にエンティティの間にしか存在しないんですから。　ここが深すぎる・・・何をやってきたのか僕は・・・

Masayoshi Hagiwara @masayh

シーケンス図の操作の順で定義するのではなく、因果関係を使います。因果関係は時間順序より抽象化して崩れにくい。だからシーケンス図はビジネスに使うべきでなく制御などに使うべき @oota_ken ユースケースとそれをシーケンス図化して責務を振るという方法

Masayoshi Hagiwara @masayh

実は責務はエンティティ間の関係です。正確にはそのコンテキストです。口座と口座の間にあるのが送金。顧客と商品の間にあるのが注文。@oota_ken そもそも誰か特定のエンティティに振るっていう発想自体がビジネス・エンティティの世界では無理あり

Masayoshi Hagiwara @masayh

より抽象化すれば、ものとものの間にあるのがこと。ことはまたこととつながります。そうして、こともものも述語として扱います。述語は真偽を示す命題。その命題が真になるコンテキストでものとことは記述される。これでビジネス領域はほとんど記述できます。

Kenichiro Ota @oota_ken

@masayh 激しく同意です！ビジネス・ルールの整理でウチのチーム(というより後輩)が因果関係による整理をしていました。ああやらないとシーケンス図の罠にはマリますね。ていうか、シーケンス図ビジネスでは役立たん・・・