本文へジャンプ

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名(非表示設定にしていない限り)とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

  • 閉じる [x]

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


送信されたすべての情報は安全です。

  • 閉じる [x]

見やすいUMLダイアグラムの描き方

Scott W. Ambler (scott_ambler@ca.ibm.com), Practice Leader, Agile Development, Rational Methods Group, IBM 
Scott W. Amblerは、オブジェクト指向ソフトウェア処理の指導、アーキテクチャー・モデリング、およびEnterprise JavaBeans (EJB) 開発を専門とするコンサルタント会社である、Ronin International の社長です。彼は、オブジェクト指向開発に関する本を執筆あるいは共同執筆しています。最近刊行されたものとしては、この記事で要約された主題を詳しく論じた The Object Primer 2nd Edition などがあります。彼の連絡先はscott.ambler@ronin-intl.com およびwww.ambysoft.com にあるサイトです。

概要: 好むと好まないとにかかわらず、Unified Modeling Language (UML) クラス・モデルおよびユース・ケース・モデルなどのソフトウェア・ダイアグラムは、見栄えによって判断されがちです。「すっきり」して見えるダイアグラムのほうが、取り散らかって見えるダイアグラムよりも、見る人 (多くの場合、ユーザーや上級マネージャー) にとって受け入れやすいものです。このヒントは、Building Object Applications That Work. の第3章をもとにしています。

日付:  2001年 4月
レベル:  初級 この記事の原文:  英語
アクティビティー: 2723 ビュー
お気軽にご意見・ご感想をお寄せください: 


モデル化の作業をしている他の同僚に差をつけることのできる、いくつかの重要な経験法則についてお話したいと思います。この単純ではありますが、重要なアドバイスは、UMLのクラス・モデル、ユース・ケース・モデル、さらにパーシスタンス・モデルを含む、ソフトウェア・ダイアグラムを構成する吹き出しや線の配置方法に焦点を絞ったもので、あらゆる種類のダイアグラムに適用できます。

すっきりした外観のダイアグラムを描くには、以下のものを避ける必要があります。

まず、ある例について考えてみましょう。図1と図2は、2つの異なるスタイルを使用して描かれた2つのダイアグラムを示しています。最初の図は、込み入っていて、まとまりがありませんが、2番目の図は (やや面白みを欠くものの) 単純で良く整理されています。どちらが良いデザインに見えますか? ほとんどの人は、2番目のほうが、すっきりとしたレイアウトになっているので良く見えると思うでしょう。実は、どちらのデザインも、機能的には同一なのです。


図1. 「取り散らかった」ダイアグラム
図1. 「取り散らかった」ダイアグラム

図2. 「すっきりした」ダイアグラム
図2. 「すっきりした」ダイアグラム

異なるサイズの吹き出しを避ける

私は図1をどのように改善したのでしょうか? まず、すべての吹き出しのサイズを同じにしました。大きな吹き出しは、小さな吹き出しよりも重要に見えます。そうしたことを伝えたい場合には、それで良いでしょう。しかし、どちらを選ぶかと言われたら、私は吹き出しを同一サイズにするほうを選びます。この方法は、すべてのユース・ケース吹き出しとアクター記号を同一にしやすいUMLのユース・ケース・ダイアグラム、UMLコラボレーション・ダイアグラム、UMLシーケンス・ダイアグラム、およびユーザー・インターフェース・フロー・チャートには最適です。個々のクラスごとに属性や操作の数が異なるUMLクラス・ダイアグラムや、UML状態チャート・ダイアグラムおよびパーシスタンス (データ) モデルなどのような、吹き出しに入る情報の量が変化するダイアグラムでは、これはちょっと困難になります。


対角線を避ける

また、図2には、図1と異なり、対角線が含まれません。これは、吹き出しが格子上にあるように配置し直し、結合された吹き出しを縦方向または横方向に離すことによって実現されています。ほとんどの人の視覚には、直線のほうが訴える力が強いのです。


交線を避ける

図1には、相互に交わる2本の線があります。私の一般的な経験法則では、ダイアグラムに含まれる交線の数をできるだけ少なくする必要があります。いくつかの吹き出しを移動させることにより、2本の線が交わるのを簡単に回避できました。残念なことに、いつもこのようにうまく行くとは限りません。必ずしも交線を避けることができるわけではないのです。図3では、5つの吹き出しを完全に結合したかったのですが、少なくとも2本の線を交差させなければ、それは不可能でした。ご覧のとおり、吹き出し3と5を結合するには、ほかに方法が見つかりませんでした。交線を使わざるを得ない場合、私は図4のように、一般的な電気配線図で使用される表記を使用し、一方の線が他方の線を「またぐ」ように描くことにしています。このように線をまたがせることの利点として、それらの線がダイアグラムで交差しているだけであって、結合しているのではないことを、明示できることが挙げられます。


