Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Object-Oriented Programming
Coursework
This coursework comprises 100% of the overall module assessment.
This is a pair exercise, and your attention is drawn to the guidelines on collaboration and plagiarism in the University
Handbook (exeter.ac.uk/students/administration/complaintsandappeals/academicmisconduct/).
This assessment covers the use and implementation of a range of object-oriented concepts using the Java programming
language that you are covering in ECM1410. The assignment is summative. Please ensure you read the entire document
before you begin the assessment.
This coursework will help you enhance your understanding of object-oriented programming. Remember to follow
the established deadline and submission guidelines in the module’s ELE page.
1 Development paradigm
This summative coursework for ECM1410 is a pair submission — with details as circulated previously in the document
“ECM1410 Object-Oriented Programming Development paradigm in summative coursework”. To reiterate the key
points from this earlier document:
? The expectation is that the submission will be weighted 50:50 between pair members. In the unusual circumstance
that members of the pair do not contribute 50:50, you have the opportunity to indicate a different ratio you have
both agreed on the cover page of the submission, up to a maximum divergence of 60:40.
? Pair programming is categorically not two developers working separately on two different machines. Side-by-side
(or virtual, sharing screen) communication developing on a single machine is a key aspect of the approach.
? The module leader reserves the right to split pairs where one student is not engaging with the
coursework. The coordinator also reserves the right to assign non-contributing students a mark
of 0. In the rare situation that you are paired with a student who is not contributing (e.g. not replying to emails
and/or not meeting up for pair-programming sessions) you must inform Dr. Pacheco of the situation within
one week of release of the coursework specification to facilitate the aforementioned splitting of pairs if
necessary. Both parties of a split pair will be assigned an individual variant of the coursework (however, if there
are multiple pairs in this situation it may be possible to reform pairs consisting of participating students, and of
non-participating students). It is not permitted for a student working on the individual variant of the coursework
to collaborate with any other student.
Given the above process and timelines, please ensure that you arrange to meet in person or virtually and start
the work as soon as the coursework specification is released to reassure yourself that you are partnered with a
student who wants to actively contribute to the coursework. It is an expectation that pairs have at a minimum
two pair-programming sessions in the first week of release of the coursework.
? It is not permitted for students working on the pair programming assignment to collaborate on the assignment
with any other student apart from their named partner. Those doing so will be subject to academic misconduct
regulations and penalties. Please refer to the undergraduate handbook for details on collusion, plagiarism, etc
(see web link on coversheet of this document).
2 Assignment - Coding (100 marks)
This assignment is based around the development of a back-end Java package. The system’s required functionality has
already been determined, and an interface is provided such that your back-end can communicate with the front-end
being developed by the module leader. The module leader should be able to simply compile in the jar file of the
package you develop, with the rest of their system, to result in a fully functioning solution.
2.1 The problem
Cycling is a very popular sport and it has been shown to cause positive effects beyond the sport’s boundaries. Cities
engaged with cycling races usually tend to have more commuters. The increasingly usage of bicycles in daily activities
has also been related to health improvements.
To foster future athletes and a healthier community, a local cycling club has decided to create a cycling staged
race. The idea is to have the same structure and rules as the famous cycling Grand Tours. Therefore, the club needs
a system to support this and future events.
1
The system can be split in three parts:
1. Rider’s Management – the system must be able to manage riders and teams.
2. Race Design – the system must have functionalities to allow the creation of stage races. That is, one must be
able to manage stages within races and configure them. Among the configurations, for instance, one should be
able to define intermediate sprints and mountain summits.
3. Race Results – the system must have functionalities to handle the realisation of races following the specified
design. In other words, the system must allow recording the results of riders on races.
A staged race is a type of cycling race that is distributed over multiple stages raced in different days. There
are also multiple competitions co-occurring in a staged race. For simplicity, the club decided to have only three
competitions within races. They are listed below, sorted by importance:
1. General Classification (GC) – this is the most important prize of the race. The winner is the rider who
finishes all stages in the least amount of time in total. Note, this rider may never win a single stage, but still be
the fastest when one aggregates the overall times.
2. Points (Sprinter’s) Classification – in this classification the actual time is not considered, but the ranks of
riders. Finishing a stage in the top ranks give riders a certain amount of points depending on the type of the
stage. In addition to the finish line points, stages can have intermediate sprints. These sprints act as intermediate
finish lines and riders get points according to their position crossing them. The winner in the points classification
is the rider who sums the most points after all stages in a race. See points distribution in Figure 1.
3. Mountain Classification – is a special competition which prizes the best climbers in the race. Similar to the
sprinter’s classification, mountain points are given to riders who first reach the summit of mountains throughout
stages. As expected, tougher climbs worth more points. At the end of the race, the King/Queen of the Mountains
(KOM/QOM) is the rider who collects the most of the mountain points. See mountain points distribution in
Figure 2.
Stages represent the diverse courses on which cycling races unfold, each offering unique challenges and opportunities for riders. These stages are classified into four distinct categories: flat, hilly finish/medium mountain, high
mountain, and time-trial, each requiring different strategies and skillsets from the cyclists. Within these stages, there
are checkpoints, such as intermediate sprints and categorized climbs, which contribute points towards the sprinter’s
and mountains classifications, respectively (see Figure 3 for an example). Notably, time-trial stages stand apart as
they lack a mass start, with riders competing individually against the clock, each starting at offset times. Moreover,
unlike other stages, time-trials do not feature checkpoint points. For a visual representation of the point distribution
for the sprinter’s classification, refer to Figure 1, while Figure 2 outlines the points awarded for mountain climbs based
on their category.
The club wants the back-end of the new cycling portal to be compatible with the front-end which is being developed
by another group, as such they have already designed a Java interface for the new system, which their front-end
application will use. You are to develop a class that implements this interface, and also develop the necessary additional
supporting classes in the Java package called cycling. The operational correctness of the back-end system will be
tested through this provided interface on submission.
Your task is to design and write the additional package members to complete the cycling package. You will need
to design and write a class that implements the CyclingPortal interface. Individuals not paired should implement
a simplified version defined by the MiniCyclingPortal interface. Both interfaces are available on the ECM1410
Assignment ELE page, as well as at the end of this document.
The implementor class must be a public class called CyclingPortalImpl. If it is not, then the front-end system
will be unable to compile with your back-end solution, and the operational component of your mark will be 0. You
will need to also write any other package members you deem appropriate to support this class and its functionality.
All classes developed must reside in the cycling package. Alongside the interfaces, I have provided in the package a
set of exception classes which each interface requires.
2
Figure 1: Sprint points distribution according to rider’s rank for different types of stage and for the intermediate sprint
checkpoint. Extracted from http://en.wikipedia.org/wiki/Points classification in the Tour de France (accessed 11 February 2022).
Figure 2: Mountain points distribution according to rider’s rank for different types of mountain checkpoints. Extracted
from en.wikipedia.org/wiki/Mountains classification in the Tour de France (accessed 11 February 2022).
Figure 3: Stage 14 of the 2023 Tour de France. It has five mountain checkpoints and one intermediate sprint. Extracted
from https://www.cyclingstage.com/tour-de-france-2023-route/ (accessed 13 February 2024).
3
2.2 Development considerations
The following points should be noted:
? Your source code should include appropriate comments and assertions.
? When a rider is removed from the platform, all of its results should be also removed. Race results must be
updated.
You will not need to submit an executable application (i.e. you do not need to submit a class with a public
static void main method within the cycling package). This notwithstanding, it is strongly advised that you do
write an application to test that your package conforms to the requirements prior to submission. We have provided a
skeleton test class (CyclingPortalTestApp.java) in the released package.
Apart from the classes you develop yourself, or that you have been given as part of the coursework, you must only
use those available in the Java built-in packages (java.*). The use of any other packages will result in a penalty of
10 marks.
You should consult the MiniCyclingPortal and the CyclingPortal interfaces for a more detailed description of
expected behaviour of a class which implements the interface which is appopriate for you or your pair (provided in the
Javadoc).
3 Submission
The coursework requires electronic submission to the ELE platform. Upload your file (see details below) by midday
on the due date specified on the cover page of this document. The paths mentioned below (folder structure) should
be all lowercase, but the files within the folders should follow the Java naming convention.
Your working environment should have at least five folders:
? TestSystem – (optional) containing your test files.
? src – to keep the source code (*.java files), including those provided as part of the coursework.
? bin – to keep the bytecode (*.class files).
? doc – to save the Javadoc from your code.
? res – to add any other resource you need in addition to the class diagram and cover page.
1. Class Diagram – include a PDF file with a class diagram representing the class cycling.CyclingPortalImpl
and all auxiliary classes you created. There is no need to include interfaces or exception classes. For each
class, include all attributes and public methods. You can use any software to create your diagram, for
instance, word, powerpoint, drawio, etc. as long as you export it to a PDF.
2. Cover Page – a cover page which details both of the student numbers of the corresponding pair. If,
unusually, you have agreed a split which is not 50:50, this page should also detail how you would like the
final mark to be allocated to the pair, based upon your agreed input. This cannot differ by more than
60:40. As the submission is anonymous, again please use your student numbers. This page should have
a development log, which includes date, time and duration of pair programming sessions, including which
role(s) each developer took in these sessions, with each log entry identified by both members using your
student numbers to ensure anonymous marking. If you are working solo, you are still required to submit
the cover page with your student number, but you don’t need to add the development log. This file should
be named cover_sheet.pdf. I have added an example of a cover page in the ELE page1
.
Failure to submit any coversheet detailing both members student numbers and development log will incur
a penalty of 5 marks.
1
Inside the released zip file, go to res/cover sheet example.pdf. This example highlights what information the cover page needs to
include. You don’t need to follow this exact format.
4
? build – to save the jar file that will be submitted. You need to generate a jar Package with a copy of your
full finished package, named cycling.jar. The jar file must include: (i) the bytecode (.class), (ii) source
files (.java) of your submitted package, including the CyclingPortal interface and all the exception classes
provided to you as part of the coursework, (iii) the Javadoc for the package, and (iv) the cover page and the
class diagram. I.e. it should be a complete self-contained package, that my test program can interact with, via
your cycling.CyclingPortalImpl class.