汎用グラフィカルモデリング言語「SysML」 パート1: 要件、ユースケース、およびテストケースのモデリング:The Rational Edge(3/3 ページ)
The Rational Edgeより:3回にわたってお送りする本シリーズの第1回では、まず製品・システム開発用の汎用グラフィカルモデリング言語であるSystems Modeling Language(SysML)の概要を説明する。パート1ではSysMLの要件、ユースケース、およびテストケースの各ダイヤグラムを解説する。
◆ 要件ダイヤグラム
上述のように、開発ライフサイクルのコンセプト段階は、製品要件へと進化する顧客のニーズ分析とは分離している。要件は従来から、テキストと、しばしば図表を交えて描写され、ファイルあるいはデータベースに保管されていた。これらの要件は、製品の機能すべてのほか、その機能を実現する際の制約も記述している。
SysMLでは、要件をモデルの要素として描写できるようになる。従って、要件は製品アーキテクチャにとって欠くことのできない部分になる。同言語は、テキストベースのあらゆる特性の要件(機能要件あるいは非機能要件など)と、それらの間のリレーションを描写する柔軟な手段になる場合が多い。図3にRSWの要件ダイヤグラムを示す。
要件ダイヤグラムには、機能要件と非機能要件の両方があることに注意したい。SysMLにおける要件は、オペレーションも属性もない抽象的な分類子だ。つまり、これらはインスタンス化することができない。にもかかわらず、要件ステレオタイプに属性を登録することで要件の要素に属性を登録することはできる。ステレオタイプの属性を使えば、これらの属性に設計時に値を割り当てることができるようになる(注1)。要件はアソシエーションもしくはジェネラリゼーションに参加することができない。しかし、あらかじめ定義された一連のリレーションがあれば、要件間のリレーションを描写する際に役立つ。これらのリレーションについては以下で解説する。
サブ要件は、ネームスペースが埋め込まれていることを示す十字のリレーションを使って、その親要件と関連付けられる。例えば図3では、Automatic Wiping要件のサブ要件の中に、この十字を使って接続されているものがいくつかある。親要件は、組み込み要件のパッケージになっている。このようなことから、親要件を削除すると組み込み要件はすべて自動的に削除される。ほかの要件のパッケージとして機能している要件のもう1つの例が、2つのサブ要件を含むCore Functions要件だ。モデルを見やすくするために、ユーザー定義キーワードである「パッケージ」は、要件ステレオタイプの横に置いている。
要件分析(例:分解やフローダウン)の中では、新しい要件が派生により作成される。これらの新しい要件は、DeriveRqt依存を使って最初のものに接続することができる。例えば、図3では、製品のコア機能セットがAutomatic Wipingの下で一連の要件から派生している。DeriveRqtという名前が選ばれたのは、UML 2.0標準のDerive依存との混同を回避するためだ。派生した要件の例としてはほかに、各機能の技術的な選択肢がある(図3のTechnical Choicesボックス参照)。設計者が、センサーをフロントガラスに固定した理由をRationaleのコメントを使って説明していることに注意したい。派生した要件の最後の例としては、System Calibration品質要件がある。これは、システムを調整する必要があることを述べている。これが、RSWにあの忌まわしい障害が発見された後から製品に追加された要件だ。この要件を満足させれば、センサーやフロントガラスの特性に変化があっても製品が確実に対応できるようになる。
要件間にあるもう1つのリレーションがRefineだ。絞り込み要件の例は図3に示されている。速度作動要件は、低、中、高といった速度を選択することで絞り込むことができる。最後に、一般的なTrace依存は、一組の要件に何らかの形のリレーションがあることを強調するのに利用できる。図3では、手動停止の要件を自動停止のところまでトレースすることができる。
要件には、これまで解説してきたリレーションのステータスを保存する多数の派生属性がある。本稿のパート2で解説するが、要件のリレーションが要件ダイヤグラムの外で描写されている場合はこれらの属性が特に便利になる。
要件は、製品のライフサイクル全体から引き出されることも多く、これらを描写するために新たな要件ダイヤグラムが利用される。従って、製品の要件は一連の要件ダイヤグラムで詳細に説明されるのが一般的だ。
SysMLは、機能要件と非機能要件の両方のモデリングを可能にする要件のジェネリックモデルを提供する。標準以外の一連の要件タイプはOMG SysML仕様の付録で提唱されている(注2)。特定のタイプの要件(タイミングやスケジューリングなどに関連するもの)は、言語拡張によって処理が行われる。SysMLは、プロファイルメカニズムをサポートすることで言語を拡張する。OMGでは、パフォーマンスや品質に関連する非機能要件のモデリングに関する特定のニーズ(注3)(注4)や、テストケースのモデリング(注5)に対応した一連のモデリング標準をリリースしている。これらのプロファイルは、一切制限を受けずにSysMLで利用することができる。
◆ ユースケースダイヤグラムとテストケース
SysMLは、UML 2.0から受け継いだユースケースダイヤグラムを無修正で提供している。RSWが持つ主なユースケース(楕円)と一緒に外部アクター間のやりとりを図4に示す。
このユースケースダイヤグラムは3つのアクターを示し、これらをそれぞれのユースケースに接続している。「Automatic Wiping」と呼ばれる中央のユースケースは、一連のサブユースケースによって構成されている。また、階層リレーションはInclude依存によってモデリングされている。
SysMLは、テストケースを描写し、これを関連する要件やユースケースに結び付けることもできる。テストケースには、操作と動作モデル(インタラクション、ステートマシン、もしくはアクティビティ)の両方がある。
図5および図6は、RSWのテストケースを示している。このテストケースは、System Calibration要件を確認している(図3)。これは次のようにして実現される。
最初に、異なるコンポーネント(センサー、フロントガラス、ソフトウェアコンフィギュレーションファイル)の特性を取り出す。
次に、互換性を評価するため、これらの特性を使ってセンサーとフロントガラスの作動範囲を計算する。センサーとフロントガラスが適合すればテストケースは成功だ。そうでない場合は警告が出る。アクティビティダイヤグラムの中にあり、各手順に貢献するアクションは、見やすくするために四角で囲ってある(図5参照)。
この例では、異なるコンポーネントに関連した成果物を格納するレポジトリに対し、一連のWebサービスを使ってアクセスを行うことで最初の手順が実現されている(図5の左端の四角を参照)。正確には、センサーやフロントガラスの特性を知るために、原材料部品一覧表(製品データ管理システムなどに保存されているもの)に対して問い合わせが行われる。そして、ソフトウェアコンフィギュレーション管理システムなどからコンフィギュレーションファイルが取り出される。
2番目の手順(図5の中央の四角を参照)は、SysMLパラメータダイヤグラムの中でセンサーとフロントガラスの属性に対する制約を定義することで実現される。これらのダイヤグラムの構成については本稿のパート2で解説する。
図6では、テストケースの実行に必要なWebサービスなどの各種機能のプロトタイプをホスティングするためにテストコンテキストが作成されている。このコンテキストは、要件の部分までトレースすることができる。(本稿のパート2で解説する)アクティビティダイヤグラムは、このテストコンテキストの機能を使って実行する。
今月のパート1では、SysMLを簡単に紹介し、要件、ユースケース、テストケースのモデリングを行う機能の概要を説明した。次回は、これらの要件を満足させる製品構造を作成する際のSysMLの使い方と、そのアロケーションメカニズムの使い方を解説する。
- トランザクション管理の複雑性を克服する(パート1)
- アジャイルとシステムテストの新たな関係(後編)
- アジャイルとシステムテストの新たな関係(前編)
- アジャイル開発の広範な普及を目指して
- 見積もりの精度 Accuracy of Estimation
- 複雑性を理解する(後編):ソフトウェアの複雑性を手なずける
- 複雑性を理解する(前編):ソフトウェアが複雑なのは仕方がない?
- 鈍重な開発チームは鈍重なシステムを作る?/パート3:役割とポリシー(後編)
- 人事評価と開発者のモチベーション/パート3:役割とポリシー(中編)
- 自己管理型チームの利点と弱点/パート3:役割とポリシー(前編)
- プロセスはチャンスが訪れるたびに改善する/パート2:プロセスと基準(後編)
- 開発プロセス導入のアンチパターン/パート2:プロセスと基準(中編)
- 反復開発の「ここはぜひカバーしたいポイント」/パート2:プロセスと基準(前編)
- 開発プロジェクト「統治」のピンポイント解説/パート1:原則と組織(後編)
- 開発プロジェクトを「統治」するベストプラクティス/パート1:原則と組織(前編)
- 初歩の「Perl」「Python」「Ruby」
- ビルドが全滅する原因/プロジェクトの状態を評価する:パート2(後編)
- 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する:パート2(前編)
- UMLを使ったビジネスモデリング(後編):そうだったのか! システムユースケース
- UMLを使ったビジネスモデリング(前編):なるほど! ビジネスユースケース
- 「この開発プロジェクトは中止!」の基準/プロジェクトの状態を評価する:パート1(後編)
- プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する:パート1(前編)
- 専門家に聞くモデル駆動開発のメカニズム
- 「設計」や「構築」よりも重宝されるスキル
- キミのコードが汚い理由
- 汎用グラフィカルモデリング言語「SysML」 パート2:グラフィカルなモデル言語で製品構造を記述
- 汎用グラフィカルモデリング言語「SysML」 パート1: 要件、ユースケース、およびテストケースのモデリング
- ウォーターフォールから反復型への移行手順
- ソフトウェアアーキテクティングのメリット
- ソフトウェアアーキテクティングのプロセス
- ソフトウェアアーキテクトの役割
- ソフトウェアアーキテクチャって何なの?(後編)
- ソフトウェアアーキテクチャって何なの?(前編)
- ITプロジェクトを見える化する
- ユーザー要件を引出すテクニック: ユースケースかストーリーボードか
- オブジェクト指向を超えて
- ルネサンスの巨匠たちに学ぶエンジニアリングの技
- ソフトウェア開発の「いま」と「近未来」の話
- 中国のソフトウェア開発現場はこんなにスゴイ
- 隣のテストチームが優秀ないくつかの理由(後編)
- 隣のテストチームが優秀ないくつかの理由(前編)
Copyright © ITmedia, Inc. All Rights Reserved.