ユースケースの推敲

UC図をOO開発経験の浅い者が作成した場合とても読み辛いものとなる。UC図は様々な目線の者が読む文書である。そのためその様々な目線に耐えうる記述でなければならない。すべての関係者にわかるような記述が必要ということだ。だが、経験の浅い者はその記述が概してできない。彼らにとって特に厄介なのはシナリオの作成である。

ユースケースシナリオは「文」の羅列であるがこの「文」は基本「SVO」「SVOO」「SVOC」で表現されるのが望ましい。S、つまり主語は「アクター」と「システム」しかない。OはSがアクターの場合は画面のウィジェットつまりテキストボックスやチェックボタン等の入力項目やボタンやリンク等のイベント項目となり、システムの場合はドメインとなる事が多い。そしてVはその項目に対する振る舞いとなる。例えば

●アクターは、メールアドレスを、入力する【SVO】

という具合だ。文章は冗長である。ゆえに見やすさを兼ねて抽象化する必要がある。それが多くの人にわかりやすい記述となるからだ。上の例であればこういう表現となる。

●入会希望者はシステムにメールアドレスを登録する

これはユーザ視点の文である。だが最終的にはSVO形式となる。2はモデラーがクライアントとラフなレベルの要求確認をする際に重要だがそれが済めば重要ではなくなる。開発者は2を読めないからだ。だが1は読める。だから最終的には1が成果物となる。

重要なのは最初から1ができるわけではないということだ。原型は2でありそれが1になる。その変換がモデラーのタスクとなる。

1のようなユースケースシナリオの最終形は標準的な書き方がある。この例は「ユースケースからテストケースへの追跡可能性」にも示されている。一部抜粋しよう(誤植修正)。

このオンライン書店 (Online Bookstore) プロジェクトでは、ユースケースの基本フローは注文で、次のようになります。
B1 ユーザーがブラウザーに Web サイトのアドレスを入力します。
 システムがログイン・ページを表示します。
B2 ユーザーは電子メール・アドレスとパスワードを入力します。
 システムは正しいログインを確認し、メイン・ページを表示して、検索文字列の入力を要求します。
B3 ユーザーは検索文字列 (書名の一部) を入力します。
 システムは検索条件と一致するすべての本のリストを表示します。

B4 ユーザーは本を選択します。
 システムは本の詳細な情報を表示します。
B5 ユーザーはその本をショッピング・カートに追加します。
 ショッピング・カートの内容がユーザーに表示されます。
B6 ユーザーは「チェックアウト」オプションを選択します。
 システムは配送先住所の確認を要求します。
B7 ユーザーは配送先住所を確認します。
 システムは配送オプションを表示します。
B8 ユーザーは配送オプションを選択します。
 システムはどのクレジットカードを使用するかをたずねます。
B9 ユーザーはシステムに登録されているクレジットカードを確認します。
 システムは注文の最終的な確認を要求します。
B10 ユーザーは注文を確定します。
 システムは確認番号を表示します。

・・・

注目すべきはB1からB10までの文が単純であることだ。殆どが「SはOをVします」「SがO1をO2にVします」となっている。B2も文が直列でつながれているだけだしB5も能動態に直せばSVOで表現される。ここでより明確にSVOであることを示そう。

B1

【ユーザー】が【ブラウザー】に【 Web サイトのアドレス】を【入力】します。

システム】が【ログイン・ページ】を【表示】します。

B2

【ユーザー】は【電子メール・アドレスとパスワード】を【入力】します。

システム】は【正しいログイン】を【確認】します

【システム】は【メイン・ページ】を【表示】します

【システム】は【検索文字列の入力】を【要求】します。

B3

【ユーザー】は【検索文字列 (書名の一部) 】を【入力】します。

【システム】は【検索条件と一致するすべての本のリスト】を【表示】します。

B4

【ユーザー】は【本】を【選択】します。
システム】は【本の詳細な情報】を【表示】します。
B5

【ユーザー】は【その本】を【ショッピング・カート】に【追加】します。
【システム】は【ショッピング・カートの内容】を【表示】します。
B6

