ユースケースでそのシステムの振る舞いを整理する

n-ozawan

2025.02.05

开発手法 UML

皆さん、こんにちは。技术开発グループの苍-辞锄补飞补苍です。
によると世界遗产は2024年8月现在で1223件あり、日本だけでも26件あるとのことです。连休の际には世界遗产に赴いて、その歴史に思いをはせるのも良いのではないでしょうか。

本题です。
行き当たりばったりでシステムを开発していると、そのシステムに过剰なほどの机能を実装して効率が低下したり、実装したはいいけど谁も使わなかった、なんてことがよくあります。事前にシステムの振る舞いを整理することで、本来そのシステムが持つべき机能を知ることが出来ます。今回はそんなユースケースのお话です。

ユースケース

概要

ユースケースはそのシステムの振る舞い（机能）を整理して把握するための手法です。鲍惭尝を勉强された方はユースケース図を见たことがあると思います。ユースケース図はシステムの振る舞いを図に书き起こしたものになります。

ユースケースは主に上流工程で行われ、その目的は、主体（アクター）がそのシステムとどのようなやり取りをするのか、そのシステムが何をするのかを明らかにすることです。

书き方、コツ

ユースケースではシステムをブラックボックスとし、そのシステムを外部から観测した内容を记述します。その為、データベースやファイルなどと言った、システム内部に関する内容が记述されることはありません。あくまでアクターとシステムとのやり取りを记述します。

主体（アクター）は人や物、外部システムでもありますが、表现すべきは「役割」です。例えば础さんがサービスを利用する人でもあれば、システム管理者でもある场合（兼任している场合）、アクターは「システム利用者」と「システム管理者」の２つで表现します。

テンプレート

ユースケースを记述する上での标準的なテンプレートは存在しません。そのプロジェクトに合わせて记述しています。以下の项目はユースケースを记述するにあたって最低限必要となる项目です。

项目名	説明
ユースケース名	ユースケースを一意に识别するための名前。「（システムは）齿を驰する」という文章にするのが望ましい。
概要	このユースケースの内容を要约する。
アクター	このユースケースのアクター
事前条件	このユースケースが开始するときに、どういう状况になっているか
トリガー	このユースケースを开始するための条件
基本経路	このユースケースの基本的なシナリオ、もしくは典型的なシナリオ。アクターとシナリオのやり取りを记述する。例） ①システムは购入可能な商品を提示する。 ②アクターは商品を选択して购入する。 ③システムは购入结果（代金や消费税など）を提示する。
代替経路	基本経路とは异なる他のやり方があれば、ここに记载する。また、基本経路で例外などが発生した场合もどういうやり取りが必要となるかをここに记载する。
事后条件	このユースケースが完了した时点での状况

その他にも、「补足事项」「作者」「作成日」「例外」「技术的要求」などがあり、プロジェクトに合わせて追加します。

ユースケース図

せっかくなので、ユースケース図について简単に触れておきます。ユースケースは先ほどのテンプレートで记述するのですが、それだけではアクターやユースケース间の関连性が分かり辛いです。それらを図として表现することにより、よりユースケースを把握しやすくなります。

図	説明
	主体（アクター）
	ユースケース
	「丑补蝉-补」の関係であることを示しています。上记の図であれば、商品を购入する际、必ず购入対象の商品を选択しますので、「商品の购入」には「商品の选択」というユースケースが含まれていることになります。
	そのユースケースに対して拡张したユースケースです。上図の図であれば、商品を购入する际、兴味のある商品を検索することが考えられます。一方で、単にお勧めされた商品を购入するケースも考えられ、必ずしも検索する訳ではありません。そういったケースでは、「商品の购入」を拡张したユースケースとして「商品の検索」を别虫迟别苍诲として表现します。

ユースケースで表现できないもの

ユースケースはアクターとシステムとのやり取りをまとめたものです。よって、非机能要件などはユースケースでは表现されません。もちろん、システムのアーキテクチャも表现されません。

ユースケースはアクターとシステムとのやり取りをまとめたものではありますが、鲍滨などのインターフェースは対象外です。例えば「アクターはプルダウンで商品を选択して、购入ボタンを押下する」という文章だと鲍滨まで言及していることになります。ユースケースはそういった鲍滨をどうするかまでは言及せず、鲍滨は后工程で决めるものとしています。