読者です 読者をやめる 読者になる 読者になる

ユースケースやユースケース図の概要

お仕事の都合上,ユースケースユースケース図について
勉強する必要が生じたので,その成果というか,学んだ内容を記載しておく.
1週間後には忘れていそうだし.

そもそもユースケースとは何か?
敢えて簡潔な表現を目指すならば,「使い方」で良いと思う.
システム開発で言うなら,「ユーザがそのシステムをどう使うか?」
という問いかけに対し,要求のレベルで回答したもの,ということになる.

「要求のレベルで」という言葉を使ったけれど,
これは「ユーザに見えるレベルで」という理解で良いんじゃないかな.
つまり,対象内の構造や振る舞いには踏み込まず(ユーザはそんなの知らない),
対象を1つの大きなブラックボックスと見なして説明せよ,というルールになる.
これは「細かな作りについて考えるのは後回しで良いよ」という利点にもつながる.

ユースケースのフォーマットは色々あるけれど,
中核を成す要素はメインフローと代替フロー.
「メインって何やねん」とツッコミを入れたくなるけれど,
そこは深く考えず,「一番発生確率が高いフロー」と解釈すれば良いと思う.
そこから外れるレアケースについては代替フローとして整理する.
代替フローからメインフローに合流することもあれば,
そのままユースケースが終了することもある.

あと,事前条件と事後条件なんてものも,よく書かれている.
この2つの関係性として,
「事後条件が全て成り立つ⇒事前条件が全て成り立つ」
という命題が真であることを,ユースケース記述者は保証しないといけない.
「なんのこっちゃ?」となった場合は,対偶を取ると分かりやすいかも.
つまり,
「事前条件のいずれかが成り立たない⇒事後条件のいずれかが成り立たない」
が真となる.これは雑に言えば,
「事前条件が1つでも守られていない状態でこのユースケースを実行した場合,
 どのような結末が待ち受けているか不明」
ということになる.
なお,これは,
「事前条件が満たされていなくてもユースケースは実行可能である」
という事実も意味する.


ユースケース自然言語で説明されるべきだけれど,とにかく量が多いので,
多くの場合は,モデルとして簡略化された状態で説明される.
その際に有名なのが,UMLユースケース図.

ユースケース図は,ユースケースの他に,
「境界」と「アクタ」と「関連」という要素を使う.

冒頭で「対象をブラックボックスと見なす」と述べたけれど,
それを絵的に表したのが「境界」.
ユースケースはこの境界の内部に,楕円に囲まれた簡潔な文字列で格納される.
多くの場合は「AをBする」というフォーマットに留まる.

「アクタ」とは,境界の外側から対象を使用する主体のこと.
敢えて主体と呼んだのは,人以外の,例えば外部システムでもOKであるため.
また,アクタは「役割」なので,1つのインスタンス複数のアクタになり得る.
「ブログ著者」と「会社員」という2つのアクタが記載されてた場合,
N_K5というインスタンスはどちらにもなり得るということになる.

「関連」は,アクタとユースケースを結びつけるもの.
これにより,「アクタはAをBする」という一文が出来上がることになる.

また,記述をキレイにする手法として
「汎化」「包含」「拡張」という手法が存在する.

「汎化」とは,オブジェクト指向でよく使われる表現で,
アクタやユースケースを,より抽象度の高いものとしてグルーピングすること.
「投手」「捕手」というアクタを「選手」というアクタに抽象化する感じ.

「包含」とは,ユースケース内の共通操作を引っこ抜くこと.
「パソコン」というシステムにおける
「ネットショッピングする」も「ブログを読む」という2つのユースケースから,
「ブラウザを開く」という共通操作を引っこ抜く感じ.

汎化と包含は混同しがちだけど,
「<元>は<先>である」が成り立つのが汎化,成り立たないのが包含と
覚えておけば,とりあえず問題はないと思う.
投手は選手だけど,
ネットショッピングをすることはブラウザを開くことではない.

で,最後は「拡張」.
これはユースケースにおけるレアパターンを切り出して明記すること.
先述の代替フローとほぼ同義な気がするが,
使い分けがイマイチわかっていない.すんません.


ユースケースは要求モデルとして非常に優秀だけれども,
書く(描く)のにとにかく時間がかかるので,
代表例をピックアップするに留まりましょう,というのが,
多くの書籍で推奨されている使い方.
実際そうだと思う.代替フローを真面目に考えたらそれだけで日が暮れるし.


以上,嘘があったらすみません.