UFCFB6-30-2 SB – Object-Oriented Systems Development

Page 1 of 16

Computer Science and Creative Technologies

Coursework Specification

Module Details
Module Code UFCFB6-30-2
Module Title Object-Oriented Systems Development
Module Leader James Lear
Module Tutors James Lear
Year 2022-2023
Main sit or resit Main Sit
Component/Element Number A - Main sit
Total number of assessments for (1) Part-I: The first covers the analysis and design of a software
this module system.
(2) Part-II: The second covers the coding and testing of the
design created in the first assignment.
Weighting 100%
Element Description Group project: This assignment is to be completed in groups of
up to three students.

Dates
Date issued to students 24th October 2022
Date to be returned to students Within 20 working days of the final demonstration session.
Submission Deadline (1) Part-I: December 8, 2022 14:00hrs
Demo session in the teaching week starting 9th January 2023
(during the scheduled practical session).
(2) Part-II: March 23, 2023 14:00hrs
Demo sessions in the teaching weeks starting 17th April 2023
(during the scheduled practical session) and 24th April 2023
(during the scheduled lab session).
This assessment is NOT eligible for 5 calendar day late
submission window
Submission Place Blackboard
Submission Time 14:00
Submission Notes (1) Part-I: Please submit a PDF document containing the UML
(Please read carefully) Use Case diagram, Class diagram, and Sequence Diagrams.
Please ensure the diagrams are readable.
(2) Part-II: Please submit a portfolio as a zip file containing
your programming Java code, a PDF report on Agile practices,
Test cases used in your program in the form of a table, suitable
program running screenshots capturing success/failure
scenarios, and the individual written report.
Please note that all members of a group must be present during
the demonstration sessions, and all members must upload both
part I and part II individually.
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 2 of 16

Feedback
Feedback provision will be On the spot verbal feedback during the demo session and as
appropriate written feedback uploaded to Blackboard.
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 3 of 16

Contents

Module Details ............................................................................................................................................................... 1

Dates............................................................................................................................................................................... 1
Feedback ........................................................................................................................................................................ 2
Contents ............................................................................................................................................................................. 3
Section 1: Overview of Assessment ........................................................................................................................... 4
Section 2: Task Specification ..................................................................................................................................... 5
Section 3: Deliverables ............................................................................................................................................. 11
Section 4: Mark Distribution and Marking Criteria.................................................................................................. 11
Section 5: Feedback mechanisms ............................................................................................................................. 11
Appendix A. Marking Criteria......................................................................................................................................... 12
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 4 of 16

Section 1: Overview of Assessment

This assignment assesses the following module learning outcomes:

• Describe the theory and concepts of the object-oriented paradigm.

• Explain the essential characteristics of the object-oriented software development life cycle including
testing.
• Apply object-oriented analysis and design techniques for a problem domain scoped at level 2
complexity.
• Understand and use a Unified Modelling Language (UML) modelling tool and Java- based
Interactive Development Environment (IDE) to develop object-oriented software implementations
appropriate to level 2 complexity
• At an introductory level, apply object-oriented software patterns and architectures for increasingly
large scale distributed systems.
• Use an appropriate development environment to design and implement persistence within a
distributed architecture at an introductory level.
• Design and implement concurrent systems and distributed systems.
• Design and implement Graphical User Interface (GUIs).
• Develop the necessary professional skills considering Agile approach while working in a group.

The assignment is worth 100% of the overall mark for the module.

The assessment is designed to allow you to use your learning and play to your strengths. You can always seek
advice and/or interim verbal feedback from your tutors during practical sessions.

Broadly speaking, the assignment requires you to design and implement a moderately realistic Object-
Oriented System. You will produce detailed Object models and designs from system requirements; using the
modelling concepts provided by UML. You will then map the designs into Java code and perform thorough
testing.

The assignment is described in more detail in section 2.

This is a GROUP assignment.

Working on this assignment will help you to understand more clearly the concepts, problems, and
techniques of Object-Oriented Systems, and how these can be used to design and implement a reasonably
large size software systems while working in a team (to a professional standard).
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 5 of 16

Section 2: Task Specification

All the tasks are based on the following scenario. Please read carefully all information contained
within the following passages of text.

Luxury Camp Site System

This scenario concerns the development of a luxury camp site accommodation system. Initially an overview
of the business is provided, followed by a detailed system specification.

