オブジェクト指向の起源
ソフトウェア開発は大きく要件定義､ 分析､ 設計､ 実装､ テスト､ 保守の各段階に分類する事ができる｡ オブジェクト指向技術は要件定義を除く全ての段階において利用可能である｡ またソフトウェアの開発には分析設計ツール (CASE ツール)､ プログラミング言語､ データベースシステム等が必要であるが､これら全てのものが現在オブジェクト指向の環境で利用可能である｡ これらの技術及びツールのリファレンスとなっているのが純粋なオブジェクト指向プログラミング言語であるSmalltalkである。
SmalltalkはXerox Palo Alto Research Center (PARC)で Alan Kay達のAI研究グループがDynabookのために1960年代末から70年代初頭にかけて開発した言語である｡ 実はオブジェクト指向の概念はこのSmalltalkの要素技術の1つにしかすぎず､ Smalltalkはマウス､ビットマップディスプレイ､マルチウィンドウ等を実現するためのプログラミング言語として開発された｡ オブジェクト指向のアイデアをはじめに取り入れたプログラミング言語は1960年代後半のSimulaであり､ Smalltalkはそれを実用のものへと完成していった｡
従ってオブジェクト指向の基本概念は現在いろいろな書物で定義されているように情報隠蔽や継承等と言う難しい言葉で説明されるものではなくもっと単純なものであった｡ つまりオブジェクトとは､ 利用者からアクセス可能な要素でり､ ユーザーが観察したり､ 操作したりする際に､ いつも意味のあるやり方で､ 自分(オブジェクト)自身を提示できる能力を持つものなのである｡
オブジェクト指向の本質
C++の影響が強いためかオブジェクト指向の特徴をクラスと理解する向きが多いが､クラスはオブジェクトの抽象機構であり決してその本質ではない｡ クラスは抽象データ型の考えをオブジェクト指向に導入したものである｡ 実際､ Acotrや Self等クラスを持たないオブジェクト指向プログラミング言語も多数存在する｡
オブジェクト指向の本質を一言で表現すれば､ 自己 (self) と非自己 (not self) の区別である｡ 決して これ (this) と あれ (that) の違いではない｡ 自己 (self) には何らかの能動性が感じられるが､これ (this) は感じられず受動的である｡ またそれ以上に自己 (self) とは他とは全く独立に認識されるが､ これ (this) は他との関係においてのみ定義可能である｡ このオブジェクトの本質がオブジェクト指向の様々な良い特徴を構成している｡
オブジェクト指向計算モデル
オブジェクト､ すなわちものを形式的に定義すれば
物理的あるいは論理的な実体に対応した自己完備な計算の実体で､通信のための統一的な手段を備えたもの と言うことができる｡ 従ってこれはプログラムの一部分やデータの一部分ではなく1つの実体である｡ 抽象データ型がデータの抽象化を行うのに対してオブジェクト指向ではものの抽象化を行う｡ さらにオブジェクト指向計算モデルでは問題をオブジェクトの集まりとしてモデル化し､ それらが相互に通信し､ 計算を依頼し､返答を受け取ることによってシステムが動いていく｡ そのため分散環境､ 並列環境に容易に対応できる。オブジェクト指向計算モデルは以下の2つに大別される｡
純オブジェクトモデル (Pure Object Model): 世の中は全てオブジェクトとメッセージだけでできているとするモデル｡ Smalltalk, Actorなど｡
不純オブジェクトモデル(Impure Object Model): オブジェクト以外の構成要素を含む｡ C++, CLOS, JAVAなど｡
どちらのモデルであっても､ユーザードメインのモデル化に際してはほとんど純粋なオブジェクトを使用する｡
オブジェクト指向の特徴
オブジェクト指向の最大の特徴は情報隠蔽 (Information Hiding)､ 多相性 (Polymorphism)､ 継承 (Inheritance)である｡
情報隠蔽とはオブジェクトの内部構造や内部状態を外部から隠蔽することであり､外部のオブジェクトはそのオブジェクトと通信する事によってのみそのオブジェクトを利用できる｡そのためオブジェクトは他のオブジェクトの詳細を知ることが出来ず､あるいは知る必要がなく自己の内部と外界との通信のみに専念させる｡ 換言すれば､ 複雑な事象を小さな構成要素のレベルまでブレークダウンすることを強制する｡
多相性は同じ内容の通信文が受取手 (receiver) のオブジェクトによって独自に解釈､実行されることであり､複雑な事象をより少ない語彙で記述できる｡ 例えばSmalltalkでは全てのオブジェクトはprintStringという同じメッセージで自分自身を表現した文字列を返す｡
継承はオブジェクトが様々な振る舞いを自分の祖先クラスから受け継ぐ機能である｡ 従ってあるクラスの子クラス (subclass) であると宣言すれば自動的にその親クラス (superclass) に備わっている機能､性質を引き継ぐ｡ これにより物事をおおざっぱな理解からより詳細な理解へと段階的に記述していくことができる｡ 例えば人というクラスがあり､男と言うクラスがその子クラスであるとすれば､そのクラスでは男に特異的な性質だけを記述すればよい｡
以上のオブジェクト指向の特徴は､世界の記述において､ 複雑な現実世界を単純化して理解し記述するのに大きく貢献する｡ 同様にシステム開発においては情報隠蔽は大規模な多人数による開発をサポートし､多層性はプログラムの単純化､可読性を増し､ 継承は拡張性を促進する｡ しかしそれはオブジェクト指向が正しく適用された場合であり､ 誤って適用すると全く逆に理解不能なモデルを構成する｡
医療情報のオブジェクト指向モデリング
これまで医療情報では標準化が盛んに行われてきた｡ これは一種のモデル化であるが､情報の静的な構造に焦点が当てられ過ぎてきた嫌いがある｡ そのため固定化したものとして受け止められ決定まで時間がかかってきたようである｡ オブジェクト指向モデリングではオブジェクトの責任 (responsibility) に重点を置いてオブジェクトを記述する｡
医療情報システムは理論的､観念的なシステムではないためそこに登場するオブジェクトの同定 (発見) は比較的簡単である｡ またそれぞれの責任も経験的に理解しやすい｡ 例えば医療ドメインにおいては少なくとも医師と患者が存在し､その間には診療行為が存在する｡ 医師はその担当する患者を知らなければならないし､患者は自分の担当医を知っている｡ 医師に担当患者のリストを持たせるか､患者に主治医の一覧を持たせるかは実装上の問題でありモデルとは無関係である｡ 医療情報モデルとしては医師と患者が日常の診療現場と同様にコミュニケーションできることが重要であり､ その内容を医師がどこに何語で書き留めたかが重要なのではない｡ オブジェクト指向モデリングはこうした抽象的なモデル化を支援し､詳細は各医療機関の実装に任せることができる｡ そして実装が異なっても互いに通信できることを保証する｡
今後のオブジェクト指向システム
オブジェクトはシステム構成要素の最小単位である｡ そのためよく設計されたオブジェクトは1つのシステムに繰り返し出現し､また他のシステムでも利用 (再利用) される｡ しかし毎回もっとも原始的なオブジェクトからシステムを設計､構築するのは冗長である｡ そこで最近ではデザインパターンと言う考えが好まれるようになっている｡ これは設計､実装上よく現れる要求をパターンとして登録し､その一般的な解法をできるだけ利用しようとするものである｡ そのためオブジェクトを同定したようにシステムの中からパターンを発見する必要がある｡ 例えば医療情報では問診のパターンや救急治療のパターンなどがある｡ さらには各専門科のパターンがある｡ これは医療から見ればプロトコル診療につながるものと考えられる｡ こうしたパターンを組み合わせて行くことによりシステムを構築していく｡
さらにすすんでフレームワークの概念がある｡ フレームワークは未完成のシステムの様なもので各ユーザーがそれぞれ必要な部品をプラグインして完成させる｡ この方法の鍵はホットスポットと呼ばれる変更の可能性の高い部分をいかに同定するかである｡
結局､ オブジェクト指向システム設計､構築でもっとも重要なことは､ いかに正しくシステム化するべき世界とシステムを理解しているかと言うことに尽きる｡