オブジェクト指向の歴史


目次

  1. オブジェクト指向の歴史
  2. 2．UMLの概要


1.オブジェクト指向の歴史

　オブジェクト指向の歴史は、１９７０年にゼロックスパロアルト研究所が開発した Smalltalkという言語が始まりだとされている。 オブジェクト指向言語が出現した後、オブジェクト指向プログラミングをするため にオブジェクト指向設計が必要となり、そして、オブジェクト指向設計をするために オブジェクト指向分析が必要となった。このように３０年の年月を経てオブジェクト 指向開発方法論が確立してきた。 それ以前の構造化手法では設計者に依存するところが大きく、提唱された品質や生産 性を得ることがなかった。この点をオブジェクト指向はカバーしたため、オブジェクト 指向方法論が脚光を浴びる。

　多くの方法論が提唱されるが、モデルの書き方やモデルの種類、作業プロセスなどに 違いがあるため、有益な部分を組み合わせて統一方法論を作り、世界標準を目指した。 しかし統一方法論の世界標準化は、多種分野に適用しなければならないので、困難であった。 そこで、標準化した方法論を作るのではなく、各ベンダーごと、各分野ごとに適した方 法論を提案することとなった。統一方法論の中で、モデルの表記方法の部分だけをUML (Unified Modeling Language)として、オブジェクト指向表記方法において世界標準とした。

2．UMLの概要

UMLには
5種類のビューと
9種類のダイアグラムが用意されている。

ビュー（システムをモデル化する際の色々な側面のこと）

  1. ユースケース・ビュー
    　ユースケース・ビューは、アクターがシステムにしてほしいこと、または、 システムがアクターに提供しなくてはならない機能を記述する。アクターとは、 実際にシステムと会話する相手のことであり、システムを利用するユーザや開 発システムと連帯する他のシステムのことである。 システム開発においてユースケース・ビューは中心的なビューである。他の ビューはユースケース・ビューで記述した内容を反映し、別の側面から記述す る。ユースケース・ビューの変更は他のビューに影響を与える。

  2. 論理ビュー
    　論理ビューは、ユースケース・ビューで抽出した機能をいかに実現するか を、つまりシステムの内部を記述する。主に設計者と開発者のためのビューであり、システムの内部は静的な構造と動的な協調関係によって記述する。

  3. コンポーネント・ビュー
    　コンポーネント・ビューとは、ソフトウェア・コンポーネント間の依存関 係を記述する。ソフトウェア・コンポーネントとは、プログラムを記述したソースコード、ソースコードをコンパイルしたバイナリコード、実行に必要なすべてのバイ ナリコードをリンクした実行可能なプログラムなどのことである。 コンポーネント・ビューは、主に開発者のためのビューである。

  4. 並行性ビュー
    　並行性ビューとは、プロセスやスレッドの並列処理における同期処理、非 同期処理を記述する。これは非機能的な側面であり、CPUなどの資源を有効 に使用することや平行して実行しているプロセスやスレッド間通信の同期を 取り扱うことを目的としている。 並行性ビューは、主に設計者とシステムインテグレーターのためのビュー である。

  5. 配置ビュー
    　配置ビューは、物理的な装置やコンピュータの配置とそれらの関係を記述 する。主に設計者、システムインテグレーターのためのビューである。