【ユーザー】は【「チェックアウト」オプション】を【選択】します。
【システム】は【配送先住所の確認】を【要求】します。
B7

【ユーザー】は【配送先住所】を【確認】します。
システム】は【配送オプション】を【表示】します。
B8

【ユーザー】は【配送オプション】を【選択】します。
【システム】は【どのクレジットカードを使用するか】を【たずね】ます。
B9

【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。
【システム】は【注文の最終的な確認】を【要求】します。
B10

【ユーザー】は【注文】を【確定】します。
システム】は【確認番号】を【表示】します。

このようにすべて叙述的な文に修正すればかなり明確な意味となる。ただそうならない文もある。修正済のB8を見てみよう。

【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。●【システム】は【どのクレジットカードを使用するか】を【たずね】ます。

これを見て皆さんは違和感を覚えるだろうか。1文目は素直に読めばこれは、画面に「登録されているクレジットカード」が表示されており、それをユーザが目視で確認するという意味だ。では2文目はどうか。システムが尋ねるとはどういう意味か。そもそもなぜアクションをユーザが起こしてもいないのにシステムに処理が移動したのだろうか。

実はこの2文目の主体はシステムではない。ユーザだ。処理がユーザからシステムに移動していない。ユースケース記述としてはトリッキーだ。私なら次のように書く。

●【アクター】は【クレジットカードを使用するか】を【たずね】ます。

 

これはアクションではない。ユーザ側からシステム側に処理が移動する条件はユーザがボタン押下などのアクションを起こさなけらばならない。ところが目視はアクションではない。ではこの次の行にあるのだろうか。ところが次の文はこうなっている。

【システム】は【注文の最終的な確認】を【要求】します。

システムに処理が移動している。これはいったいどういう事か。

「確認する」の意味は通常3つである。

①「目視する」

②「目視確認し▲▲ボタンを押下する」

③「確認ボタンを押下する」

では上の例はどれに相当するのか。

【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。

●【システム】は【どのクレジットカードを使用するか】を【たずね】ます。

 

●ユーザーはシステムに登録されているクレジットカードを確認します。(【ユーザー】は【登録されているクレジットカード】を【確認】する)

これは登録されたクレジットカード情報が画面に表示されていることを確認するという意味だ。だがこの「確認」は「目視」ではなく「確認ボタンを押下する」と云う意味である。これは次行のアクティビティからわかる。

システムは注文の最終的な確認を要求します。

察し、そこから確認ボタンの存在を推理できる。その上で、カード情報がどのような構成になっているかをドメインモデル図、概念モデル図を参考にしながら別紙にでも書き留めておかないとこのユースケースレビューを終わらせることはできない。

こうした他のモデリングを並行しながらユースケースを検証をしていく過程で、ベンダーとクライアントは様々なことを学習していく。不整合、記述不備、曖昧記述は直されユースケースは徐々に推敲されていく。その間に新たなアイデアも浮かぶ。ならばそれも取り込めばよい。そのレビューが最適化につながる。これを推敲と呼ぶ。 

推敲作業はユースケースシナリオが完成してから2回行われる。その際に1回目の推敲がおわるまで、設計作業は開始すべきではなく、2回目の推敲が終わるまでは実装を始めるべきではない。

 <修正中>

ユースケース

OOAでは機能要求を「ユースケース図」に記述する。
ユースケース図」にはユースケースの説明文として以下のような「ユースケース記述」が付与される。主処理フローはメインフローに記述されるがケースにより代替フロー、例外フローも記述される。またフロー開始時の条件は事前条件、終了時の条件は事後条件、ビジネスルールなどは事前事後に適用される不変条件として記述する。

なお、ユースケース図の各要素(特にフローと条件)はイテレーティブに記述が追記・変更されることが前提である。

ユースケース名】商品を購入する
【概要】本ユースケースは、Web上および店頭で商品を購入する際に呼び出される。店頭では、店員を通じて本ユースケースが利用される

【アクター】

  • Webユーザー
  • 店員(オペレータ)

【事前条件】

  • アクターがログイン済であること 

