代做1CWK100、代写C/C++程序语言
- 首页 >> Python编程 Programming Languages and Paradigms
1
ASSESSMENT COVER SHEET
Unit Code and Title:
(6G6Z0041_2324_9FHU): Programming Languages and
Paradigms
Assessment Set By: Dr Peter Ankomah
Assessment ID: 1CWK100
Assessment Weighting: 100%
Assessment Title: Multi-paradigmatic Solutions to a Self-Proposed Task
Type: Individual (100%)
Hand-In Deadline: Monday 8
th April 2024 - 9pm
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
section.
Learning outcomes being assessed:
Implement solutions to common algorithmic tasks using a range of programming
LO1: languages and paradigms.
Compare and contrast design and implementation aspects of core programming concepts
LO2: using multiple 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 instructions carefully, and your work is
submitted in the correct format, using the correct hand-in mechanism (e.g., Moodle upload). If
submitting via Moodle, you are advised to check your work after upload, to make sure it has uploaded
Programming Languages and Paradigms
2
properly. If submitting via OneDrive, ensure that your tutors have access to the work. Do not alter your
work after the deadline. You should make at least one full backup copy of your work.
Penalties for late submission
The timeliness of submissions is strictly monitored and enforced.
All coursework has a late submission window of 7 calendar days, but any work submitted within the late
window will be capped at 40%, unless you have an agreed extension. Work submitted after the 7-day
late window will be capped at zero unless you have an agreed extension. See ‘Assessment Mitigation’
below for further information on extensions.
Please note that individual tutors are unable to grant extensions to assessments.
Assessment Mitigation
If there is a valid reason why you are unable to submit your assessment by the deadline you may apply
for assessment mitigation. There are two types of mitigation you can apply for via the unit area on
Moodle (in the ‘Assessments’ block on the right-hand side of the page):
• Self-certification: 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, presentations, 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 situation which has
impacted you. Allows you to apply for a longer extension and is available for event-based
assessment such as in-class test, presentations, interviews, etc. For event-based assessments, the
normal outcome is that the assessment will be deferred to the Summer resist period.
Further information about Assessment Mitigation is available on the dedicated Assessments page:
https://www.mmu.ac.uk/student-life/course/assessments#ai-69991-0
Plagiarism
Plagiarism is the unacknowledged representation of another person’s work, or use of their ideas, as one’s
own. Manchester Metropolitan University takes care to detect plagiarism, employs plagiarism detection
software, and imposes severe penalties, as outlined in the Student Code of Conduct and Regulations for
Undergraduate Programmes. Poor referencing or submitting the wrong assignment may still 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 submitting your work through Moodle, you can email it to the Assessment Team’s
Contingency 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. Alternatively, you
can save your work into a single zip folder then upload the zip folder to your university OneDrive and
submit a Word 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.
Programming Languages and Paradigms
3
Assessment Regulations
For further information see Assessment Regulations for Undergraduate/Postgraduate Programmes of
Study on the Student Life web pages.
Formative Feedback:
You are encouraged to share your work with your tutor and your peers for
discussion and feedback.
Summative Feedback:
You will receive written 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. Introduction
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 tic-tac-toe program
o Solutions for this task should not be easily available online.
o Take the existing tic-tac-toe code and add some sensible variation to it.
o Your task should be personalized using some identifiable information (e.g., your full
name, or your student ID number).
• You will write Three solutions to your task, using different programming languages and
paradigms.
o Your solutions must each exhibit a range of paradigmatic features.
o Your solutions must each use a unique programming language.
• For each solution, you will provide:
o (a) the name of the language and paradigm you have used.
o (b) Screenshots of your design process, demonstrating how you created the code and
the validation process you used to ensure that it was suitable for your task
o © a short description of your programme, explaining how the code you have written
completes the task and how your programme fits the named paradigm.
• The deliverables are:
o Your uniquely proposed task description (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 documenting your design process (see Appendix A)
▪ A word document or pdf with your code explanation
▪ Assessment Overview (1CWK100)
Programming Languages and Paradigms
4
a) Enhancement to Tic-tac-toe
You should write your own task description. This should be a new task, for which there are no
solutions readily available via web search (or at worst, very few). You may base your task on an
existing task, for example by starting with that task and then adding your own elements of
specification to make the task unique.
For example, you may start with the task of developing a tic-tac-toe game. To make this unique you
could implement some additional 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 imaginative in creating your task to ensure it is
unique to you and different to those in the rest of the class.
To further personalise your task, you should incorporate either your student ID number or your name
into the task description and code. This helps for future plagiarism detection. For example, you may
seed a random number generator with your student ID, or if your task includes some text element
then you may use your name for this (e.g., a cryptograph). You should make it clear in your task
description how the element of personalization 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. Solutions to
more difficult problems will likely expose more interesting features of the languages and paradigms,
leading to the opportunity to score more highly on the assessed documents. As a rough guide, your
task should be more difficult than a typical lab-exercise (e.g., fizzbuzz with the numbers changed is
probably too simple), but less difficult than a typical end of year assignment (e.g., you should not
propose to implement a full-fledged mobile app or web front end). 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 solution and your
choice of language should reflect this. The five programming paradigms we cover are as follows:
Imperative, Procedural, Object-Oriented, Functional, Logic. c) Create Solutions
You should write a bespoke solution 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 conventions, etc.). You are welcome to use the same approach to
solve the task you have designed across your three solutions; however you should design your
solutions in such a way that the specific paradigmatic features of each language you have used may be
properly showcased. d) Document Solutions
Programming Languages and Paradigms
5
You must provide two distinct documents for each language.
The first document should show your design and development process for your solution 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 still document this for each language. As part of your design document, you should
also capture the development process that you have undertook including testing 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 interactions, as well as
some indication as to how you used this information 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 connecting texts) collected during your design and implementation process.
The second document is a short paragraph (max 300 words) describing the language features that
you have used to solve the solution, and explaining how the solution conforms to the stated
paradigm. A typical solution might spend 200 words on the former and 100 words on the latter,
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 documentation 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 interactions as screenshots as
an appendix to the specific document that they are relevant to. e) Compare Solutions
Finally, you should write a comparison of your three solutions. Your comparison should be no more
than 1000 words and should highlight similarities and differences between your solutions in each
pair of languages, especially considering the paradigms that you have conformed to. A typical
solution might spend around 150 words introducing the three languages and paradigms, then 250
words per language pair highlighting similarities 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 explanation 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 interactions as an appendix to your
comparison document.
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 description you have written.
Programming Languages and Paradigms
6
(b) A word document or PDF containing a comparison of your solutions, highlighting similarities and
differences in how you used specific paradigmatic 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 solution. 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 documentation, 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 explanation of how the code you have written 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
▪ Prolog_code.txt
▪ Prolog _design.docx
▪ Prolog _paradigm.docx o GO
▪ GO_code.txt
▪ GO_design.docx
▪ GO_paradigm.docx
3. Mark Scheme
Marks will be apportioned as follows:
Programming Languages and Paradigms
7
For each language (25% of overall grade per language):
Design Document (10 marks)
Paradigm Document (15 marks)
Comparison (25% of overall grade)
Individual mark schemes for each section are given below:
Design
0 marks: No documentation.
1-3 marks: little design and implementation documentation work, or design and implementation
documentation is incoherent and unrelated to submitted code.
4-6 marks: Adequate design and implementation documentation work. Design and implementation
documentation is related to submitted code.
7-10 marks: Excellent and extensive design and implementation documentation work. Documentation
goes beyond usual expectations for a final year undergraduate student.
Paradigm
0 marks: No documentation.
1-5 marks: Paradigm is incorrectly identified. Poor description of features, with little relationship 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 identified. Outstanding description of features, showing exceptional
understanding of how the given paradigm is used.
Comparison
0 marks: No Comparison.
1-5 marks: An inadequate comparison, covering an incomplete set of paradigms. Little or no criticality in
evaluation.
6-15 marks: An adequate level of comparison. At least two paradigms are correctly compared. Some
appropriate features are identified and equivalencies are demonstrated in solutions with little or no
errors.
16-20 marks: A good degree of comparison. All paradigms are compared appropriately. A complete set of
features is identified with no errors made. High level of criticality and understanding of programming
paradigms.
Programming Languages and Paradigms
8
20-25 marks: An excellent degree of comparison, above and beyond the reasonable expectations for the
final year of study. Each paradigm is compared to the other two paradigms. Highly coherent analysis of
features used.
4. 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 indicating positive points of the assignment, as well as an
indication of areas that you have lost marks. An example feedback sheet is given in Appendix B.
5. Support for the Assignment
a) Help! I don’t know where to begin or what to do!
You should start by identifying 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) Opportunities for Formative Feedback
You will be given an opportunity to submit your task description for formative feedback during the
semester. See Moodle for the submission date. The feedback you receive will typically either be a
confirmation that this task is acceptable, or a suggested modification to improve the task. If you miss the
deadline, I will be unable to provide ad-hoc formative feedback for task descriptions.
c) Your Final Feedback
You will receive an overall mark, a breakdown of that mark according to the mark scheme (Section 4).
You will also receive a short comment on what went well, allowing you to attain the given grade
boundary and what could have been improved to attain the next boundary.
Programming Languages and Paradigms
9
d) How do I contact the unit tutor?
If you want to ask any questions 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.
Appendix A – Example Design and
Implementation Document
I decided to implement the modified tic-tac-toe programme using Haskell. My high-level pseudocode for
the overall algorithm is as follows:
1. Represent board as list of lists
2. Implement recursive function to go through a single list determining if there is a win (rows)
3. Implement recursive function to go through a list of lists determining if there is a win (cols)
4. Implement recursive function to go through a list of lists determining if there is a win (diagonal)
5. Implement function to add a ‘M’ or ‘S’ in a row-col position. Signature: char, [[Integer]] ->
[[Integer]]
6. Implement function to remove a ‘M’ or ‘S’. (reuse above function?)
7. Implement function to govern game logic
a. M goes first, then S
b. At each iteration get a number (1-49) indicating 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 function below:
Recursive function: [SCREENSHOT 1]
Add/remove char to board: [SCREENSHOT 2]
Game Loop: [SCREENSHOT 3]
During my implementation process, I wrote the following code as a first iteration:
[SCREENSHOTS OF CODE]
This allowed me to identify 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:
Programming Languages and Paradigms
10
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]
Appendix B – Feedback Sheet
Marker Name: Matthew Shardlow
Student Name: Matthew Shardlow
Student ID: 99999999
Solution 1 Solution 2 Solution 3
Comparison
(25)
Total
(100)
Design
(10)
Explanation
(15)
Design
(10)
Explanation
(15)
Design
(10)
Explanation
(15)
7 11 3 8 10 15 17 71
This submission contains a tic-tac-toe game with a modified board design and an additional rule to allow
players to remove their opponents tiles. Solutions 1 and 3 (Haskell and C++) were well implemented in
the functional and OO paradigms. The OO structure in C++ was exceptionally well designed and led to
efficient code. Solution 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.
Programming Languages and Paradigms
11
ASSESSMENT CRITERIA
Design
(10)
0 marks: No documentation.
1-3 marks: little design and implementation documentation work, or design and implementation
documentation is incoherent and unrelated to submitted code.
4-6 marks: Adequate design and implementation documentation work. Design and implementation
documentation is related to submitted code.
7-10 marks: Excellent and extensive design and implementation documentation work. Documentation
goes beyond usual expectations for a final year undergraduate student.
Explanation
25%
Comparison
25%
Programming Languages and Paradigms
12
Design
0 marks: No documentation.
1-3 marks: little design and implementation documentation work, or design and implementation
documentation is incoherent and unrelated to submitted code.
4-6 marks: Adequate design and implementation documentation work. Design and implementation
documentation is related to submitted code.
7-10 marks: Excellent and extensive design and implementation documentation work. Documentation
goes beyond usual expectations for a final year undergraduate student.
Explanation
0 marks: No documentation.
1-5 marks: Paradigm is incorrectly identified. Poor description of features, with little relationship 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 identified. Outstanding description of features, showing exceptional
understanding of how the given paradigm is used.
Programming Languages and Paradigms
13
Comparison
0 marks: No Comparison.
1-5 marks: An inadequate comparison, covering an incomplete set of paradigms. Little or no criticality in
evaluation.
6-15 marks: An adequate level of comparison. At least two paradigms are correctly compared. Some
appropriate features are identified, and equivalencies are demonstrated in solutions with little or no
errors.
16-20 marks: A good degree of comparison. All paradigms are compared appropriately. A complete set of
features is identified with no errors made. High level of criticality and understanding of programming
paradigms.
20-25 marks: An excellent degree of comparison, above and beyond the reasonable expectations for the
final year of study. Each paradigm is compared to the other two paradigms. Highly coherent analysis of
features used.
1
ASSESSMENT COVER SHEET
Unit Code and Title:
(6G6Z0041_2324_9FHU): Programming Languages and
Paradigms
Assessment Set By: Dr Peter Ankomah
Assessment ID: 1CWK100
Assessment Weighting: 100%
Assessment Title: Multi-paradigmatic Solutions to a Self-Proposed Task
Type: Individual (100%)
Hand-In Deadline: Monday 8
th April 2024 - 9pm
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
section.
Learning outcomes being assessed:
Implement solutions to common algorithmic tasks using a range of programming
LO1: languages and paradigms.
Compare and contrast design and implementation aspects of core programming concepts
LO2: using multiple 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 instructions carefully, and your work is
submitted in the correct format, using the correct hand-in mechanism (e.g., Moodle upload). If
submitting via Moodle, you are advised to check your work after upload, to make sure it has uploaded
Programming Languages and Paradigms
2
properly. If submitting via OneDrive, ensure that your tutors have access to the work. Do not alter your
work after the deadline. You should make at least one full backup copy of your work.
Penalties for late submission
The timeliness of submissions is strictly monitored and enforced.
All coursework has a late submission window of 7 calendar days, but any work submitted within the late
window will be capped at 40%, unless you have an agreed extension. Work submitted after the 7-day
late window will be capped at zero unless you have an agreed extension. See ‘Assessment Mitigation’
below for further information on extensions.
Please note that individual tutors are unable to grant extensions to assessments.
Assessment Mitigation
If there is a valid reason why you are unable to submit your assessment by the deadline you may apply
for assessment mitigation. There are two types of mitigation you can apply for via the unit area on
Moodle (in the ‘Assessments’ block on the right-hand side of the page):
• Self-certification: 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, presentations, 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 situation which has
impacted you. Allows you to apply for a longer extension and is available for event-based
assessment such as in-class test, presentations, interviews, etc. For event-based assessments, the
normal outcome is that the assessment will be deferred to the Summer resist period.
Further information about Assessment Mitigation is available on the dedicated Assessments page:
https://www.mmu.ac.uk/student-life/course/assessments#ai-69991-0
Plagiarism
Plagiarism is the unacknowledged representation of another person’s work, or use of their ideas, as one’s
own. Manchester Metropolitan University takes care to detect plagiarism, employs plagiarism detection
software, and imposes severe penalties, as outlined in the Student Code of Conduct and Regulations for
Undergraduate Programmes. Poor referencing or submitting the wrong assignment may still 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 submitting your work through Moodle, you can email it to the Assessment Team’s
Contingency 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. Alternatively, you
can save your work into a single zip folder then upload the zip folder to your university OneDrive and
submit a Word 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.
Programming Languages and Paradigms
3
Assessment Regulations
For further information see Assessment Regulations for Undergraduate/Postgraduate Programmes of
Study on the Student Life web pages.
Formative Feedback:
You are encouraged to share your work with your tutor and your peers for
discussion and feedback.
Summative Feedback:
You will receive written 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. Introduction
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 tic-tac-toe program
o Solutions for this task should not be easily available online.
o Take the existing tic-tac-toe code and add some sensible variation to it.
o Your task should be personalized using some identifiable information (e.g., your full
name, or your student ID number).
• You will write Three solutions to your task, using different programming languages and
paradigms.
o Your solutions must each exhibit a range of paradigmatic features.
o Your solutions must each use a unique programming language.
• For each solution, you will provide:
o (a) the name of the language and paradigm you have used.
o (b) Screenshots of your design process, demonstrating how you created the code and
the validation process you used to ensure that it was suitable for your task
o © a short description of your programme, explaining how the code you have written
completes the task and how your programme fits the named paradigm.
• The deliverables are:
o Your uniquely proposed task description (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 documenting your design process (see Appendix A)
▪ A word document or pdf with your code explanation
▪ Assessment Overview (1CWK100)
Programming Languages and Paradigms
4
a) Enhancement to Tic-tac-toe
You should write your own task description. This should be a new task, for which there are no
solutions readily available via web search (or at worst, very few). You may base your task on an
existing task, for example by starting with that task and then adding your own elements of
specification to make the task unique.
For example, you may start with the task of developing a tic-tac-toe game. To make this unique you
could implement some additional 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 imaginative in creating your task to ensure it is
unique to you and different to those in the rest of the class.
To further personalise your task, you should incorporate either your student ID number or your name
into the task description and code. This helps for future plagiarism detection. For example, you may
seed a random number generator with your student ID, or if your task includes some text element
then you may use your name for this (e.g., a cryptograph). You should make it clear in your task
description how the element of personalization 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. Solutions to
more difficult problems will likely expose more interesting features of the languages and paradigms,
leading to the opportunity to score more highly on the assessed documents. As a rough guide, your
task should be more difficult than a typical lab-exercise (e.g., fizzbuzz with the numbers changed is
probably too simple), but less difficult than a typical end of year assignment (e.g., you should not
propose to implement a full-fledged mobile app or web front end). 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 solution and your
choice of language should reflect this. The five programming paradigms we cover are as follows:
Imperative, Procedural, Object-Oriented, Functional, Logic. c) Create Solutions
You should write a bespoke solution 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 conventions, etc.). You are welcome to use the same approach to
solve the task you have designed across your three solutions; however you should design your
solutions in such a way that the specific paradigmatic features of each language you have used may be
properly showcased. d) Document Solutions
Programming Languages and Paradigms
5
You must provide two distinct documents for each language.
The first document should show your design and development process for your solution 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 still document this for each language. As part of your design document, you should
also capture the development process that you have undertook including testing 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 interactions, as well as
some indication as to how you used this information 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 connecting texts) collected during your design and implementation process.
The second document is a short paragraph (max 300 words) describing the language features that
you have used to solve the solution, and explaining how the solution conforms to the stated
paradigm. A typical solution might spend 200 words on the former and 100 words on the latter,
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 documentation 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 interactions as screenshots as
an appendix to the specific document that they are relevant to. e) Compare Solutions
Finally, you should write a comparison of your three solutions. Your comparison should be no more
than 1000 words and should highlight similarities and differences between your solutions in each
pair of languages, especially considering the paradigms that you have conformed to. A typical
solution might spend around 150 words introducing the three languages and paradigms, then 250
words per language pair highlighting similarities 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 explanation 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 interactions as an appendix to your
comparison document.
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 description you have written.
Programming Languages and Paradigms
6
(b) A word document or PDF containing a comparison of your solutions, highlighting similarities and
differences in how you used specific paradigmatic 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 solution. 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 documentation, 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 explanation of how the code you have written 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
▪ Prolog_code.txt
▪ Prolog _design.docx
▪ Prolog _paradigm.docx o GO
▪ GO_code.txt
▪ GO_design.docx
▪ GO_paradigm.docx
3. Mark Scheme
Marks will be apportioned as follows:
Programming Languages and Paradigms
7
For each language (25% of overall grade per language):
Design Document (10 marks)
Paradigm Document (15 marks)
Comparison (25% of overall grade)
Individual mark schemes for each section are given below:
Design
0 marks: No documentation.
1-3 marks: little design and implementation documentation work, or design and implementation
documentation is incoherent and unrelated to submitted code.
4-6 marks: Adequate design and implementation documentation work. Design and implementation
documentation is related to submitted code.
7-10 marks: Excellent and extensive design and implementation documentation work. Documentation
goes beyond usual expectations for a final year undergraduate student.
Paradigm
0 marks: No documentation.
1-5 marks: Paradigm is incorrectly identified. Poor description of features, with little relationship 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 identified. Outstanding description of features, showing exceptional
understanding of how the given paradigm is used.
Comparison
0 marks: No Comparison.
1-5 marks: An inadequate comparison, covering an incomplete set of paradigms. Little or no criticality in
evaluation.
6-15 marks: An adequate level of comparison. At least two paradigms are correctly compared. Some
appropriate features are identified and equivalencies are demonstrated in solutions with little or no
errors.
16-20 marks: A good degree of comparison. All paradigms are compared appropriately. A complete set of
features is identified with no errors made. High level of criticality and understanding of programming
paradigms.
Programming Languages and Paradigms
8
20-25 marks: An excellent degree of comparison, above and beyond the reasonable expectations for the
final year of study. Each paradigm is compared to the other two paradigms. Highly coherent analysis of
features used.
4. 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 indicating positive points of the assignment, as well as an
indication of areas that you have lost marks. An example feedback sheet is given in Appendix B.
5. Support for the Assignment
a) Help! I don’t know where to begin or what to do!
You should start by identifying 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) Opportunities for Formative Feedback
You will be given an opportunity to submit your task description for formative feedback during the
semester. See Moodle for the submission date. The feedback you receive will typically either be a
confirmation that this task is acceptable, or a suggested modification to improve the task. If you miss the
deadline, I will be unable to provide ad-hoc formative feedback for task descriptions.
c) Your Final Feedback
You will receive an overall mark, a breakdown of that mark according to the mark scheme (Section 4).
You will also receive a short comment on what went well, allowing you to attain the given grade
boundary and what could have been improved to attain the next boundary.
Programming Languages and Paradigms
9
d) How do I contact the unit tutor?
If you want to ask any questions 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.
Appendix A – Example Design and
Implementation Document
I decided to implement the modified tic-tac-toe programme using Haskell. My high-level pseudocode for
the overall algorithm is as follows:
1. Represent board as list of lists
2. Implement recursive function to go through a single list determining if there is a win (rows)
3. Implement recursive function to go through a list of lists determining if there is a win (cols)
4. Implement recursive function to go through a list of lists determining if there is a win (diagonal)
5. Implement function to add a ‘M’ or ‘S’ in a row-col position. Signature: char, [[Integer]] ->
[[Integer]]
6. Implement function to remove a ‘M’ or ‘S’. (reuse above function?)
7. Implement function to govern game logic
a. M goes first, then S
b. At each iteration get a number (1-49) indicating 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 function below:
Recursive function: [SCREENSHOT 1]
Add/remove char to board: [SCREENSHOT 2]
Game Loop: [SCREENSHOT 3]
During my implementation process, I wrote the following code as a first iteration:
[SCREENSHOTS OF CODE]
This allowed me to identify 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:
Programming Languages and Paradigms
10
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]
Appendix B – Feedback Sheet
Marker Name: Matthew Shardlow
Student Name: Matthew Shardlow
Student ID: 99999999
Solution 1 Solution 2 Solution 3
Comparison
(25)
Total
(100)
Design
(10)
Explanation
(15)
Design
(10)
Explanation
(15)
Design
(10)
Explanation
(15)
7 11 3 8 10 15 17 71
This submission contains a tic-tac-toe game with a modified board design and an additional rule to allow
players to remove their opponents tiles. Solutions 1 and 3 (Haskell and C++) were well implemented in
the functional and OO paradigms. The OO structure in C++ was exceptionally well designed and led to
efficient code. Solution 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.
Programming Languages and Paradigms
11
ASSESSMENT CRITERIA
Design
(10)
0 marks: No documentation.
1-3 marks: little design and implementation documentation work, or design and implementation
documentation is incoherent and unrelated to submitted code.
4-6 marks: Adequate design and implementation documentation work. Design and implementation
documentation is related to submitted code.
7-10 marks: Excellent and extensive design and implementation documentation work. Documentation
goes beyond usual expectations for a final year undergraduate student.
Explanation
25%
Comparison
25%
Programming Languages and Paradigms
12
Design
0 marks: No documentation.
1-3 marks: little design and implementation documentation work, or design and implementation
documentation is incoherent and unrelated to submitted code.
4-6 marks: Adequate design and implementation documentation work. Design and implementation
documentation is related to submitted code.
7-10 marks: Excellent and extensive design and implementation documentation work. Documentation
goes beyond usual expectations for a final year undergraduate student.
Explanation
0 marks: No documentation.
1-5 marks: Paradigm is incorrectly identified. Poor description of features, with little relationship 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 identified. Outstanding description of features, showing exceptional
understanding of how the given paradigm is used.
Programming Languages and Paradigms
13
Comparison
0 marks: No Comparison.
1-5 marks: An inadequate comparison, covering an incomplete set of paradigms. Little or no criticality in
evaluation.
6-15 marks: An adequate level of comparison. At least two paradigms are correctly compared. Some
appropriate features are identified, and equivalencies are demonstrated in solutions with little or no
errors.
16-20 marks: A good degree of comparison. All paradigms are compared appropriately. A complete set of
features is identified with no errors made. High level of criticality and understanding of programming
paradigms.
20-25 marks: An excellent degree of comparison, above and beyond the reasonable expectations for the
final year of study. Each paradigm is compared to the other two paradigms. Highly coherent analysis of
features used.