実践 ユースケースモデリング ユースケース図はメニュー設計

ICONIXプロセスでは、個々のユースケースを書き始めるまえに、ユースケース図でアクターとユースケースを洗い出していく。ユースケースは、すぐ増えるので扱いやすいようにパッケージ図を使って、整理(組織化)する。

このユースケース図で描いた構造を、実装すると画面上では、たとえば階層メニュー(メニューツリー)になる。アクターごとに別のトップ画面があるサービスなら、ユースケース図のパッケージとトップ画面が対応する。

ユースケースモデリングの最初のステップであるユースケース図作成が、そのままメニューの実装につながる。

ICONIXプロセスは、ここ以外にメニューの詳細設計や検討をする手順はでてきません。ユースケース図とそのパッケージ構成が、そのままメニュー構成、トップ画面構成になります。

その視点で、ユースケース図のレビューをやると、いろいろ課題や疑問がみつかります。あるいは画面プロトタイプの早い段階で、ユースケース図の構造と実際のメニュー階層ととが一致していることを確認する。

ユースケースの構成と、画面のメニュー構成に、用語・グルーピング・順番などの不一致があるのは、問題領域の理解がずれている注意信号です。敏感にキャッチして、早い段階で、不一致をつぶしましょう。


実践 ユースケースモデリング 利用者のアクションを見つける

ICONIX プロセスでは、ユースケースを書く時に、画面の紙芝居、線画、モックアップ、プロトタイプを使うととても役に立つと勧めている。

ユースケースモデリングの段階では、画面の模型には「ボタン」と「メニュー」は全て含めることが重要だとしている。ボタンとメニューが「利用者は○○する。」の○○を見つける手がかりだから、ユースケースを書くための画面の模型には「ボタン」と「メニュー」は全て含める。 アクションを洗い出すためには、実際に動く画面プロトタイプも有効だとしている。

ただし、画面のプロトタイプで、詳細やレイアウト、デザイン、体裁に凝るのは、ユースケース記述には一切役にたたない。むしろ邪魔になる。

多くの場合、線画の画面模型くらいがちょうど良い。短時間で描けるし、ユースケース記述のネタの発見効果が大きい。

短時間で描く、そして「ボタン」と「メニュー」だけは特に意識して全て描き出す。ユースケースモデリングで使う画面の模型は、ここがポイントです。

もう一つ忘れてた。すべてのモデリングに共通の重要ルール。

画面の「名前」はきちんと書きましょう。

曖昧で他の画面でも使えるような名前ではなく、説明的でぎこちなくても良いから、その画面を正しくあらわす名前を見つけることにエネルギーを使いましょう。

モデリングは「名前」の発見作業。

実践 Domain-Driven Design  ドメインモデルを実装する

ドメインモデルは、例えば、UML でクラス図で表現する。

実際に動くソフトウェアにするためにモデルを実体に変換しなければいけない。

・メモリ上に実現するために、Java とか C# とかで記述する。
・ハードディスク上に実現するために、 SQL を使う。
・画面上に実現するために、 例えば、 XHTML + CSS 。
・通信ライン上に実現するために、例えば、XML を使う。

のように、それぞれの装置用の言語で、マッピングが必要になる。

O-R マッピング, O-X マッピング, Http リクエストとオブジェクトのバインド、オブジェクトの Http レスポンスへのレンダリング。

Spring をはじめ、いろいろなフレームワークがでてきて、ここらへんのマッピング作業は、コードを書く必要がどんどん減ってきている。

Ruby on Rails は、モデルを設計してデータベースに実装すれば、他の領域とのマッピングは、自動でやってくれる。

開発全体の中で、ドメインモデルを開発により多くの時間・エネルギーを使えるようになってきた。

問題領域を深く理解し、そこから、良いドメインモデルを創ることができれば、その問題領域の利用者にとって、より使いやすい、より役に立つソフトウェアを提供できるはず。

それがソフトウェアが開発者の使命であり、やりがい。

Eric Evans も "Domain-Driven Design" (「ドメイン駆動設計」) の中で、良い開発者とは、顧客の問題領域を理解することに情熱と喜びを持つ人、という記述があった気がする。

実践 ICONIXプロセス 動的+静的の2層構造