【メインフロー】 

  1. アクターは、購入したい商品のジャンルを選ぶ
  2. システムは、選択されたジャンルの商品一覧を返す
  3. アクターは、商品を選ぶ
  4. システムは、商品の詳細情報(説明、金額、写真)を返す
  5. アクターは、この商品でよければ商品購入手続きに入る

【改訂版】初歩のUML:第8回 顧客の要求をユースケースに反映させる - ITmedia エンタープライズ参照

 ユースケースユースケース名を決めた時点で粒度が決まるが、その粒度を小さくしすぎて機能数が増大してしまう落とし穴がある。これを回避するため「ユーザの認識できる言葉」でユースケース名をきめていく必要がある。

 機能単位をユースケースにするな

 ユースケースの単位を、機能分割の感覚で作ってしまいます。そのようなユースケースは、ユーザーの視点から見ると時系列を伴うものが多く、時系列を表すすべがないユースケース図には不適切であり、また、ユースケースの個数が膨大になってしまいます。

【改訂版】初歩のUML:第8回 顧客の要求をユースケースに反映させる - ITmedia エンタープライズ参照

 ユースケースは「技術」「性能」「品質」に依存しない。DBが変わったりFWやPGLがかわってもユースケースには影響しない。

データベースがどこにあるかなどは問題ではない

 よくある誤解が、例えば「商品を登録する」というユースケースの中にデータベースが存在すると勘違いしてしまうことです。この勘違いから、「商品を参照する」というユースケースに関連を持つアクターからも「商品を登録する」に関連を引いてしまいます。

【改訂版】初歩のUML:第8回 顧客の要求をユースケースに反映させる - ITmedia エンタープライズ参照

ユースケースには変更されやすいホットスポット、変更されにくいコールドスポットがある。そしてコールドスポットがあるユースケースにはBRが含まれることが多い。逆にBRがないユースケースホットスポットとなりやすい。優先順位が高いのは前者だ。ロバストネス分析でBRの数を数えればそれが開発優先順位の指標となる。勿論数が多い方が優先順位が高い。変わりにくい、またはビジネスにとって重要なユースケースから始めるのだ。

最後に洗い出されたユースケース全体を眺めて粒度をそろえる。

ビジネスルールの概要

ビジネスルールはユースケース抽出と平行で分析する。

このルールはドメイン分析にて抽出され最終的にはドメインクラスとして定義される。ビジネスルールの概要には次のように定義されている。

ビジネスルールとは、ビジネスの1つの側面を定義あるいは制限するもので、ビジネス構造をはっきりさせたり、ビジネスの振る舞いに影響を与えたりするために作成します。ビジネスルールでは、アクセス権限に関する事柄に着目することがよくあります。たとえば、教授は、自分が教えているゼミを受けている学生の点数を入力したり修正したりすることができますが、他のゼミの学生の点数を入力することはできません。ビジネスルールには、ビジネス上の計算が含まれることもあります。たとえば、パーセントで表した学生のゼミの評価(91%など)を、文字で表した評価(A-など)に変換する方法などです。ビジネスルールの中には、組織の方針に着目したものもあります。大学の方針として、同じ学期のうちに2つ以上のコースで不合格になった学生を1年間停学にするというものがあるかもしれません。

ビジネスルールのロジックはビジネスロジックの粒度に比べ小さい。そのためしばしばエンティティに付与される。例えば以下のようなビジネスルールがあるとしよう。

ビジネスルールの例 (要約形式)

  • BR123 教授は学生の評価をつけることができる。
  • BR124 教授から権限を認められた助手は学生の評価をつけることができる。
  • BR177 数値の評価と文字の評価を変換するための表。
  • BR245 修士過程には論文の提出を含まなければならない。

全てのルールは「BR」に定義され「BL」より呼び出される。依存性は「BL→BR」。「BR」は「BL」に依存しないが「BL」は「BR」に依存する。

しかしこれで正しいのだろうか。さらに調べたところ詳細なルールが分かった。 

名前:

教授は学生の評価をつけることができる

識別番号:

BR123

概要:

自分だけが教えているゼミの学生の評価を、教授だけが最初に入力したり変更したり削除したりすることができる。それかできるのは、ゼミが行なわれている学期の間だけである。

例:

