1    Theory Part (40 points)

The following problems are worth the points indicated.  They are generally based on the lectures about software development, data structure selection, and much of Clean Code. As a irst assign- ment, it establishes a baseline for design and code quality. Therefore, it gives more credit than will be usual for the programming section,and it has more interconnections between the Theory Part and the Programming Part.

“Paper” programs are those which are composed (handwritten or typed) on the same sheet that the rest of the theory problems are composed on, and are not to be text-edited, compiled, executed, or debugged.  For fairness, there will be no extra credit for doing any work for paper programs beyond the design and coding necessary to manually produce the objects or object fragments that are asked for, so text editor or computer output will have no effect on your grade. The same goes for the Theory Part in general:  scanned clear handwriting is suficient, and computer-generated documents will earn no extra credit.

An important note about academic honesty: If you use any resource, including stackoverflow. com, you must properly attribute the source of your answer with the proper citation. Cutting and

pasting without attribution is plagiarism.  The CAs will electronically and physically check for   cheating, and will report to the instructor any suspected violations. This even goes for wikipedia. org—which for this course often turns out to be inaccurate or overly complicated, anyway—since   plagiarizing from Wikipedia is still plagiarism.  Much better to read, think, and create your own   sentences.

1.1    Con  icting design requirements (6 points)

Consider how a student would decide on which restaurant to choose, based on the restaurant’s design objectives.  List six design considerations that are conlicting, like we did in class with the examples of vehicles, for example, we said “high speed” is an objective but it conlicts with “fuel eficiency”. Show for each consideration their analogy to a feature or consideration of Java classes.  For example, “limited menu” for a restaurant could be like “array capacity” .  Is there a “best” restaurant? Explain.

1.2    arrays, ArrayLists, LinkedLists (11 points)

Using the cheatsheet, explain which of the three data structures of a[], AL, LL—or which nested combinations of them—are best for use in the following scenarios, giving a reason or an example of its use:

a.  A box of facial tissues, used one at a time.

b.  A “favorites” list in an application, like within a browser.

c.  That part of a wallet that holds bills, which the user keeps sorted by denomination.

d.  A tie or scarf rack.

e.  A train going from city to city, picking up and dropping off collections of boxcars, whose place in the train is determined by their eventual destination.

f.  A collection of boxes of various sizes that allow you to move your “stuff” from a full small box to a larger box.

g.  The United States Postal Service, who has assigned nine-digits (“Zip plus 4”) codes to geo- graphical regions of the country, to route all mail.

h.  The bouncer at a popular social establishment, who keeps patrons waiting in a line, but who may allow special handling for distinguished guests or people he doesn’tlike.

Then, give one example each of your own from the real world in which aggregations of real objects are manipulated like a[], AL, LL. You must give examples that differ from the ones given in class and in this question: e.g., no parking lots, spring-loaded bookcases, beads on a chain, zip codes, bouncers, etc.

1.3    After the Programming Part: UML (5 points)

Find a free Eclipse plug-in that takes your Java code, and creates printable output of your system’s UML. UMLet, which is free, is a reasonable choice and is suggested. But you can use others, or, alternatively, you can create the UML manually. Your answer to this problem is the output of that tool applied to your system, at whatever Step you completed.

1.4    After the Programming Part: Clean Code, Names (6 points)

Select three names you used in your solution that you are most proud of. Show how each of them follows at least two of the suggestions in Chapter 2.  Make sure all six of these total suggestions are different.

1.5    After the Programming Part: Clean Code, Methods (6 points)

Select three methods you used in your solution that you are most proud of. Show how each of them follows at least two of the suggestions in Chapter 3.  Make sure all six of these total suggestions are different.

1.6    After the Programming Part: Clean code, Comments (6 points)

Select three comments you used in your solution that you are most proud of.  Show how each of them follows at least two of the suggestions in Chapter 4.  Make sure all six of these total suggestions are different.

2    Programming Part (60 points)

2.0    Overview

2.0.1    In general

This assignment is intended to walk you through the design process, using a console application built on straightforward Java.  It will also serve as a baseline to record your design proiciency at the beginning of the course, since that you will use part of your solution to this assignment in Assignment 5.  So try to make it as clean, well-documented, and lexible as you can, as you will have to adapt your design later in the course in ways that are as yet unknown to you.

