ObjectSquare

[編集委員のあいだで飛び交ったメールより抜粋]


-ほとんど生データですので、すっかりカオス状態ですが、編集部の雰囲気を感じ取っていただけたら幸いです-

U>#で、カプセル設計って言葉あるのでしょうか? 聞いたこともない。。

S>U> #で、カプセル設計って言葉あるのでしょうか? 聞いたこともない。。
S>
S>ふう、ちょっと安心しました。
S># カプセル設計知らないのは私だけかと思った。
S>
S>ところで、「b:カプセル設計」ってなんのことでしょう?
S>私はカプセル化、つまり、クラスに属性と操作を定義すること(を云いたいの)
S>だと思いました。
S>そう考えると、「a:オブジェクトモデリング」は単純に概念としてのクラス(あ
S>るいはタイプ)を抽出するだけだと考えられないでしょうか?
S>
S>ところで、この問題の解答が「エ」ということに異論はないのでしょうか?
S>>皆さん
S>さっき読んだとき、なんとなくウを選択してしまいました。
S>
S>c: 業務プロセスモデリング(ユースケース作成など)
S>a: オブジェクトモデリング(概念(クラス)の抽出とラフな関連)
S>b: カプセル設計(クラスに属性と操作を入れる)
S>d: 制御設計(シーケンス図?)
S>
S># といいつつ、シーケンス図書きながら操作を加えたりもするしなぁ。
S>
S>別の案として、カプセル化はサブシステム分けといえるかも。
S>といってもサブシステム分けのタイミングって様々なケースが考えられますよね。
S>
S>うーん、さっぱり分からないSでした。

N>この世の中、Unified ProcessだけがOO技法じゃないんだから
N>ちょっとした応用力・想像力が欲しいものです。
N>
N>dにおいて、シーケンス図やコラボレーション図で
N>各ユースケース実現に必要なオブジェクトと操作を識別し
N>どこに何を割り振ったらリスポンシビリティが適切かを考えて
N>スムーズに制御が流れる設計を行い、
N>
N>bでは、その結果を受けて、各クラス仕様を属性・操作を含めて定義するという
N>あたりまえの作業のことを言っているのです。

H>U>#で、カプセル設計って言葉あるのでしょうか? 聞いたこともない。。
H>
H>賛成!
H>
H>ついでに「制御設計」も聞いたことありませんね。
H>
H>ちなみに、業務プロセスモデリングの前にまず
H>概念モデリングとして、オブジェクトモデリングをやるのも
H>よくやる一般的な手法だと思います。
H>また、システム開発が終わるまでずっとオブジェクトモデリングは
H>継続して行うのが一般的だと思います。
H>
H>いったいどこで定義されている開発プロセスの用語について
H>質問しているのかわかりませんね。

N>情報処理試験の問題は深く考える人には不利ですね。

U>H> ついでに「制御設計」も聞いたことありませんね。
U>
U>ですね。どこの時代のどこの言葉なのでしょう。
U>
U>H> ちなみに、業務プロセスモデリングの前にまず
U>H> 概念モデリングとして、オブジェクトモデリングをやるのも
U>H> よくやる一般的な手法だと思います。
U>H> また、システム開発が終わるまでずっとオブジェクトモデリングは
U>H> 継続して行うのが一般的だと思います。
U>
U>Yes, indeed.
U>
U>こうした問題があると、あたかもこの順番で行わければならない
U>ような感覚を受けますよね。悪問と思います。
U>
U># ちなみに今回コンサルしたQ社も、順番を決めたがりました。
U># 「各工程の成果物の完了をきちんと確認してから次の工程に進む」という
U># 考えがどうしても抜けないようで苦労しました。。。
U>
U># 視点を変化させてぐるぐる回るからこそ本質が見えるんですよね。

