専門家が思わずうなる、モデルの作り方：ETロボコン2008〜チャンピオンシップへの道〜（6）（1/2 ページ）

モデルワークショップの中から、パネルディスカッションの様子をレポート。いま一度、正しいモデリング技術を復習しよう。

[上口翔子，＠IT MONOist]

　ソフトウェアのモデリング技術を競うETロボコンは、競技後に行われるモデルワークショップがある意味メインだといっていい。

　2008年度ETロボコンでは、モデリング全体の質が向上したと前回お伝えしたが、その背景にもこのモデルワークショップの存在があるからだ。本稿では、大会2日目に行われたモデルワークショップの中から、審査員団によるパネルディスカッションの様子をお伝えする。

　来年参加予定の方も、今年残念ながらチャンピオンシップへ進むことのできなかった方も、いま一度モデリング技術を基礎から振り返ってみよう。

審査員団のご紹介（左から順に）

久保秋 真 氏（アフレル）、平鍋 健二 氏（チェンジビジョン）、福田 和也 氏（東横システム）、幸加木 哲治 氏（リコー）、鷲崎 弘宜 氏（早稲田大学／国立情報学研究所）

ETロボコン審査委員長 渡辺 博之 氏（エクスモーション）、太田 寛 氏（マイクロソフト）、中嶋 栄次 氏（豆蔵）、斎藤 司 氏（ニューウェーブシステム）

モデリング技術の見直し

幸加木氏　皆さん、いいモデル作りたいですよね？ 今回は、モデル審査委員が思わずうなるようなモデルを作るための、モデリング技術について解説します。まずはチャンピオンシップで気になった以下5つの使い方を紹介します。

1. アクティビティ図
2. シーケンス図
3. 状態遷移図
4. クラスにおけるインターフェイス
5. ユースケースにおける関連

画像1 アクティビティ図の使い方

　最初はアクティビティ図の使い方です。画像1は、アクティビティ図と書いてありますが、表題を見ると全体のシステムの振る舞いと書いてあります。また、これはタイミングチャートのようにも見えますし、振る舞いというよりも、どちらかといえば処理の流れを示したいようにも見えます。本当に表したいところはどこだろう、というのが気になりました。

画像2 シーケンス図の使い方

　2つ目にシーケンス図の使い方です。画像2の表題では、4つのタスク構成ということでオブジェクト文がタスクで分割されていて、それぞれが状況に応じて振る舞うんだなというのが見てとれました。しかし、肝心の構成に基づいたモデルがシーケンス図になっています。いつの間にか処理と書いてあって、タスク分割と処理のどちらを示したいのか、というのが気になりました。タスク分割ならば一般的にはコラボレーション図で表すでしょうし、処理であれば、このままシーケンス図でいいと思います。

画像3 状態遷移図の使い方

　3つ目に状態遷移図の使い方です。画像3に出ているインコースの場合、システム全体の振る舞いが記述してありますので、スタートから中間ゲート手前はどういう動作をするのかを見て取れます。しかし、応答数を見ると、状態が同じです。中身を見ると少し違いますが、動作を見ると実はほぼ一緒です。もしインコースとアウトコースの違いを示すのでしたら、共通の値の差分で示した方がいいのではないかと思います。そして、本当に表したいところはそもそも何だろう、というのが気になりました。

画像4 インターフェイスの使い方

　4つ目ですが、これは地方大会でも審査員が頭を抱えるくらい気になりました。インターフェイスの使い方です。画像4の例は、右図でインターフェイス走行戦略と書いてありますが、属性があるのに、実現クラスがない、汎化関係になっています。そもそも走行戦略から、ステアリング（黄色の部分）に関連しているので、アブストラクトのようにも見えてしまいます。

画像5 ユースケースの使い方

　最後、ユースケースの使い方です。画像5を参照してください。そもそもユースケースとは、ユーザーが何を要求しているかというのを表す図です。それにもかかわらず、実現レベルが低過ぎます。そもそもの目的であったはずのユーザーの機能要件というのがおざなりになってないかな、というのが気になりました。

　では以上のことを踏まえまして、正しいモデルの使い方についてディスカッションをしたいと思います。

審査員が思わずうなる、モデルとは

太田氏　数名の参加者の方から、状態遷移図って難しいですよね？ という話がありました。その方はインコースとアウトコースで2つのモデルを描いていたのですが、実際にはほぼ同じものでした。私はインとアウトを1つの状態遷移図にまとめてしまって、変化するところはクラス図でまとめてしまう方が好きなのですが、その方は、審査委員が分かりやすいように、インとアウトにあえて分けたのだそうです。

