## Introduction

Harvey Mudd’s MyCS program is designed to introduce students in middle school and early high school to topics in computer science. As HMC Computer Science professors have been teaching students and advising teachers on teaching the material, one topic that has stood out is the concept of binary numbers. As students are not fully taught ‘positional arithmetic’ when learning the decimal system, it is difficult for them to understand what digits in a binary number represent. Positional arithmetic emphasizes the value that each digit represents in a given number. In order to aid teachers as they teach binary numbers to their students, MyCS professors and teachers have conceptualized a game that would reinforce the concept of positional arithmetic while allowing the students to practice converting binary numbers into decimal numbers. Robyn Herbig, a teacher in a school participating in the MyCS program, will serve as a representative to the HMC team that will be designing the game.

## Agenda for the Review

To be discussed with the other team's review leader.

• Andrew (and maybe someone else?) yells at us for doing silly coding stuff.
• One person takes a look at the Proposal and see if there might be something we're not thinking of that would be helpful to have
• One person tries out the prototype (need to install pygame)

Priorities

• Do the classes and class organizations make sense?
• Are there any tools that we are not using that would make our lives easier?
• Does our code make sense to people from another team?

Classes for our initial design can be seen here.

Our class diagram is displayed below:

## Architecture Critiques

Our architecture begins with the EventHandler, which interprets user input and other events and doles out responsibilities accordingly. EventHandler hosts the only instance of our Graphics class, which is responsible for drawing everything. Objects do not know how to draw themselves - instead, they know only enough information (generally position, size, and image) about themselves that when Graphics attempts to render the items on a surface, it can easily query the items themselves for the requisite information and draw accordingly. Because of this, updating the screen is a simple process contained almost entirely in Graphics.

EventHandler has two modes - MENU, and GAME. These modes correspond to the MenuHandler and Game classes, through which all menu- or game-related information and functions can be accessed. MenuHandler is responsible for keeping track of the different MenuPages (which, in turn, keep track of their buttons and other elements) and it possesses the functionality to swap between them, though it will only do so at the request of EventHandler. This is a prime example of the general principle underlying our architecture: EventHandler looks at what’s going on, gathers information from the other classes, then hands down orders.

## Rationale of Choices

We decided to implement our architecture in this way because it’s an easy-to-use and intuitive design. The chain-of-command is consistent and allows us to keep track of what’s going on, since every command originates somewhere in EventHandler. The other classes are essentially just helper functions that carry out the wishes of the EventHandler. One of the main downsides of this decision is that information must be passed around a lot, and it is common to end up with lengthy constructions such as “self.eventHandler.menuHandler.menuPage.menuButton.” However, we believe the benefits of having a centralized command center doling out orders outweigh that inconvenience.