＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
設計：「オブジェクト指向」で設計する事について
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-26 10:56
初心者が教える「オブジェクト指向で設計する技法」を勝手に記述しだして
少しずつ考えが、纏まってきました。 今なら返答できそうです。 
七味唐辛子さんへ＞ 今となれば確かに話が、ぶっ飛んでいますね。(^^; 以前、がるがるさんの講座で「オブジェクトの切り方が解らない！」 と質問させて頂きました。 これは、当り前の話で、 「言語の記述方法を知ったからプログラムが書ける訳では無い」と同じと思います。 オブジェクト指向は、オブジェクトの切方が解って習得完了と考えています。 勿論、「習得完了」の次もある訳ですが．．． このオブジェクトの切方は、開発経験の豊かな人、頭の良い人には多分、 理論建て無くても「こうだな！」と暗黙的に解ると思いますが、 初心者である今の内に、私がどの様な経過で習得していったか吐出さないと その内、私にとっても暗黙的な思考に陥ると思い、あの無茶なスレッドを建てました。 また、あのスレッドが「こう言う事です」という返答として受けとって下さい。 （長が〜く時間が掛りますが、、、） この暗黙知を体系建て話が出来るようになれば、 返答者として質問者に体系建て「何が解らないの？」と選択肢が提供出来ると思います。 ここまでこなければ、どうしたら、 「より再利用が出来る様になるのか」、「より解り易くなるのか」の議論が出来ないと考えます。 そして、なにより、「オブジェクト指向」でやっているのに後輩に 知識継承が出来ないと言う、変な矛盾が発生すると考えます。 | ||||||||||||||||||||
|
投稿日時: 2004-03-26 12:58
はにまるです。
おお、「契約(Contract)の概念」って言う言葉があるんですね勉強不足でした。 多分、「オブジェクト指向で設計する技法」を書上げたら、 それって、ｘｘｘｘの本に全部載っているよ？と突っ込まれそう．．． 契約概念は、オブジェクトの存在を守る暗黙的な所を明示する事と思うのですが、 私は、その契約概念を明示して、且つ契約概念の元（根拠、原因）を辿り、 そのオブジェクトの元オブジェクトを求める所にオブジェクト指向の意義を見ています。 # もしかして「Design by Contract」には、そこも含んでいます？ # 私が見たＨＰには記述されていなかった。 プログラムでは「継承」という概念で親から子に行くわけですが、 設計で大切なのは、子（自分が知っている知識）から見て親（暗黙知）は誰なのか？を考える事と考えています。 本当であれば、親から子なのでしょうが、現在のシステム開発では、多くの親（基礎技術）を失っている為、 今は、親を探すことが大切かと．．．． # それも、もしかして、、ｘｘｘ概念って既にあるんでしょうか？
「入力機能」「画面」「売上情報」を親としたのは、 「画面」はＯＳや言語ツールの制約を受ける。 「売上情報」は業務要件から来ている。 「入力機能」はシステム設計思想から来ている。 という考えから来ています。 「売上入力画面」が親としたのは、 基幹業務で売上管理をする場合は、「売上入力画面」があるのが当り前 という考えから来ています。 | ||||||||||||||||||||
|
投稿日時: 2004-03-28 14:27
はにまるです。
やはり、年度末は忙しいっすね．．． 割込み作業の多い事．．．
多分、るぱんさんの仰っているのは、顧客要件（設計書の機能目的欄に記述する内容） の事を言われているのかな？と思いました。 「要求者が作業者に仕事を頼む」場合に例えると、 作業者が対応手段の確認をする場合、要求者の依頼に重点が置かれますが、 もう一つ、対応手段を決める要素として、「作業者自身の能力レベル」があります。 対応手段を「決める／承認」する際に、作業者自身の能力レベルを殆ど意識しない理由として 作業者が「自分の能力を把握している」と思っている。 要求者が「依頼」前に、「作業者の選別」を先にしているからと考えます。 システム開発では、要求者と作業者の１対１の関係とは比べ物に成らない程 非常に複雑ですが、それでも、「要求者の依頼に重点を置く」対応手段の確認方法に 主眼が置かれています。 そして「作業者自身の能力」が管理の領域のみで話をしている事に疑問を感じ始めました。 私の言う、「設計根拠を設計する」の「根拠設計」とは今の所、 例で言う「要求者の依頼」は含めず、「作業者自身の能力」を示しています。
そう！また、それで対応出来ちゃうからなんですね．．． それで、いて、新人とかに「理屈が判って対応しろよ！」とか 生意気な事言ってますからね。 ^^;
おお、流石は経験者、これがオブジェクトの分割単位の基準ですね。 メモらさせて頂きます。 ．．．ところで質問ですが、 「２．コントローラ」はＭＶＣのＣと思っていいのでしょうか？ このコントローラって３階層アーキテクチャのビジネス・サービスに と同意義と思っていいものですかね？
ここですね、私は判らないんで、細分化して考え様と思います。
是非、私からもお願い致します。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-28 15:01 ] | ||||||||||||||||||||
|
投稿日時: 2004-03-28 14:52
はにまるです。
最初、こくぼさんの投稿時点で参照先を見ましたが然程感銘を受けませんでした、 （萩本さんごめんなさい） しかし、考えがまとまって来たので、返答前に今もう一度読み直すと、 私が言いたかった事の殆どが各１文で記述されている事に気が付きました。 やっぱ、読む側の人間もレベルを上げないと駄目ですね．．． 「オブジェクト指向が何故判り易いか？」と言えば、 立場やその局面によって、人は知りたい情報が変わります。 知りたい物が、全体から見てどのような位置付けか？ 知りたい場所は詳細に、それ以外は関係示すだけに概要で見せると良いと思います。 この考えから、オブジェクトは概要と詳細の２面性を持ち合わせている為、 判り易いになると思います。 つまり、オブジェクトを設計や開発する際は、この「概要と詳細」の２面性を 確りさせないと、意味をなさないとも考えています。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-28 14:57 ] | ||||||||||||||||||||
|
投稿日時: 2004-03-29 10:15
まず、はにまるさんの 「概要」と「詳細」の２面性について僕は同意しています。とした上で、 １．顧客 − ２．自分 − ３．作業者 とします。 ２−３の間は比較的に阿吽の呼吸を取りやすいことを念頭において、 ずぶのど素人の顧客でも説明しろと言われればいつでも説明できるような体制に整えておければ穴は出なくなるのではないかと考えてる所があります。 理屈のわかっていない人ほど物事の核心、根本的な矛盾を突く可能性が高いからです。 設計根拠を設計すると言うのは、設計レベルで全体的な整合性を取れている事が重要かなと。 プログラムレベルでは皆さん整合性取りたがりますよね？ 規模が大きくなるとめんどくさいので、 設計レベルでの整合性云々は言わなくなるんですよね。不思議な話です。 最近はその整合性を確立する為の「EA」なんて発想が出て来てますよね。
ＭＶＣのＣと言うよりは、 ビジネスモデルロジックの切り分けのポイントとしてのコントローラですね。 で、先の発言の 末端のＧＵＩを統合して切り分けているポイント・・・ と言う発言に流れ着くわけなんですけどね。 動的にする際には、どこか静的に流れを押えて制限しているポイントが 必要になりますよね？ それがコントローラの役割なんではないかと思っています。 | ||||||||||||||||||||
|
投稿日時: 2004-03-29 13:07
はにまるです。
前文に関して、話をどの様に持っていきたいか解りませんでした。 勿論、その原因が私にある事は言うまでもありません。ごめんなさい。 
# 同じ様に、私へのご指摘御を御願い致します。
ここの考えが私と異なります。 「２．自分−３．作業者」の話は「１．顧客−２．自分」と比較した場合、 確かに各段に意志疎通はし易いですが、私の周囲ではＯＫを出せるレベルではありません。 「１．顧客 − ２．自分」「２．自分 − ３．作業者」 のどちらにしても問題の置き場所は、「２．自分」としないと技術論にならないと思いますので 問題場所は、「２．自分」として話を進めませんか？ 仕切直しとして、モヤモヤして文書に出来なかった考えを記述します、 「２．自分」が設計した理由（自分のスキル側）が何かを明示する癖を付けないと、 効率的で品質の高い設計技術を学ぶ事が出来ない。 取りあえず自分が認識している範囲でいいから設計し、 その後、設計根拠を辿り、本当にその考えが最適なのか考え品質をあげる。 また、設計時に再利用性が高くなるのは 「要求に対する設計」では無く「設計根拠の設計」でしか無い、 この再利用により品質を上げる事が出来る。 「要求に対する設計」は単純に要求が一致した時だけの話となる。 つまり、 「要求に対する設計」をインスタンスとし、 「設計根拠の設計」をクラスとした オブジェクト指向で設計する技法が、設計者の技術向上に必要 という事です。後、 また、オブジェクト指向の技術投入の初期段階では、 オブジェクト指向の恩恵は言語を使う事により発生しているものであり、 設計自体は、殆ど変ら無い。（ＵＭＬの設計書が追加される位） これは、オブジェクト指向とモジュール分割技法を比較して、 その差が不明であれば、初期段階と思う。 言語からの恩恵に満足せずに、 次のオブジェクト指向の技術投入先として「設計」を考えなおし、 そして、「業務定義」や「業務分析」へ摘要と順を追わないと、 その効果が半減する。 って言うのが、私の妄想で確立しています。
ん．．そうですね確かに、それはありますね． 理解出来ない人は、全体像を常にもっているからと言う事でしょうか。。。 逆にすれば、「理解出来ない時は、全体像を常に頭に置いとけよ！」って事か.. 反省。 # ２回も修正しています  [ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-29 13:18 ] | ||||||||||||||||||||
|
投稿日時: 2004-03-29 13:44
るぱんです。 お客さんに求められていない物は作らなくて良い・・・と言う背景が邪魔してますね。 言っていることは基本的に同じ事です。 しかし、僕は自分が作った物はいつ聞かれても良いようにしています。 資料もあるし、自分が判断した判断基準も明示できます。 お客さんの要求があるから説明するのではなく、 説明を求められなくても説明できる体制だけ整えておけば良いと考えてます。 もし、仮に、お客さんがわがまま言ったとしても、 断る理由ができるわけですし、追加のお金を貰うポイントにする根拠にもできます。 ここから逆算します。 仮に「修正・変更」がかかった際の巻きなおしにかかる費用と、 予め書類を作っておいて防波堤にできる体制を整えておく事のどちらが効率的か？ と言う問題が有るとしたら、間違いなく「書類を作る」になると思うんです。 と言うことは、「作る人がお客さんに見られると言う覚悟で作る」としていれば、 何も問題は発生しないのではないか？と考えてます。 誰にも見られない書類を作ることは非効率です。 しかし、説明を求められて資料が出てこない方が大問題ではないですか？ 例えば、六本木ヒルズの詳細仕様変更の議事録が存在していないと言うことが トラブルが起こっている現在の混乱を如実に表しているのではないかと考えています。 想定の範囲を越えた・・・の一言で人が一人死んでますよね？ そんな状態で「仕様です。」と言い切れませんよね？ 作ったシステムのせいで人が一人クビが飛ぶかもしれません。 怖いです。 あ、基本的に、僕は誰にも世話になりたくない・・・と考えている節があります。 上司だろうがなんだろうが「利用する」のは最後の手段・・・かな？ 基本的なコンセプトの置き方の違いじゃないでしょうか？ あと、技術論をする気は毛頭ないです。 誰でもわかる基準でYes/Noが出来る書類を用意しておくだけです。 そこで、全員がYesと言えたら、僕の責任範囲から外れるからです。 トラブル発生 ↓ 原因追求（実作業者） ↓ 企画が甘かった ↓ 企画した奴が悪い 下流工程でやる以上、一番最初に原因追求が来ます。 それを「上流工程のせいなのか」、「下流工程のせいなのか」 切り分けやすい資料を作っておけば良いと考えています。 今回は設計が問題なので次のような形になります。 顧客要求 ↓ 要求定義 ↓ 設計作業 ↓ 作成作業 ↓ テスト ↓ 実運用 問題が起きた時には実運用でトラブルの場合、まず、テスト結果と見比べて 想定パターンかどうか？ ↓ コード検証 ↓ 設計の検証 ↓ 要求定義の検証 ↓ 要求の検証 の順にさかのぼると思うんです。 その時に、自分が判断した設計基準が既に書類になっていれば、 要求定義の問題で、それは自分の責任範囲ではないと言い切れるからです。 もしそこで、要求定義に乗っていない想定をしろといわれたら、 「要求定義の問題です。」とシビアに断れますからね。 「追加案件で良いですね？」って言えますし。 要求定義にメモとして乗ってたらそれは設計のミスになるでしょうし。 判断がしやすくて良いと思いません？ 外注で食ってくためには責任回避手段はできるだけ用意していないと責任をかぶせられて 終わるんですよ。都合よく使われたり。 だからと言って、責任をなすりつけるのも僕の性格に合わないものですから書類作ってます。 自己保身と捉えられるかもしれませんけれど、 それぐらいシビアに出来ないと食いつなぐのが厳しいんですよね。 基本的に丸投げを受けてるわけですし。 お客さんによっては気まぐれでチェックが入る事もありますし。 | ||||||||||||||||||||
|
投稿日時: 2004-03-29 14:33
はにまるです。
るぱんさんの文書を読み．．． > お客さんに求められていない物は作らなくて良い・・・と言う背景が邪魔してますね。 に激しく同意。 そこが設計技術が低レベルなままの一大要因ですかね．． ^^; とすると、オブジェクト指向で設計するには、そこの概念を取っ払う必要があるって 事ですかね．．．ちょっと思考中。 後、読み終えると同時に、 「るぱんさん、もうやっちゃっているよ．．．」 敗北感たっぷり
って感じです。 
しかし、どうしよ、あっちのスレッド、、、
# 駄文 過去の議論（別スレッド込み込みで）を含めて、るぱんさんの事を考えると なんか、勿体無い状態にいますね．．．（余計な御世話！と言われそうですが） 「そりゃー愚痴も増える」って感じです。 | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.