Use case diagram : distingishing the actor of a use case

Question

I know a system contains a set of use case diagrams and not one use case diagram, but anyway in the first step to find the system requirements or to analyze them I have problem in distinguishing the actor of a use case.

suppose the system is : Library

one actor is the Member and one actor is the Librarian.

a typical use case is Borrow a book

Suppose the one who interacts with the software is Librarian. Then borrow a book should be associated with librarian or the member?

In fact Borrow a book use case is a service of the system for the member. but the actor who interacts with it is the librarian.

In which stage and in which use case diagram I should use the member as actor and associate it with the Borrow a book use case? and in which diagram I should associate it with the librarian?

Also the librarian is really an actor of the system or its part of a system?

Answer 1

Remember the definition of an actor: an entity that interacts with your system. The librarian is the one who is actually interacting with the system (the library), whereas the member is just requesting the librarian for a book, and does not care where the hell that book comes from. Then the member is an actor on the librarian, who is a system in herself.

The librarian: a system, actor on the library

Library: a system

Member: an actor on the librarian

Answer 2

In most cases both the librarian and the member could be seen as actors: the librarian is the primary actor and the member is the secondary actor.

The librarian is the primary actor: he fulfills the use case.

The member is needed for giving his library card to the librarian: without him/her there is no use case. And the member receives the book.

So they are both actors, but with a different importance to the use case.

Another example: If the borrowing system is automated, then the member is the only actor and the librarian is not needed to borrow the book. The member will trigger the use case, and the librarian only helps when necessary.

Answer 3

Yes, The Library Staff should be the primary actor, as he/she is the one who interacts with the target system.

In a typical library system, usually the library users only have limited right to access the system such as check the availability, or reserve for a book (but not checking in / out of a book.

For Example:

A computerized library system for a university keeps track of all books and periodicals in the library and their check-out status. Checkout and return are automated through a bar code reader (an external device).

The library system also interfaces with an external relational database which stores information about the library users (students, faculty, and staff), including whether they have any library items checked out.

Library users can access the catalog and recall books and periodicals.

Library employees have the same access as an Library user, and as well as additional capabilities (e.g., check-in and Check-out of Book).

Note:

1. the library catalog is part of the library computer system so it is not shown as an actor.)
2. Employee Login is may NOT be a good use case, as it does directly fulfill a user goal

The example illustrates how the main role (primary actor) of the system associated with their corresponding use cases

Answer 4

Actors interact directly with the system while being external to the system. People who don't interact directly with the system but benefit indirectly, are stakeholders.

The actors with therefore depend on what Library system is:

• Library facility: the librarian and the member would both be external to the library and interact with it. They both are actors. For the use-case borrow a book, the primary actor would be member since the use-case is meant for him/her . The librarian would be involved as secondary actor to support the use-case.

• Organisation (e.g. a company): the librarian would be a part of the organisational system and not be an external actor. The only actor would be member.

• Software system: the primary actor of the borrow book would be the librarian, since he/she would interact with the software, and the software was designed with this job in mind. The member would interact with the librarian but not directly with the library system. Therefore the member is not an actor. It's a stakeholder who benefits indirectly of the system. Of course, you'd need to adapt this analysis if it would be an ultra-modern library, where users could self-register their borrowings.

Remark: There are already plenty of good answers here for the software case. I just wanted to highlight the necessity to have system boundaries clearly in mind before actors can be distinguished.