Worked out a use case diagram question from a past year paper. Would like some feedback on whether my diagram is correct based on the following question. Thanks for any guide.
Question:
University new library system.
Students will use computer terminal to check availability of a book.
Student library card is scanned into the system.
System searches through the student database to check the student's borrowing history.
Student allowed to borrow a book subject to the following 2 constraints:
They have no overdue books
Currently no more than 4 books on loan.
If loan not permitted, the librarian can override the system and enter a code to allow the loan.
Student can borrow from another university's library by accessing inter-loan system to find to find book and place order.
The above check of the student's card is again performed.
Special books within library cannot be borrowed. They can only be consulted. Also subjected to the 2 constrains previously described.
Finally, students have access to printer, using credits previously added by a 3rd party on his card. The card check for the printing process is
subject to the constraints previously described.
Construct a UML representation of the processes described above. This will involve the production of one or more Use Case Diagrams.
Answer:
Link to my UML diagram:
http://www.picpaste.com/pics/exam_uml-sCmMDwtm.1390472335.jpg
No. You shouldn't put any "if" logic into use case diagram. "No Overdue" or "Not >4books..." belong to more concrete diagrams - sequence, state, Activity, Interation Activity, maybe, Timing. But they are NOT use cases.
On the other hand, you have no system elements here. Use cases are subjects of dialogues between agents, that are people and system components or subsystems. You have only people here.
Also, you have no login activities here and no administrator. But maybe, it is out of the scope of the task.
Printer should be a subsystem. But you do not have "Print" use case connecting User and Printing Subsystem
Edit:
If you consider the checking so important to be present on the level of Use case diagram, create a subsystem for it and a use case or two between Actors and this subsystem.
And I see one more problem: interlib loan system and DB should appear as subsystems and access to the first and history check remain as use cased connected to them.
And I can't help with "consult special books", because I don't understand that at all.
And where are such base operations, as search for a book, search for the author, scan the card?
Notice, that your "includes" should become normal use cases between subsystems.
Related
I have a task to make a simple information system for the functioning of a guest house. I need to make a USE CASE diagram, but I don't know if what I've done is correct, or if I need to add something, I don't know where to include the maid.
As users of the system I have put - client, receptionist, manager
As objects of the system I have put client, room, occupied rooms, employees (maids, receptionist, manager), tour agency, payment
Can you give me a hand?
Well, you are at the verge of functional decomposition. And that's not what UCs are about. They are about added value. So the bubbles contain headers describing those added values. For a hotel the basic UC would be Reserve room. (A real hotel would of course offer more added values, but for your example that's it.)
Now, the reservation is usually going along with payment. But would you consider that added value? I would not. So rather than making these UCs they are constraints (from requirements defined elsewhere). There's a lot one could talk about representing requirements and business rules, but that is far too much for a discussion here. I recommend reading Bittner/Spence about UC sythesis. It takes that book and a lot of experience to get familiar with this area.
Note that UCs are described with subject/predicate(/object) to be meaningful. Room is no UC. If you intend to show an object, use a rectangle (with object notation). That however, is in most times more confusing than helpful. Stay with actors and (real!) use cases.
Another note: the downward association from Hotel manager should rather be a generalization (open triangle instead of an arrow). And the actors usually are also shown with arms ;-)
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 :
Update based on feedback:
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.
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.
I've been asked to make a Sequence Diagram for a Casual Employment System in which includes mainly the Applicant, Employer and System. Following my Use Case and Class Diagram, I have used the info I Have to produce a sequence diagram for the Applicant which I have been assigned as actor. My teacher came up with the following comments:
Frames can only be alt, opt or loop.
You can't have multiple arrows into the same activity bar.
It looks like applicant and employer are humans. sequence diagrams are of software not humans.
There is no method name for the driver method on the left.
There is only one participant for the software "System". You need to have many participants each is a class.
My question would be:
what other participants can I have besides the "system" for the Applicant to interact, what other classes can I make?
User Story:
As an applicant, I want to be able to
create an account so that I can apply/search for available jobs.
create a job preference so that I can work in my desired field.
update my employment status.
change my job preference.
create and modify my availability regularly so that my work time will cope with my personal / school schedule.
add or update my employment records.
add or update my reference.
upload my CV online.
select my interview time, IF I get an invitation to an interview (for shortlisted candidates ONLY).
accept/reject job offer.
make a complaint about my employers if necessary.
If you know how to create a class diagram: take the classes in that diagram.
If you know an object-oriented programming language, take the classes you would have in the software.
Otherwise, look at the nouns in the user story: account, job, etc. These will be classes. Some nouns are not classes, but just attributes of classes: desired field, employment status etc. You may ignore these.
All these classes are part of the system. Do not include System as a participant.
I have heard conflicting things about this and just wanted to clarify.
I have always thought that when constructing a Use Case Diagram, I only include the activities that will be carried out by the system. For example, if it were a bank atm, "User depositing money" would be included, as it involved the user interacting with the atm. However, "User is paid cash in hand from job" is not included in the diagram, even though it may bear relevance to a scenario or situation.
Thanks all
The fact that the user is paid in cash is in any way related to the information system which is a system involving people. The payment transaction has to be integrated with your project, at least on a conceptual point of view. In other words it should have a relationship of an unspecified kind with a use case, depending on the context.
I recognize my answer is quite messy: if you're already getting bored, jump directly to the solution section...
The use cases diagram
According to The UML User Guide:
A use case is a description of sequences of actions that a system performs that yield observable results to a particular actor.
The point is about modeling what is related to the system: your main problem is to consider the scope of your project.
Depending on the scope you identify, the use case you should consider would be something like Cash withdrawal: consider the observable results from the point of view of the actor. This part is highly subjective whether you consider the operation part of the system or not. I personally disagree with the other answers here.
A few words about being paid cash in hand. On a pure development process point of view, would it be normal to have a sharp idea how a user is being paid while modeling ? Still the scope question here: perhaps is it a strong constraint in your context.
Even when reverse-engineering, a use case is user-oriented, it has nothing to do with how things are done, but what is done: I think nothing to do with especially automating things, even when talking about a system. There is a subtle idea here: I consider an information system, a system involving people in the first place, not a completely automated system. Of course, purely automated systems can be modeled with UML, but most systems involve users.
The relationship between the use case itself and the information how the payment is done has not to be represented on the diagram figure. However, even if this is not in the use cases spirit, the way it is done could be written in a note if it is an important constraint the diagram reader should be informed of.
The solution
In my point of view, the right place to put that information in the use cases is not the diagram figure itself but in a use case description. Martin Fowler gives a few hints about this in UML distilled. You have a simple use case description example here. This is related to the way you are using UML and the way you wish to describe use cases (I personally share Martin Fowler's perception).
Perhaps you would prefer to represent this with a formalism specific to your modeling software, but I think this would not be a traditional way of using UML (appropriate for an Executable UML, not appropriate with blueprint or sketch).
It is not included because the "User is paid cash in hand from job" is outside the scope of a project and would not be needed for what you are trying to create.
Most often use cases are used at the functional/logical level of your model (MDA's PIM level). This means that it only describes those parts of the process that will be automated.
So unless your system has a feature that somehow records the fact that the user is paid in cash, that isn't part of the system under construction.
At the business/conceptual (MDA's CIM level) level however you model the whole processes, regardless of automation. So at this level it "User is paid in cash from job" would certainly be at its place.
I have a scenario where a customer calls and gets an appointment at a garage. When drawing a UML Use Case Diagram, is the actor who is connected to placing this appointment inside the system (a) the customer, or (b) the employee?
The person that has their fingers on the keyboard and mouse is the actor. The person calling in is important from a business perspective, but not as important as the customer service rep that is interacting with the system.
Knowing that the actor is a CSR helps the screen designer and even the developer, because they will work from that perspective, ask for requirements or design clarifications from that perspective, and the system will be better as a result.
The reason the conflict exisits is because of the point of the project when you start drawing these use cases.
In your example, you already know that there is a CSR using 'a system' to make the booking.
However the design could have started from scractch. If this had happened the initial broad use case would have been 'a customer wishes to make a booking'. This could have lead to a number of differenc cases i.e. a customer will call a telephone number and an automated service will make the booking, a customer arrives at the garage and uses a terminal to make a booking or (as in your case) talks to a CSR (however that is i.e. phone or face2face) and they make the booking.
In many examples the customer would be the main actor in the system. However in your design the CSR is the one holding the mouse/keyboard/phone/pen or whatever and you don't need to design the iteraction between the customer and the CSR! Most societies did that years ago :)
It can be both. It depends. There is no single good way to model this. I would personally opt for the customer.
It is btw perfectly alright to include the phone as part of your system. So the boundary of a system does not have to be a defined by screen, mouse, keyboard. A printer might be included too as part of the system. I have written use case where it was quite essential that users printed some information and file that.
Who is the important actor here? The customer right? It is interesting to note here that Alistair Cockburn extended the actor and goals model of Ivar Jacobson with the actors and 'interests' model. His advice is to also think about who cares (or gets hurt) if user goal fails.
Is it important to get the actor just right? It is useful to brainstorm actors to find all user goals against the system. When you are confident you have found all goals, the actor is not so important anymore. Would you 'write' a completely different use case depending on this decision? Would a different system be build based on the outcome of this decision?
Who initiates the interaction? What is the event initiates it? This event is the decision of customer to call to make an appointment.
You could model customer as primary and employee as secondary actor helping customer to reach user goal. Both use phone and system to reach the goal, customer helped by employee. How they do that exactly is design?
Another consideration is that the 'actor' is a role. So you could use a role Appointment Maker. Some people care a lot about keeping job titles separate from roles as there typically some flexibility in roles that job titles perform.
There are also people who are of opinion that use of 'system' in describing use case is undesirable. They feel that it is a design/implementation decision and so they prefer more neutral 'Performer'. The Performer could be a system but also a human. In use case texts they use 'Initiator' and 'Performer' and in introduction of the use case text they explain that the 'Initiator' is in use case the Appointment Maker.
I personally think it would be fine and better if the use case was described as if customer was the one operating the system. The employee is just passing along information from system to customer and vice versa.
The book by Alistair Cockburn is a recommended read. His insights really helped me with questions like this one. It also helps to make sense of UML in relation to use case