TopSE修了制作

要求仕様の精度向上の試み～シミュレーション投入システムへの適用～

キヤノン株式会社
井上拓
inoue.taku@canon.co.jp

1

対象領域


シミュレーション投入システム
ブラウザ経由でシミュレーション投入
シミュレーションはWebServiceでI/Fされている
 BPELで記述した連携手順を実行

基本機能の開発は既に完了
 次バージョンで大規模運用機能を開発予定
Job（複数のBPELプロセス）投入
ユーザ
invokeStart

SwitchEndFork

シミュレーション
実行
計算ノード群（WebService）

invokeBPELスクリプト2

従来開発の課題


開発後半に要求仕様の追加・変更が頻発
仕様の抜け・矛盾によるものが6割強（特にデータ不整合が顕著）
 アーキテクチャの大幅修正／予期せぬ追加開発を招いていた


仕様項目数

仕様追加・変更の内訳

ユーザ
要望

仕様の抜け・矛盾

プロトタイプ

本開発期間（当初予定）

追加開発期間（想定外）

精度の良い安定した要求仕様モデルを確立したい！
3

従来の開発プロセス


要求仕様の精度不足に起因する手戻りが大ボトムアップ的なOOアプローチ、データ制約の発見が個人のスキルに依存

クラス図／シーケンス図／状態遷移図では表現しきれないケースあり



レビューで発見できなかった仕様バグが後工程／次Iterationで発覚

要求管理の粒度が荒い


後工程の進捗管理や実装の優先度付けに不十分
仕様矛盾

データ不整合ユーザ
仕様漏れ フィードバック

要求仕様作成ボトムアップOO

レビュー
UML

アーキ設計
詳細設計

要求管理

実装

Excelリスト（機能仕様）

テスト

リリース

4

試行した開発プロセス

複数の仕様モデリング方法の併用


UML-Components： 安定したアーキモデルを早期に構築

レビュー： 従来開発と同様にUMLモデルに対して実施



OCL： データの整合性を分析



VDM++モデリング／テスティング： 形式記述により仕様の妥当性を確認
設計以降の工程は本発表の範囲外

要求仕様モデル間のトレーサビリティの確保


要求管理リストの活用
ユーザフィードバック
要求仕様作成UMLComponents

レビュー

OCL

VDM++
モデリング・テスティング

アーキ設計
詳細設計

要求管理

実装

テスト

リリース

Excelリスト（機能仕様＋制約）
5

UML-Components

軽量なコンポーネントベース開発方法論


データ指向のアーキテクチャ構築に有効

要求⇒仕様（⇒提供⇒組み立て⇒テスト⇒配備）

独自の工夫点Coreタイプ抽出時にモデルを正規化し、データ間の依存関係を明確化

ライフサイクルを考慮したコンポーネント分割（分散協調モデル）

正規化

ビジネス概念モデル

ビジネスタイプモデル

6

レビュー（UML-Components）


出席者： 社内の開発チームメンバ＋外部委託先
ドメイン知識は豊富

初回レビュー時にUML-Componentsについて説明、抵抗なく受け入れられたレビューで発見されたモデルの抜け/制約

ユースケースレベルの抜け

複数IFに跨るシナリオでの抜け

実装上の制約（Webコンテナの仕様など）

広範囲を効率的にチェック可能

要求管理リスト（Excel）の有用性


UMLモデルだけではレビューア毎に異なる解釈をする場合がある

自然言語による文書化＋口頭説明は必須



モデルの根拠、対案は記載必須

7

OCL


オブジェクト制約言語


UMLモデルに制約事項を追加することが出来る抽出した制約分散DBに保持されているデータ間の整合性
 オブジェクトの同一性ではなく属性の同一性で制約を表現

例：システムリソーススケジュール設定中の全てのプロジェクトがActiveである

別々のDB

