トップエスイー修了制作

形式手法を用いた
高可用性クラスタ・システムのモデル化と検証
日本ユニシスグループ ユニアデックス株式会社 今泉 正雄 Masao.Imaizumi@uniadex.co.jp

システム設計における問題点

形式手法の適用による解決

ＨＡシステムの設計には，クラスタ・ソフトウェアの仕様や管理する各種リソースに対する，多くの知識・スキルを要する．またシステムが大規模化，複雑化すると，構築後の網羅的なテストも現実的でない上，それを補うべきモデル検証
も人手だけでは困難である．

クラスタ・ソフトウェアの仕様をVDM++により記述した． これにより，個々のユーザモデルが仕様において正しいことを，半自動で検査可能となった．また同じユーザモデルからPromelaモデ
ルを生成することで，ハードウェア障害時の動作についてもシミュレート可能となった．

VDM++によるHAクラスタソフトウェアの仕様記述
•
•
•
•
•
•

クラスタソフトウェアの仕様を，ユーザモデルの定義部，サービス起動等の動作部，ノードや各種リソー
ス等の環境部に分割定義 ⇒ ポータビリティの確保
定義部は，クラスタ，サービス，リソースタイプなどのクラス（ユーザモデルのメタクラス）として記述
モデルの正しさは，不変条件やメソッドの事前条件，事後条件として記述
ユーザモデルは，各クラスのインスタンスとして生成
ユーザモデルを複雑化させながら，仕様の正しさを確認，修正 ⇒ 制約を利用したテスト駆動開発
出来上がった仕様に基づき，本来のユーザモデルを検証 ⇒ 動的な検証はSPINを援用

インクリメンタルなユーザモデルの作成とテストを支援するＧＵＩツール

検証の流れ
1.
2.
3.
4.
5.

GUIツールによりユーザモデルを定義
ツールからVDM++のインスタンス，検証メソッドを生成
2のコードに必要なら手を加え，VDM++ Toolbox上で検証ツールからPromelaコード，検証用時相論理式を生成
4のコードに必要なら手を加え，SPIN上で検証

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

ゴール指向モデルを利用したソフトウェアテストの精度向上
日本ユニシス沖汐大志

motoji.okishio@unisys.co.jp

テストにおける問題点

手法・ツールの適用による解決

ソフトウェアの品質を確保するためには，ソフトウェアが要求仕様を満たしていることを網羅的に，かつ高い精度で確認する必要がある．
網羅性はテスト技法で改善できるが，精度については，要件定義書の完成度やテスト担当者のスキルへの依存が大きい．テストの精度向上に有効な技法があるわけではない．

要件定義書や設計書から得られる情報が不足している場合でも，ゴール指向モデルを作成することで，上位目標から要求までの関係を明らかにできる．
KAOS法のゴール指向モデルを利用して，テスト担
当者がテストの精度を向上する方法を提案する．

テストの精度向上手順
重要度の
高い要求
の選択，
情報収集

ゴール指
向モデル
の作成

ヒアリング

要件
定義書

重要要求
目次

要件定義

診断書に請求可能な内容がないかをチェッ
クしている

RVTM

論理設計

要求

WFシステム

テスト
条件

1

2

システム
テスト

期待値 設計との対応

2

結合テスト

テストケース表
3

元のテストケース

保険金を滞納していない（契約が失効していない）

契約時に不正（告知義務違反、架空契約）をしていない

契約者

営業員

単体テスト

・システム境界における精度の向上
・上位目標に対する精度の向上
・記述上の確認による精度向上

3

事務的な支払い
ミスがない

請求内容を
見落として
いない

特約が簡素
になってい
る

契約者が契
約内容を理
解している

契約内容の説明が分かりやすい

1

ID

物理設計

テストの
精度向上

契約者が、すべての請求可能な契約について請
求している

サブゴール サブゴール サブゴール
要求

要求とテ
ストケー
スの対応
付け

すべての契約・特約について請求可能性をチェックしている

ゴール

契約が約款に準拠しており、有効である

請求書が提出されている請求可能なすべての契約・特約に対して、案内を出している

要求

WEB・資料支払い漏れがない

関連
情報

重要な
要求

契約者が、契約について説明を
受けやすい

保険会社

要求に対応する要件定義書の項目を，
目次などを利用して関連付ける．
RVTM(トレーサビリティマトリクス)を利用して，要件定義書に対応する設計書の項目を関連付ける
テストケース表の設計書対応欄を利用して設計書に対応するテストケースを選
択する

