【新人教育 資料】第5章 UMLまでの道 〜ユースケース図の説明&書いてみよう編〜
あらすじ
新人がいっぱい入ってくる。新人のレベルもバラバラ。教育資料も古くなっているので、更新しましょう。
どうせなら、公開しちゃえばいいじゃん。という流れになり、新人教育用の資料を順次更新していくことにしました。
※後々、リクエストに応じて更新することが多いのでストックしておくことをおすすめします。
自分は某社でCTOをしていますが、頭でっかちに理論ばっかり学習するよりは、イメージがなんとなく掴めるように学習し、実践の中で知識を深めていく方が効率的に学習出来ると考えています。
未経験者の教育についてインタビューされた記事もあるので紹介しておきます。ご興味ある方は御覧ください。
エンジニアは「即戦力」より理念に共感した「未経験者」を育てるほうが費用対効果が高い。
※他の登壇やインタビュー記事はWantedlyから見てください。
教育スタイルとしては正しい事をきっちりかっちり教えるのではなく、未経験レベルの人がなんとなく掴めるように、資料を構成していきます。
以下のようなシリーズネタで進めます。
箸休めには以下をどうぞ
では、今回もはじめていきましょう！
ユースケース図
システムまたはアプリケーションが人、組織、外部システム等と対話するシナリオを示したものです。ユースケース図でこれらの登場人物(システムも含む以降アクターと呼ぶ)が達成する目的やシステムの範囲を示すものです。システムの範囲というのが重要です。
ユースケース図も規模が大きくなってくると複雑になるので、ある特定のシーン(シナリオ)においてという前提をつけて書き出すと綺麗になっていきます。
ユースケース自体を書き始めると粒度が分からなくなってしまう事が多いので、ザクっとした「○○が✕✕する」という英語で習った主語＋動詞というレベルだけに絞って書くなどのルールを決めると分かりやすくなります。
自分なんかは設計するときに口を酸っぱくして言うことの1つに「システムでやらないことを決めろ」といいますが、システムでやらないことを決めるのに、利用するのがユースケース図です。
いや逆でしょってツッコミ受けると思いますが、ユースケースを使って開発をすればするほど、「システムでやらないことを決めるのがユースケース図」だとなんとなくわかってくると思います。
クラス図と同様に細かい表現はいくつかありますが、大まかには以下の3つで構成されると覚えてください。
- アクター
- ユースケース
- 対象
本教育資料上では、ECシステムを例にあげて、ユースケース図を説明していきます。
アクター
人であろうとシステムであろうと、アクターとして登場人物を表現します。
アクターは、システムを利用する何らかの役割を持つオブジェクトだと考えてください。アクターは人であっても、他システムであってもOKです。ユースケースで記載しようとしているシステムに対し、システムにアクセスするものを役割として表現しましょう。いわゆる棒人間で表現されます。棒人間で表現されますが、人に限定されるわけでなく、他システムなども同じように棒人間で表現されるので、注意しましょう。主語にあたる「○○が」の部分ですね。
actor アクター名
ユースケース
ユースケースは楕円で表現されます。細かい表現はさけて、✕✕するという動詞だけで表現しましょう。△△を✕✕するのように表現が多くなると、どこまで記載すべきかなどがブレるので、初めはシンプルに心がけましょう。
(ユースケース)
ユースケースを書いていくにあたって、アクターが出しきれたか、ユースケースはこれで正しいかと、洗練されてきた後に、「✕✕する」から動詞の目的語を付け加えて「△△を✕✕する」とブラッシュアップしていくことがよいかと思います。
対象
対象は、ユースケースを実現する対象を示すものです。長方形で表現れます。システム境界線なども言いますが、どのシステムで実現するのかシステム範囲をしっかり表現するために、システム名称などのラベルを書きましょう。
rectangle 対象名
実際には、対象の中にユースケースを含める
rectangle 対象名 {
アクター名 --> ユースケース
}
ECシステムのユースケースの例
STEP.1 アクターを列挙する
ECシステムのユースケースを考えた場合、どのようなアクターが登場するでしょうか？
シンプルに考えた場合以下の2種類のアクターではないでしょうか？
- 購入者
- 管理者
STEP.2 アクター毎のユースケースを列挙する
「○○が✕✕する」と英語の文法のS(主語)＋V(動詞)を意識するように簡潔にユースケースを書きましょう。細かい事は一旦省いて書くようにしましょう。
STEP.3 対象に収める
アクターとユースケースが列挙出来たら、対象に収めましょう。
アクターごとのユースケースが分かるように、配置なども考えて整えましょう。
STEP.4 ユースケースを整理する
STEP2.で作ったユースケースの列挙を整理していきます。今まではアクター毎のユースケースを簡潔に、とりあえず列挙したユースケースを、ロジックシンキング等でよくいうMECE（もれなくダブりなくの意）を変更していくことやや、S(主語)＋V(動詞)から「○○が△△を✕✕する」と英語の文法のS(主語)＋V(動詞)+O(目的語)に変更していくこと。また、同じユースケースが他のアクターでも発生するのではないか？等を考えて、反映させていきます。
ユースケース図の使って、アクター(システムを利用する人やシステム)の定義や、対象のシステムでどのようなユースケースに対応するかなどのシステムの範囲が明記出来ました。
なんとなくイメージはつかめたでしょうか？
ドキュメント文化強い会社などはコレに加えて、以下のユースケース記述という文書を添えます。これはより具体的なシーンとして理解できるように記述を添えるというものです。
- ユースケース記述
- ユースケース名
- 概要
- アクター
- メインフロー
プラスα
ユースケースがなんとなく理解出来た人に向けて、さらに表現を広げてみましょう。
汎化（Generalization）
クラスの説明の際にした汎化と同じです。先から基へ矢印が向きます。
「is a」関係、つまり、「B is a A」、「BはAといえる」が成り立つものです。
以下の例は「初回購入者 is a 購入者」、「初回購入者は購入者といえる」が成り立つ例です。
ユースケースにおける、汎化の使いドコロとしては、こういうアクターやユースケースも含まれていますよ的に使います。
アクター名B --|> アクターA
包含（Include）
ユースケースとして記載しているが、ユースケースは当然、他のユースケースを含むと表現したい時に使います。
「has a」関係、つまり、「A has a B」、「AはBを含む」が成り立つものです。
以下の例は「商品を買うは商品を選ぶを含む」が表現されています。
(ユースケースA) ..> (ユースケースB) : include
拡張（Extend）
ユースケースとして記載しているが、ユースケースは当然、他のユースケースを含むと表現したい時に使います。
(ユースケースA) ..> (ユースケースB) : extends
パッケージ
複数のユースケースをまとめて表現するもしくは、サブシステムにまとめる際に利用するのがパッケージです。
今回の例でとりあげた、ECシステムのユースケースですが、購入者と管理者が同じ「商品を探す」等のユースケースがありますが、購入者が「商品を探す」のと、管理者が「商品を探す」
場合、通常、探す条件やシステムに求める内容が違いますよね？
そんなときにパッケージで表現してみましょう。
package パッケージ名 {
}
plantumlでのおまじない
plantumlではdefaultでユースケースが縦になってしまうので横にしましょう。
left to right direction
プラスαを抜いた一連のアニメーション
