SSブログ

「実践UML 第3版」と責務駆動設計 [判断と実行の混同例]

さて「ソフトウェア工学には頭脳が足りない」シリーズの2回目です。「シリーズだったんだ、これ。」って自分でもそんな感じですが、前回のアクセス数が多かったのでタイトルを流用することにしました。現金で申し訳ありません。ついでにシリーズだけを追掛けやすい様にブログ自身も分けました。なお、予想通りtwitter上でアンチな反応もありましたが、直接メンションを付けられたわけではないので補足や反論はせず、伝え切れていない事を伝える事に専念したいと思います。議論をお望みでしたら、直接こちらにコメントする様にお願いします。

それでは始めましょう。
今回は前回にちょっとだけ触れた「ユースケース図」について取り上げる予定でしたが、予定を変更してUMLのバイブル本の一つ「実践UML 第3版」を吊るし上げたいと思います*。(おいw)語尾も今回だけ「ですます」調に変わりますが、よろしくお付き合いください。

さて、いきなりですが私は責務駆動設計の思想が大好きです。責務駆動設計自身についてもいつかこのシリーズで取り上げたいと思っていますが、なんで好きかというと「擬人化」を核にしているからです。擬人化を使った高度な設計技法の開発に20年以上前から取り組んでいるなんて、まさしく敬服するに値します。渡航費用を持っていたら行って考案者のほっぺにキスしたいぐらいです。
そのぐらいお気に入りなんですが、じつは恥ずかしながら、昨年日本語版が発売された「エリック・エヴァンスのドメイン駆動設計」に関する記事をネットで見かけるまで「責務駆動設計」のことを知りませんでした。当然、方々に影響を与えている事を知る由もなく、今頃になって関連書籍を読み漁っています。

今回取り上げる「実践UML第3版」もその中の一冊です。これでも昔はUMLに熱中していたのですが「実践UML」は高過ぎ・分厚過ぎでチェックしていませんでした。本を開くと、いきなり見返しにGRASPパターンの一覧表が出てきて期待が膨らみます。GRASPとは責務駆動設計での原理・原則です。他の記事は飛ばして「第17章 GRASP: 責任駆動のオブジェクト設計」(「責任」と訳されているが元は同じresponsibilites)を読み始めたのですが、いきなりつまずきました。なぜ?って、それは「判断と実行の混同」に出くわしたからです。

ここで「判断と実行の混同」について解説しておきましょう。人は「認識もしくは判断」によって意思決定し、「行動」によってその意思をアウトプットします。ただし他人から見ると「行動によって意思がもたらされた」ように見えます。これが典型的な「判断と実行の混同」です。結果を利用するだけならばこの混同は省力化につながるのですが、プログラムの設計をするには「判断」と「実行」を区別しないとまずい場合が多々あります。我々は「判断と実行の混同」に慣れ過ぎているので、この区別は意識的に行わなくてはなりません。それがこのブログのテーマです。ちなみにソフトウェアの実行はサービスとして行われる事が多いので「判断とサービスの混同」と表記することもあります。これらは前回「頭脳とスキルの混同」と呼んでいたものと同じです。ただ、「頭脳」も「スキル」もメタファ(比喩)なので、より直接的な表現に変えました。さて、話を元に戻しましょう。

「実践UML第3版」の「17.3 責任と責任駆動設計」では、
責任(責務)は「実行と情報把握」に分けられるとして、次の様に述べています。



オブジェクトの実行責任には以下のものが含まれます。
 ○オブジェクトの生成や計算の実行など、何かをそれ自体で行う
 ○他のオブジェクトのアクションを始動する
 ○他のオブジェクトのアクティビティを制御し調整する

オブジェクトの情報把握責任には以下のものが含まれます。
 ○カプセル化されたプライベートなデータを把握する
 ○関連するオブジェクトを把握する
 ○導出または計算可能なものを把握する



