年度ソフトウェア工学分野の先導的研究支援事業要件定義 ... · 2019-04-01 · システムへの要求の変化想定外の不具合ソフトウェア・アーキテクチャの特性

2012年度ソフトウェア工学分野の先導的研究支援事業

要件定義プロセスと保守プロセスにおけるモデル検査技術の開発現場への適用に関する研究

2014年5月22日

芝浦工業大学

SIT総合研究所ソフトウェア開発技術教育研究センター

松浦佐江子

Agenda

• 背景• 要件定義プロセスと保守プロセスにおける検証

– 検証とは？検証するとは？検証するためには？

• 開発現場でモデル検査技術を利用するための課題とアプローチ– UMLによるモデル駆動開発– モデル検査ツール

• 開発現場での適用シナリオと検査方法の事例– 検証したい性質の定義– ツール支援

• まとめ

2014/5/22 2第2回産学連携のためのソフトウェア・シンポジウム

開発に求められるもの

2014/5/22 第2回産学連携のためのソフトウェア・シンポジウム 3

要求分析設計実装テスト保守

システムへの要求の変化想定外の不具合

ソフトウェア・アーキテクチャの特性

ハードウェア・アーキテクチャの多様性

実装技術の特性

システムの利用シナリオの多様性と広がり

ユーザの多様性

多様な要求にいつ、どのように対処するのか？定義したものはその要求を満足しているのかをいつ確認するのか？定義と検証

検証とは何か？

• 定義したものがある性質を満たすことを保証する

• 定義したもの ⇒ 要件・設計・プログラム

• ある性質 ⇒ 機能要件・ハードウェアの制約・セキュリティ要件…

• いろいろな要求を下記の観点から考察– IEEE Std 830-1998

– 機能・非機能要求

– ISO/IEC9126 品質特性

– 要求仕様の品質


検証するとは？

• チェックリストに従ってレビューする

• いろいろなケースで定義が検証したい性質を満たすことを試す（テスト）

• 定義に対して、ある状態になるか、あることは起きないかといった形式で、その性質を満たすことを調べる（状態探索モデル検査）

• 定義に対して検証したい性質を満たしていることを証明する（リファイメントと証明）


検証するためには？

• 定義したものに対してある性質を定義しなければならない

• 定義の意味が一意に解釈できなければならない

⇒ 厳密性が求められる

性質はどのように定義すれば良い？

• 課題– 検証可能な厳密な定義ができるようになるには学習コストがかかる

– いつでも容易に定義とある性質を検証可能なように定義できるのか


背景－何を検証するのか？

• 要求– ユーザがしたいこと

• 要件– システムで実現しなければならないこと– 実現する上での制約

• IEEE Std.830-1998• 機能要件・非機能要件• ISO/IEC9126 品質特性• 要求仕様の品質


書くべきこと

満たすべきこと


満たすべき性質

起きてはいけない不具合現象

さまざまな制約・条件機能要件非機能要件ハードウェア・アーキテクチャソフトウェア・アーキテクチャ実装言語

ある性質非機能要件

IEEE Std 830-1998

要求定義設計実装テスト保守

要求仕様ソースコード振舞いの定義

機能要件

設計書

これらの問題を克服してどのように定義と検証のサイクルを導入するか？

非形式な要求表現の多様性不明確な機能要件との関係

要求仕様の品質のつくり込み

ISO/IEC9126プロダクトの品質のつくり込み

開発現場で「定義と検証のサイクル」を実現するためには？

• 定義したものがある性質を満たすことを保証する

–定義言語

–検証方法

–学習コスト

–開発者の背景知識

–定義の観点・プロセス


定義は難しい…けれど保証がされる

定義は容易、けれど誤りを見つけるのは大変…

定義言語⇔学習コスト⇔効果

• 自然言語– 利点：学習コストがかからない・ソフトウェアの非専門家でも読める・どんな分野の要求でも表現できる

– 問題点：あいまいさがある・省略、多義語、定性的な表現がある

