evergreen notes

ユースケースという語の意味は対象となる成果物で見分ける

ユースケースという語には、要求分析で定義された用語と、そこから「使い道」へ意味を広げた日常的な用法がある。 さらに、要求から導いた実装上の処理単位もユースケースと呼ばれる。 これらは共通して「誰かが何かのために使う」という発想を持つが、同じ成果物ではない。

要求分析におけるユースケース

要求分析では、対象とするシステムが利用者の目的をどのように支えるべきかを明らかにする。 この意味でのユースケースは、特定の主要な登場人物が一つの目的を達成するためにシステムを使う、成功、代替、失敗を含む一連のシナリオを束ねたものである。

たとえば「銀行口座から現金を引き出す」というユースケースには、正常な払い出し、暗証番号の不一致、残高不足、現金切れなどのシナリオが含まれる。 ユースケースは正常な手順一つだけでも、一回の操作だけでもない。 実装技術や画面配置を決める前に、システム境界、登場人物の目的、システムの責任を記述する要求のモデルである。

対象システム：現金自動預払機
主要な登場人物：口座利用者
目的：現金を引き出す
基本シナリオ：本人確認から現金の払い出しまで
代替シナリオ：暗証番号不一致、残高不足、現金切れ

同じ形式でも、対象システムの境界によって業務ユースケースとシステムユースケースを区別できる。 業務ユースケースは企業や組織を対象システムとみなし、顧客などの外部の登場人物へ価値を届ける業務全体を扱う。 システムユースケースは一つのソフトウェアや機器を対象とし、そのシステムと外部の登場人物との相互作用を扱う。 これはユースケースという語の別定義ではなく、同じ要求分析手法を異なる境界へ適用したものである。

ユースケース図

UMLのユースケース図では、登場人物、対象システム、ユースケース、それらの関係を図示する。 楕円に「現金を引き出す」と書いたものもユースケースと呼ばれるが、楕円自体が要求の全内容ではない。 図は目的と範囲の一覧を示し、基本シナリオや代替シナリオの詳しい振る舞いは別の文章などで表す。

flowchart LR
    A[口座利用者] --> U([現金を引き出す])
    subgraph S[現金自動預払機]
        U
    end

したがって、「ユースケースを書いた」が楕円を並べたことだけを指す場合と、シナリオまで記述したことを指す場合では、完成している情報が異なる。

アプリケーション設計におけるユースケース

アプリケーション設計では、利用者の目的を実現する一回の処理をユースケースと呼ぶことがある。 クリーンアーキテクチャにおけるユースケース層や、`WithdrawCashUseCase` と名付けた処理がこの用法に当たる。 入力を受け取り、ドメインオブジェクトや保存先を調整し、結果を返す実装上の境界である。

このユースケースは、要求分析のユースケースを実現する側にある。 ただし、一つの要求分析ユースケースを一つのクラスへ写す決まりはない。 基本シナリオと代替シナリオを一つの処理が扱う設計も、複数の処理へ分ける設計もあり得る。

製品や技術の利用場面

製品紹介や技術比較では、ユースケースを単に「その製品や技術が役立つ状況」という意味で使う。 「生成AIの顧客対応ユースケース」なら顧客対応への利用例を指し、「GraphQLのモバイルアプリ向けユースケース」ならGraphQLが適する利用場面を指す。 ここには、特定の対象システム、主要な登場人物、一つの目的、複数のシナリオが揃っているとは限らない。

これは英語の use case を「使用例」や「用途」として使う日常語に近い。 正式な要求分析の成果物を求めている場面では、「利用場面」「用途」「適用例」と言い換えると混同を避けられる。

API設計におけるユースケース志向

API設計でいうユースケース志向は、利用側の一つの目的や画面に合わせて操作や応答を設計する方針を指すことが多い。 `confirmOrder` のような目的別の操作を公開したり、一画面に必要なデータを一度に返したりする設計が該当する。

この用法は要求分析のユースケースから目的という考え方を借りているが、基本シナリオと代替シナリオを備えた要求文書を意味しない。 GraphQLのユースケース志向も、主にクライアントの用途に合う操作を組み立てられるという意味である。

シナリオとテストケース

シナリオは、一つのユースケースに含まれる特定の条件と結果を持つ経路である。 テストケースは、入力、操作、期待結果を具体化してシステムを検証するための成果物である。 要求分析のシナリオからテストケースを導けるが、両者は同じではない。

会話ではテストケースや利用手順を誤ってユースケースと呼ぶこともある。 その用法に特別な定義があるのではなく、目的を表すユースケース、目的までの一経路を表すシナリオ、具体的な検証を表すテストケースを区別できていない状態である。 ユーザーストーリー、ユースケース、受け入れテストの関係では、この違いを現金引き出しの例で整理している。

文脈を見分ける問い

要求分析のユースケースかを判断するには、対象システムの境界、主要な登場人物の目的、複数のシナリオが示されているかを確認する。 コードのクラスや関数を指していればアプリケーション設計上の処理単位であり、技術を採用する場面の列挙なら用途や適用例である。 楕円と登場人物の図だけを指していれば、ユースケースそのものよりユースケース図という表現形式に注目している。

flowchart TD
    W[ユースケースという語] --> R[要求モデル<br/>登場人物の目的と複数のシナリオ]
    W --> D[図の要素<br/>目的と範囲の一覧]
    W --> A[実装の処理単位<br/>アプリケーション固有の振る舞い]
    W --> P[用途や利用場面<br/>技術が役立つ状況]
    W --> I[API設計方針<br/>利用側の目的に合う操作]

https://www.ivarjacobson.com/publications/use-case-foundation

https://www.omg.org/spec/UML/ISO/19505-2/PDF

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

https://graphql.org/

#requirements #use-case #uml #application-architecture #api-design