連載
【改訂版】初歩のUML

第１回　まずはUMLのクラス図を書いてみよう

萩本順三
株式会社豆蔵
2003/2/4

読者のみなさま 　ずっとストップしていました「初歩のUML」。第4回をお待ちになっていた方々には、大変ご迷惑をおかけしました。このたび＠IT編集局と協議した結果、「初歩のUML」を12回程度の本格的な連載にすることになりました。そこで、第1回〜第3回の改訂したものを2月中にリリースし、第4回を3月初旬にリリースすることにしました。 　第4回では、モデルのJavaによる実装についてお話する予定でしたが、連載改訂案ではまず、言語から離れた形でモデリングの本質を理解していただき、その後UMLとJavaのマッピングについても取り上げるように考えております。 　本連載では、UMLの表記法を説明するというよりも、モデリングの本質的な目的と意義・効果を通して、必要性を理解していただくことを目標とします。どうぞこれからも初歩のUMLをお楽しみください。 萩本順三

　 UML(Unified Modeling Language：統一モデリング言語）は、フローを書くとソースコードのほとんどを自動生成してしまうような旧来の似非CASEツールの一部のように思っている方も多いようです。UMLは、そのようなものではありません。

　「UMLはオブジェクト指向を使ってモデリングする際に使われる統一的な言語なのです」といっても、何のことかよく分からないですよね。最近書店に行くとUMLコーナーができるくらい、ものすごい人気。過剰ともいえる盛り上がりを見せています。現在はソフトウェア技術者だけがUMLユーザーとなっていますが、今後何年かの間に普通のビジネスマンがUMLを使用することになるでしょう。ビジネスの構造をとらえる手法（ビジネスモデリング）としてUMLはすでに使われはじめているからです。このことは、オブジェクト指向という考え方がビジネスをモデリングする際にも有効であるということを意味しているのです。このように大人気のUMLの正体とは、いったいどんなものなのでしょうか？

　そのことを知るには、まずモデリングとは何かということを考える必要があります。モデリングとは「対象問題について深い理解を得るために、その対象をある目的または観点から眺め、細かくて余計な部分を取り除くことで、本質的な部分だけを浮かび上がらせる方法」なのです。

　UMLは、オブジェクト指向をベースとするソフトウェアの構造をソースコードよりも抽象化した形で構造的かつ形式的に表記する言語を提供します。UMLというモデリング言語を使って頭の中でソフトウェアの構造を整理することが「モデリング」という行為そのものであり、その結果作成された成果が「モデル」です。

　UMLによるモデリングを学んでいくことで、ソフトウェアの構造を、少ない情報量で多くの知識をほかの人に伝えることができるようになります。

なぜUMLを使うのか?

　ここで、ソフトウェア開発において、なぜモデリングが重要かということを説明しましょう。ここで例として挙げるのは、モデリングを使用しないチームとモデリングを使用するチームの特性についてです。

モデリングを意識せずに文字だけで意思伝達を行う開発チーム

図1 文字だけによる意思伝達 　知識の共有ができにくく、問題領域の本質が見えにくいという傾向があります。議論がロジックのみに終始し、複雑さの中で問題を解決しようとします。よって技術が個人に隠ぺいされ、知識の構築ができずチーム全体として最新技術を共有知として構築できません。

UMLによるモデリングを使用するように訓練しているチーム

図2 モデルよる意思伝達 　構造（イメージ）が議論の中心となり、ロジックは個人にできるだけ隠す習慣がついてきます。標準化されたイメージングモデル(UML)によって、問題領域を単純化し最適解を導き出すことができ、単純さの中で問題を解決する習慣を自然と身に付けることができるようになります。開発サイクルにおいては、分析から実装まで直結するオブジェクトモデルを使ってイメージを共有することができます。また、モデリングは個人の技術蓄積にも効果をもたらします。オブジェクト・モデリングによって、自然と抽象化の訓練がなされ、先端テクノロジの普遍概念を見抜き、時代によって変化するテクノロジを、普遍概念からの差分（サブクラス）として無理なくとらえるようになるからです。

　さて、前置きが長くなりましたが、ここからUMLのダイアグラムについて説明していきます。できるだけシンプルに分かりやすく解説しますので、じっくりお付き合いください。

クラス図の役割

　 UMLにはさまざまなダイアグラムが用意されていますが、その中で最も多用される重要なダイアグラムはクラス図です。クラス図は、クラスの内部構造とクラス間の関係をモデリングする際に使われます。例えば、単純なクラス図の例として、会社と社員の関係を考えてみましょう。クラス図は図3のようになります。このモデルは、次のようなことを表しています。

• 社員は必ず会社に所属していること
  
• 社員は1つの会社にしか所属できないこと
  
• 会社には、0人からN人までの社員がいること
  
  

  図3 クラス図

●クラス
　この図には会社クラスと社員クラスが表されています。クラスは四角形で記述し、内部に、上段からクラス名、属性、操作が書かれます。属性と操作は、Javaのプログラムコードに落とされる際には、変数（インスタンス変数とクラス変数）とメソッドになるものです。分かりやすくするために、属性と操作部分を省略してしまうこともあります。

●関連（association）
　会社クラスと社員クラスの間の線は「関連」といいます。関連は、クラスから作成されるインスタンス間のつながり（リンク）の可能性を示すものです。会社には何人かの社員が必ずいます。また、会社に所属する人のことを社員といいますので、両クラスにはクラスの構造上で概念的な関係があるということを示したものが関連の意味です。注意すべきことは、関連は属性として表現されないことです。具体的にいうと、会社クラスの属性に社員リストという属性を入れてはなりません。（図4：会社の属性に社員を書いてはならない）これは、UMLのクラス図の約束事だと思ってください。実際にモデルをソースコードに落とす際には、関連はコレクションクラスなどで実装される属性となります。

図4 会社の属性に社員を書いてはならない

●関連の多重度
　また、線の上の「1」、「＊」は多重度と呼ばれます。この多重度はある程度UMLを理解している人でも根本的な誤解や混乱をしてしまっている人も多いので、少し詳しく説明してみましょう。

　多重度を理解するには、実際にクラスからインスタンスを生成して、自分自身がそのインスタンスになったつもりになるとよく分かります。では、さっそくやってみましょう。あなたは、社員インスタンスの田中さんになったつもりで聞いてください。あなたは、BeanStoreという会社で働いているということにしましょう。そのとき、あなたから会社を見るとBeanStoreという会社が1つだけ見えます。このモデルでは、あなたはどこかの会社に必ず所属していなければならないというルールを元に定めています。なぜなら、どこにも所属しない社員インスタンスはあり得ないからです。また、複数の会社に所属することもできないというルールも前提とされています。つまり、あなたから見た会社という関連相手は必ず1つなのです。このことから社員クラスから見て会社に向かう線の先に「1」を書いてください。

図5 社員から見た会社の多重度

　次は、会社クラスのインスタンスになったつもりで聞いてください。あなたは、複数の社員を雇うことができます。このときの可能性を考えてみましょう。あなた（会社インスタンス）から見て、社員が1人もいないときの会社（A）、社員が1人のときの会社（B）、社員が数名の会社（C）になったときなどが思いつくでしょう。このとき、会社クラスのインスタンスには、0からN個の社員インスタンスがつながる可能性があると考えるわけです。N個の表現はUMLではアスタリスク「＊」を使います。よって、0個からN個は「0..*」と表現し、会社クラスから社員クラスに向かう線の先に「0..*」と書きます。

図6 会社から見た社員の多重度

　ここで、多重度の犯しやすい過ちについて話しておきましょう。複数の会社インスタンスが存在するケースがあり得るからといって図7のように多重度をつけないようにしてください。あくまで、1つのインスタンスに対して相手が幾つつながる可能性があるかということを、それぞれのクラスに対して考えるのです。

　図7は完全に異なるモデルとなってしまっています。いかがですか、多重度の考え方が分かりましたか？

　それでは、ここで問題を出しましょう。図7では、会社と社員のモデルがどのように変化してしまったのでしょうか？ それぞれのインスタンスになってみて相手のインスタンスのつながり関係を想像しながら答えを考えてみてください。

図7 誤った多重度

●関連の多重度問題の解答
　図7のような多重度をつけると複数の会社に所属する社員がいるということになります。例えば、下記の山田インスタンスを見てください。山田インスタンスは、BeanStoreと＠ITに所属しています。もちろん、このような社員が存在することをモデル上で示す必要がある際には、会社側の多重度を「1..*」と示さなければなりません。また、インスタンスの絵に、社員が存在していない会社(豆屋)を追加することで、このクラス図の理解を深めることができます。

図8 複数の会社に所属する社員モデル

　ただ、この表現では複数の会社で同じ社員番号を使わなければななりません。この問題を正しく表現する方法のひとつに、関連クラスがあります。関連クラスについては、この連載の中で取り上げる予定です。

関連の多重度表記

　多重度の表記には次のようなものを使うことができます。

　「*」は、0以上か1以上かはっきりしない時（させたくない時）に使うとよいでしょう。また、多重度を省略することがあります。この場合、まだ多重度が明確になっていないと考えてください。ただ、「1」の省略系として使われることもあります。

多重度	意味
1	厳密に1
*	複数
0..*	0以上
0..1	0 or 1
1..*	1以上
2..5	範囲指定(2から5まで)
1,3,5	1 or 3 or 5
1,3..6	1 or 3 or 4 or 5 or6
表 多重度の表記例

オブジェクト図の役割

　 いままでインスタンスの図を簡単なイメージ図として書いてきましたが、UMLの表記法にはこのようなインスタンスのイメージ図を示すためにオブジェクト図（注）が用意されています。オブジェクト図は、クラス図では表現できにくいインスタンス同士の複雑な関係を補足するときなどに有効です。つまり、オブジェクト図は、クラス図から生成されるインスタンス同士のつながりの事例を示すことでクラス図を補足するために使用されます。

　例えば、図8のインスタンス・イメージをオブジェクト図として示すと図9のようになります。N対Nの分かりづらいインスタンス間のつながり関係が手にとるように分かるでしょう。

　オブジェクト図の四角形の中には、「インスタンス名：クラス名」を書きます。モデルの意味上、インスタンス名をあえて付与する必要がないときは、四角形の中を「：社員」のように省略できます。また、インスタンス名だけで意味が通じる場合はコロンを省いて「田中」と記述します（図10）。文字列にアンダーラインを付けるのを忘れないでください。インスタンス間の線はリンクと呼ばれ、クラス図の関連から作られる実際のオブジェクト同士のつながりを意味するものです。

図9 オブジェクト図

図10 オブジェクト図では、インスタンス名とクラス名の両方を記述した図（左）を省略できる。インスタンス名を省略する場合の記述（中）、クラス名を省略する場合の記述（右）

　 今回は、これでおしまいです。今回はクラス図の基本中の基本となる関連について説明してきました。次回からは、クラス図を中心にUMLの中で初心者が知っておくべき表記やUMLを使ううえで重要な考え方について取り上げていきたいと思います。

【用語解説：オブジェクト】 　オブジェクト指向の世界ではオブジェクトは、クラスやインスタンスの総称として使用されています。たとえば、型（クラス）や実体（インスタンス）がどうのこうのということはどうでもよく、単に「あのオブジェクト、このオブジェクト」と言うときに使われます。UMLでは、オブジェクトというとほとんどがインスタンスの意味として使われているようです。よって、オブジェクト図は、インスタンスの図ということです。

IT Architect 連載記事一覧