ロバストネス分析は、ユースケースのように文章で記述された要求から分析レベルのオブジェクトを見つけ、適切な単位にまとめることができるものです。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。本稿はロバストネス分析の使い方と効果について解説します。
はじめに
ロバストネス分析という用語を聞いたことはありますか？
ロバストネス分析を使うことによって、ユースケースのように文章で記述された要求から分析レベル（アーキテクチャが考慮されていないレベル）のオブジェクトを見つけ、適切な単位にまとめることができます。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。
これから、3 回に渡ってロバストネス分析について解説します。本稿にあたる第 1 回ではロバストネス分析の使い方と効果について解説し、第 2 回ではサンプルアプリケーションをもとにしてロバストネス分析を実践し、第 3 回ではロバストネス分析にまつわる様々な考慮点について深く掘り下げて議論します。
SPEM の読み方
本稿では、ロバストネス分析をソフトウェア開発プロセスの観点から説明するために、SPEM (Software Process Enginering Metamodel) というソフトウェア開発プロセス定義のための UML 拡張を利用しています。
SPEM ではソフトウェア開発に登場する概念の意味の定義や記法の定義がされています。本稿では、SPEM の概念と記法のうち、モデル、成果物、作業定義（ワークフロー）、作業を利用しています。モデルとは成果物の特殊系で、UML などで記述されたモデルを示す用語です。
Before ロバストネス分析
どのような作業に関しても、インプットとなる情報がなければ作業を開始することはできません。それはロバストネス分析も同様の話です。
ロバストネス分析のインプットとなる成果物が 2 つあります。その 1 つがユースケースモデルで、もう 1 つが概念モデルです。
ユースケースモデルは要求定義という作業で、概念モデルは概念モデリングという作業で作成されます。つまり、ロバストネス分析に先立って要求定義と概念モデリングを済ませなければならないわけです。
要求定義はソフトウェアシステムに求めらていている機能要求、非機能要求を定義する作業です。機能要求は UML のユースケース図とユースケースの詳細を記述したユースケース記述ドキュメントを使って定義し、非機能要求は通常の文書に記述します。
概念モデリングはソフトウェア開発の対象となる業務における重要な概念と概念間の関係を識別し、UML のクラス図で整理します。このクラス図のことを概念モデルといいます。
この要求定義と概念モデリングの作業によってユースケースモデル（機能要求）、非機能要求、概念モデルが完成するわけですが、ロバストネス分析のインプットとなるのはユースケースモデルと概念モデルだということは前に説明した通りですが、この 2 つの成果物と残りの成果物である非機能要求は、アーキテクチャ分析という作業のインプットとなります。アーキテクチャ分析とはアーキテクチャメカニズムを識別し、詳細化することを目的とする作業です。アーキテクチャメカニズムとは永続性やプロセス間通信のようなアーキテクチャに求められる機能を指す用語です。
How ロバストネス分析？
さて、能書きはこれくらいにして、お待ちかねのロバストネス分析のしかたを説明しましょう。
ロバストネス分析ではロバストネス図という図を記述します。ロバストネス図とは、ユースケースに登場するクラスを定義するための図で、このクラスの静的な側面をクラス図で、動的な側面を相互作用図（シーケンス図かコラボレーション図）で記述します。
ロバストネス図に登場するクラスは 3 種類に分類できます。それが、
- バウンダリ
- エンティティ
- コントロール
です。
バウンダリ
バウンダリとはステレオタイプ << boundary >> で拡張したクラスで、図のようなアイコンで表現されます。
バウンダリにはソフトウェアシステムの外部とのインタフェースを定義します。つまり、バウンダリはアクターと相互作用するオブジェクトです。画面は代表的なバウンダリで、例えば「ユーザ情報登録画面」、「商品紹介画面」のように 1 つの画面の種類ごとに、1 つバウンダリを定義します。画面の他にも、帳票やメールや他システムとのインタフェースもバウンダリとして定義することがあります。
バウンダリには属性として、入出力項目を定義します。画面の場合は入出力の両方がありますが、帳票やメールの場合には出力のみとなるでしょう。画面や帳票などの人のアクターと相互作用するバウンダリは、概してレイアウトが重要視されるものが多くあります。レイアウトを考慮しなければならないものを識別するためにもバウンダリは役立ちます。
エンティティ
エンティティとはステレオタイプ << entity >> で拡張したクラスで、図のようなアイコンで表現されます。
エンティティにはソフトウェアシステム内部で半永久的に管理するデータとその振る舞いを定義します。つまり、エンティティはそのままデータベースのテーブルとなるか、もしくはデータベース設計の入力になります。ロバストネス分析の前に概念モデリングを行っている場合には、インプットの概念モデルがエンティティの候補となりますが、もし前もって概念モデリングを行っていない場合には、ロバストネス分析と並行して概念モデリングを行う必要があります。
エンティティの属性にはデータ項目を、操作にはそのエンティティ特有の操作を定義します。
コントロール
コントロールとはステレオタイプ << control >> で拡張したクラスで、図のようなアイコンで表現されます。
コントロールにはユースケースでソフトウェアシステムが行っている処理を定義します。コントロールの粒度については、方法論によって様々で、ユースケース単位の場合もあれば、ユーザのアクション単位の場合もあり、はたまた特に指針がない場合もあります。コントロールをどの単位で定義するかはプロジェクトごとで決定しなければなりません。通常、コントロールには属性を定義しません。反対に、コントロールには操作を定義します。ただし、ICONIX アプローチは操作の単位までコントロールを分割するため、コントロールに操作を定義しません。
ロバストネス分析の流れ
ロバストネス分析は図のような流れで作業します。
ロバストネス分析の作業を大きく分類すると、モデルの記述（バウンダリの識別、クラス図の記述、相互作用図の記述）と、モデルの洗練（ユースケースの洗練、概念モデルの洗練、コントロールの洗練、バウンダリの識別）に分かれます。どこまでモデルを洗練するかはプロジェクトのスケジュールや指針によりますが、大抵の場合は 1 回だけ洗練を行って作業を終了します。
例題のユースケース
これから、ロバストネス分析の流れを簡単な例をもとに説明します。下は今回の例となる「ログイン」ユースケースのイベントフローです。
ログインユースケース 1. 営業員はユーザー ID とパスワードを入力する |
バウンダリの識別
ユースケースのイベントフローからバウンダリの候補を見つけます。
イベントフローには「営業員はユーザー ID とパスワードを入力する」といったような、ユーザーが画面に対して行うアクションが記述されています。このアクションがバウンダリがある証拠となります。このアクションの場合には「ログイン画面」バウンダリがあるとわかります。また「システムは検索画面を表示する」や「システムは見積帳票を出力する」などバウンダリそのものの名前がアクションに記述されている場合もあります。
識別したバウンダリがもつ入出力項目をバウンダリの属性として定義します。ログイン画面には「ユーザー ID」と「パスワード」が属性となります。もし、入出力項目が明確でない場合は、顧客に対してヒアリングを行い明確にする必要があります。
クラス図の記述
1 つのユースケースにつき 1 つのクラス図を作成します。このクラス図にはユースケースに登場するバウンダリ、エンティティ、コントロールの関係を記述します。このクラス図がロバストネス図の一部となります。
まず初めにユースケースから識別したバウンダリをクラス図に記述します。
次にコントロールをクラス図に記述します。コントロールの説明にあるように、コントロールの単位はプロジェクトごとに決めなければなりません。そのため、今回はイベントフローのユーザーのアクション単位にコントロールを識別します。コントロール名はユーザーのアクションに続くシステムのアクションから定義すると良いでしょう。例えば、「営業員はユーザー ID とパスワードを入力する」というユーザーのアクションからコントロールを定義し「システムはユーザー ID とパスワードが正しいことを確認し、メニュー画面にユーザーが選択可能なメニューを表示する」というシステムのアクションからコントロール名を「ユーザー認証」と定義します。そして、イベントフローをもとにバウンダリとコントロールの間に関連を記述します。
次にコントロールを実現するために必要なエンティティを識別し、クラス図に記述します。コントロールを定義する際に参考にしたユーザーのアクション、システムのアクションをもとに必要なエンティティを概念モデルから見つけます。例えば、「システムはユーザー ID とパスワードが正しいことを確認し、メニュー画面にユーザーが選択可能なメニューを表示する」というアクションから「ユーザー情報」エンティティが見つかり、属性にユーザー ID とパスワードが必要だということが分かります。このエンティティとコントロールとの間に関連を記述します。もし、クラス図中で複数のエンティティが登場し、その間に関連が存在し、その関連がユースケースにとって重要なものの場合には、このエンティティ間の関連も記述する必要があります。例えば、「システムはユーザー ID とパスワードが正しいことを確認し、メニュー画面にユーザーが選択可能なメニューを表示する」というイベントフローのアクションから「ユーザー情報」エンティティと「メニュー」エンティティを見つけたのなら、クラス図にはこの 2 つのエンティティ間の関連を記述しましょう。
ロバストネス図のクラス図を記述する際のクラス間の関連にはいくつかのパターンが存在します。以下のクラスの組み合わせがクラス図に登場する関連のパターンです。-> は関連の方向を示しています。
- バウンダリ -> バウンダリ
画面間の遷移を表現します。 - バウンダリ -> コントロール
画面が特定のコントロールを起動することを表現します。 - コントロール -> バウンダリ
コントロールが画面の表示、帳票の印刷などを行うことを表現します。 - コントロール -> コントロール
コントロールが別のコントロールを利用することを表現します。 - コントロール -> エンティティ
コントロールがエンティティを利用することを表現します。 - エンティティ – エンティティ
エンティティとエンティティの間に関係があることを表現します。
相互作用図の記述
1 つのユースケースにつき複数の相互作用図を作成します。相互作用図は基本イベントフロー、代替イベントフローごとに書くことを推奨しますが、あまりにも単純な代替イベントフローについては省略しても問題ないでしょう。また、相互作用図のうち、コラボレーション図（もう 1 つはシーケンス図）を使うことを推奨します。なぜなら、ロバストネス分析ではユースケースにおいてエンティティがどのように使われているか明確にする必要があるためで、そのためにはコラボレーション図のようにエンティティの構造を記述できる図の方が有効だからです。
このコラボレーション図には各イベントフローに登場するバウンダリ、エンティティ、コントロールがどのように協調動作しているかを定義します。このコラボレーション図がロバストネス図の一部となります。
まず初めにイベントフローに登場するバウンダリ、エンティティ、コントロールとその間のリンクをコラボレーション図に記述します。リンクはクラス図に書いた関連をもとに記述すると良いでしょう。
次に各リンクにメッセージを記述します。バウンダリからコントロールへのメッセージにはコントロールで実行して欲しい処理（「ログインする」など）を、コントロールからバウンダリへのメッセージには「表示する（画面）」や「印刷する（帳票）」をコントロールからエンティティへのメッセージにはエンティティで実行して欲しい処理（「生成する」、「検索する」、「確認する」、「更新する」、「計算する」、「削除する」など）を記述します。
<
ユースケースの洗練
複数のユースケースのクラス図や相互作用図を記述していくうちに、ユースケースにまたがって同じようなコントロール群が登場することがあります。この場合、このコントロール群をまとめて 1 つのユースケースを定義すると良いでしょう。このユースケースは他のユースケースから包含（ include ）されるユースケースとなります。そのため、ユースケース図に新しいユースケースと包含関係（ include 関係 ）を記述しなければなりません。
詳しくは次回の記事で説明します。
概念モデルの洗練
クラス図や相互作用図を記述していくうちに、概念モデルに存在しないエンティティが見つかったり、属性が見つかることがあるでしょう。この場合、概念モデルにこの変更を加えなければなりません。
詳しくは次回の記事で説明します。
コントロールの洗練
コントロールの洗練のしかたはコントロールの粒度やプロジェクトの指針によってかなり異なります。
コントロールの単位がユースケースの場合は、ユースケースの洗練時に新しい包含されるユースケースが作成されたのなら、同時にそのユースケースに対応するコントロールを記述します。
コントロールの単位がユーザーのアクション単位の場合でも、同じことをするコントロールが複数存在する場合には、それらを 1 つのコントロールに統合します。またプロジェクトの指針によりますが、同じエンティティに対して操作するコントロールが複数存在する場合に、それらを 1 つのコントロールに統合してもよいでしょう。
大規模開発の場合には、設計作業の一環として特定のルールに従いコントロールを分割することがあります。ただし、分割のルールは対象のソフトウェアシステムのアーキテクチャメカニズムやサブシステム構築の指針によってしまうでしょう。特定のルールを定めることによってアーキテクチャについて詳しく知らないエンジニアでも、設計作業を自動的に進めることが可能となります。
コントロールの洗練に関わる問題については第 3 回の記事で重点的に議論したいと思います。
Why ロバストネス分析？
さて、ここまでロバストネス分析の方法を説明してきました。それでは、ロバストネス分析をすることでどのような効果が得られるのでしょうか。
ユースケースの妥当性を検証する
ロバストネス分析でユースケースのクラス図や相互作用図を記述していく過程で、ユースケースのイベントフローの問題が見つかることがあります。例えば、イベントフローのアクションの記述が仕様の定義として不十分という問題もあれば、代替イベントフローの見落としという問題もあります。問題のあるユースケースを修正することで、ユースケースの品質が高まります。
ユースケースを洗練する
ロバストネス分析では複数のユースケースにまたがって同じコントロールが登場する場合に、それを包含されるユースケースとして新たに作成することができます。このようなユースケースを見つけることで、ソフトウェアシステムの再利用性が高まり、またプロジェクトのコスト削減にもつながります。
概念モデル（エンティティモデル）を洗練する
ロバストネス分析でユースケースのクラス図や相互作用図を記述していく過程で、概念モデルの問題が見つかることがあります。その問題とは、エンティティが足りない、エンティティ間の関連が足りない、エンティティの属性が足りないなど様々です。問題のあるエンティティを修正することで、概念モデルの品質が高まります。
設計モデルのインプットを作成する
ロバストネス分析で登場したバウンダリ、エンティティ、コントロールは設計要素の候補となります。つまり、バウンダリから画面の設計要素（画面クラスや JSP など）を、エンティティからデータの設計要素（テーブル、Entity Bean など）を、コントロールから処理を実行する設計要素（ Servlet や Session Bean など）を定義するわけです。
また、コントロールとエンティティの関連から、関連が強いクラスを集めてサブシステムを定義することもできます。
After ロバストネス分析
それでは、ロバストネス分析のアウトプットであるロバストネス図は、その後どのように使われていくのでしょうか。ロバストネス分析の後にはソフトウェアの設計が始まります。設計と一言でいっても 2 種類の作業があり、その 1 つがアーキテクチャ設計で、もう一つがユースケース設計です。アーキテクチャ設計はアーキテクチャメカニズムをインプットとし、ソフトウェアアーキテクチャの構成と構成要素を決定します。ユースケース設計では、ロバストネス図とアーキテクチャ設計のアウトプットであるアーキテクチャ設計モデルをインプットとし、各ユースケースのロバストネス図に決定したソフトウェアアーキテクチャを適用し、ユースケースごとの設計モデルを作成します。
図 12 ロバストネス分析と設計の関係
次回に向けて
今回は、ロバストネス分析を適用したソフトウェア開発の流れ、ロバストネス分析の方法、ロバストネス分析の効果について説明しました。次回は今回の内容をふまえて、具体的な例題を用いてロバストネス分析を行い、モデルが洗練されていく過程を明らかにしていこうと思います。どうぞ、お楽しみに。
参考文献
- [1] 『オブジェクト指向ソフトウェア工学OOSE－use-caseによるアプローチ』 Ivar Jacobson・Magnus Christerson・PatrikJonsson・Gunnar Overgaard／著, 西岡利博・渡邊克宏・梶原清彦／監訳, トッパン
- [2] 『ユースケース入門－ユーザーマニュアルからプログラムを作る』 Doug Rosenberg・Kendall Scott／著, 長瀬嘉秀・今野睦／監訳, ピアソン・エデュケーション
- [3] 『UMLによるエンタープライズJava開発』 CT Arrington／著, 平沢章・笠充彦・船越隆行・早川秀利／訳, 翔泳社
- [4] 『Building J2EETM Applications with the Rational Unified Process』 Peter Eeles・Kelli Houston・Wojtek Kozaczynski／著, Addison-Wesley
改訂履歴
・サイトテンプレート変更に伴う変更（2018年3月）