実践 ICONIXプロセス : 要求モデルから実装設計へ

ロバストネス分析は、要求を分析し、実装への橋渡しをする重要なステップです。
ICONIXプロセスの特徴、考え方がもっとも良くでているステップです。

要求モデルを強靭(ロバスト)にする

ICONIXプロセスの要件定義は、初期のドメインモデル(用語集)を2時間くらいで描いて、画面の紙芝居を使いながらユースケースを記述します。

初期バージョンのドメインモデルやユースケース記述は、いろいろな曖昧さや不整合が残ります。

ロバストネス分析は、「ユースケースを絵にしてみる」だけの作業です。しかし、驚くほど、ドメインモデルに不足していたオブジェクトや、ユースケース記述の課題を発見できます。
ロバストネス図を描くことは、とても簡単かつ実践的な分析テクニックです。

ロバストネス分析によって、要求モデル(ドメインモデル、ユースケースモデル)は、強靭(ロバスト)になります。

実装を強靭(ロバスト)にする

ICONIXプロセスでは、ロバストネス分析は、実装の予備設計です。

UIオブジェクト(画面やボタン)、メソッド、エンティティオブジェクトを丁寧に洗い出す作業です。
ロバストネス図を描けば、実装すべき要素を確実に発見できます。

ドメインクラスは、このステップですべて見つけ出し、属性も詳細に定義します。

アーキテクチャとシーケンス図

ロバストネス分析の次はシーケンス図を使って、実装設計を行います。
ただし、シーケンス図作成の前に、アーキテクチャを明確にする必要があります。

最近は、Webアプリケーション用の優れたフレームワークが活用できるので、アーキテクチャの決定の主要な作業は、フレームワークの選定と、活用ノウハウの取得、実装パターンの整備です。

---

ロバストネス分析は、要求と実装、顧客と開発を一つのチームにまとめる、マジックです。
顧客は要求を話しているし、開発は実装を考えている、でも、議論はきちんとかみあう。

ロバストネス図に表れる言葉は、画面名、ボタン名、業務用語(ドメインオブジェクト名)です。
ロバストネス図の矢印は、業務の処理の順番と情報の流れです。

ですから、顧客にとっては、ロバストネス図は、業務の説明図です。

ロバストネス図のバウンダリは、UIオブジェクトです。コントローラは、メソッドです。エンティティは、ドメインオブジェクトです。

ですから、開発にとっては、ロバストネス図は、実装の骨格図です。

ロバストネス図のコントローラは、テストケースです。
顧客と開発は、同じテスト項目(判断基準)を共有しながら、プロジェクトを進めることができます。

実践 ICONIXプロセス : ロバストネス分析 Tips

ロバストネス図を描くときに注意したいこと。

バウダンリを部品単位で描かない

ボタン、テキストフィールド、リストボックスなどをバウンダリにしない。
バウンダリは画面単位で描く。

画面が大きなブロックに分かれている場合、例えば、
・検索条件の入力フォーム
・検索結果の一覧
・注目商品一覧
・ログインフォーム
...

各ブロックの表示とアクションが、ひとつのユースケースになる。
だから、バウンダリも、ページ全体ではなく、ブロック単位に分解して描く。

つまり、画面がいくつも集まって、ひとつのページになる。

クリック操作

クリック操作(ユーザのアクション)は、

バウンダリ → コントローラ

の矢印のところにラベルとして書く。

アクターとバウンダリとの間には書かない。

表示コントローラ

表示コントロールは、すべての画面に必ず描く。

理由1.
表示には、初期化ロジックや、データベースからの情報取得が必要なことが多い。
 これを見落とさないように、表示するコントローラをまず描き、そのコントローラのロジックや参照すべき情報を検討する。
 表示するコントローラを省略すると、いっしょに、こういう要求事項も見落としてしまう。

理由2.
コントローラは、そのままテストケースとなる。
「表示する」ことを確認するテストケースを見落とさないために、すべての画面には表示するコントローラを描く。

矢印の使い方

・処理の順番
・情報の流れ

この2点を表すために、積極的に矢印を使う。

UMLコミュニケーション図のメッセージの方向とは全く別である点に注意する。

コントローラはクラスではなくメソッド

ICONIXプロセスのロバストネス図では、コントローラはクラスではなく、メソッドです。
ロジック、機能の置き場所として、コントローラを描きます。