H>N>bでは、その結果を受けて、各クラス仕様を属性・操作を含めて定義するという
H>N>あたりまえの作業のことを言っているのです。
H>
H>でもやっぱり、オブジェクトモデルを主要成果物として、
H>開発プロセス全体を通じて作り上げていくオブジェクト指向開発の本質を
H>とらえた問題であって欲しいと思います。

U>N>この世の中、Unified ProcessだけがOO技法じゃないんだから
U>N>ちょっとした応用力・想像力が欲しいものです。
U>
U>出展が知りたいですよね。「オブジェクトモデリング」はOMTで聞いたこと
U>があるような気がしますが。。
U>
U>Capsule Design?
U>Control Design?
U>
U>それとも国産の開発プロセス手法?

U>S> ところで、「b:カプセル設計」ってなんのことでしょう?
U>
U>私の解釈では、おそらく、オブジェクトモデリングがある程度進んだ段階で、
U>クラスの属性、操作の可視性を定義することと見ました。多分。
U>
U>S> ところで、この問題の解答が「エ」ということに異論はないのでしょうか?
U>S> >皆さん
U>S> さっき読んだとき、なんとなくウを選択してしまいました。
U>
U>わたしもなんとなくウにしました。
U>
U>「制御設計」をオブジェクトのコラボレーションとしての制御ではなく、
U>「カプセル設計」後のクラスのメソッド内部の制御(アルゴリズム)を決める
U>のかなと思ったのでした。
U>
U>と、いうわけで何度もいいますが、愚問です。

B>B@私もウと思ったです。
B>
B>私も「制御」って聞いたら、妙に細かいレベルが連想されて、
B>同じようにアルゴリズムレベルの話かと思います。
B>(なんだか仲間が多くてうれしい ^^;)

K>えへへ、実は私も... (^^;
K>
K>K@編集委員全滅か??!

N>S>「制御設計」をオブジェクトのコラボレーションとしての制御ではなく、
N>S>「カプセル設計」後のクラスのメソッド内部の制御(アルゴリズム)を決める
N>S>のかなと思ったのでした。
N>
N>いや、それだったら、メソッド設計、操作設計、アルゴリズム設計などというでしょう。
N>
N>いやしくも「制御」というからには複数の対象(オブジェクトだったりプロセスだったり
N>トランザクションだったりしますが)の間の”コーディネーション”いいかえると協調
N>を設計することだと考えるのが常識の線でしょう。
N>
N>さらにWさんやSさんの専門の組込みリアルタイム系では
N>制御設計において、スレッドやプロセスのコーディネーションを行って
N>そこで都合が悪ければオブジェクトモデリングで識別したオブジェクトの境界を
N>壊してやったりしますから、
N>
N>まさにその後のカプセル設計フェーズで、最終的な実装のレベルでのオブジェクト仕様として
N>プロセス境界を考慮したカプセル化を設計しなおすわけですね。
N>
N>ということで、やはりユースケース実現の検討としての制御設計という解釈に落ちつくのでは。
N>
N>わたしは結構この問題いい問題と思いますが。
N>特に、制御設計とカプセル設計の順序を問うところが渋いですね。

H>妙にかばうところが怪しい...
H>もしかしてこの問題の出題者はN氏のよく知っているオブジェクト友達なのでは?
H>あるいはN氏自身が出題者なのでは?などと私は勘ぐってしまいますが。

B>ちなみに世の中の回答速報やってるところでは、、、
B>
B>アイテック https://www.itec.co.jp -> ウ
B>TAC https://www.tac-school.co.jp -> イ
B>日経産業新聞 -> ウ
B>
B>ですね。

H>大変な盛り上がりですが、このあたりの一連のやり取りをまとめて掲載してしまうと
H>とっても面白い記事になるのではないでしょうか?

U>問題作成者の意図が伝わりにくく、いろいろな意見が出てきてしまう
U>ということなので、迷問ですね。

...そうして編集部の夜は更けていくのでした...

© 1999 OGIS-RI Co., Ltd.
Prev
Prev.