• 図式言語例えばUML– 利点：文章より容易に表現できることもある・学習コストが少ない、支援ツールを作り易い

– 問題点：表現範囲が限定される、曖昧さが残る

• 形式的な言語– 利点：仕様が正しいことの証明・仕様が等価であるかの判断ができる、段階的に変換して実行可能なプログラムへ

– 問題点：記述が間違っていればそれまで・学習への壁


モデル検査

• 有限の状態空間（定義）を網羅的に調べて、与えられた性質が成り立つか否かを調べる

• 成り立たない場合には、その理由となる反例を具体的に提示する

• 反例を解析すると、不具合の原因を探ることができる

• 上記の特徴を知っていれば、その仕組みを詳しく知らなくても、ブラックボックス化して使用できる


開発現場でモデル検査技術を利用するための課題とアプローチ

• 要件定義はわかりやすく、検証可能にしたい• 検証結果から問題点を解決したい• モデル検査ツールを直接使わないようにしたい

• UMLによるモデル駆動開発• モデル検査ツールを組み込んだ検証支援



要求分析モデルの定義学習支援システムLUMINOUSのBBS開発


何が段階的にわかるのか？


システム

プロトタイプでシステムの外側から見た応答

入力からこの手順で出力は得られるか

入力データ

出力データ

エンティティデータ

入力データ

出力データ

エンティティデータシステム

エンティティデータ

入力・出力を見極める

エンティティの候補は出てくる

エンティティが見えてくる

変換過程が見えてくる

更新されるデータはどこかで作られているか

UMLの利点と限界

• 振舞いモデルと構造モデルを容易に対応付けられる

• アクティビティ図では、アクション記述やガード記述、オブジェクトノード記述は自然言語なので、整合性をとるには注意が必要

• ユースケース全体でデータの不整合はないのかが確認しにくい


モデル検査ツール• モデル検査アルゴリズムに基づいたソフトウェア開発ツール

• 設計段階で利用

2014/5/22第2回産学連携のためのソフトウェア・シンポジウム

17

モデル検査ツール

システムモデル

検査式

反例

検査

シミュレータ

設計対象システムの振舞い⇒有限状態モデルで記述

システムが満たしてほしい性質⇒ 時相論理式で記述

入力

性質が成り立つ・成り立たない

出力

有限状態モデルの振舞いを提示シミュレーション

モデル検査ツールの利用• 多くの検査ツールがある SPIN SMV LTSA UPPAAL…

• システムの振舞いモデルと時相論理による検査式をどう書くかが問題

• 時相論理って？

• UMLのモデリングでもわかるように、要求分析段階ではラフなスケッチから段階的に定義することが必要

• 非機能要件は検討しながら機能要件の振舞いに導入している

• 記述の整理は？– アクション記述やガード記述の整合性

– オブジェクトノードの名前

• 検査式をどう導くのか？2014/5/22

第2回産学連携のためのソフトウェア・シンポジウム18

モデル検査技術

• 定義に対して、ある状態になるか、あることは起きないかといった形式で、その性質を満たすことを調べる（状態探索）

• システムへの要件– システムの振舞いにより実現すべき機能要件

– 振舞いや状態に対する制約や条件を表す非機能要件

• 機能要件 ⇔ 活性

• 非機能要件 ⇔ 到達可能性・安全性・公平性


検証できる性質

• 活性（liveness)– システムがある条件下で、将来いつか必ずある特定の状況が起こる

• 到達可能性（reachability）– システムが、初期状態から、ある特定の状態へ到達する可能性がある

• 安全性（safety）– システムが、ある条件のもとで、ある正当でない状況に陥ることが決して起こらない

• 公平性（fairness）– システムが、ある条件のもとである特定の状況が無限回起こる


モデル検査器

検査対象の振舞いモデル


検査式

検査

ツール支援

自動変換

不具合原因の分析と修正

シミュレータ

自動生成

検査したい性質

非機能要求

機能要求

接点を作り込む

1

2


反例


到達可能性・安全性のパターン

開発現場での適用シナリオと検査方法の事例

