1

I have a list of functionality that the system should have and I have created a case diagram for it, but I am not sure if it correspond to said functionality and want a second look on my solution. Hopefully it is readable and I appreciate any feedback on my trail of design.

Description of said functions:

The system shall allow people to register as a student or faculty member. To sign up, users must provide their name, e-mail address, phone number, and a password. In addition, students add the name of their program and their student id; faculty members add the name of their department and their employee id.

A user shall be able to search for books, the library system shall indicate the availability for books. If available for loan, a logged in user shall be able to reserve a book for loan. When reserved, the librarian will move the book to a pick-up shelf. To loan a book, users shall login at the library in person, and checkout the books.

The library has an automated booth where users can leave the books and the system shall process the return, upon return, the system shall send a digital receipt sent to their e-mail address. When a book is not returned in time, the system shall send a reminder e-mail with a fine for each day it is late.

The system shall allow users to extend the loan period of a loaned book at most two times. The system shall allow users to have at most five books on loan simultaneously. If a book is not available in current library, but is in another one, users can ask the system to transfer and vice versa. Books have a title, author, ISBN, edition, and shelf number denoting their location in the library. The library has varying stock for different books, it has a single copy for most books but up to ten physical copies for some popular books.

Librarians shall be able to add new books to the system and edit the information of existing books.

The design :

enter image description here

Update based on feedback: enter image description here

zellez
  • 398
  • 2
  • 17

2 Answers2

1

I will not make a detailed review of your diagram, since this is very specific to your needs and will not help anybody else. However, I'd like to address some general issues that are frequent in these kind of diagrams:

  • It appears in the requirements that users may be a student or faculty member (or both?), whereas your diagram suggest that a user is another independent category of actors.

  • Having several actors for a use case is ambiguous. It cannot always be avoided, but here, it's not clear if all the actors are involved at the same time for a search, or if they are involved one after the other, or if only one may be involved at a time.

  • Your diagram is a functional decomposition of the requirements. For example, Register and Verify registry are not independent, but the second belongs to the detailed decomposition of the first, without being an independent user goal (in fact, the verification doesn't make sense without the first). The same applies to all the verifications ("maximum...") as well. This is not forbidden but strongly discouraged as it leads to too detailed and complex diagrams.

  • Sometimes your diagram seems to be a sequence of action: e.g. Return a book is followed by a confirmation email. Use-case diagrams shall not show any sequence. If you want to show the workflow, you need to use an activity diagram and not a use-case diagram.

  • extend corresponds to an optional use-case. Here, you seem to say that books are returned only for some loans.

In conclusion, simplify your diagram to show only user goals. Avoid extend and include dependencies as much as possible, to keep it simple and understandable. If you want to document details, document them in a narrative, not in the diagram.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • I will use `Register` as example. If I understand, It should just be register. Do I just ignore that the student needs specif way to register and also the faculty members or do I put them in a generalization relation connected to `Register`? – zellez Sep 08 '22 at 21:32
  • @zellez a first question is to see if `Register` is really a user goal. In most of the case, it's just a constraint, because people don't register for the purpose of being registered, but only because it is necessary to do for something else. Moreover, you could imagine that your system may implement some SSO mechanism, and that the user does no longer have to register because he/she registered elsewhere. – Christophe Sep 08 '22 at 21:57
  • @zellez but putting this first question aside, indeed: you could say that User registers, and that `Student` and `FacultyMember` are specialization of the User. You could also get rid of User and only show `Student` and `FacultyMember` and disambiguate with a comment or a {xor} constraint that it's either the one or the other. – Christophe Sep 08 '22 at 22:02
  • @zellez does this help more guarding the generalization: https://stackoverflow.com/q/65675822/3723423 ? – Christophe Sep 08 '22 at 22:08
  • I know I am late, but had some family thing, but I am back now. I tried to adjust my design based on your feedback. I am still not quite sure about if I am using includes/excludes right or if they are necessary at all. Not expecting a long answer, but a short answer like you need to simplify more or something. It would be appreciated. I am just trying to grasp this and dont have anyone else that I know to confirm my designs/questions on the matter – zellez Sep 26 '22 at 22:10
  • @Zellez It is indeed an improved diagram. Remarks: 1) The inheritance says "Students are Faculty members". I'm not sure it is true, so I think that having a `library user` as a general actor, and `Student` and `Faculty member` that both inherit from `library user` would better correspond to the distinction the narrative tries to make. 2) the arrow of include is in the opposite direction of extend. 3) Book is not a use-case. 4) `send confirmation` and `reminder email` are probably not use-cases either, but details in the activities performed to implement the use-case. – Christophe Sep 26 '22 at 22:27
1

To boil it down: this is no use case synthesis but functional decomposition. Use cases show added value for actors. Full stop. This is obviously the hardest thing to learn when finding use cases. They are like pearls you have to find. It's not about the how-to.

I recommend reading Bittner/Spence about use cases.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86