ASSIGNMENT ONE ~ CPT230 SP3 2014
Due Date: 11:59pm, Sunday 28th September (week 4)
This assignment focuses on the concepts of lectures 2-4. It is designed as a learning experience in itself, and will be more challenging than the course content. You are advised to work on this assignment weekly.
Assessment Value
15% of your final mark will come from this assignment. As your assignments combine to form a hurdle, failing to submit this assignment will impede your goal of passing this subject.
Specification Updates
Every endeavour has been made to ensure clear communication in this specification. However, just like industry scenarios, it is reasonable to expect some minor revisions over time.
Help and Hints
• A discussion board forum is dedicated to Assignment One for queries and discussions. You are free to share URLs and offer suggestions, but please do not paste your answers.
• Do read the prior year’s solution. This will give you an idea of quality, format and detail required.
• Last minute work is not encouraged and all forum queries should be posted before Friday 26th September, 5pm. All email queries should be emailed by Wednesday 24th September, 5pm to facilitate response time.
REMEMBER: The purpose of this task is assessment, not to sell your work to a client ? You are not expected to return complex, industry level responses. Be wary of getting caught in low level detail.
Trouble Getting Started
If you find yourself overwhelmed / going around in circles, the following approach may help.
- review the relevant lecture material
- start with the question you are most comfortable with
- quickly ‘brainstorm’ an answer to the question, as if you were only given 10 minutes to answer
- review your answer and make adjustments, be they sweeping or subtle
- be prepared to adjust / refine your answer after completing the other questions
Common mistakes in this subject include
- ‘analysis paralysis’ – overanalysing the question to the extent you can’t get started - over detailing the responses – don’t try to contain every piece of data in every diagram - incorporating implementation. Your models should be platform independent.
How to Submit
Submit using Weblearn. You can submit multiple times, but each submission overwrites your previous one, with only the final submission being retained. Email your submission only if Weblearn is not functioning.
What to Submit
Your submission should be one single document, in a pdf format, non-zipped – no other formats will be accepted. Use the web to locate and download a free pdf writer if required.
Hand drawn models are not recommended but will be acceptable in Assignment One only – they will not be accepted in A2. Check handwriting is clear and scan quality is high, to ensure a readable submission.
You will need to copy/paste some responses from modelling software or scans into your main document, each with an appropriate heading. Ask for help as needed.
Difficulty combining graphics with a main document is not a valid reason for lateness. Ensure you are capable of combining your files well before the due date, and ask for help on the forums if needed.
Late policy
Late assignments are penalised 10% (1.5 marks) per day. After 5 days, the penalty will be 100%. Do consider submitting incomplete rather than late – it often results in a higher net mark.
OUA CS Extension policy
The instructor is completely uninvolved in the extension process, regardless of circumstances.
Please do not email me any requests for an extension !
• Extensions will only be granted for extenuating circumstances (personal/ workloads are not accepted reasons).
• Extension requests take time to process and should be initiated ASAP. Requests must occur before the due date.
• Extension requests are likely to require the submission of original supporting documents by mail.
Consult the document “CPT230 Overview SP3 2014” for more information about the extension process.
All requests need to be sent to ouacsit@rmit.edu.au
RMIT Short courses– Stakeholder Interviews
Scenario: RMIT requires some domain level UML models for their short course enrolment system.
Des the Course Designer
• I’m responsible for adding course definitions. A course may be offered many times. We capture aspects of the course definition (name, description, and course code) as well as details that are relevant to each particular course offering (start date, end date, cost, status, and capacity).
Caz the Course Coordinator
• I’m responsible for scheduling offerings of our courses. I specify the dates, capacity and cost, and I always assign teacher (name, phone, email) to the course offering as it’s scheduled. I may also assign a venue at this time, but sometimes this is done later.
• When the offering is 25% booked, the course offering is confirmed, and its teacher notified.
• When an offering is fully booked, it is closed. However, a cancelled booking may enable a course offering to re-open for bookings, if the cancellation is within 2 days of the start date.
Val the Venue Officer
• Each course offering is allocated a venue and I am responsible for adding new venues to the system. Venues may be RMIT owned, in which case we capture the address, the room ID and the owning department. For hired venues, we record the address and the hire cost. Venues can be reused.
Alex from Accounts
• When a customer pays an invoice, I mark it as paid in the system.
• I’ll need to generate two types of monthly invoice reports – unpaid invoices and invoices billed.
• We’ve decide that an invoice should be generated at the time of each enrolment. Each invoice shows the customer name, an invoice number, the course name, the course offering start date and the course fee. We’ll need to keep track of whether or not the invoice has been paid or not.
Ernie at Enrolments
• Customers enrol in our course offerings via our internet site, or they can have the Administrator do it for them over the phone. Customers can enrol in different offerings of the same course if they like, although obviously no more than once in each offering.
• Enrolments can be cancelled via customers or the Administrator.
• No student results are recorded for these short courses.
• To enrol in an offering, the user selects the desired course definition. The system displays that course’s open offerings, and the user selects one. The system asks for an email and customer ID.
- If the user has a customer ID (from a prior enrolment), the user enters it along with the associated email address. The system validates the email and ID combination and displays the associated customer information (customers name, address, email, and customer ID).
If the system can’t locate the email and ID combination, it asks the user to re-enter them.
- Users without a customer ID will select to create a new account, and enter the customer name, address, and email. The system generates a customer ID for this data and stores it.
• The system checks the customer has no overdue invoices – the enrolment can’t proceed if they do.
• The system asks for enrolment confirmation and when received, creates the customer’s enrolment
- If the offering is now full, then the system changes the status of the offering to “closed”
- If the offering has not yet been marked as confirmed, and is now equal to or over 25% full, then the offering status is changed to confirmed and the teacher is notified.
• The system emails the enrolment confirmation to the customer.
• We have decided that the system should also generate an invoice at enrolment. Talk to Alex the Administrator for information about what that involves.
Use the transcripts to respond to the questions following. Remember you are being assessed on your UML application skills, not your business or strategy insights. Ignore unmentioned functionality.
Part 1. Use Case Diagram
Develop ONE UML use case diagram
Draw ONE use case diagram to capture all functionality mentioned in the staff interviews. Include only activities mentioned by the staff – do not include additional functionality however obvious it may appear (no scope creep!).
Your diagram MUST demonstrate the use of: Primary Actors
Includes & Extends
Generalisation – both actor and use case Appropriate naming conventions
Appropriate relationships
Your diagram MUST NOT
Use extension points (we’re keeping it simple – ask if you need help turning them off in VP)
Use notation not covered by the CPT230 2014 SP3 lecture notes Show secondary actors
Include additional functionality not covered in the interviews, regardless of how obvious it may feel Exceed one page
Note, you must incorporate a ‘Create Enrolment’ use case (or similarly named) as this will be used in Part 2.
4 marks.
Part 2. Use Case Textual Description
Write a use case textual description of the ‘Create Enrolment’ use case
Develop a description of this use case using the “Template – Use Case textual description” as per Appendix A. Be sure to ask for help in the forums if you are not sure of the purpose or use of any field.
Use the relevant portion of the interview with Ernie to logically document the flow of events.
Your response MUST:
Use of the template in Appendix A
Display an understanding of the fields in the textual description
Provide sufficient detail in the Basic Course of Events and Alt Paths Be consistent with the transcripts (don’t create or deduct information).
Stick to the scope of this use case, and refer to other use cases as needed (rather than overlap)
Be consistent with information you have modelled in your use case diagram
4 marks.
Part 3. Class Diagram
Develop a domain level UML class diagram based on the interviews
Consider classes carefully to maintain relationships and eliminate data duplication.
Your diagram MUST demonstrate: Classes with appropriate attributes
Associations, all with appropriate multiplicity An example of an association class
Generalisation and abstract class
A controlling class named ‘Application’ with at least some of the operations pertinent to this class (operations in other classes are not required)
Your diagram MUST NOT
Use notation not covered by the CPT230 2014 SP3 lecture notes
Include information not required or beyond the scenario
Show getter or setter methods
Be inappropriate to the problem domain – e.g. arrays, foreign keys, etc. Exceed one page
Your diagram MAY
Show operations in other classes (no extra marks, not required for A1)
Show attribute types (no extra marks, not required for A1)
Resist the urge to create sophisticated and complex systems – it will quickly turn into a large task, and you won’t receive any extra marks for it. If in doubt keep it simple.
4 marks
Part 4. Object Diagram
Develop ONE UML object diagram from your class diagram
Develop an object diagram which fully captures the scenario below. Your diagram should demonstrate data integrity (no data repetition, single values per attribute).
Rory Williams (Cust ID 501) had enrolled in the April 2011 offering of “Intro to Space & Time” (taught by Steven Moffat), but never paid the invoice. Amy Pond (cust ID 705) had already taken this same unit in April 2010 which at that time was taught by Mark Gattis (and unlike Rory, she did pay the invoice). Both offerings were held at 100 Swan Street (hired by RMIT for $500). In 2012 Amy enrolled in 2 offerings (April and October) of Advanced Wall Repairs, both of which were held in the Art Department – room 3_14 in April (also taught by Mark Gattis) and room 3_18 in October.
Your diagram MUST:
Be consistent with your class diagram – this includes naming, attributes, associations & multiplicity
Demonstrate appropriate use of instances, attributes, and links Model all of the scenario in ONE diagram
Your diagram MUST NOT
Use notation not covered by the CPT230 2014 SP1 lecture notes
Include information not required or beyond the scenario
Contain duplication of data or instances
Break the scenario down into separate object diagrams
Exceed one page
3 marks
APPENDIX A : TEMPLATE FOR USE CASE TEXTUAL DESCRIPTION
A sample UC text description is included in the prior SP sample solution. Please refer to it for examples of each field.
Name This must be identical to the use case in the use case diagram.
Version Identifier to distinguish between versions of one use case text description.
Summary A short summary (without step by step detail) of the use case process or purpose.
Actors List any primary actor/s who initialises the use case. These should be job titles not individual’s names. Do ensure consistency with the UC diagram.
Preconditions Conditions that must be true before the use case can even start. Write as a predicate, a statement that is either true or false.
Don’t bother testing for these in the basic course of events, because if they’re false the use case will never even start and won’t get to the basic course of events.
Triggers The event that causes the use case to activate. It may be a user selecting something, it may be another use case.
Main Flow of Events
A well detailed and clearly numbered sequence of steps taken to achieve the goal. Steps should include actor and system actions.
Steps should describe the flow of events, with a good level of detail. Steps may also refer to where other use cases take over (where they have been included or extend this UC).
Alternative Paths There may be points in the main flow where an alternative flow or action is needed. These may be other ways to achieve the same goal, or where failure points are considered.
Alternative paths should be clearly numbered so as to indicate at what point in the flow the alternative path occurs, why it occurs, and what actions are then taken.
Post Conditions The state of the system after the use case has executed. For example if the customer successfully withdraws cash their bank balance should be lower by the withdrawn amount.
There may be multiple post conditions if multiple outcomes are possible. Indicate those that are mutually exclusive with an ‘OR’.
Post conditions may need to include alternative paths where failure paths are present.
Business Rules Any condition that should be observed/ maintained that is specified by the business or an external entity, and relates specifically to this use case. E.g. “Enrol Child” may only enrol children where they are immunised or over a certain age.
Notes Extra information that you need to record. It’s a good place to capture questions or ‘park’ issues you have observed that are bothering you. Don’t go overboard here, and do ensure it relates to this particular case.