ICONIX プロセスは この図 のように、上段の「動的」なモデリングの流れと、下段の「静的」なモデリングの流れがあり、上下を常に同期させることが成功のコツという考えです。

コードは、下段の静的モデルの流れの最終結果です。
概念クラス図(ドメインモデル)から出発し、属性などを追加して更新したドメインモデルを経過して、操作まで記述した実装クラス図を経て、実際のコードになる。

上段は、この下段の流れを「駆動」するためのモデリングです。
利用者から見るのは画面で、利用者がやることは、クリックやフォームの入力。ソフトウェアは、この利用者のアクションに応答して、画面を表示したりメールを送ったりする。

この上段のシステム利用の動的な側面(ソフトウェアの実行時の動作)と下段のソフトウェアの静的な(構造の)側面をモデリングの初期の段階から、いつも同期をとるので、良いソフトウェアの設計と実装が速く確実にできる、というのがICONIXプロセスの基本哲学ですね。

そのため、
・上段の画面の紙芝居から、下段の初期のドメインモデルを作成する。
・上段のユースケースモデリングでは、常にドメインモデルの用語を意識して使う。

この「ユースケース」と「ドメインモデル」の上下2層構造で、かつ、上下の同期を重視することが、ICONIXプロセスの特徴です。

ドメインモデル(クラス図)だけ睨みながらモデルを改良する、逆に、紙芝居やUIデザインだけでソフトウェアを開発する、どちらも偏りすぎている。ちょうどよいのは、ドメインモデルもやって、振る舞いモデルもやって、いつも両者を同期させること。しかもアジャイルに。

それが空論ではなく、実践としてガイドしているところがICONIXプロセス、「ユースケース駆動開発実践ガイド」を私が気に入っている理由です。

実践 ユースケースモデリング ユースケース記述は2段落?

ICONIXプロセスで、ユースケースを書くとき、基本コースも代替コースも「2段落」以内にする、というガイドラインがある。

これがぴんとこないんで、ちょっとインターネットで調べてみたら、段落(paragraph)のサイズについて、こんなガイドが見つかった。

この説明によると、ひとつの段落は、文が5つか6つくらいが目安らしい。ひとかたまりのアイデアを説明つきで記述すると、このくらいのサイズになるらしい。
アメリカだと、こういうラインティングのガイドラインというのは、結構みんな知っているものなのかしら?

たしかに「ユースケース駆動開発実践ガイド」の原著では、段落は、この程度のサイズになっている。

このガイドを参考にすると、ユースケースの基本コース、個々の代替コースは最大で10程度の文で記述する。それが最大のサイズ。それ以上だったら分割( invokes や    precedes )を考える。

一つの文が「システムは○○する。」「利用者は◇◇する。」と書くことになるから、ひとつのユースケースの基本コースは、一番大きくても、5画面程度の画面の遷移がひとつのユースケース(利用場面)ということになる。

あたりまえといえばあたりまえの話ですね。利用者が一連の操作をする時、スムースに進んだ場合(基本コース)で、5画面というのは Web アプリケーションでは現実的ではないですよね。

そういう意味では、ユースケースのサイズは、段落数より、画面ステップの数でガイドしたほうがわかりやすい気がする。

実践 ユースケースモデリング 場面・登場人物・小道具

ユースケース(シナリオ)は、システムを利用する、ある「場面」の筋書きですね。

ちょっとしたシステムでも、場面数(ユースケース数)は、100くらいにはなる。 ユースケースの大きさはいろいろな考え方があるようですが、ICONIX プロセスは比較的、小さな単位のユースケースでやろうとします。

それぞれの場面の登場人物は、いつも二人。「アクター」と「システム」ですね。アクターのほうは、もっと具体的に「顧客」とか「受注担当者」とかになる。「システム」も「顧客システム」とか「受注システム」とかはいえるけど、実際には「システム」で済ませている。

画面の紙芝居は、利用者だけの筋書きです。いってみれば一人だけの芝居。
ユースケースは、必ず「アクター」と「システム」の二人芝居として記述する。システムが語りかけ(画面を表示)、それにアクターが答え(クリック)、またシステムが語りかける、という二人のやりとり(インターアクション:相互作用)を、書いていく。

