@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ロバストネス分析から実装レベルの相互作用図の依存度は
投稿者 | 投稿内容 | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-06-28 13:07
こちらも横槍になりますが・・・
モデルを表すのに文字ベースで表すことは可能だと思いますが、 そこから、モデルの関連などを理解するのは難しいです。 モデル図を使えば、文字ベースよりも理解しやすいと思います。 そもそも、文字ベースだろうがモデル図だろうが、表しているのはシステムの一部なので 表現方法が変わっても問題無いというか、むしろ適した表現方法を選択するのが賢いと思います。 モデル図は、サポート情報か?:作成&メンテナンスする労力に十分な見返りがあり、サポートとはいえない。必須な情報。 図は加工し難い:加工し易い理解し難いドキュメントよりマシ 図は曖昧になる:文字で記述しても曖昧な記述は可能、曖昧さを減らすには記述者の曖昧さを減らす意識が大切。図だから文字だからは関係ない。 | ||||||||||||||||||||||||
|
投稿日時: 2004-06-28 17:54
私の言葉を使っている所は、私に対する反論ですか? 反論であるならば、私からの返答は下記の通りです。
モデル図の技法自体は、効果の保証はしていませんし、 モデル図が無くてもシステム開発は出来るので必須では無いと考えます。
理解し難い「図」も存在します。それとも単に システム開発自体に関する情報は加工性を無視してでも理解性が重要と仰っているのでしょうか? きっと「管理」が思考対象から外れていると思います。
文字で表現される全て情報は、図で精度を落す事無く表現出来ると仰るのでしょうか? それは、説明が不要な図式表記が出来るとも取れますが。 勘違いされているのかな?と思いますので説明すれば 現在の議論は、「文字」VS「図」になっている訳では無いと考えます。 私自身は図を多用する人間です。 | ||||||||||||||||||||||||
|
投稿日時: 2004-06-28 18:21
objectです。
るばんさんの御意見は、とても素直な意見だと思いました。 オブジェクト指向の学習過程で良く言われる 「初心者の方が理解し易い」 と言われる要因は、るばんさんが述べておられる事に関連してるんだと思います。 私は、I.ヤコブソンが提唱する「OOSE」は、ある意味で概要が先に見えてくるアプローチを目指していると思うんですよね。 今までは、ドメイン領域を対象としていませんでしたよね。 そういう意味では、確かにそうで、概要が先に見えて来る可能性が先ず無かった訳です。 でも今、その流れが変わりつつあるという事ではないでしょうか?
私も、基本的には、tak3さんと同じ考えです。 数学的に重要で基本的な構造として 1)代数構造 2)順序構造 3)位相構造 があると思います。 #これらが完全に独立に存在し認識出来る訳ではないのですが…。 「文字ベース情報」は、代数構造と順序構造がメインで表現されていると私は思っています。 #もちろん、「文字ベース情報」でもそのコンテキストを追えば、位相構造が見えて来る訳ですが…。 「モデル」は、位相構造と順序構造がメインで表現されていると思っています。 しかし、「モデル」でもその表現方法を完成させていけば、代数構造も直感的に表せるのではないか、と私は密かに思っています。 このスレも、テーマからかなり離れて来たので、私はこの辺で終わりにします。 [ メッセージ編集済み 編集者: object 編集日時 2004-06-28 18:27 ] | ||||||||||||||||||||||||
|
投稿日時: 2004-06-28 23:47
私の意見は、はにまるさんの反論というわけでは、ありません。
一部、反論というか”おや?”と思う部分があったので、自分の考えを述べただけです。 もちろん”「文字」VS「図」”というような話をしているわけでもありません。 と、いってもあの書き方では、そうとられても仕方が無いと思いました。 もう少し推敲して投稿するべきでした。 で、あらためて個人の意見を言わせてもらうと 1.モデル図を使えば、文字ベースよりもモデルの関連を理解しやすい。 2.システムを表現するのに”根底は「○○ベース」”というより適した表現を用いるべき。 1については、確かに保証されていませんが、私はそう感じています。 まず、この大前提の元に意見があるので、これが間違ってると感じたら下記の意見も間違ってると感じることになると思います。
管理の話をするのであればこそ、クラス図は重要だと思います。 ”無くてもシステム開発ができるので必須でない”よりも ”有れば効率的にシステム開発ができるので必須”と思っています。 図の効果は、はにまるさん自身が仰っています(2004-06-25 14:48)
クラスの関連は「文字ベース情報」よりも「モデル図」で表現するほうが適切だと思います。 理解し難いクラス図は、文字で表現してもより理解し難いと思っています(個人の主観) システム開発自体に関する情報は、理解性を無視してでも加工性が重要と仰っていますか? ドキュメントに対して「メンテナンスすること」を重視していますが、 作ったドキュメントは参照されるのでメンテナンスを重視しているのですよね? 参照されないドキュメントを作る必要は無いですよね 参照されるときに、人それぞれで解釈がちがったら困りますよね? アウトプットとしてのドキュメントより、インプットの位置付けのほうが、より重要だと思います。 # だからこそ曖昧な図が云々という意見を述べられてると思いました。 # この辺りも、はにまるさんと意見が違うと感じてなかったのですが・・・ ドキュメントを理解する時間が減らせるならば、工数をかけてクラス図を作成する 価値がありますよね。(仰る通り保証されていません<理解する時間の減少) あとクラス図はソースコードの雛型を作れるレベルで記述ができます。 このソースコードを、はにまるさんのいう「文字ベース情報」だと仮定しますが、 ソースコードをクラス数分渡されるより、クラス図を1枚渡されたほうが、 私はクラスの関連を理解しやすいと思います。(個人の主観です) 念のため言いますが、ここで理解したいのはクラスの詳細でなくクラスの関連です。 [ メッセージ編集済み 編集者: tak3 編集日時 2004-06-29 01:23 ] | ||||||||||||||||||||||||
|
投稿日時: 2004-06-29 10:45
畏まりました。
あくまで反論に対する返答ですので、同意や反論する意図が無い文書は 省略致します。
クラス図と言う特定の図式表現が出ましたが、 管理とは一部フェーズの話しをいている訳では無くシステム開発全工程に対する管理です。 要件定義で発生した「要件」からサービス提供するまでに1連の流れを持ってシステム開発を する際、前工程から発せられる要求を漏れなく満たす検査機構は持たせる場合は、 図では困難です。
「必須」の定義が異なる様ですね。DB好きな私は、 「必須」とは、それ無しでは事を無し得ない物を示します。 (例) # コードは必須、名称は非必須、普通に考えれば名称が無いのは人間として困るが、 # システム的に必須では無い。
上段文書は同意ですが、 下段文書を読むと、図式表現と設計技術を混在されていると思います。
私の質問を逆手に取った逆質問と思いますが、 私の質問は、前投稿の「>それとも単に」とある様に 「>図は加工し難い:加工し易い理解し難いドキュメントよりマシ 」への意図の確認です。 >作ったドキュメントは参照されるのでメンテナンスを重視しているのですよね? 一過性のドキュメントもあります。その際はメンテナンス性は重視しません。 特に運用フェーズに入ると管理対象資料を一気に絞り込むので、 私は、参照性とメンテナンス性は別物で捉えています。 >参照されるときに、人それぞれで解釈がちがったら困りますよね? 困りますが、何故その話しが出てくるのですか?どこに掛る文書でしょうか? >アウトプットとしてのドキュメントより、インプットの位置付けのほうが、より重要だと思います。 「ドキュメント」と「位置付け」を比較してインプットが「重要」となっています。 多分、文書の記述漏れでは? | ||||||||||||||||||||||||
|
投稿日時: 2004-06-29 11:47
おはようございます。
るぱんです。
これって、方向性がTop Downですよね? 今現在の業務が無ければこれは非常に正しいあるべき姿だと考えます。 動いている仕事で、既にある程度のシステムが有る場合は、 Bottom Up-Middle Down後にMiddle Up-Top Downとなるような感じで それぞれの繰り返しが必要なのではないでしょうか? 概要から入るのはわかりますけれど、 付いて来れない人は切り捨てる・・・ってなりませんかね? 概要から入る事ができるのはやっぱり理想モデルでしかないのではないでしょうか? 大事なのは、現実モデルとぶつけてみて、違和感無くスムーズに移行する事の方が 重要なんじゃないかな?って思いました。 概要と言うのはわかるのですが、概要がしっかりして無いと困りますよね? 概要がひっくり返った場合、エンジニアが一番被害こうむると思うんです。 で、僕らが逆に概要からはいれるケースと言うのは、 業務知識がさほど要らない状態じゃないでしょうか? それとも、現場を見ないで概要をいきなり書くことから始めると言うことでしょうか? 疑問が残りました。 | ||||||||||||||||||||||||
|
投稿日時: 2004-06-29 17:43
objectです。
>るばんさん >これって、方向性がTop Downですよね? 私は、「Top Down」と「Bottom Up」とのどちらかというと、 「Bottom Up」だと思います。 「るばんさん」は、「Top」・「Bottom」をどの様に考えておられるのでしょう? #ここで、「Top」・「Bottom」に対する私の説明はしません。 それから、確かに 「Top」 「Bottom」 という範疇で考える事は、有効な場合があると思います。 しかし、私は前のレスで「ドメイン領域」と書きました。 つまり、ここでは ドメイン <-> コドメイン という「スタンス」で考えている訳です。 そして、「概要」という言葉は、 「ドメイン領域」に於ける「認知プロセス」での初期状態 という程度の意味で使っています。 少し、補足しておきます。 >動いている仕事で、既にある程度のシステムが有る場合は、 >-------------------------------------------- 上記以降の内容に関しては、誤解の上に展開された「るばんさん」の考えだと判断し、コメントはしません。 | ||||||||||||||||||||||||
|
投稿日時: 2004-06-29 23:46
ドメイン←→コドメイン ドメインをTOP、コドメインをBottomと捉えてます。 通常の視点と敢えてずらしてます。 どんなものでも、上の階層から行けばTOP 下の階層から行けばBottomで捉えています。 行ったりきたりをしながら最適解を探る・・・って事なんですけどね。 認知プロセスに関しては、納得です。 でも、認知プロセスで、一発目から概要を抜けるほどではないですね。。。 ちょっと混沌とした現場が多いです。 仕様書も無い事が多いですし。
理想を決める場合には、いきなり概要でOKでしょうけれど、 既に何かしら資産の有るところからStartする場合には、 全体的な整合性検証の手段を構築してからになりませんか? ・・・って程度の意味です。 軽く流していただいても結構です。 |