IBM SG24-7368-00 Fitness Equipment User Manual


 
Chapter 3. Black-box thinking: Defining the system context 41
Finding actors in the MDSD modeling process is only slightly different from
finding actors in ordinary software-focused use case modeling. The difference is
usually one of scale or context. With a software application as the system, we are
really only looking for people and systems that interact with, or use the
application to be our actors. With actors in MDSD we take a broader view, and
must look for any entity that interacts with ours. This term
interact is important.
Not all things that touch a system interact with it. For example, should rain be an
actor to the aircraft? Well, it depends on whether the aircraft has a requirement to
interact with the rain. If, for instance, as with some cars, the presence of rain
triggers the windshield wipers and defogger, then the rain is indeed causing an
interaction and should be shown as an actor.
In finding actors we are looking for entities that take part in interactions that
involve system functionality. Remember that the purpose of the model is to
describe system functionality through usage scenarios, so it is the participants in
those scenarios that we seek for actors. Can inanimate, passive objects be
actors? Probably not, unless they are systems themselves. A voting machine
does not interact with a ballot, nor does a gun interact with the bullet. These
items will be captured later in the model as I/O entities.
Primary and secondary actors
Primary, or initiating actors are those who initiate system usage while
secondary, or
participating actors, are those who interact with the system in the
course of it performing some function initiated by a primary actors. As I order a
book from an online store, that store’s system interacts with my bank’s system to
validate my credit card. To the store’s system, I am a primary actor (customer)
and the bank system is a secondary actor. The bank system only interacts with
the online store system in the processing of doing something for me. Without me,
there is no need for an interaction with the bank. This is not to say that primary
actors are more important than secondary actors, or that somehow the system is
more
for them. The notion of primary and secondary actors is important because
not all actors will initiate usages of the system—some will simply participate in
usages initiated by others.
Note that we cannot designate primary and secondary actors as such in the
model, because a particular actor might function as the initiator of one system
usage, while being only a participant in another. We simply use this distinction to
aid in discovering all of the actors. Often, primary actors are mentioned first, and
in thinking about what the system does for them, other secondary or participating
actors are discovered as well.
A common trap that befalls new MDSD modelers, is to try to come up with
usages for all of the actors discovered. Because some of the actors will be
secondary (participating) actors, they will not have their
own use cases.