代做Assessment Brief: Coursework
- 首页 >> Python编程Assessment Brief: Coursework 2023-24
Assessment Details
Course Title:
Fundamentals of Computer Science I
Course Code:
LCSCI4207
Level:
4
Assessment Title:
Project 2
Assessment Number:
AE3
Assessment Type:
Code & Documentation
Restrictions on Time/Length:
24-32h
Individual/Group:
Individual
Assessment Weighting:
30%
Issue Date:
13 February 2024
Hand in Deadline:
1 March 2024 at 13:00
Planned Feedback Deadline:
28 calendar days after hand in deadline
Mode of Submission:
Online
Anonymous Marking:
Yes
Assessment Task
In this assessment, you will design a program to represent a standard 52-card deck and play some more advanced card games!
A deck consists of 13 ranks in each of the four suits: clubs (♣), diamonds (♦), hearts (♥) and spades (♠). Diamonds and hearts are also referred to as “red cards”; while clubs and spades as “black cards”. The 13 ranks of each suite consist often numeral cards, from one (Ace) toten, and three face cards, Jack, Queen and King. You will design this program step-by-step:
1. Playing Card data design (5 marks)
Design the data type PlayingCard to represent a single card. You should be able to represent the rank of the card (Ace, 2-10, Jack, Queen, King) as well as its suit (clubs, hearts, diamonds, spades). Include at least 3 example cards – which will come in handy later for tests!
a) Design the function cardToString that takes a card as input and produces a string according to the following specification: the rank comes first, separated by a "pipe" character ('|'), followed by the suit of the card (e.g., “Ace|diamonds” or “2|hearts”). Make sure to test all your card examples!
b) Design the function stringToCard that takes a string, assumed to be in the format described above, and produces the corresponding card. No more reminders about testing, but you know the drill :).
Hint: you'll find string.split(separator) quite handy: it breaks the string into a list, separated by the supplied separator string.
2. Playing Card Deck data design (5 marks)
Design the data type Deck to represent a standard 52-card deck of cards. The deck should contain a sequence of cards. You are encouraged to represent this sequence using a standard mutable list. Fill this list with all the 52 cards in the constructor.
a) Design the function shuffleDeck that randomly shuffles a complete deck of cards.
Hint: you’ll find MutableList<T>.shuffle standard function handy!
b) Design the function dealCard that randomly deals one card from a deck to a player (without replacement; in other words, when a card is dealt from the deck, it cannot be dealt again).
3. Poker hands (5 marks)
Design the data type CardHand to represent a list of five cards. Each CardHand has a method fileFormat, which produces a textual representation of the hand as "card1,card2,card3,card4,card5". Include at least 3 example card hands – which will come in handy later for tests! – and make sure to test the required method.
4. Poker hand types (50 marks)
Each card hand corresponds to a named type (in winning order):
1. “Royal Flush”. Player has Ace, King, Queen, Jack, and 10, all in the same suit.
2. “Straight Flush.” Player has five consecutive cards, all in the same suit. For example, 6, 7, 8, 9, 10, and Jack, all spades.
3. “Four-of-a-Kind”. Player has four cards of the same rank, and any other card. E.g., four 3s and a King.
4. “Full House”. Player has three cards of the same rank and two cards of the same rank. E.g., three 10s and two 7s.
5. “Flush”. Player has five cards, all of the same suit, but not in a consecutive order. E.g., then 5, 7, 9, Jack and King of diamonds.
6. “Straight”. Player has five consecutive cards which are not all the same suit. E.g., 6 of spades, 7 of diamonds, 8 of hearts, 9 of clubs, 10 of spades, and Jack of hearts.
7. “Three-of-a-Kind”. Player has three cards of the same rank; and any other two that do not form a pair. E.g., three 10s, one 7 and one 5.
8. Two Pair. Player has two pairs, each being a different rank. E.g., two 10s, two 7s, and a King.
9. One Pair. Player has two cards of the same rank. E.g., two 10s.
10. High Card. Player has cards that do not form any of the above combinations. Write the following functions:
a. (45 marks) Design the function getType that takes a hand, and returns the type of hand a player holds. Consider functions isRoyalFlush, isStraightFlush, isFourOfAKind (see Project 1), isFullHouse, isFlush, isStraight, isThreeOfAKind, isTwoPair, isOnePair, isHighCard and how they need to be invoked in order to determine the type of a hand a player holds. Include at least 3 example card hands for each type.
Hint: A “royal flash”, for example, is a special case of a “flush” .
b. (5 points) Design the function compareHands that takes two hands, one per player, and returns which player wins. In case of a tie (e.g., both players have a “straight”), the highest card wins.
5. Files of hands (30 marks)
Now that we have our card hands, let's update how we read them from files.
a. (5 points) Design the function stringToCardHand that takes a string, assumed to be in the file format described above, and produces the corresponding card hand.
Hint: You'll find string.split(separator) quite handy.
b. (5 marks) Design the function readCardHandFile that takes a path to a file and produces a list of card hands. If the file does not exist, return an empty list. Otherwise, you can assume that every line is formatted in the string format we just worked with.
c. (20 marks) Now, let’s replay a game! Design the function replayGame that takes as argument two or more files, each corresponding to a player in a game of Poker. You can assume that all files have the same number of lines and every line in a file is formatted in the string format we just worked with. Each line corresponds to the hand dealt to a player at a round of the game: The first line of the first file is the hand of Player 1 in round 1, the first line of the second file is the hand of Player 2 in round 1, and so on. The function returns the winning player the game overall. In addition:
6. Let’s replay a tournament (5 marks)
Write a function replayTournament that takes as argument two or more 3-player games. Return a report of the frequency of each card hand type in the tournament.
Specification
1. You are to upload a filenamed p2.main.kts on canvas for your submission.
2. You are expected to provide necessary documentation for your code; 10% of your overall mark will be based on English proficiency (see T3a in Learning Outcomes below).
3. Each class and function, highlighted in bold letters in the task description above, should have associated tests.
Assessment Criteria
70 or higher There was evidence of the ability to perform all programming tasks correctly. The demonstration of the methods was excellent, coherent, well documented and clearly explained.
60-69 There was evidence of ability to perform some programming tasks
correctly. The demonstration of the methods is good, coherent and reasonably detailed and explained.
50-59 There was evidence of ability to perform some programming tasks
correctly, but the demonstration of the methods was limited, incoherent, not adequately documented and vaguely explained.
40-49 There was limited evidence of ability to perform programming tasks.
The demonstration of the methods involved significant omissions and produced substantial inaccuracies.
39 or less Failure to solve the programming task in assignment. Methods were
completely incorrect or absent. General grading criteria for Level 4 are described in Appendix B of the course syllabus.
Marking
The University uses two common assessment marking schemes – one for undergraduate and one for postgraduate - to mark all taught programmes leading to an award of the University.
More detailed information on the common assessment marking scheme and the criteria can be found in the Course Syllabus, available on the University’s VLE.
Information for students on pathway and mobility programmes about conversion to Northeastern University grades is available in the relevant programme handbook
Learning Outcomes
This assessment will enable students to demonstrate in full or in part the learning outcomes identified in the Course Descriptor.
On successful completion of this assessment, students should be able to: Knowledge and Understanding
K1a Demonstrate knowledge and understanding of the underlying principles and concepts of programming.
K2a Demonstrate knowledge and understanding of program design principles and concepts such as parametric polymorphism (e.g., generic functions and data types), generative recursion, and accumulators.
K3a Demonstrate an understanding of the technical, social and management dimensions of programs, their extensibility and correctness, in real-world applications.
Subject-Specific Skills
S1a Complete a data analysis of a problem statement and describe the data
required to solve a problem; create input and output examples of the data to describe the desired functionality of a program that solves the problem at
hand; and use aforementioned examples for testing.
S2a Plan an iterative approach to solve large problems; and design scalable, abstract data collections to solve growing problems.
S3a Compose programs from several functions and data collections, either
sequentially (e.g., for batch applications) or using event-based features (e.g., for web applications).
Transferable Skills
T1a Make reasoned discussions and contributions in group settings, fostered through collaborative work during lab sessions.
T3a Display a developing technical proficiency in written English and an ability to communicate clearly and accurately in structured and coherent pieces of
writing.
Accessing Feedback
Students can expect to receive feedback on all summative coursework within 28 working days of the submission deadline. The 28 calendar day deadline does not apply to work submitted late. Feedback can be accessed through the Turnitin assessment link on the course page. Further instructions on submitting an assessment and accessing feedback can be found on the University’s VLE.
Late Submissions
Students are reminded to submit their assessment in the correct format and ahead of the published deadline. Deadlines are strict and Canvas uploads made remotely might not be immediate, we therefore strongly recommend that students upload
their work to Canvas in goodtime before the deadline. If assessments are
submitted late without approved Extenuating Circumstances, there are penalties:
● For assessments submitted up to two days late: any mark of 40% or higher will be capped at 40% for undergraduate students. Any mark of 50% or
higher will be capped at 50% for postgraduate students. Any mark below
40% for undergraduate students and below 50% for postgraduate students, will stand.
● Students who do not submit their assessment within two days, and have no approved extenuating circumstances, are deemed not to have submitted and to have failed that assessment element. The mark recorded will be 0%.
● Late penalties are calculated differently for some types of portfolios. Please read the Assessment Brief of your portfolio carefully.
For further information, please refer to AQF7 Part C in the Academic Handbook.
Extenuating Circumstances
The University’s Extenuating Circumstances (ECs) procedure is in place if there are genuine circumstances that may prevent a student submitting an assessment. If the EC application is successful, there will be no academic penalty for missing the published submission deadline.
Students are normally expected to apply for ECs in advance of the assessment deadline. Students may apply for consideration of ECs retrospectively if they can provide evidence that they could not have done so in advance of the deadline. All applications for ECs must be supported by independent evidence.
Students are reminded that the ECs procedure covers only short-term issues (within 21 days leading to the submission deadline) and that if they experience longer-term matters that impact on learning then they must contact Student Support and Development for advice.
Under the Extenuating Circumstances Policy, students may defer an assessed
element on only one occasion and may request an extension on a maximum of two occasions.
For further information, please refer to the Extenuating Circumstances Policy in the Academic Handbook.
Academic Misconduct
Any submission must be a student’s own work and, where facts or ideas have been used from other sources, these sources must be appropriately referenced. The Academic Misconduct Policy includes the definitions of all practices that will be deemed to constitute academic misconduct. This includes the use of artificial intelligence (AI) where not expressly permitted within the assessment brief, or in a manner other than specified. Students should check this policy before submitting their work. Students suspected of committing Academic Misconduct will face action under the Policy. Where students are found to have committed an offence they will be subject to sanction, which may include failing an assessment, failing a course or being dismissed from the University depending upon the severity of the offence committed. For further information, please refer to the Academic Misconduct Policy in the Academic Handbook.