*begin*back*foward*end*contents

開発モデル編 -
第16章 静的構造モデル

静的構造モデルとは、クラスの静的な関連構造を示すものであり、その図式表現にはクラス図を使う。Dropのクラス図は、オブジェクト指向統一モデリング言語(UML:Unified Modeling Language)に準拠しているものである。

UMLクラス図の表現力はとても優れており、記述形式はシンプルで洗練されている。しかしながら、そのセマンティクスついては詳細すぎる部分があり、このことがUML普及の障壁となるかもしれない。

そこで、Dropの静的構造モデルは、Drop方法論のセットとして必要と思える表記に止めている。また、UMLの表記法の中で一部冗長と思えるな表記に改善を加えたものや、Drop方法論として追加した表記が若干ある。そのようなDrop独自の表記は、以下のマークが付けられている。

sorry this is image

静的構造モデルは、下記の項目に分けて解説をおこなう。

表記法&利用例 表記の説明と利用例を示す
解説 表記法の詳細とその使い方について解説
Drop利用フェーズ Drop開発サイクルで使われるフェーズ
注意事項 使う必要のない場合、代替できる表記について

またクラス図の解説は、以下のようにクラス図の利用レベルを分けて解説する。実際にプロジェクトで利用する際には、無理せずに、まず基本表記から使っていくことを薦める。

基本表記 Dropの静的構造モデルとして基本となる記述
応用表記 Dropの静的構造モデルの中で、設計・実装局面で使われる表記や複雑な問題をモデル化する際にだけ必要となる記述

16.1 基本表記

クラスの表記法&利用例

sorry this is image
図16-1 クラスの表記法

解説

上段にクラス名、中段に属性、下段に操作名を記述する。

Aは、クラスの属性と操作を記述したものである。通常、クラスが多くなると強調すべき属性や操作だけを記述したり、Bのように、クラス名だけを記述する。Cは、設計フェーズにおける詳細な記述であるが、Dropは、この記述を強制するものではない。

どの程度詳細に記述するかは対象問題に応じてチーム内で決定する。

図Cの記号について説明する。

+......public(公開属性または操作)

-......private(非公開属性または操作)

#......protected(自クラスとサブクラスだけに公開する属性または操作)

Drop利用フェーズ

図中のAやBは、Drop開発全般にて使用される。

図中Cは、設計フェーズ(コンポーネント設計・実装、システム共通設計、アプリケーション設計・実装)にて使用されるが、どの程度クラス属性・操作について、詳細の記述をすべきかは、下記「注意事項」に書かれているととに留意しながら、対象となるモデルごとに判断する必要がある。

注意事項

実装フェーズが近くなるとクラスの詳細な記述が必要とされるだろう。Cのようにクラス図の中に実装に必要となる情報を埋め込むこともできる。しかし、その結果、モデルとしての可読性や理解性が損なわれる可能性もあることを忘れてはならない。Cの記述は、クラスの詳細について付加的に説明する図として有効なものとなる。

関連の表記法&利用例

sorry this is image
図16-2 関連の表記法(社員が所有する備品)

解説

上記は、「社員は備品を所有する」というモデルを表す。

クラスとクラスの間の線を関連という。関連は、クラスから導出されるインスタンス間の関係を表すものである。このインスタンス同士の関係は、後述のインスタンス図ではリンクとよばれる。

図中のアスタリスクや数字は、関連における多重度を表している。関連においてインスタンスの個数が限定できるものは明確な数字を示す。「*」は「0以上」、「0..1」は「0から1」という意味である。

この意味は、読者がそれぞれのインスタンスになってみると理解できる。「*」は「社員インスタンスから備品をみると、その社員は0個以上の備品を所有する」ということを意味し、「0..1」は「備品インスタンスから社員をみると、その備品を所有する社員は1人若しくは未所有(0人)となる」、ということを意味する。「0..1」によって、1つの備品を複数社員で共有することはできないという意味が明確に表現されている。