context マシンスケジュール設定情報ベース::
changeSysResSchedule(システムリソーススケジュール設定)
pre: システムリソーススケジュール設定.
ノード割り当てinシステム.割り当てプロジェクトs->forall(elem| I_プロジェクトMgt.Actives->
exists1( prj | prj.プロジェクトID=elem.プロジェクトID))

OCL記述
UML記述（クラス図）

8

VDM++


状態型の形式仕様記述言語


Explicitなモデルを実行することにより仕様のテスティングが可能

UML-Componentsモデル→VDM++の変換ルールを定義

①
②
③
④⑤




UML-Components上の表現
VDM上の表現
システ ム インターフェース,
抽象Class
ビジ ネスインターフェース
Comp spec
具象Class
Coreタイプ,typeタイプ
Class（属性は全てPublic）
String, Int等、
Token型
Map
多重度が多の関連抽出した仕様バグ
組み合わせパターン（設定値、状態）の漏れ



複数ＩＦに跨るシナリオ／時系列的な制約の抜け

VDM++モデリング・テストの効能仕様カバレッジを計測できる

実際に動かして検証できるロジックの抜け・思い込みの防止に有効
9

要求管理



要求管理リストを用いてモデル間のトレーサビリティを確保

モデリングによって詳細化された要求仕様を、リストに反映



各モデルに要求管理IDを保持

設計・実装以降の工程での進捗管理にも利用

仕様の詳細化により、管理精度が向上~~~~~~~~~~~~~~--WSEX_04_01~~~~~~~~~~~~~~~~~~~~~
OCL記述~~~~~~~~~~~~~~~~~~~~~--WSEX_04_01~~~~~~~--WSEX_04_01~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

各種モデルの有無

OCL・VDMにより詳細化された仕様項目
仕様ID
WSEX
WSEX_01…
WSEX_04
WSEX_04_01
WSEX_04_02
WSEX_05

カテゴリ
内容
サービス実行

備考

関連ID

優先度付け・
進捗管理に利用

UML OCL VDM Test…
…
計算ノード側で、リクエスト内容／ノード状態／スケジュールポリシーが整合していることを確認する
リクエスト元のプロジェクトが、該デプロイWSのオーナプロジェクトか実行可能プロジェクトのいずれかと【理由】…
一致する必要がある
単体テスト用のWS実行数が、ノードスケジュール設
定中の上限値未満かチェックする。
【代替案】…

優先度 ステータス
…
…

…
…

X
MSCH_01

X

X

X

高

実装済み

MSCH_01

X

X

X

中
…

設計済み
…

…

要求管理リスト
VDM++記述・
テストコード10

仕様の精度とモデル作成工数


仕様項目数（≒精度） ⇒ 従来の約1.8倍



モデル作成工数



仕様の精度向上を実現、ただし工数との間にトレードオフ

期待効果： 設計以降の手戻りレスにより全体の開発期間が短縮⇒ 従来の約2.5倍

レビュー

仕様の追加・修正 累計項目数

UML-Components+レビューを従来プロセス相当とした場合

要求仕様
1st Iter. 2nd Iter.
作成

Mth Iter.

Nth Iter.

UMLComponents

050

100
工数累計（ h ）150200数（累計）項目

VDM++モデリング／テスティング仕様

OCL

1st Iter.
要求仕様
作成

2nd Iter.

試行プロセス
従来プロセス

最終仕様の半数以上が開発途中で追加／変更されている

時間軸

11

まとめ

モデリング手法の併用により要求仕様の精度向上が可能

ドメインの性質やプロジェクトの日程制約を考慮したテーラリングが必要

今後の展開： 組み込み領域への適用検討（並行性・HW要件を考慮）
開発フェーズ

高
導入コスト

モデル検査
・証明

低

並行性・厳密性
VDM

仕様網羅度の計測
データ制約（複合）OCL

データ制約（IF単体）
ユースケースの抜け
理解容易性

VDM VDMテスト レビュー

OCL
レビュー

UML
UMLレビュー
Components

概念モデルの作成
要求管理12

End13