米持幸寿のJava Issue
UMLの勧め
米持幸寿
日本アイ・ビー・エム
2001/3/2
「Javaの設計にUMLを使うべきですか？」
先日、このような質問を受けた。答えは「もちろん」である。UMLはオブジェクト指向におけるモデリング言語の標準である。UMLがJavaのプログラミングにおいて、なぜ重要かについて考えてみよう。
◆モデリング言語って何？◆
以前、研修のインストラクターが、「UMLはオブジェクト・モデリング言語です」と説明したら、生徒に「モデリングって何ですか」と質問されて回答できない光景を見たことがある。モデリングとは、物事を分析したり、抽象化したりすることを示している。しかし、この問答は「モデリング」という言葉を知らなかった人にとっては分かりやすい説明ではなかったからだろうし、回答できなかったインストラクターは、分かっていて説明したわけではないと思う。
要するに、オブジェクト指向設計において設計図を書くのがモデリングであり、設計図の書き方の標準がUMLである（正確には違うと思うが、おおまかには正しい）。
◆なぜ「Unified」？◆
UMLはUnified Modeling Languageの略である。直訳すると統一モデリング言語である。何が「統一」されたのだろうか。それには歴史がある。
オブジェクト指向を牽引してきた人物が数人いた。有名なのはランボー、ブーチ、ヤコブソンといったところだ。彼らは彼らなりにオブジェクト指向の記述方法を考案してきた。OMT法、Booch法、OOSE法、Objectly法などだ。しかし、問題があった。それぞれの分析方法には特色があり、準備される図の組み合わせが違う。また、クラスの表現方法が雲の形だったり、四角だったりまちまちだったし、なんといっても困ったのは矢印の方向が違っているものもあった。設計図は複数の人が同時に見て共通認識を持つために重要であるのにもかかわらず、見る人によって意味が変わってしまうではないか。
そこで、オブジェクトモデリングツールで有名なRational社が中心になってこれらを統一したのがUMLであり、1997年に発表され、OMGでも標準として認定された。
◆UMLは何を表す？◆
UMLには幾つかの図が存在する。これらはそれぞれが目的を持っており、使い道がある。オブジェクト指向において設計を起こすことをオブジェクト分析とか、オブジェクト設計というが、その過程において、それを図に表すのがUMLの役割である。だれかが、システム要件や機能を分析し「どういうふうにオブジェクトにマッピングしようかな」というのを図で表すのである。これによって、チームで議論するときに共通認識を持つことができる。
●ユースケース図
システムをブラックボックスとして見たときの機能要件を示す。
 |
| ユースケースの例 |
●クラス図
クラスの定義内容を示す。継承関係、フィールドやメソッドの名前や隠ぺい度、インターフェイスなど。
 |
| クラス図の例 |
●オブジェクト図
クラスが実体化（インスタンス化）したときのイメージを表現する。参照関係や生成するのはだれなのか、など。クラス図に似ている。
●コラボレーション図、アクティビティ図、シーケンス図
オブジェクト同士の呼び出し関係を示す。コラボレーション図ではより図的に、シーケンス図ではより時系列的に表す。
 |
| シーケンス図の例 |
●状態遷移図
オブジェクトが持つフィールドなどの「状態」が、オブジェクトが生成されてから消滅するまでの流れの中で、どのように変化するかを表す。
 |
| 状態遷移図の例 |
●コンポーネント図
システムが、どのようなコンポーネント（JARファイルなどのライブラリや、ミドルウェア、オペレーティングシステムなど）と関係して構成されるかを示す。
 |
