UML:ユースケースを識別する方法、アクターの定義、時間はアクターになれるのか?、どこまでシステムで扱うのか?

自分メモ。UML Tips

先ずはシステムの外部に居るアクターを探すこと。次にユースケースを識別せよ。その方法は…

ユースケースを識別する方法

• アクターはシステムにどのような機能を望んでいるのか
  
• システムは情報を蓄積するのか? その情報の作成/更新/削除を行うのはどのアクターか?
  
• システムはその内部状態の変化をアクターに通知する必要があるのか?
  
• システムが知っていなければならない外部イベントはあるのか? あるのなら、そのイベントをシステムに知らせるのはどのアクターか?
  

アクターの定義
　ぼくらはそれを管理しないってこと。つまり今考えているシステムのプロセスの範囲外にいるということ。でもシステムへ何らかの影響を及ぼし、インタフェース(ユースケースとアクターを結ぶ線)でつながれているもの。

時間の扱いについて
　定時バッチ処理とか、日時レポート出力とか、特定の時間に行われるアクティビティがある。この場合、「時間」をアクターと見なしてもよい。アクター「時間」は給与計算や日時レポート出力を行うユースケースを開始することができる。

　ちなみにレポート出力先はアクター「プリンタ」が受け取ることになる。アクターとしての「プリンタ」はよく見落としがち
(ワタシだけかもしれん…　＿/￣|○)

どこまでシステムで扱うのか?
　超重要。システムへの要求の一部をアクターが扱わなければならない場合はどうすればよいか?

• そのアクターは実はシステムの一部なのではないかと仮定してみる
  
• その要求は実はシステムへの要求ではないと仮定してみる
  
• 上記のどちらが妥当なのかを判断する←その要求を出している人といっしょにね
  
• どっちに転んでも、そのアクターは再定義する必要がある←重要これをやらないのでシステム境界があやふやになるのだ
  

めちゃめちゃ重要
ダイアグラムってのはその時点でのプロセスについての知識を表したものにすぎない。だからプロセスについて分かったことが増えたのなら、ダイアグラムに戻って変更をしなければならない。ダイアグラムは僕らの知識と共に成長するんだよ

いままで「つくってオシマイ」を繰り返してきたワタシにとっては、非常に非情に耳に痛いが、真理です。肝に銘じるためにここに書いておく。

ネタ元「ユースケースの適用：実践ガイド」(ピアソン・エデュケーション)
--