精度を
向上した
テストケース＜条件＞
・「追加案内自動判定」の結果，保険金追加案内の「担当者判定待ち」と判定されるものが存在するとき，「担当者判定処理」の判定画面で「案内要」と判定した場合＜期待値＞「案内文書作成」処理に進むこと＜条件＞
・入院給付金を支払い済みの契約者が，通院給付金の請求も可能なとき，「追加案内自動判定」で保険金追加案内の「担当者判定待ち」となり，「担当者判定処理」の判定画面で「案内要」と判定した場合＜期待値＞「案内文書作成」処理で，通院給付金の請求案内を作成できること

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

UMLと実装モデル検査を組み合わせた導入コストの低い開発プロセスの提案
川上 真澄
Masumi KAWAKAMI

開発における問題点

手法・ツールの適用による解決（１）モデル検査適用コストが大・設計とは別に、検証用モデルを作成するコスト
・モデル検査言語の学習コスト（２）特性の保障に失敗するケース有・設計時：不適切な手動抽象化による検査失敗
・実装時：不適切な手動実装による誤り混入

UMLツール（Rhapsody®）と実装モデル検査（JPF）を組み合わせた開発プロセスを提案（１）少ない適用コストで、設計および実装を
モデル検査可能な開発プロセスを提案（２）モデル検査の知識がない設計者にも利用できるよう、検査方法をパタン化設計および実装をモデル検査可能な開発プロセス【設計工程】

一般的な開発手法

設計モデル（UML:Rhapsody）
クラス図【実装工程】

状態図

検証用実装（JavaTM）

監視 自動
クラス 生成実装モデル検査（JPF）

生成コード

検査用コード監視変数の取得＋機能動作内容

Rhapsody
実行ﾌﾚｰﾑﾜｰｸ

検査プロパティ[](機能_Start→<>機能_End)

自動生成
＋手動実装
実装
（JavaTM）①検査モデル作成不要⇒UMLとJavaTMの知識のみでモデル検査可能

実装モデル検査（JPF）
設計時の検査内容を再適用②設計および実装に対する同一検査実施⇒設計誤りの早期発見、実装後の特性保障

検査方法のパタン化【通常の機能的なテスト】
・ある条件で機能を動かして、機能が実行できることを確認（例：削除機能を実行するとファイル数が1減る）【本方式】
・機能実行時の進行性＋機能確認内容をJPFで網羅検査
・機能の開始/終了点を状態図で指定
機能開始イベント/
MC_機能_ED()
MC_機能_ST()
処理
監視クラス

ltl_flag=1;

本提案手法

ltl_flag=2;
file_num2=getFile_Num();

検査用コードif( ltl_flag==2 && file_num1-1==file_num2 ) return true;
検査プロパティ []（機能_Start→<>機能_End）

評価【従来手法との比較】
#

比較項目

SPIN

JPF

UML+JPF（本方式）

1 検査モデルの ×
○
○
作成コスト
Promela記述 56step追加 56step追加
2 設計時の
特性保障

△
手動抽象化

×
コード必要

○
UMLを検査3 実装時の
特性保障

×
実装と乖離

○
○
実装を検査 実装を検査【今後の課題】
・検査時の状態数削減（現状２スレッドの単純な問題で確認）
・設計モデルまたは実装から、検査したい機能に関連するモデルまたは実装をスライシング

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成
Javaに関連するすべての商標およびロゴマークは、米国 Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です
Rhapsodyは、世界の多くの国で登録されたInternational Business Machines Corp.の商標です。

トップエスイー修了制作

UPPAALを用いたリアルタイムシステムにおける設計・運用品質の向上手法
駒形 龍太

大規模システムの設計における課題

モデル検査の適用による解決システムを構成するプロダクトは多様化し、かつ、管理するチームも分散しており、システム全体としての品質確保が困難になっている。問題点の1つとして、プロダクトのパラメータ設計の不備により、障害発生時の原因究明までの時間が延伸するという事象が発生している。

プロダクト間の連携処理に影響する時間に関するパラメータ設計（タイムアウト値等）の整合性の確保のために、リアルタイムシステムにおける時間に関する性質を検証可能なツールであるUPPAALを用いて、設計時・運用時双方に適用可能な、品質向上のための手法を提案する。

UPPAALとは

モデル検査対象

クロック値を判定ロジックに用いて動作するようなシステムを表現可能なモデル検査ツールであり、作成したモデルに対して、”動作開始から60秒以内に処理Aを終えることができるか？” といったシステムの時間的性質の検証を行うことができる。

