Assignment #2 Design: Connect Four

Due: in class on or before Tuesday, November 19th

No late work will be accepted for a grade.

Overview:

Summary of what the design part is about.

Description

The design part of the assignment requires you to create several documents that will help prepare you for your implementation of the program Connect Four.

Required Reading

Required readings: Assignment 2 web page, syllabus readings through Chapter 9

Goals:

What do we plan to gain from this?

· Experience: You will gain experience with the analysis and design phases of the software life cycle.

· Preparation: You will accomplish the necessary steps to prepare you for the implementation of the program.

· Practice: After completing Assignment 2, you should now have a better understanding of what is needed for a good program design. In this project you will put into practice what you've learned.

Analysis and Design:

What Is Programming Really Like?

Analysis, and Requirements Specifications Realities

When computer programmers are handed projects, they are usually given in the form of a requirements specification. This document supposedly accounts for the complete behavior of whatever it is that someone want for you to write. How you write it is generally up to you, as long as it follows the specifications.

Although being given a complete requirements specification would be nice, this is almost never the case. Typically, these will be at some high level which makes sense to some employer of yours, but to you it may seem extremely vague, and not detailed enough to know when or how to properly handle all decisions.

Therefore, the first step in analysis for most computer programmers is to look at your given requirements specifications and attempt to make them complete. This often involves either going back to your employers and asking them clarify something for you, or making an educated decision on your own about how you think, as the programming expert, the ambiguity should be handled and why.

Design, and Why It Is Hard

The realities of programming are that most programmers spend most of their time either designing or debugging their programs. A detailed, well thought out design often avoids a long and difficult debugging process. Inversely, a poor design that doesn’t consider specific issues will lead to enormous debugging and recoding times. Design is hard because essentially it amounts to planning, and any connect four player will tell you that, while planning far ahead is difficult, the farther ahead you plan, the better your results will be.

A large part of part of design is choosing your data representation. Perhaps the most obvious choice in this Connect Four game is to decide how best to represent your Connect Four playing chips. Should you use a primitive or an object reference type? There’s no correct answer. It’s a design decision that will be up to you. But it is a decision that will fundamentally change some aspects of your program. While too many objects can make a program very complicated very quickly, too few objects leaves too much work to be done by each, and each object you have will become confusing very quickly.

It will be entirely up to you in this assignment to choose, given the type of data you need to represent and how that data needs to be manipulated, the best representation (what objects) for this assignment.

Design is Hard. Take time to do this part well.

Requirements:

The Assignment 2 web page provides a partially complete requirements specification. There are details that haven't been specified, and it is your responsibility to clarify these details during your analysis of the programming project.

· Create a document that completes the requirements specifications.

Indicates any of the given specifications that are unclear, incomplete, inconsistent, or ambiguous, and tell us how you plan to resolve it.

Design your classes/objects, and show how they work together to solve the problem.

· Create a design document for each class that you need to fulfill the requirements of Assignment 2.

You need to have a design document for each class that you create as well as one for the main program. For each class, tell us what high-level role they serve in your program. Page 260 of the text illustrates a program design document. Pages 262-263 illustrate a class design document. Do not use any GUI components such as javabook2 classes, file dialogs, or other graphical user interface classes. Do not use the Vector class.

· Create as many object interaction diagrams as you need to indicates the interaction between the objects in your program.

Pages 169 and 261 of the text illustrate interaction diagrams. Really, these should border on memory diagrams. Here’s what we want to know: What, at any given moment in your program, can we expect your program to “look like”? What objects, and how many, do you have? What information are they holding, and what, generally are they doing? What objects are in control?

This may mean multiple object interaction diagrams if you need to communicate stages or aspects of your program that are separate, or perhaps complex object ownership diagrams. Since your program must use provided classes as well as your own, make sure to include all necessary objects. Show us exactly how the objects you described in your design documents are going to “fit together”.

Incremental development.

· Create an implementation document that outlines the incremental steps you will take to implement your program.

Pages 172 and 260 show examples of incremental development steps.

Consider your program’s flow control diagram. Tell us what pathways in that diagram you are going to complete first, second, third, and so on. Saying that you are going to write each class, and then make it all work WILL NOT COUNT!!!

We recommend either a top-down approach (starting with the most outer loops and working inwards) or a bottom-up approach (starting with the most inner paths and working outwards), or some combination of both and meeting somewhere in the middle. In general, the middle is not a good place to start, though it can be done.

Hand-in Requirements:

Hand in a hardcopy (i.e. on paper and typed if you have poor handwriting) of the following documents:

· Unclear Specifications Document

· Program Design Document

· Class Design Documents

· Object Interaction Diagrams

· Implementation Steps Outline

Solution

No solution will be provided for the design. Back to Top