Project 2

Our goal for project 2 is to allow your group to do more design exploration. In project 1, we gave you the design, for the most part, as an MVC architecture. In this project, we are not going to hold you to any specific architecture. It will be up to your group to choose an architecture and then implement a system from it. At the same time, it is not practical to start a whole new problem given the short time we have in the quarter. Hence, we will build on the ideas we studied in project 1.

We want your group to build a GoMoku game server. The idea is that player clients will play a game by interacting through the game server. In some ways, this is not much different than project 1. However, it is different in the following ways:

1. Clients can be remote. The client process can run on any machine that has at least intermittent Internet connectivity. The client will interact with the server over the Internet.
2. While clients can be computer-based players, we want to see at least one client that allows a human to play the game, i.e., the client presents a user with a GUI that allows the user to make moves and see the state of the game. An actual game can include any two combinations of computer-based and human players.
3. We are less concerned with bad behavior in project 2. While we expect that you carry over the anti-cheating mechanisms you developed for project 1, we do not expect you to catch the new types of cheating behavior brought about by moving to a client-server architecture.
4. We will not promote plug-and-play between groups. Unlike project 1, we do not expect that we can take pieces from group k and integrate them with group k+1.
5. We expect you to refactor project 1 code that you use. Your group has seen (and 422 staff have mentioned) the problems with the project 1 design. Refactor to get rid of them. In particular, you can assume that your design is only for GoMoku. You do not need to worry about designing a system that will play any board game. This should lead to a simplification of the project1 design.

These are the basic requirements. There are also a set of optional pieces that you can use to help boost your group score. We will discuss those later.

Your group has the freedom/obligation to come up with a client-server design. You can use (and are encouraged to use) as much of your project 1 code as you like. But we expect you to refactor for this new project. The architecture that you choose and the refactoring you do is a group decision and will not be made by 422 staff for you.

We are going to propose three basic communication alternatives for your design. If you decide to use something else, see Ted or Steve first to get an OK. We discussed the pluses and minuses of each of these in class on Tuesday so look back at your notes. You should be able to find plenty of tutorials and reference material on each of these on the web. If you find example code you can use on the web, feel free. I have books for short-term loan on each of these as well.

1. Raw sockets.
2. HyperText Transfer Protocol (HTTP), the protocol used for Web pages.
3. Java Remote Method Invocation (RMI).

Your very first group meetings should focus on design. It is critical that you work out which options you will choose and then how you will attack the implementation. If you do not do this as a group, chaos will reign. You will not have buy-off from each group member and they will go their separate ways. There will be no set of interfaces or standards provided by 422 staff to keep everyone in line (as there was in project 1).

You are welcome to choose the project 1 parts you reuse from other groups! We will make a separate directory structure under project1 that has a read-only version of each group's project 1 results. You are free to browse these directories and copy any of the project 1 code you want into your group's directory. However, we do not expect another group to give you tech support - you take the code as is and do not bother them with questions. This entire step is optional - you are not required to reuse project 1 code, whether it be your own group's code or some other group's code. Up to you.

Your group will not be allowed to work with other groups on project 2. We want to see that all of a group's work is their own. Neither ask another group for help nor borrow ideas or code from them (beyond what we give you for project 1 results).

It is up to your group to decide when to refactor. Refactoring involves rethinking a design once you have some experience with it. There's some discussion of it on pp. 76-78 of the optional extreme programming text as well as at the Extreme Programming Web site. You saw us (422 staff) do small refactoring during project 1 as we discovered flaws in our original design. Your group will now have to make these decisions, and they are often difficult to make. Again, if you don't work as a group, refactoring is not really an option for you: you need the whole group together to buy-off on a redesign just as you do on the initial design.

We will accept these as components that will increase your group grade.