Overview
With the rise and popularity of staycations the owner of a camp site has expanded their enterprise to include
various types of luxury camping accommodation. The camp site is located on over five acres of land, zoned
into four distinct areas: hilltop, wild meadow, woodland and lakeview. A map of the camp site is provided in
Figure 1 for illustrative purposes.

Figure 1: Camp site map illustrating distinct areas and accommodation

The camp site has four different types of luxury accommodation: yurts, cabins, geodesic domes and
shepherd huts. Each individual area is associated with an individual accommodation type. The yurts are
positioned in the woodland, the hilltop accommodates the shepherd huts, the traditional log cabins surround
the lake edge, and the modern geodesic domes are located in the woodland. The accommodation information
is detailed in Table 1 below:

Area Name Accommodation Number in Accommodates Price Per Night

Type Zone
Hilltop Shepherd Hut 3 3 £140
Wild Meadow Yurt 4 2 £110
Woodland Geodesic Dome 4 2 £120
Lakeview Cabin 3 4 £160

Table 1: Zones and associated accommodation

UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 6 of 16

When a guest checks in they provide their name, mobile phone number (in case they need to be contacted on
site) and whether they require a breakfast every day. The owner of the camp site cooks all breakfasts and
delivers them early in the morning.

When a guest checks out of their residence the accommodation is refreshed and cleaned in preparation for
the next guest. The owner hires dedicated cleaning staff for this purpose.

The owner of the camp site currently uses Airbnb to take initial bookings for their luxury accommodation,
however, they find they must record additional information to assist in the daily running of their business.
The owner now requires an on-site software system to replace their traditional “pen and paper” approach.
The system specification follows:

System Specification

The system is located “on-site” and both the owner of the camp site and the cleaning staff will use the
system on a daily basis to assist in the running and operation of the business.

Although the owner would very much like you to design the Graphical User Interface (GUI), they envisage
the core functionality will appear similar to the example in Figure 2.

Figure 2: Example Graphical User Interface (GUI)

The system has the following GUI needs. Please be creative in your GUI design by using labels, text fields,
check boxes, combo boxes, buttons, images and tables:

1. Accommodation Details by Area

The owner and cleaning staff require a mechanism to determine “at a glance” the state of the
accommodation in each area. Therefore, the system must include the functionality to display an overview or
summary of the four areas and their associated accommodation. Figure 2 uses a GUI table to display this
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 7 of 16

summarization information, partitioned by the selected area. Be creative and use different GUI controls as
you see appropriate.

Table 2 below describes the GUI column headings and their valid values:

Attribute Values Description

The Unique Accommodation 1..* This number uniquely identifies a single
Number accommodation within a zone.
The Accommodation Type Shepherd Hut, The type of the accommodation. An
Yurt, individual area has a specific type of
Geodesic Dome, accommodation.
Cabin.
Occupancy Occupied, Occupied if a guest is currently residing in
Unoccupied. the accommodation. Otherwise,
Unoccupied.
Availability Available, Determines whether the accommodation
Unavailable. is available for subsequent guest check in.
Accommodation is “Unavailable” if the
accommodation is either already occupied
or requires cleaning.
Status Clean, After guest check out the accommodation
Requires Cleaning. must automatically be set to “Requires
Cleaning”.
Accommodation cannot be used for guests
unless in a “Clean” state.

Number of Guests 0..* Total number of guests residing in the

accommodation.

Breakfast Yes, No. Indicates whether the guest specified a

breakfast during the check in process.

Table 2: Accommodation Information

2. Area Statistics

To assist in the preparation of breakfasts the owner requires a mechanism to calculate the number of
breakfasts each day.
Likewise, the cleaning staff require a method to show the number of residences that require cleaning each
day. Preferably the statistics should be partitioned or grouped by the area (see Figure 2).
3. Guest Check In

From the perspective of the owner, on guest arrival, the system must provide a check in facility. Firstly, the
owner selects the corresponding accommodation row in the GUI table. The following detailed
accommodation information is displayed for the residence (also see Figure 2).
• The unique accommodation number and the associated accommodation type (as described above).
• Accommodates – The number of guests the accommodation can sleep (detailed in Table 1).
• Price Per Night – The daily price of the accommodation (detailed in Table 1).

During check in the owner enters the guest information, detailed in Table 3, into the system. This creates a
guest booking in the system. The guests may then use the accommodation for the duration of their stay.
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 8 of 16

Attribute
The First and Last Name of
the Primary Guest
Telephone Number
Check In Date and Number
of Nights
Description
This is the guest who originally booked the accommodation.
The telephone number for guest contact during their stay.
The check in date and the number of nights stay requested.

