[UML World 2000 報告]
| ■UML World in New York！ |
 |
さる 6/12(月）から15(木）の4日間、New York は Broadway にて UML World Conference が開催されました。 Keynote や Session のスピーカーとしては、３アミーゴのJames Runbaugh、「リファクタリング」「アナリシスパターン」のMartin Fowler、「UML による Java オブジェクト設計」のPeter Coadといった面々も登場し、扱う話題も記述言語としての UML だけにとどまらず、方法論から、プロジェクト管理、 UML 導入のコツなど非常に広範にわたりました。 |
| ■カンファレンス概要 |
今回の UML World カンファレンスでは、全体のセッションを”Architecture”、”Patterns”、”Project Management”、 ”Software Process”、”UML&Beyond”の５つに分類されていました。セッション数としては”UML&Beyond”が４０%ほどを占めていましたが、その後に”Architecture”、”Software Process”と続きました。どちらかというとばりばりコードを書く開発者向けというよりアーキテクトやプロジェクトマネージャといった人向けの話題が中心でした（実際、あるセッションでのアンケートでは参加者の半数以上がプロジェクトマネージャだったりしました）。
セッションのレベルは UML 導入を考えている人向けに UML ダイアグラムの紹介を行なうような初歩的なものから、UML を利用した Web アプリケーションの開発、XP、パターンの応用といった実践的な話、さらには RUP や Analysis Pattern を扱った高度な話題まで、幅広いレベル設定でしたが、参加者もカンファレンスに参加するくらいの人たちですから、初歩的な話題よりも実践的な話題の部分に興味があるようで、特にパターン、XP 関係のセッションが人気でした。
| ■Keynote & Session |
今回のカンファレンスでは Keynote、Session ともに非常に幅広い話題で持ちきりでした。ここではいくつかの Keynote ＆ Session で印象に残ったプレゼンを紹介したいと思います。
| １． Keynote:”UML Today and into the Future" by James Rumbaugh |
初日の Rumbaugh氏による Keynote で、UML の必要な理由、およびその現状と今後について語られました。
[困難なシステム開発]
-- 複雑化するシステム間インタラクション
-- あいまいな仕様
-- システムの分散化、並行化
-- Real-Time システムへの対応
[それで、どうすればいい？]
-- 開発の第一歩は Modeling
俺たちは Engineer で Cowboy じゃない！ 開発では Modeling をちゃんとしよう！
-- 良い Architecture を！
この世のもので変わらないものはない。
Business や Technology は変化し、Software もそれに対応しなければならない。
しかし、Architecture が良ければそのような変化に耐え得る Software を作ることができる。
Architecture を大切にし、よい Architecture を作ることを心がける。
-- Process をおろそかにしない
-- Component を使いましょう（他の産業がそうであるように、すべてを自分で作る必要はない）
-- Tools を使って効率的に作業をしよう
 |
[UML の今後] UML 1.4 は今年末リリース予定。 UML 2.0 についても現在取り組みが行なわれており、initial proposal が来年の中頃に、リリースが2002年になる予定。 とのことでした。 UML 2 においては、左図のようにメタモデルの見直しや、モデルのバージョニング、および、Real-Time 分野に関する仕様などが盛り込まれる予定だそうです。なかでも Real-Time 分野に関しては OMG でも活発に作業が行なわれており、今年の８月には Execution Semantics が発表される予定で、その後 Time and Scheduling や Reliability and fault tolerance などに関しても検討されるとのこと。また、UML 2 においては、UML-RT, SDL, HDLS などをまとめていくようです。 |
| ２． Session:”The Manager's Role in introducing UML” by Norman L. Kerth |
このセッションでは UML を現場に導入する際にどういった点が問題になり、それをどうやってクリアしていくかに関しての話題が取り上げられました。
 |
[UML の学習曲線] UML 導入にあたっては通常の学習曲線は当てはまらないと考えた方が良い。 通常の学習曲線では導入から知識取得に掛けて、生産性はほとんど変わらないが、その後とあるトリガーで一気に上昇する。しかし、UML の学習においては導入後、” UML は本当に我々にとって正しいツールなのか？”と考え込んでしまう「Chaos」の状態に陥ってしまうことが多く、それにより生産性は一時的に下がってしまう。これは今までに取得した開発テクニックがうまく機能せず、おまけに UML のノーテーション、それにあわせたプロセス等多くのことをマスターする必要があることが原因である。マネージャは開発者がこのステージを超えることで大きく成長することを理解し、そのための支援として仕事の割り当て、スケジューリングなどを柔軟に対応しなければならない。 |
 |
[UML CASEツールについて] 初めは紙と鉛筆で十分。 その後 Visio などの一般的な描画ツールに移行し、UML を十分に使いこなせるようになった段階で CASE ツールの導入を考えれば良い。 最初から CASE ツールを導入するのであれば、その予算を Project Room にまわしチームメンバーのコミュニケーションに気をつけよう。（UML のそもそもの目的がコミュニケーションなのだから、ということでしょうか？） |
| ３． Session:"Walking Through a UML Design" by Robert C. Martin |
ベストセラーとなった”Designing Object Oriented C++ Applications Using The Booch Method”の作者であり、ObjectMentor 社のコンサルでもある Robert C. Martin 氏のセッションです。一応、セッション用のテキストはあるのですが、ほとんどの時間は出席者からの質問に答えるのに使っていました、、、
[実践モデリング入門]
”お天気監視システム”の開発を例に取り、UML によるモデリングの実例が行われました。単純なモデルから始まり、徐々に Observer や Adapter、Bridge
パターンを導入、途中 Refactoring も行いながらどんどんモデルを進化させていくといった内容です。出席者からの”どこまでモデルを作り込む必要があるのか”という問いに対しては、”開発に対する要求によって一番始めのモデルでいい場合もあるし、最後のモデルが必要となることもある。どこまでという基準はなく、要求に合わせて柔軟に考えるべき”とのこと。知っているパターンを総動員するのが良いモデリングではなく、ユーザの要求にあわせて必要なものだけ使うべきだ、というポリシーが実践的で好感を持ちました。
| ４．Session:"Using Extreme Programming with UML" Robert C. Martin |
引き続き、Robert C. Martin 氏のセッションです。なぜか、このセッションは”銀河の大きさってどうやって測るか知ってる？”というソフトウェアとは全く関係の無い話から入りました。おもしろいおっさんやなぁ．．．
[バグフィックスのコスト]
約30年前にBoehm 氏は「システムのバグリカバリコストは、要求時点で $1 とすると実装時点では $1000、テスト時点では $10000になる」と指摘したそうです。しかし、Martin 氏はこの30年で多くの技術的変化が起こり、Software の変更は以前より容易になってきたと述べ、現在ではコストの増加曲線はより Flat なものになっていると指摘。というわけで、それを可能とする開発プロセスの一つとして XP が紹介されました。今回のカンファレンスにおいてはこのセッションのみならず、いたるところで XP の話題に事欠きませんでした。 先週の JavaOne でも感じましたが、XP の人気はすごいですね、、、（ XP の内容に関しては平鍋さんのページをご参照ください）
 |
[XPにおいて重要なのは、、] XP において最も重要なものの一つは”Communication”。各タスクは個人に割り当て、それに関する作業量の見積もりから責任まで各個人に属させるが、UML などを用いてチーム間でシステムの情報を共有するようにし、更には pair work プログラミングを行なう際にパートナーを随時変更していくことで、実装レベルの情報も共有。チームメンバーであれば、誰でもどこのコードでも修正できるようにする。pair work は、”一人がコーディング、一人がテスト”というのではなく、完全に一つのディスプレイだけで、２人が協力してコーディングしなければならない。例えば一人がコードを書いているなら、もう一人はその間にＡＰＩを調べる、という具合に。 |
次に重要なのは”シンプルさ”を保つことで、コメントを書く時間があるのなら、コードをシンプルにすること（Refactoring）に時間を使う方が大事である。これは、しばしコメントは更新されず、誤った情報を与えるもとになるから。開発にあたっては、UML、コード、そして"なぜそのような Decision を行なったのか”を示すドキュメントがあればよく、システムの説明だけを行なうようなドキュメントは重要でない（「Amazon.com のドキュメント見たことある？ UI が直感的なら複雑なドキュメントなんて必要ないよ」）。
また、”Feedback”を大切にし、Feedback をできるだけ早くシステム開発に反映させるためにも、リリースはこまめに行なうのが良い。そのためには繰り返しの単位を小さくし、タスクも小さくし、テストもこまめに行なおう。
最後に重要な点が”Courage”。開発者は勇気を持って、”疲れたら休む”、”全ての決定をユーザに任せる”、”同僚、ユーザに助けを求めることをいとわない”、”既存のコードでも書き換える”、”うまくいかないプロセスは換える”などなど。
さて、もう一点 XP を採用するにあたって重要になるのは、テストです。XP に基づいて開発を行なう上では、テストは頻繁に行なわなければならない。コードを少し変更すれば、即コンパイル＆テスト。極端に言えば1分、30秒毎にテストをする。テストはユーザの視点で行い、決して軽視してはいけない、とのことでした。
| ■展示会 |
| 展示会は期待したほどの大きさではありませんでしたが、そんな中でも UML ツールを販売している会社の元気が良かったです。 Rational 社はもちろんですが、それ以外にも Popkin 社の System Architect、Advanced 社の GD Pro、Anoix 社の Software through Pictures（StP）、などなど。当然といえば当然ですが、どこの会社も Rational 社をかなり強く意識した売り込みで特にチーム開発、XMI への対応などそれぞれの利点を熱っぽく語ってくれました。この他、オブジェクト指向技術に関するコンサルの会社もいくつか出展してました。 |  |
| ■なぜUMLが必要か？ |
上記問いかけがカンファレンスを通じての一つのテーマであり、Keynote、Session を問わずあらゆる機会に語られていました。ここではJames Rumbaugh 氏の行なった Keynote ”UML Today and into the Future”、および Bruce Powel Douglass 氏の行なった Session ”Model-Based Develpment”を中心に、それらをまとめてみました。
| 1.開発にとって重要なのはコミュニケーション |
コミュニケーションには、ユーザとのコミュニケーションと開発者間でのコミュニケーションがあります。ユーザとのコミュニケーションがうまくいかず、システムの要件理解が相互で食い違ってしまえば、システム開発は失敗に終わるでしょう。また、システムの要件定義が明確であっても、開発者間でシステム理解に差があれば、これもまた開発が失敗に終わる可能性が大きくなります。UMLはそのどちらのコミュニケーションにも使用でき、システム開発にあたり強力なツールとなる。
これがUMLの ”One Language”としての存在意義です。
| 2.変更の無い要求など無い |
最初からシステムに関して明確な要求を示してくるユーザはまずいないのではないでしょうか？
また、開発を行なっているその瞬間にでもビジネスおよび技術的な変化は起こるのです。つまり、システムへの要求変更の無い開発はなく、開発においてはそのことを当然のことと考慮しておく必要があります。
そのためにはシステムを記述するにあたって、抽象度を高くしておく必要があります。つまり、システムの抽象度を高め全体像を理解しやすくしておくことで、変更が容易にでき、要求変化に強いシステム開発を行なうことができるのです。これがUMLのもう一つの存在意義です。
| 3.モデルベースの開発を！ |
開発において最も偉大なものは何でしょう？
それはもちろん、ソースコードです。どんなに美しい文言でまとめられたユーザマニュアルが存在したとしても、どんなにすばらしい機能が書かれた仕様書が存在したとしても、コードが無ければまったく無意味です。
では開発においてコミュニケーションをコードベースにして行なうのは正しいでしょうか？
ユーザとのコミュニケーションは言うに及びませんが、開発者間のコミュニケーションさえうまくいかないのではないでしょうか？開発では1週間前に自分で書いたコードが理解できない、ということを経験したことはないですか？ましてや、コードだけを使用して他人とコミュニケーションが取れるでしょうか？（「それに関しては直接コードを見て理解して！」というのはコミュニケーション？）
| Code | Model |
| Localized | Distributed |
| Sequential | Concurrent |
| Isolated | Connected |
次に、抽象度という点ではどうでしょう？
コードの提供する情報のみで、開発者がシステムのハイレベルの構造を理解すると共に、複雑な動的振る舞いをも理解することは可能でしょうか？コードは非常に詳細なレベルでの情報を提供してくれますが、その情報は1次元で直列的であるうえ、システムの情報は複数コードにまたがって存在しています。残念ながらコードだけから開発者がシステムの全体図を理解することは困難です。また開発者がシステムの全体像を掴んでいなければ、システムの要求変更に際して適切な変更が行なえる可能性は低いものとなります。
すなわち、
”コードベースの開発からモデルベースの開発へ”
これが今回のカンファレンスにおける一つのメッセージです。
| ■UMLから一歩先に |
そんなわけで、多少まとめ方に強引さもありますが、このカンファレンスでは単に”共通のモデル記述言語”として UML を使用しましょう、というだけにとどまらず、これからは”コードベース”でやってきたシステム開発の手法そのものを、”モデルベース”にしましょう、そうすればみんな”もっとシアワセに”なれますよ、とUMLから一歩進んだ提案を行なっていると感じました。
ただし、”モデルベースの開発”にしよう、ということは開発手法そのものを見直そう、というわけですから、言うは易く行なうは難し。だれか助けてよ！、ということで必要に応じてツールやコンサルタントも利用しましょう、ということでした。UML を使用したモデルベースの開発で、ユーザも、開発者も、ツールベンダも、コンサルタントも、OGISもみんなシアワセ！！
（最後のツールベンダーからOGISまではともかく、ユーザと開発者がシアワセになれる、というのは本当にこのカンファレンスのメッセージでもありました。一方、Robert C. Martin なんかはあるセッションで質問に答えた際、かわいらしく”（困難に直面したら）僕たち（コンサルが）いるじゃないか！”と言ったりして、ほんと憎めんおっさんです．．．）
| ■最後に：Software を soft に |
最後にもう一つ、今回のカンファレンスで強調されていたのが、”Software は soft”に作りましょう、ということです。これは Martin Fowler 氏の Keynote のテーマでもありました。ここでは Norm L. Kerth 氏の Session の話を引用します。
”システム開発にとって最も重要なのはユーザの要求どおり正しく動くという正確さ、そしてシステムの開発期間（time to market)である。システムへの投資リターンを最大化するには、システムを要求変化を柔軟に、また素早く受け入れられるように開発する必要がある。Software を soft に。そしてそれができるのは、Software Guys、我々なんだ。”
以上、UML World 2000 報告でした。
| © 2000 OGIS-RI Co., Ltd. |
|