こうやって、二人の相互作用を書き出すと、ソフトウェアが何をしなければいけないかが、明確になってくる。いつも、二人のやりとり、相互作用で定義していく、というのが利用者に役に立つ、実際に動くソフトウェアをコツ。これが「ユースケース駆動」の考え方ですね。

ICONIXプロセスでは、この場面の小道具として「画面」オブジェクト、つまり画面そのものや「ボタン」や「リンク」を具体的に書きます。

また、システムが使う小道具としてドメインモデル上の「ドメインクラス」を使います。本物の芝居なら、「店員はポットから茶碗にお茶を注ぐ」というのと同じように、システムは「書籍一覧」を取り出す、「書籍」を取り出す、「注文」を記録する、とうようにドメインクラスを小道具として書くことを徹底する。

「画面」オブジェクトを使ってユースケースを書くことで、ソフトウェアの振る舞い(外から見える言動)がとても具体的に定義できます。

「ドメインクラス」を使ってユースケースを書くことで、ソフトウェアの内部の構造の中核、つまりドメイン層で実現するドメインオブジェクトの実装といつも関連づけながら、ソフトウェアの仕様を固めていける。

私がICONIXプロセス以前に学習したユースケース記述は、実装とはかなり遠い出発点に見えました。しかも、どのくらい離れているか、どうやったらユースケースから動くソフトウェアにたどり着けるが、正直わかりませんでした。

ところが、ICONIX プロセスでは、画面という実体を最初から意識する。そしてユースケースを書く前に、初期のドメインモデルを準備して、ユースケースを書きながら、ドメイン層の実装に近づいていく、というやり方がとても具体的でわかりやすい。

ユースケース記述の要点は、
・画面オブジェクトを小道具として活用する
・ドメインクラスを小道具として活用する
ことですね。



実践 ユースケースモデリング 画面の紙芝居を使う

ICONIXプロセスで、画面の紙芝居やプロトタイプをもとに、具体的な画面名・ボタン名・項目名を使ってユースケースを書くことを重視している。

たとえば、こんな感じで書きます。

基本コース:

システムは○○一覧画面を表示する。
ユーザは○〇を選択してクリックする。
システムは、詳細情報を取り出し、詳細画面を表示する。
ユーザは詳細画面の注文ボタンをクリックする。
...

このレベルで書くには、画面の模型があるとユースケースが楽に書ける。

画面の模型は、プロジェクトの初期は、主要画面のラフスケッチくらいしかないところから初めて、ユースケースを書きながら、対象画面の範囲が広がり、また、画面模型もより実物に近くなっていく。

画面模型の成長の過程は、こんな感じです。

1.手書きの紙芝居
2.線画
3.モックアップ(静止画)
4.プロトタイプ(動画)

1.画面の紙芝居

原文では、 GUI Story Board です。

例えば、こんな感じ
http://mm1projects.wikispaces.com/space/showimage/storyboard.jpg

もともとは、映画、芝居、アニメなどの企画段階で、シナリオをざっと紙芝居にしたもののようです。

ユースケースシナリオ、アクター(登場人物)、紙芝居( Story Board) というのは、すべて、映画や芝居の世界から流用したやり方ですね。(意識的に流用した)

手書きでちゃちゃっと書く感じ。


2.Line Drawing (線画)

「ユースケース駆動開発実践ガイド」の64ページの図3.3が「線画」の例です。
(98ページでは「線図」になっている。訳語にゆらぎがありますね)

あと、画面のレイアウトを四角(直線)で表現したのもこの範疇かな?
http://itpro.nikkeibp.co.jp/article/COLUMN/20060427/236477/?ST=swd-design

1.の手書きの紙芝居に比べると、デザインぽくなっている。
最近は、線画は手書きより、パソコンを使うことが多い。
Enterprise Architect で、ダイアグラムの追加で「その他」から「画面設計」ダイアグラムを選ぶと、簡単に画面の線画を描くツールがでてきますね。

あまりきっちり描きすぎると、開発がかなり進んでいるという誤解をあたえるといけないので、こんな雰囲気で
http://napkinlaf.sourceforge.net/SketchedFileChooser.jpg
まだ、手書きだし、紙ナプキンの裏に描いてみただけだからね
という絵を描く専用ツールがあるようです。