図3. 線を交差させずに3と5を結合するには、どうしたらよいでしょう?
図3. 線を交差させずに3と5を結合するには、どうしたらよいでしょう?

図4. 一方の線が他方をまたぎます
図4. 一方の線が他方をまたぎます

曲線を避ける

図4をさらに改良して曲線をなくしたものが図5です。一般に垂直または水平の直線のほうが好まれるのです。今回も、格子上にダイアグラムを描いているつもりになって (実際には、このような描き方は、多くのコンピューター支援システム・エンジニアリング (CASE) ツールの組み込み機能になっています)、そのような格子上に描くように吹き出しと線を描きました。


図5. 図4をさらにすっきりさせたダイアグラム
図5. 図4をさらにすっきりさせたダイアグラム

乱雑または込み入ったダイアグラムを避ける

詳細な書き込みが多すぎたり、乱雑に見えたりするダイアグラムは、見栄えが悪くなります。1枚の複雑なダイアグラムにすべてを詰め込むよりは、詳しさの程度を変えたダイアグラムを何枚か描いたほうが気が利いています。UMLにいくつかのダイアグラムがある理由の1つは、このことによります。ソフトウェアが複雑すぎるため、単一のダイアグラムではすべての機能をモデル化することは期待できません。さらに、UMLを使用すると、ダイアグラムにパッケージを付け加えることができます (これについては、次週のトピックで採り上げます)。

これに関連して、画面またはページのスペースの使い方を考慮する必要があります。私の考えでは、あるダイアグラムが複数のページにまたがって広がるほうが、1ページで印刷するために、何もかも無理やり詰め込むより良いと思います。必要なだけスペースを使って、分かりやすいダイアグラムを描くべきです。


ダイアグラムの見栄えを良くするための時間のむだ使いを避ける

以上の経験法則は、きわめて広く通用しますが、ダイアグラムの外観をいつまでも調整して、モデル化作業に時間がかかりすぎる危険が常に潜んでいます。これを解決する方法の1つは、そこそこ良い見栄えのダイアグラムを目指すことです。あなたが開発作業にかかわっているかぎり、ダイアグラムが完全である必要はないのです。そのダイアグラムが狙いどおりにアプリケーションをモデル化できていると納得できたら、線が交差しないように吹き出しを移動させて、ダイアグラムを分かりやすくしてください。

私たちの第一目標は、きれいなダイアグラムを作り上げることではなく、システムをモデル化することです。これらの経験法則を利用することにより、あまりよくないデザインを良く見せかけることも可能であることは、十分に注目する点です。たとえば、図2からスタートし、それを配置し直して図1のように描き換え、実際よりも複雑なデザインに見せかけることも可能です (たとえば、上級管理者に対して、作業を行うための時間やリソースを増やすように説得したり、自分が気に入っていない代替案から彼らの目をそらしたりするために)。皆さまの動機が状況に応じて変化するものであるのなら、皆さまが、オフィス・ポリティクスにおける生存競争などではなく、優れたデザインの外観に磨きをかけることに専念できるような、恵まれた環境にあることを願っています。


参考文献

著者について

Scott W. Amblerは、オブジェクト指向ソフトウェア処理の指導、アーキテクチャー・モデリング、およびEnterprise JavaBeans (EJB) 開発を専門とするコンサルタント会社である、Ronin International の社長です。彼は、オブジェクト指向開発に関する本を執筆あるいは共同執筆しています。最近刊行されたものとしては、この記事で要約された主題を詳しく論じた The Object Primer 2nd Edition などがあります。彼の連絡先はscott.ambler@ronin-intl.com およびwww.ambysoft.com にあるサイトです。

不正使用の報告のヘルプ

不正使用の報告

ありがとうございます。 このエントリーは、モデレーターの注目フラグが設定されました。


不正使用の報告のヘルプ

不正使用の報告

不正使用の報告の送信に失敗しました。


developerWorks: サイン・イン


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 利用条件

 


お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。 プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。 お客様の姓名(非表示設定にしていない限り)とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

表示名をお選びください

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

(半角英数字で3文字以上31文字以下にする必要があります)


「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 利用条件

 


この記事を評価する

コメント

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and Web services
ArticleID=245150
ArticleTitle=見やすいUMLダイアグラムの描き方
publish-date=042001
author1-email=scott_ambler@ca.ibm.com
author1-email-cc=

タグ

Help
このタグで、My developerWorks のすべてのタイプのコンテンツを見つけるために検索フィールドを使用します。

スライダーバーを使用することで、より多く(少なく)タグを表示します。

人気のタグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するトップのタグを表示します。

マイ・タグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するお客様ご自身のタグを表示します。

このタグで、My developerWorks のすべてのタイプのコンテンツを見つけるために検索フィールドを使用します。人気のタグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するトップのタグを表示します。マイ・タグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するお客様ご自身のタグを表示します。