なお、関連の多重度はその他以下のような記述ができる。

sorry this is image
図16-3 関連の多重度

Drop利用フェーズ

Drop開発フェーズ全般にて使用される。

注意事項

備品クラスの属性に、社員との関係を表すための属性(社員NO等)が存在しないことに注意しよう。クラス図の基本的な考え方として、関連を実現するための属性は記述しない。また、関連の方向は双方向である、つまり、どちらのインスタンスからもお互いを参照可能であると考えなければならない。しかし、分析から設計へと進むにつれ、関連に方向性を記すことも可能である。この表記については後述する。

関連(集約)の表記法&利用例

sorry this is image
図16-4 集約の表記法(請求書は請求明細行で構成されている)

解説

上記は、「請求書は請求明細行で構成されている」というモデルを表す。

集約とは、「全体-部分」のモデルである。上記の場合は、請求書の部分として請求明細行がある。集約は菱形で表される。集約を記述することで、2つのクラスの間に意味的に強い結びつきがあることを知ることができる。この例では、請求明細行は、請求書の存在がなければ存在する価値がないという意味を持つ。

Drop利用フェーズ

Drop開発フェーズ全般にて使用される。

注意事項

関連と集約の違いによって、実装方法にあきらかな違いがでるというわけではない。関連と集約の違いを実装方法の違いと認識するのは誤った考えである。集約の効果は、モデルの意味理解を助けるものと考えなければならない。ただ、実装におけるクラス間の設計指針を暗に入れ込むという役割もある。これを図16-4で解説すると、請求書に届くメッセージは、集約する部分クラスに同じメッセージを伝搬するかもしれないということを表している。たとえば、請求書に「印刷しなさい」というメッセージが届くと、所有する請求明細行に対して、「印刷しなさい」というメッセージを伝搬するだろうという意味を含み持つことになる。

何れにせよ、関連と集約の実装における決定的な違いはなく、意味的にもどちらとも言えない場合もある。その場合は、あまり悩む必要などなく、どちらかにすればよい。

関連名とロール名の表記法&利用例

sorry this is image
図16-5 関連名とロール名の表記法

解説

上記は、「人は会社で働く」というモデルを表す。

関連は名前を持つことができる。図では「働く」というのが関連名である。また、関連の両端の文字はロール名と呼ばれ、関連におけるクラスの役割を示している。たとえば、人クラスが会社との関連を持つ際のロールは「社員」である。ロール名を使うことでクラスの役割の一側面に焦点をあてることができる。たとえば、会社クラスは人クラスを社員として見ており、それ以外の人クラスとしての特徴を会社は知る必要がないということを意味する。

関連の線だけでは関係があいまいすぎる時に、ロール名と関連名を使ってモデルの意味付けを深めることができる。

Drop利用フェーズ

Drop開発フェーズ全般にて使用される。

注意事項

間連名には三角印を書くことができるが、これは「人が会社で働く」ことを意味的な方向として表しているだけである。よって、この矢印がインスタンスを指し示す実装上のポインタとは異なるものである。

継承、表記法&利用例

sorry this is image
図16-6 継承、表記法&利用例

解説

上記は、「グラフィッククラスから継承した3つのクラス」を示すモデルである。操作の部分に「操作名{abstract}」と記述すると、その操作は実装の伴わない抽象操作であることを示す。また「{abstract}」はクラス名の下段に記述することもできる。この場合は一切の操作をサブクラスに委ねる抽象クラスとなる。UMLによる継承の表記は、上記図のどちらでもよい。また、OMTの継承表記は若干異なる(三角を書く位置がクラスとクラスの中間にある)が、OMT表記を使っても問題はない。

継承は、問題領域分析フェーズで発見されることはあまりない。ほとんどがODGのフェーズもしくはADGの設計フェーズで発見されるものである。また、多重継承についてはあまり推薦できないが、実装上必要不可欠な場合は取り入れてもよい。