3.モックアップ(静止画)

実物大の模型という意味ですね。ただし動かない。
フォトショップなので実物どおりの画面イメージを作成したもの。

4.プロトタイプ(動画)

HTML で記述し、リンクで、画面が遷移したりする。ここまでくると、ほぼ実物ですね。

1から4の順番で、作ったり、直したりに時間がかかる。
だから、プロジェクトの初期段階では、主要画面の手書きの紙芝居で出発する。
ユースケースを書き始めたら、主要画面だけでなく、エラー画面(代替コース)も検討しなきゃいけないし、紙芝居からは漏れていた一覧画面、詳細表示画面、入力フォームがいっぱいでてくる。

この時、見つけた画面は、手書きの線画でちゃちゃっとスケッチする。実際にやってみると、画面スケッチがあるほうが、ユースケース記述が簡単になり、また内容も豊富になり、レビュー時や実装時の手戻りを大幅削減ができます。

ICONIX プロセスでは、ユースケース記述は詳細な画面設計に近い作業ですね。

実践 ユースケースモデリング ユースケース図

紙芝居や要求の箇条書きから初期のドメインモデルを作成したら、ユースケースモデリングを始めます。

まずは、ドメインモデルからアクタを取り出して、そのアクタが実行するユースケースを洗い出してゆく。ユースケース図ですね。

ユースケースの候補は、ドメインモデリングの過程で「アクション(動詞)」と判断して、隅にとりあえず置いておいたものとか、ドメインオブジェクトに対して、CLGUD ( Create, List, Get, Update, Delete ) する行為とかで洗い出していく。

ユースケースは、たくさん見つかるので、パッケージを使って、グルーピングしながら進める。

ICONIXプロセスでは、ユースケース図を精細に描くことがしません。(時間のムダなのでやるべきではない)
たとえば、アクタとユースケース間の線は重要ではない。ユースケース間の汎化関係や拡張を示す線は、描くべきではない、とガイドしています。
より重要なのは、ユースケースを具体的に書くこと。ユースケース図によるモデリングはほとんど役には立たないよ、と言っています。

実装を考えた時、クラスは、モデルの汎化関係を実装することに意味がある。ユースケースはモデルの汎化は、実装では意味を持たない。(個別に実装する)

だったら、関連するユースケースは、パッケージでまとめれば必要十分だから、汎化モデリングに時間をかける意味はない。

共通のユースケース(の部品)はあるので、その場合は、<> でサブのユースケースを呼び出す。 あるいは、 <> で、ユースケースの実行順番を示す、ことを勧めています。

ICONIX プロセスは、抽象的なユースケースモデリングをとても嫌っています。
実際の画面、ユーザのクリック、システムからの応答(画面やメッセージ)という具体的な内容だけにするべき。
実際の操作の順番を、ユーザガイドのように記述すべき。
ということにこだわっている。

実際にやってみると、ICONIX プロセスでは、ユースケース記述は、ようするに一連の画面操作と画面遷移を文章で記述をすること。
実装方法、つまりMVCのコントローラクラス、あるいは、処理手順を記述したサービス層のアプリケーションロジックを、いきなり日本語で書きだしていくイメージです。

書いてある内容を関係者でレビューすると、ユーザー側は、画面操作をひとつづつ確認していくイメージだし、開発技術者は、すでに、実装を頭にイメージしている状態。
ユースケース記述に使っている言葉は、具体的な画面名であり、ドメインモデルで整理した共通の「用語集」なので、両者がいっしょに話をしても、コミュニケーションギャップがおきない。

ユーザ側の概念と実装側の概念が非常に近いところで、開発を進めることがほんとうにできるんだ、ということを実践しつつあります。



実践 ICONIXプロセス ドメインモデルからユースケースへ

ドメインモデルのこと、いろいろ書いてきたけど、ICONIXプロセスの次のステップ、ユースケースモデリングに進みます。

ICONIX プロセスでは、初期のドメインモデリングが、ユースケースモデリングの準備作業と位置づけています。用語集(初期のドメインモデル)を準備してから、ユースケースを書き始めよう、ということ。

また、ユースケースを書きながら、ドメインモデル(用語集)も随時、更新しながら、いつも、ドメインモデルとユースケースは同期をとるべき、としている。

