2

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?

3

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

  • 1
    When I want to analyze a system, to figure out the use cases, investigating member needs gives me more hints, cause the services are for him? could at that stage use member as the actor? – Ahmad Oct 13 '14 at 17:16
  • The Borrow a book use case isn't a service of the system you are currently talking about. You are talking about the library, and only the librarian is associated with the 'borrow a book' use case. – naiveai Oct 18 '14 at 16:42
1

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.

  • Thank you, in the last paragraph of my question I asked when I should use the member and when the librarian, I mean maybe in the analyze stage to figure out the use cases its better to suppose the member as the actor, because the services are for him logically? – Ahmad Oct 13 '14 at 17:14
1

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: enter image description here

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

0

You need to be accurate when you define the use-case subject, that is the system under consideration.

Use-cases are mostly applied to software, for example a library software. But Ivar Jacobson, the inventor of the use-cases, also wrote a book about applying use-case to business analysis in which the system under consideration is used for departments or even companies. And this makes your question very ambiguous.

What's the problem with your question ?

suppose the system is : Library

What does this mean ? Is the library the library the building ? Is the library the facility and its books ? Or do you mean the library as an organisation ? The correct answer depends entirely on your definition !

As we are here on "software engineering stackexchange", the other contributors all understood that the library was the library software. But this does not match your statement. So none of the other answers is right, despite they are insightful if you would have said that the system is the "library software".

What is the right answer ?

If the library is the facility and the books, the librarian would be external to the library, and he/she would be an actor. For the use-case borrow a book, the primary actor, the one who would expect the most value from the interaction, would be the member. But the librarian would be involved in the use-case. He/she'll be a secundary actor.

If the library is the organisation or the company, the librarian would be part of that organisation (human resource) as well as the facility and the books (material resources). The only actor would be member. Perhaps a secondary actor could be the local authorities if the library has to fine you because you don't bring the book back ;-)

If the library is in fact the software use by the library, the primary actor of the borrow book use-case would be the librarian, since he/she would interact with the software, whereas the member would interact with her. Unless it would be an ultra-modern library, where users could self-register their borrowings, the exit door opening only if all the detected books are registered ;-) Anyway, for the software case, you could have a look at all the other answers which are all very relevant.

Now in this last case, the member does not interact with the system. According to the UML specs, the member is therefore not an actor:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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