Drop利用フェーズ

Drop開発フェーズ全般にて使用される。

注意事項

多重継承は、分析フェーズでは使用してはならない。もし、多重継承の必要性を感じた場合は次のような代替案を考えることを勧める。

  • 問題の本質的な部分をスーパクラスから継承する。
  • もう1つの継承は、関連を使って書き換える。

部分クラスの非公開表記&利用例

sorry this is image
図16-7 部分クラスの非公開表記と利用例(車の構成部品モデル)

解説

上記は、「車は車体、エンジン、タイヤ、座席から構成される」という関連(集約)のモデルである。Dropでは、部分となるクラスを隠すことができる。 いくつかのクラスを隠しているクラスには、クラス名の右端に「+」マークがつけられる。また隠されるクラスは、以下の条件が成立しなければならない。

  • 隠しているクラス(+マークのついたクラス)以外のクラスに使われていない。
    (たとえば、タイヤクラスは車クラスでしか使われない)
  • 隠しているクラスの存在だけで、静的構造モデルの情報としては十分である。
    (たとえば、モデルにエンジンクラスがなくても、車クラスからその存在は想定される)
Drop利用フェーズ

Drop開発フェーズ全般にて使用される。

注意事項

非公開表記は、Dropで追加した表記である。この表記は、「オブジェクト発見手法DRO」により部分クラスを抽出した結果、多くの部分クラスによってクラス図のシンプル性が保てなくなる場合に使用する。

コンポーネント表記&利用法

sorry this is image
図16-8 コンポーネント表記と利用例(車の構成部品モデル)

解説

車が再利用可能なコンポーネントであるばらば、非公開となるクラスを隠して車クラスにコンポーネントマークを付与する。コンポーネント表記は、クラス名の右端に「〇」マークを付ける方法と、UMLのコンポーネント表記のどちらでもよい。

先に挙げた「部分クラスの非公開表記」と「コンポーネント表記」の違いは下記の通り。「+」マークの付いたものはコンポーネントの候補となりうるが、そうでない場合もある。たとえば、単に図をシンプルにするためだけに「+」マークが使われる時などである。

  • コンポーネントユーザがコンポーネントを利用する上で意識すべきクラスがコンポーネントとなり、他のクラスは隠される。
  • 1個のクラスでもコンポーネントになりうる。(図中タイヤ・コンポーネント)
Drop利用フェーズ

Drop開発フェーズ全般にて使用される。

注意事項

Dropでは、コンポーネントに対して「コンポーネント仕様」ドキュメントが要求される。

16.2 応用表記

インタフェース表記法&利用例

sorry this is image
図16-9 インタフェース表記法&利用例

解説

図16-5 Aの解説

この表記の考え方は、オブジェクトの操作を役割(ロール)としてモデル化するものである。その表記法は、オブジェクトの外にロールをインタフェースとして「○」で表す。たとえば、図16-5で使った「人と会社モデル」の中の「人の持つ社員ロール」をインタフェースとして表すと図中Aのようになる。

図16-5 Bの解説

図中Bは、道路交通監視シミュレーションシステムを例にとって「人コンポーネント」「車コンポーネント」が保有するMovableインタフェースの使われ方を解説するものである。Application(A)は、コンポーネントが何であれMovableを持っていれば、シミュレーションの対象として操作する能力があることを示すものだ。つまり、「人」「車」は、移動可能(Movable)という役割インタフェースによって抽象化されている。また、この図では、「人」クラスが、考える(Thinkable)というインタフェースを提供しているという例も示している。このように1つのクラスがいくつもインタフェースを持つこともある。

図16-5 CとDの解説

次はもう1つのインタフェース表記法について解説しよう。印刷可能(Printable)というインタフェースを想定してみてほしい。今までの表記法だと図中Cとなる。 Printableは、printメッセージとformatPrintメッセージをまとめたインタフェースとしよう。このインタフェース定義に着目した表記として図中Dのようにも記述できる。Printableインタフェースを持つクラスはImage、Text、Paragraphという意味である。また、Printableを使って実際印刷するのは、Applicationである。