他の方法論では、違うかもしれません。 ICONIXプロセスでは、メソッドです。

実践 ICONIXプロセス : ロバストネス図はユースケースの絵

ロバストネス図はユースケースの文章を絵にしたもの。
ロバストネス図では、具体的な画面名とユーザのアクション(ボタンクリックなど)を使う。
ロバストネス図でドメインモデル(用語集)のオブジェクトを使う。

画面と用語集で描くのだから、ロバストネス図は顧客にもかんたんに理解できる。

一方、ロバストネス図は、実装の設計でもある。

「顧客に理解できる実装の設計図」という、このロバストネス図こそ、ICONIXプロセスの核心でしょう。

実践 ICONIXプロセス : ロバストネス図から実装へ

ロバストネス図は、実装の初期設計。
それぞれの要素を、そのまま実装に変換する。

バウンダリ → シーケンス図のインスタンス(オブジェクト)
エンティティ→ シーケンス図のインスタンス(オブジェクト)
コントローラ→ クラスのメソッド

コントローラは、クラスではなくメソッドになる。
また、コントローラは、テストケースでもある。コントローラは機能・ロジックの単位ですから、単体の機能テストの単位ということです。

ロバストネス分析をする時、この実装との強い結びつきを意識したほうが良い。

ロバストネス分析は、実装の設計なんです。

実践 ICONIXプロセス : ロバストネス図という魔法

ロバストネス分析は予備設計です。

実装の設計(シーケンス図)を行う準備作業として、ロバストネス分析を行う。

要求は、以下のモデルで記述します。
・ドメインモデル(概念クラス図)
・ユースケースモデル(パッケージ図、ユースケース図、ユースケース記述)
・補足仕様書(画面の紙芝居/線画/モックアップ、ビジネスルール詳細など)

この情報を完璧に理解して、設計ができればすばらしい。

でも、現実は、設計をはじめてから発覚する要求仕様のモレ、矛盾、誤解はかなり多い。

ICONIXプロセスは、この現実の問題を解決する実践テクニックとしてロバストネス図を使う。

ロバストネス図の二面性

ロバストネス図は、ユースケースを絵にしただけだから、要求モデルの一部です。
しかし、
ロバストネス図のバウンダリとエンティティは、シーケンス図のオブジェクトになり、コントロールはシーケンス図のメソッドになる。つまり、実装の設計図です。

「要求」モデルであり「実装」モデルでもある。このロバストネス図の二面性が、モデルを直接コードに持っていくマジックの種明かしです。

プログラマはシーケンス図までは、自分の領域に感じるようです。もう一歩だけ、要求に近づいて、ユースケースを読んでロバストネス図を描くのは、実装設計の準備なので違和感なく取り組めるはず。


要求定義も実装の一部

ロバストネス図は、ユースケースを絵にしただけ。ロバストネス図を描けるということは、自分で、ユースケースを書くこともできるということ。ここで、さらに一歩、要求に近づく。

ICONIXプロセスを社内に導入してから、一番大きな変化は、開発者たちが、要求仕様のモデル化(ユースケース記述)を、実装に近い作業として取り組むようになったこと。それも、いわゆる上流工程の概念的なあいまいな作業ではなく、開発作業の一部、実装の準備作業という感覚でやっている。

実際、Eclipse を使う時間が減り、Enterprise Architect を使う時間、図やユースケース記述を使って、メンバーどうしや顧客と話す時間が増えたのはびっくりします。

この変化の効果は絶大で、顧客の要求の取り違い、とんちかんな実装、とんでもないバグがほんとうに減りました。要求を勘違いをしていても、早い段階に発覚するし、軌道修正も速い。

実践 ICONIXプロセス : ロバストネス図にユースケースを置く

ICONIXプロセスのユースケースモデリングでは、汎化(generalize)、包含(includes)、拡張(extends)を使いません。
分析・検討に時間がかかるのに、何の役にも立たない。

ICONIXプロセスでは、ユースケースを、ユーザマニュアルと同じ、と考えています。

・汎化したマニュアル(説明)が読みやすいですか?
・共通部分の説明を包含ですませた説明が読みやすいですか?
・拡張部分だけを別に記述した説明が読みやすいですか?

すべての答えはノー。だから、使わない。

もちろん、共通部分がありますので、

・先行 ( precedes ) : ユースケースを順番に実行する
・呼出 ( invokes ) :サブのユースケースを呼出(実行後、元に戻る)

