Finding actors in the MDSD modeling process is only slightly different from finding actors in ordinary
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
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.
Chapter 3. | 41 |