| コンポーネント図の例 |
◆すべてUMLにすべきか？◆
この質問に対しては、賛否両論あるであろう。システムの議論をするときに、すべての人がオブジェクト指向やUMLのようなテクノロジに強い人とは限らない。
筆者はプロジェクトにおいて、最初にUMLの概説をすることを心がけてきた。しかし、それでも図の見方に悩まれる方は多い。これは仕方のないことである。
例えば、既存システムを利用して新要件を実現するような場合、システム間のデータ連携というのがしばしば行われる。このようなシステム構築では、システム間のデータの流れを、コラボレーション図やシーケンス図で表すことになる。しかし、既存システムにおいてDOA（Data
Oriented Approach：データ指向分析）を長くやってきた技術者は、DFD（Data Flow Diagram）で記述するだけでずっと簡単に理解できる。また、オブジェクトの継承や保持関係をクラス図やオブジェクト図で表すのがUMLの作法であるが、データ項目の関係だけであればER（Entity
Relation）図でも表現は可能だ。UMLで分かりにくいときには、柔軟にほかの表現方法を取り入れることも大切だ。
要するに「UMLは基本」であるが、それを無理に押しつけるのが得策でないこともあることを認識して利用した方がよい、ということである。ただし、二度手間になったとしても、すべてのドキュメントをUMLで準備しておくことは将来のためにはやっておくべきことでもある。
しかし、だからといって、「やっぱりUMLは使わなくてもいいや」というのは誤解である。それでもなおUMLは必要な知識であり、使うべきである。
ただし、UMLはあくまでも「記述様式」である。その前に、オブジェクト指向自体をきちんと理解することは大変重要なことである。
◆UMLの利用はなぜ重要か◆
先に述べたように、分析や設計において重要なのは「意思疎通と共通認識」である。システムを要求する人、考案する人、実装する人は、その設計において共通の認識を持つ必要がある。共通の言語がなければそれは難しいだろう。
フローチャートがJISで制定されたのは、1970年だが、当時もきっと、コンピュータのエンジニアの中には「手順を記述するのにフローチャートを使うべきですか」という質問をした人がいるかもしれない。現代のエンジニアから見れば、「もちろんです」と、皆答えるだろう。標準とはそういうものである。
UMLは、オブジェクトやクラスを記述するための標準である。少なくとも、現在はそうであることは疑いのない事実である。
そして、共通認識のためにもう1つ必要なのは、「正しく伝わること」である。今日現在、オブジェクトやクラス設計を最も正しく伝えることのできる記述方法はUML以外には存在しない。
また、多くのオブジェクト指向開発ツール（特にJavaに関連したもの）では、UMLを基本として設計したシステムモデルから、Javaなどのソースコードを自動生成したり、システムの設定を行ってくれるようなものが数多く存在する。このようなツールを使う場合には、UMLは必須の知識であることは間違いない。
IBM VisualAge
for Java では、Rational
Roseと連携することにより、UMLモデルをJavaのソースコードとしてプロジェクトに取り込む機能を搭載しているし、IBM
WebSphere Business Components のような、EJBを基本としたコンポーネント部品においては、その開発ツールであるStudioにおいて、UMLによってシステムモデルを設計することで、コンポーネント部品同士を連携させるためのJavaコードを自動生成する機能を持っている。
オブジェクト指向の標準語であるUMLを使うことは、ITが（マルチプラットフォームが当たり前という意味において）グローバル化する現代には、ITエンジニアに求められる、1つの必須スキルといって間違いないだろう。グローバル社会において、標準語である英語が求められているのに似ているかもしれない。オブジェクト指向やUMLは、英語と同様、身に付けるのが大変であるが、ぜひとも習得したい知識である。
◆UMLはどうやって書く？◆
UMLは、Rational Roseのような専用ツールで書くのが一番だ。いまどき、手で書くことはまれだろう。会議中に紙に書くときぐらいのものだ。しかし、多くの場合、便利で高機能なツールは非常に高価だ。UMLは、できれば個人で身に付けておいて、使うときには知っている状態になっておきたいものだが、個人で購入するにはそれらのツールは高すぎる。フリーウェアや安価なシェアウェアなども存在するが、一部の図しかサポートしていなかったり、図の形が標準とは若干違うなど課題も多い。
幾つかのドローソフトでは、UMLの記述をサポートしているものもあるが、いわゆるデファクトのプレゼンテーションソフトなどはサポートしていない。また、ドローソフトでUMLを記述する場合、オブジェクトやクラスという概念はそこには存在しないので、クラスを複数個所に記述した場合に、クラス名を変更するとなると、すべての図を間違いなく修正する必要があるなど面倒も多い。
結局のところ、個人的に身に付けるには書籍で学んでドローソフトなどで地道にやるしかない、という状況は当分の間変わらないだろう。できることなら、大手メーカーで「個人使用目的」のための安価なライセンス制度を作ってほしいものである。また、プレゼンテーションソフトでも、部品としてUMLをサポートしていただきたい。
◆UMLフォーラム2001◆
3月21日、22日の2日間「東京ファッションタウンTFTホール」にて、OMGジャパン主催で「UML Forum/Tokyo 2001」が開催される。オブジェクト指向の著名人のセミナーを受講したり、UMLの最新情報を入手するチャンスであるので、足を運んでみてはいかがだろうか。
| Index |
|
第1回
ソフトウェアの部品化は現実になる？(2000/12/19)
|
| プロフィール |
| 米持幸寿 1987年、日本アイ・ビー・エム入社。 ＩＢＭメインフレームOSであるVSE、およびVM関連ソフトウェアプロダクト の保守、 システム無人化ソフトウェア開発を手がける。現在はJava、XML、EJBに関わるプロモーション活動を行っている。 [筆者執筆記事一覧] ・JavaとXMLはなぜ仲良し？ ・Java Servlet徹底解説(JSPとの連携) ・Java Servlet徹底解説(EJBとの連携) |
 |
第2回 20世紀Javaの歴史と21世紀への5つの提案 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