図中Dに記述は継承線が点線となっていることに注意しよう。これはUML表記の拡張関係という表記を使ってインタフェースと実装クラスの関係を表している。Dropでは、拡張関係の表記を使うのは、このインタフェース表記のみとしている。

Drop利用フェーズ

Drop開発フェーズ全般にて使用される。

注意事項

インタフェースの表記は、直接的にプログラム言語機能と結びついているものではない。ここでその例を示そう。インタフェース概念を使ったモデリングの例としては下記のようなものが考えられる。

  1. クラスのインタフェースと実装を分離するモデルとしてインタフェースを使う。
  2. コンポーネントユーザに対するロールのモデル化にインタフェースを使う。

(1)は、クラスをインタフェースと実装に分類するという仕組みを実現するために使われる。一方(2)は、再利用可能なクラス(つまりコンポーネント)の利用者から見た役割をインタフェース化するという意味を持つ。Drop方法論の問題領域分析フェーズでモデル化されるインタフェースは(2)のコンポーネントユーザに対するのロール(役割)としてのインタフェースになるだろう。その場合に表記法は図16-9の(A)から(D)の何れかの表記が使われることになる。

一方(1)については、クラスのインタフェースと実装を分離するというソフトウェアアーキテクチャ設計における利用法であり、コンポーネント分析フェーズ、システム設計、システム共通設計、アプリケーション設計・実装フェーズなどで考慮されることになる。この場合の表記法は、ロールを強調する表記は使用されず、インタフェース定義に着目する図(図16-9のD)だけが使われる。

これらのモデルを実装に落とし込む際には、プログラム言語によってサポートされている機能を使うことになる。たとえば、C++言語では、純粋仮想関数によって構成される抽象クラスをインタフェースとすることになるだろう。Java言語では、interfaceを使うことができる。このようなインタフェース継承のメカニズムを使わないで、インタフェースのクラスが実装クラスを持ち、処理を委譲するという設計をすることもある。(詳しくは「第27章 コンポーネント設計・実装」のコンポーネント構造の具体化を参照されたい)

コンポジション集約

sorry this is image
図16-10 コンポジション集約の表記法(請求明細行はHashtableクラスによって管理される)

解説

上記は、「請求明細行はHashtableクラスによって管理される」というモデルを表す。

このように、設計フェーズにおいて、請求書クラスの属性であるHashtableクラスをあえて外に出すことで、請求書と請求明細行の詳細な繋がり方を設計書として示したいときがある。これは、コンポジション集約とよび、黒い菱形で表される。前述した集約は、このコンポジション集約と比較して共用集約ともよばれることもある。

Drop利用フェーズ

コンポーネント設計、システム共通設計、アプリケーション設計

注意事項

コンポジション集約は、実装イメージを連想させるためのモデルであり、オブジェクトの意味的な側面を表すモデルには現れないことに注意しよう。たとえば、要求仕様から作成される要求モデルでは、Hashtableクラスなど存在せず、請求書と請求明細行間の関連で、両クラスから導出されるオブジェクトインスタンスに関係ができることを示している。

また、実装言語における「クラス属性をポインタ型で持つか?」「実体で持つか?」ということにも直接的な関係がないことにも注意しよう。

関連の方向表記&利用例

sorry this is image
図16-11 関連の方向表記と利用例(請求書と請求明細行のモデル)

解説

上記は、「請求書と請求明細行」の関連について方向(矢印)と関連の実装型を示したものである。2つのクラスの関連に、矢印が付けられた場合、それは参照可能な方向となる。矢印が1方向しか記述されない場合は、1方向の参照ということになる。

Drop利用フェーズ

コンポーネント設計、システム共通設計、アプリケーション設計

注意事項