幸加木氏　そもそも本当に表したいことって、状態遷移図で表したかったんですかね。そこが非常に気になります。

太田氏　私が思うに、モデルをきちんと描く、正確に描くことに越したことはないと思うんです。おそらく皆さんの中には、モデルを描いてその後コーディングに入る際に、モデルで時間をかけたのにまたコーディングかよ、と思っている方もいるのではないでしょうか。

　私のスタンスとしては、描いたモデルがそのまま自動生成されて動く環境を使っている方だったら厳格にモデルを描く。そうでなかったら、チームのメンバーでディスカッションをして、誤解がないレベルでいいんじゃないかな、と思います。

幸加木氏　とはいいましても、ツールであろうが、実際に皆さんが議論する場であろうが、正確さをきちんと追究しないと、本当のモデルができないんじゃないかと思いますね。

鷲崎氏　私はどちらかというと中立の意見なので、両方の言い分は分かるんですけれども。この場合は要するに、その参加者の方は、まずは丁寧にインとアウトそれぞれの振る舞いを検証するために、そのようなモデルを採用したのではないでしょうか。

　一方で保守や拡張のしやすさというのは別の品質ですから、別のモデルを使ってもいいんじゃないかと思います。要するに構造のクラス図を使って、インとアウトの違いをこういうふうにしたら変わりますよというのを、そこに結び付くような形で見せてくれればいいと思いますね。

　または幸加木さんがおっしゃるように、そこが具体的にどうなのかという点については、振る舞いのモデルである程度分かると、もっといいと思います。もしかしたら、状態遷移図で表現しなくても単に最初の導入のための分析であれば、無理にモデルで表現する必要はない、という割り切りもありだと思います。

太田氏　まぁそういう方法もありますね。つまり問題は2つあって、状態遷移図を正しく使うという話と、自分が検討したいことをどんな図を使って表現するか、というところだと思うんですね。

　モデルは一度描いておしまいではないですし、最終的なモデルに至る過程で使うモデルというのもまた違います。先ほど少し触れたのですが、例えばいま状態遷移図の話にフォーカスしていますけれども、それを描いている段階で、実はクラス図も変えなければいけないかもしれない。そしてクラス図を見直したら、状態遷移図はもっとすっきりする、というのも当然あるケースですよね。

鷲崎氏　だから適材適所で必要な事柄が最も適している図であればいい。それぞれが両方そろっていることと、リンクされていることが重要かなと思います。

幸加木氏　確かに、この図だけですべてを表現しているわけではない、というのが見えればいいですね。

太田氏　スキルアップのために、両面必要なんだと思うんですね。厳格に記述するタイプと、分かればいいんじゃないの、という両方ですね。

平鍋氏　モデルって2つ面があって、1つは機械とかソースコードに向かって、実行可能な方向にモデルを描いていく。それって実は機械がリーダーのようなモデルを描いていくということです。

　もう1つは、モデルを使って人がコミュニケーションしたり、そもそも何がやりたかったんだっけという同意を取ったり、下流の人にこういう意図で作ってください、と渡すコミュニケーションのための、つまりヒューマンリーダーのようなモデルを目指すという両面があるんですよね。

　ロボコンの大会がいいなと思うのは、1つはこの業界のMDA（モデル駆動型開発）という大きな流れがあって、なるべくモデルのレベルで動作可能なものにしていこう、という工学のアプローチとして非常に正しいからです。もう一方で、今日この場にいる皆さんのモデルを見ると、ヒューマンリーダビリティというところにアプローチをしています。

太田氏　MDAはいま変化の波が押し寄せてきているので、昔みたいにマシンリーダブルだけを考えてやっているモデル駆動というのはなくなりつつあります。最新のMDAは、コストが掛からずに作れる技術が出てきています。ですから、コード自動生成をやるにしても、結局ヒューマンリーダブルで正しいものがモデルとして描かれていないと、自動生成できないんですね。

鷲崎氏　それは、当初のMDAの誤解ですよね？ つまりモデルを描いてコード生成することが、モデル駆動開発であったり、モデル駆動アーキテクチャだったり、モデル上で何かプログラムを書いているような具合で、おかしかった。きちんと人に分かるようなモデルを描いて、それを段階的に機械の方に近づけていく。それで最終的にコード生成でもいいでしょう。というのが、本当のモデル中心、モデル駆動でした。まずは人間が分かる部分を、このETロボコンでできているのはいいことだと思います。