Basically, this assignment provides a requirement speciication, which is very wordy, together with some friendly advice, which you are free to ignore. It asks you to do the object decomposition, documentation, algorithm and data structure selection, coding, and testing (via a friend!)  of a relatively simple system. None of this assignment requires any graphical user interfaces, but that will come later in the course. Nevertheless, the system will show behaviors that maybe dificult to predict.

Further, this Programming Part attempts to show in miniature, step by step, what happens when a system design is actually deployed.  The initial design should be chosen so that it can be extended easily, either in response to a change in real world speciications, or to the discovery of a way to improve of system performance, or to user feedback. Up front adherence to good design practice will make all such developments possible—and even easy–later.

You are strongly encouraged to think through the design irst, and decompose your system into classes in away that allows incremental upgrades by means of localized changes.

2.0.2    In speciic

Your project begins at the irst Step by implementing a system to play the three-gesture game of Rock, Paper, Scissors (“RPS”) against a human opponent, namely, a friend.. The system plays ran- domly, which, it turns out, is a winning strategy against people, since human players tend to have irrational preferences and superstitions. Your system will show this, because it will summarize the game statistics at the end of each game.

At a second Step, you extend the system to play a somewhat more complex game, Rock, Paper, Scissors, Lizard, Spock (“RPSKL”), against the friend.  Again, random play by the system will again win, as will be shown by your system’s game summary.  RPSKL is one of several possible “trivial” extensions of the game to ive gestures.  But in order to complete this step, your system has to adapt to these changed speciications of the game.  If you had taken care in your design in the irst step, this should be quick and painless.  And, like any good system, your design should still retain the ability to play RPS, based on user choice.

At the third Step, you extend the system to play a non-trivial but balanced extension, Rock, Paper, Scissors, Fire, Water (“RPSFW”). It is non-trivial because the rules are not simply a re- naming of the rules for RPSKL; the KL and the FW behave very differently. Nevertheless, it is a balanced game, in that no single gesture can always win.  Some experimentation will again show that people “get stuck” and can therefore be beaten easily by a machine. But because the game is non-trivial, strictly random play does not work.  Fortunately, an almost random strategy does.  At this step, both the rules of the game and the algorithms for selecting a move have evolved further.

But again, if you have taken care, these changes should also be “natural” and rather small, and the user will now have a choice of three games to play.

At the fourth Step, the system and the friend have to play a very different non-trivial balanced ive-gesture variant called Rock, Paper, Monkey, Fire, Water (“RPMFW”). Its big difference with RPSFW here is that the Monkey doesn’t play like a Scissors; in fact, Monkey runs away from Fire or Water, so there is no winner between Monkey and Fire or between Monkey and Water.  In this game also, people will get stuck, and, fortunately there is an almost random strategy—different from the almost random strategy for RPSFW—that wins. By this step, your system has four games it can play, and it should have become clear how to make your design cleaner, in part due to feedback from your friend.

Lastly, a Creativity Step requires you to report back on how you asked you friend for feedback on your game after completing one of the Steps, and what you did with the feedback. You can pick a friend yourself, or you can ind a friend through a posting on Ed Discussion. We simply ask that you report the UNI of the friend as part of your discussion, in addition to your report for this Step..

2.1    Step 1: RPS (30 points)

2.1.1    Speciication

For this Step, you start small, with a console application that uses text output and text input, and that just plays the original game of Rock, Paper, Scissors with a friend. The application should do something like the following.

A Talker class displays some welcome text that gives the rules of the game.  Then, for about 100 consecutive times or “rounds”, a Thinker class selects the computer’s own move, and them some class, maybe the Talker again, asks the friend for a single character from ’r’, ’p’, or ’s’ . When a valid character is thrown by the friend—you must design a loop to do sanity checking!— some class prints out a message indicating the computer’s throw and the friend’s throw, and who won, and why. Roughly, it says something like:  “I win!  My paper covers your rock!”.  Note that if a throw ends in a tie, the round must continue until there is a winner. Therefore, the number of throws is always greater or equal to the number of rounds.

Note that there for this game there will will need to be nine such messages—and in later Steps, there will be 25 such messages—so use some form of abstraction to simplify them. Note that there is a trade-off here between code and data, and the following table can give you an idea of (1) how to simplify your code by using a data structure instead of lengthy repetitive code, (2) how to localize the rules of the game in a compact form within a class, (3) how to allow for quick human visual checks, by other designers in a walk-through, for consistency of both data and code, and (4) how to anticipate “natural” extensions.

You should make this effort of abstraction now in Step 1, because the design will soon be expanded, and you will appreciate any advance thought that makes extension simple and easy. Not to put too ine a point on this, but if you have any nested long if-then-else statements, or more than one switch statement, you have probably missed an important abstraction.

See the data table for the game rules shown below. Note that it indicates that the game is fair, since each row sums to 0.  Also note that there appears to be some sort of diagonal structuring, particularly if one considers the table to “wrap around” from left-to-right and from top-to-bottom:

Friend

R  P  S

Computer R |  0 -1 +1

P | +1  0 -1

S | -1 +1  0

When a full game ends, a Reporter class computeshow many rounds of the game the computer won and how many the friend won, both as counts and as percentages.  This is then displayed, something like:

Friend

R    P   S  Tot

Computer R |   0 -15  19     4

P | 17   0 -13     4

S |-15  21   0     6

|

Tot |   2   6   6    14/100

To pull all your classes together, have a short, simple, solution- oriented Runner class, with a main() that is small in the amount of the code, but extensive in the Javadoc, which documents your system design.

Among other design issues, you probably should consider that the strings “rock”, “ paper”, and “scissors” have been determined by the real world, and, like the rules of the game, are simply not negotiable: you must use their names as given. These strings and the rules probably should be encapsulated together in a some class, maybe called Librarian or GameKeeper or Lawyer, etc..

Since the various input and output speciications are likely to change, make sure the Talker class design is extensible, even if there are no graphics involved. And make sure that it can handle sloppy or ignorant or malevolent inputs. And, eventhough the Thinker’s throws must be random in this Step, that strategy is certainly going to be augmented, so make the Thinker and GameKeeper class design extensible, too.

2.1.2    Deliverables

If you stop at this Step, turn in your *.java iles (generally, this means whatever classes you wrote in the Eclipse project), a sample run of at least a dozen rounds captured from the console output, and a summary table from a game of 100 rounds showing number of throws, wins, ties, losses, and totals, as above.

Submit them to the Assignments page of Courseworks. Remember to use the Javadoc conven- tions to properly document your classes, constructors, and methods, since a good part of your grade will depend on them. Do not use a README ile, since anything that would go in the README should go into the Runner class instead, where it is less likely to get lost or out of date.

Note that the functionality of this and every Step should be retained.  For example, if you do all four Steps, your system should be able to play all four different games with the appropriate strategy for each, at the request of the friend.

2.2    Step 2: RPSKL (7 points)

2.2.1    Speciication

This Step is intended to show by example that a well thought-out design should allow for relatively straightforward increases in functionality, without having to rewrite everything from scratch.

Simply extend you system to also play RPSKL, while also retaining the ability for a user to play RPS, at their option. This requires some extension to the Talker, at least..  To test this Step, you will again need to do about 100 rounds.

Here are rules for RPSKL:

Friend

R  P  S  K  L

Computer R |   0 -1 +1 -1 +1

P | +1  0 -1 +1 -1

S | -1 +1  0 -1 +1

K | +1 -1 +1  0 -1

L | -1 +1 -1 +1  0

2.2.2    Deliverables

If you stop at this Step, you must turn in the same kinds of things described at the end of Step 1, above:  *.java iles (with their Javadoc comments), for a System that does both Steps.  You only need to submit one trial run from either one of the two games, but you must submit two summary tables, one for each game of 100 rounds.

2.3    Step 3: RPSFW (7 points)

Do this once more for RPSFW, whose unusual rules are given below:

Friend

R  P  S  F  W

Computer R |   0 -1 +1 -1 +1

P | +1  0 -1 -1 +1

S | -1 +1  0 -1 +1

F | +1 +1 +1  0 -1

W | -1 -1 -1 +1  0

It is not hard to show that “random” play here does not mean that all ive characters should be played equally often.  Instead, it can shown that R,P, and S are each played 1/9 of the time, and F, W are each played 3/9 of the time.  One way to see this is if R,P,S,F,W were replaced with the values 1, 1, 1, 3, 3, then each weighted row sum still is equal to zero.  For example, the row for W becomes (1   — 1) + (1    — 1) + (1    — 1) + (3    +1) + (3   0) = 0. (See the Wikipedia article, or the journal article in Week 1 of Courseworks.) You will have to augment your Thinker as well as your Talker.

2.3.1    Deliverables

If you stop at this Step, you must turn in the same kinds of things described at the end of Step 2, above: *.java iles (with their Javadoc comments), for a system that does all three Steps. You only need to submit one trial run from anyone of the three games, but you must submit three summary tables, one for each game of 100 rounds..

2.4    Step 4: RPMFW (7 points)

One of the most unusual non-trivial balanced ive-gesture games has the following rules:

Friend

R  P  M  F  W

Computer R |   0 -1 +1 -1 +1

P | +1  0 -1 -1 +1

M | -1 +1  0  0  0

F | +1 +1  0  0 -1

W | -1 -1  0 +1  0

2.4.1    Speciication

Again, it is balanced, but weighted randomness is different. Again, it can be shown that R,P,M,F,W works for 1, 1, 1, 2, 2. still is equal to zero. For example, the row for W becomes (1    — 1) + (1    — 1) + (1   0) + (2   +1) + (2   0) = 0.

2.4.2    Deliverables

If you stop at this Step, you must turn in the same kinds of things described at the end of Step 3, above: *.java iles (with their Javadoc comments), for a system that does all fours Steps. You only need to submit one trial run from any one of the four games, but you must submit four summary tables, one for each game of 100 rounds..

2.5    Step 5: Creativity using user feedback (9 points)

2.5.1    Speciication

At the Step of your choice, you need to ask your friend to critique your system, so that it can be improved. You then report on:

1.  The UNI of your friend.

2.  The Step that you asked about.

3.  A list of the questions you asked.

4.  A corresponding list of the responses you received.

5.  A corresponding list of the decisions you made about the responses, including any changes you made to the system because of them.

This can be done completely off-line. If you want, you can have a Studier class ask some ixed questions and record the friends responses as (multiple choice, free text, etc.) but you will get no extra credit for automating this.

2.5.2    Deliverables

Provide the about ive parts as text. This part of the Step will graded by the CAs, just as the design, documentation, coding, and testing of the other Steps will be..

2.6    Some further notes on design, for background and hints

Note that by the end of this Programming Part, you should have experienced the ways in which good object-oriented design can make modifying systems easier.  And, it should be apparent that even if you had the luxury of perfectly knowing exactly what all the future enhancements of a system would be, this foreknowledge doesn’t by itself solve all of the design issues. You still have to carefully understand who does what, what the data structures and algorithms are, and how best to document and test your design.

On the engineering side, one way to evaluate how good your design is, is to ask if it could easily be extended further, in order to handle something like “RPS-7”, which is described and has a playable web version at:

https://www.geogebra.org/m/qjDh8qPx

or “RPS-25”, which is described at:

http://www.umop.com/rps25.htm

or even “RPS-101”, shown at [again, cut and past the URL]:

https://www.reddit.com/r/coolguides/comments/

e682uv/very_advanced_rock_paper_scissors/

If you really want to get into the game theory aspects of RPS++, note that the game in general must always have an odd number of characters, and that there are c(c —   1)/2 possible pair-wise outcomes, not counting ties.  That grows much too big to allow you to encode the rules as code, even for small c. For example, for RPS-25, there would be 300 rules, and for RPS-101, there would be 5,050 rules. For these kinds of problems, data clearly wins over code.

If you look closely at the diagram for the 25-character game, you should get a hint as to how to organize your data, even for the 5-character RPSKL case. It is unlikely that RPS-25 or RPS-101 were derived simply by trail and error; there is a pattern to them.

Also, if you look closely at the rules for RPSKL, the rules has ive 3-character games embedded within it: RPS, PSK, SKL, KLR, and LRP. The rules for RPSFW are a bit more challenging, but data is still better than long code. However, the rules for RPSFW have only four 3-character games embedded with in:  RPS itself, plus FWR, FWP, FWS. Likewise, RPMFW has only RPM, plus WFR, WFP. These observations can help guide the design of the code, and guide the trade-off between decisions made in code versus decisions made in data tables.

2.6.1    Additional resources for a user study

Although we won’t be doing formal user studies in this course, here are some of the questions that a formal user study or a beta test would seek to answer. But these questions can help as reminders even during early design when we are working alone.

a.  Are the initial instructions clear? How could they be improved?

b.  Does the required interaction at each round proceed smoothly? How could it be improved?

c.  Does the user make any comments to the designer of surprise or anger?  About what and why?

d.  Does the user ask the designer for additional functionality in the user interface or in the system performance?

