概要
「メソッド（サブルーチン） → 御仕事」
「オブジェクト → 人」
「クラス → 各担当者の作業手順書」
で考えると解り易い
コード:
１．画面（対応が良い、窓口担当者）
２．内部値チェック（口うるさい、経理担当者）
３．ＳＱＬ文生成（正確且つ効率的に作業する、技術者）
４．ＤＢに処理依頼（迅速且つ荷物を間違い無く届ける、配達担当者）
５．更新の結果取得（迅速且つ荷物を間違い無く届ける、配達担当者）
６．結果の表示（対応が良い、窓口担当者）
これは、現実世界で担当者を決めて仕事をする時に、
「役割を決める」
「仕事依頼時の手順を決める」
「１回の情報提供で沢山の仕事をして欲しい」など
担当者のあり方とオブジェクトのあり方が似ているからです。
既存の設計とオブジェクト指向の設計の基礎部分は一緒で、
既存の設計技法（特にモジュール分割）が確りしておけば、
オブジェクト指向に移行し易いという事です。
１．テンプレート化、部品化している組織では、オブジェクト指向の恩恵を受け難いが、
オブジェクト指向言語に移行し易い。
２．部品化技術のレベルが低い組織では、オブジェクト指向言語で提供されている
各種部品やフレームワークで、その技術レベルの低さを補える。
３．視覚的要素のある箇所、基本的な処理の流れは、オブジェクト化し易い。
オブジェクト単位の考えた方は、
「擬人化」と言われる一般的な手法
要件について
設計は「要望」と「制限」の影響を受け、
この「要望」と「制限」を一般的に「要件」と言います。
要件を考えた場合、下記の要件があります。（言葉は勝手につけている）
１．業務要件
→御客様の要望
例：売上から請求書を作りたい。
製品単位で利益が出ているか知りたい。
２．システム要件
→組織で明示されたベキ論／一般論、運用担当者／保守要員の要望
例：外部ＩＦは全てバックアップを取る。
内部エラーはテキスト若しくは、ＤＢに記録として残す。
３．アプリ／インフラ要件
→言語／ツールが仕様提示している要件、物理的限界など
例：ＶＢ６だからマルチスレッド処理は出来ない。
容量的に３年間の情報は保持出来ない。
４．暗黙要件
→設計者、組織で根拠が明示されていない、ベキ論／一般論
例：オブジェクト指向はｘｘｘｘするべきだ！
この処理はこうするのが普通だ！
５．管理要件
→金、納期、メンバースキルなど
例：２０００万の予算で開発する。
新技術の摘要は今回出来ない。
関連ドキュメント
分からないことは？
最終更新：2009年06月11日 18:55