モデル検査は、ソフトウェア設計時に要求仕様の充足性の検証を行うために用いられることが一般的であるが、本手法では、更に、運用時の障害原因究明の手段として、モデル検査の適用を行う。

状態 ： s1

状態 ： s2

設計時作成したモデル

運用時

時間制約 ： A
アクション ： 処理B
例：制約Aを満たす時、処理Bを実行し、s1からs2に遷移する。

設計時のフロー

設計対象の
プロダクト

充足性検証

障害原因究明障害発生時のフロー

UPPAALモデル
によるモデル化システムで障害が発生

各プロダクトのエラーログを収集

設計モデルを利用しての障害の原因究明

ログからUPPAAL
モデルを自動生成

AG(x…)
AG(x…)
システムの
要求仕様

時相論理式
による表現

UPPAALを用いた検証

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

複数言語対応のソースコード処理系フレームワーク～テストカバレッジ測定への適用例～
早稲田大学 鷲崎研究室

坂本 一憲

kazuu@ruri.waseda.jp

開発における問題点

手法・ツールの提案による解決

ソースコードを対象とした処理ツールが言語依存で，言語毎にツールが存在する．そのため，ツールのP1)ノウハウ共有が困難な点，複数言語を用いるプ
ロジェクトでP2)統一的に利用できない点，新言語への対応等P3)開発コストが高い点，言語仕様の変更への追従等P4)保守コストが高い点で問題がある．

複数プログラミング言語対応のソースコード処理フ
レームワーク：OpenCodeProcessorFramework(OCPF)を提案する．共通処理/言語固有/処理系固有の３部分に整理して，処理系固有と言語固有を分けることで，S1)処理の実装を言語非依存，S2)言語の対応を処理非依存にする．さらに，共通処理を提供することで，S3,4)開発と保守コストを低減する．

Open Code Processor Framework の概要
共通処理部（コールドスポット） ：言語と処理系の両方に非依存．OCPFが想定する言語概念レベルの操作をインタフェースで規定（ステートメントの追加や削除等）．抽象構文木（AST）レベルの操作を提供（ノード追加や削除，置換）
言語固有部（ホットスポット） ：各プログラミング言語固有の処理．各言語の言語概念レベルでの操作を実装．
処理系固有部（ホットスポット） ：各ソースコード処理系固有の処理．提供される言語概念レベルの操作を利用．
高
抽象度
←

カバレッジ

メトリクス

C

カバレッジ測定C

言語概念レベルの操作

Java

メトリクス測定

Java

C

C#

リファクタリング

C#

Java

C#

低
→

抽象構文木レベルの操作

３×３＝９通りの実装

カバレッジ測定への適用例

int func(int a)
Statement

Function

int func(int a) {if (branch(0, a == 0)) {}else if (branch(1,false)) {stmt(1);
printf("a != 0");}stmt(0) Statement stmt(1) Statement
printf(”a == 0”)

printf(”a != 0”)３＋３＝６通りの実装

Python

2031
2000

1500

1056

90%
削減

1000

旧バージョンで評価• カバレッジ測定•開発コスト低減- 埋込処理のLOC- 90%程度削減

500

125

131

93

0

}
void stmt(int id) {RECORD_STATEMENT(id);}Statement

リファクタリング

Java

2500

stmt(0);
printf("a == 0");

メトリクス測定

OCPF

適用例への評価

LOC [ 行 ]int func(int a) {if (a == 0) {printf("a==0");}
else if (false) {printf("a!=0");}
AST上で挿入}カバレッジ測定

測定用コード•自動的に挿入•カバレッジ情報出力•副作用なしCobertura

EMMA

OCCF(Java)SCP OCCF(Python)

実装内容

達成数

平均時間

新カバレッジ追加(OCCF)

4人

Python3への対応(OCCF)

4人

新カバレッジ追加(SCP)

0人•機能拡張実験- Python2への
13.5分
新カバレッジ
47.5分- Python2から
4時間以上
Python3へ変更

Python3への対応(SCP)0人―

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

モデル検査技法を用いたマリシャスコードパターンの分析
JPCERT コーディネーションセンター

椎木 孝斉

takayoshi.shiigi@jpcert.or.jp

セキュリティ上の問題点

手法・ツールの適用による解決

・近年、インターネットセキュリティインシデントの多くがマルウエアに関連するものとなっており、その対応が大きな課題となっている。
・マルウエア対策を行うためには、その脅威を明らかにするために分析を行う必要があるが、マルウエアの分析（特にコード分析）は難しく、必要な知識の蓄積、共有も十分ではない。

