Programme:
Applied Computing
Module Code:
KF6034
Module Title:
Object Oriented and Web Programming
Distributed on:
Submission Time and Date:
To be submitted at demonstration on Thursday 16th January 2020
Word Limit:
Weighting
This coursework accounts for 50 of the total mark for this module
Submission of Assessment
This coursework will be submitted in electronic form at the arranged presentations
Introduction
This is a practical, group assignment, in which the majority of marks are for individual effort. It is expected that you will work in teams of three for the assignment, and the brief is split into three distinct sections. Each student in the team will take responsibility for one of the sections.
The majority of the marks are for the developed application and code. The only element which is not, is the class diagram, which is part of the File Handling role.
The assignment will be assessed at a scheduled demonstration on 16th January 2020. The demonstration process is not assessed and this is merely a means to facilitate accurate marking. At the demonstration, the tutor will also collect your handin using electronic methods possibly by copying your solution to a data stick, or by receiving a data stick from the team.
The software to be developed will be an mp3 player application.
This assessment addresses the following learning outcomes:
KnowledgeUnderstanding: 1. A critical application of predefined classes in the development of objectoriented programs2. A critical understanding necessary to construct multitiered applications using an appropriate languageIntellectualProfessional skillsabilities:3. To analyse a programming problem and develop an objectoriented program to provide a solution
Brief
2.1 Teams
First, form a team of three students. Teams of two or one are only acceptable in the following circumstances:
The number of students being assessed does not divide exactly by three
Students withdraw from the module or programme, leaving a team of two, or one.
A student has particular circumstances which mean that they need to not work in team situations, for example with a registered disability.
If there are any teams of less than three, one team member must be responsible for the player functionality.
Initially, you will be given a week from the release of this assignment in which to selfnominate a team. Once you have a team agreed, you should email me Dan Hodgson and cc in the rest of your team. If you do not I will have to email out to the rest of the team to check that the team is valid.
If you do not nominate a team within a week, you will be allocated to a team and notified. Once teams are finalised there will be no rearrangement of teams.
Advice on forming teams: A lot of student automatically ask their friends, and students that they get on with to team up with them. This can work very well, but sometimes can cause issues. Teams work best when the expectations of how much work will be done, and what sort of marks are being targeted, are as even as possible. Disparity of expectations is the biggest cause of team friction.
Also, communication is essential for teams to function well. Teaming up with people where communication is relatively easy can be a great advantage.
Create some software
Secondly, you of course need to create some software.
The software requirements are in three distinct areas of functionality: GUI, Operation, and File Handling. Each member of the team is responsible for one of these areas. The GUI person is responsible for the GUI elements of the software, the Operation person is responsible for the actual functionality of playing the musicsounds, and the File Handling person is responsible for saving and loading information, and for the creation of the class diagram.
In one of the practical sessions you will be introduced to GUI interfaces in Java. In the same session you will be introduced to the tools for playing MP3 files. In another session you will experience serialisationone method for saving and loading files.
Not everything that is asked for in this brief will be shown in the teaching sessions. There is an expectation that you will need to do some of your own research into these technologies.
Each of these three areas of responsibility will be marked separately, but there is also an element of the mark for integration, in which you will be marked on whether your components work well together.
For each area, three levels of requirements will be given, level A requirements, level B requirements and level C requirements. Mostly, in order to achieve level B requirements, level A requirements are needed, and similarly for level C requirements, these will normally rely on having met some level B requirementsin other words these are tiers of requirements that build on each other. Roughly speaking, a perfect implementation of level A requirements is worth 45 of the mark, a perfect implementation of levels A and B is worth 65 of the mark, and a perfect implementation of all three is worth 75 of the mark. Marks above 75 are reserved for taking your assignment beyond the prescribed functionality. Some ideas will be given about that later.
Java Interfaces
Java includes a mechanism for defining an interfacea set of required methods as defined by their signatures. Alongside this assignment brief, two interfaces, the danPlayer interface and the danSaver interface are given in Java files danPlayer.java and danSaver.java. These interfaces define the expected interactions between the different areas of responsibility. You MUST use these interfaces, and you MUST NOT change the interfaces, but you MAY ADD more methods to your classes which can be used by other areas that are not part of these interfaces. These interfaces are there for your protection, and to allow the marking of elements where not all of the team have fulfilled their responsibilities.
Instructions on how to use Java interfaces will be given in the teaching material.
The GUI part
One person in the team will have the responsibility of creating the GUI Graphical User Interface for the application. This should use Java AWT and Swing components as appropriate. Good marks in this part are reliant on the student undertaking some further investigation into available components, how to organise layout of components, and reasonable GUI design. It is likely that the code created will be limited to one class, or two if all of the level C requirements are met.
It is expected that the GUI class will be the entry point of the program, and it will have an attribute which is the player class, which does the actual sound playing commands. The player class must implement the danPlayer interface which is provided with the assessment danPlayer.java, which specifies a number of methods that can be used to talk to the player, however this implantation is the responsibility of the team member dealing with the Player part of the software. These will be outlined in the expected technologies below. Please noteas GUI creator you do not need to implement the functionality, you just need to get your GUI to call the relevant methods in the player class. The assignment does not define which types GUI elements should be used, so you need to intelligently choosethere may be buttons, text labels, checkboxes, sliders, radio buttons, text input as you see fit.
Level A requirements for the GUI
The GUI class will inherit from JFrame. It will probably also implement the ActionListener interface
The GUI class should be the entry point for the program. When an instance of the GUI class is created, this should automatically display the GUI window.
When the GUI is closed using the red cross, or by other methods the GUI instance should be disposed of and the program should completely close.
Code layout will be neat, including use of indentation, comments and sensible naming. This will apply to code created for functionality in level B and level C requirements also.
Code structure will be sensible, including sensible choices about classes, methods, attributes and inheritance. This will apply to code created for functionality in level B and level C requirements also.
The GUI will have a simple but useable layout
The GUI will provide the following possible control actions:
Play. Activating this will call the play method in the player class
Stop. Activating this will call the stop method in the player class
Pause. Activating this will call the pause method in the player class. You may want to think about what makes sense when the user activates pause when the sound is already paused.
Open. Activating this calls the openFile method in the player class.
Level B requirements for the GUI
All calls to methods of the player class will be protected with trycatch to catch and deal with exceptions. For the best implementation the GUI team member will work with the Player team member to implement bespoke exception classes. Appropriate messages will be given to the user, which must be either part of the GUI or in popup dialogs, not via the console output. These protections should be for all functionality, not just level B functionality
The GUI will display the controls and information with reasonable formatting using layout containers as appropriate.The interface will be clear and useable.
The name of the track being currently played will be displayed in the player. This can be found by calling the getCurrentTrackName method in the player class.
The current position time in the track will be displayed in the GUI in the form mins:secs.The current time can be found by calling the getTime method in the player class. This will need to be updated regularly, and you will need to find a method of doing so that works. A frequency of 10 times a second may be reasonable for this. The getTime method returns an object of the builtin type Duration, documentation can be found here: https:docs.oracle.comjavafx2apijavafxutilDuration.html
A control or controls will be provided so that the user can control the volume. The actions involved will call the method setVolume in the player class. This method expects a value of type double between 0 off and 1 full volume. Visual feedback will be given to the player to indicate the current volume level.
A control or controls will be provide so that the user can mute and unmute the player. The actions involved will call the method setMute in the player class which takes a Boolean value: true will mute the player, false will unmute the player. Visual feedback will be given to the player to indicate the current mute status.
When the GUI is initialised, it will query the current status of the player for volume and mute, and update the GUI to present this information. This will be done after the player class has been initialised, to allow the player to load these from a settings file. This information can be got using the getMute and getVolume methods in the player class.
Level C requirements for the GUI
Displaying a playlista list of tracks e.g. the tracks of an album to be played one after another. The list of tracks can be found by calling the getPlaylist method in the player class, which returns an ArrayListString.
When a user clicks on one of the track names in the playlist, the player starts to play that track instead of the current track. This can be done by calling the playTrack method in the player class, which needs an integer parameter. That number indicates the index in the playlist of the track to be played. If the user clicks on the track currently being played, it should not restart the track.
A control which is provided so the user can skip to the next track in the playlist. This can be done by calling the playTrack method in the player class, which needs an integer parameter. That number indicates the index in the playlist of the track to be played. If the player was already playing the last track in the playlist, the control should be ignored.
A control which is provided so the player can either restart the current track or skip back to the previous track. If the current track is less than 10 seconds from the start, the behaviour will be to skip back to the previous track, otherwise to restart the current track. If the player is already playing the first track of the playlist, then the skip back behaviour is ignored the restart track behaviour is still implemented. This can be done by calling the playTrack method in the player class, which needs an integer parameter. That number indicates the index in the playlist of the track to be played.
A seek control which allows the user to pick a specific point during the track and play from there. In existing software this is often implemented with some sort of slider, such that the lefthand end represents the start of the track and the righthand end represents the end of the track. Information on the length of the track can be got using the getTotalTime method in the player class, which returns a Duration object https:docs.oracle.comjavafx2apijavafxutilDuration.html. The current time can be found by calling the getTime method in the player class. If the time display has been implemented, then the GUI class already has a periodic method for getting this information. You can jump to another part of the current track using the setTime method in the player class, which expects a Duration parameter.
Functionality to facilitate the automatic starting of the next track when the current track has finished playing. The GUI team member and the Player team member will need to work together to ensure that information on the GUI is updated as appropriate, and that mechanisms for this to happen are put in place. This may involve creating methods which are not specified in the danPlayer interface.
Alteration to the load functionality such that when the user activates the load option they are presented with a dialog asking them to choose if they are loading a single MP3 file or a playlist. Depending on their response, openFile or openPlaylist will be called.
The Player part
One person in the team will take responsibility for the Player part, which is the functionality which actually deals with playing MP3 files. This can be achieved using the MediaPlayer class which is in the javafx.scene.media package. An example of basic functionality is presented in the practical material for this module. Documentation for the class can be found at https:docs.oracle.comjavafx2apijavafxscenemediaMediaPlayer.html which includes a full list of methods available.
The player functionality will include at least one class, but may involve more as seem sensible through the design. It must, however, include a class which implements the interface danPlayer. The Java file for this interface is posted with this assessment brief danPlayer.java, and needs to be included in your project. The code responsible for the GUI interface will have an attribute of the type of this class, which will then allow the GUI to invoke the prescribed methods of this class. The GUI will be implemented by the team member responsible for the GUI part of the software.
In one of the classes in the Player part there will be an attribute which is the Saver class, which implements saving and loading of information. The Saver class must implement the danSaver interface which is provided with the assessment danSaver.java, which specifies a number of methods that can be used to talk to the Saver, however this implantation is the responsibility of the team member dealing with the Saver part of the software.
Level A requirements for the Player
There will be a player class which implements the interface danPlayer. This class will initially have a stub implementation of all of the methods in the interface. Each stub will output a message to the console using System.out.println indicating which method has been invoked, and the values of any parameters passed to the method. Stubs of methods which expect a returned value will have a reasonable, hardcoded value. With these stubs implemented, the team member responsible for the GUI will be able to proceed with work before the full functionality is implemented. As work progresses on the player, these stubs will be replaced by functioning methods, which do not then need to output to the console.
Code layout will be neat, including use of indentation, comments and sensible naming. This will apply to code created for functionality in level B and level C requirements also.
Code structure will be sensible, including sensible choices about classes, methods, attributes and inheritance. This will apply to code created for functionality in level B and level C requirements also.
Implementation of the play method which will start playing the currently loaded mp3 file
Implementation of the stop method which will stop the currently loaded mp3 file playing
Implementation of the pause method which will pause the playing of the currently loaded mp3 file
Implementation of the openFilemethod which will pop up a file open dialog box so the user can choose an mp3 file to play. There are several readymade classes available which would help in this functionality, for example the JFileChooser class in the javax.swing packagedocumentation, including example of use can be found at https:docs.oracle.comjavase7docsapijavaxswingJFileChooser.html
Level B Requirements for the Player
All calls to methods of external classes including the Saver class will be protected with trycatch to catch and deal with exceptions. For the best implementation the Player team member will work with the Saver team member to implement bespoke exception classes. Appropriate exceptions will be thrown, which can then be caught by the GUI class. For the best implementation of this, the Player team member will work with the GUI team member to implement bespoke exception classes. This includes level A and level C functionality
Implementation of the getCurrentTrackName method which will return the name of the track being played, extracted from the filepath, but without any folder names, and without .mp3 at the end. This will be of type String.
Implementation of the setMute method to mute the sound. This takes a Boolean parameter, where true indicates to mute, and false indicates to unmute
Implementation of the setVolume method to set the volume of playback. This takes a double parameter where 0 means off and 1 means full volume.
Implementation of the getTime method which returns the current timepoint in the mp3 being played. This returns a value of type Duration, documentation for which can be found here: https:docs.oracle.comjavafx2apijavafxutilDuration.html
Implementation of the method getMute which returns a Boolean to indicate whether playback is muted true or not false.
Implementation of the method getVolume which returns a double indicating the current volume level of the player.0 means off and 1 means full volume.
Functionality to enable the saving of the current player settings mute and volume to an external file through the Saver class. This will involve invoking setMute and setVolume in the Saver class before invoking saveSettings in the Saver class. Decisions about when and how this process is triggered should be made as a team.
Functionality to enable the loading of player settings through the Saver class. This will involve first invoking loadSettings in the saver class, followed by getMute and getVolume. The state of the player should be set using this information. This will be done in a constructor for the class, so that the GUI class can be confident of these settings being in place, so it can update the visual feedback to the user when the application is launched.
Level C requirements for the Player
Implementation of the setTime method which will jump playback of the currentlyplayed track to a location in the track. This takes a parameter of the type Duration, documentation for which can be found at https:docs.oracle.comjavafx2apijavafxutilDuration.html
Implementation of the getTotalTime method which returns a Duration see previous requirement indicating the total length of the current mp3 track.
Implementation of playlist functionality. A playlist is a list of mp3 tracks, with a specified order. The player will hold the list of tracks in memory, and functionality is provided through the danPlayer interface to control the use of the playlist. Also, functionality is provided in the danSaver interface to load and save playlist files. However, no functionality is asked for which will allow the dynamic creation of playlists so the danSaver interface includes the getHardCodedPlayList method to allow the team to set up play lists by hardcoding the information.
On startup of the player, the method getHardCodedPlayList should be called in the Saver class, to initialise a playlist. This will be followed by functionality to save the playlist, by popping up a save file dialog you will need to research how followed by a call to the method savePlayList in the Saver class to save the playlist. The user will be able to choose not to save if they wish. Note: if the extended functionality for usercreated playlists is implemented, then this requirement can be removed.
Implementation of the method openPlayList which will pop up a file load dialogue, and then call loadPlayList in the Saver classto load a playlist.
Implementation of the method getPlayList which will return a list of the tracks in the current playlist, which have the directory names and .mp3 stripped out so that they are suitable for display
Implementation of the method playTrack which takes an int parameter indicating and index of a file in the playlist to load and play.
Implementation of the method restart which restarts the playback of the current track.
The Saver part
The team member with responsibility for the Saver part of the software has two responsibilities, The first is to document the workings of the software using one or more UML class diagrams. The second is to provide functionality for the saving and loading of settings, and of playlists.
The Saver functionality will include at least one class, which must implement the danSaver interface which is provided with the assessment danSaver.java, which specifies a number of methods that the Player can use to talk to the Saver, The player functionality which calls these methods will be implemented by the team member responsible for the Player part of the software.
Level A requirements for the Saver
There will be a saver class which implements the interface danSaver. This class will initially have a stub implementation of all of the methods in the interface. Each stub will output a message to the console using System.out.println indicating which method has been invoked, and the values of any parameters passed to the method. Stubs of methods which expect a returned value will have reasonable, hardcoded values. With these stubs implemented, the team member responsible for the Player will be able to proceed with work before the full functionality is implemented. As work progresses on the saver, these stubs will be replaced by functioning methods, which do not then need to output to the console.
Code layout will be neat, including use of indentation, comments and sensible naming. This will apply to code created for functionality in level B and level C requirements also.
Code structure will be sensible, including sensible choices about classes, methods, attributes and inheritance. This will apply to code created for functionality in level B and level C requirements also.
Documentation of the whole software project will be provided in the form of one or more UML class diagrams. These should include all relationships between classes and the inner elements of each class. This is limited to the classes in the project, including the provided interfaces, but will not include any external classes e.g. MediaPlayer. This will be provided in pdf format and available for handin with the software at the demonstration. Please note, it is often easier to document what has been created after the creation rather than what will be created before creation. This element may require furher research into the correct format of UML documentation.
Level B requirements for the Saver
All saving and loading functionality will be protected with trycatch to catch and deal with exceptions. For the best implementation the Player team member will work with the Saver team member to implement bespoke exception classes. Appropriate exceptions will be thrown, which can then be caught by the Player classes this includes level C functionality.
The implementation of saving and loading of player settings.This may involve the use of any method for filesaving and fileloading that the team member wishes, however it should be noted that the saving and loading of Java classes using XML serialisation is covered in the lecture and practical of week 10 of the module. The saver class will store the player setting information provided as attributes of a class, from which the information will be saved, and to which the information will be loaded. The player settings comprise the following data:
A Boolean representing the mute status of the player
A double representing the volume status of the player
The implementation of the saveSettings method which will cause the settings contained in the internal attributes to be saved to an external file. The name of this file is expected to be hardcoded.
The implementation of the loadSettings method which will cause the settings to be loaded from an external file into the interlan ttributes. The name of this file is expected to be hardcoded.
The implementation of the setMute method which sets the mute attribute for later saving
The implementation of the setVolume method which sets the volume attribute for later saving.
The implementation of the getMute method which returns the current value of the mute attribute
The implementation of the getVolume method which returns the current value of the volume attribute
Level C requirements for the Saver
The implementation of functionality to support playlist operation in the player. A playlist is a list of mp3 files to be played in order, and may represent an album, but not necessarily. A playlist is represented by an ArrayListString where each element holds the full filepath of one Mp3 file.
The implementation of the getHardCodedPlayList method. Inside this method, a number of filepaths to MP3 files will be hardcoded, and returned as an ArrayListString. This method allows for the creation of playlist files without implementing sophisticated functionality in the MP3 player, and will probably be run several times with different values output in order to create a number of usable playlist files.
The implementation of the savePlayList method. This takes as parameters a playlist in an ArrayListString and a filepath to which the playlist will be saved.
The implementation of the loadPlayList method. This takes a filepath as a parameter, determining the location of the playlist file to be loaded, and returns the playlist in the form of an ArrayListString
Diagrammatic representation
GUI
A:
Start and close
Simple playing
Code Quality
B:
Displaying more info
Mute and Volume
Exceptions
C:
Change play time
Playlists
GUI
A:
Start and close
Simple playing
Code Quality
B:
Displaying more info
Mute and Volume
Exceptions
C:
Change play time
Playlists
Player
A:
Dummy interface
Simple playing
Code Quality
B:
Providing more info
Mute and Volume
Exceptions
C:
Moving play time
Playlists
Player
A:
Dummy interface
Simple playing
Code Quality
B:
Providing more info
Mute and Volume
Exceptions
C:
Moving play time
Playlists
Saver
A:
Dummy interface
Code Quality
UML Diagrams
B:
Save and load settings
Exceptions
B:
Playlists
Saver
A:
Dummy interface
Code Quality
UML Diagrams
B:
Save and load settings
Exceptions
B:
Playlists
Individual responsibility and Integration
This brief is designed to deliberately minimise reliance between team members, and the use of the provided interfaces and stub implementations is part of this process, to reduce dependence. However, a team assessment needs some interdependence and you will see that there are several areas in which this is required, more so as the requirements increase through levels A, B and C.
You will see in the marking scheme that there are specific marks for integration. These are to reward the students who have managed to work effectively as a team. It is reiterated here that while you must implement the Java interfaces, and must not alter them, you may add functionality and communication that does not use these methods.
As a team assessment, you are allowed to help each other with development, however the team member responsible for a particular area is the one who will get the marks for that area regardless of relative efforts.
Going beyond the brief
As you will see when you read the marking scheme, implementing the full brief will get you to a mark of 75. In order to push your marks higher than that you will need to provide sensible, useful functionality which goes beyond what is asked for. This, of course should be aligned to the responsibilities you have, but may involve working together across the responsibilities. Some suggestions for ways in which the functionality could be extended are given here:
Shuffle capability
Making the GUI particularly attractive
Displaying album art
Using ID3 tags to display track information
Implementing a search facility
Updating the track position display in real time as the user scrubs the play position
User creation of playlists
The marks given for extended functionality will be dependent on the complexity of the tasks undertaken. Please note, engaging with this is an optional part of the assignment.
In the unfortunate situation of teams or two, or even one student, it may be reasonable for functionality for areas not covered by a students responsibility to be considered as going beyond the brief. For example, if a team comprises one member implementing the GUI, and another implementing the Player, and the team member implementing the saver leaves the programme, it may be that work done by one or both of the remaining team members in the Saver brief can be considered for marks in this category.
Showing novelty
Very high marks in this assignment are very hard to achieve, and are reserved for students who not only go beyond the brief, but also show some originality in approach or functionality, possibly extending functionality into cuttingedge, or unusual but useful areas.
Handin Details
The software and electronic copies of the documentation will be handed in at the demonstration which will be arranged for 16th January 2020. This will either be by the handing over of electronic media, or by the copying of the relevant files onto the tutors electronic media. Which method may be stipulated beforehand.
Students must retain an electronic copy of this assignment and it must be made available within 24hours of them requesting it be submitted.
Marking
4.1 Individual responsibilities 80
Individual sections are marked out of 80 and use the rubric below. Work which is perfectly described by the description in the rubric will receive a midpoint mark in that mark range. Marks between the midpoints will be used where work falls between these descriptions. Reasonable compromises will be made, for example work which has significant functionality beyond the requirements, yet fails in some requirements will be marked as seems reasonable. Partial marks may be used.
Quality as assessed using the defined criteria
Marks Range
Exceptionalgoing beyond expectations and showing novelty or innovationall functionality levels a, B and C, significant further functionality, and the implementation of novel or cutting edge features.
7280
90100
OutstandingGoing beyond expectationsall functionality levels A, B and C and significant further functionality.
6471
8089
Excellent: All functionality of levels A, B and C
5663
7079
Strong: All of level A and level B functionality but none of level C functionality
4855
6069
Satisfactory: all of level A functionality and roughly half of level B functionality, but none of level C functionality
4047
5059
Weak All of level A functionality but none of level B or level C
3239
4049
Poor: Some of level A functionality and none of level B or level C
2431
3039
Deeply Flawed:no functionality or very little functionality
023
029
Integration 20
The integration marks represent how well the software is integrated and works as a whole. The mark for this is a group mark, which by default will be given to each member of the group. Unlike the individual responsibilities, you are not asked to go beyond the brief or show novelty in this area for high marks. It is possible, for perfect integration, to get a full mark 20.
This mark covers how well the classes made by different people work together, including the prescribed interactions through the Java interfaces, any other interactions created, and the use of exceptions. Marks will be allocated using the following grid:
Work which is perfectly described by the description in the rubric will receive a midpoint mark in that mark range. Marks between the midpoints will be used where work falls between these descriptions. Reasonable compromises will be made, as appropriate. Partial marks may be used.
Quality as assessed using the defined criteria
Marks Range
Perfect: no integration issues
1820
90100
Excellent: a one or two small integration issues
1617
8089
Strong: a few small integration issues or one more significant issue
1415
7079
Satisfactory: On balance more than half of the integration working
1213
6069
Weak: significant flaws in integration
1011
5059
Poor: Most integration not working, but a few scattered bits of functionality
89
4049
Deeply Flawed: Very poor or no functionality integrated.
07
3039
Please notethis assignment is designed so that most of the integration should be simple, as it is heavily reliant on predefined interfaces.
In teams of two either by design or fate it may be reasonable to only consider the integration of the two areas that are represented.
Feedback.
Marks and summative feedback will be sent to you individually by email after marking. You may also receive verbal feedback andor preliminary marks at the demonstration.
Module marks are not negotiable and the module team will not respond to challenges to marks on academic grounds. If you think there is a procedural error in your marking e.g. sections missed, incorrect addition please contact the teaching team. If you are having problems understanding your feedback you may contact the marking team for clarification. Provisional marks may be released along with feedback before the marks have been formalised by an exam board. Any such provisional marks are subject to change.
Peer weighting
By default, the marks for integration are a group mark. If your team feels that this is in some way unfair, then a process will be undertaken to allocate marks more reasonably. If one or more team members request this process, it will run as follows:
After preliminary marks are received, and team member who wishes to initiate peer weighting will contact the marker to indicate so. This will be within 5 working days of receiving preliminary marks and feebback.
All team members will be notified that one or more of the team has asked for peer weighting of marks
All team members will be invited to indicate what they think the relative proportions of effort were for the integration aspects
There will be a strict deadline for students to respond to this
The final decision will be made, taking into account the students responses, circumstances and any understanding of the situation that the tutor may have, by the tutor. The tutor will be as fair as can reasonably be expected with the information at their disposal, and their decision will stand.
No deviation from team marks will be considered on the report of only one student.
Regulations and Policies
7.1 Assessment Regulations
You are advised to read the guidance for students regarding assessment policies. They are available online here.
7.2 Late submission of work
Where coursework is submitted without approval, after the published handin deadline, the following penalties will apply.
For coursework submitted up to 1 working day 24 hours after the published handin deadline without approval, 10 of the total marks available for the assessment i.e.100 shall be deducted from the assessment mark.
Coursework submitted more than 1 working day 24 hours after the published handin deadline without approval will be regarded as not having been completed. A mark of zero will be awarded for the assessment and the module will be failed, irrespective of the overall module mark.
These provisions apply to all assessments, including those assessed on a PassFail basis.
The full policy can be found here
7.3 Group Work
The group work policy can be found here
7.4 Academic Misconduct
The Assessment Regulations for Taught Awards ARTA contain the Regulations and procedures applying to cheating, plagiarism and other forms of academic misconduct.
The full policy is available at here
You are reminded that plagiarism, collusion and other forms of academic misconduct as referred to in the Academic Misconduct procedure of the assessment regulations are taken very seriously. Assignments in which evidence of plagiarism or other forms of academic misconduct is found may receive a mark of zero.
Reviews
There are no reviews yet.