＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
オブジェクト指向分析・設計？
1
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-29 09:45
るぱんです。
お知恵を拝借したいので宜しくお願いします。 具体的に
「ピンポイントでこれだ！こうやるんだぁ！」っていうのが少ないと思います。 皆さんの意識をお伺いしたいです。 他に参考となるＨＰや書籍が有れば教えて頂きたいです。 本探したんですが、トッパン出版は絶版・・・・。 読みたいタイトルの本がおおいんだけどなぁ・・・。（「ＯＯＡ」や「ＯＯＤ」） | ||||||||||||||||||||
|
投稿日時: 2004-09-30 10:32
るぱんさま
意識調査だと思えばよろしいでしょうか。 ということで、私が考えているあたり。 1.ドメイン分析 いわゆるオブジェクト指向開発手法は、要求分析、主にユースケース分析からはじまりますが、実際のところ、客先の常識を知らないことにはユースケース分析も話にならない。 ということで、「客先の常識を整理しておきましょう」ということで行うのがドメイン分析。ドメイン分析という言葉が一般語なので、何をどうするのかというのは人それぞれ。 ドメイン分析のうち、ビジネスワークフローから、システムの行う事と行わないこと事の境目をはっきりさせようとするのが、ユースケース分析であると解釈することもできる。 ドメイン分析のうち、概念というかデータの静的構造というか、そういうものを記述するのが、概念モデル。 私は、振る舞いと構造(というかデータ)を分けて話を進めるのは、オブジェクト指向の本質から外れていると思う。 ということで、私はドメイン分析といったら、概念モデルをベースに、振る舞いをそこに乗せこむ形で仕事を進めています。 2.ロバストネス分析 バウンダリ・コントロール・エンティティという3つの分類で話を進めようとする分析。 なぜか、MVCとはこいつのことだという誤解が広まっている気がする。 (MVCのC コントローラはいわばインプットハンドラ。ロバストネス分析のコントロールとは違うものなのだが…) で、バウンダリを分離するのはともかく、コントロールとエンティティを分けるのは、振る舞いとデータを分離しようとすることになるので、私はロバストネス分析が大嫌い。 http://www.ogis-ri.co.jp/otc/hiroba/technical/RobustnessAnalysis/RA1/ 3.その他 ・イベント-レスポンス分析？ 私は組み込みソフト開発をやっています。 この分野は今でこそいろいろオブジェクト指向の開発手法が出てますが、他の分野に比べまだまだ遅れてます。 なので、必要な手法は自分で考える、他の分野の手法をポーティングするということが必要でした。 ということで、自作の分析手法のうちの１つ。 ・システムを[イベント-レスポンス]対の塊であると考え、とにかくこれを列挙する。 ・[イベント-レスポンス]対には、レイヤが存在するので、レイヤは分けて考える。 ([１バイトの受信割り込み-割り込み要因解除][パケット受信-応答送信][サービス要求-サービス]。これらはレイヤが違う。レイヤが違うと分析する時期が違う。) ・[イベント-レスポンス]対の優先順位、許容時間、イベント発生元などの情報を書いて一覧化 この分析の結果はスレッド/タスクの候補となっています。あくまで分析なので、設計は別途。 振る舞い分析のうちの一つなので、ユースケース分析の一部ともオーバーラップする。というか矛盾すると話にならない。 4.参考 開発手法というわけではありませんが、好きなページです。 話は古いのですが。 「オブジェクト指向システム分析設計入門」 http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/index.htm | ||||||||||||||||||||
|
投稿日時: 2004-09-30 13:17
るぱんです。
＞Elle様 ご返事ありがとうございます。 意識調査です。 「皆の考えている分析は何をどのように分析するのか？」 これがお伺いしたきっかけです。 １．ドメイン分析について ユースケース分析とドメイン分析の違いがわかっていなかった事からくる疑問だったと言う事に気が付けました。 業務プロセスからアクティビティ図を作成して、 書き下ろしたユースケース図に対してシステム化要件を切り分ける・・・と言う風に 捉えておりました。 そう考えた時に、 「ユースケース分析とはなんぞや？」 「ドメイン分析とはなんぞや？」 と言うところで詰まっていました。 上手く言葉にすら出来ていませんでした。 一緒にしてかまわないと言うとらえ方のお話を伺って明が開けた気がします。 ２．ロバストネス分析について。 ロバストネス（堅牢性）分析でkamedane.comと言うのを見つけたのですが、この中でこれだけこんがらがりやすい図をいきなりユースケース直後の最上流でやるべきかどうかに疑問がわきました。 やりたい事は、一つの大きなコントロールの中に小さいコントロールを内側に書きながらエンティティ迄をつなげていく作業ではないのかな？と思ってしまいました。 ＭＶＣのＣとコントロールは別物であるという認識です。 コントローラーとコントロールはまず、言葉が違うと思った為です。 そして、ロバストネス分析では、何を分析対象にするのか、また、分析項目にどんな物があるのかがまだ見えておりません。 今一度調べてみます。 可能ならばお返事を頂きたく思います。 宜しくお願いします。 ３．その他について 「イベント−レスポンス分析」なるキーワードは初めて目に致しました。 これは、アクションリスナーを押してから結果が戻ってくるまでの時間分析とかですか？ とあるオブジェクトのメソッドをたたいてから答えが帰ってくるまでの時間を分析してレスポンス性能を上げる為の物でしょうか？ コンポーネント単位でやったら非常に有効そう・・・。 疑問が更にわいて出て、収集がつかなくなりそうです。(;^_^A ｱｾｱｾ･･･ 非常に参考になりました。 本当にありがとうございます。（＾＾ | ||||||||||||||||||||
|
投稿日時: 2004-09-30 16:58
「ドメイン」とは問題領域、つまり現実の業務を分析することです。「ユースケース」は 解決領域すなわちシステムの機能を定義するものですから、そもそもまったく異なる目的 でおこなうものです。 ＃ただし「ビジネスユースケース」だと問題領域に属しますが
通常ロバストネス図はユースケースごとに作成しますので、こんな複雑な図が最初からできる わけではありません。というか、ロバストネス図はそれほど深く考えて作るようなものでは なく、一つの図にせいぜい一時間くらいかける程度のものです。ロバストネス図を有効活用 しようという方法論にICONIXアプローチがありますが、ICONIXでも実装段階になればロバス トネス図は「捨ててもいい」ものだと言っています。 また、Elleさんが
と書き込んでおられますが、ロバストネス図の構造をそのまま実装段階まで持ち込む必要は ありません。BCEのうち、BとCの一部がくっついたりEとCの一部がくっついたりすることは よくあることです。 どちらかというと、ロバストネス図はOOA/OODに不慣れな人がとっかりりとしておこなうのが いいんじゃないかと思います。好きじゃない/わからないならやらなくていいのではないかと。
CRC分析とか。自分ではやったことありませんが、考え方としては知っておいて損はないと 思います。本としては「実践UML」はまず読んでおくべきでしょう。これに書かれているGRASP パターンはOODの基本中の基本です。あと、ピーター・コード関連の本(カラーUNLとかストリーム オブジェクトモデリングとか)もいいのではないかと思います。 | ||||||||||||||||||||
|
投稿日時: 2004-09-30 17:32
るぱんです。
＞uk様 質問させてください。
ビジネスユースケース以外のユースケースはどんな時に書いた方が良い物なのでしょう？ システム間のユースケースでも、結局問題領域＝ユースケースとなる気がするのですが、このとらえ方は間違っているでしょうか？
ロバストネス分析とは堅牢性の検証の為に作る物ではないのですか？ コンポーネント図に引き渡す物として考えてました。 ・インターフェース以外のメソッドはpublic指定しない。 ・ＤＢで使うテーブルの項目を列挙して検索条件で必要なＳＱＬ等を検証し、戻り値の値で必要なチェックを行う・・・位に考えていたので、非常に意外です。 ロバストネス分析では、「何」を分析するのですか？
ありがとうございます。 早速調べて勉強させて頂きます。 | ||||||||||||||||||||
|
投稿日時: 2004-09-30 17:56
ユースケースはシステムの機能要件を定義するものです。システムの定義ですから当然解決 領域に属します。
そのとおりです。要するに、ユースケースの機能を実現するためのごくプリミティブなシステム の構成要素をBCEという視点から分析してみて、ユースケースの実現性や妥当性を検証するもの です。
「コンポーネント図」は、そもそも使ったことがないので言及できませんが、ロバストネス図 で登場した各クラスは当然実装段階でもクラスの候補になります。
そういう実装レベルの細かいことはロバストネス図では考慮しません。 メソッドなどは通常日本語で書きます。エンティティの属性も個人的には書かなくてもいいん じゃないかと思います。 | ||||||||||||||||||||
|
投稿日時: 2004-09-30 17:56
返答を書いているうちに話が先に進んでしまいました。(^^;
せっかく書いたのだから、あくまで、私の解釈、考えということで。 1.分析について 分析はすべてシステムの姿を浮き彫りにするためのものだと考えています。 いろいろな視点からシステムを眺めるとどのように見えるかということ。なので、分析には視点、モデルが必要です。 例えば、ユースケース分析は、「システムとはサービスの塊である。」といった調子です。 「イベント-レスポンス分析」では、「システムはイベント-レスポンス対の塊である。」とモデリングしています。 3.ドメイン分析について 誤解があるようなので…(ってここはukさんが指摘してくれていますね) 私の文章で「ドメイン分析のうち」が形容しているのは「ビジネスワークフロー」であって「ユースケース分析」ではありません。 ビジネスワークフローを、システム化範囲で切り取る(システム化範囲を明確化する)のがユースケース分析という意図の文章でした。 分りにくい文章ですみません。 4.ロバストネス分析について ロバストネス分析は、「バウンダリ:インタフェース(画面)」「コントロール:サービス(ユースケース/処理)」「エンティティ:データ(スタック上の一時的なものではなく)」の３つのものの塊としてシステムの構造を眺めようというものだと思っています。 この３つのうち、インタフェース、即ちバウンダリは相手（画面だと人間が相手）のある話でもあり、もっとも変化の激しい部分です。 このバウンダリの激しい変化に、他の部分をさらしたくはありません。なので、バウンダリを特に他の部分とは切り離し、別物として考えます。 次に、変化のもっとも乏しい部分として、データ(=エンティティ)を考えます。この部分は変化がもっとも乏しいのですから、他の影響を受けたくはありません。なので、これも分離し、「他とは違う」と考えます。 最後に、サービス(=コントロール)ですが、バウンダリとエンティティが分離していった残りの部分ということになります。 こうして、システムを変化の激しさで３つの部位に分割して、構造を眺めるというのが、ロバストネス分析だろうと。 変化の激しさによって守るべきところを守る。守るべきところを守れば頑強である。だから、頑強性(=ロバストネス)分析。 かな〜と思っているのですが、何せロバストネス分析については、嫌いなもので勉強が足りていません。(…ukさんのご説明に依れば、違うということなのかな。) 一応弁明しておくと、設計ではなく分析として嫌いです。(^^; その結果が設計のモデルにそのまま反映されるわけでないとしても。 5.イベント-レスポンス分析について この分析というか手法というか、これはあくまで必要に迫られて「自作」した分析ですよ？ (^^; （似たようなものはどこかにあると思いますが） 組み込みシステムは応答時間が厳しいものも多いのです。なので、このような分析を行わないと、困ってしまうのです。 非機能要求分析の一つですね。 何をいつからいつまでの間に行わなければならないのか、どのくらいの時間の猶予があるのか、優先順位などなど、はっきりさせる必要があるのですが、どうやって整理するか悩みました。 で、「システムはイベント-レスポンス対の塊である。」とモデル化し、整理することにしたわけです。 組み込み系以外でも、応答時間が問題になるようなシステムでは使えるでしょうが、あくまで自分が使えりゃいいやという分析手法です。(^^; [ メッセージ編集済み 編集者: Elle 編集日時 2004-09-30 18:00 ] | ||||||||||||||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.