コンピュータ技術者のための無料情報倉庫です

ソフトウェア設計者向け情報

6.ユースケース解説
・・・オブジェクト指向設計とユースケースの登場 ・・・

　システム設計の現場でオブジェクト指向の技術が利用され始めたのは、つい最近、20世紀の終わりごろでした。
日本でも1999年には、数十億円規模の開発の上流工程でオブジェクト指向設計が実施されています。 ここでいう上流工程とは、システム要求（要件定義書や基本計画書要求の作成）と 概要設計書（外部設計書）の作成を示しています。
著者は、設計工程へのオブジェクト指向開発（本稿、以下では、OODとします。）の採用で、 最も効果をあげたのは、ユースケース（本稿、以下、UCとします。）の登場と考えています。
本稿は、著者の経験に基づく記述事項が多いため、過誤等については著者の責任において発生したものとお断り申し上げます。
また、UCは一つのツールであり、他のツールや設計理論と同様に重要であると認識していただきたいと存じます。

6-1.UCの目的

　UCは、ユーザ（人、または、他のシステム）の「行動もしくは状況」を端的に見やすく表現することを目的とします。
「誰々は、何々をする（もしくは、誰々は何々である）。」という平叙文の形式で、命題として記述します。 命題の形式で記述するのは、解りやすく、かつ、表現による差異を防止する機能を発揮させるためです。 また、多くのシステム開発で、ユースケース分析が採用されているのはその便利性にあります。 （アジャイル開発の一部・・XPやスクラムなど・・は、UCをさらに単純化したような方法をとります。）
この利便性は、システムに関する文章表現の方法（集合と命題のことです：第一部に紹介いたしました。）を統一することにあります。 誰でも、同じ内容として、理解できることを目的とした表現を採用したのです。
　したがって、ユースケースでは技術専門用語をなるべく使わず、エンドユーザやそのビジネスの専門家に分かり易い用語を用いるのが一般的です。 なぜなら、ユースケースの作成は、技術者（主にアナリスト）とエンドユーザが共同で行うことが多いからです。 ここで重要なことは、ユースケースではシステムをブラックボックスとして扱うことです。 （ユースケース分析の過程では、実装について制限しないのが基本となります。） さらに、システムの反応を含めたシステムとのやり取りは、外部から観測されるものとして描かれます。 これは、意図的に設定された方針であり、ユースケース作成者は「システムがどう動作するか」ではなく「システムは何をするか」に集中しなければならないことを示しています。 これによって「特定の実装方法を暗黙のうちに前提としてしまう罠」を避けるものであると定義されています。

著者注：
多種の理由で、「実際のシステム開発では開発の制約条件が【罠】である場合」が多いことに留意・対応が必要です。
制約条件にたいしては、それを満足させられる事が明示してあれば十分です。 この【罠】は製造工程で変更される場合もみられますので、設計時点では「必要条件」としないことが肝要でしょう。

6-2.システム設計におけるUCの定義

UCは、何らかのビジネス目標/機能に関するシナリオでのアクター(actor)と呼ばれるユーザとシステムのやりとりを描いたものです。 アクター(actor)は人であるユーザ（主にエンドユーザ）の場合もあるし、別のシステムの場合もあります。
システム設計においては、「アクターは、システムに影響を与えうる全ての事象を示している」と定義を拡張して理解してください。
設計工程においては、次の二種類のユーザについて分析が必要です。
＊UMLのUC定義上のユーザ
　システムから恩恵を受けるエンドユーザ、ならびに、システムに関わる他のシステム
＊設計作業上で考慮すべきユーザ
　システムにかかわる可能性があるユーザ、および、システムに影響を与える可能性があるユーザ
（第三者と規定できる範囲を含みます。）
著者注：
システムの要件を定義してから完成するまでの間に、しばしば、アクターは変更になったり追加されたりするものと考えておくことも重要です。

6-3.UCが命題の形式で記述されることによる利点

　命題は、古くから研究されてきた論理で、対偶・逆・裏が証明済みで定義されており、それぞれ利用することが可能です。

1.　「UC記述」と「対偶」
　設計工程『要件定義（基本設計）から概要設計（外部設計）』において定義することになる「UC記述」に従って、システムは『製造工程（詳細設計と製造）』へ進んでいきます。 この「UC記述」に誤り（過誤）が存在すると、予定した機能を発揮できないシステムが製造されてしまうことになってしまいます。 「命題記述」によって表されるUCは、以下の二つの方法で、記述の正確さを判断できるのが一般的です。
(1).ベン図の作成によるUC記述内容の確認
　UC記述は、『「集合A」ならば、「集合B」である。』と記述できます。
したがって、「集合B」の要素で、「集合A」に包含されるべき要素が存在しないことが「必要」になります。
（第一部3.コンピュータの文章表現「帰結」をご参考ください。）
(2).「対偶」の確認によるUC記述内容の確認
UCの対偶記述は、『「集合B」でないならば、「集合A」ではない。』と記述できます。
したがって、「集合B」の要素以外で、「集合A」に包含されるべき要素が存在しないことが「必要」になります。
対偶の確認は、設計書を記述するレベルの技術者諸兄には当然の作業ですが、対偶が証明できれば命題は正しいことから、 「命題の成否を確認する試験」方法として使用することを可能にしています。
＊「UC記述」もしくはその「対偶」は、単体試験からシステム試験において必須の確認項目として使用されます。

