« 構造化設計にこだわるわけ | トップページ | フローチャート使用に、賛成?反対? »

2011年2月11日 (金)

オブジェクト指向と構造化 お勧めは?

「構造化設計にこだわるわけ」という記事で、誤解を招くような事を書いてしまいました。

問題・その1:オブジェクト指向=クラスで設計 という書き方をしてしまった
この記述は誤りです。ゴメンナサイ
クラス設計はオブジェクト指向設計の一部でしかありません。
この詳細は、元記事のトラックバックにもある、後悔^H^H公開日記:別館 : 組込みでのオブジェクト指向的思考で、ご指摘および、フォローの説明まであります。ぜひ、併せて読んでみてください。
(組込み屋さんにとっては、なるほど... という内容だと思います。)

問題・その2:構造化設計にこだわるのは、オブジェクト指向設計の否定派だからではない
私の自身は、オブジェクト指向設計も推奨派です。
プログラムに馴染みが深い人にとっては、最初は構造化による手続き型の考え方の方が馴染みやすいと思っています。しかし、できればオブジェクト指向の方が、人が理解しやすいソフトウェア構造が作りやすく、「強いプログラム」にしやすいと思っています。


それならば何故、構造化設計を取り上げたか...
これを説明するために、オブジェクト指向と構造化についてもう少しお話しましょう。


オブジェクト指向では、振る舞いや、規則など、同じような特徴を持ったモノの集合を捉え、その共通点で抽象化したオブジェクトを考えます。ソフトウェアの設計では、システムの構成要素として、色々な特徴を持ったオブジェクトを抽出します。そして、それらオブジェクトが互いに何らかの関係で繋がることによって、システムが実現できるという考えです。
この考えは、人の日常に照らし合わせるとわりと自然な考え方です。


例えば、小さなお弁当屋さんについて、考えてみました。

Photo_3

■ オブジェクト指向で、お弁当屋さんをモデル化する
調理員”と、”販売員”という、別々の役割を担った人がいます。販売員がお客さんの注文を聞き、注文に応じた”お弁当”を調理員が作る。出来上がったお弁当は販売員が売り、お客さんからお金をもらい、”売上”がたちます。また、売上から”食材”が購入することにより、次のお弁当が作れる。
これを一通りのお弁当屋さんシステムとします。

上記の説明の斜線にしたところが、オブジェクトだと考えます。それらは異なる特徴を持ち、オブジェクトどうしが、互いに何か関係をつくることで、「お弁当屋さん」という一つのシステムが成り立っているのです。


こうして考えると、あまり難しくは感じられないのではないでしょうか?
では、同じお弁当屋さんの例を、手続き型の思考でモデル化してみるとどうなるでしょう。


■ 手続き型で、お弁当屋さんをモデル化する
Obenntouya2

お弁当屋さんの登場人物である、販売員と調理員。それぞれの仕事と、その実行順序を考ると、次のようになります。

・販売員さんの仕事
お客さんの注文を聞いて調理員に依頼 → 出来上がったら、お弁当をお客さんに渡す → 代金をいただく。

・調理員さんの仕事
注文を聞いたら、お弁当を作る → 出来上がったら、販売員に渡す。
(お弁当作りとは異なる時間帯に)翌日の営業用に、売上金から、食材を買い求める。

そして、二人の間をいつ、どのようなモノ(物理的な物、情報)が行き来するかを考えて、全体のシステムが表現できます。


二つのモデルを見比べてみてどうでしょう。
手続き型のモデルには、各担当の詳細な仕事が順序だてて明記されています。この仕事の内容は、オブジェクト指向型モデルには登場しません。
オブジェクト指向のモデルでは、仕事の内容は、オブジェクトの振る舞いとしてオブジェクト内部に定義されます。
モデル図だけを比べると、オブジェクト指向型のモデルの方が、シンプルで解りやすくないでしょうか。

