モデル化の作業をしている他の同僚に差をつけることのできる、いくつかの重要な経験法則についてお話したいと思います。この単純ではありますが、重要なアドバイスは、UMLのクラス・モデル、ユース・ケース・モデル、さらにパーシスタンス・モデルを含む、ソフトウェア・ダイアグラムを構成する吹き出しや線の配置方法に焦点を絞ったもので、あらゆる種類のダイアグラムに適用できます。
すっきりした外観のダイアグラムを描くには、以下のものを避ける必要があります。
まず、ある例について考えてみましょう。図1と図2は、2つの異なるスタイルを使用して描かれた2つのダイアグラムを示しています。最初の図は、込み入っていて、まとまりがありませんが、2番目の図は (やや面白みを欠くものの) 単純で良く整理されています。どちらが良いデザインに見えますか? ほとんどの人は、2番目のほうが、すっきりとしたレイアウトになっているので良く見えると思うでしょう。実は、どちらのデザインも、機能的には同一なのです。
図1. 「取り散らかった」ダイアグラム
図2. 「すっきりした」ダイアグラム
私は図1をどのように改善したのでしょうか? まず、すべての吹き出しのサイズを同じにしました。大きな吹き出しは、小さな吹き出しよりも重要に見えます。そうしたことを伝えたい場合には、それで良いでしょう。しかし、どちらを選ぶかと言われたら、私は吹き出しを同一サイズにするほうを選びます。この方法は、すべてのユース・ケース吹き出しとアクター記号を同一にしやすいUMLのユース・ケース・ダイアグラム、UMLコラボレーション・ダイアグラム、UMLシーケンス・ダイアグラム、およびユーザー・インターフェース・フロー・チャートには最適です。個々のクラスごとに属性や操作の数が異なるUMLクラス・ダイアグラムや、UML状態チャート・ダイアグラムおよびパーシスタンス (データ) モデルなどのような、吹き出しに入る情報の量が変化するダイアグラムでは、これはちょっと困難になります。
また、図2には、図1と異なり、対角線が含まれません。これは、吹き出しが格子上にあるように配置し直し、結合された吹き出しを縦方向または横方向に離すことによって実現されています。ほとんどの人の視覚には、直線のほうが訴える力が強いのです。
図1には、相互に交わる2本の線があります。私の一般的な経験法則では、ダイアグラムに含まれる交線の数をできるだけ少なくする必要があります。いくつかの吹き出しを移動させることにより、2本の線が交わるのを簡単に回避できました。残念なことに、いつもこのようにうまく行くとは限りません。必ずしも交線を避けることができるわけではないのです。図3では、5つの吹き出しを完全に結合したかったのですが、少なくとも2本の線を交差させなければ、それは不可能でした。ご覧のとおり、吹き出し3と5を結合するには、ほかに方法が見つかりませんでした。交線を使わざるを得ない場合、私は図4のように、一般的な電気配線図で使用される表記を使用し、一方の線が他方の線を「またぐ」ように描くことにしています。このように線をまたがせることの利点として、それらの線がダイアグラムで交差しているだけであって、結合しているのではないことを、明示できることが挙げられます。
図3. 線を交差させずに3と5を結合するには、どうしたらよいでしょう?
図4. 一方の線が他方をまたぎます
図4をさらに改良して曲線をなくしたものが図5です。一般に垂直または水平の直線のほうが好まれるのです。今回も、格子上にダイアグラムを描いているつもりになって (実際には、このような描き方は、多くのコンピューター支援システム・エンジニアリング (CASE) ツールの組み込み機能になっています)、そのような格子上に描くように吹き出しと線を描きました。
図5. 図4をさらにすっきりさせたダイアグラム
詳細な書き込みが多すぎたり、乱雑に見えたりするダイアグラムは、見栄えが悪くなります。1枚の複雑なダイアグラムにすべてを詰め込むよりは、詳しさの程度を変えたダイアグラムを何枚か描いたほうが気が利いています。UMLにいくつかのダイアグラムがある理由の1つは、このことによります。ソフトウェアが複雑すぎるため、単一のダイアグラムではすべての機能をモデル化することは期待できません。さらに、UMLを使用すると、ダイアグラムにパッケージを付け加えることができます (これについては、次週のトピックで採り上げます)。
これに関連して、画面またはページのスペースの使い方を考慮する必要があります。私の考えでは、あるダイアグラムが複数のページにまたがって広がるほうが、1ページで印刷するために、何もかも無理やり詰め込むより良いと思います。必要なだけスペースを使って、分かりやすいダイアグラムを描くべきです。
以上の経験法則は、きわめて広く通用しますが、ダイアグラムの外観をいつまでも調整して、モデル化作業に時間がかかりすぎる危険が常に潜んでいます。これを解決する方法の1つは、そこそこ良い見栄えのダイアグラムを目指すことです。あなたが開発作業にかかわっているかぎり、ダイアグラムが完全である必要はないのです。そのダイアグラムが狙いどおりにアプリケーションをモデル化できていると納得できたら、線が交差しないように吹き出しを移動させて、ダイアグラムを分かりやすくしてください。
私たちの第一目標は、きれいなダイアグラムを作り上げることではなく、システムをモデル化することです。これらの経験法則を利用することにより、あまりよくないデザインを良く見せかけることも可能であることは、十分に注目する点です。たとえば、図2からスタートし、それを配置し直して図1のように描き換え、実際よりも複雑なデザインに見せかけることも可能です (たとえば、上級管理者に対して、作業を行うための時間やリソースを増やすように説得したり、自分が気に入っていない代替案から彼らの目をそらしたりするために)。皆さまの動機が状況に応じて変化するものであるのなら、皆さまが、オフィス・ポリティクスにおける生存競争などではなく、優れたデザインの外観に磨きをかけることに専念できるような、恵まれた環境にあることを願っています。
-
Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology、Scott W. Ambler著。New York: Cambridge University Press, 1998.
-
Process Patterns -- Building Large-Scale Systems Using Object Technology、Scott W. Ambler著。New York: Cambridge University Press, 1998.
-
The Object Primer 2nd Edition、Scott W. Ambler著。New York: Cambridge University Press, 2000.
Scott W. Amblerは、オブジェクト指向ソフトウェア処理の指導、アーキテクチャー・モデリング、およびEnterprise JavaBeans (EJB) 開発を専門とするコンサルタント会社である、Ronin International の社長です。彼は、オブジェクト指向開発に関する本を執筆あるいは共同執筆しています。最近刊行されたものとしては、この記事で要約された主題を詳しく論じた The Object Primer 2nd Edition などがあります。彼の連絡先はscott.ambler@ronin-intl.com およびwww.ambysoft.com にあるサイトです。