UMLの初心者向けガイド
基本的にUMLとは、その名称が示すとおり言語の一種である。この言語は適切なソフトウェア開発工程と併用することにより、ソフトウェアシステムの設計や仕様作成に関する支援システムとして機能する。こうしたプロセスは“モデリング”と呼ばれている。UMLを使うことで、設計者、開発者、管理者、テスタ、デザイナ、ユーザの間で基本情報の共有化が行われ、ソフトウェアモデルを抽象的な形態で構築することが可能となる。この抽象化こそが、ソフトウェアモデリングの有用性をもたらす鍵となっている。ソフトウェア開発には経歴やスキルの異なる多数の人間が従事するものであるが、UML下でまとめられたモデルを用いることで、新たに構築すべきシステムがどのようなものであるかを、関係者全員が共通のイメージとして把握できるようになるためである。プロジェクト関係者全員が共通のイメージを持つということは、全体像の把握に必要な土台を与えることに他ならず、そうした行為は、集団で進めるプロジェクト作業に不可欠な用語の統一やデッドラインの設定を行いやすくし、また“木を見て森を見ず”的な状況に陥ることを回避しつつ有益な意見交換が行えるようにする。
UMLモデルを構成する大きな要素は、構造（structural）、振る舞い（behavioral）、相互作用（interaction）という3つの図（ダイアグラム）である。ごく大雑把に言うと、構造図は基礎となるソフトウェアシステム（つまりはコード）を規定し、振る舞い図は特定の条件下にてシステムで何が発生するかを規定し、相互作用図は制御フローを規定するものである。これらは振る舞い図のサブセットという位置づけになる。なおダイアグラムの分類法およびそれぞれの名称や重要度は各種のソースごとに異なってはいるが、権威ある分類法としてはUML 2.0の仕様が用いられている。下記の一覧は、UMLの一部をごく簡潔にまとめたものである。
構造図：
- クラス図――クラスとパッケージおよびこれらの相互関係を規定する。開発者はクラスを用いることで、リソースを共有する論理要素の集合として、コードを整理することができる。こうしたクラスはパッケージを用いることで論理的にグループ化できる
- コンポーネント図――システム構造上のコンポーネントが、どのように相互作用するかを規定する
- 配置図――インストール後のシステムがどのような構成となるかのマップを規定する。その中にはハードウェアおよびシステムの詳細も含まれる
- 複合構造図――クラスの内部構造および当該構造で可能な共同作業のモデルを規定する
振る舞い図：
- ユースケース図――ユーザとシステムとの相互作用のモデルを規定する
- アクティビティ図――システムの全体的な制御フローのモデルを規定する
- ステートチャート図――特定の実行過程におけるシステム状態のモデルを規定する
相互作用図：
- シーケンス図――アクターとオブジェクトおよびその他オブジェクトとの相互作用のモデルを規定する。基本的にはタイムラインのことである
- コラボレーション図――オブジェクト間での相互作用と相互関係のモデルを規定する
- コミュニケーション図――オブジェクト間でのシーケンス化されたメッセージ交換のモデルを規定する
UML図の作成は、紙と鉛筆で済ますこともできれば、Rational Roseなどの高機能かつ高額なツールを使用することもできる。オープンソース系ツールも多数存在するが、私のお気に入りはUmbrelloという操作性に優れたUMLエディタで、これは先に一覧したダイアグラムの作図機能を網羅しているだけでなく、ActionScript、ADA、C++、Java、JavaScript、Perl、PHP、Python、Ruby、SQLなど各種コードのエクスポート用オプションも装備している。特にこのツールでは、複数の図を単一のXMLファイルに収めることも可能である。なおXMLファイル化機能に関しては、異なるプロジェクトに属する図を単一のXMLファイルに取り込ませることもできるが、混乱を招く危険性があるため、実用的な観点からはそうした使用法は避けるべきだろう。
UMLにおけるプロトタイピングの概要
通常のプロジェクトにおいて、こうした図の大部分はそれほど利用価値のあるものではない。特に重要度の高いものを挙げるとするなら、クラス図およびユースケース図ということになる。
クラス図を用いると、開発者はシステム設計にのみ集中してプロトタイプ作成を行えるようになる。掲載した1枚目のスクリーンショットは、Umbrelloを用いて作成した簡単なUMLクラス図の一例である。ここではTest_Namespaceというネームスペースが1つのパッケージとして規定されている。このパッケージに付属している（UML的な表現では“含まれる”）のは、Test_Classという名称のクラスである。クラスのノードは、属性（プロパティ）およびオペレーション（関数/メソッド）のマークアップに用いられる。属性については、データ型（文字列、整数、浮動小数点など）、スコープ（定数か変数か）、参照可能範囲（クラスへのアクセスを許すか）に関する設定をすることができる。同じくオペレーションについても、種類、パラメータ（呼び出し元から渡される値）、参照可能範囲、スコープなどの要件を指定できる。このようにUMLでは、現行のオブジェクト指向プログラミング言語で用いられるすべてのコンストラクトをモデリングできるようになっている。ただし、UMLはオブジェクト指向言語だけでしか使えないという訳ではなく、そうした事情はクラス図にのみ該当する。
モデルを用いるその他のメリットとしては、クラス間の関係や他のクラスやオブジェクトに対する依存関係を、図として確認できることが挙げられる。例えば先のスクリーンショットを見ると、クラスAnother_Classにはtcobjというオブジェクトが存在し、それはText_Classというタイプに属することが分かる。この種の情報を図示しておくことは、カップリングを最小限化する方向に寄与し（デメテルの法則を参照）、またリファクタリングのプロセスにおいて役立つはずである。
UML用の追加機能としては、UMLを基にドキュメント作成を行うオプションについても触れておくべきだろう。UmbrelloでUMLをコードとしてエクスポートする際には、各言語に固有のフォーマットに従ったドキュメントのエクスポートも行える。この機能は、手の空いた時間にドキュメント作成を行うつもりで、結局そうした時間を取れないでいるソフトウェア開発者の多くにとって役立つはずである。またプログラムのメンテナンスを行う際に、開発者はこの種のドキュメントを必ず参照しなければならないため、インラインドキュメント機能はコードを読み解く人間にとっても有用に寄与することになる。
開発者にとってユースケース図が役立つのは、アクション関連のプロセスの中でも、中程度以上の複雑なインタフェースを設計する場合である。一般的なユースケース図は“アクター”と“ユースケース”という要素で記述される。ここで言うアクターとは、模式的には人間として表されるが、実際にはユーザやマシンなど何らかの活動を行う存在を示す。同じくユースケースは、模式的には楕円として表され、通常はアクターが行うアクションを示す。
具体的な事例として、2枚目のスクリーンショットに掲載したユースケース図を見てみよう。この場合、AdministratorとUserという2つのアクターおよび、Add User、Delete User、Login、Email Userという4つのアクションが存在している。アクターとユースケースの間は、ごく単純な実線で結ばれている。その一方でアクション間については、ここでのAdd UserとEmail Userのように、特殊な線で結ばれることがある。この図では“Add UserケースはEmail Userケースをextendsする”と表記されているが、これは“ユーザを追加した場合、そのユーザには電子メールを送る”ことを意味している。またこうした図では、アクターとユースケースを結ぶ線の矢印も重要な意味を担っている。例えばこの図における2つのアクターを結ぶ線に注目すると、その一端には矢印が描画されているが、この場合は“AdministratorもUserの1人として扱われる”ということを示している。
ユースケース図を用いたモデル作成では、システム運用時に生じる可能性のあるすべてのシナリオをマッピングしておくことが理想である。事前にすべてのシナリオを網羅するプロセスを経ておくことは、システム構築時における錯誤や不確定要素を大幅に削減する方向に寄与する。ユースケース図は有用性能試験を施す際にも役立ち、これらは実際のユースケースと仮想的にリンクする形で使用される。なおユースケース図とユースケースとは異なる存在であり、ユースケース図とはユースケースに対するマップとして使用されるものである。
最後にいくつか注意を喚起しておこう。その1つは「単純なシステムをわざわざモデリングするな。そんな手間をかけても、たいていは費やした時間に見合うだけのメリットは得られない」というものである。また「どんなシステムであれ、モデリングに時間をかけすぎるな。どれだけ考えても、見落としは出てくるものだ」ということも言える。私の場合は経験則として、1人の開発者が半日以下で完成できるプロジェクトについては正式なモデリングを行わないことにしており、また最初の要件がすべて満たされた段階でモデリングは終了させ、モデリング時に要件を追加したり過度に複雑化させないようにしている。またテクノロジに惑わされないように注意することも必要で、例えばモデリング用ソフトウェアなどは無くても済むもので、その種の作業はホワイトボードを使うだけでこなせるはずである。
モデリング用ソフトウェアが便利な存在であることは確かだが、ソフトウェア設計にまつわるすべての問題を解決してくれる存在でもない。必要なのは、それを考えられる人間と適切な方法論を用意することである。いずれにせよ、ここで解説したUMLやモデリングのプロセスを上手く使いこなすことができれば、多くのソフトウェアプロジェクトにおいて、品質、完成度、スケーラビリティの向上をもたらし、開発時間の削減を達成することができるだろう。
NewsForge.com 原文
