オブジェクト指向開発〜導入

オブジェクト指向開発の導入部分として、分析/設計やクラス/メンバ関数、メリットなどをメモ。

オブジェクト指向分析/設計

オブジェクト指向ソフトウェア開発では、まずオブジェクト指向的にシステムの仕様を捉え、それをどのようにコードに落としていくかという方針を決定する。分析/設計工程の成否がシステム開発全体の成否に大きく影響する。

クラス

クラスは「自分で定義できる型」と言えるが、「型はクラスの一部」と言う事も出来る。データとそのデータを操作するための関数が共存してひとまとまりになった物がクラス。
クラスの実体をインスタンスという。

メンバ関数

関数が使用されるシチュエーションの多くは、きわめて限られている。シチュエーションは、関数が処理するデータの種類によって特定される。
従来のモジュール分割は関数を基準としていたが、クラスによるモジュール分割は名詞的な単位が基準になる。
一般的に、データメンバは外部から隠蔽される(処理不可能)。データメンバを処理する場合、メンバ関数を使って行われる。隠蔽されたデータにアクセスし、色々な処理を行う事がメンバ関数の大きな役割。

外部から隠蔽するという事は、外部から保護すると言い換える事が出来る。Cなどの文字列はオーバーフローの問題がついて回るが、長さを隠蔽しそれを元に安全な処理を行うクラスを作れば、それを利用する限り安全な実装が可能。

開発者にとってのメリット

システムは通常、「成長」する。従来の手法では、バージョンアップの度にゼロから作り直す事は頻繁に行われている。ゼロから作り直すという事は、全てにバグが含まれる可能性があるということ。「バグを出さない一番良い方法は、プログラムを作らないこと」
システムに十分な拡張性があれば、前バージョンとの差分だけを作成すれば良い。ミスが混在する可能性は作成した差分だけに限られる。部品を追加して成長させる方法であれば、拡張性を高めるだけでなく生産性・信頼性も高める事が出来る。
開発者と利用者とで「モジュール」の見方は違う。住宅のモジュールを考えると、開発者は柱や梁・壁・釘・ねじという単位をモジュールとして見ている。一方、利用者は「部屋」をモジュールとして見ている。部屋と部屋を繋げたい場合、既存モジュールの破壊と工数が必要になる。保守性を向上する方法は、開発する際にも利用者の視点でモジュール分けを行うこと。利用者の視点でシステムを客観的に見たときに、そこに存在する対象(モノ)をモジュール化した物がクラス。
システムを必要とする利用者は、必要とする段階では何が必要なのかを理解していない。優れた製品を誕生させるためには、フィードバックを受け、改良を重ねる事が不可欠。

開発の手順

1 システム分析
要件の分析。しなければいけない事、やらない事を定義する。問題領域のモデル化、大まかな構成の決定。
2 システム設計
分析結果を実際のシステム上で稼働させるためにどうすればいいかを考える。
3 実装
コーディング/テスト/デバッグ。

流れは従来の方法通り。異なる点は、この流れを繰り返し行う点。スパイラルアプローチやランドトリップエンジニアリングと呼ばれる。

時間的な流れ(開発フロー)を横軸と考えると、分析/設計の部分では縦軸に静的モデリングと動的モデリングに分かれる。

1 静的モデリング
システム対象領域が「どのようなオブジェクトで構成されているか」ということを分析/設計する。
2 動的モデリング
システム内で「どのようにオブジェクトが動作するのか」ということを分析/設計する。

静的/動的モデリングは別々に行われるのではなく、並行して行われる。静的モデリングはクラスのメンバ定義、動的モデリングはメンバの実装。

分析と設計

分析
プログラムがしなければいけない事、求められている事を整理する事が分析。分析段階での成果物は、環境に対して依存性が無い。
設計
ソフトウェアとして実行するために必要な実装方法を考える事が設計。オブジェクト指向では分析から実装まで、クラスという単位が一貫して存在する。

オブジェクト指向ソフトウェア開発の場合、分析と設計はシームレスに連続している。分析/設計の手法(概念)はオブジェクト指向言語(OOPL)に依存する事が無く、すべてのOOPLで通用する。

プロフィール

このブログ記事について

このページは、koshigoeが2005年12月 9日 22:38に書いたブログ記事です。

ひとつ前のブログ記事は「タグを使ってカレンダーと同期」です。

次のブログ記事は「DBのO/RマッピングはSQL全部カバーするもの?」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。