e.  Do the summary statistics appear accurate? Informative?

f.  What grade (A through F) does the user give the system overall?

2.6.2    Additional resources: game history, culture, and hints

Here are some additional aids to understanding the real-world problem you are solving.  You can skip over them if you are in a hurry, but they can give some practical insights.

For RPS    We assume that you come from a culture that has some variant of RPS, which you learned relatively early in life.  As you can easily verify, the game is both old and pervasive.  But for some interesting commentary, see:

https://www.youtube.com/watch?v=rudzYPHuewc

Which was anticipated by:

https://www.youtube.com/watch?v=rMz7JBRbmNo

Just to bring this all into the real world, see the following article, which showshow this “game” has life and death consequences, at least for some lizards. We won’t be using this resource, but it is  fascinating nonetheless—and the text of the article’s abstract even starts with Java’s favorite word,  “polymorphism”! Use your browser to search for the word “orange” to get to their algorithm, at:

http://www.pnas.org/content/107/9/4254.full

To see a detailed user study on human experiences with RPS, and some AI strategies that are based on actual human competitions offering prize money, see [you will have to cut and paste the two halves of the URL together]::

https://arstechnica.com/science/2014/05/

win-at-rock-paper-scissors-by-knowing-thy-opponent

The original published paper that studied human performance (it is a bit heavy going—it even uses the mathematics of inverse cosine function) is at:

https://arxiv.org/pdf/1404.5199.pdf

A very recent, more down-home article, which makes claims about gender differences among players, is at:

https://www.wikihow.com/Win-at-Rock,-Paper,-Scissors

For RPSKL    For a quick summary of the rules of RPSKL, see:

https://www.youtube.com/watch?v=x5Q6-wMx-K8

A more formal presentation is by its creator, at:

http://www.samkass.com/theories/RPSSL.html

A game which is really just RPSKL but renamed for pirates(!) can be found at:

https://markarayner.com/how-to-play-monkey-robot-pirate-ninja-zombie/

For RPSFW    For an example of RPSFW in the popular culture, see:

https://www.youtube.com/watch?v=lMCE2cvR7tg

For a written exposition on both RPSKL and RPSFW, see:

https://en.wikipedia.org/wiki/Rock_paper_scissors#Additional_weapons

For RPMFW    For RPMFW, see the analysis paper on Courseworks > Files > Week  1:  g, en- titled, “Towards a Framework for Management of Strategic Interaction”.  It is not a well-written paper, but it makes some interesting theorems, namely that there are only four (out of 582!) non- trivial balanced ive-gesture RPS-like games

2.6.3    Some inal preparatory comments

a.  If you read ahead through all the Steps of this assignment, you can have an unfair advantage over real world designers, in that you will be able to see the future of your product perfectly. But the system is complex enough that it will be should be easier to follow the steps in order, anyway.

b.  Note that the friend doing the testing can be someone who is also taking the course, since, generally speaking, testing someone else’s code is not considered to be dishonesty.   Of course, there is no good way for the instructional staff to verify that you actually did any testing with a friend. But why cheat yourself out of this college learning experience?  They will remember you for life.

c.  Please remember:  it is always preferred to have a saved version of a working system that does only some things well, rather than to have a non-working system that has tried to do everything at once. Eclipse can help with this; look up its “local history” feature.  We will enforce this preference by requiring that all submitted programs must at least compile!

3    General Notes

For each Step, design and document the system, text edit its components into iles, compile them, debug them, and execute them on your own test data.  When you are ready, submit the text of its code, a copy of your testing, and whatever additional documentation is required.  Make sure that the source code is clear and its user interface is comprehensive and informative.

Write your classes clearly, with a large block comment at the beginning describing what the class does, how it does it, and justify how it will be tested. Clear programming style will account for a substantial portion of your grade for both the Theory Part and the Programming Part of this assignment. Use the suggestions from Clean Code. For a related series of suggested practices and stylistic guidelines, see the website of a popular textbook sometimes used in COMS W1004, at:

http://horstmann.com/bigj/style.html

Remember that human designers, documenters, coders, and testers are limited in their abilities to understand something new, and that it is important to stay short, simple, searchable, solution- oriented, and standard. Be clean, be consistent.

4    Checklist

Here is an approximate checklist for submission. Please note that this is designed to be a general guide, and you are responsible for all things asked for in the text of the assignment above, whether or not they appear below.