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

Masayoshi Hagiwara @masayh

そういう意味ではRDBでの正規化したテーブルのジョインでは分割前のデータは復元できても因果関係が落ちてしまうので正確な意味的復元はできません。クラウドではeventual consistencyによるデータ復元で問題となります@oota_ken 因果関係による整理をしていました。

竹内正治 @mshrtkch

者ー事ー物。事ー事。オブジェクトモデリングのパターン

竹内正治 @mshrtkch

ユースケースは、本質的にオブジェクト指向と関係するでしょう

竹内正治 @mshrtkch

ユースケースは、オブジェクトの関係。責務は、オブジェクトそのもの

Ikufumi Moriya @imoriya

@masayh より抽象化すると「もの」も「こと」も述語（意味）をあらわすものであり、述語と述語の間にもまた述語があらわれるということでしょうか。また、データ復元において、復元不可の述語がある場合は、現実的にはある規則を実用レベルで適用して近似的に復元したとみなすのでしょうか。

Masayoshi Hagiwara @masayh

機能を実現するためにオブジェクトは連携するように構築するという意味ではおっしゃる通り。しかし、その前に分析設計でどう関わらせるかがここでのテーマで、責務の決定プロセスでのユースケースの役割について @takemasa ユースケースは、本質的にオブジェクト指向と関係するでしょう

Masayoshi Hagiwara @masayh

OOPだけで実装すれば責務はクラスに属させるしかありません。がマルチパラダイムではそうではないし、責務配置にデータとの関係を考えなければならないクラウドでは古典的なこの考えは有効ではないと思います@takemasa ユースケースはオブジェクトの関係。責務はオブジェクトそのもの

Masayoshi Hagiwara @masayh

@imoriya はい、述語は述語と結びついて階層化するのが現実世界です。技術ではなくて現実世界の姿です。例、顧客が注文した商品を、それを在庫する倉庫から、出荷する

Masayoshi Hagiwara @masayh

@imoriya 通常、分割して結合する場合の意味の復元には、順序もかかわることがあるので、そのために意味をロジックに埋め込むことをします。しかし、本来なら分割されたデータ、モデルがその意味を持つべきです。関係モデルの正規化ではこの意味の保持が大変で、設計が難しいのです。

竹内正治 @mshrtkch

OOの考え方は、置き換えられるべき不要な古典ではなく、本質的には不変で重要な型ではないか。型を極めた人の型破りな考え方は、型を習得していない人の誤解を招く場合がある。新しい型には新しい名前を付けたい

竹内正治 @mshrtkch

責務は誰かが負うべきもので、その誰かがオブジェクトであると考えれば、責務がオブジェクトに属さないという考えは成り立たない。その考え方が成り立つのは、別の概念、すなわち用語の定義が違うから

Masayoshi Hagiwara @masayh

まったくその通りです。用語の定義に注目されるところはいかにもですね。@takemasa 責務は誰かが負うべきもので、その誰かがオブジェクトであると考えれば、責務がオブジェクトに属さないという考えは成り立たない。

Masayoshi Hagiwara @masayh

実装上のオブジェクトが責務を持つことが必ずしも概念レベルでのOOADの意味で概念クラスが責務を分担することと一致しないことを言っています。実装でOOパラダイムを使うならそこに責務を振るしかないので一致させることが自然でしょうが。だからといって既存のOOADに限定することでもない。

Masayoshi Hagiwara @masayh

ユースケースを実装するのは各オブジェクトの責務が負いますが、ユースケース自体は責務とは異なる実体です。これはユースケースが実装としてのオブジェクトとは異なる抽象レベルで定義されているからです。述語も実体はオブジェクトでの実装だけで動作します。述語はユースケースに類似した実体です。

Masayoshi Hagiwara @masayh

XMLの意味を扱う技術から触発されて、OOのドメインモデルを扱ういい方法を考えました。DDDもいいけれど、そろそろ次の段階もあってもいいでしょう。関数型やデータモデルをドメインモデルと組み合わせる方法。

竹内正治 @mshrtkch

ユースケースは、オブジェクトの協調なので、オブジェクトと同じ抽象レベル。抽象レベルではなく、視点が異なる。ユースケースを責務とするオブジェクトを考えると、抽象レベルが上がる

Masayoshi Hagiwara @masayh

@imoriya はい。クラウドに対応する場合は特に述語を意識したデータ、モデルを作るべきでしょう。関係モデルの正規化は通常は第3正規化まで。しかし、クラウドやBIに対応するまでは第1正規化まででいいと思います。コッド氏の思想も後半はそうなっていったと理解しています。

Masayoshi Hagiwara @masayh

ユースケースには実現前の要求定義、仕様の段階とOOPによる実現の段階があると思います。前者はOOPの実装だけには限定されない抽象レベルが高い段階だと思う。@takemasa ユースケースは、オブジェクトの協調なので、オブジェクトと同じ抽象レベル。抽象レベルではなく、視点が異なる。

竹内正治 @mshrtkch

オブジェクトは、ユースケースの語彙なので、ユースケースと同じく抽象レベルの段階がある。ユースケースとオブジェクトの視点を使い分けながら、一緒に抽象レベルの階段を上り下りするのは有効な方法

Masayoshi Hagiwara @masayh

ここでいうオブジェクトの定義は何ですか？OOPのオブジェクトとは違いますね。それとユースケースの実装にOOPは必須と考えていますでしょうか？@takemasa オブジェクトは、ユースケースの語彙

Masayoshi Hagiwara @masayh

ああ、これが竹内さんのいうオブジェクトの定義ですね。わかりました。それなら述語と大差ないです。でもこれ一般的用語ですか？@takemasa 「ユースケースは、オブジェクトの関係。責務は、オブジェクトそのもの」「責務は誰かが負うべきもので、その誰かがオブジェクトであると考えれば」

Masayoshi Hagiwara @masayh

述語は命題の集合という論理学の基盤があり定義も明確です。しかし、ユースケースが責務を連携してという「オブジェクト」の定義は工学的に定義できるのでしょうか。抽象度が高いからといって工学的定義ができないわけではありませんから。

Masayoshi Hagiwara @masayh

述語はものこと分析を意味論で使いますが、既存のDOAや概念分析と類似なのはそこまでです。2階論理以上にあると、それらとは違う結果が得られます。2階以上の論理になって初めて従来との優位性が現れる点が優位です。類似だからといって既存の技術の延長というわけではありません。

Masayoshi Hagiwara @masayh

OOの世界観は世界はすべてオブジェクトというインスタンスで記述できるのか。ああ、なんという均一で単純な世界なのでしょう。そこまで単純化してしまえば、なんでも記述できる理想の世界です。でもそれですべて解決できるほど単純な現実ではない。概念がそのまま動くことはないので。

Masayoshi Hagiwara @masayh

概念モデルを理想に近づけるとすれば、それだけ実装との差が広がることもありうる。たとえば、RDBとKVSを実装で使うだけで概念モデルとのギャップが変わる。問題が概念モデルをきれいに単純に記述することではなくて、それをいかにして動かすか。可変性や単純化を両立して。