何かシステムの概要を捉えるとき、詳細な処理や手順は隠して、モノどうしの関係性で考えた方が、人には理解しやすいのです。
しかし、ソフトウェアを作ることを考えると、そうはいきません。コンピュータに向け、何を、いつ、どうやって片付けるか... という細かな指示をしないといけません。プログラム作成に慣れた頭では、このコンピュータ向けの思考が設計時に現れてくるのです。
言い換えれば、コンピュータのために、かえって難しい考え方をしているのです。


このように、オブジェクト指向はシステムを設計する上で、本来の人の思考に近い技法です。
けれども、それをソフトウェアの実現手段として考えるには、慣れが必要でしょう。

とは言え...
現場にいるソフトウェア開発者にとって、この考え方に慣れるまでトレーニング時間を割いて、その後に設計をするなんて、悠長なことは言っていられません。常に、製品開発は動いているのです。
そこで、まず設計技法に取り組む第一ステップとして、お勧めするのが構造化設計です。


構造化設計は、処理を階層構造化して、概略的な処理の塊から、詳細な処理へとブレークダウンしていく考え方です。

先ほどのお弁当屋さんの例でいえば、手続き型モデルで考えた、販売員さんの仕事、調理員さんの仕事を、プログラムで実現できる細かな粒度にまで、徐々に噛み砕くような設計を行います。
はじめは、システム全体はいくつかの概略処理で捉える。それを、より具体的な処理への分解していく。分解したものを、動作できるように適切に組み立てて、プログラムとして連結する。 ということを、この技法では考えていきます。
構造化設計で唱える考え方は、多くのプログラマが考えてきた、手続き型思考の整理の仕方といっても、よいかもしれません。


まとめると...
  強いプログラムを作るためには、オブジェクト指向設計はお勧め。
  しかし、オブジェクト指向に取っつき難いと感じた方は、構造化設計からはじめることがお勧め。
と思います。

※ 関連記事: Interface 2011年1月号

« 構造化設計にこだわるわけ | トップページ | フローチャート使用に、賛成?反対? »

ソフトウェア開発」カテゴリの記事

Interface記事」カテゴリの記事

コメント

>何かシステムの概要を捉えるとき、詳細な処理や手順は隠して、
>モノどうしの関係性で考えた方が、人には理解しやすいのです。
>プログラム作成に慣れた頭では、このコンピュータ向けの思考
>が設計時に現れてくるのです。
>言い換えれば、コンピュータのために、かえって難しい考え方
>をしているのです。

慣れてない人に、初めからオブジェクト指向で考えてもらうっていうのだと、
むしろできるんですかねぇ。
(私は、そこが構造化→オブジェクト指向への切り替えるポイントなの
かなぁと思っていました。)
そうだと、いいのだけどと思っているのですが、いきなりモデル書きましょう、
設計しましょうというのも無理な話なんですよね。っで、動かせるプログラム
から入ると結局上記の問題になるわけで・・・。

MDDでなんとかなるかなと思っていたのですが、アクション言語でひっかか
っちゃいました。ただ、まったくうまくいってないわけではなくて、現時点では
結構いけるのかもという感じです。

以前、2007年のMDDイニシアティブで、Cortland Starrett氏(米Mentor Graphics Corp.)は、
 「プログラムを知らない高校生は、なかなか良いモデルを作るよ」
と仰っていましたね。

モデルから動くプログラムに変換する際に、アクション言語が障壁になってるのですね。
そこは、沢山のサンプルプログラムがあって、その中からやりたいことを探して少しずつ習得できるような環境があると、よいのかもしれませんね。
文法を教えられても、やはり喋れるようにはならない。
見よう見まねで、練習を積み重ねないと、喋れないのと似ているかなと思いました。

コメントを書く

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: オブジェクト指向と構造化 お勧めは?:

« 構造化設計にこだわるわけ | トップページ | フローチャート使用に、賛成?反対? »