オブジェクト設計-その2

 前回はオブジェクト指向の考え方、すなわちその概念を取り上げました。
 今回は情報システムにおけるオブジェクト指向設計の考え方を取り上げようと思いま
 す。
 オブジェクト指向設計の基本は“知識を持っている実体を中心に考えていく”ことで
 した。
 情報システムに置き換えますと、知識(=属性)はデータでしたから、顧客データ
 項目、商品データ項目、在庫データ項目、受注データ項目等が相当することになり
 ます。実体としては顧客マスター、商品マスター、在庫ファイル、受注ファイル等で
 すので、これらのマスターやファイルをオブジェクトと考えれば良いことになり
 ます。

(1)オブジェクトの関係
  さて、“このオブジェクトの働き(=機能)は何でしょうか”
  オブジェクト指向では指令(=操作)がオブジェクトに対して与えられます。それ
  はそのオブジェクトがその機能を果たすことが出来るからでした。
  ということは、他からの指令を機能として取り込めば良いことになります。顧客
  オブジェクトであれば、「顧客与信情報検索」、「顧客住所検索」、「顧客リスト
  一覧」、「顧客情報更新」などがあります。
  受注オブジェクトですと、その機能は「受注情報検索」、「受注登録」、「受注
  更新」などが可能です。
  オブジェクト指向設計ではこれらの機能を属性と合わせ、オブジェクトの設計図と
  してのクラスを構成します。たとえば、顧客クラスや受注クラスがそれに該当し、
  属性と機能で設計されます。このクラスは他からの指令を与えられて働きをし、
  成果を出す実体、オブジェクトとなります。
  従って、このクラス間は他のオブジェクトからの指令(=機能)によるオブジェク
  トとの関係を作ることになります。
  たとえば、受注入力を受注クラスに対して行うと、受注オブジェクトは在庫クラス
  に対して在庫引当の指令を出します。在庫オブジェクトは引当を行い、出荷指示を
  出すという流れになります。
  このような、クラスに対するオブジェクトに対する指令の関係設計がオブジェクト
  指向設計です。
 それでは、“何故、このオブジェクト指向設計が必要とされているのでしょうか?”

(2)なぜオブジェクト指向設計が必要か
  従来のシステム設計をオブジェクト設計と比較しながら見てみましょう。従来の
  システム設計ではデータベースと処理を分離しています。すなわち、受注処理は
  顧客DB、在庫DB、受注DB等を参照し更新します。オブジェクトで言う属性と
  機能をまったく分離して設計していることになります。いわゆるデータベース中心
  のデータオリエンテッド設計です。この設計は機能(=処理)と属性(=データ
  ベース)が複数の相互関係を持つことになります。そうしますと、DBの一部が
  変更になると全ての処理を変更しなければなりませんし、処理の変更が発生し、
  DBの一部変更が生じますと同様に全ての処理変更となります。
  一方、“オブジェクト指向設計したシステムはどうでしょう。”
  属性と機能が一体となっていますから、そのクラスの機能変化です。
  すなわち、システム機能の変更に対し、その対応のクラス変更のみになりますから
  最小の変更で対処できることになります。
  オブジェクト設計が大きく騒がれている意味がご理解できると思います。

 インドや中国の大勢はこの設計が中心となり、オブジェクト指向設計大国である米国
 のソフト産業の2割の労働力がシフトされているようです。
 
第62回はここで終了します。オブジェクト指向設計の重要性を取り上げました。
次回は、このオブジェクト指向設計を効率的に具現化する「UML―その1」を取り上げます。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする