代写Assessment Brief: Coursework

日期：2024-02-26 08:43

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.