• 要件定義プロセスの場合– 機能要件をどう書くか？⇒ UMLでユースケース分析

– 機能要件に対して非機能要件をどう書くか？

⇒機能要件に登場するデータの性質をステートマシン図で定義– 定義したものがある性質を満たすことを保証する

⇒ユースケースモデルを有限状態モデルに変換し、モデル検査ツールを利用

⇒その性質に違反することはないという安全性の検査式を生成する


自動生成

検査式A 検査式B

自動生成

検査式の実行反例の表示


自動生成

・セキュリティ要件・永続化データの普遍的性質．．．

Class A

Class B

モデル駆動要求分析モデル

UML


フィードバックモデルの修正

開発支援ツール

要件定義プロセスでの検査事例

• 到達可能性

• 安全性

– システムの永続化データに対して定義した基本的な性質

であるCRUDの振舞いとシステムの全サービスを定義した

振舞いモデル間に矛盾が発生しない。

– セキュリティ属性が定義されたデータのセキュリティ属性

に関する基本的な性質に対して、システムのあるサービ

スがその属性に関する適切な振舞いを満たしている。

※「適切な」の意味は、セキュリティ評価標準規格であるコモンクライテリ

アによって定義


事例開発

① 大学院授業課題：大学生協教科書販売システム

② 授業で用いるグループワーク支援システムGWSS

③ 大学で運用しているLMS LUMINOUSの拡張機能(BBS)