「生物301 ガンマ放射線の先進的利用」を教えているBruce博士は、そのゼミに登録している学生全員の評価をつけることができるが、Peter博士が教えている「生物302 クモ類に対する放射線の影響」に登録している学生の評価をつけることはできない。

 

 

ロバストネス図作成におけるプラクティス

ロバストネス分析を行うにあたり有効なアジャイルモデリング(AM)のプラクティスを抜粋。 

基本プラクティス

  • 利害関係者の積極的な参加:これはXPの「オンサイトの顧客」を拡張したものです。「オンサイトの顧客」とは、開発対象のシステムに関する情報を提供したり、要求とその優先度について適切でタイムリーな決断を下すことができる権限と能力を持つユーザに、現場にいてもらう必要性を述べたものです。AMでは、XPのプラクティス「オンサイトの顧客」を拡張して、直接のユーザやその上司や上級の管理職、運用担当者、サポート(ヘルプデスク)担当者といったプロジェクトの利害関係者に、プロジェクトに積極的に参加してもらうことを提唱しています。たとえば、上級の管理職に資源に関してその場で判断してもらったり、上級の管理職にプロジェクトに対する公的/私的な援助をしてもらったり、運用やサポートの担当者に、それぞれの担当職務に関係する要求やモデルの作成に積極的に参加してもらったり、といったことが考えられます。
  • 複数モデルを並行して作ろう:モデルの種類ごとに長所/短所があるため、1つのモデルだけでモデリングのニーズを満たすことは不可能です。たとえば要求を調査しているときには、いくつかの本質ユースケースやユーザストーリー、1つの本質UIプロトタイプ、いくつかのビジネスルールを作成する必要があります。アジャイルモデリングでは、「他の成果物に移ろう」のプラクティスと組み合わせることで、一度に1つのモデルに集中するよりも複数のモデルを並行して作成する方が、ずっと生産性が高くなることがよくあります。
  • 中身はシンプルに作ろう:要求、分析、アーキテクチャ、設計といったモデルの内容は、プロジェクトの利害関係者のニーズを満たせる範囲内で、できるだけ簡単にするべきです。つまり、正当な理由なしにモデルに余分な情報を付け加えるべきではありません。システム監査機能を追加するという要求がなければ、その機能をモデルに追加してはいけません。依頼されたときに(依頼があった場合にだけ)実際にその機能を追加できると信じる勇気を持ってください。
  • モデルを公開しよう:モデルは公開すべきです。多くの場合は、「モデル掲示用の壁」や「不思議の壁」と呼ばれるようなものに掲示します。モデルの掲示によって、隠しごとがなくなり、チームのメンバーやプロジェクトの利害関係者が最新のすべてのモデルをすぐに見ることができます。その結果、チームの「オープンで正直なコミュニケーション」が促進されます。モデル掲示用の壁とは、誰にでも見えるように自分のモデルを掲示する場所で、開発チームやプロジェクトの他の利害関係者からアクセスできるところでなければなりません。モデル掲示用の壁は、アーキテクチャのダイアグラム用に指定されたホワイトボードや、物理データモデルをプリントアウトしてテープで貼り付ける場所のように、物理的なものになる場合もあるでしょう。また、スキャンした画像を載せる内部的なWebページのように、仮想的なものの可能性もあるでしょう。
  • 少しずつモデリングしよう:大規模な仕事を小さな部分に整理して、順に、できれば数週間から1、2か月の間隔でリリースするというインクリメンタルな開発では、ソフトウェアを早くユーザの手に渡すことができるため、アジャイル(機敏)さが向上します。
  • 他の人々と一緒にモデリングしよう:「目的を持ってモデリング」を行っている場合、自分が何かを理解するためにモデリングをしていること、アイデアを他人に伝えるためにモデリングをしていること、あるいはプロジェクトの共通の構想を作り上げようとしていることに気付くことがよくあります。これはグループでの作業であり、複数の人の意見を効果的に組み合わせる必要があります。プロジェクトにとってきわめて重要な一連の中核モデルを作成するためには、開発チーム全体で協力する必要があることに気付くことも多いでしょう。たとえば、システムのメタファ(喩え)やアーキテクチャを構築するには、グループでモデリングをして、皆が合意し、しかもできる限り簡潔である解決策を作り出す必要があります。ほとんどの場合、これを行うためのもっともよい方法は、その問題について徹底的に人と論ずることです。
  • コードで確かめよう:モデルとは考えを抽象的に表現したものであり、開発対象の1つの側面を正確に反映するべきものです。しかし、そのモデルで大丈夫なのでしょうか。それを判断するには、コードを書いてモデルを確かめなければなりません。請求先住所の情報を入力するHTMLページの下絵を書いたとしましょう。それをコーディングして、その結果のユーザインターフェースをユーザに見せ、フィードバックをもらってください。複雑なビジネスルールを実装するロジックを表したUMLのシーケンス図を書いたのであれば、テストコードとビジネスロジックのコードを書き、テストを実行して、正しく動くことを確認してください。多くのプロジェクトで一般的になってきている反復型のアプローチでソフトウェアを開発するときには、モデリングは行わなければならない数多くのタスクの1つでしかないことを忘れないでください。少しモデリングをし、少しコーディングをし、そして(これが特に重要ですが)少しテストをするのです。
  • もっとも簡単な道具を使おう:大多数のモデルは、ホワイトボードや紙や、あるいはナプキンの裏にでも描くことができます。それらのダイアグラムを保存したければ、デジタルカメラで写真を撮ることもできますし、単に紙に書き写すこともできます。これで問題がないのは、ほとんどのダイアグラムが使い捨てだからです。それを描いて問題点をじっくり考えることに本当の価値があるのであって、問題が解決すればそのダイアグラムにはあまり価値がなくなります。そのため、ホワイトボードとマーカーというのが多くの場合にもっとも適したモデルを作る道具になります。重要なプロジェクトの利害関係者に見せるダイアグラムを作成するには描画ツールを使い、コードの生成などプログラミング作業に役立つときにだけモデリングツールを使ってください。次のように考えるとよいでしょう。単純なモデルを作成している場合、その多くは使い捨てです。というのも、「理解するためのモデル」を作成しているなら、問題を理解してしまえばそのモデルをとっておく必要はおそらくないからです。だとしたら、複雑なモデリングツールを利用する必要はありません。