の2つのパターンは積極的に使います。

ひとつのユースケースは単純なほうがわかりやすいので、ICONIXプロセスでは、ユースケースは、わりと小さな単位になります。

ユースケースを絵にした時、ロバストネス図が、普通にA4に収まるくらいのイメージ。

あるユースケースをロバストネス図として描いているとき、

・先行するユースケース
・呼出元のユースケース
・呼び出すユースケース

をユースケースモデルからドラッグしてきて、ロバストネス上に置きましょう。

そのユースケースをどういう文脈(コンテキスト)で実行するのか、分かりやすくなります。

最初のうちは、ロバストネス分析をしながら、ユースケースモデルの構造をいろいろ改良することが多い。

・ユースケースを分割する
・ユースケースの先行、呼出関係の見直し
・ユースケース名の変更

などですね。

これでユースケースモデルの構造が、強靭(ロバスト)になる。

実践 ICONIXプロセス : ロバストネス図の矢印の方向

ロバストネス図の目的

・ユースケース記述から曖昧さを除く。
・ドメインモデルで見逃したオブジェクトを発見する。

つまり、主体は、ユースケース記述であり、ドメインモデルです。

・ユースケース記述を改良して強靭(ロバスト)にする
・ドメインモデルを改良して強靭(ロバスト)にする

ための手段がロバストネス図、ということですね。

ユースケース駆動開発実践ガイドでは、ロバストネス図の矢印の方向は、重要ではない、といっています。
矢印の方向は、上記の目標の達成には重要ではないと。

ただし、矢印はデータの流れ、制御の流れを示す、便利な手段です。
ロバストネス図を描くときは、矢印を積極的に使ったほうが、わかりやすくなります。

誰でもぱっと見て理解できるように
・制御の順番
・情報の流れる方向
だけを意味することを、チーム内で徹底しておくことがたいせつ。

まちがっても、UMLのコミュニケーション図の矢印の方向の議論を持ち込まないでください。
ロバストネス図は、ロバストネス図と割り切って使いましょう。

補足メモ

UMLは基本的にオブジェクト指向の「メッセージ」の概念を重視する。

例えば、get() メソッド。
・メッセージの方向は、 get()を使うクラス → get() を実装したクラス、になる。
・情報の流れる方向は、 get()を使うクラス ← get() を実装したクラス、と逆になる。

コミュニケーション図は「メッセージ」による方向を明示する手法です。オブジェクトとオブジェクトが「メッセージ」で、コミュニケートする様子をモデル化する手段。

ロバストネス図は、制御の順番情報の流れを表すために矢印を使う。

ユースケース駆動開発実践ガイドでは「矢印の方向は重要ではない」といっていますが、実践的には、制御の順番情報の流れを表すために矢印を積極的に使うほうが、良い分析が簡単にできると思います。

実践 ICONIXプロセス : コントロールとコントローラクラス

ICONIXプロセスのロバストネス分析ではコントロールは、機能(ロジック)の置き場所(プレースホルダ)。
実装時のコントローラクラスではない。

名前がかぶっているので、実装時のコントローラクラスをマネージャクラスと呼ぶことにしましょう。
(○○Manager)

ロバストネス図のコントロールのアイコンは、実装時には、メソッドになります。(クラスではありません)

もちろん、マネージャクラスが必要な場面もある。
「ユースケース駆動開発実践ガイド」であげている例:

コントロールのかたまり

多くのコントロールは、表示/妥当性検証/情報取得/情報書き込みなど、独立した機能です。
しかし、関連するコントロールのかたまりをロバストネス図上に発見することがあります。

この場合は、そのかたまりをマネージャクラスとして実装する、という設計はありです。

状態遷移

ひとつのユースケースの実行時に状態遷移の管理が必要な場合。
具体的には、ユースケースを書くために、状態図でモデリングをしてみた、というような場合。

この状態遷移を管理するためにはマネージャクラスを実装することが適切そうです。
もっとも、状態管理を意識する必要があるユースケースが多いとは思えません。

マネージャクラスの多用の戒め

ICONIXプロセスの筆者たちは、設計や実装でマネージャクラスやコントローラークラスを使いすぎないように警告しています。

