はじめての設計をやり抜くための本 第2版 概念モデリングからアプリケーション、データベース、アーキテクチャ設計、アジャイル開発まで

100

導

入

編

1

設

計

編

ア

キ

テ

ク

チ

ャ

編

2

3

4

5

6

7

3

　ユースケースは、主アクターの視点で記述します。それは、ユースケース

のレベルを揃えるうえでも重要です。システムの担当者は、ついついシステ

ムの視点で記述しがちです。しかし、システムの視点よりも、アクターの視

点のほうがシステムの目的に近いことを忘れてはなりません。

　ユースケースを抽出するためにも、アクターの視点は必要です。抽出され

ているユースケースは、アクターの目的をすべて満たすでしょうか？ アク

ターのライフサイクルを考えた時に、ユースケースが足りているでしょう

か？ そのように考えることで、足りないユースケースを発見できます。

　アクターは、特定の個人を指すのでしょうか？ それとも、役割（ロール）

を指すのでしょうか？ ユースケースを書き始めた当初は、ヒアリングをし

ている特定の個人をアクターとしてイメージしているかもしれませんが、当

然ながら同僚もいることでしょう。また、その上司がそのユースケースを実

行することを考えると、個人ではなくロールであると考えるほうが自然で

す。ただし、ロールといってしまうと、システムの認証におけるロールと同

じになってしまいます。確かに、ユースケースのアクターから認証の仕組み

を考えることはできますが、必ずしも同じではありません。システム認証で

のロールはログインをしていないと識別できませんが、ユースケースのアク

ターはそうではありません。ユースケース分析を行っていると、アクターが

抽象的になっていくのは自然ですが、システム認証のロールとは同じではな ...