For example, take an online bookseller. Actors identified are the customer and the bank credit card system. Both are valid actors, though it is likely only the customer will be a primary actor who initiates a system usage (purchase book). The bank credit card system will likely turn out to be a participating actor in this usage.

At this stage in the modeling process we seek to identify all actors—those who will turn out to be primary, secondary, or both.

Questions to discover actors

The following questions, based on those used in software application use case modeling, can be helpful in identifying actors:

￿Who/what uses the system?

￿Who/what gets or receives something from this system?

￿Who/what provides something to the system?

￿Where in the company (or in the world) is the system used?

￿Who/what supports and maintains the system?

￿What other systems use this system?

￿What outside conditions or events must the system detect and respond to?

￿Who/what can request or command the system to do something?

￿Who/what must the system communicate with to do anything identified in the aforementioned questions?

Actors and value

Value is a difficult term to define clearly.4 Most definitions of actors state that a use case always provides a meaningful result of value to the actor. In reality, it is easy to see that while value is always created by a use case, it is not always the actor who receives that value. Take the case of a payroll clerk printing paychecks using a payroll system. Does the payroll clerk receive value from this? Perhaps, if one of the paychecks is the clerk’s own, but the lion’s share of the value accrues to the enterprise itself. An even more vexing case is the common situation in aerospace and defense systems of a system firing a weapon at an enemy target. Clearly the enemy target is an actor, but does it receive value? One could perhaps say whimsically that it receives negative value, but the clearer answer is that the firing of the weapon produces value for the enterprise by defending the fleet, or maintaining a position.

In MDSD, we find it best to simply require that use cases provide a meaningful result of value, without requiring that the value be assigned to an actor.

4See “Use case” on page 19

42Model Driven Systems Development with Rational Products

Page 58
Image 58
IBM SG24-7368-00 manual Questions to discover actors, Actors and value