システムエンジニアのためのモデリング心得 トップ10

その7 要求モデルで、高くつく欠陥を早期に回避できる

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: システムエンジニアのためのモデリング心得 トップ10

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:システムエンジニアのためのモデリング心得 トップ10

このシリーズの続きに乞うご期待。

要求仕様をうまく作り上げるのは、見かけ以上に大変な作業です。実際、非常に大変で、35年以上やっていますが、私は未だに欠陥のない要求というのを見たことがありません。要求仕様は、「することになる(shall)」を使った文章からなる文書であるのが普通です。これには幾つもの根本的な問題があります 。

まず、文章というのは、表現力がすばらしく豊かであるのですが、また曖昧であり、いろいろな解釈が可能なものです。自然言語を用いて精密にというのはとても難しいことです。そう考えると、詩には自然言語がうまく合っており、技術仕様にはあまりうまく合っていないと言えます。

注 :実際、私はUML状態マシンを使って詩を書いたことがありますが、まあこれは今一つだなとわかりました。

更に、その仕様が完全で漏れがないことを確証するのも困難です。システムが稼動する全てのケース・状況・環境を網羅できていますか?性能やその他のクオリティ・オブ・サービスに関する要求についてはどうでしょうか?故障や例外事象の条件については?

非常にたくさんの要求の一貫性を証明することはもっと大変です。数百ページにわたる仕様での一貫性というのはとても困難な問題です。

では、このような仕様を、設計や開発を行うエンジニアリング・チームに手渡す前にどのように検証するのでしょうか。たいていの場合は、やらない(その結果プロジェクトの最終局面にて発覚する問題への対応での長時間かかるシステム検証や妥当性確認作業に陥る)か、もしくは、気の遠くなるような時間のかかるピア・レビューをするかでしょう。

問題は、文章としての要求は本質的に検証可能ではないという点です。では解決策はというと、モデルとして要求を作成することです。

簡単なユースケースとして、交通信号制御システムの「夜間閑散モード」を考えてみましょう。優先道路側の信号機は黄色点滅し、二次的道路側の信号機は赤色点滅します。図1は、このような簡単な要求群がどのように状態マシンとして表現され、取り巻く環境中のアクターである優先道路側の歩行者(primary road pedestrians – PP)、二次的道路側の歩行者(secondary road pedestrians – SP)、優先道路を直進する車(primary through traffic vehicles – PV)、優先道路から方向を変える車(primary turn traffic vehicles – PtV)、 二次的道路を直進する車(secondary through traffic vehicles - SV)、二次的道路から方向を変える車(secondary turn traffic vehicles – StV)にメッセージを送る様子を表しています。

図 1. 「夜間閑散モード」のための簡単なユースケース状態マシン
「夜間閑散モード」のための簡単なユースケース状態マシン
「夜間閑散モード」のための簡単なユースケース状態マシン

このモデルの主要な利点は、実行可能であるということです。モデルは、異なる状況・文脈・設定値・イベントの発生順序といったことを探っていくのに使えるのです。もちろん、図1の状態マシンは、ほとんど自明な例ではあります。しかし、もう少しだけ複雑な要求集合として、この同じ交通信号制御システムの「固定サイクルモード」を考えてみましょう。

  • ユースケース : 固定サイクルモード
    • 交差点には優先道路と二次的道路がある。
    • それぞれの道路には直進レーンとターン・レーンがある。
    • 直進レーンは、その道路の対面する両方向に対して同時にアクティブになり進行指示をする。
    • ターン・レーンは、その道路の対面する両方向に対して同時にアクティブになり進行指示をする。
    • 直進レーンは、外部からの何らかのきっかけ(stimulus)がなくとも、赤-緑-黄-赤のサイクルを通して進行指示をする。ある道路が通行を許可している間は、他の信号機は赤(そして歩行不可)の状態を維持する。
    • ターン・レーン は、ターン・レーンに車が到達することでアクティブになり進行指示を開始する。それ以外の状況では赤の状態に留まる。
      • 直進レーンが通常にアクティブになるはずの次のタイミングにおいて、まずターン・レーンが先に動作し、直進レーンはターンのサイクルが完了するまで赤の状態に留まる。
      • 対面する両方のターン・レーンは、赤-緑-黄-赤と進む。その後、直進レーンが緑になることを許される。
      • 一旦ターン・レーンが「処理される」と、再度アクティブになるには次の車の到達を待つ必要がある。
    • 歩行者信号機 は、歩行者が到着してボタンを押さない限りは「歩行不可」の状態に留まる。
      • 直進レーンが緑になる次のタイミングにおいて、歩行者ラインのサイクルが動く。
        • DON'T WALK (歩行不可)
        • WALK (歩行可)
        • FLASHING DON'T WALK (歩行不可)の点滅
        • DON'T WALK (歩行不可)
      • 直進レーンは、歩行者信号機が歩行不可になった後にのみ黄へと進むこととする。

これは、ものすごく複雑なユースケースというわけではありませんが、直進レーンとターン・レーンと歩行者の異なる組合せを扱う多くの異なるシナリオが構成可能です。図2に示すこのユースケースの状態マシンは、それほど自明なものでもなく、簡単に把握できるものではありません。そして、興味深い状況やシナリオが全て説明されるべきものです。このモデルを実行することで、イベントや条件や設定値の異なる組合せを調べ上げて、システムが常時正しく動作することを確証することができます。

図 2. 「固定サイクルモード」のユースケース状態マシン
「固定サイクルモード」のユースケース状態マシン
「固定サイクルモード」のユースケース状態マシン

このようなユースケースによる機能分析の自然な帰結として、欠けている要求が明らかになります。それらは文章としての仕様に追加され、モデル中の仕様要素と紐付けされます。その結果、より完全で、より的確で、より精密で、より正確な、つまり、より良い要求になるのです。

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者のBruce Douglassを含む、ラショナル・グローバル・チームのメンバーと共に、ラショナル・ソリューションの普及とお客様へ提供する価値の向上に日々取り組んでいます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=954834
ArticleTitle=システムエンジニアのためのモデリング心得 トップ10: その7 要求モデルで、高くつく欠陥を早期に回避できる
publish-date=12062013