Programming Languages and Paradigms
1
ASSESSMENT COVER SHEET 
Unit Code and Title: (6G6Z0041_2425_9FHU): Programming Languages and 
Paradigms
Assessment ID: 1CWK100
Assessment Weigh9ng: 100%
Assessment Title: MulK-paradigmaKc SoluKons to a Self-Proposed Task
Type: Individual
Hand-In Deadline: Friday 23rd May 2025 – 9 PM China Time
Hand-In Format and Mechanism: 
Submission is online, via Moodle.
You must submit a single zipped file containing all folders for each 
programming language referred in the assignment delivery 
sec9on.
Learning outcomes being assessed: 
LO1: Implement soluKons to common algorithmic tasks using a range of programming languages and 
paradigms.
LO2: Compare and contrast design and implementaKon aspects of core programming concepts using 
mulKple programming languages
Note: It is your responsibility to make sure that your work is complete and available for marking by the 
deadline. Make sure that you have followed the submission instrucKons carefully, and your work is 
submiYed in the correct format, using the correct hand-in mechanism (e.g., Moodle upload). If submiZng 
via Moodle, you are advised to check your work a[er upload, to make sure it has uploaded properly. If 
Programming Languag代写6G6Z0041 MulK-paradigmaKc SoluKons es and Paradigms
2
submiZng via OneDrive, ensure that your tutors have access to the work. Do not alter your work a[er the 
deadline. You should make at least one full backup copy of your work. 
Penal4es for late submission 
The Kmeliness of submissions is strictly monitored and enforced. 
All coursework has a late submission window of 7 calendar days, but any work submiYed within the late 
window will be capped at 40%, unless you have an agreed extension. Work submiYed a[er the 7-day late 
window will be capped at zero unless you have an agreed extension. See ‘Assessment MiKgaKon’ below 
for further informaKon on extensions. 
Please note that individual tutors are unable to grant extensions to assessments. 
Assessment Mi4ga4on 
If there is a valid reason why you are unable to submit your assessment by the deadline you may apply for 
assessment miKgaKon. There are two types of miKgaKon you can apply for via the unit area on Moodle (in 
the ‘Assessments’ block on the right-hand side of the page): 
• Self-cerFficaFon: does not require you to submit evidence. It allows you to add a short extension 
(usually, but not always, seven days) to a deadline. This is not available for event-based assessments 
such as in-class tests, presentaKons, interviews, etc. You can apply for this extension during the 
assessment weeks, and the request must be made before the submission deadline. 
• Evidenced extensions requires you to provide independent evidence of a situaKon which has 
impacted you. Allows you to apply for a longer extension and is available for event-based assessment 
such as in-class test, presentaKons, interviews, etc. For event-based assessments, the normal 
outcome is that the assessment will be deferred to the Summer resist period. 
Further informaKon about Assessment MiKgaKon is available on the dedicated Assessments page: 
hYps://www.mmu.ac.uk/student-life/course/assessments#ai-69991-0
Plagiarism 
Plagiarism is the unacknowledged representaKon of another person’s work, or use of their ideas, as one’s 
own. Manchester Metropolitan University takes care to detect plagiarism, employs plagiarism detecKon 
so[ware, and imposes severe penalKes, as outlined in the Student Code of Conduct and RegulaKons for 
Undergraduate Programmes. Poor referencing or submiZng the wrong assignment may sKll be treated as 
plagiarism. If in doubt, seek advice from your tutor. 
If you are unable to upload your work to Moodle 
If you have problems submiZng your work through Moodle, you can email it to the Assessment Team’s 
ConKngency Submission Inbox using the email address submit@mmu.ac.uk. You should say in your email 
which unit the work is for and provide the name of the Unit Leader. The Assessment team will then forward 
your work to the appropriate person. If you use this submission method, your work must be emailed 
before the published deadline, or it will be logged as a late submission. AlternaKvely, you can save your 
work into a single zip folder then upload the zip folder to your university OneDrive and submit a Word 
Programming Languages and Paradigms
3
document to Moodle which includes a link to the folder. It is your responsibility to make sure you share 
the OneDrive folder with the Unit Leader, or it will not be possible to mark your work.
Assessment RegulaFons 
For further informaKon see Assessment RegulaKons for Undergraduate/Postgraduate Programmes of
Study on the Student Life web pages. 
FormaFve Feedback: You are encouraged to share your work with your tutor and your peers for 
discussion and feedback. 
SummaFve Feedback: 
You will receive wri=en feedback on your work within 20 working days of 
submission, in the form of a feedback sheet as shown in Appendix B. There 
will also be general feedback offered to all students studying the unit.

  1. Introduc,on 
    The unit is 100% coursework based, and has a single component (1CWK100), weighted at 100% of the unit 
    marks. In summary: 
    • You will propose enhancements to the Kc-tac-toe program
    o SoluKons for this task should not be easily available online.
    o Take the exisKng Kc-tac-toe code and add some sensible variaKon to it.
    o Your task should be personalized using some idenKfiable informaKon (e.g., your full name, 
    or your student ID number). 
    • You will write Three soluKons to your task, using different programming languages and paradigms. 
    o Your soluKons must each exhibit a range of paradigmaKc features.
    o Your soluKons must each use a unique programming language.
    • For each soluKon, you will provide: 
    o (a) the name of the language and paradigm you have used. 
    o (b) Screenshots of your design process, demonstraKng how you created the code and the 
    validaKon process you used to ensure that it was suitable for your task 
    o (c) a short descripKon of your programme, explaining how the code you have wriYen 
    completes the task and how your programme fits the named paradigm. 
    • The deliverables are: 
    o Your uniquely proposed task descripKon (unmarked) 
    o A folder containing 3 subdirectories, one per language. 
    o Each subfolder must contain: 
    ▪ A text file with your code 
    ▪ A word document or pdf documenKng your design process (see Appendix A) 
    Programming Languages and Paradigms
    4
    ▪ A word document or pdf with your code explanaKon 
    ▪ Assessment Overview (1CWK100) 
    a) Enhancement to Tic-tac-toe
    You should write your own task descripKon for the game Kc-tac-toe. This should be an extension to 
    the Kc-tac-toe code, which should be your own piece of work. You can add your own elements of 
    specificaKon to make the task of Kc-tac-toe unique. 
    For example, to make the task of developing a Kc-tac-toe game unique you could implement some 
    addiKonal rule, or rules to the game, such as making the board larger (e.g., 7x7, or NxM) or implement 
    some extra gameplay rule (e.g., you can choose to remove one of the opponent’s O’s or X’s every 3rd
    turn. You should be imaginaKve in creaKng your task to ensure it is unique to you and different to 
    those in the rest of the class. On Moodle as well there are some more enhancement suggesKons 
    provided and as discussed during the lecture.
    To further personalise your task, you should incorporate either your student ID number or your name 
    into the task descripKon and code. This helps for future plagiarism detecKon. You should make it clear 
    in your task descripKon of Kc-tac-toe game on how the element of personalizaKon will be done. 
    I am not making a limit to the difficulty or ease of the task. You should choose a difficulty level that you 
    feel is appropriate to your coding ability and that will set you an appropriate challenge. SoluKons to 
    more difficult problems will likely expose more interesKng features of the languages and paradigms, 
    leading to the opportunity to score more highly on the assessed documents. 
    b) Choose three different languages 
    You should select three different languages to use to solve your task. These languages must be selected 
    from those taught during the unit. You can refer to Moodle for a full list of languages that have been 
    covered. The languages you choose should allow you to solve the task in a variety of programming 
    styles. You must use a different programming paradigm for each soluKon and your choice of language 
    should reflect this. The five programming paradigms we cover are as follows: ImperaKve, Procedural, 
    Object-Oriented, FuncKonal, Logic.
    c) Create Solu9ons 
    You should write a bespoke soluKon in each language, conforming to a paradigm. You are allowed to 
    use a large language model, or copilot to aid in your programming. Please ensure that your code is 
    appropriately indented, well commented, and conforms to appropriate standards for the language you 
    are coding in (e.g., variable naming convenKons, etc.). You are welcome to use the same approach to 
    solve the task you have designed across your three soluKons; however, you should design your 
    soluKons in such a way that the specific paradigmaKc features of each language you have used may be 
    properly showcased. 
    Programming Languages and Paradigms
    5
    d) Document Solu9ons 
    You must provide two disKnct documents for each language. The first document should show your 
    design and development process for your soluKon in that language. You should include any sketches, 
    UML diagrams, class diagrams, pseudocode or wireframes that you create. There may be some 
    crossover in your design work between languages, but you should sKll document this for each 
    language. As part of your design document, you should also capture the development process that 
    you have undertook including tesKng and bug-fixing. You should include intermediary screenshots of 
    your design process. If you use a large language model or copilot as part of your programming, you 
    should include screenshots of all interacKons, as well as some indicaKon as to how you used this 
    informaKon and how you validated the results. This document may be presented in a ‘scrapbook’ 
    format and should be made mostly of images or figures (with short connecKng texts) collected during 
    your design and implementaKon process.
    The second document is a short paragraph (max 300 words) describing the language features that you 
    have used to solve the soluKon, and explaining how the soluKon conforms to the stated paradigm. A 
    typical soluKon might spend 200 words on the former and 100 words on the laYer, although this will 
    vary from one language to another.
    You should not use a language model to produce either of these documents. They will typically 
    produce hallucinated documentaKon or false reasoning for this type of task which will impede your 
    marks. If you do choose to use a language model you must include all interacKons as screenshots as 
    an appendix to the specific document that they are relevant to.
    e) Compare Solu9ons 
    Finally, you should write a comparison of your three soluKons. Your comparison should be no more 
    than 1000 words and should highlight similariKes and differences between your soluKons in each pair 
    of languages, especially considering the paradigms that you have conformed to. A typical soluKon 
    might spend around 150 words introducing the three languages and paradigms, then 250 words per 
    language pair highlighKng similariKes and differences in approach, with 100 words reserved for a 
    summary conclusion. You may assume that the marker is aware of your task and has read your design 
    and explanaKon documents.
    Again, you should not use a language model to produce your comparison document as they are not 
    suitable for this task and are likely to give incorrect answers, harming your chance to succeed. If you 
    do use a language model, you must include screenshots of your interacKons as an appendix to your 
    comparison document.
    Programming Languages and Paradigms
    6
  2. The Submission 
    Your submission is via Moodle. You must submit a zip file containing a folder. The folder should have your 
    ID number as its name. Inside the folder you should place: 
    (a) a text file containing the task descripKon you have wriYen. 
    (b) A word document or PDF containing a comparison of your soluKons, highlighKng similariKes and 
    differences in how you used specific paradigmaKc features to solve each task. 
    (c) 3 sub-folders. Each sub-folder should have the name of the programming language that you have used 
    for that soluKon. Inside each sub-folder you must have: 
    (c.1) a text file containing the code you used named LANG_code.txt, where LANG is replaced 
    with the language you have used. 
    (c.2) A Word or PDF document containing your Design documentaKon, named LANG_design, 
    where LANG is replaced with the name of the language you have used. 
    (c.3) A word or PDF document containing a statement of the paradigm that you have used and 
    your explanaKon of how the code you have wriYen meets your stated paradigm. This should be 
    named LANG_paradigm, where LANG is replaced with the language you have used. 
    A sample file hierarchy is given below, Note, you are free to choose any 3 languages from the course:
    • 99999999 
    o Task.txt 
    o Comparison.docx 
    o Python 
    ▪ Python_code.txt 
    ▪ Python_design.docx 
    ▪ Python_paradigm.docx o Prolog 
    ▪ C++_code.txt 
    ▪ C++ _design.docx 
    ▪ C++ _paradigm.docx o GO 
    ▪ C_code.txt 
    ▪ C_design.docx 
    ▪ C_paradigm.docx 
    Programming Languages and Paradigms
    7
  3. Mark Scheme 
    Marks will be apporKoned as follows: 
    • 15% Code Design
    • 15% Language 1 – Paradigm DescripKon
    • 15% Language 2 – Paradigm DescripKon
    • 15% Language 3 – Paradigm DescripKon
    • 40% Comparison
    Individual mark schemes for each secKon are given below: 
    Design 
  4. marks: No documentaKon. 
    1-5 marks: liYle design and implementaKon documentaKon work, or design and implementaKon 
    documentaKon is incoherent and unrelated to submiYed code. 
    6-10 marks: Adequate design and implementaKon documentaKon work. Design and implementaKon 
    documentaKon is related to submiYed code. 
    11-15 marks: Excellent and extensive design and implementaKon documentaKon work. DocumentaKon 
    goes beyond usual expectaKons for a final year undergraduate student. 
    Paradigm 
  5. marks: No documentaKon. 
    1-5 marks: Paradigm is incorrectly idenKfied. Poor descripKon of features, with liYle relaKonship to the 
    code. 
    6-10 marks: A paradigm is stated with appropriate reasoning. Most features are correctly described, with 
    few to no errors. 
    11-15 marks: Paradigm is correctly idenKfied. Outstanding descripKon of features, showing excepKonal 
    understanding of how the given paradigm is used. 
    Comparison 
  6. marks: No Comparison. 
    Programming Languages and Paradigms
    8
    1-10 marks: An inadequate comparison, covering an incomplete set of paradigms. LiYle or no criKcality in 
    evaluaKon. 
    11-20 marks: An adequate level of comparison. At least two paradigms are correctly compared. Some 
    appropriate features are idenKfied and equivalencies are demonstrated in soluKons with liYle or no errors. 
    21-30 marks: A good degree of comparison. All paradigms are compared appropriately. A complete set of 
    features is idenKfied with no errors made. High level of criKcality and understanding of programming 
    paradigms. 
    31-40 marks: An excellent degree of comparison, above and beyond the reasonable expectaKons for the 
    final year of study. Each paradigm is compared to the other two paradigms. Highly coherent analysis of 
    features used.
  7. Feedback 
    Your feedback on the assessment will consist of an assigned marking boundary for each element as given 
    above. You will also receive summary feedback indicaKng posiKve points of the assignment, as well as an 
    indicaKon of areas that you have lost marks. An example feedback sheet is given in Appendix B. 
  8. Support for the Assignment 
    a) Help! I don’t know where to begin or what to do! 
    You should start by idenKfying the task and languages that you will use. Once you have decided on these, 
    the rest of the assignment should fall into place. You may wish to discuss ideas with your peers in order 
    to get an understanding of whether the scope of your proposal is appropriate, but make sure you submit 
    a different task to those you have discussed with. 
    b) Opportuni9es for Forma9ve Feedback 
    You will be given an opportunity to submit your task descripKon for formaKve feedback during the 
    semester. See Moodle for the submission date. The feedback you receive will typically either be a 
    confirmaKon that this task is acceptable, or a suggested modificaKon to improve the task. If you miss the 
    deadline, I will be unable to provide ad-hoc formaKve feedback for task descripKons. 
    Programming Languages and Paradigms
    9
    c) Your Final Feedback 
    You will receive an overall mark, a breakdown of that mark according to the mark scheme (SecKon 4). You 
    will also receive a short comment on what went well, allowing you to aYain the given grade boundary and 
    what could have been improved to aYain the next boundary. 
    d) How do I contact the unit tutor? 
    If you want to ask any quesKons on the requirements of the assessment then please do get in touch with 
    me via Email, Teams, or face-to-face during my weekly office hours which will be held in the learning studio. 
    See Moodle for my contact details. 
    Programming Languages and Paradigms
    10
    Appendix A – Example Design and 
    Implementa3on Document 
    I decided to implement the modified Kc-tac-toe programme using Haskell. My high-level pseudocode for 
    the overall algorithm is as follows: 
  9. Represent board as list of lists 
  10. Implement recursive funcKon to go through a single list determining if there is a win (rows) 
  11. Implement recursive funcKon to go through a list of lists determining if there is a win (cols) 
  12. Implement recursive funcKon to go through a list of lists determining if there is a win (diagonal) 5.
    Implement funcKon to add a ‘M’ or ‘S’ in a row-col posiKon. Signature: char, [[Integer]] -> 
    [[Integer]] 
  13. Implement funcKon to remove a ‘M’ or ‘S’. (reuse above funcKon?)
  14. Implement funcKon to govern game logic 
    a. M goes first, then S 
    b. At each iteraKon get a number (1-49) indicaKng cell to play in 
    c. Every 3rd turn players can remove a cell 
    I have provided screenshots of the pseudocode that I wrote on my whiteboard for each funcKon below: 
    Recursive funcKon: [SCREENSHOT 1] 
    Add/remove char to board: [SCREENSHOT 2] 
    Game Loop: [SCREENSHOT 3] 
    During my implementaKon process, I wrote the following code as a first iteraKon: 
    [SCREENSHOTS OF CODE] 
    This allowed me to idenKfy the following errors in my approach, which led me to redesign my system as 
    follows: 
    [SCREENSHOTS OF ERRORS AND UPDATED CODE] 
    Once I had a working system, I decided to test it. The tests that I ran are as follows: 
    1) Run to the end with M player winning 
    2) Run to the end with S player winning 
    3) Run to the end with a draw. 
    [SCREENSHOTS OF TESTING] 
    Programming Languages and Paradigms
    11
    Appendix B – Feedback Sheet 
    Marker Name: MaYhew Shardlow 
    Student Name: MaYhew Shardlow 
    Student ID: 99999999 
    Score for Design: X; 
    Score for LANG1 Paradigm DescripKon: Y1; 
    Score for LANG2 Paradigm DescripKon: Y2; 
    Score for LANG3 Paradigm DescripKon: Y3; 
    Comparison Score: Z
    Total Score: T
    This submission contains a Kc-tac-toe game with a modified board design and an addiKonal rule to allow 
    players to remove their opponents’ Kles. SoluKons 1 and 3 (Haskell and C++) were well implemented in 
    the funcKonal and OO paradigms. The OO structure in C++ was excepKonally well designed and led to 
    efficient code. SoluKon 2 failed to use Rust correctly and did not state the paradigm that was being used. 
    I have used the criteria below to mark your work. You can see a further breakdown of your marks by 
    matching your assigned grade to the given band for each category. 

jcvfnjn8
1 声望0 粉丝