基本プラクティスで最も重要なのは「利害関係者の積極的な参加」だ。ロバストネス分析には利害関係者の知恵が必要だ。その実現のためにこのプラクティスを遵守することはプロジェクトを成功させる可能性を高めるだろう。

追加プラクティス

  • 一時的なモデルを捨てよう:作成したモデルの大部分は、一時的/作業モデルです。つまり、設計の下絵、あまり正確でないプロトタイプ、インデックスカード、アーキテクチャおよび設計の代替案などといったモデルですが、これらはすでに目的を果たしていて、今後価値を持つものではありません。モデルはすぐにコードと一致しなくなりますが、それはあたりまえのことです。そこで、プロジェクトにとって価値があるのならモデルを同期させるか、モデルを更新するための労力に見合うだけの価値がない(費用対効果はマイナス)ためモデルを廃棄するかの判断を迫られることになります。
  • 話すためにモデリングしよう:モデリングを行う第2の目的は、チーム外部の人とコミュニケーションしたり、取り決めモデルを作成したりすることです。いくつかのモデルの利用者はチーム外の人なので、ワードプロセッサやお絵かきツール、あるいは高度なモデリングツールといった電子ツールを使い、時間をかけてモデルをきれいに整える必要があるかもしれません。
  • 理解するためにモデリングしよう:モデルを適用するもっとも重要な目的は、問題空間を検討したり、システムの要求を識別・分析したり、いくつかの設計案を比較して要求を満たす中でどれがもっとも簡潔な解決策になりそうかを判断したりすることです。このプラクティスを実行することで、クラスのライフサイクルや画面間のフロー、目的を果たせば捨ててしまうダイアグラムといった、ソフトウェアの1つの側面に焦点を当てた小さく簡潔なダイアグラムを作成することができます。

この追加プラクティス「一時的なモデルを捨てよう」「話すためにモデリングしよう」「理解するためにモデリングしよう」は重要だ。