④ 研究室内図書管理システム (2009年度版）

⑤ 研究室内図書管理システム (2011年度版）

モデル名 ① ② ③ ④ ⑤クラス数 110 162 58 33 45属性数 387 157 112 91 125

ユースケース数 11 13 9 6 7アクション数 390 315 183 119 138

サイクロマチック数の平均 22.9 28.2 14.9 15 12.3フローとアクション数の平均 106.5 85.7 56.1 64.3 58

要素数の平均 65.5 60.5 39.5 43.5 39.57


実験結果の分析

名称説明発見数

分岐判定記述漏れ業務セオリー上でReadの値あり／なしを非決定に決定する分岐が存在する場合に、それに対応したReadの値あり

／なし分岐を記述していない問題

10

分岐判定記述漏れによって発見されたモデルの問題

値あり／なしによる分岐判定を考慮しない事によって生じた、値なし状態でのUpdate／Deleteに関する問題

2

値ありフローの中でのオブジェクトのCreate問題

Createは値なし状態において作成させるべきで有り、値あり状態でのCreateでは、サービス期間中にオブジェク

トを作成されない問題

1

名称説明発見数

クラス間の関連・属性が解釈されない問題

クラス間の関連と属性を対象とする解釈機構が存在しない為、その意図を正しくモデルに反映できない問題

4

値なしが取り得ないRead

Readの結果が必ず値ありになる場合に対する問題。業務セオリーの定義はエンティティ単位にしか行えないが、オブジェクト単位に定義したい場合がある。

7

その他、定義ミス、定義漏れ等合計83個の発見


セキュリティ要件の検査

• これらのアクセスに関する規則を定義したい

• 必要な要件を正確に定義するにはセキュリティの知識が必要

• 知識のよりどころを利用 ⇒ 情報セキュリティの国際評価基準（ISO/IEC15408）であるCommon Criteria（CC)

• 機能要件モデルに対して、アクセスに関する規則をCCをベースに定義する

⇒ 機能要件のアクター・データ・アクションと規則を結び付ける


教員は必要に応じて、質問と回答をFAQとして公開できる非公開の質問は当人以外の学生には見えない

セキュリティ要件の検査


Common Criteria

ルールA アクション開始時，公開非公開=公開 ||投稿者.役割=学生.役割である

ルールB 表示されている話題は公開非公開=公開||話題.投稿者.役割=学生.役割である

ルールC アクション後，公開非公開=非公開になっている

ルールD アクション後，公開非公開=公開||非公開になっている

ルールE アクション開始時,公開非公開=非公開&&アクション終了時，公開非公開=公開である

ルールF アクション開始時,公開非公開=公開&&アクション終了時，公開非公開=非公開である

ルールG 表示されている投稿者は学生.役割=投稿者.役割である

セキュリティ機能方針(SFP)

規則セキュリティ属性

CCの用語の意味

アクタセキュリティ属性クラスセキュリティ属性ユースケースアクション FDP_ACF.1 FMT_MSA.3 FMT_MSA.1

話題公開非公開質問を投稿する話題を生成するルールB1日時質問を投稿する現在日時を取得する

話題を選択する(学生) 現在の利用者を取得する質問を投稿する投稿者を取得する

投稿内容話題を閲覧する(学生) 投稿内容を取得する話題を閲覧する(学生) 添付ファイルをダウンロードするルールA質問を投稿する添付ファイルを生成するルールB2

質問に回答する <質問番号>により選択された話題を取得する質問に回答する回答を追加して話題を更新する

話題の公開非公開を公開に変更するルールC1話題の公開非公開を非公開に変更するルールD1

日時質問に回答する現在日時を取得する話題を選択する(教員) 現在の利用者を取得する質問に回答する投稿者を取得する

投稿内容話題を閲覧する(教員) 投稿内容を取得する話題を閲覧する(教員) 添付ファイルをダウンロードする質問に回答する添付ファイルを生成するルールB3

添付ファイルの公開非公開を公開に変更するルールC1添付ファイルの公開非公開を非公開に変更するルールD1

・・・

・・・

話題公開非公開

投稿者役割

添付ファイル公開非公開

投稿者役割

添付ファイル公開非公開

教員役割(教員)

サブジェクトオブジェクト操作ルール

学生役割(学籍番号)

クラス図

要求分析モデル

検査式A 検査式B

自動生成

検査式の実行反例の表示UML


自動生成

開発支援ツール

クラス＋属性毎のデータの満たすべき性質

自動生成

フィードバックモデルの修正

アクティビティ図

OS(Windows/Linux)

JVM

UPPAAL(モデル検査器)astah*

UML2UPPAALユーザ操作

モデルデータ

検証

検証結果

支援ツール UML2UPPAAL


モデリングツールのプラグインUMLモデルを定義検査を実行反例をモデル上に反映⇒マークされたパス上で問題点を発見する

開発現場でモデル検査技術を利用するための課題

• 保守プロセスの場合– 定義したものはプログラム– Software Model Checkingには多くの事例がある– ソースコードを自動的に抽象化

⇒ソースコードの記述を読み解かなければ検査式は書けない⇒ 状態爆発が起きると、検査できない状態空間を抽象化する必要がある

– 機能要件に対して非機能要件をどう書くか？⇒ 仕様の定義が必要

– 「停止しない」といった観測できる現象をどう書くか？


保守プロセスでの検査事例

• ETロボコンプログラムへの適用– ドリフトターンと呼ばれるレース開始後に決定されるペットボトルの位置によって、ターンエリアの旋回ルートを変更するという難所の走行プログラムにおける不具合

– 現象：走行アクションの基点となるペットボトルの検出ができない

• Apache Commonsのバグへの適用• 会計伝票発行における無限ループ

到達可能性：制御により期待される結果が得られない場合に、すべての制御フローが全て通りえる状態であるかを検査する。検査式は、生成されたロケーションへの到達の検査であり、自動的に生成できる。

観測できる状態として「停止しない」ことを、無限ループのモデルを制御の条件式に対して設定することで、無限ループの発生を検査する。検査式は無限ループ状態のロケーションへの到達の検査であり、自動で生成できる。


UPPAAL検査器

ソースコード


検査式

不具合現象

仕様

ユーザ定義モデル

検査

Source2UPPAAL

段階的モデル化

手動定義

不具合原因の分析と修正

UPPAALシミュレータ

自動生成

保守プロセスにおける検証


反例


JavaAST

Parser AST

AST+

割り当て要素→

UPPAALモデルへの変換

UPPAAL

状態機械

システムシステムモデル


Abstract Syntax Tree

検査式検査式

Javaprojectクラス構造JavaClass

クラス構造JavaClass

ユーザ定義モデル

GUIメソッドの割り当て

値の割り当て

支援ツールの構成


Javaを対象EclipseのプラグインでGUIを実装

検査支援ツール Source2UPPAAL

• 探索空間を制限する仕組み

– メソッド単位で段階的に検査する

–非決定性の割り当て• 非決定値取得パターン「true のみ」，「false のみ」，「true もしくは

false」，「任意の数値」を用意し，モデル化対象項目にドラック＆ドロップする


まとめ• 高品質なプロダクトを効率よく開発するためにモデル検査ツールを用いて定義と検証のサイクルを導入

• 開発現場での適用シナリオ– 段階的に非機能要件を確認– 仕様を確認– 不具合現象を確認

⇒検査したいことを対象システムと関連付けて定義することが必要

※検査したい性質には対象システムの仕様に依存しないもの依存するものがある

• 開発者が品質を作り込むこと、何の品質を作り込んでいるかを認識することが重要

• 検証したいことを定義することの訓練• 教育と支援ツール


発表論文• Yoshitaka Aoki, Saeko Matsuura, Verifying Business Rules Using Model-

Checking Techniques for Non-specialist in Model-Checking, IEICE TRANSACTIONS on Information and Systems, Volume E97-D No.5, pp.1097-1108, 2014.

• 青木，小形，野呂，松浦、モデル検査技術を用いたセキュリティ要求の検証，ソフトウェア工学の基礎XX，日本ソフトウェア科学会FOSE 2013, pp.209-214, 2013.

• Y.Aoki, S.Ogata, H.Okuda and S.Matsuura, Data Lifecycle Verification Method for Requirements Specifications Using a Model Checking Technique, Proc. of The Eighth International Conference on Software Engineering Advances(ICSEA2013),pp.194-200, 2013.

• A. Noro and S. Matsuura, “UML based Security Function Policy Verification Method for Requirements Specification”, Proc of 2013 IEEE 37th International Conference on Computer Software and Applications, 2013, pp.832-833,2013.

• 松浦，ソフトウェアエンジニアリングシンポジウム2013 チュートリアル「要件定義プロセスと保守プロセスにおけるモデル検査技術の開発現場への適用」


発表論文• Y．Aoki，S．Ogata，H．Okuda and S．Matsuura，Quality Improvement of

Requirements Specification Using Model Checking Technique， Proc of ICEIS 2012，Vol.2,pp401-406，2012．

• S．Ogata，Y．Aoki，H．Okuda and S．Matsuura，An Automation of Check Focusing on CRUD for Requirements Analysis Model in UML Proc of ICSCE 2012，pp.1095-1103，2012

• 小形，青木，奥田，松浦，データライフサイクルの妥当性に着目したモデル検査ツールの自動利用法，電子情報通信学会，信学技報， vol.112， no. 314，KBSE2012-56， pp.109-114，2012．

• 青木，小形，奥田，松浦，要求分析におけるCRUD観点のモデル検査技術の適用，ソフトウェア工学の基礎XIX，日本ソフトウェア科学会FOSE 2012，pp．75-80．

• 谷沢，西村，青木，小形，松浦，Source2UPPAAL: ソースコードの効率的な検証へ向けた開発者支援ツールの検討，ソフトウェア工学の基礎XIX，日本ソフトウェア科学会FOSE 2012，pp．241-242， 2012

• 青木，松浦，開発現場を想定したモデル検査に基づくプログラムの不具合検証，電子情報通信学会KBSE研究会 2013年3月発表予定．



Documents

年度ソフトウェア工学分野の先導的研究支援事業 要件定義 ... · 2019-04-01 · システムへの要求の変化 想定外の不具合 ソフトウェア・アーキテクチャの特性

年度ソフトウェア工学分野の先導的研究支援事業要件定義 ... · 2019-04-01 · システムへの要求の変化想定外の不具合ソフトウェア・アーキテクチャの特性