Primary and secondary actors in use case

Question

We know that the primary actor is the one that initiates a use case and a secondary actor is the one that helps completion of the use case through his specific support. The Primary actor is usually placed at the left side to the boundary of the system and the secondary actor is placed to the right of the boundary of the system. But lets consider a library system where we have two actors , librarian and the reader . Lets consider some specific use cases here :

1) A use case where the library can add books to the library system. In this case the librarian is a primary actor.

2) A use case where the reader borrows a book . More specifically , the reader gives the book that he needs to borrow to the librarian and the librarian scan the book using bar code and enters all the needed info in this system ( reader ID , load time ,....etc ) . In this case the librarian is a secondary actor .

So my question is where to put the librarian in the use case diagram? Right or left to the boundary of the system ? Because in some use cases he is a primary actor and secondary actor in others .

Answer 1

Placing primary actors left and secondary actors right is just a convention to facilitate the reading of the diagram by people who know that convention. This is not part of the UML standard, so you can do as you want.

Personally, if it's a primary actor of one of the UC, I'd put is on the left even if it's a secondary actor of another UC in the same diagram. But it would not be wrong to put in on the other side either.

Answer 2

You need to look at this from a different angle; based on your description, you are making software that supports the daily activities of the library employees (you are making it for them, to help them with their work). So, you are not modeling the library itself, but the business domain of the library. Primary actors are essentially people who interact with that system directly, in order to perform a business function within the domain you are modeling - e.g., perhaps the system enables them to do their daily work, or they are using the system because it provides some service for them.

In your case #2, the reader never interacts with the system (they interact with the librarian), so you could reasonably argue that, within the context of this model (and this particular use case), the reader is not an actor at at all (but an external detail you can mention in the description of the use case). The meaning of the use case isn't "reader borrows a book", but rather something like this: "a librarian enters check out information in order to let the reader borrow the book while keeping the catalog up-to date" (remember, the system is built to satisfy the business needs of the library; also, as a side note, I used the user story–style description here [role-what-why]). (Of course, maybe the library has a reader-facing portal that's part of your system, but that's a different situation, and a different use case).

So I would just treat the librarian as the primary actor. When modeling anything, you have to make a decision on where the boundary of the model is. E.g., if the reader is actually buying the book for someone else, is that someone else the initiator - and is it helpful to think about the problem in that way? Based on your question, you implicitly set the boundary to include the whole library as an entity, rather then just the system that you are building; that may feel natural, but it isn't necessarily useful from software development perspective.

A note on secondary actors. When following any practice or recommendation, try to figure out the reason behind it - it's not always easy to do that, but it's worth contemplating it. So, why do we make a distinction between primary and secondary actors in the first place? The idea is to identify the main business reasons for the existence of the system, the main functionality that it should have in order to satisfy the needs of the people for whom it is built, so that you can structure the system in terms of those main needs. This is about the "why" behind things - not for philosophical reasons, but in order to gather information that's relevant when building a system for someone.

Describing things in this way needs some practice, but it's important. To use the same example, a librarian doesn't want to access a specific screen to enter data about a book (this is missing the business-oriented "why"); instead, a librarian wants to enter check out information so that they could provide, in an organized way, a primary service the library offers (lets readers borrows books, keeps track of books). To figure these out, you will need to talk with people who work in your domain and who will be using the system (the domain experts). Understanding these let's you make the right architectural trade-offs (and there are always trade-offs), and come up with an initial architecture that supports the most important users and the most important functionality. I say "initial" because you still may need to tweak it as you learn more about the domain in the future, as you notice certain change patterns emerge, etc.

Secondary actors are supporting actors, in the sense that they exist to support the workflow of primary actors, but aren't in and of themselves drivers of the business value. Note that you don't have to come up with all these up front. Try to identify the primary actors, then revise the model as you go along, for as long as doing so is useful to you. Trying to get it all right up front is a very waterfall-y; in an agile setting, you have short iterations, and these let you learn, test assumptions, and remodel things over time as your understanding grows.

Answer 3

Although Christophe's answer is very good, the comments between myself and qwerty_so led me to Alistair Cockburn's Writing Effective Use Cases. Although the bulk of the book uses what Cockburn calls the "fully dressed" format of documenting use cases, he also talks about "casual", 'one-column table", "two-column table", "RUP style", "if-statement style", "Occam style", "diagram style" (which is not a UML use case diagram, but the use of sequence, collaboration, and activity diagrams), and the UML use case diagram.

An appendix is devoted to the discussion of UML use case diagrams. In this appendix, one of the guidelines is to place "supporting actors on the right":

I find it helpful to place all the primary actors on the left side of the system box, leaving the right side for the supporting (secondary) actors. This reduces confusion about primary versus secondary actors. Some people never draw supporting actors on their diagrams. This allows them to place primary actors on both sides.

So, the idea of placing primary actors on the right and secondary actors on the left is not part of the UML standard. Even when this book was published (in 2001), it does not appear that it was a standard. This is just Cockburn's style, and he even identifies that some people do not even include secondary actors on their diagrams.

I'd also point out that Cockburn's definition of a primary actor slightly deviates from the one presented in the question. The primary actor is "the stakeholder that calls on the system to deliver one of its services" and that the primary actor "has a goal with respect to the system". This is "often, but not always, the actor who triggers the use case".

There are two questions:

• Who are the primary actors?
• Where do the primary actors go on the use case diagram?

I believe that you can make a case that either the reader or the librarian is the primary actor. Although, in he current implementation of the system, the librarian is the one who is interacting with the software, the reader or library patron is the one who is calling upon the system to deliver a service. This is a question of software boundaries and system boundaries and exactly what it means to call upon a system to deliver its services. This is an opinionated matter - there's no right or wrong here.

Once you've figured out who your primary actors are, you need to decide if you want the secondary actors to be on the diagram. At the end of the day, if you're going to include a diagram, it should be readable. Enhancing the readability may lead to if and how you lay out the actors in the diagram. It may be interesting to start with Cockburn's guideline.

I would be remiss if I didn't provide two more pieces of information regarding UML use case diagrams, though:

From Cockburn, in Writing Effective Use Cases:

If you spend much time and energy worrying about the graphics and the relations, you are expending energy in the wrong place.

And from Martin Fowler in UML Distilled:

In your use case work, don't put too much effort into the diagram. Instead, concentrate on the textual content of the use cases.

A use case diagram is very high level, showing actors, use case titles, and relationships. There is so much more value in the more detailed information that simply can't be presented in a UML use case diagram. If you're to the point where you're nitpicking over where to put actors in the diagram, you're spending energy in the wrong place.

Answer 4

Whether an actor is a primary or secondary actor is NOT a diagram level distinction, it is per Use Case. An actor may be the primary actor of one use case, but secondary to another, so this 'convention' of left/right is not helpful unless you're duplicating actors (which is allowed). The Cockburn definition of a Primary actor is about whose user (sea level) goal is being achieved by the use case - who initiates it is not the definition. If I receive a notification on my phone - who initiates that (and don't you dare say 'time' as an actor)? When I view the notification I get the benefit/value from it and achieve my goal of reading it. Are there one or two use cases there? It depends what you find useful to model - there is NO absolutely right answer (remember, "all models are wrong, but some may be useful").