ロバストネス図が「ロバストネス図以外のモデルの起点」となるためには関係者全員がこのモデルに対して「口を出す」必要がある。

例えば全ての開発者はこの図をベースとして設計する。DB設計者ならER図やテーブル設計書を、画面担当者なら画面遷移書やUI定義書を、プログラマならビジネスロジックドメイン、DAOを「ロバストネス図をベースにして」作成しなければならない。利害関係者ならこのモデルが現実化されたシステムを利用しなければならない。

そのためには図を理解しなければならない。不明点があれば質問をしながら理解を深め、問題があれば話し合い時には変更を決断しなければならない。この開発手法はロバストネス分析駆動開発といっていい。我々はこうした分析作業をしながら各モデルに適切な名前を付け、それを覚え、その意味を理解する。全ての設計はこの図の理解なしでは立ち行かない。そして最適化のために話し合う。そのために各人が積極的に参加する必要がある。

 

 

ロバストネス分析

ロバストネス図とは何か。

ロバストネス図の概要にはこうある。

『In Use Case Driven Object Modeling With UML』においてDoug RosenbergとKendall Scott(1999)は、ロバストネス分析という技法を説明しています。その基本となる考えは、ユースケースのステップを分析することで、その中のビジネスロジックを検証し、それまでに分析した他のユースケースと統一の取れた用語を使っていることを確認できるというものです。言い換えると、ユースケースが十分にロバスト(堅牢)で、開発対象のシステムの利用要求を表現していると確認できるということです。もう1つの用途として、ユースケース内で呼び出されるロジックをサポートするオブジェクトやオブジェクトの責務の候補を識別するために使うことができます。これは事実上、UMLシーケンス図やUMLクラス図といった他のダイアグラムへの橋渡しとなります。

ユースケースシナリオはホワイトボードやノート、iPad上でロバストネス図として表現することが可能だ。ステークホルダーの目の前でユースケースシナリオに従ってこの図を導き出す。導出手順は以下の通り。

  1. 画面や帳票といった主ユーザインターフェース要素ごとにバウンダリ要素を追加する:ユースケースの中には、アクターがボタンを押したりフィールドを編集したりといったレベルで非常に詳細に書かれているものもありますが、私はもっと高いレベルで記述し、詳細は含めない方が好きです。ただしこの図には「学生作成アイコン」を記述することにしました。後で考えると、このバウンダリクラスには「デスクトップ」と名前をつけた方がよかったかもしれません。しかし図は変更しないことにしました。私はAMの「困った時だけ更新しよう」のプラクティスに従っていて、正直なところこの小さな問題は修正するほど重要ではないからです。ユーザインターフェースフロー図を作成するのであれば、これらのクラスはおそらくその図にも書かれることになるでしょう。
  2. モデリング対象のシナリオのプロセス全体を管理するコントローラを追加する:図2では「大学に登録する」という要素がこれにあたります。見れば分かるように、この要素は図をまとめる役割を果たしています。設計時には、この要素はおそらく、クラスとして、あるいは1つ以上の操作として、あるいは何らかのワークフローエンジンがアーキテクチャ全体の中に含まれているならそれによって、実装されることになるでしょう。
  3. ビジネスルールごとにコントローラを追加する:これによって図上でビジネスルールが明確に示されます。ビジネスルールをまったくモデリングせず図を簡潔にしておく人もいますが、そうすると図から非常に重要な情報が抜け落ちてしまうことになります。両方のやり方を試してみて、自分に合った方法を選んでください。
  4. 他の複数の要素と関係するアクティビティに対してコントローラを追加する:ビジネスルールおよび「学生」エンティティと相互作用している「学生を作成する」という要素がこれにあたります。
  5. ビジネス概念ごとにエンティティを追加する:「学生」と「学生授業料」がこれにあたります。概念モデルを作成するのであれば、これらの要素はおそらくそこにも書かれることになるでしょう。
  6. シナリオにユースケースが含まれてればそれを追加する:私は、「ゼミに登録する」のユースケースの呼び出しを、ユースケースの標準のUML表記法で書くことにしました。ユースケースをコントローラとして書く方法もありますが、私の経験では、プロジェクトの利害関係者にとってはあまり分かりやすくないようです。AMの「見栄えより中身」の原則を思い出して、自分の状況にもっとも合った方法を選んでください。

 

