I am working on some software modeling/design homework and I'm having trouble wrapping my head around how to turn this particular use case into a Collaboration diagram. I found this excellent tutorial, but the use case I am studying introduces a "UI" component that I can't find an analogy for.
The problem in question is quoted:
Use case name: Report Emergency
Participating Actors: Initiated by the officer and communicates with correspondent
Flow of Events:
The officer activates the “Report Emergency” function of her terminal
System responds by presenting a form to the officer
The officer fills the form by selecting the emergency level, type, location, and
brief description of the situation. The officer also describes possible responses to
the emergency situation. Once the form is completed, the field officer submits the
form.
System receives the form and notifies the correspondent.
The correspondent reviews the submitted information and creates an incident in the
database. The correspondent selects a response and acknowledges the report.
The system displays the acknowledgement and the
selected response to the officer.
Precondition: The officer is logged into the system
Postcondition: The officer has received an acknowledgement and the selected response
from the correspondent, OR the officer has received an explanation indicating why the
transaction could not be processed.
As I understand it, associations in a Collaboration diagram indicate the flow of messages between objects, and don't necessarily reflect the physical relationship between what the objects model. If that's the case, then which object should be responsible for the newEmergencyForm() method, and which object should be calling that method? Couldn't the newEmergencyForm() method and the reportEmergency() method be rolled up into one?
Now (current UML standard is 2.4.1) the diagram is called Communication diagram, not collaboration one. Collaborations remain as elements of some diagrams, but they have other sense.
As I understand, Report Emergency is filling the form. And newEmergencyForm is providing the form to be filled. These are two different actions, you already know the difference between them, so, you have no need in not noticing this difference and counting them for one operation. But if for some reason you wish to postpone showing the subject for later diagrams, you may do it. It is NOT against standard.
I wouldn't name the things that create these messages 'objects'. On this level of abstraction we rather speak on components.
You can't say what component creates some message until you define all components. You can do it in head, it is OK, but then we cant't help you with the choice. What is 'system'? (on this level we do not talk on system as a whole, it is the term for Use Case. What is çorrespondent'? Is it the same as officer or can be same? Or is it a subsystem? What other components do you have?
Else you have to provide us the Component diagram as a source. BTW, I am almost sure that after correct defining all components you will find the solution yourself.
Related
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 am fairly new to UML especially use case. My question is should we divide use case to represent the flow of our systems?
For example, Party Management System has features like Party control, Mission Control and Participant Control. One participant can join many parties and parties can have many participants.
Users after login can choose All parties they currently enroll through Show Party button. Parties can be created by users and thus they will become Host so that they can invite Participants to join and give them Missions.
Selecting one party will direct user to Party Name page. From there, Host can Invite Participants via Participant Control tab, change their role into Host or Participant handle Mission to them in Mission Control tab contained in a specific Party.
Host can change party type to Open/Invite Only in Party Control tab or change name and date.
Only host can modify Party Details and assign Mission, participants can view missions that are assigned to them but cannot modify anything. All the tabs are placed at a Left Side Menu Bar.
We have 2 primary actors, Host and Participants. So my question begins here:
1. Should I divide use case to 4 use cases: All Parties (which will have Show Party process), Party Control, Mission Controls, Participant Controls just like the basic flow of the system (After login, users are in dashboard. From Dashboard, Choose Show Party—> Party Control, Mission Control, Participant Control)?
2. With each Use Case diagrams, I will add a Flow Chart to further illustrate how users interact with system, if just one Use Case diagram is need in this case, should I break down those features into many Flow Charts?
Thank you for reading my question!
No! What you are talking of is functional decomposition and that is not part of use case (diagrams). A use case "just" shows the added value it gives to an actor of the system under consideration.
When it comes to implementation details or "user stories" you can either use a Cockburn-like textual description or choose activity diagrams. It's also possible to have a mix if you have complex scenarios. However, there shouldn't be an overlap since then you have the question: which one tells the truth. Edits over time will likely diverge and leave some mess behind.
As always I recommend to read Bittner/Spence about use cases!
P.S. Basically #Christophe's and my answer are similar or at least they do not contradict. I'm just stressing a bit more that functional decomposition is a no-go on use case level.
Yes, use-cases can be broken down into several distinct diagrams that each show a part of the larger model.
But no, not a breakdown by flow: Use-cases are not for modeling flows. Use cases should correspond to user goals and should not to show how these goals shall be achieved:
for user interface details (e.g. the button, which leads to a feature, then the next...) you may use wireframes
for a more global design of user experience, you may consider story boards or user journey maps.
for a detailed flow of control or objects, you may consider activity diagrams instead of flow charts. In fact an activity diagram can specify a behaviors that allows to achieve a complex use case. However, withstand the temptation of “visual programming”.
But the use-case itself should be independent of how it is implemented and leave freedom for user-centric UI design. What can this system do for its users is the main question the diagram should answer.
I need to create an expense tracking tool. This tool will allow an individual user to keep a record of their expenses and also to predict financial status at a certain date.
User Interface
This will be built as a .NET C# windows forms desktop application. You are free to design the user interface as you wish but here are the minimal requirements.
The interface must have at least these views:
A contacts view for entering and updating the details of contacts (payers
or payees).
An expenses entry view for entering and updating expense details for a
certain day.
A financial report view – showing all expenses for a chosen date range.
A view that enables the user to see their predicted financial state at a
certain date.
For extra credit:
A view for entering events: appointments and tasks.
A weekly view displaying daily events and expenses.
It is up to you how you design your forms. We are purposely not giving you a
design example to avoid everyone having the same design. You are advised to
create mockups and storyboards and modify them iteratively as you develop your design document.
Your design decisions should be included in your report.
Persistent storage of run time data
The data for the expenses will be created by a view that allows the
specification of the expenses to be entered for a date, and this should be a programmatic dynamic interface. Once the user has finished you need to save
the expense data as an XML file and in a database of your choice. When the
application is run again (after closing) the system shall use the XML data to
populate the data on your interface. It should use the database data for the
financial report. When writing to or reading from the database the activity
should be threaded (to enable the interface to be useable while writing to an
external database)
My UML diagram
Can you please review the following diagram ?
Are use case suitable for UI requirements ?
A use case represents a goal that an actor wants to achieve. It is a behavior (in general an action). It's not how the user shall achieve the goal; not either the description of the user interface; and even less a data model.
If you have to design a user interface (as the narrative of your exercise seems to require), you might not need UC but rather wireframes to sketch the UI.
What are the UC in your requirements ?
With this in mind, I would identify the following UC in your requirements:
Manage contact details (#1) - I used Maemphasized textnage to shorten Enter or update -Open question: maybe two UC after all: Manage Payer details + Manage payee details.
Manage expenses for a day (#2) - the selection of date is a detail of the UI, not a UC !
Report expenses (#3) - the selection of date range is a detail of the UI, not a UC !
Forecast financial situation (#4)
Enter (maintain?) events (#5)
Report weekly situation (#6)
What can be improved in your diagram ?
Now a review of your own UC diagram:
Select data range could be an include for Add transation and Generate reports (caution: typo), since it is a part of the behavior and the including UC are incomplete without the included UC. Note that having it as a separate UC seems to me artificially detailed and not to be recommended.
Select data range should in principle not be an extension for Add transation, because an extension is optional and the extended UC should be complete without the extension. And here, it makes no sense to Add a transaction without knowing the date.
I'd suggest to change the UC name from to an active behavior: Chose/select data range, Generate/Report weekly view
You currently use generalization in your use case. Although it is not the most common practice, this is perfectly legal: the UC is a classifier and classifiers can be generalized. However, when generalization is used in an UC, it's generally with the same graphical flavour as all the other "links", separate and between only two elements, and usually not in the shared target form (example). Note that the naming of your specializations sound like nouns corresponding to data objects (e.g Payer) rather than behaviors (e.g. Manage payers). Note also that a typo caused Payee to be there twice
Edit: more about generalization in UC
There is some controversy on use of inheritance in UC since its practical meaning is not as intuitive as the other kind of relations.
Inheritance could be useful when there are several variants of the same UC. It's the principle of abstraction. But a UC should give an easy overview without loosing readers in details. So a better practice would be to keep your diagram without showing the specialisations, and have a second diagram dedicated to these details.
But personally (and looking at the comments and other answers, I'm not alone) I recommend not to use it. It makes a simple and easy to understand diagram, in something more complex with different levels of abstraction. In this reagard, it's worth to mention Ivar Jacobson, the inventor of UC:
He didn't use inheritance in his UC before they were included in UML.
He does not either use it in his most recent work on Use Case 2.0, where he promotes the use of use-case slices to cope with variants.
Use verb to name your UCs, income, expense, payee, Data Range and Weekly View are not UC but they correspond mainly to data.
Some UCs are missing, all what a user can ask to the system is not covered
I do not know what is the right UC for DataRange so difficult to check your extend / include but as Thomas Kilian I have a doubt about them
MAKE RESERVATIONS is the activity and it states the following:
A customer contacts a reservation officer about a car rental.
The customer quotes the start and end dates needed, the preferred vehicle, and the
pickup office.
The reservation officer looks up a prices file and quotes a price.
The customer agrees to the price.
The vehicle availability is checked to see if an appropriate vehicle is available for the
required time at the required office.
If the requested vehicle is available at the nominated pickup office, then it is
reserved for the customer. An entry is made in the vehicle availability registering the
reservation.
The reservation officer issues a rental number to the customer.
A rental agreement is then created in a rental file, including the rental number, the
rental period, the vehicle type and the pickup office.
Exceptions
An appropriate vehicle is not available at the pickup office. The customer is offered
an alternative vehicle.
The customer does not agree to a price and asks for an alternate vehicle and/or
period.
I designed the activity diagram for the activity above yet I don't know whether I have to put the question in the decision node or above on the control flow? In my case, the Agree to Price should it be on the decision node or on the control flow arrow that inputs the node?
As well as that, if a use case only specifies a condition, such as " If a vehicle is available, the customer is offered the vehicle and a price is quoted. If the customer accepts then a rental is initiated." how does the decision node look like?
Moreover, what if there are three different actors, should there be a swimlane representing the actors or can the activity diagram be drawn without one?
The activity diagram for the use case above is posted below
I don't know whether I have to put the question in the decision node or above on the control flow?
They are written in the flow, as you did. In UML the decision node is empty (this is a difference from basic flowcharts, where one would write the condition within the node). Each flow coming from a decision node may be annotated with a guard (i.e. condition). When the decision node is executed, any flow whose guard evaluates as true may be selected for execution (Usually, the conditions of the guards are exclusive, and only one guard may be selected, but that is not a requirement).
As well as that, if a use case only specifies a condition, such as " If a vehicle is available, the customer is offered the vehicle and a price is quoted. If the customer accepts then a rental is initiated." how does the decision node look like?
It looks as in your figure, but there should be an action node for asking the client before the decision node, because the only purpose of the decision node is choosing among several possible flows. No actions are executed as part of the execution of the decision node.
Moreover, what if there are three different actors, should there be a swimlane representing the actors or can the activity diagram be drawn without one?
It depends on what you are modelling, if you have different actions performed by different parts of your system, you may use swimlanes (I recently drawn an example here), but you may avoid swimlines if it is not interesting to model that separation. Normally, the actors would provide input to the system, but they will not be executing actions by themselves.
For instance, your example model the behavior of the reservation officer (which is part of your system) based on input from the customer (the initial quote and agreement) and the customer receives output (the rental number). I recommend that you ask that as a separate question emphasizing on the third actor.
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