ダイアグラム（ビューの内容を表現する図のこと）
  1. ユースケース図

    　ユースケース図の構成要素には
    アクター・ユースケース・システムがある。

    a.アクター
    　ユースケースを起動する人や物、つまり実際にシステムを使うエ ンドユーザや、システムと接続する他のシステムや装置である。 アクターが人の場合には、一人一人のユーザではなく、抽象化さ れた人の役割（ロール）を表す。これにより、同一人物が複数のア クターを演じることができる。その人がどれだけのアクターを演じ ることを許されているかで、その人のシステムに対する権限を制限 できる。
    　アクターは他のアクターと関係を持つことができ、典型的な関係 は継承である。

    b.ユースケース
    　ユースケースは、アクターとシステムの対話をモデル化し、シス テムユーザがシステムを利用して遂行する単位業務の一つを抽象化 したもの。アクターが起動するシステム内の機能であり、通常簡潔 な文章で記述する。（例）「図書の貸し出しをする」
    　特徴はアクターが起動することと、完結した機能であることである。 完結した機能の中に一連の作業（アクティビティ）シーケンスを持つ。 　ユースケース間の関係には拡張関係・使用関係・グループ化がある。

    　拡張関係（extends）
    　拡張関係とは、ユースケースどうしの継承関係であり、あ るユースケースが他のユースケースを拡張する。拡張された ユースケースでは、拡張元ユースケースの全ての機能を含む 必要はなく、一連の作業（アクティビティ）内の一部を含む だけでもよい。
    　しかし通常ユースケースは文章で記述されるため、拡張された ユースケース側にとって、追加、流用、再定義した部分 がわかりづらいし、明確にしにくい。メモ書きをUMLに追加 し、説明を付け加える必要がある。

    　使用関係（uses）
    　使用関係も拡張関係と同様、ユースケースどうしの継承関 係であるが、拡張関係と違う点は、使用するユースケースの 全ての機能を使用しなくてはならないことである。ただし、 使用するユースケース内の一連の作業（アクティビティ）シ ーケンスをその順序のまま使用しなくてもよい。使用するユ ースケースと使用されるユースケースの作業シーケンスが混 在していてもよい。

    　グループ化（grouping）
    　ユースケース図には多くのユースケースを記述する。そこ で似たような機能や関係の深い機能を集めグループ化する。
  2. シーケンス図

    　シーケンス図は、複数のオブジェクトどうしの協調関係を時系列に表す図 であり、システムの動的な側面を記述する。
    　時間は、シーケンス図の上から下へと進んでいき、その間にどのオブジェ クトがどのオブジェクトに対して、メッセージを送るのかを記述する。これ により、メッセージの実行順序、オブジェクト間の協調関係を見つけること ができる。

  3. クラス図


    　クラス図では、システム内に存在するクラスどうしの静的な構造（クラスど うしの関係やクラスが持つ属性、操作）を記述し、 システムの機能に着目して、問題領域を論理的、静的に見るための図である。 クラスとは、システム内に存在する「もの（オブジェクト）」を抽象化したも のである。
    　クラス間の関係には関連（一時的な関係）・汎化（継承、親クラス性質を子クラスが受け継ぐ）・集約（全体と部分の関係）がある。
    　クラスは同じ性質を持つオブジェクトをグループ化したものであり、クラ スに属する全てのオブジェクトの集合である。従ってクラス図は、システム のライフサイクルのどの時点においても同じ構造を維持する。このため、ク ラス図はシステムの静的な構造を記述する。

  4. 状態図

    　オブジェクトはその内部に状態を持ち、状態は時間や外部的なイベントと ともに変化する。状態図はひとつのオブジェクトの状態変化に着目し、その オブジェクトが持つ動的な側面を表す。
    　状態変化には、イベントが関与し、アクションがある。 イベントとは、オブジェクトに送られるメッセージであり、状態を変化さ せる刺激である。時間の経過やある条件の成立、他のオブジェクトからのメ ッセージがイベントとなる。
    　アクションとはある状態において、そのオブジェクトが提供できるサービ スである。ある時点でそのオブジェクトは何をしてくれるのか、また逆にあ る状態にならないとそのオブジェクトはある仕事をしてくれないなどである。

  5. アクティビティ図

    　アクティビティ図は、オブジェクトの"アクティビティ（作業）"の流れを 表す図であり、システムの動的な側面を記述する。状態図の特殊な形で、ひ とまとまりの業務や処理を表すために、複数の作業を順序だてて記述する。


  6. オブジェクト図

    　オブジェクト図は、クラスから生成される個々の具体的なオブジェクトど うしの構造を記述する。 クラスはオブジェクトの抽象であるため、具体的な値を保持しないが、オ ブジェクトは具体的な値を保持した形で記述する。オブジェクト図は、ある オブジェクトがその値を保持しているある時点での状態を記述し、 クラス図の具体的な例として作成する。


  7. コラボレーション図

    　オブジェクト間の接続関係に着目して、メッセージやデータの流れを表す。 コラボレーション図も、シーケンス図と同じように複数のオブジェクトど うしの協調関係を表す図であり、システムの動的な側面を記述する。 シーケンス図と異なる点は、時系列に表現しないことである。時間の経過 における協調関係を強調したい場合はシーケンス図を使い、オブジェクトど うしの関係を強調したい場合はコラボレーション図を使うのが一般的である。


  8. コンポーネント図

    　コンポーネント図は、ソフトウェア・コンポーネントの物理的な構造や、 コンポーネントどうしの依存関係を表す。 クラスやオブジェクトの実装コンポーネントへの割り当てを表したり、 ソースコードや実行モジュール間の依存関係（コンパイルやリンクの順序な ど）を表す。

    　コンポーネント
    　コンパイルやリンクや実行の単位で、システムの物理的構造 を組み立てるブロックの役目を果たす。 コンポーネント図を作成することで、あるコンポーネントに変更が生じた 場合、他のどのコンポーネントに影響を与えるかを分析できる。


  9. 配置図

    　ハードウェアにソフトウェアをどのように配置するかという観点から 考えて、表したもの。システムの物理的なアーキテクチャ、つまりコン ピュータや装置（ノード）の配置とそれらの関係（接続）を記述する。 ノード間に引く実線によりコミュニケーションが行えることを表す。 ノードに具体的なコンポーネントやオブジェクトを割り当て、運用環境を イメージ化する。3階層システムや分散システムにおけるコンポーネント、オ ブジェクトの配置を設計し、インターフェースや性能の設計に役立つ。 ノード内には、実行時の計算リソースであるオブジェクトやコンポーネン トの構成を表示することができる。そして､コンポーネント間に依存関係を引 くことによって､クライアントとサーバの関係を明示することができる。また コンポーネントがどのノードに割り当てられるかを示す役割もある。



参考


　上述した動的な側面を表現する図の中で、矢印はメッセージの流れとタイ ミングを示している． シンプルは同期/非同期を特に問題としていないときに使う一般形である．