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 .

  • 1
    You seem to be conflating a use case (the actions or steps needed to achieve a goal, along with relevant actors. pre- and post-conditions, extensions) with a UML use case model or use case diagram. However, I cannot find any reference to "primary actor" or "secondary actor" in the UML specification for a use case model - where do these terms and the associated rules for where they go on the diagram, come from? It seems like this question may be based on something other than the UML standard.
    – Thomas Owens
    Jan 4, 2020 at 17:46
  • @ThomasOwens: as far as I'm aware they come from, or were at least popularized by, Ivar Jacobson. I know it appears here, although the concept probably existed earlier, as well as here. Jan 4, 2020 at 18:48
  • @ThomasOwens en.wikipedia.org/wiki/Use_case cites Cockburn. Funny, I never realized that it's actually no UML term. Somehow it felt natural to use it, though.
    – user188153
    Jan 4, 2020 at 19:44
  • @qwerty_so Interesting. I have a copy of Cockburn's Writing Effective Use Cases and, IIRC, the bulk of it is textual/tabular with a bit of UML. His textual/tabular formats do identify primary actors, but I'd have to look through the book to see if he applies any recommendations to structuring the UML diagrams that is outside of the standard. Alternatively, there could have been something in an older version of the standard that has been since removed, and I probably won't dig through old specs to find that.
    – Thomas Owens
    Jan 4, 2020 at 19:51
  • Wiki references Cockburn, 2001. Inside rear cover. Field "Use Case Title".
    – user188153
    Jan 4, 2020 at 20:11

3 Answers 3


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.


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.

  • aren't in and of themselves drivers of the business value when speaking of the people checking out books from a library the whole thing would by pointless without them. So that's probably not true.
    – user188153
    Jan 4, 2020 at 19:38
  • @qwerty_so Well, I wasn't speaking about people who are checking out the books - I didn't even include them in the model as actors (which doesn't imply they are insignificant). I was referring to secondary actors - entities (people, other systems) that support the value-providing operation of the system being built (i.e, they are there because of primary actors). That's just what a secondary actor is, that's the distinction. If an actor is actually performing a "main" action, and is directly providing business value, then it's not a secondary actor. Jan 4, 2020 at 19:54
  • In most points I concur with what you say. But a snd. actor is just one taking part in the UC. The primary starts the UC. In Checkout Book the librarian is the primary actor and the customer the secondary. However, for the business this secondary is the primary one. There might be a library without librarian where the customer checks out books via an automate. Pretty ok for the overall business. Of course here you'd have a different UC with the custmomer being the primary actor.
    – user188153
    Jan 4, 2020 at 22:29
  • I think it's a design question. Putting the librarian in front (per design) will nail that person to its desk (fine for him). But the business to bring books to readers might be solved without that person (even better?).
    – user188153
    Jan 4, 2020 at 22:32

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.