はじめに
オブジェクト指向言語の知識がほぼほぼゼロの私ですが、オブジェクト指向プログラミングを学習するのと同時に、UMLについて学習したいと思います。その備忘録をブログとしてまとめます。
図を作成する前に…
ユースケース図を作成する前に、前回のシステム要件をもう少し書き下してみます。
システムで実現したいこと
- セミナー受講者が月次の目標設定を行う
- セミナー受講者がサイトの記事数、PV数、収益の推移を入力する
- 上の推移を講師が確認する
- 月次でレポートを出す
- 更新が滞っているセミナー受講者に連絡をとる
巷にはGoogleアナリティクスなる便利な計測ツールが存在しますが、今回は全部手入力でやっていくこと前提にします。
この記事が完結する頃に私に余力があれば、アナリティクスAPIを使用してユーザ入力を自動化する仕組みを実装したいと思います。
ユースケース図を書いてみよう！
では本格的にユースケース図を書いていきます。まずはユースケースとアクターの候補を洗い出します。
| ユースケース | 検討対象のシステムがアクターに対して提供する機能または振る舞いのこと。システムで実現するべきこと。 |
| アクター | 検討対象のシステムの利用者のこと。人間としてのユーザだけではなく、ハードウェアや外部システムといった人間以外の要素も含まれる。 |
要件を元に作成していきます。
ユースケースの候補
- 目標設定をする
- 結果の入力をする
- レポートの確認をする
- レポートの投稿をする
- 更新の止まっているユーザを一覧表示する
- ユーザの一覧表示をする
- ユーザの連絡先を調べる
アクターの候補
- セミナー受講者
- セミナー講師
大まかにこんな感じでしょう。最初から完璧なものは作れるはずがないので、ざっくりと作成します。こだわり過ぎると時間を無為に消費してしまいます。過不足があれば後で修正するくらいの気持ちで作ります。そんな感じで出来たのが下の図になります。
ステレオタイプについて説明します。
<<include>>：複数のユースケースに共通利用されるユースケースとの間に成り立つ関係。利用するユースケースに対して破線の矢印を引く。includeされるユースケースは必ず利用されなければならない。
<<extend>>：ある条件下で、他のユースケースを利用することを指す関係。includeと違い、必ず利用されなければならない訳ではない。
例えば、必ずログインを行ってからその他の操作を行わせたいので、ログインというユースケースはその他操作に<
今回のまとめ
分からないなりに作成した図なので、間違っている箇所が見つかり次第訂正いたします。要するにこれが正しい！と鵜呑みにするのは大変危険ということです。笑
どこまで詳細なユースケース図が求められるのかは、要件定義の段階で決まります。要件として挙げられているものは確実に実現しなければならないものです。それとは別に、アイデアがあればそれを盛り込むのも良いでしょう。何はともあれ、それなりに意味のあるユースケース図が書ければ今の時点では問題ないということです。(と信じたい。。。)
次回はオブジェクト図について見ていきます。
