ウェブアプリになってから、あまり画面そのものをモデリングする機会がありませんでした。スタンドアロンの GUI アプリでは画面のモデリングが必要となるケースが結構あった（複雑な画面を持つアプリケーションは画面上に配置されるコンポーネントを戦略的に管理しないと開発が成り立たなくなる）のですが、Kodougu を含めウェブアプリを作るようになってからあまり意識していませんでした。所詮画面のあるシステム、そうそう違いがあるとは思えないので、ためしに画面設計に関するモデリングを検討してみました。

---

■ 見た目をモデリングする意味はあるか

まずは一番直感的な見た目をモデリングしてみましょう。

2 カラムのブログを例に挙げてみましょう。左側に新着記事のリストとログインフォーム、右側に記事コンテンツがあるようなデザインを思い浮かべてください。そこからオブジェクト図を起こすと以下のようになるでしょう。



オブジェクト図から以下のようなクラス図を起こします。ロール名が書いていなかったり、多重度 1 の場合の多重度を省略していたり、ちょっと行儀の悪い図になっていますが、以下のような図を得ることができるでしょう。ページの中にカラムがあって、カラムの中にブロック（コンポーネントとかモジュールとか呼ぶ）がある、単純な入れ子構造です。



さて、見た目の構造を図式化する意味はないこともないとは思うのですが、ブログでは敢えて書きだすほどのメリットが今のところ見つかりません。それでも、カラムごとに何かを制御するなら、画面設計の戦略策定に貢献するかもしれません。今パッと例が思いつきませんが。


■ 状態からモデリング

少しアプローチを変えてみましょう。ページの状態からモデリングしてみます。

たとえば、先ほどのブログで、ログイン状態、ログアウト状態があるとします。ログイン状態時に表示されるのは、記事の編集メニューとか「ようこそ、あかさたさん」のようなログインステータスなどとします。ログアウト状態なら、ログインフォームなどでしょうか。オブジェクト図を書いてみます。



オブジェクト図からクラス図を起こします。



一見すると先ほどとそれほど変わらないクラス図が現れました。しかし、この図は画面設計に対する非常に興味深い示唆を与えてくれています。

これは、状態に応じて画面上の Block の可視性を制御する必要があるケースです。この図は、Block（div 要素でしょう）に何らかの方法で、その Block が Visible になる場合の状態を記述することができれば、状態に応じた可視性の制御をエレガントに行う方法が見つかることを示唆しています。
こうした例は、可視性だけではなくイベント制御などにも有効です。（イベント制御の場合、どの状態がどのイベントを受け取れるかという観点でモデリングすることになります。）

適切な方法でモデリングを行えば、画面設計の戦略に有効な情報を得ることができます。プレインな HTML であれば、戦略のバリエーションはそれほど多くはないでしょうが、Ajax、Flash、Silverlight などが普及してくれば、問題の複雑化とともに戦略のバリエーションも増していくのではないでしょうか。

今回は主に画面アプリの保守性を検討しました。他の観点でも、モデリングを行うことはできるかもしれません。また、この例では状態は最初から見つかっているものという前提で書きましたが、複雑な GUI アプリになると、どのような状態が存在するのか見つけだすことそのものが難しかったりします。


■ この例に UML は適切か？

UML は概念的には本問題をカバーしているので、見てわかりやすいかどうかだと思います。私は見慣れているのでわかりやすいのですが、誰にとっても図の見た目が直感的とは限りません。もっと良いモデリング言語が存在するかもしれないので、探してみる価値はあるかもしれません。


■ 結論

複雑な問題に対しては、何らかの整理手段（＝モデリング）が有効だという当たり前のことがわかりました。「複雑な GUI を持つアプリケーションの設計について（Web アプリ編）」にも似たような話題を別の観点から記述しているので、ぜひご参照ください。


■ 宣伝
本記事は Kodougu を使って書きました。