5. 記述例

D-Case 記述ステップを使った例をご紹介します。DEOS ではET で毎年デモを行なっています。


 図6は2011 年に発表したウエブサーバシステムです。このシステムのD-Case を書いてみましょう。 DEOS センターが行った記述実験を元にしています。

1. システムライフサイクルを整理し、それぞれのフェーズの入力、出力ドキュメントをまとめる

このウエブサーバシステムは、既存のサーバPC を統合して開発しました。 そのライフサイクル、入出力ドキュメントは図7であったとします。 ただしデモシステムなので、いくつかのドキュメントには実際には存在しないものもあります。 ここでは特に運用ワークフロー定義文書に注目します。


2. 入力、出力ドキュメントを分類する

各フェーズの入出力ドキュメントを、ディペンダビリティの観点から整理して分類します。 D-Case を書くときの入力となるものです。

3. トップゴールを置く: 「システムはディペンダブルである」

D-Case のトップゴールはシステムのディペンダビリティに関する命題です。 まず「システムはディペンダブルである」という決まり文句をおいてください。 そして対象システムに応じて、変更、詳細化してください。 この例では、「ウエブサーバシステムは十分にSLA(ServiceLevel Agreement) を満たす」としました。

4. ディペンダビリティ要求、環境情報、語彙定義を前提としてトップゴールにおく

トップゴールを議論するために必要になる前提情報を前提としておきます。 どういったディペンダビリティ要求なのか、どのような環境運用されるのか、 トップゴールを理解するために必要な語彙定義などを置きます。 特にシステムのスコープを明確にします。この例では、図8のような前提をおきました。 ここではディペンダビリティ要求はSLA(Service LevelAgreement) に相当します。

 

5. 大まかにD-Case の構造を考える

トップゴールから一歩一歩ゴールを作っていくのは時として大変なことが多いです。 まず大まかな議論構造を考えましょう。この例では以下の様にして決めました。 「サーバPC の中身は、開発はしていないので、詳細はわからない。 最近のPC 技術は十分に成熟しているので、特にこのような小さなシステムでは、 PC 内部の欠陥による障害はそれほど考えなくてよいだろう。 むしろ最近では、サーバ運用上のミスによって重大な情報損失事故などが起こっている。 ワークフローにそって、きちんと起こりうるリスクに対処できるか、 議論することが重要なのではないか。その上で、障害即応、変化対応議論をしよう」 図9が上記の議論からでてきたおおまかな構造です。

 

6. 必要なドキュメントを前提として置く

運用ワークフローにそって議論するためには、ワークフローを定義しているドキュメントが必要です。 ワークフローは、ユーザログイン, ショッピングカート処理, クレジットカード認証, 終了処理, 配達, クレーム処理の6ステップからなり、それぞれのステップがさらにサブステップに分かれていると定義されていました。

7. ドキュメントからD-Case のサブツリーを作る

参照するドキュメントの構造から、自動的にゴールをサブゴールに展開することができます。 この例のD-Case のトップゴールは、ワークフロー定義書にしたがってステップごとに、 図10のように展開できます(最初と最後のステップのみ展開)。