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!
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 trying to design a use case diagram for the following scenario.
I have a society that is distributing goods to clients based on their orders. These clients can be administrations, companies, or private individuals.
Depending on what the client is I want to know more or less of their info (name, number etc)
The use cases are different depending on whether the client is:
English
English and have used this service for more than 3 years
Foreign
For example:
The 1) English clients' orders are accepted only if they pay a small fee in advance.
The 2) English clients that have used the service for 3 years don't have to pay this fee but need to get approbation from a different actor (an Agent in this case)
The 3) Foreign clients' orders are always accepted no matter what.
This right here is where I run into trouble and need help with.
The orders from nglish clients that have a criminal record are always denied UNLESS they are an administration.
What are the most optimal actor choices here? I thought of going with English client, and Foreign clients but I don't know how to include the "Unless the client is an administration" in the use case.
The use case diagram is not the right place to put this information. As correctly pointed out by #Christophe, a use-case represents a goal for a user who is going to interact with the system to achieve the goal.
This means that there is only one single use case in your scenario: "Order Goods". However, it has a set of preconditions. You could list them as structured plain text. Since there is quite some complexity behind each of them, I recommend to put them into a separate decision chart. Then you have a nice clean separation of the diagram scopes, and they remain easily readable.
Sidenote: There could be a second one "distribute ordered goods" executed by a 2nd actor who is an employee who does fulfillment / routing / dispatching.
Actors in UML use-cases are classifiers. To decide about which actors to create requires to understand the actors their goals and behaviours and how they differ in the interaction with the system.
First of all, you need to clarify the super-ambiguous requirements:
"English client": is this a client with English nationality? Is it a client that lives permanently in the UK? Is this a client with an address in the UK? Is it a client with a +44 phone number?
"Foreign client": same kind of questions + can you define for sure the difference between Ensglish and Foreign? For example: what with bi-nationals? what with people having two addresses one being abroad?
"Using this service more than three years": what with a foreign customer who uses the service for 3 years and then settles in the UK?
Since you deliver goods, you might also need to consider a delivery address. What with an English client ordering on a foreign address or vis-versa ?
"criminal record": the criminal record might change over time: is it provided at each purchase? or is it part of the customer registration process ? In the latter case, is there a need to periodically renew this information ?
Use-cases should in principle be goal oriented. So a use-case represents a goal for a user who is going to interact with the system to achieve the goal. Use-cases are not meant to describe the detailed sequence of your process (if client is this, do that, etc...) and neither are actors meant for that purpose.
You should therefore consider reformulating the use-cases to represent how the actors would perceive them. If needed you may consider the status of the actor that could explain that an actor behaves very differently. Typically in your case, I could imagine :
New client: a new client may want to provide details (address, identification) or evidence that they are entitled to buy (criminal record - I suppose your activity is regulated if you request such details)
Public administration: behavior of administration in purchase is anyway different because of public procurement and legal constraints.
Privately owned company: behavior is different since it can involve several persons,
Private individual
The need to pay an advance fee seem to depend on the address, nationality, history. It's more related to the process (it's a part of it) than an independent goal for an actor. So I would neither show this as a use-case nor make different actors for this purpose.
The reason to deny an order is not something that is not relevant for the customer (no customer has a goal go get a purchase denied!). It's relevant to you and your system and is a consequence of the registration process. So no need to have a dedicated actor for that.
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!
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.
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.