・マルウエアのコード分析（静的分析）に必要な情報（マルウエアの挙動の特徴、分析ノウハウ等）をパターン（Malware spec pattern）として整理された形式で、作成、蓄積する。
・作成されたMalware spec patternについて、分析対象のマルウエアがその性質を満たすかど
うかをモデル検査技法を用いて検証する。

提案手法の概要
Malware Spec Patterns

Malware特徴の抽出、整理、蓄積[Name][Class][Objective][Related Patterns][Keyword][Formula]

検証性質
として
入力
Model
Checking

結果出力

Assembly Code

ディスアセンブル

Malware Spec Patternの例[Name]

Downloader[Class]Common malware behavior[Description]

Malware download program from remote siteand execute it. .....

[Objective]- To achieve initial attack smart....

[Related patterns]
Write exec

[Keyword]

URLDownloadFileA
WinExec | CreateProcess | ShellExecute[Formula]and @apicall(URLDownloadFileA(0, [_], [x]))(EX EU @noassign(x) @@Exec(x))…
push 0lea ecx, [ebp+NewFileName]
Call ds:WinExec

検証対象
グラフに変換期待される効果・マルウエアの挙動の特徴や、分析ノウハウ等を様々なパターンとして、再利用可能な形で作成しておくことで、マルウエア分析に関する知識の蓄積、共有が可能となる。
・マルウエアのコード分析（静的分析）とモデル検査技法を組み合わせた検査を行うことで、より効率的、効果的なマルウエア分析を実施することが期待でき、対策に役立てることができる。
・今回提案する手法を分析者や技術者が使い易いツールとして実装することで、形式手法やモデル検査技法といった手法の当該分野への適用を進めることができる。

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

セキュリティ要件定義のためのゴール指向モデリ
ング手法
東芝ソリューション株式会社

斯波 万恵

Shiba.Masue@toshiba-sol.co.jp

開発における問題点

手法・ツールの適用による解決

セキュリティの要件定義には以下のような課題があった．

・脅威分析を行わない／システムへの要求によるセキュリティ要件定義モデルが必要
・セキュリティ対策と機能要件のパターンが必要
・セキュリティ要件定義のための操作モデルが必要

・脅威分析工程が重い
・セキュリティ機能要件の抽出が難しい
・CC Part2 コンポーネントの個々の要件化（操作）が難しい・システムへの要求や機能からセキュリティ要件を決定する手法がないセキュリティ要件定義のメタモデルにゴールを拡張し，ＫＡＯＳのゴールモデルと操作モデルのオブジェクトにステレオタイプで新しいモデルを与えた．

提案するゴール指向モデル
メタモデル

ゴールモデル

Function
Security
FunctionTargetSystemGoal Model(Pattern)

Security
Requirements

Asset

Actor

AssumedThreatThreatObjective

Assumption

Operational
Environment

Goal

Policy(OSP)
Goal Model(each system)

Each system

提案モデルの適用例

セキュリティゴール
データの機密性

サービスの機密性

データの完全性

サービスの可用性データの可用性

サービスの追跡性

Pattern

セキュリティ要件定義ツール
要件定義利用者のプライバシ