ロジックだけをひとかたまりにしたクラスが有用なシーンはもちろんありますが、原則は、ロジックとデータをひとかたまりにすること。現場の技術者たちが、この原則を忘れて、マネージャクラスを多用しがちなことを、筆者たちは、トレーニングの現場で痛感し、また危機感を持っているようです。

実践 ICONIXプロセス : 機能を洗い出す コントローラ

ロバストネス分析で、かなりトリッキーなのが、コントロール。

ICONIX のロバストネス図ではコントロールは「オブジェクト」ではありません。
MVCモデルの C (コントローラー)ではない、ということです。

コントロールは、機能(ロジック)の置き場所です。
・画面を表示する(初期値を設定する)
・入力データを検証する
・エンティティオブジェクトを保存する
...

別の言い方をするとコントロールは主要メソッドを洗い出す作業です。
display()
validate()
save()
...
になることを想定してコントロールを描く。

それぞれのメソッドをどのクラスに実装するかは、ロバストネス分析の段階では決めません。それは、次のステップ「シーケンス図」で割り当てるクラスを決めます。

validate() 系の機能(コントロール)は、おそらくエンティティクラスに割り当てる。

display() 系の機能(コントロール)は、使用する Web アプリケーションフレームワークによって、実装方法は変わる。
私たちは、 Web Flow 2.0 を使っているので、画面のレンダリングメソッドは不要です。
レンダリング対象のドメインオブジェクト、それを取得するサービスクラス、velocity テンプレートを用意して、XML定義ファイルでワイリングするだけ。
まあ、その定義ファイル内に、「表示」を宣言しているわけですが...

save() 系の機能は、私たちの場合は、DDD の REPOSITORY パターンを使っているので、REPOSITORY クラスのメソッドに割り当てる。

ロバストネス図のコントロールは、こういう機能単位、メッソド単位で洗い出して描くこと。

コントローラーオブジェクトと混同しないこと。

「コントロール」と「コントローラー」と名前が似ているので、かなりトリッキーです。でも前者は「メソッド」で、後者は「クラス」なんです。

ということは、ロバストネス図は、オブジェクトと機能(メソッド)を混在させているのでUMLのコミュニケーション図ではありません。 UML的には、ロバストネス図のコントロールは、コントローラークラスに見えます。 コミュニケーション図であれば、そうなる。

でも、ICONIXのロバストネス図は(見た目は似ているけど)コミュニケーション図ではないんです。

機能(メソッド)単位で、洗い出す。その発見した機能(メソッド)の置き場所が、コントロール「アイコン」というだけです。

ロバストネス分析を効果的に進めるには、このトリッキーな「ロバストネス図のコントロールはメソッド」を、現場で共通理解にすることが大切です。

実践 ICONIXプロセス : 画面を洗い出して定義する

ロバストネス図を描くとき、

・画面をすべて洗い出すこと(特に代替コースのエラーメッセージ)
・すべての画面に明確な名前をつけること

ICONIXプロセスは「ユースケース記述は不完全」と想定します。

実際にやってみると、
・代替コースでのエラーメッセージ表示や再入力のための画面定義が不十分
・画面の名前が不完全。曖昧。
ということになる。

気をつけてユースケースを書いたつもりでも、やっぱり、こういうことが起きる。要求レビューをやっても、やっぱり画面のもれぬけが起きる。

だから、最初から「不完全」と考えて、チェックする手順を用意する。それがロバストネス分析、つまり、絵に描きなおしてチェックするという約束事を決めてある。

実際に、ロバストネス図を描くと、
・画面名が決まっていなかった
・代替コース(エラー発生時)の画面遷移が抜けていた。まちがっていた。
という発見がかなりあります。

画面の名前が決まっていないことはありがちですが、とても面白い現象。
「名前」を書かせてみると、とんでもない勘違いが発覚する。

単なる名前の書き忘れではなく「要求を理解していない」から、画面名が「ページを表示」とかになっちゃう。本人はそれに気がつかないで、わかったつもりになっている。

ロバストネス分析でこれが発見できることを実際に経験すると、ロバストネス分析は、ほんとうに実践的で効果的なやりかたというのが実感できる。

ロバストネス分析で、
- 必要なバウンダリ(画面)をすべて発見する。
- すべての画面に意味のある固有の名前をつける。
- すべての画面の模型(線画やモックアップ)をそろえる。

これで、プレゼンテーション層の画面構成がかたまり、強靭(ロバスト)になる。

calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM