対象 本教育資料上では、ECシステムを例にあげて、ユースケース図を説明していきます。 機能要求を「ユースケース」（利用者＝アクターから見たシステムの利用場面）としてまとめ，それを基に分析設計することが一般化してきた。 アプリケーションの開発・販売，プログラミングに関する書籍や雑誌記事の執筆，およびセミナーなどにおける講演活動を行っている。
6「アクター」「ユースケース」「サブジェクト」を書きだし、必要に応じてパッケージ・汎化などでシーケンス図を発展させましょう。 具体的には、システムを使う人、組織、外部システムなどが該当し、人型の線で表現されることが多いです。
言い換えると、システムの詳細を示すのにユースケース図は適していません。
5 コラボレーション図 コラボレーション図は，シーケンス図と同様に，オブジェクトの相互作用を示す図である。
またユースケースを実現するために、外部システムと連携する必要がある場合は、外部システムをアクターとして記述し、ユースケースと関連で結びつけます。
名詞と動詞の組み合わせにするのが望ましい（「本を借りる」「現金をおろす」など）。 粒度を意識すると難しくなるので、最初はとにかく箇条書きで書き出すことから始めましょう。 Contents• 基本的には数個の文で記述され、ゴールと主なアクターに関する説明を含む。
9管理者• この色分けはを真似ています。 また、完了可能なゴールにするのが望ましい（「ユーザー登録」ではなく「ユーザーを登録する」が好ましい）。
ユースケースはビジネスユーザーに理解しやすいことを旨としており、開発者とエンドユーザーの意思疎通に役立つ。
・アクターとシステムの関わりの記述に留める。
特定のゴールを達成するためにシステムをアクターがどう使うかを描く。
いや逆でしょってツッコミ受けると思いますが、ユースケースを使って開発をすればするほど、「システムでやらないことを決めるのがユースケース図」だとなんとなくわかってくると思います。
アクターは、システムを利用する何らかの役割を持つオブジェクトだと考えてください。 ビジネス分析のための最初のユースケースは、ソフトウェア開発中に使われる詳細化された版とはかなり異なることがある。
ユースケースを洗い出す場合は、アクターごとに箇条書きで書き出しましょう。
ユースケースは段階的リリースを行いやすくする。
ユースケース図の書き方 ユースケース図を構成する3つ基本要素を洗い出したら、次に図記号を使ってレイアウトします。
ちなみに、この「調査する」という時点のことを「拡張ポイント」と言います。 ぜひ皆さんも活用してみてください。
具体的なユーザーの行動を例に挙げて図解しているので、ITリテラシーが高くない方でも理解しやすいですがその分、要件定義フェーズでのユースケース図には分かりやすさが求められます。
ECサイトの例で例えるなら、「セール品を注文する」と「お急ぎ便で注文する」の二つのユースケースは、どちらも「注文する」という一つのユースケースに汎化できます。
で作ったユースケースの列挙を整理していきます。
3 対象に収める アクターとユースケースが列挙出来たら、対象に収めましょう。
ユースケースを表や文章で示したもの•。 つながりの意味はあまり意識せず、書きたいことや思い付いたことをどんどん書いていきましょう• ユースケース図の使って、アクター システムを利用する人やシステム の定義や、対象のシステムでどのようなユースケースに対応するかなどのシステムの範囲が明記出来ました。 UML図はユースケース図のみではありません。
UMLは思考の道具である。 文章や口頭だけではなく分かりやすい図でお互いの認識を合わせることが大切です。
基本イベント経路は例えば以下のようなステップとして描かれる:• アクター：人型の線で表された図記号。
ビジネスユースケースの詳細によりビジネスのプロセスが定義される。
オブジェクト指向でいう「 」関係の時に使います。
ユースケース図の特徴は「システムの内部構造のみならず、ユーザーの行動も仕様書内に明記される」「具体的なユーザーのアクションに対して、システムが実行する内部処理の流れを明記しているので理解しやすい」という点です。 このような作業をするうえでのポイントをいくつか紹介します。
8利用者を洗い出す まずは、システムの利用者を洗い出します。
以下の例では「携帯システム」のサブジェクト内に「一般」パッケージと「管理」パッケージが存在するユースケース図です。
パッケージ 下図は、受験（サブジェクト）をパッケージとして表したものです。
1つのシステムの設計においてUMLのすべての図を使う必要はない。
寄稿者• ただしメリットでも解説したとおり、ユースケース図を使用した要件定義フェーズでのヒアリングは有効なので、作成コストはかかりますが、それを補ってあまりあるメリットがあります。 ユーザーを追加する• ユースケースをストーリーやシナリオに変換するのは非常に簡単である。 電卓の場合では，電卓を使うユーザーがアクターに当たる。
20双方の認識がズレたまま開発を進めると、完成品はお客様側の要望を満たしていないものが出来上がってしまい大変なことに。 ただし、どのような場合でもなるべくシンプルにして余分な要素を入れないように気を付けましょう。
この記事で解説している基礎知識を抑えてしまえば、たった５つのステップで作成できてしまいます。
ステレオタイプで関連を表す ユース・ケース同士が関連を持つ場合があり，そのような場合，ユース・ケースを破線で結び，「＜＜」「＞＞」の記号ではさんで関連を説明する。
洗練させていくにはいろいろな方法がありますが、本稿の趣旨を外れてしまうのでここでは割愛します。
アクターは、対象にとって外部の存在です。 ユーザーがシステムで何をしたいのか、何を得たいのかを明確にする• 自分なんかは設計するときに口を酸っぱくして言うことの1つに「システムでやらないことを決めろ」といいますが、システムでやらないことを決めるのに、利用するのがユースケース図です。
棒人間で表現されますが、人に限定されるわけでなく、他システムなども同じように棒人間で表現されるので、注意しましょう。
多少のルール違反や表記の乱れでも、保守性に大きな悪影響を及ぼします。
記事を変更する• 外部的条件、時間的条件、内部的条件がありうる。
シナリオ：シナリオはシステムを実行したときの具体的な流れを文章で表現したものです。