要求仕様における無矛盾性と追跡可能性に関する品質保証を目的とした

要求仕様における無矛盾性と追跡可能性に関する
品質保証を目的としたソフトウェア設計手法
おくだ
知能ソフトウェア工学研究
1.
はじめに
ソフトウェア開発プロセスの初期に行う要求定義で
は、その成果物である要求仕様書の品質が次工程以降の
効率や成果物の品質に大きな影響を及ぼす。要求仕様の
品質は、IEEE Std. 830-1998[1]に 8 つ定められている。
本研究室では、品質特性の非曖昧性と妥当性の観点か
らユースケース分析に基づく業務系 Web システム開発
を対象に開発者の定義した要求分析モデルから顧客が
その妥当性を確認出来る Web UI(User Interface)のプロ
トタイプ生成を特徴とした UML(Unified Modeling
Language)を用いたモデル駆動要求分析手法[2]を提案し
てきた。
要求分析では、システムが提供するユースケースを、
その実施主体者とシステムの相互作用として定義する
ことが目的で、数種の UML を用いて要求分析モデルを
定義する。特に、図 1 上段のように 3 つの観点の振る
舞い(ユーザの動作起点となるトリガを含む入出力項目、
入力項目検査やユーザへの通知、トリガが起点となり起
動する動作系列であるビジネスロジックとその例外フ
ロー)をアクティビティ図のパーティションに分けて明
確に定義する。データ構造は UML クラス図で定義し、
その具体値はオブジェクト図で定義する。
業務システムはデータを中心に継続的に運用する事
が特徴であることから、そのデータの振る舞いである
CRUD(Create/Read/Update/Delete)の矛盾が要求仕様に存
在しないこと（無矛盾性）を早期に保証する必要がある
ので、要求仕様の CRUD 検証手法を提案する。
さらに、無矛盾性が保証出来た業務システムを実現す
る為に、要求仕様から系統的に漏れなく正確に設計仕様
へ適用する（追跡可能性）手法を提案する。
2.
要求仕様の無矛盾性観点の品質保証
業務システムでは、永続化候補のデータ(以降、エン
ティティ)の振る舞いの矛盾が次工程の手戻りの大きな
原因となる。
2.1.
要求分析モデルに追加する CRUD 記述
ユースケースにおけるアクションをエンティティに
対する CRUD 操作として明確化することで、サービス
全体で基本的な CRUD の性質を満たしているかを検証
できる。そこで、アクティビティ図のシステムパーティ
ション内のアクションの記述(目的語と CRUD を表す 9
種の動詞)と目的語に対応するオブジェクトノードの位
置関係を整理した。
2.2.
CRUD テーブルに基づく検証手法
CRUD の動詞を抽出することで、アクタごとのユース
ケース名を行に、エンティティ名を列にもつ CRUD テ
ーブルを自動生成することができる。 CRUD テーブル
からは、各ユースケースが各エンティティに対してどの
CRUD 操作を行っているかが一目でわかるので、(1)開
発者の意図するサービスの責務とエンティティの過不
足、(2)システムにとって不要なエンティティの洗い出
しと必要性の判断、(3)サービス全体でエンティティが
適切なデータの振る舞いを行っているかを確認できる。
2.3.
シナリオに沿った CRUD の網羅的検査
アクティビティ図の基本・代替・例外フローの全ての
パスにおいて、データの無矛盾性を保証するには、フロ
ひろたか
MA11043 奥田博隆
電気電子情報工学専攻
指導教員松浦佐江子
ーを網羅的に辿る必要がある。そこで、エンティティ毎
に成り立つべきオブジェクトの値の存在の有無と
CRUD 操作の関係をステートマシン図で定義する。これ
らのモデルを有限オートマトンに変換し、モデル検査技
術を用いて網羅的に検査することで、サービスの全ての
利用シナリオに沿った無矛盾性の検査を行う。
2.4.
実験と考察
モデル駆動要求分析手法を用いて、大学院授業課題や
大学で運用している LMS の拡張機能、授業で用いるグ
ループワーク支援システム等 5 種類の要求分析モデル
を作成し、CRUD テーブルおよびモデル検査技術による
評価実験を行った。
Read の取得結果に応じた例外又は代替フローの分岐
が存在しない為、例外に対する対処ができていない箇所
を発見した。また、オブジェクトが存在するフローの中
でオブジェクトを作成している為、サービス継続中にそ
のオブジェクトが存在し得ない状態となり、意図通りに
サービスを継続できない矛盾を発見できた。
3.
要求仕様からの Web フレームワーク設計
仕様への追跡可能性観点の品質保証
3.1.
Web フレームワーク設計モデル化手法
近年の Web 開発では、効率・拡張性の向上の為、開
発言語や運用環境に応じて MVC パターンに基づく様々
な特徴を持つ Web フレームワークを用いる事が多い。
要求分析モデルの User, Interaction, System パーティショ
ンがフレームワークの View, Controller, Model に対応づ
く。しかし、Controller にはフレームワーク固有の仕組
による実装方法の違いからフレームワーク固有の View
依存の処理とビジネスロジックの分離が必要である。本手法では、図 1 下段に示すように、Model に定義さ
れるビジネスロジックを用いて、正常・例外・代替のロ
ジックフローを記述した Logic Controller、フレームワー
クの View に依存する処理であるページ遷移処理・View
へのデータ送受信・入力項目の検査を行う View
Controller の 2 種の Controller を定義する。
Logic Controller は、トリガに対応する入出力処理単位
を表す Process Flow をサービス単位に構成する。アクテ
ィビティ図のフローを踏襲し、この Process Flow として
コード化することにより、機能要件に関する要求仕様と
設計仕様を対応付けている。
View Controller は、Web UI ではページ読み込みとト
リガ実行が動作起点となる事から、View Controller 及び
View に動作起点に対応する記述を定義し、 Logic
Controller の実体である Process Flow を呼ぶことで要求
仕様と設計仕様を対応付ける。
分離した Controller の機能をつなぐ為、入出力クラス
からトリガ部分を除く入出力項目に等しくなるよう定
義されたデータ転送用クラス（Transfer クラス）を用い
て、View Controller と Logic Controller 間のデータ送受信
を行う。
Model に関しては、設計では複数ユーザのシステムと
のインタラクションと、ネットワークを介した個々のユ
ーザのデータの授受を考慮する必要がある為、システム
パーティションにあるオブジェクトノードに（１）デー
タベースへの永続化、（２）インスタンスの状態識別、
（３）画面遷移間の値の保持、（４）出力情報のフィル
タの 4 つの役割を決定する。
テップとして明記する必要がなく、掲示板親書込生成時
に取得した。（B）に関しては、図 2 の破線部分の箇所
はページング機構を表している。それには、フレームワ
ークが提供するページング機構を利用し View
Controller に適用した。
表 1：「掲示板を閲覧する」Process Flow のコード
p r i v a t e s t a t i c Map<String, Object> viewBBSProcess(Filter f) {
Map<String, Object> rtnValue = n e w HashMap<String, Object>();
i f (f == n u l l ) //(1)
f = Filter.getShowAllPosts();
//(2)
User user = SessionManager.getUser(); //(3)
i f (user i n s t a n c e o f Student) { //(4)
Group group = ((Student) user).getMyGroup(); //(5)
rtnValue.put("group", group);
} e l s e i f (user i n s t a n c e o f Teacher) { //(4)
List<Group> allGroups = Group.findAll(); //(6)
rtnValue.put("groups", allGroups);
}
List<ParentPost> postsByFilter = ParentPost.getPostsByFilter(f); //(7)
rtnValue.put("posts", postsByFilter);
rtnValue.put("filter", f);
r e t u r n rtnValue;
}
図 1：要求分析と設計モデルの対応関係
3.2.
適用事例の概要
本研究室で提案するモデル駆動要求分析手法を用い
て、授業で用いるグループワーク支援システム（GWSS）
の開発を行った。規模はユースケース数 12 個、ソース
コード行数 4946 行、永続化エンティティ数 16 個である。
開発期間は約 25 日間、開発メンバは Web システム開発
経験のある大学院生 2 名、使用した Web フレームワー
クは、Java 言語・MVC 型フルスタックが特徴の Play!
Framework である。
3.3.
ケース・スタディ
GWSS の機能である掲示板の閲覧に着目してモデル
とソースコードの追跡可能性を検証する。
図 3：モデルと実装が対応付かない記述例
システムパーティションのオブジェクトノードの役
割として図 2 中に示す様に、ステレオタイプとして記述
した。4 つの役割を決定した根拠を以下に示す。
（１）データベースへの永続化：サービスの継続的運用
の為に必要なデータを対象とする。（<<Persistence>>）
（２）インスタンスの状態識別：サービス利用の為に、
あるエンティティの状態を識別する必要が有る時にセ
ッション変数を利用する。（<<Session>>）
（３）画面遷移間の値の保持：Process Flow に跨るデー
タの受け渡しを目的としてセッション変数を利用する。
（４）出力情報のフィルタ：Process Flow の入力や出力
となるオブジェクトノードを対象に画面出力情報を制
御する為にセッション変数や GET メソッドを用いる。
（<<Filter>>）
4.
図 2：「掲示板を閲覧する」の Process Flow
図 2 に「掲示板を閲覧する」の要求分析モデル中の
Process Flow を示す。表 1 に「掲示板を閲覧する」の
Process Flow の Java の実装コードを示す。図 2 中の吹き
出しの番号と表 1 内の文末の番号が対応している要素
である。クラスの対応関係は、Filter クラスはフィルタ、
User はユーザ、Group は班、ParentPost は、掲示板親書
込である。要求分析モデルの（１）〜（７）に対して、
ソースコードの（１）〜（７）が対応している事から機
能要件に関する要求仕様の振る舞いが定義できている。
設計観点として考慮する事として（A）開発言語やフ
レームワークの API の利用、（B）フレームワークが提
供するモジュールの利用がある。
（A）に関しては、図 3
に示す様に時刻の取得は API を用いる為、コード中のス
まとめ
業務システムには欠かせない概念であるデータの無
矛盾性に着目し、その検証手法を提案し、有効性を示す
評価実験を実施し、手法の妥当性を示した。クラス間の
関連や属性を考慮しない為、それが存在するクラスの
CRUD 操作がどの関連まで適用されるのかが不明慮で
ある。今後の課題として、それを表現する記述を導入し、
開発者の意図を正確に検査出来る様にする。
次に無矛盾性を保証されたモデルを対象に要求分析
モデルの機能要件を正しく漏れなく設計モデルに反映
する為の系統的な適用ルールを提案し、本手法を用いた
実システムを開発する事ができた。
参考文献
[1] IEEE:
Recommended
Practice
for
Software
Requirements Specifications, Std. 830-1998(1998)
[2] 小形真平, 松浦佐江子 : UML 要求分析モデルから
の段階的な Web UI プロトタイプ自動生成手法,コン
ピュータソフトウェア, vol. 27, No. 2, pp. 14-32(2010)
代表的な研究業績
Hirotaka OKUDA, Shinpei OGATA, Saeko MATSUURA :
Mapping Rule Between Requirements Analysis Model and Web
Framework Specific Design Model, Knowledge-Based Software
Engineering 2012 上記以外査読付 3 編,その他 9 編

Download Report