図2. ロバストネス図の例

f:id:chungzee:20170430032857p:plain 

 ロバストネス図は組み立てられたら「はい、終了」ではない。終了までには3つのステップを踏まなければならない。

モデラーはまずメンバーを招集して「会議」を催す。そこで参加者の認識を確認する。認識が違えばその原因を追究し認識の統一を図る。ロバストネス図はオブジェクト図の特殊な形態である。オブジェクト図はオブジェクトを描いた図でありオブジェクトとは「名前を持つ何か」であるが、ロバストネス図に登場するオブジェクトは名前のほかに種別と関連を持つ。種別には「バウンダリ」「コントローラ」「エンティティ」があり、それぞれも種別はアイコンを持つ。関連は他のオブジェクトとの関わのことである。この名前、種別、関連をもつオブジェクトでユースケースのフローを表現した図がロバストネス図であり、逆にロバストネス図を表現した文章がユースケースシナリオである。だがユースケースロバストネス図にしようとしてもうまくいかないことがある。原因はユースケースシナリオにある不備、不明点である。そこでユースケース担当者に問い合わせてこれを解消し、改めてロバストネス図作成を試行する。うまくいけばロバストネス分析の第1ステップは終了する。もちろんうまくいかなければ再びユースケース担当者に問い合わせることになる。

ロバストネス分析の第2ステップは公開である。担当者は図を公開しユースケース図やロバストネス図に関心のある者たちがオブジェクトに対して自分と同じ認識を持っていることを確認する。違っていれば何らかの問題があることになるので原因を追究し解決を図る。

ロバストネス分析の第3ステップは熟成である。公開後しばらく放置したら再びメンバーを招集し認識に変わりがないことを確認する。だが変わりがあれば再びロバストネス図を修正し再度確認。承認を得られたらユースケースシナリオに反映する。これを繰り返すことで図はブラッシュアップされ安定する。

これをもってロバストネス分析は終了する

ロバストネス図を書くことで、このユースケースを実装するためにしなければならない作業がどのような感じかを短時間に知ることができます。構築しなければならない可能性のある要素を、目に見える形で表すことができるからです。バウンダリ要素によって、ユースケースがユーザインターフェースの開発や既存のシステムの分析作業に結び付けられます。これらのクラスの中にはエンティティ要素があり、それらは必ず概念モデルに含めなければなりません。コントローラはそれよりもずっと設計概念に近いものなので、ロバストネス図は設計への橋渡しもしているといえます。

ロバストネス図アジャイルさを保つにはどうすればよいでしょうか。私の経験では、次のAMのプラクティスが役に立ちます。

  • 一時的なモデルは捨てよう:通常、ロバストネス図は、ユースケースのロジックを分析するためにホワイトボードに書きます。ユースケースを改善した後、ロバストネス図が残されるのは次の開発ステップ(以下を参照)への橋渡しをするまでで、その後は消されます。
  • 適切な成果物を使おう:モデリング担当者の中には、利害関係者がユースケースからシーケンス図などの開発成果物へ論理的に飛び移れるようになれば、ロバストネス図を作成しなくなる人がいます(私もその1人です)。ロバストネス図は、利害関係者が抽象的な考え方をできるよう教育するためのもので、その目的が達成されれば手法としては不要になる、と言うこともできます。このモデルが作業全体にとってまだ大きな価値があるという理由で、ロバストネス図を使いつづけるモデリング担当者もいます。

 ロバストネス図にはもう一つ、学習効果がある。ロバストネス分析は開発者たちにユースケース図とロバストネス図の確認を何度も強いる。これは多少は彼らの時間を奪うが同時に彼らに業務に関する学習の機会を与えこれが品質につながる。

これぞ品質向上の要諦である。

ドメインについて(6)

ビジネスという関心事を分離し品質を向上させることがドメイン設計の目的である。