さて、どこで「判断と実行の混同」が起きているか分かりますか?
「実行と情報把握」に「判断」が含まれて無いのは一目で分かりますね。では、どこに紛れ込んでいるのでしょう?
先の短い箇条書きからは推測が難しいのですが、おそらく「他のオブジェクトのアクションを始動する」という項です。あるいはその下の「他のオブジェクトのアクティビティを制御し調整する」にも混ざっているかもしれません。どちらも他のオブジェクトに「命令」もしくは「メッセージ」を送って相手を動かしているのですが、「命令」と「メッセージ」では全く性質が違います。命令は自分が判断した事を暗示します。メッセージ送信は相手が判断する事が前提です。その区別がつかないと言う事が混同の証拠です。

ちなみに本家「オブジェクトデザイン ロール、責務、コラボレーションによる設計技法」では「責務とは何か」という項で微妙に異なるまとめ方をしています。



・オブジェクトが行う行動
・オブジェクトが持つ知識
・オブジェクトが他に影響を与える主要な判断



さすがは本家本元!擬人化のツボを押さえて、「頭脳」と「サービス」をきちんと区別しています。

ちなみに擬人化設計技法の基本メタファ「心技体=頭脳、技術、フィジカル」と、どう対応するかというと

「オブジェクトが行う行動」が「技術(というか、Plan-Do-CheckのDo)」
「オブジェクトが持つ知識」が「フィジカル」
「オブジェクトが他に影響を与える主要な判断」が「頭脳」です。

まぁ「行動⇔技術」「知識⇔フィジカル」は結構強引ですけどね。知識(≒データ)はプログラム中では普遍的な存在ですが、あえて一つに当てはめると消去法で「フィジカル」になります。知識と聞いて「頭脳かな?」と思った人も多いでしょうが、頭脳役は「判断するのがお仕事」ですからすでに埋まっています。「フィジカル」は典型的なメタファなので具体的にイメージしづらいのですが、大雑把に「仮想世界のフィジカル(身体+道具)=データ≒知識」と思ってもらえばいいです。当然、重要な情報はフィジカルに集積されます。

いずれにしてもオブジェクト指向の枠内で活動してきたはずのに「頭脳」と「サービス」をきちんと区別しているのですから、やはり流石と言うより他にありません。思わぬところで「責務駆動設計」本家の素晴しさを再認識することになったのですが、この「ソフトウェア工学には頭脳が足りない」シリーズではこうした「判断(頭脳)と実行(スキル)の混同」を見つけたら随時取り上げていきたいと思います。

最後に一つ、演習問題です。
「オブジェクトが行う判断」ではなく「オブジェクトが他に影響を与える主要な判断」を責務としている理由は何でしょうか?
答えは責務駆動設計について取り上げる時に載せます。それまで待てない人は「オブジェクトデザイン ロール、責務、コラボレーションによる設計技法」を読んでみてください。

さて、次回は予定通り「ユースケース」を取り上げ、語尾も「である」調に戻します。
その後は「MVC」とか「REAモデル」とか「過去のプログラミング・パラダイム」とかを取り上げる予定です。
ディープなネタが続きますので、お楽しみに。
ではまた。

*注
この記事は「実践UML 第3版」の価値を貶めるものではありません。「判断とサービスの混同」はオブジェクト指向設計全般でよく見かけますし、「実践UML 第3版」にはGRASPのコントローラ・パターンも載ってますから、勘の良い設計者なら正しい設計に気付くでしょう。また、オブジェクト指向設計にも素晴しい点はたくさんあります。責務駆動設計を取り入れたものなら尚更です。「実践UML 第3版」のGRASPについての記述は詳細設計において大いに役立つ事でしょう。


実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

  • 作者: クレーグ・ラーマン
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2007/11/12
  • メディア: 単行本(ソフトカバー)




オブジェクトデザイン (Object Oriented SELECTION)

オブジェクトデザイン (Object Oriented SELECTION)

  • 作者: レベッカ・ワーフスブラック
  • 出版社/メーカー: 翔泳社
  • 発売日: 2007/09/13
  • メディア: 大型本



nice!(0)  コメント(1)  トラックバック(0) 
共通テーマ:パソコン・インターネット

nice! 0

コメント 1

yazılım

共有していただきありがとうございます。
by yazılım (2023-06-27 01:58) 

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

トラックバック 0

-|ユースケースのケースって何? ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。