Assignment 2
Worth: 30% of your final grade.
Due: Please refer to Canvas
Late assignments that do not have an extension will be penalised at the rate of 5% per day.
The assignment requires you to carry out some systems analysis and early systems design activities for the Weddings Parties Everything system described here. Read the case study on the next page and answer questions 1-10 following.
Summary of what to submit:
Question | Task | Marks |
1 | Use cases | 8 |
2 | Domain model class diagram | 6 |
3 | Fully-developed use case description | 4 |
4 | Activity diagram | 4 |
5 | System Sequence Diagram (SSD) | 4 |
6 | State Machine Diagram (SMD) | 4 |
TOTAL MARKS | 30 |
The case study: Everything Catering Services System
Nowadays different events and activities, as conferences and weddings, are continuously being held. During these events, a professionally catered menu is needed, people have specific preferences regarding food and drink.
Everything Catering is a company that connect customers who need a caterer for their event to businesses that provide catering services. Everything Catering is similar to other services such as: https://www.oneflare.com.au/catering. Basically, customers provide their location and requirements, and are then provided with a shortlist of potential caterers who may meet customers’ needs.
Previously Everything Catering did most of its operations manually. Due to the growth of its business, Everything Catering decides to develop a new system, named Everything Catering Services System (ECSS), to automate its business processes.
ECSS contains two sides: the customers and the caterers. Caterers need to register on ECSS by providing their business name, description, types of services they provide (selected from a list), their location (city and postcode), link to their own website, and contact email. Caterers can become “verified” caterers by providing their ABN, business name, logo, and proof of current Public Liability or Professional Indemnity insurance. Caterers can also add “On-Time Guarantee” on their profiles, which means that they guarantee to provide the service on time. Otherwise, caterers will reimburse the customer $80 if they are more than half an hour after the scheduled time. Caterers can also present reviews from previous satisfied customers, and their average rating on their profiles.
Caterers need to purchase “credit” to respond to job requests from customers. While payment is done via PayPal, ECSS needs to record these transactions. Caterers can use credits to prepare quotes for customers, and every quote costs the same number of credits. Credits expire after four months. ECSS will notify the caterers if they need to purchase more to be able to quote. ECSS also notifies the caterer if they have run out of credit.
Customers do not need credits to use ECSS. When customers need to find caterers for specific events, they fill in an online form. Specifically, they need to provide type of event (buffet, dinner party, food truck, cocktail party, etc), broad type of cuisine (Australian, French, Chinese, Mexican, Indian, etc), number of people to be catered for, budget per person, service required (delivery only, wait staff, bar staff, etc), date of event, and any further instructions. They also need to provide an email address to be contacted with. Customers can also use the email to access their account and view the status of their job requests. The account is created when they submit their first job request.
After customers submit their job requests, ECSS matches the requests with caterers who provided related services, and provides the three caterers that best match the customer’s requirements. These caterers are then notified via email that there is an open request for quotation.
The caterers selected by ECSS can then provide a detailed quote to the customer. The quote includes the estimated cost, a flag indicating whether further information is required for a complete quote, and any comments. The quote is submitted to ECSS and customers will receive an email notification that a quote has been submitted, and can then view the quote via ECSS. After that, the customer and the caterer may further discuss the job privately outside ECSS. Customers can also browse caterers’ profiles and view related information, such as reviews, to make the final decisions.
Once customers make the final decision and select specific caterers, they can go to ECSS and click the “hired” option for quotes selected. Then other caterers who also submitted quotes are automatically notified that their quote was unsuccessful. Customers can also click “unsuccessful” for all quotes if none of these quotes suite their requests. If no quotes are received within 48 hours of posting the job request, the customer is notified, and the request is closed. A customer may decide to cancel the job request any time before making the final decisions.
After the catering job is completed, the customer can log in their account and leave their rating (from 1 to 5 star) and related reviews for the job. Only customers who make the booking can submit reviews for their booked services. Then rating and reviews will be added to caterers’ profiles and become available to other customers.
ECSS need to generate various summary reports each month. These include the percentage of quotes that were successful in obtaining a booking for a catering job; and the average satisfaction rating of completed catering jobs. The revenue to ECSS in terms of payments for credit is also reported, broken down for each capital city.
TO DO:
Answer questions below. Note the following points:
- You may need to make assumptions where information in the case is incomplete: state any assumptions clearly. You can also ask questions on the discussion board.
- Your diagrams should be drawn using Visio (or suitable alternative that creates UML diagrams). Use the appropriate template for each diagram type. Make sure your diagrams are clear and readable.
- Your diagrams must follow correct UML notation and naming conventions, and each diagram should include a title and legend.
- Your models, diagrams and discussions should be consistent with one another throughout your analysis and design.
- Ensure your work is clearly and professionally presented, proofread for spelling and grammar, with a title page and table of contents. Start each main question on a new page.
Q1. Develop a list of use cases for the ECSS (please do not include multiple tables). Present your list in a table that includes the participating actors, use case name and a brief use case description. For those identified via Event Decomposition technique, you need to include the event and type of event. (Note that some use cases are already identified below. Include these in your lists.) (8 points)
Hint: You to use CRUD to identify at least two use cases.
Q2. Create a domain model class diagram for the ECSS, including all classes, attributes, associations, and multiplicity. Show association classes and generalization hierarchies where appropriate. (6 points)
Q3. Create a fully-developed use case description for the use case Find caterer. Follow the template provided at the end of this handout. (4 points)
Q4. Draw an activity diagram to represent the flow of activities for the use case Generate credit payments report. (4 points)
Q5. Draw a system sequence diagram for the use case Provide feedback. (4 points)
Q6. Draw a state machine diagram to show the possible states and transitions for a Catering Job object. Label each state with the state name. Label each transition with the appropriate transition name, guard condition (if appropriate) and action expression (if appropriate). (4 points)
Marking Rubric
Criteria | HD | D | C | P | F |
6.4-8 | 5.6-6.3 | 4.8-5.5 | 4-4.7 | 0-3.9 | |
Q1 Use case (COL2.1, 2.3) (8 points) | Almost all use cases are identified.
|
Most use cases are identified. | A reasonable number of use cases is identified.
|
Some use cases are identified. | Only a few use cases are identified. |
4.8-6 | 4.2-4.7 | 3.6-4.1 | 3-3.5 | 0-2.9 | |
Q2 Domain model class diagram (COL2.2, 2.3) (6 points) | The diagram has few errors, and is fully consistent with the case. | The diagram has few errors, and is mostly consistent with the case.
|
The diagram has a few errors, and represents the case reasonably. | The diagram has some errors, and have some inconsistencies. | The diagram has many errors, and has a lot of inconsistencies. |
3.2-4 | 2.8-3.1 | 2.4-2.7 | 2-2.3 | 0-1.9 | |
Q3 Fully-developed use case description (COL2.2, 2.3) (4 points) | The answers contain all necessary details of the use cases, and are fully consistent with the case. | The answers contain most necessary details of the use cases, and are mostly consistent with the case.
|
The answers contain reasonable details of the use cases, and represents the case reasonably. | The answers contain some details of the use cases, and have some inconsistencies. | The answers contain few details of the use cases, and have a lot of inconsistencies. |
Q4 Activity diagram (COL2.2, 2.3) (4 points) | The diagram has few errors, and is fully consistent with the case.
|
The diagram has few errors, and is mostly consistent with the case. | The diagram has a few errors, and represents the case reasonably. | The diagram has some errors, and have some inconsistencies. | The diagram has many errors, and has a lot of inconsistencies. |
Q5 System Sequence Diagram (COL2.2, 2.3) (4 points) | The diagram has few errors, and is fully consistent with the case.
|
The diagram has few errors, and is mostly consistent with the case. | The diagram has a few errors, and represents the case reasonably. | The diagram has some errors, and have some inconsistencies. | The diagram has many errors, and has a lot of inconsistencies. |
Q6 State Machine Diagram (COL2.2, 2.3) (4 points) | The diagram has few errors, and is fully consistent with the case.
|
The diagram has few errors, and is mostly consistent with the case. | The diagram has a few errors, and represents the case reasonably. | The diagram has some errors, and have some inconsistencies. | The diagram has many errors, and has a lot of inconsistencies. |
Use Case Name: | ||
Scenario: | ||
Triggering Event: | ||
Brief Description: | ||
Actors: | ||
Stakeholders: | ||
Preconditions: | ||
Postconditions: | ||
Flow of Activities: | Actor | System |
|
||
Exception Conditions: |
|