具体的にどのようにすればいいのか。云うまでもなくシステム開発ではアーキテクチャの選定が重要である。だがドメイン開発ではこのアーキテクチャは決まっている。これについては考える余地はない。レイヤーアーキテクチャである。レイヤーアーキテクチャではコア層であるドメインを中心に設計する。以下の文書が主な成果だ。
  1. ドメインクラス図:モデラーがビジネスエキスパートやクライアントからヒアリングしたビジネスの要素。
  2. ユースケース図:ドメインクラスとして分解したシステム要素をさらに機能(プロセス)に分解した成果。機能要件・非機能要件がこれにあたる。
  3. ロバスとネス分析図:ビジネスエキスパートやクライアントとのメモ的文書。ユースケース図とドメインクラス図の起点となる。正式な成果とはならない事も多い。
注目すべきはこれら文書の保守性の高さである。設計文書というのは下流になっても継続的に変更されるものである。だが一般的には設計書等の下流における変更コストは非常に高いという問題がある。だがドメイン化をすればその問題がなくなる。凝集度が高いためどこにどんな機能やデータがあるかが分かり易くなる。結果修正時間が短縮される。修正だけではない。内容を把握したり、検証する時間も短縮される。変更は影響範囲の調査が難しい。下流の開発者はビジネスに精通していない。変更をどのようにすればいいか分からない。それについては聞かなければならない。所がそのソースを見せてもAPIレベルのソースコードと一緒になっている。そのため調査に高いコミュニケーションコストがかかる。
だがドメインクラスが分離されていれば対応も容易となりコミュニケーションコストも安くなる。

ドメインについて(5)

FDDはDe Lucaによって開発され、シンガポールプロジェクトで彼がCoadと作業している時に修正された。ますます短期化するビジネスライフサイクルへのレスポンスタイムに取り組むためには不要な工程を切り捨てる必要があった。

Coadは云った。「10年前、私たちの一人が110頁のプロセスを大規模開発チームのために作成した。私は彼のプロセスの各頁が価値あるものだと弁護したがチームメンバーは最後の4頁の要約を常に見て残りは無視した」

De Lucaは云った。「プロジェクトではクライアント、開発者、管理者の全てがFDDを気に入っていた。」

FDDでは2週間のインターバルで機能が納品される。頻繁に発生するこの納品はクライアントにとって意味のあるマイルストーンにより計画される。

FDDプロセスはイテレーティブなアジャイル開発の中でもっともシンプルな手法の一つである。ワークフローはこうだ。

  1. ドメインの開発(10%を最初に、4%を継続的に)
  2. フィーチャー一覧の構築(4%を最初に、1%を継続的に)
  3. フィーチャーの計画(2%を最初に、2%を継続的に)
  4. フィーチャーの設計と開発(77%をこの組み合わせに)

プロセス1が特に重要だ。ここではチーフアーキテクトがモデラードメインエキスパートで構成されるチームを主導する。ドメインエキスパートは要件を提供し、モデラーはこれをドメインモデルに落とす。それが役目だ。De Lucaはこのプロセス1の10%の時間が開発に於いて最も価値がある時間とした。

 短いレスポンスタイムが要求されるシステム開発FDDは要件定義を行わない代わりにドメイン設計を行う。つまり設計工程に新たな作業を導入する。これにより設計工程は複雑になるし様々な対立も発生する。これは課題のひとつだが、その代わりに得られる開発短期化の魅力は課題を鑑みてもお釣りが来る。

  1. オブジェクト指向モデラー対データベースモデラー・・これは思想の対立と云える。両者の対立は管理者や他の開発者も巻き込む。このようなことが起きないように管理者はメンバー選定に注意を払うべきだろう。
  2. プログラマモデラー・・これはプログラマドメインを無視するという意味である。何の対策もしなければプログラマは自分が欲しい機能を作成する。ドメインを利用しなくてもいいなら利用しない。結果、この対立の勝者はプログラマとなる。この対立を防ぐためにはプログラマに分かり易いガイド(標準)の作成と監査が必要だ。プログラマを設計者に置き換えた対立もある。
  3. 管理者対モデラー・・作業量の多さ、高頻度の要件変更、情報収集の機会のなさなどが対立の原因である。これはプロセス1で解決するより他ない。