Here's the question:
CarHere is a national car rental company that provides low cost car rental extensively in the British Isles. Their cars are available through their rental offices located at all main airports and some central city locations. They currently have a poorly performing computerised system that is to be replaced. A team has now been commissioned to start the development work.
When a potential customer requests a rental from CarHere company the booking clerk takes the rental requirements that include the pick-up and drop-off times and places, the class of vehicle and any special needs. A booking will be made once the details are agreed. All bookings are provisional until confirmed by the customer before the given confirmation date
.
For each booking, the booking clerk will record the details of the customer and any other drivers they nominate: title, first name, surname, telephone, address, licence number and class of car to be rented and any special features. Once the customer pays the full amount the clerk will record the payment details: payment date, payment method and amount. The clerk then updates the bookings as “confirmed” and issues a rental document to be signed by the customer. Payments can be made by credit/debit card or in cash. Confirmed bookings may be cancelled no later than three days prior to pick-up; the payment is reimbursed, less a charge of 10%.
Every morning a list of provisional bookings that are overdue and a list of all cancellations for confirmed bookings are produced. Provisional bookings are then cancelled and customer is reimbursed.
Here's my diagram:
Is there anything I can do to improve the diagram?
First, you want to understand that included use cases are required and extensions are optional. "Add payment record" doesn't look optional, and neither do the extensions to "Get rental requirements." So, if you're not clear on this, you'll want to revise your extends and includes accordingly.
Next, don't try to fully explain the behavior of a use case in terms of other use cases it includes. If your included use cases are really part of the base use case, then leave them out. There are other ways of documenting the behavior as I will explain.
Next, if you have different ways of accepting payment, you might want to have each as a separate use case that inherits the "Pay" use case.
Finally, to fully explain the behavior of a use case, use an activity diagram, one per use case. You can go into whatever detail you want there. You may also want to google "use case narrative" to see ways that you can verbally document the behavior of a use case; this narrative is what an activity diagram would depict. If you have a particularly complex path through a use case, look up "use case scenario" and how to document one with a sequence diagram.
Related
I'm currently attending a class on UML diagrams where there are lab exercise which we need to complete.
In lab exercise, there are various data class in regards to the topic Supermarket. One of the data class is called Receipt which include attributes like id, payment datetime, purchased items and total price. There is also another data class called Payment which include a payment type attribute, Payment data class is "linked" to Receipt data class, however I'm not sure which relationship to use.
The full question paragraph is as follow:
Shopper arrives at checkout counter.
The total price is calculated and the shopper is given an receipt which includes a list of purchased items.
Payment is recorded when it occurs, either now (cash) or later (card payment).
Assuming that you make a class diagram:
The "link" is a simple association, since nothing in the wording suggests composition or aggregation.
"Payment is recorded when it occurs, either now or later" means that it is possible at some moment in time that there is no payment (yet) for a payment.
"either now (cash) or later (card payment)" strongly suggests that a receipt is paid with a single payment (multiple partial payments are not excluded by the wording, but it seems improbable).
so the multiplicity is 0..1 payments for a receipt.
Nothing is said about the multiplicity of receipts for a payment. We can imagine that there is a minimum of 1, since nobody would make a payment for nothing. But it cannot be excluded that a payment with a credit card is made for paying several unpaid receipts at once. I would therefore prudently let it unspecified in the diagram. In the real world, this is something that you would verify with your customer. In your exercise, depending of the practice you've witnessed from the professor, you may want to put a 1.
So here the simplified diagram (I haven't shown properties and operations for the sake of simplicity, nor the items which you dodn't mention as a problem):
I've written a script to make a cafeteria system at college. I need to know whether my diagram is correct, especially the shares of the operations.
The student selects one of the restaurants available in the cafeteria.
The student selects the item you want with the possibility of adding some ingredients to the item and receive the sellers.
The student pays to the seller. The delivery of a request is included, an update to the store at the moment the student is paid.
The seller's issue the invoice to the student and includes an addition to the account of exports and imports of the restaurant.
Administrator for the restaurant When you want to add new item, the sellers are notified of the new item added.
Administrator records attendance and absence of sellers.
Use correct naming for use cases: predicate, subject (, object).
Do not use include/extend as it's simply mistaken for functional decomposition, which is plain wrong.
Synthesize function descriptions to extract the added value hidden behind those descriptions and make them use cases (single added values the system under consideration delivers to its actors).
It's ok to indicate primary and secondary actors by using directed associations. However, this in no standard, but a convention and needs to be explained in separate modeling rules.
Your saller should likely be Seller. Note the upper case first char too (also wrong with Student).
With little effort your diagram could have been uncluttered!
I need to create USE Case for the following component.
Manage Consultant
Use cases--add consultant, update consultant, add speciality, update speciality Consultants and specialities are either active or inactive.
Speciality is a stand alone class
Speciality is also part of Consultant class
2nd Component
Confirm appointment--consultant views appointments and confirms times. Firm appointment is saved and customer gets email confirming time.
Confirm Invoice--consultant views invoices and, if an invoice has been paid, marks as paid.
Am I right?
From my understanding USE Case does not show the detailed list steps with in the USE Case. So mark paid you don't don't ned to be shown.
For your first diagram: do not use generalization with UCs. Each UC represents a unique single added value for the actor. If there were such a thing as a generalized added value that would never be unique. Remember: there's just a unique selling point, never a general one. Just remove the Manage-UCs and connect the "real ones" directly.
Your 2nd diagram looks fine to me.
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.
Sorry, I know this is a very lame question to ask and not of any use to anyone else. I have an assignment in UML due tomorrow and I don't even know the basics (all-nighter ahead!). I'm not looking for a walkthrough, I simply want your opinion on something. The assignment is as follows (you only need to skim over it!):
=============
Gourmet Surprise (GS) is a small catering firm with five employees. During a typical weekend, GS caters fifteen events with twenty to fifty people each. The business has grown rapidly over the past year and the owner wants to install a new computer system for managing the ordering and buying process. GS has a set of ten standard menus. When potential customers call, the receptionist describes the menus to them. If the customer decides to book an event (dinner, lunch, picnic, finger food etc.), the receptionist records the customer information (e.g., name, address, phone number, etc.) and the information about the event (e.g., place, date, time, which one of the standard menus, total price) on a contract. The customer is then faxed a copy of the contract and must sign and return it along with a deposit (often a credit card or by check) before the event is officially booked. The remaining money is collected when the catering is delivered. Sometimes, the customer wants something special (e.g., birthday cake). In this case, the receptionist takes the information and gives it to the owner who determines the cost; the receptionist then calls the customer back with the price information. Sometimes the customer accepts the price, other times, the customer requests some changes that have to go back to the owner for a new cost estimate. Each week, the owner looks through the events scheduled for that weekend and orders the supplies (e.g., plates) and food (e.g., bread, chicken) needed to make them. The owner would like to use the system for marketing as well. It should be able to track how customers learned about GS, and identify repeat customers, so that GS can mail special offers to them. The owner also wants to track the events on which GS sent a contract, but the customer never signed the contract and actually booked a GS.
Exercise:
Create an activity diagram and a use case model (complete with a set of detail use case descriptions) for the above system. Produce an initial domain model (class diagram) based on these descriptions.
Elaborate the use cases into sequence diagrams, and include any state diagrams necessary. Finally use the information from these dynamic models to expand the domain model into a full application model.
=============
In your opinion, do you think this question is asking me to come up with a package for an online ordering system to replace the system described above, or to create UML diagrams that facilitate the existing telephone-based system?
Create an activity diagram and a use case model (complete with a set of detail use case descriptions) for the above system.
I think it's right there in the text: they want you to document the system described.
Best of luck!