著者注：第一部でも例示しましたが、命題は、文章表現の華麗さよりも、正確に対偶が確認できる表現が重要と認識して下さい。

2.「逆」と「裏」の存在
　「UC記述」が命題の形式で記述されるため、必ず、「逆」と「裏」が存在します。 命題が正しい場合、「逆」と「裏」が正しい確率は、0％から100％の間です。
これらについては、ユーザーの意向で設計段階での記述が求められない場合があります。 したがって、設計者はこれらを設計資料として作成しておく必要があるという注意が不可欠です。 正確に動作するシステムを設計するうえでは、運用性能の確認試験において必要なため、重要項目となります。
「逆」と「裏」については、発生の可能性が不明確な場合が想定されます。 設計段階では、将来システムを阻害する可能性があり対策の必要がある事象ととらえるのが望ましいでしょう。
(1).「逆」の確認
　UC記述が、『「集合A」ならば、「集合B」である。』である場合、「逆」の記述は、『「集合B」ならば、「集合A」である。』と記述できます。 したがって、「集合B」の要素について、「集合A」に包含されるべき要素と包含されない要素の洗い出しが「必要」になります。
（A=Bの場合は、「逆」は全て成立することに注意。）
(2).「裏」の確認
　UC記述が、『「集合A」ならば、「集合B」である。』である場合、「裏」の記述は、『「集合A」でないならば、「集合B」ではない。』と記述できます。 したがって、「集合B」の要素で、「集合A」に包含されない可能性のある要素を確認することが「必要」になります。
＊「逆」と「裏」に該当する要素発生の「不確定要因」は、システム試験から結合試験において重要な試験項目として使用されます。 もちろん、発生する確率が0％でないと推定される事象については、発生時の対応（CP：注2）が試験項目となります。

6-4.その他のアクターの存在

　設計手法によって、代替経路・異常系・例外系などと定義されています。 「命題」および「逆」と「裏」以外の事象であり、システムで対応できる範疇以外の異常事態で、人災・天然災害発生下での企業・団体としての異常事態対応（CPで定義可能な現象とBCPとなるもの：注2）を示すものとして記述する必要があると定義することを推奨いたします。 ここで、まず、著者が想定しているのは、地震・水害・火災・人災などによる「電源停止」や「通信不能」などの事態です。 高度なシステム構築を志向する場合は、もっと高度なBCPに対する（もしくは、「備えた」）システム設計が、必須になってくるでしょう。
（システム記憶装置の重複設置などが実施されていますが、本稿では、検討の対象外とします：ハードウェアは専門の諸兄にお願いするのが最良です。）
(1).天然の災害に対する対応
　天候不順や地震等の天然災害に関する対応が必要です。 主な項目として、「停電」と「通信経路の切断」発生時の対応は必須と考えるべきでしょう。 この項目への対応はBCP（注2）として定義が必要です。
(2).偶発する人災に対する対応
　故意ではなく発生する、システムへの妨害です。 主に、通行人・清掃担当者などによって引き起こされます。 「電源供給の異常（コンセントの抜けなど）」と「通信回線の異常（通信ケーブルの切断など）」発生時の対応が必要です。
(3).攻撃に対する対応
　故意に引き起こされる、システムへの妨害です。 悪意のある使用者と通信回線をとおして侵入してくる他のシステムなどによって引き起こされます。 正規ユーザへ成り済ました不正規な操作、通信管理システムへの攻撃、機器への破壊行為などが対象となります。
＊「その他のアクターの存在は、総合試験から受け入れ試験（運用確認）において必須の試験項目として使用されます。

著者注1：
オブジェクト指向設計で発生するトラブルは、「逆」、「裏」、および、その他のアクターに関する設計・調査・記述（CPの記録）が不十分であることに起因する場合が非常に多いと著者は経験しています。 製造後、総合試験以降でのトラブル発生は、設計時の記述不十分をその原因としている場合が多いと考えております。

著者注2：
CP、BCPは本文中では下記の内容として使用しています。
CP：コンテンジェンシープランで「障害対応の定義」可能な現象
BCP：ビジネス・コンティニュイッティー・プラン「長期の障害発生時」の回避・代替行動

ユースケース解説-以上

お問い合わせについて

▲ページトップに戻る