モデルの動的な側面(ユースケースなど)と静的な側面(ドメインモデル)をいつも連携させることが、良いソフトウェアを、速く、確実に作る秘訣である、というのが、ICONIXプロセスの基本思想の一つですね。

「ユースケース駆動開発実践ガイド」を何度も読み返しながら、実際にやってみると、ほんとうに、このやり方が空論ではなく、実践的であることが実感できます。

今まで、なんどか、ユースケース関係の書籍を使って、要求分析などやってきましたが、正直いってどれもぴんとこなかった。
「ユースケースモデル」だけが浮いた感じになって、実際の開発の手順にはまり込まない。書くだけムダ、という評価だった。

ところが「ユースケース駆動開発実践ガイド」を読んで、ユースケースの評価がいっぺんしました。 ユースケースはとても実践的な設計手段だという手ごたえを始めて感じました。

ICONIXプロセスでは、ユースケース記述に徹底的に画面名やボタン名というUIの実装を取り入れます。一般的なアプローチではないと思いますが、実際にやってみると、ユースケースがとても書きやすくなり、また、早い段階で仕様のモレ・ヌケを発見できるようになりました。

また、準備として用語集(ドメインモデル)を用意して、しょっちゅう同期をとるやり方なので、ユースケースを書きながら、ドメインモデルが成長していく様子が実感できます。

また、ドメインモデルで良い発見や改良があると、ユースケースがすっと書きやすくなる、ということが実際に体験できた。

本を最初に読んだときは、正直に言って、「ドキュメント&レビューかあ?」ちょっとなあ、という否定的な印象でした。

ところが、ほんとうに実践的で、また実際にやってみて1ヶ月後くらいには、手ごたえがでてきた。

ポイントは、
・ユースケースは画面を意識して書くべし
・ユースケースとドメインモデルは徹底的に同期すべし
の2点だと思います。

実践 ドメインモデリング 日本語と英語のマッピング

ICONIX プロセスでは「プロジェクトの用語集」から出発したドメインモデル(概念クラス図)をしだいに洗練し、詳細化し、最後は、実装クラスの自動生成という考え方。

「ユースケース駆動開発実践ガイド」の原著 "Use Case Driven Object Modeling with UML - Theory and Practice" では、最初に登場した "Book" が、Java で class Book { }まで落とし込まれていく。

日本ではどうなる?

「ユースケース駆動開発実践ガイド」では、ドメインモデリングは「書籍」で出発し、予備設計のロバストネス分析までは「書籍」。
実装設計のシーケンス図でこのオブジェクトが突然 "Book" にしている。

プロジェクトの関係者で問題領域の理解を共通にし、深めるためには、やはりモデリングは日本語でやるべきでしょう。 実装は、英語の名詞・動詞を使うことが多いと思う。Java やフレームワーク側が、クラス名もメソッド名を英語だし。

じゃあ開発プロセスのどこで日本語と英語のマッピングをするのが適切だろう。「ユースケース駆動開発実践ガイド」を翻訳した人たちも、議論があって、実装の前と後のところに線を引いたんだと思う。

でも、ラフなモデルから段階的にドメインモデル(クラス図)を成長させていく、ICONIX プロセスの考え方からすると、実装の直前で、大量の日英マッピング作業を発生させるのは実践的ではない。

最初は属性が無い状態からクラス図を書き始め、振る舞い分析(ユースケースモデリング)をしながら発見した属性を追加していく、ロバストネス分析の完了時には、75%程度の属性が定義済み、という ICONIX プロセスのガイドライン。

日英マッピングもこれと同じようなペースが良いと思う。
まず、最初の用語集(2時間で作るバージョン)は日本語だけでよい。
ここからスタートするときに、少しづつ、英語での表記を追加していく。例えば 書籍:Book のように。

英語へのマッピングは、負担が増えるけど、このマッピングをみんなでブレスト(おしゃべり)することで、モデルとみんなの理解を別の角度から検証という効果がありそう。

このやり方だと、ドメイン層のオブジェクトは、ソースコードレビューをユーザ自身ができてしまうような気がする。まあ、やる価値があるかどうかは別として。

calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< July 2008 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM