◆概念的オブジェクト指向分析 - Conceptual Object Oriented Analysis

本文章ではあらゆるシステムの構造を 柔軟かつ強固に表現するためのメタモデルを インデックス形式で示します。
  • 操作 - Operation


    概念と実体 - Concept, Information

    人が実体に対して認識している概念は様々である。

    概念 - Concept

    概念は人がモノとして認識できるもの、物事を抽象的に捉えたもので、 人間の認識の単位である。
    概念の例 : 人、男、ウィンドウ、矩形、コンテナ、エラー、 テキスト、文字、数値、絵、ペン、色、青、制御、プログラムなど
    参考 : 文献 1.「オブジェクトタイプ」

    実体 - Information

    ここでいう実体は現実にあるモノだけでなく情報としてのみ表現される モノ、いわゆるソフトウェアも含む。
    人は実体を、多くの一般的に知られる概念(属性)を 集約 した1つの概念として認識している。

    実体の多様性

    実体は媒体やドメインや用途によって 異なる種類の概念の集約として認識される。 例えば線分は、プログラム上では2点の座標で表現されるが、 ビットマップではピクセルの集まりとして表現される。
    同じ実体でも概念の構造(集約)が異なれば プログラム上ではそれぞれ別のインスタンスになる。
    それぞれのインスタンスの間では同じ実体を示し続けるように 整合性が保たれている必要がある。 それぞれのインスタンスが間で同じ属性(のコピー)を持つことがよくある。 整合性を取ることをフラッシュするという。 属性のコピーは関連する(Link)時に型変換してバッファに持つとよい。


    概念と関連と操作 - Concept, Relation, Operation

    概念的オブジェクト指向分析の核となるモデル構造で、 概念と操作はグラフ理論におけるノード、関連はリンクの性質を持つ。

    1.概念は概念と関連する ●−●

    概念はそれを定義するための部分的な概念である属性と所有関連する。 概念は空間や媒体など所属する概念と非所有関連する。 概念は共同で行う操作がある他の概念と関連する。

    2.概念は操作と関連する ●−◆

    概念は、その概念またはその属性だけを扱う 操作 と関連する。 この操作の関連する概念は1つである。

    3.関連は概念と関連する |−●

    関連の属性は、概念と概念の間の関連と関連する。 たとえば、2つの物体の相対位置など。
    プログラム言語では普通どちらかの概念に所有関連する。 一方の概念が対多関連しているときは、もう一方の概念に所有関連するとよい。

    4.関連は操作と関連する |−◆

    関連する複数の概念の間で行われる 操作 とその関連は関連する。 この操作の関連する概念は複数であると、4. と 1. から導かれる。

    5.操作は概念と関連する ◆−●

    (これは 2. と 4. の逆である。)
    操作は、共同する概念(入力変数)と関連する。 関連する概念は1つまたは複数である。 複数の概念と関連する操作はそれらの概念の間の関連と関連している。(4.の逆)
    操作によって概念が発見される。それゆえ、一般的に広く知られる概念は、 あらゆる操作に耐えてきた丈夫な概念である。

    6.操作は操作と関連する ◆−◆

    操作は処理を構成する多くの操作と所有関連する( メソッド )。 操作はその操作から発生したイベントをトリガする操作と非所有関連する( ルール )。


    概念の集約、属性 - Aggregation, Property

    概念または実体を集約して別の概念または実体を定義することを集約という。 逆に、属性を抽出することも多い。

    概念を集約した概念(定義) - definition

    概念は多くの属性(部分概念)を集約して定義される。
    属性は構成する概念(所有関連)の他に、 関連する概念(非所有関連)への ポインタ も含む。
    オブジェクトの概念は何も変化しないが振る舞いが異なるとき、 状態という属性を用いる。 一連の手続きから属性を抽出すると概念を捉えやすくなる。

    概念を集約した実体(表現) - description

    実体 は、多くの一般的に知られる概念(属性)を集約した 1つの概念として認識しているため、概念を定義するのと同じように 属性を集約して実体を表現することができる。
    空間や媒体との所属や、関数呼び出しと関数実装のようなDoc/Viewなどは 非所有関連であり、それぞれ別の実体である。 非所有関連する概念により状態が変化することがある。
    参考 : 関連修飾

    実体を集約した実体(構築) - structuring

    実体を集約して1つの実体を構成することでモデルを階層的に扱うことができる。 ただし、すべての構成要素を集めたときに適用できる 概念 があるときに限り集約できる。

    所有木とショートカット - structure tree, short cut

    所有関連は根元が1つの単純な木を構成する。
    集約木の深い方にショートカット(関連)を使って階層を飛び越えることもある。 たとえば、y = f(x) と f(x) = axx + bx + c は、 y = axx + bx + c である。
    所有木がうまく作れないときは、 空間や媒体との所属や、関数呼び出しと関数実装のようなDoc/Viewなどの 非所有関連を使って実体を分割するとうまくいく。

    関連するものもカプセル化したクラス - encapsulating class

    概念を集約しただけでなく関連する操作も集約することで、 データと機能をカプセル化したものをクラスという。
    関連する操作のインターフェイスだけを集約したものも(抽象)クラスである。 オブジェクト指向言語のほとんどは、関連の操作や関連の属性を 片方のオブジェクトがカプセル化してしまう。

    集約の実装

    1対1の関連は継承で実装されることがある。 そのため、集約の実装に多重継承を用いることがある。 多重継承は単一継承を複数並べることで実装可能。
    1対多の関連は継承では実装できない。
    親が無い非所有関連だけで構成されることもある。

    関連修飾

    関連する概念によって関連の操作や関連の属性が変化するので、 概念自体は変化しないがクラスが変化する。 それを局所化する言語の機能を関連修飾という。
    関連修飾は単純な継承で実装できる。 関連修飾はいちばん具象な概念から行う。(インスタンスレベル)
    参考 : 文献 4.


    概念の汎化 - Generalizaion

    一般的な概念を抽出することを汎化という。

    一般的な概念という汎化概念 - General Concept

    より多くの実体にあてはまる一般的な概念を汎化概念という。
    一般的な概念はより多くの識別が必要になる。
    この汎化関係は根元が1つの単純な汎化木になる。
    一般的な概念は 関連の制限 をゆるめたものか属性を無効にしたものと考えることもできる。 そのため、汎化概念から継承したときに使わない属性が出てくる可能性がある。

    属性という汎化概念 - Generalized Property

    複数の概念に共通するある1つの属性も汎化概念であると考えられる。
    この汎化関係は根元が複数(ラティス構造)の汎化木になる。 属性という汎化概念は汎化木の親になることもあれば 子(属性)になることもある。
    参考 : 文献 1.「パワータイプ」

    汎化の実装

    汎化関係の実装は継承が適するが、 関連(used-a)を用いて委譲してもよい。

    汎化分類集合

    共通する汎化概念と関係する実体を集めたもの。 インフォメーションマップの一種。 ポインタの集合で実装する。
    参考 : 文献 3.「インフォメーションマップ」「分類ハイパートレイル」


    概念の識別 - Identification

    概念は他の概念と識別できる。

    終端の概念 - Terminal Concept

    プログラム中で属性を持たない概念を終端の概念という。
    終端の概念は識別さえできればいいので識別データだけで構成される。
    C言語なら enum などで実装される。

    終端ではない概念 - Non Terminal Concept

    終端ではない概念は識別データと属性から構成される。
    C言語なら struct などで実装される。

    識別データ、型 - Identifier, type

    概念を識別するために数値(ID,アドレス)やシンボル定数や 文字列(名前)やそれらの複合したものを用い、これらを識別データという。
    識別する必要のある概念を集めて汎化したものを型という。 型と識別データを組み合わせて概念を一意に決定できる。 同じ概念でも型によって異なる識別データになることがある。

    概念(識別データ)は大小比較できるものとできないものがある。
    識別データは型の中で他の概念と重ならないものと重なることのあるものがある。
    識別データは配列の添え字やアドレスなど トライアルゴリズムによって素早く特定できるハンドルと、 名前など線形サーチやバイナリサーチによって特定できるボリュームの 2種類ある。

    識別データの具体的な値は概念が生成される前に決定する。 存在する概念(実体ではない)の識別データはグローバルに参照できるとよい。

    ポインタ、走査子 - Pointer, Iterator

    ポインタは関連する有限個の概念を識別するための変数で、 関連を実装するために用いる。
    参考 : 対応付け
    ポインタは識別データだけから構成される。(終端の概念と同じ構造)
    何も関連していないという意味の null 値があると便利。 ただし、null 値の場合に振る舞いが異なることが多い。(多態性)

    配列の隣の要素をポイントすることができるように、 ポインタが自ら別の関連を導出(計算)できるものを走査子という。


    関連 - Relation

    関連に含まれる意味、制限

    所有関連や非所有関連や所属関連など、関連には意味がある。 これらよく用いられる意味の他にも、 「一番最初に登録された顧客:Aさん」のような特別な条件や、 「重さ(kg):48」のような単位などがある。
    関連に含まれ得る意味から関連できる概念の制限ができる。 制限は汎化概念(より具体的な概念であること)で指定されることが多い。 制限の無い関連もある。

    対応付けの数

    それぞれの関連に含まれる意味が同じためそれらを区別できず、 プログラムでは汎化した関連を扱っていることがあるが、 その関連は同時に対応する概念が複数存在し、 その数を対応付けの数という。
    対応付けの数が複数のものを対多関連という。
    参考 : 文献 1.「カーディナリィ制約」


    対応付け - Correspondence

    対応付けは一方通行のリンクのことである。

    対応付けの無い関連

    操作するためだけの関連は 関連の操作を用いればよいので対応付けする必要が無い。
    ただし、排他制御などのプロセスの関係上、 処理中の対応付けをしておくこともある。

    ポインタによる対応付け

    普通、対応付けは ポインタ で実装する。
    関連を生成したり削除したりするときは、 関連する両方のポインタの整合性をとる必要がある。
    対多関連はポインタの集合(コンテナ・配列)で実装する。

    ただし、ポインタでも識別データがハンドルではなく ボリューム の場合は、 特定するのに線形サーチやバイナリサーチをする必要があるが、 関連する両方のポインタの整合性をとる必要がない可能性があることと、 対多関連に集合を用いる必要が無い。

    ベクトルによる対応付け

    構造体はベクトル(配置)による対応付けである。
    この対応付けは静的なのでプログラム実行中に変更できない。
    たとえば、構造体 s のメンバが int a,b; のとき、s から b の 対応付けは 2byte ( 32bit では 4byte ) のオフセットで実装される。
    対多関連を配列で実装する場合もこれに含まれる。

    導出対応付け

    計算または検索によって対応付けを実装する。
    関連する概念を求めるたびに計算または検索することになるが、 複数の関連する概念の間に存在する整合性を保つことが容易になる。

    参考 : 文献 1.「対応付け」


    メッセージ転送 - Message Sending

    push式メッセージ、pull式メッセージ

    関数でメッセージを実装する場合、 データ転送を入力、返事を出力とするものを push 式メッセージ、 データ要求を入力、データ転送を出力とするものを pull 式メッセージという。

    pull 式で受け取る相手に対してメッセージを送る側は メッセージを相手から読み込むことができるバッファにためておく必要があるが、 バッファを整理することで効率的にメッセージを受理することができる。
    プロセス間通信は pull 式しかできない。
    pull式メッセージはイベントハンドラ(ルール)を用いる。

    要求メッセージ、通知メッセージ

    具体的な処理内容を知らせるものを要求メッセージという。 メッセージを出す方が相手のインターフェイスに合わせる。
    参考 : メソッド

    イベントを知らせるものを通知メッセージという。 メッセージを受け取る方がその通知に対する振る舞いを実行する。
    参考 : ルール

    フレームワークは通知メッセージが、 コンポーネントは要求メッセージが適する。
    多態性を生かすなら通知メッセージが適する。


    ルールとメソッド - Rule, Method

    操作は実行する順番を並べた手続きのことである。
    操作は大きく分けてルールとメソッドに分類できる。

    ルール - Rule

    「〜したとき〜する」というタイプの操作。 積極的にメソッドに委譲すると再利用を期待できる。
    ルールは、メソッドの内部に実装される。たとえば、属性を変更する メソッドのでは、属性の値を変更したあとにフラッシュする。
    プログラム外部のイベントは pull式メッセージ のイベントハンドラで受け取る。 イベントハンドラはどの概念と関連するというものではないが、 起動する必要のあるメソッドを実行できるウィンドウなどの ある程度大きな集約概念がまとめて関連するとよい。
    対象となる全部のモデルによってトリガする操作の数が異なってくる。 (多態性)

    メソッド - Method

    「〜するには〜する」というというタイプの操作。
    引数の概念(クラス)によって起動するメソッド(実装方法)が 異なることがある。(多態性) 多態性は 属性値識別データ による分岐や クラスによる言語の多態性を用いて実装する。
    メソッドは大きく 生成破壊メソッド概念へのメソッド関連のメソッド の3種類に分類される。
    操作の具体化を細かくすると汎用的になるが 必要以上にプログラムが大きくなるので注意。
    何度も参照される概念に2文字程度の局所的な別名を用いるとよい。 これはプログラムに限らず一般的な操作の説明をするときも有効である。

    参考 : 文献 1.「ルール」「メソッド」


    生成破壊メソッド - Create, Destroy

    概念の生成破壊。
    概念の生成と破壊なので実体は存在し続けることもある。

    生成時の概念の具体化

    生成する際に 属性 や関連を全て具体化することになる。

    属性のコピーとリンク

    属性を指定する引数は copy(embed)、関連を指定する引数は link される。 そのどちらかであるかコメントしておく。

    リソース、プロトタイプの指定

    生成の引数は属性だけでなくリソースまたはプロトタイプの 識別データから属性をコピーして指定してもよい。
    プロトタイプがコンストラクタの中でハードコーディングされているなど 暗黙的に存在することもある。
    プロトタイプはあらゆるオブジェクトよりも先に生成される。
    • TWindow.new(言語上の識別子、デフォルトコンストラクタから)
    • "TWindow".new (文字列の識別データから)
    • ResourceID(241).new (数値の識別データから)

    破壊

    破壊するとき、その概念の属性も全て破壊する。
    属性を破壊する他に、たとえばOSのリソース管理で使われているような、 あるクラスから生成した全ての概念を破壊する方法もある。


    概念へのメソッド - Objective Method

    概念への操作は、操作が概念に関連する(関連する概念が1つの)操作。 通常、属性とアクセス(コピーまたはリンク)する。 特定の属性の検索を伴うこともある。

    属性による操作の分類

    概念への操作は対象となる 属性 によって分類するとよい。

    暗黙の関連の操作

    捜査の対象となる概念と、その暗黙的に関連する概念との関連の操作を 伴うことがある。たとえば、文字列の色を変えたとき、色の属性の値を 変更することだけでなく、表示する画面の描き変え(関連の操作)もする。

    状態遷移、クラスチェンジ

    状態遷移とは概念(属性)が変化することなので、実装の仕方によって 識別データの変更だけでなく概念の生成破壊(クラスチェンジ)が 起こることもある。そのときは、継承される属性(特に関連)を受け継ぐ ために両方のインスタンスの間でコピー、つまり 関連のメソッド をする。


    関連のメソッド - Interactive Method

    概念への操作は操作が関連に関連する(関連する概念が複数の)操作。 関連する複数の概念に 対応付け関連修飾) は必要ない。そのため、汎用的である。

    関連する概念は2つ

    関連する概念はなるべく2つより多くしない。 3つ以上あるときでもなるべく2つずつに分ける。

    オブジェクト指向言語と関連の操作

    オブジェクト指向言語のほとんどは1つのオブジェクト(概念)しか 関連することができないため、操作の関連する概念のうちの1つだけに 所属することになる。また、複数の概念による多態性は言語で提供されない。
    使いたい操作は関連するどちらかの概念に関連している。

    演算

    演算は概念( 識別データ のみ)に対する比較、変換、計算、 参照(ナビゲーション)のこと。演算のほとんどは対象となる 概念の 属性 である。
    型が異なるときは同じ型にする。 クラス(識別子)に対しても演算可能であるとよい。


    演算器 - Operative Adapter

    すべての属性ではなく演算やデフォルトを通して簡単に多くの属性を 設定するための付加的なオブジェクト。 設定する概念にくっつくためアダプタと呼ばれる。
    ほとんどの操作は暗黙的に演算器を含んでいると考えられる。
    具体的な属性を隠す役割もある。
    たとえば、ペンなどの描画ツールや、ストリームなど。
    参考 : 文献 2.「アダプタパターン」

    演算器の属性

    • 固定値、使用した式
    • 状態値:状態遷移マシン的振る舞い
    • 操作引数
    • 出力値
    • 入力元、出力先

    図表現 - Figure

    オブジェクト図

    関連の表現
                多
    クラス −−−−−−−−−− 生徒
             所属する
    
    ・対応付けの数が1のときは何も書かない。
    ・見る方向は自動車の進む方向
           →    |
          −−−  ↑|↓
           ←    |
    
    集約の表現
    +- 二次方程式 y=axx+bx+c ----------+
    |                 |
    | 左辺y     右辺     解 |
    |     所属する|        |
    |     +--- 二次式 -----+   |
    |     |  axx + bx + c  |   |
    |     +----------------+   |
    +----------------------------------+
    集約はボックスで囲む。
    

    データフロー図

    希望のデータが求まるまでのデータの変換過程を示した図 プログラムの引数に表される。

    トリガルール図

    処理する順序(並列)を示した図。 図でなくてもプログラムの制御文に表される。
    参考 : 文献 1.「イベント図」


    参考文献 - Reference

    1. オブジェクト指向方法序説(基盤編), James Martin, James J.Odell
    2. デザインパターン, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
    3. ハイパーテキスト情報整理学, Robert E. Horn
    4. 修飾, Tucker!
    5. ページ理論, T's-Neko

    version 1.11 - written by Toda Mar.4.1996, Jan.7.1998