Number of Guests
Breakfast Required
The total number of guests in the guest booking. This number must
not exceed the number of guests the accommodation can sleep. An
error message should be displayed if this occurs
Indicates whether the guest specified a breakfast during the check in
process.

Table 3: Guest Check In Information

A guest check in can only be performed if the accommodation is in the “Available” state. That is, the
accommodation is “Clean” and not in a “Requires Cleaning” state. If the accommodation requires cleaning
an error message must be displayed.

4. Guest Check Out

The owner requires the system to provide a facility to check out a guest from their accommodation on guest
departure (button in Figure 2). The status of the accommodation after check out must be automatically set to
“Requires Cleaning”.

5. Cleaning Status

The cleaning staff interact with the system daily to view the number of rooms that require cleaning and set
the individual residence to “Clean” when they have finished their duties (see below in Figure 3).

Figure 3: Change of Cleaning Status from “Requires Cleaning” to “Clean”

You are the leader of a team of three developers who have been asked to design and implement a system
which enables the Owner and the Cleaning Staff to manage the “day to day” running of the luxury camp site,
exhibiting the functionality described above.
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 9 of 16

More specifically there are the following tasks:

You are tasked with producing the following deliverables for the scenario given above.

Part-I (Weighting 40%)

Task 1: Use Case Diagram

Produce a UML Use Case Diagram to capture the functionality for the system to be built.

Task 2: Class Diagram

Produce a UML Class Diagram to meet all the requirements captured in the Use Case Diagram.
You are not required to represent the GUI classes on this diagram.

Task 3: Sequence Diagrams

Produce at least two UML Sequence Diagrams for the system.
Remember a Single Sequence diagram represents a single Use Case. You must choose two Use Cases
identified in step 1 and expand them into two Sequence Diagrams.

Part-II (Weighting 60%)

Task 4: Joint Report

Write a joint report (300-800 words) outlining the typical steps that you would follow to develop and
implement the system in relation to Agile development. You may consider the following steps:

- Team Communication: The essence of our project is effective communication among team
members either through face-to-face or online conversation …
- Continuous Team Iterations: The development phases of our project are more flexible as we
continuously iterate between design and implementation compared to a conventional development
methodology which it too rigid and strict …
- SOLID: Our main objective is to establish practices that develop software with consideration for
future maintenance and extension. We adopt the SOLID principles of software design to assist with
correct design choices.
- Work Plan (Not mandatory but recommended): Project backlog, SPRINT Cycle and details.

Task 5: Implementation
Develop the system using Java and JavaFX considering all the functionalities described above. You may
either “hand code” the JavaFX GUI or use Scene Builder to design and implement your interface.

You should be creative and come up with your own User Interface Design. The design in Figure 2 is merely
an example.
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 10 of 16

Task 6: Testing
Testing is typically a part of the program development – you should use a test strategy to test your system
thoroughly. You should create test cases for all Use Cases identified and create test cases to exercise any
validation you have implemented. Deliberately feed your system out of range or incorrect data to attempt to
make it fail.

Produce a table of test cases as illustrated in Table 4. For the “Actual Result” column you may optionally
provide or refer to a screenshot of your application. One example test case has been provided for you.

Test Case Purpose Expected Result Actual Result

Test Case 1: The check out process is
Check Out integral to the system.
Guest Check out removes the
guest booking from the
system.
The guest booking has As expected.
been removed and the Guest booking
associated GUI fields successfully removed.
cleared. The status of GUI fields cleared. The
the accommodation status has correctly
changes to “Requires changed to “Requires
Cleaning” and the Cleaning”.
availability remains at
“Unavailable” (until
the accommodation is
cleaned).

Table 4: Example Test Case Table

Task 7: Individual Contribution and Reflective Report (300 – 700 words)

Your report should include:

(a) the evidence of your work produced for the above activity with an outline
(b) reflection on your contribution to the work in relation to skills and knowledge acquired.
(c) provide a brief reflection on how persistence of data could be achieved technically to store the
accommodation information and changes to the system.
(d) reflect on the use of the design patterns used in your system
UFCFB6-30-2 SB – Object-Oriented Systems Development
Page 11 of 16

Section 3: Deliverables
You must use the Blackboard electronic submission system to submit your work. Each student will have to
upload complete package individually. Electronically submitted deliverables include:

For Part I: Each student needs to upload the following deliverable.

1. One PDF document that covers Task 1 to Task 3 (UML Designs).
For Part II: Each student needs to upload the following deliverables in one .zip file. The naming standard
of the zip file is WP1234567.zip where 1234567 is the student Id.
1. For task 4, a joint group report in PDF format.
2. For task 5, the following deliverables should be compressed in a .zip file.
a. A software system based on the specifications in section 2, with source code in ZIP file (using
e.g., 7Zip). This should contain all the files and folders for the full working system.
b. Please provide a text file with instructions on how to start and use your software system.
3. For task 6, evidence of testing e.g., test cases, unit tests and outputs. These can be included in a
separate PDF document.
4. For task 7, each student will write individual report in PDF format.

Instructions for submission

You must submit your work before the stated deadline by electronic submission through Blackboard.
• Multiple submissions can be made to the portal, but only the final one will be accepted.
• It is your responsibility to submit deliverables in a format stipulated above. Your marks may be
affected if your tutor cannot open or properly view your submission.
• Do not leave submission to the very last minute. Always allow time in case of technical issues. Also,
save your work frequently to avoid losing your work at the last minute.
• The date and time of your submission is taken from the Blackboard server and is recorded when your
submission is complete, not when you click Submit.
• It is essential that you check that you have submitted the correct file(s), and that each complete file
was received. Submission receipts are accessed from the Coursework tab.
• UWE academic regulations for late submissions will be applied. Please check module handbook.

Note: All submitted work will be checked for Plagiarism using SafeAssign or other suitable
software/approaches. Every student undertaking an assignment or other piece of assessed work is required
to take, and will be deemed to have taken, full responsibility for all the work submitted by the student. In
particular, this includes responsibility for any assessment offence (e.g., Plagiarism, collusion) committed.
Assessment offence such as plagiarism or collusion will result in 0 marks.

Section 4: Mark Distribution and Marking Criteria

Part I weighting is 40% and Part II weighting is 60%.
In common with all UWE standard undergraduate assignments, the pass mark for this assignment is 40%. The
detailed marking criteria for this assignment is detailed in Appendix-A.

Section 5: Feedback mechanisms

On the spot verbal feedback during the demo session and as appropriate written feedback uploaded to
Blackboard. Formative feedback provided in Part-I will be useful to complete Part-II of the assignment.
UFCFB6-30-2 SB – Object-Oriented Systems Development Page 12 of 16

Appendix A. Marking Criteria

Part-I (Weightage 40%)

0.0-2.9 3.0-3.9 4.0-4.9 5.0-5.9 6.0-6.9 7.0-8.4 8.5-10.0 Mark &
Advice for
Improvement
Use case Little or Partial diagram Partial diagram Almost complete Almost complete Complete diagram Complete diagram
diagram no provided but provided, actors diagram provided, diagram provided, provided, actors provided, actors
(10%) diagram actors and/or use- and/or use- actors and/or use- actors and/or use- and/or use- and/or use-
provided cases/relationships cases/relationships cases/relationships cases/relationships cases/relationships cases/relationships
or are only partially are correct are only partially are correct. are partially are correct
diagram is correct (overall (overall less than correct (overall (overall, less than correct (100% complete)
mostly less than 40% 50% complete). less than 60% 70% complete) (overall less than
wrong complete). complete). 85% complete)
(overall
less than
30%
complete).
Class Little or Partial diagram Partial diagram Almost complete Almost complete Complete diagram Complete diagram
diagram no provided but Class provided but Class diagram provided, diagram provided, provided, Class provided, Class
(10%) diagram naming naming Class naming Class naming naming naming
provided convention, Class convention, Class convention, Class convention, Class convention, Class convention, Class
or relationships, relationships, relationships, relationships, relationships, relationships,
diagram is Attributes/methods Attributes/methods Attributes/methods Attributes/methods Attributes/methods Attributes/methods
mostly of the classes and of the classes and of the classes and of the classes and of the classes and of the classes and
wrong their visibility and their visibility and their visibility and their visibility and their visibility and their visibility and
(overall type are only type are correct type are only type are correct type are partially type are correct
less than partially correct (overall, less than partially correct (overall less than correct (100% complete)
30% (overall, less than 50% complete). (overall less than 70% complete). (overall less than
complete). 40% complete). 60% complete). 85% complete)
Sequence Little or Partial diagram Partial diagram Almost complete Almost complete Complete diagram Complete diagram
diagram (at no provided but provided, Lifeline diagram provided diagram provided, provided but provided, Lifeline
least two diagram Lifeline Notation, Notation, but Lifeline Lifeline Notation, Lifeline Notation, Notation,
provided Activation Bars, Activation Bars, Notation, Activation Bars, Activation Bars, Activation Bars,
12
UFCFB6-30-2 SB – Object-Oriented Systems Development Page 13 of 16

diagrams) or and Message and Message Activation Bars, and Message and Message and Message
(10%) diagrams Arrows are only Arrows are correct and Message Arrows are Arrows are only Arrows are
are mostly partially correct (overall less than Arrows are only correct (overall partially correct correct (100%
wrong (overall less than 50% complete). partially correct less than 70% (overall less than complete).
(overall 40% complete). (overall less than complete). 85% complete).
less than 60% complete).
30%
complete).
Demo and Absent 0.0
Individual Inadequate (barely able to explain the analysis/design and/or work done) 0.0-3.0
Q&A Good (good explanation of analysis/design and/or work done) 3.1-6.0
(10%) Very Good (very good explanation of analysis/design and/or work done) 6.1-8.0
Excellent (excellent explanation of analysis/design and/or work done) 8.1-10.