基本的に、方向性と実装型は、設計フェーズにおいて具体的に設計するとよい。しかし、問題領域分析フェーズの中で、この表記により、方向のみを矢印で記述することで、共通的なクラスが他のクラスから独立していることを明示することができる。「オブジェクト発見手法DRO」では、この表記を使うことにより共通クラスの独立性を高めている。

注釈の表記&利用例

sorry this is image
図16-12

解説

実装フェーズが近づいてくると、実装方法をクラス図の中で解説したくなることがある。そのような場合は、図16-12のように記述することができる。

Drop利用フェーズ

コンポーネント設計、システム共通設計、アプリケーション設計

注意事項

クラス図中の注釈は、必要最小限に止めること。

能動的動作が可能なクラス(Active表記)

sorry this is image
図16-13

解説

開発するクラスの中には、クラスの提供するサービスを呼び出した段階から呼び出し側と非同期にサービスが実行すべきこともあるだろう。このような場合は、クラス内でスレッドやプロセスを起動してサービスの非同期実行を実現することになる。図16-13では、Clientクラスから呼び出されるJobControllerクラスが非同期に仕事を処理できることを表している。このように、JobControllerのようなクラスは「能動的動作が可能なクラス」として太線の矩形で囲み"<<Active>>"と記述することができる。なお、"<<Active>>"は省略してもよい。また、"{parameter}"表記は、パラメータによって関連を得ることを意味している。この例では、Clientクラスに依存しないように設計されているJobControllerが、ClientクラスからJobインタフェースを実装するオブジェクトをパラメータとして受け取ることを表している。なお、"{parameter}"のような記述については「第17章 動的構造モデル」のコラボレーション図にて詳細に解説する。

Drop利用フェーズ

コンポーネント分析、コンポーネント設計、システム共通設計、アプリケーション設計

注意事項

図16-13ではJobControllerはいくつかのクラスで構成されたコンポーネントとして表されており、実際のスレッド生成またはプロセス生成のためのクラスなどをコンポーネントユーザから意図的に隠していることに注意しよう。この図は、JobControllerコンポーネントがどうやって実装されるかということを表す図ではなく、JobControllerコンポーネントのユーザに対して、JobControllerの使い方を示すために作られた例である。このように、実装フェーズが近くなってくると、コンポーネントを利用するのか、それとも実装するのかという目的に併せて、抽象化すべき箇所と詳細化すべき箇所を差別化することが肝要となる。

関連の制約の表記法&利用例

sorry this is image
図16-14 関連の制約の表記法(プロジェクトと社員の関係)

解説

上記は、「プロジェクトには一人のリーダと何人かのメンバがいる」というモデルである。このように、クラス間に2つ以上関連がひかれることもある。その場合、上記図のように関連名により関連の意味を明確に分類しなければならない。また、関連間での制約についても図のように{文字}で、記述するとよい。上記図では、リーダという関連はメンバという関連のサブセットであることを示している。

Drop利用フェーズ

問題領域分析、コンポーネント分析

注意事項

このモデルも他のモデルと同様に、実装に完全に一致するものではない。これは、2つの関連を実装する手段を決定したものではなく、意味的に関連の種類が2つに分かれているということを示している。従って、関連の実装方法がひとつのArray(コレクション)で実装されることもありうる。

では、なぜこのような冗長な記述が必要とされることがあるのだろうか?それは問題領域における意味の理解を高める場合に使用される。さらに、実装局面においてリーダとなる社員インスタンスはArray管理とは別に持つべきかもしれないという分析結果を設計者に伝えるためのものである。つまり、関連の実装方法の詳細は設計者に委ねながらも、オブジェクト同士の意味的な関係を設計者に伝えることで、分析モデルをベースとした設計モデルが作れるようにする。

限定子の表記法&利用例

sorry this is image
図16-15 限定子の表記法(飛行機の座席を構造として捉えたモデル)

解説

