讲解 ECM1410 Object-Oriented Programming Development paradigm in summative coursework讲解 Java编程

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 arepaired 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 maybe 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).

Assignment - Coding (100 marks)

2

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 intermediatesprints 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 topranks give riders a certain amount of points depending on the type of the stage. In addition to the finish line points, stages can have intermediatesprints. 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 oppor- tunities 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 intermediatesprints 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.

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 (ac- cessed 11 February 2022).

Figure 2: Mountain points distribution according to rider’srank 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).

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. ClassDiagram –

includeaPDFfilewithaclassdiagramrepresentingtheclasscycling.CyclingPortalImpland 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 page.

Failure to submit any coversheet detailing both members student numbers and development log will incura penalty of 5 marks.

• build – to save the jar file that will be submitted. You need to generate ajar 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.

Assuming you followed the above-mentioned folder structure, here is an example of how you can generate the expected jar package:

>> ls

TestSystem    bin    build     doc     res     src

>> javac -dbin/ src/cycling/*.java

>> jarcvf build/cycling.jar -C bin .

(listing files added, omitted output)

>> jar uvf build/cycling.jar -C src .

(listing files added, omitted output)

>> jar uvf build/cycling.jar doc

(listing files added, omitted output)

>> jar uvf build/cycling.jarres

You may want to check the files within the jar file: >> jar -tf build/cycling.jar

or to extract its content:

>>jar -xvf build/cycling.jar

You can test your package using the CyclingPortalTestApp.java class provided with the interface and other files.

>> cd TestSystem

>> javac -cp ../build/cycling.jar CyclingPortalTestApp.java

>> java -cp .:../build/cycling.jar CyclingPortalTestApp

The system compiled and started the execution...

Finally, you will submit to ELE only the jar file build/cycling.jar.

4 Advice

1.     Do not jump straight into the coding: take time to consider the design of your solution first. Think about the objects that you will use, the data they will contain, what the methods they should

provide are (in addition to those mandated via the interface), how they relate to one another, etc. Once you are happy with your design, then start programming. Don’t be afraid to reassess your

design as you go through, but check on the implications of making a changes on all the other objects in your system that use the changed part.

2.     Check your objects behave as you intend — use a testing application and use assertions.

3.     Slowly fill out functionality — it is far better to submit a solution that supplies most but not all of the required operations correctly, rather than one that doesn’tprovide any/doesn’t compile, as a submission which does not provide any correct functionality at all will get a 0 for the operation    criteria. Start off with a CyclingPortalImpl

class that compiles and slowly (incrementally) add functionality. I have provided a class that implements   CyclingPortalon the released package (called BadCyclingPortalImpl) that does just this — it compiles, but provides none of the correct functionality. The solo version is called BadMiniCyclingPortalImpl.

4. Keep copies of your working code. If the worst happens and you had a version that worked on 50% of the operations and you’ve made changes that seem to have broken everything, it is useful to be able to     ‘roll-back’ to the earlier version and try again.

5. Do not change the interface and classes that I have provided for you. If you change them, the markers will not be able to compile my codebase with your submission, and you will receive an ‘Operation’ component mark of 0, as the interface will not be able to connect to the front-end of the system.

6. Practice creating the jar file using the following GitHub Classroom assignment

https://classroom.github. com/a/icpw4zB4.

5 Marking Criteria

This assessment will be marked using the following criteria.

Penalty. Use of non-permitted packages. -10

Penalty. Non-submission of classes diagram. -10