作成したゴールモデルのパターンを用いて、ゴールからSFRs(セキュリティ要件）を選択するツールを開発した．

□データの機密性□データの完全性□データの可用性□サービスの完全性□サービスの可用性□サービスの追跡性□利用者のプライバシ•RFP(提案依頼書)•セキュリティ課題•セキュリティレベル課題
input

セキュリティ
要件定義ツール
情報システム
に必要なセキュリティ
目標設定

操作モデル

ISO
13335

仕様書生成ツール

セキュリティ要件
セキュリティ
要件選択

outputセキュリティ
要件の仕様記述

output
要件定義書 など

□識別認証
□利用者認証□認証の秘密情報□認証失敗□監査□監査データ生成□監査分析□アクセス制御

ゴール
モデル

ISO
15408

ISO
19791

ISO
27002

セキュリ
ティ管理
基準

セキュリティ
要件群

選択したSFRs(セキュリ
ティ要件）は，操作モデ
ルを用いて個別の要件として定義する．

セキュリティ基準、標準類

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

ユーザ企業におけるゴール指向要求分析法の導入とテスト効率化手法の提案
鹿島建設株式会社

清水靖則

yshimizu@kajima.com

開発における問題点

手法・ツールの提案による解決

曖昧で整理されていない要求分析は、開発中の手戻りによる納期遅延、リリース直後の追加
開発、継続的な修正対応を招く。また、不十分な総合テストは、リリース後の不具合対応を招く。
これらの工程を主体的にかつ確実に行うことはユーザ企業側の役目であり、さらに機能や運用コスト低減策の提案が求められている。

要求分析では、ゴール指向要求分析手法KAOS
をベースに、分析の手助けを行うガイドセンテン
スの作成を提案。また非機能要求の早期意識付けのためにFURPS+の取り込みを行った。
総合テストでは、要求仕様書からテスト仕様書を自動作成する、テスト項目自動抽出ツールを使用した。

KAOS＆FURPS+による要求分析手順とテストの効率化

ソフトゴールにガイドセンテンス
を当てて提案機能を導出
操作モデルにFURPS+
非機能要求の意識付け
要求分析
総合テスト

設計
→ 製造
→テスト

KAOS
ゴールモデル

KAOS
責任モデル
操作モデル

テスト計画書テスト仕様書
兼結果報告書FURPS+

ユースケース
図/記述

テスト実施

要求仕様書IEEE
Std.830

テスト項目
自動抽出ツール
テスト仕様書が約5分で完成要求仕様書の修正漏れに気付く（効果）テストフロー図

テスト仕様書【今後の展開】
・KAOS用ガイドセンテンスの充実。要求分析の経験を抽象的なガイドセンテンスとして蓄積していく。
・ゴール指向要求分析と非機能要求分析を合わせたモデリング手法の更なる探求。
国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

状態遷移表のモデル検証自動化ツールの開発（株）東芝 ソフトウェア技術センター

高田 沙都子satoko.takada@toshiba.co.jp

開発における問題点

モデル検証自動化ツールの開発

近年、高まりをみせているソフトウェア品質の向上への施策としてモデル検証が着目されている。
しかし、独自の記述言語や時相論理といった専門的知識が必要な点や人手によりモデルを作成することで検証結果を得るまでに時間を要す
る、といった点がモデル検査を開発現場へ導入、展開する際の足かせとなっている。

状態遷移表から検証用モデルを生成し、モデル検査を実行する作業を自動化し、更に時相論
理の知識が必要とされる検査式作成を支援する機能を加えたツールを開発した。これにより、モデル検査経験のない開発者でもモデル検査
適用への敷居を感じることなく取り組むことができるようになった。

モデル検証の流れと開発ツールの概要
開発目標範囲

ツールによって作業の一部を支援・自動化する

今回開発した個所

ツールによって自動化された個所
イベントA イベントB イベントC イベントD イベントE イベントF イベントG イベントH イベントI

状態1

状態2

状態７

－

－

－

アクション２

アクション２

アクション２

アクション２

状態遷移表
作成支援
－

－

アクション２

アクション２

－

－

－

状態１

アクション１

アクション２

－

－

－

－

－

－

状態２

アクション２

アクション２

アクション１

アクション１

アクション１

アクション１

状態3

アクション２

状態4

アクション２

－

－

状態７

－

－

－

状態１

状態5

アクション２

アクション２

アクション２

アクション１

アクション１

アクション１

アクション１

－

－

－

－

－

－

状態４

アクション２

アクション２

アクション２

アクション１

アクション１

アクション１

アクション１

人手でモデルや検証式を書いていたため時間と知識が必要だった

・・・

モデル検査実行

・・・
・・・
・・・
・・・

・・・
・・・

言語
知識

・・・
・・・
・・・
・・・

状態6

・・・

検証用モデル生成

反例解析

・・・
・・・
状態7

数学
知識

検査項目
起動後、一度は状態pがSTATE_1,状態qがSTATE_4という状況が成立すること

検証式生成<>(p && q)#define p p_state == STATE_1#define q s_state == STATE_4

SPIN

解析
ノウハウ

ツール使用法

開発ツールの特徴

ツール適用の効果

パネル操作で検証式や検証用モデルを生成後、検証を実行

実際の事例を適用•

二重化構成による冗長性を持たせたシステム––

規模状態遷移表：約300セル（状態×イベント）
Promela行数：約500行

検査結果獲得までの時間が短縮された
これまで…

モデルや検証式の記述方法、ツールの使い方を習得した上でモデル検査を実行

状態遷移表と変数定義を入力すればパネル上でモデル検査が可能

検証––

開発ツール未適用

開発ツール適用

約30日

約1日

ツールの使用方法や言語習得が不要
モデルが自動生成されるのでケアレスミスの混入がない

専門的知識を意識せずに検証が可能–

簡単なGUI操作で結果を取得できる

モデル検証経験のない開発者でも取り組みが容易になった

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

スケジュール管理Webアプリケーションへのアスペクト指向プログラミングの適用
竹澤 亮

NTTコムウェア株式会社

takezawa.ryo@nttcom.co.jp

開発における問題点

AOPの適用による解決
アクセス制御機能の追加開発を題材として、アスペ
クト指向プログラミング(AOP)を適用。
・横断的な関心毎をアスペクトとして設計・実装。既存に影響を与えずに、予期せぬ追加機能(アクセス制御)を達成。
・設定ファイルにてアスペクトの追加・取り外しが可能になり、提供先毎に最低限の機能を提供できる。

Webアプリケーション開発における以下の課題について取り組む。
・予期していない変更・機能追加への柔軟な対応
・既存部分に横断的にまたがる機能追加への対応
・提供先毎に異なる要求への対応

適用の概要
スケジュール管理Webアプリケーションに、アクセス制御機能をアスペクトとして追加。
ポイントカットによって絞り込まれた、
挿入能な位置(ジョインポイント)にアドバイスを織り込む

本質
予定管理
ユーザ管理
グループ管理Bさんの情報を更新 NG

横断的関心毎(アスペクト)

予定管理

アドバイス

ユーザ管理

アクセス制御適用の評価と課題

ポイントカット(設定ファイル)
XX管理の作成メソッド
呼び出し時に挿入試作した適用支援ツール○予期せぬ横断的な機能追加に、母体への修正なしで対応できた。
○取り外し・交換可能な状態に分離できた。
○本質・アスペクトの個々について見通しが良くなった
クラス

メソッド

ライン(LOC)

設定ファイル

適用時

0

0

0

大 (約400行)

未適用

5

30

50～100

小 (数十行)

修正数

×全体を結合した状態で、矛盾無く動作するか、把握しづらい。
×設計段階でのレビューや、試験項目作成が困難に。
△設定ファイルの肥大化。

グループ管理アクセス制御OK

Aさんの情報を更新

Weave

ユースケースをコードと同様に
織り込む。
Weave

結合ルール
（設計ドキュメントをCSV出力したもの）

ユーザを作成する, DBを更新する,
アクセス制御(禁止)

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

インクリメンタル型
ソフトウェア開発の品質予測
富士通株式会社

竹田和正

takeda.kazumasa@jp.fujitsu.com

インクリメンタル開発の品質予測

欠陥除去率の予測モデルを構築
・欠陥除去率の予測モデルを構築することで開発途中の残存欠陥数を可視化する・ウォーターフォール型プロセスでは
品質予測モデル*が確立している*ソフトウェア信頼度成長モデルやレイリーモデルなど

・インクリメンタル開発プロセスに適用可能な
品質予測モデルを構築することで適切なプロジェクト制御を可能とする・インクリメンタル型開発プロセスにおいて予測モデルをそのまま適用することができないモデル化のアプローチ
右図のとおりの手順を繰り返す① メトリクスデータ分析（実測データ分析）② 予測モデル構築③ 検証（シミュレーション）

1st開発
設計

製造

試験

2nd開発

リリース毎の欠陥除去率（DRE* : Defect Removal Efficiency ） に着目* DDR = リリース前欠陥数÷（リリース前欠陥数＋リリース後の欠陥数）
 欠陥作り込み密度 （DID * : Defect Injection Density）* DID = 欠陥数÷開発規模
各リリースにおける追加の開発規模と摘出した欠陥数（残存欠陥数）との関係に着目
最終リリース（出荷）における残存欠陥数（＝顧客評価で検出される欠陥）を予測する

n 開発

動的な品質予測による
プロジェクト制御に活用

3rd開発②予測モデル
構築

測定(収集)

・開発規模
・検出欠陥数etc.

①④メトリクス
データ分析(実測データ分析）

現在の開発プロセスで収集しているメトリクス
データを残存欠陥数の予測モデルへ適用する

修了制作
取組対象

繰り返し

③検証
(ｼﾐｭﾚｰｼｮﾝ）

モデル構築とシミュレーション結果
1.0
欠陥除去率（予測値）

・リリース毎の開発規模と欠陥除去数から残存欠陥数を予測することが可能である.
・プロセスパラメータ(DRE,DID)を目標値とした品質制御が可能である.

欠陥除去率

欠陥除去率（実績）
0.9

0.8

0.7
0.0

0.5

1.0

1.5

当該リリース開発行数に対する累積追加コード行数の比率

残存欠陥数の予測シミュレーション
200
実測値に基づく

残存欠陥数の予測値①シミュレーション作成ツール*により残存欠陥数を予測するモデルを構築
リリースid, 開発規模, リリース前後の摘出欠陥数, 欠陥除去率(DRE),
作り込み欠陥密度(DID),から、残存欠陥数の予測値分布を生成した.
*GeNie （ネットワークモデル化ツール）使用②実測値データから欠陥除去率を予測するモデルを構築
実測値（欠陥除去率）を外接する指数型モデルとして定式化した.
⇒ 一般の欠陥発見モデルにしたがった③累積追加開発規模比率を使用して, 欠陥除去率を予測するモデルを構築②をリリースidではなく, 累積追加した開発規模比率を説明変数としてモデル化した.

シミュレーション #4

150

シミュレーション #1
100

50

0
1

2

3

4

5

6

7

8

9

経過リリース数

評価結果

今後の展開

インクリメンタル開発プロセスにおける品質予測のモデル化が可能であることを検証できた.
リリース途中の品質傾向が可視化可能となり, プロジェクト制御に耐えうる（メトリクスとして有効）レベルであることが検証できた.
出荷後の品質評価が定まった（欠陥数の検出が収束した）時に,シミュレーション結果の最終的な評価を行うことでより精度の高いモデル（静的モデル）の構築が可能となった.

リリースid, 開発規模, 欠陥除去率から残存欠陥数を予測した⇒ さまざまなプロセス要因*を加味することで, プロジェクト の実状にあった予測モデルへ発展させることが可能.
*プロセス要因:プログラム階層,経験値,工数,仕様変更量etc.
 ベイジアンネットワークモデルへの本格適用⇒ メトリクスデータから確率分布を推定（学習）する試みを行うことでモデル化できないか.

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

Promela における割り込み制御の半自動モデル化
フェリカネットワークス株式会社

只野 賢二

Kenji.Tadano@FeliCaNetworks.co.jp

開発における課題

本研究の提案

ファームウェアの品質向上手法として，モデル検査を導入するにあたり，C 言語のソースコー
ドをモデル記述言語である Promela に変換(モデル化) する必要がある．
モデル化の過程で，割り込み制御情報をモデル化する必要があり，割り込みの数が増加するにつれて，モデル実装者の負担や実装中のミス混入が懸念される．

モデル実装者の負担軽減，実装中のミス混入軽減をするために，以下を機械的にモデル化する手法を提案する．
•多重割り込み•割り込みマスク※ 上記 2 つが割り込み制御情報のモデル化を複雑にする原因である．

研究の概略
従来のモデル化

提案手法によるモデル化

割り込み制御情報

割り込み制御情報(HWマニュアル等)(csv形式)

ソースコード

割り込み制御有りモデル

ソースコード

割り込み制御無しモデル

割り込み制御有りモデル( C言語 )

( Promela )( C言語 )

( Promela )( Promela )

手動変換

手動変換

自動変換

(割り込み制御情報を考慮)(割り込み制御情報を考慮せず)

本研究のスコープ→ 割り込みの数が増加するにつれて，変換が複雑化

→ 人手で割り込み制御情報を考慮せず，変換が可能

実システムへの適応
モバイル FeliCa IC チップを本手法によりモデル化

まとめ
本研究で行ったこと
・多重割り込み，割り込みマスクを考慮した割り込み制御情報を半自動でモデル化する手法を提案・提案した手法を自動にて行う，変換ツールを作成し，ツールの妥当性を確認
・実システムへの適応による，有効性の確認

今後の展望
・規模のより大きいモデルへの適応
・複数割り込みが同時に動作する場合の考慮→ 検証項目「いつか必ず RE == 1 となること」を確認

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

Webシステムにおけるデータ項目の抽出とチェックの仕組み検討
塚本 純一

tukamoto@sysmic.jp

開発における問題点

手法・ツールの提案による解決

Webシステム改修による品質の低下が発生することがあり、原因の一つとして同時に修正しなければならない
部分の修正が漏れてしまう。
Webシステムには多くのデータ項目があり、データ項目の状態をチェックできればよいが、扱うデータ項目は多いことと、複数のデータ項目を持つオブジェクトが多く存在しているため、チェックするのが大変である。

複数のデータ項目を持つオブジェクトを抽出し、チェックするツールを提案。
このツールを、データ項目をオブジェクトから使用する際に、アスペクトで挟み込む。

データ項目の抽出とチェックの仕組み
データ項目の抽出

データ項目のチェック

JSPからデータ取得の：Object obj = request.getAttribute("person");mapとして抽出したデータのイメージ

Item name
(項目名)
name
age
address

Key(項目名) value(値)

このオブジェクトが保持しているデータの抽出を行う。
mapとして抽出したデータのイメージ

Key(項目名)

value(値)nameageaddress

name127
aaaa@xxx.jp

データ項目が持つ項目名、値をマッピングするオブジェクト(map)として抽出する。
このmap化を一度行うことによってチェックメソッドは専用のメソッドを用意せず統一してチェックすることができる。

アスペクトの挟み込み

name
age
address

Xmlに定義されたデータ項目情報のイメージ

name1
27
aaaa@xxx.jp

data type(データ型)
stringnumberstring

Digit
(桁)
40
3
80

チェックは、日付、数値、文字列等の各項目でチェックを行いたい内容のチェックメソッドを用意し、mapとして抽出したデー
タのデータ項目とXmlファイルで定義された内容を照らし合わせることでチェックを行う。

まとめ

コードの例
public void execute(ActionMapping map,
HttpServletRequest request) {…
if(request.getAttribute("update.flag") != null) {Object obj = request.getAttribute("person");…
}…
}・達成されること
Webシステムでは、１つのオブジェクトに複数のデータ項目を入れることが多いので、そのデータ項目をチェックする考え方。
オブジェクトが取り出される時にアス
ペクトによる処理の挟み込みを行う。

データ項目の抽出とチェック実行
データ項目の抽出とチェックをシステムの処理とは別に切り離して実行される。

・達成できていないこと
現時点では「方針・考え方」であって、「ライブラリ・フレームワーク」までは作りこんでいない。
また、チェックをアスペクトで挟み込む
タイミングは別途検討が必要。

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成

トップエスイー修了制作

組込みシステムコア資産の作成手法の提案
所属 三菱電機マイコン機器ソフトウエア株式会社
名前 徳弘 雄亮 メールアドレスtokuhiro@mms.co.jp

開発における問題点

手法・ツールの適用による解決

プロダクトライン開発において、非機能要求の変更によりアーキテクチャの変更が発生した。
アーキテクチャの変更は、コア資産の使用を制限され、プロジェクトの失敗を発生させる。非機能要求の変更に対応できる、アーキテクチャの開発が必要である。

変更に対応するためには、詳細な部分で非機
能要求と機能要求が対応しておく必要がある。
詳細な部分まで要求を分析するために、ゴール
指向要求分析であるKAOSを使用した。KAOSで分析した要求からフィーチャーモデルを作成し、コア資産を使いやすくするために、コンポーネン
トベース開発のKobrAを使用し、コンポーネント化した。

ゴール指向要求分析(KAOS)の成果物
機能要求

非機能要求

機能要求と非機能要求の対応付け

要求分析から設計までの対応
cmp コン ポ ー ネン トモデ ル

KAOS

KobrA
非機能による機能の可変する
構造を記述

コー ス取得機能

非機能要求と機能要求の対応付けの手法
KAOSによる要求分析
ゴール指向要求分析
AND/ORによる階層構造
共通部分と可変部分の分析が可能
具体的なゴールをトレースできる分析が可能

コー ス判断機能

KAOSからの拡張点
非機能要求の具体的な実現手法の分析
非機能要求を実現する機能要求の追加

ライン 検知機能<<<<VariationPoint...
特殊走行検知機能

フィーチャーモデル
コース
共通部分と可変部分を 取得機能
表示
コース
判断機能
ライン
検知機能

特殊走行
検知機能

時間
検知機能
距離
検知機能

<<<<Variat>>>>マー カー 検知機能<<<<Variat>>>>
時間検知機能ゴール検知機能

ゴー ル検知機能<<<<Variat>>>>
距離検知機能非機能要求の対応前
非機能要求の変更が、複数の機能要求に影響変更がアーキテクチャの構造に影響を与える
非機能要求の対応後
非機能要求の変更が与える影響が明確
機能コンポーネントの変更で対応が可能

マーカー
検知機能

国立情報学研究所
トップエスイー
トップエスイー： サイエンスによる知的ものづくり教育プログラム
National Institute of Informatics～サイエンスによる知的のものづくり教育プログラム～
文部科学省科学技術振興調整費
産学融合先端ソフトウェア技術者養成拠点の形成