作成日 2008/6/22
最終更新日 2008/6/22
依存
このページではクラス間の依存について説明します(※1)。
だるまが初めてUMLを勉強したとき、依存については本当に理解できませんでした。なぜかというと、あまり書籍に書いてない。
でも、実際にソフトウェアの設計をしていると依存関係って結構出てくるのですよ。これが。結局、どうすればよいのかわからず本当に困りました。
このページでは、過去のだるまのような人たちを減らすために作成しました(※2)。
-----
※1:このページではUMLのクラス図について多少知っているものとして説明しますが、可能な限りUMLを知らなくても理解できるように努力するつもりです。なお、ここではUMLのバージョンは2.0で説明します。
※2:そういえば、「グラフの色の変更」というアドインも作成理由が同じだ。
過去(まだ、だるまがVBAが出来なかったころ)に、エクセルの等高線グラフの色をかえる必要が出てきたんだけど、このときは1つ1つ手作業でやりました。大変だったけど。
もしかしたら、過去のだるまのようなことになっている人がいるかもしれないと思って、アドイン(最初はマクロ)を作りました。
依存(dependency)(※1)とは、ある要素(element)(※2)に変更があった場合に他の要素が影響を受けることを意味します(※3)。
ClassAがClassBの変更の影響を受ける場合は、図1のように破線の矢印で表記します。
図1 依存の表記方法(ClassAがClassBの変更の影響を受ける場合)
もし、ClassAがClassBの変更の影響を受けるし、ClassBがClassAの変更を受ける場合(双方向の依存の場合)には図2のような感じで。
図2 双方向依存の場合
-----
※1:詳細はUML2.0の仕様書のp32のFig7.15とp58の「7.3.12 Dependency (from Dependencies)」を見てください。
※2:要素とはモデルを構成するものすべて意味すると考えてください。例えば、クラス図におけるクラスや操作、コメント、関連、ユースケース図におけるアクターやユースケースなどです。
要素(element)についての詳細を知りたい人はUML2.0の仕様書のp23のFig7.3とp60の「7.3.14
Element (from Kernel)」を見てください。
OCUP ファンダメンタルの受験を考えている人は勉強した方が良いと思います。
※3:このページはクラス図における依存を説明する方針だったので補足すると、実は依存というのはクラス間だけでなく、他の要素間(正確には名前付きの要素間?)でも使用できるようです。
以下はClassAがClassBの変更の影響を受ける例です(図1の例です)。
- 使用(Usage(※1))
ClassAのオブジェクトはClassBオブジェクトを持っていない(ClassAからClassBへの関連は無い)が(※2)、ClassAのメソッドの中で以下のような感じでClassBを使用する。
・ClassAのメソッドの中でClassBのオブジェクトを生成する。
・ClassAのメソッドの引数や戻り値の型、スローする例外の型(※3)にClassBが指定されている。
・ClassAのメソッドの中でClassBのクラススコープのメソッドを呼ぶ。
とにかく、ClassAからClassBへの関連は無いがソース上でClassAのメソッドの中でClassBが出てくる場合は依存。
- 実現(Realization(※4))
ClassBが仕様を定義し、ClassAがそれを実現する関係にある。
ただし、一般には図3のように表記します。
図3 実現の表記方法
- 他にもあるけどだるまが理解していないので省略
申し訳ないです。
-----
※1:詳細はUML2.0の仕様書のp32のFig7.15とp131の「7.3.53 Usage (from
Dependencies)」を見てください。
※2:正確にはClassAからClassBへの関連はあってもよいと思います。しかし、その場合はクラス図には依存の線(破線矢印)は描かないです。というのは関連がある場合は(多分)間違いなく使用しているためです(描かなくたって分かるから描かない)。
※3:「スローする例外の型」と書いたけどエクセルVBAではスローできるのはErrOjbectだけです。…それって、描く意味があまりない気がする。
※4:詳細はUML2.0の仕様書のp32のFig7.15とp124の「7.3.45 Realization (from Dependencies)」を見てください。
だるまが初めてUMLを勉強したとき、依存を表す破線矢印はすべて描かないといけないと思っていました。しかし、本当にそんなことをしたら、めちゃくちゃなことになる…(クラス図が読めなくなってくる)。
ということで、今は以下のように考えています。
- まず、クラス図で何を伝えたいのかを明確にする。Wordなどで文章を書く際も何を伝えたいのかを考えると思いますが、クラス図も同じです。
依存を表す破線矢印(※1)が無くても、伝えたいことが伝わるのであれば描かないようにしています。
- すでにクラス図があり、それを修正するよう場合には、基本的に元のクラス図に合わせる。
(詳細度を元のクラス図に合わせる。)
他にも何かルールがある場合にはそれに合わせる。
でも、絶対ではないです。ある依存がものすごく重要な場合は描くかもしれません(1を優先させる場合がある)。
- 詳細なクラス図を描く場合は、結構描くかもしれない。そういう場合は、クラス図を何個かに分ける(※2)。1つのクラス図ですべてを伝えようとすると無理があるのだから、クラス図を分ければいい。それでもクラス図がぐちゃぐちゃして分かりにくい場合は、他のところを見れば分かるものは描かない(例えば、操作の引数や戻り値の型が記載されていれば、依存を表す破線矢印は無くてもわかる)。
-----
※1:「依存を表す破線矢印が無くても」と書いたが、これは依存に限らず、操作や属性などにも同じ事が言える。
※2:クラス図を分けたあと、個々のクラス図で何を伝えたいのかを明確にすることはもちろん行う(分けた後のクラス図に対して1を行う)。
このページを作成する上で参考にしたページや書籍です。
番号 |
リンク先の名称 |
リンク先の説明 |
リンクした日 |
1 |
OMG
Document -- |
UML 2.0の仕様書(UML Superstructure Specification,
v2.0)がダウンロードできます。(※英語のページです)
|
2008/6/22 |
このページの利用によって発生した、いかなる損害について、このホームページの作成者は責任を負いません。
このページの間違いや嘘を見つけた方、このページに書いて欲しい情報がある方は
メールをお願いします。
Microsoft 、Windows 、Visual Basic および Excel は米国Microsoft
Corporationの米国およびその他の国における登録商標または商標です。
ここではExcel® をエクセル、Visual Basic® for Applications をVBAと表記する場合があります。
Mac 、Mac OS 、Mac OS X は米国Apple Computer,Inc.の登録商標または商標です。
OMG、UML、Unified Modeling
Languageは、Object Management
Groupの商標または登録商標です。
このページのUMLの図は日本電気株式会社製SystemDirector
Application Modeler UML Editor V2.0を使用して作成しました。
その他、社名および商品名、システム名称などは、一般に各社の商標または登録商標です。
このホームページの作成者はこれらの会社とはいっさい関係がありません。