2 —
Due Wednesday, 25 September 2024, 11:59:59pm
Purpose This milestone has two goals:
T to start building a system from bottom up so that each piece can be tested before it is integrated with others; and
S to practice socially responsible software development with an easy task.
Despite the popularity of “agile” development processes and “code first” (aka “extreme programming”) approaches to system development, someone has a rough global design and development plan in mind before it all begins. (It just may not be written down, which is actually a problem.) This “global” view of the project is from the “top down.”
No matter what, though, the actual construction of a software system proceeds from the most basic, “bottom-most” pieces “up.” When developers integrate different components, they encounter two kinds of problems: (1) a mismatch of API assumptions and (2) logical mistakes in the components. The second one of them is easily reduced to a “almost no problem” status with unit testing. Integration testing will reveal mistakes of the first kind and subtle, difficult-to-understand of the second kind that span components.
Delivery Place the product of this week’s milestone into your git repo as follows:
Create a repo-level directory called Bazzar Bazaar and, inside this folder, created two sub-directories: Bazzar Bazaar/Common/ and Planning.
for the Programming Task, place equations.PP and cards.PP into Bazzar Bazaar/Common/, because both our referee and our players can use this common component.
Here .PP stands for a language-specific suffix, which depends on your choice of TAHBPL. Some languages demand a specific organization within the file system. In that case, you may place a link to the proper equations.PP into Common/.
If your equations representation calls for additional data representations that you would prefer to place into different files, place the files (and links) into Bazzar Bazaar/Common/.
for the Design Task, place game-state.md into the Planning/ folder so that you can reflect on your planning ideas and failures at the end of the semester.
creating a table of equations;
filtering the table of equations according to whether a player can use them to trade with its pebbles;
rendering the table of equations graphically;
creating cards;
determining whether a player can acquire a card with its pebbles;
rendering cards graphically.
Design Task The referee is a mechanism that acts according to a book of rules and the state of the games. That is, the state of the game is the referee’s knowledge about the game that enables it to grant turns, decide the validity of actions, and announce the end of the game and its outcome to every participant.
Design a data representation for the game state. List all pieces of functionality that should be available to the referee to run a game.
To describe the data representation, mix English and references to the data sub-language of your chosen programming language. For the operations, choose the wish list format that you got to know in Fundamentals I and Fundamentals II, depending on which of the languages used in these courses matches your chosen language most closely. Distinguish the two parts clearly.
The memo should not exceed a page. Less is more.
Keep in mind our Bazaar.Com, a Plan while you work on a design task.
You do not need to read the rest of this page if you recall the notion of “design and implement” from Fundamentals I through III.
To design means to turn the information in the real world into a data
representation—
Design also means to think about what other components will want to know about
this information or perhaps represent a change over time. To this end, you are
to come up with a list of functionality—
The referee is an example of implicit functionality. When a group of us sits around a kitchen table to play Q, we collectively play referee. A software system cannot keep such functionality implicit; ideally, it must be open to audits in case of law suits.
To implement is to systematically turn the wish list of functionality into an implementation of functions and methods. Since this milestone it is about the design of a component, it also means to make some of these functions and methods public and keeping all helpers private. Use your chosen language well.
The entire point of proceeding systematically is to accommodate
change. It is unlikely that anyone’s first design and implementation of the
equations is perfect. A good intuition will go a long way to finish most of the
needed work this week, but “easy change” is the name of the software
game—
At Northeastern, we teach “systematic” from week 2 in the undergraduate curriculum. Follow these principles and you will be able to manage your time this semester