13
UFCFB6-30-2 SB – Object-Oriented Systems Development Page 14 of 16

Part-II (Weightage 60%)

0.0-2.9 3.0-3.9 4.0-4.9 5.0-5.9 6.0-6.9 7.0-8.4 8.5-10.0 Mark &
Advice for
Improvement
Agile Little or no Partial Partial Almost complete Almost complete Complete Complete
development description description description description description description description
(10%) provided provided but provided, provided but provided, provided, provided,
(overall less texts/justification texts/justification texts/justification texts/justification texts/justification texts/justification
than 30% are not written are written are not written are written are written are written very
complete). reasonably reasonably reasonably roughly reasonably well and
accurately accurately accurately accurately accurately accurately
(overall less than (overall less than (overall less than (overall less than (overall less than (100%
40% complete). 50% complete). 60% complete). 70% complete). 85% complete). complete).
0.0-6.0 6.1-8.0 8.1-10.0 10.1-12.0 12.1-14.0 14.1-17.0 17.1-20.0 Mark &
Advice for
Improvement
Implementation Little or no Partial Partial Partial Almost complete Complete Complete
(20%) development development, development, development, development, development, development,
(overall less compiles and compiles and compiles and compiles and compiles and compiles and
than 30% runs, but GUI runs, GUI runs, but GUI runs, GUI runs, but GUI runs, GUI
complete). displays input displays input displays input displays input displays input displays input
and output and output and output and output and output and output
messages only messages only messages only messages only messages only messages
partially partially partially partially partially correctly. (100%
correctly (overall correctly (overall correctly (overall correctly (overall correctly. complete).
less than 40% less than 50% less than 60% less than 70% (overall less than
complete). complete). complete). complete). 85% complete).
0.0-2.9 3.0-3.9 4.0-4.9 5.0-5.9 6.0-6.9 7.0-18.4 8.5-10.0 Mark &
Advice for
Improvement

14
UFCFB6-30-2 SB – Object-Oriented Systems Development Page 15 of 16

Testing (10%) Little or no Partially tested, Partially tested, Partially tested, Almost tested, Almost tested, Completely
test cases (overall less than (overall less than (overall less than (overall less than (overall less than tested, (overall
(overall less 40% tested). 50% tested). 60% tested). 70% tested). 85% tested). less than 100%
than 30% tested).
tested).
Individual Q&A Absent 0.0
(10%) Inadequate (barely able to explain the analysis/design and/or work done) 0.0- 3.0
Good (good explanation of coding/testing and/or work done) 3.1- 6.0
Very Good (very good explanation of coding/testing and/or work done) 6.1- 8.0
Excellent (excellent explanation of coding/testing and/or work done) 8.1- 10.0
Individual No submission 0.0
report (10%) Inadequate (barely covers individual contribution evidence or reflection) 0.0-3.0
Good (reasonable examples of individual contribution evidence and reflection on learning) 3.1- 6.0
Very Good (good examples of individual contribution evidence and reflection on learning ) 6.1-8.0
Excellent (Excellent examples of individual contribution evidence, reflection on learning) 8.1-10.0

15
UFCFB6-30-2 SB – Object-Oriented Systems Development Page 16 of 16

This Page is Intentionally Left Blank

16