上記は「飛行機にはいくつかの座席がある」というモデルを表す。Aは限定子を使い、Bは限定子を使わない例である。Aのモデルは、「飛行機の中で、座席は座席NOによってユニークになる(限定される)」という意味となり、Bの「飛行機は幾つかの座席を持つ」という意味よりも多くの情報を含むことができる。実装段階では、座席NOは、座席クラスのインスタンスを限定させるIDとして使われることになり、飛行機から座席をアクセスするためのキーとして使用されることになるだろう。

注意事項

限定子を使うことで、相手オブジェクトを限定(ユニーク)するKeyを表すことができるため、モデルの意味を深めることができる。限定子を使う際の関連の多重度は、「限定子により相手オブジェクトが限定される」という意味で「*」から「1」の記述となっていることに注意しよう。

Drop利用フェーズ

問題領域分析、コンポーネント分析

3項関連の表記法&利用例

sorry this is image
図16-16 3項関連の表記法(銀行・客・取引口座のモデル)

Drop利用フェーズ

問題領域分析

解説

上記は、「客は、いくつかの銀行にいくつかの取引口座を持つ」という3項関連のモデルである。3項関連により、3つのクラスのインスタンスのリンクが明確化される。意味を分かりやすくするために、実際のオブジェクトのインスタンスの例をイメージとして図16-17に示そう。なお、この図はあくまでイメージでありUMLによるフォーマルな表記ではない。

UMLのよるオブジェクトインスタンスの表記については「第17章 動的構造モデル」にて解説している。

sorry this is image
図16-17 3項関連のインスタンスイメージ(銀行・客・取引口座のモデル)

関連属性(クラス)の表記法&利用例

sorry this is image
図16-18 関連属性(Association attribute)の表記法(社員の給与モデル)

解説

上記は、「会社で働く社員の間に成立する給与」を表すモデルである。関連属性は、2つのクラスのインスタンスのリンクにより成立する属性で、両クラスの属性として配置ができないものが対象となる。

図16-19を使ってこのことを解説しよう。人クラスの属性として給与は適切だろうか? もし、人が他の会社で働いていた場合はどうだろうか。また、人クラスは、会社クラスとの関連において給与以外に様々な属性をもつことになるのではないか?

このように考えると、人クラスと給与という属性は2つのクラスから分離して関連属性とした方が適切なのである。

分離された属性は、どこに属するべきかを分析が進むにつれ詳細に検討しなければならない。そのような過程で、関連属性は、クラスに昇格することもある。たとえば、給与は、基本給、手当などの支給項目や、保険料などの控除項目という属性からなるクラスになるだろう。

sorry this is image
図16-19 関連クラス(Association Class)の表記法(社員の給与モデル)

以下に、インスタンス図による「社員の給与モデル」を示す。

sorry this is image
図16-20 社員の給与モデルインスタンス図

Drop利用フェーズ

ごく希に問題領域分析フェーズで使われる。

下記、注意事項を参照してほしい。

注意事項

関連属性や関連クラスは、Dropでいう「現状認識モデル」「戦略モデル」といった現実世界の理解したり、戦略を立てたるする時に、よく使われることになるだろう。しかし問題領域分析における「要求モデル」を定める段階では「 関連属性や関連クラスを排除することで、モデルをシンプルにすることができないか?」という検討をすべきである。

ここで、図16-19の社員の給与モデルのクラス図を問題領域分析段階の要求モデルに落として考えてみよう。

この会社が、もし支社別に給与システムを要求するなら図16-21のようなモデルになる。また、全支社合同の給与システムを要求するなら図16-22のようになる。このように、給与システムの要求から考えると、関連属性や関連クラスを存在させる意味がなくなってしまっていることである。また、人クラスが社員クラスに変化していることも注意しよう。

sorry this is image
図16-21 支社別給与システム(Drop要求モデル)

sorry this is image
図16-22 全支社合同給与システム(Drop要求モデル)


*begin*back*foward*end*contents

この記事のトップへ