1. A Palm client. We almost made this required instead of optional given the nature of the CS field today. We believe it would be highly desirable for you to get some PDA programming experience on your resume. To that end, we have done the following to help you if you decide to take this on. First, we have setup a web page describing how to program in Java for a Palm Pilot (and like devices). This page was built after 422 staff (Brad, in particular) built a java client for GoMoku for the Palm. So it reflects his experience and frustration in getting it all to work. The cool part is that the development software includes a Palm simulator so that all coding can be done on any platform that supports the Java 2 Micro Edition (J2ME). The J2ME is a version of Java which works in potentially less memory and has a smaller set of standard classes than the Java 2 Standard Edition (J2SE) you have worked with so far. Note that the J2ME has a completely different set of user interface classes---it does not use either AWT or Swing.

Second, we have placed a J2ME book as optional at the bookstore. This is currently the first and only book out for J2ME programming. However, you might wait to buy it - first decide if you will take on the project and then whether the web site is not enough. It does have a TicTacToe GUI!

Third, we talked Handspring into donating 16 Visors to the department for this class. The Visor is a fancier Palm-like PDA. I will check a visor out to any group that wants to play with it. In essence, once you get your client running on the simulator, you can try it on the real thing.

If you decide that you might want to try the Palm-client option, it might affect your early design decisions. In particular, the Visors do not have an Internet card. They make such cards - we just did not get them donated L. However, the simulator will simulate an Internet connection so you can pretend as if the device does have socket style connectivity. You just can't move that to the real device. Sorry. The Visor does have a hot-synch cable that allows serial IO. Talk to us about this if your group needs further info. We will accept a simulator-only client or a real-device client as turn-in for this option.

