1. azuki8
Changes in body
Source | HTML | Preview
@@ -1,61 +1,61 @@
#シーケンス図でクラス図に操作を追加する
クラス図は、クラス間の構造を描く。
そして、クラス間の関連や操作・属性が一目で分かる。
当たり前のことだが、これはとても便利だ。
また、UMLモデリングツールを使っていると、
シーケンス図を書きながらクラスに操作を追加してゆくことができ、
クラス図側にも自動的に操作が追加されてゆくのでさらに都合がいい。
#クラス図の配置メンテナンスの発生
しかしどうだろう、
クラスに操作が増えると、クラスとクラスの間のレイアウトが崩れてくる。
関連線がクラスの下に隠れたり、クラス同士が重なって読めなくなる。
仕方がないから、クラス図のレイアウトを直す。
自動レイアウト機能もあるが、自分の思った通りにレイアウトしてくれるわけではない。
やがては、ダイアグラムのメンテナンスが面倒になってくる。
これでは、ツールを使っているのではなく、ツールに使われ始めている。
何か、本末転倒だ。
#メンテナンスを防ぐ2枚のクラス図
こんなときは、クラス図を2枚用意する。
- クラス間の構造をみるためのクラス図
- クラスの操作を一覧するためのクラス図
##クラス間の構造をみるためのクラス図
一つ目のクラス図では、属性と操作を非表示にしておく。
大抵のUMLモデリングツールにはこの機能がついている。
-これで、クラスに操作が追加されてもレイアウトは崩れてゆかない。
+これで、シーケンス図の編集でクラスに操作が追加されてもレイアウトは崩れてゆかない。
よって、メンテナンス作業は不要だ。
##クラスの操作を一覧するためのクラス図
二つ目のクラス図では、操作が増えてレイアウトが崩れても、
クラス同士が重ならないようにクラスを配置しておく。
関連線も非表示(ダイアグラムから削除)にしておく。
こうしておけば、クラスに操作が追加されても、それを一覧でみることができる。
もし、クラス図が大きくなりすぎるならば、クラスのグループごとに、さらにクラス図を分けておこう。
クラス図に「XXのクラスの操作一覧のためのクラス図」などと名前を付けておくと使いやすいだろう。
#解決策の考えかた
今回の問題は、クラス図から得たい目的が2つあるのに、
その2つの目的を1枚のクラス図で解決しなければならない、
と思い込んでいるところにあるのではないだろうか?
複数の目的を一つの手段で解決しようとすれば、
大抵の場合、片方を立てれば、もう片方が立たなくなる。
ならば、目的ごとに手段を用意してしまえば良いではないか、
と考えてみると、解決できてしまうこともある。
今回の場合は、UMLのモデリングツールを使っている場合なので、
ダイアグラム間の整合性は、ツールがとってくれる。
ならばと、ダイアグラムを多少増やしたところで、手間は増えず、ただ楽になっただけだった。
#アレンジ
あとは、アレンジもあると思う。
クラスの構造を見るクラス図で、主要な操作と属性だけは表示しておきたいのならば、
モデリングツールには、操作や属性を指定して表示非表示を切り替える機能がある。
多少の面倒はあるが、これでクラス図の配置を大幅に直す必要性は、かなり低下する。