酒匂と申します。

At 21:31 03/10/09 +0900, Satoshi Osabe wrote:
>今まで、プログラミングでコーディング&デバッグ方式でやってきたのですが、
>「職業プログラマー入門」(エーアイ出版)という本を読んで、その方式だと素人的で、
>プログラミングの効率が悪いと思うようになりました。ウオータフォール・モデルの方が
>望ましいのかと思い、PAD図とモジュール構造図を用いる方法を勉強しました。
>しかし、Rubyだと、begin、rescueを使った例外処理が、PAD図の選択箱では表現しにくい
>ようです。Rubyプログラミングで、設計からきちんとやるにはどういう方法を
>とるのでしょうか。

そもそも PAD 図のようなものが必要になるのは、長い命令列を見やすくする
ためなのですが、一般的に良い「オブジェクト指向プログラム」は
一目で理解できる程度の長さのメソッドが理想とされています。
よって手続きを構造化して見やすくするための PAD やフローチャートのようなものは
基本的に不要というわけです。

私は
クラスの責務と、協調関係を、求められる仕様に従って少しずつ構築していくのが
オブジェクト指向設計/プログラミングだと思っています。
(大きく見ればまつもとさんがおっしゃっている XP と CRC と変わらない
   見方かもしれません)

クラスの責務を設計するには、個別の属性、メソッドを吟味しながら、破綻のないサービスを
提供すれば良いことになりますが、こうした際に役に立つのは
不変条件、事前条件、事後条件といった制約条件の認識です。

こうした各種条件は Rose などのモデリングツールを使っていると
記入場所があることに気が付くでしょう(必ずしも活用されている
とは言いがたいのですが)。

またクラス間の協調関係設計とは、きちんと定義された責務をもつオブジェクト
同士を協調させる方法を考えることです。あるサービスを提供するクラスを想定した際に
そのクラスが全部自分で解決するのではなく、責務を分離した他の
クラスに協力を依頼しながら、より上位のサービスを提供します。

例えば(例題として適切かどうかわかりませんが)、「旅行代理店」というクラスが
存在したとします。このクラスの責務は「依頼を受けて旅程の予約を行うこと」です。
たぶんメソッドとして「予約を受付ける(旅程)」というものが存在することでしょう。
もちろん通常旅行代理店が自分で飛行機を飛ばしたり、ホテルを経営しているわけでは
ありませんので、旅程に対する各手配は適切な運用会社(エアライン、ホテル、レンタカー会社
、鉄道会社)に委任しなければなりません。

「旅行代理店」と「運用会社」が協調して、「顧客」のための「予約」を作り出します。

こうした文脈では、「顧客」と「予約」が問題領域の情報構造を扱っており、
「旅行代理店」と「運用会社」はそれぞれサービスの切り口を
提供することになります。

しばしば前者(問題領域の情報構造)はドメインモデルと呼ばれたりします。
説明のためには UML のクラス図で書くことがポピュラーです。

後者が互いに協調することにより、ドメインモデルを維持管理します。
こうした部分は単なるクラス図よりも、UML のイベントシーケンス図、
コラボレーション図などを用いた方が分りやすいでしょう。

と、まあ五月雨式に書きましたが、一つだけ強調しておくならば
UML の記法だけを覚えても何の役にも立ちません。
それぞれのモデルの持つ役割をはっきり
認識して厳密なモデル構築を心掛けるべきですね。

以上取り急ぎ。
では失礼します。

-----------------------------------------------------------------------
<Sako Hiroshi>  -- to design is human, design is our business 
   http://www02.so-net.ne.jp/~sakoh/  mailto:sakoh / ba2.so-net.ne.jp
   Designers' Den Corporation : and for now, No Peace, No Future.      
-----------------------------------------------------------------------