By the way: While J2ME does not support RMI, others claim to support Java Message Service (JMS-http://java.sun.com/jms/) on the Palm. But we have not tried this route. Buyer beware. Here is the paper: http://www.softwired-inc.com/pdf/products/MobileMiddlewareJuly2000.pdf.

2. A full function GUI that allows a user to make hypothetical moves, get critiques of those moves (before committing to them), and gives advice about the next best move. In essence, this uses a good player from project 1 as a critic or coach for the human player. This can be done through a regular (non-Palm) client. It will give you a bit more Swing practice. More credit if you get it working on a Palm client.

Project 2 will be similar to project 1 in that each group meets with a GTF weekly. As before, full attendance by group members is expected and absences will be noted. A difference in project 2 is that we expect that the first couple of meetings to focus on risk analysis and design. This is your group's chance to sit down and think about design and what you will commit to.

However, we do not rule out some coding. In particular, we want to see some "spike solutions" from your group by week 7. A spike solution is essentially a little program written to get a handle on the difficulty of using a technology/design. Just to get you started on this, the GTFs will expect to see in week 7 that your group has implemented a prime server using whatever technology you have chosen. The prime server is a process that will give you the next prime if you send it a place to start the search. The heart of the server is the NextPrime class with a method nextOne that takes a BigInteger as an argument and returns a BigInteger as result.

class NextPrime {

   public static BigInteger nextOne( BigInteger start ){


      BigInteger zero = BigInteger.ZERO;

      BigInteger one = BigInteger.ONE;

      BigInteger two = new BigInteger( "2" );


      if( start.mod( two ).equals( zero ) )

         start = start.add( one );          //only search odds


      while( !start.isProbablePrime( 5 ) )

         start = start.add( two );


      return start;


   } //nextOne


} //NextPrime

The server will not maintain a connection: once it gives you an answer, it drops the connection. So it is a bit like an http request. It is also like http in that it does not need to maintain state - it expects the starting number to come in from the client.

If you are working with sockets on this exercise, then you need a prime server running on some port. You also need a client that will connect to that port, pass the starting number and get back the prime. The client can simply do an SOP of result. You can choose to pass strings (easy to translate to/from BigIntegers) or serialized objects (closer to what you might be passing in your game).

If you are working with RMI, then you basically write your "server" as a class that invokes nextOne directly. In reality, the server should sit on one machine and the NextPrime class on another. The hard part is getting RMI setup so this all looks like simple method calls.

If you are using http, you will have a process running on the server side that will use NextPrime to return a value. Arguments will likely come through using cgi style format. If you want to get fancy, you can explore using a servlet process instead of a straight cgi solution, but that is optional. The client process should be a java program you write, not a browser nor an applet. You are free to use built-in http classes in your client.

Big caveat: if your group is committed at this point to trying a J2ME client, you might want to do some research on what is supported on the Palm. In fact, you might want to try to build a client on the Palm simulator. This is clearly more work, but will give you a better feel for how hard it is going to be down the road to build a GoMoku client on the Palm. That is the whole point of this early exercise - get a better handle on the risks of the larger project.

Big hint: pair-programming should really be useful in this exercise. One person can be reading documentation while other codes.

Evidence that group is progressing on design choice. This might include:

1. Risk assessment
2. Diagrams of various designs (see chapter 7)
3. Start on prime server exercise (or completion of it).

Note that this requires that your group keep a record of your design meetings. We want to see that you thought about different options and rated them, not simply that you chose design X and that is all you have to show.

We expect by week 7 that you have chosen a design and are finished with the prime server. Using the experience of building the prime server, we would like to see you present both a class diagram and a set of sequence diagrams (both UML based). These can be drawn on paper. For the sequence diagram, we want to see at least the following:

1. A scenario that shows the normal turn of a client, starting with the server noting that it is a client's turn, and ending with the client sending in a legal move.
2. A scenario that shows the handoff of turn to the other client. It starts with one client submitting a legal move, and ends when the other client is told that it is its turn.

Optional error scenarios will be helpful in getting your group to think through a design, but are not necessary at this meeting.

We also want to see a project plan that lists the major tasks that must be completed and your current estimates of when they will be completed. Include the times necessary to research any new technologies that you are using, e.g., RMI, Swing, etc. The plan does not need to have people assigned to tasks.

Unlike project 1, we will not try to dictate exact classes what we expect to see in subsequent meetings. We can’t - you are doing your own thing. However, we can check to see if you are making progress against your plan (see week 7). And we do expect to see Junit tests developed along with code.

GTFs will expect that certain pieces of your design can be demoed: they will assume that your group is using incremental development as opposed to everyone go off for 4 weeks and work and then try to pull it together in week 10 (never will happen). You should always have some piece of functionality to show them, not just long code listings.

GTFs know that you may decide to refactor once you have some experience trying to implement a design. They will look for a revision in your project plans that reflects the changes to the original design.

The GTFs will expect to see enough pieces in place to complete the project by the deadline.

• How much functionality you attempted in your design. The client-server architecture you used and its generality (how easily could it be extended to other platforms, other games, etc.). Do you support multiple simultaneous games? Multiple servers?
• How completely and robustly that functionality was implemented. Does it handle common error conditions? Uncommon ones?

While we encourage teams to use the Gang Of Four (GOF) state pattern within their system, it is not required.

Several teams have asked about Junit testing. We believe that regression testing is an important part of any real-world software project. Unfortunately, the Junit framework is not well-suited to testing client-server architectures. In an industrial context it would be well worth your team's time to develop a better test harness for client-server systems. Due to the tight time frame of this project we will not require this, but we will offer optional credit for a testing framework (see below).

The optional parts of the project will also be graded according to design and implementation. The following give some general ranges:

• Greater GUI functionality (up to 15%) This can take many forms: Allow replay of moves so far in the game, suggest moves for the user, configure the clients (selecting a server, choosing whether to be first or second player), explanatory dialogs when network connections fail, selecting possible computer-based opponents (this will require code on the server side as well), plus others you might design. We'll grade based upon how appropriately you use the GUI features, rather than how many you use.
• Dropped connections (up to 5%) In a wireless environment, systems should be prepared for dropped connections. The client should be able to provide identification (how?) and resume an interrupted game.
• KVM (up to 10%) Your clients running on the Solaris simulator of a Palm machine.
• Visor PDA (up to 5%, in addition to credit for the KVM) Your clients running on the actual Visor (or one of your personal Palms).
• Testing harness (up to 5%) A test harness that tests the client-server protocol in a repeatable fashion. This could test exceptional cases in your protocol such as three clients signing on, a client signing on twice, and so forth, or it could test exceptions in the underlying transport layer such as the client not finding the server or the client losing its connection to the server.