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

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のコントローラクラス、あるいは、処理手順を記述したサービス層のアプリケーションロジックを、いきなり日本語で書きだしていくイメージです。

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

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



calendar
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM