Course:
CMSC 435
Classroom Building 102
Tuesday, Thursday 2-3:15pm
http://www.cs.umd.edu/~bederson/classes/cmsc435/
3171 A.V. Williams Building
Office Hours: Tue, Thur: 3:30pm – 4:30pm
bederson@cs.umd.edu
UML Distilled: Applying the Standard Object Modeling Language Fowler and Scott [Addison-Wesley], 1997.
Code Complete: A Practical Handbook of Software Construction McConnell [Microsoft Press], 1993.
Close to the Machine: Technophilia and Its Discontents Ullmann [City Lights Books], 1997.
Java in a Nutshell, 2nd Edition Flanagan [O’Reilly], 1997.
This is a development course, and as such, you must be prepared to do substantial object-oriented programming. You must do all programming in Java. To take this course, you should be an accomplished C++ or Java programmer, and you must have a good understanding of basic object-oriented programming techniques. You do not have to know Java to take this course, but if you don’t, then you must be prepared to learn Java on your own. We will spend a little time in class learning Java – but it will be largely your responsibility to learn Java. You must have a grade of C or better in CMSC 420 - Data Structures.
Homework
Most homework will be related to the course project described below. There will also be substantial reading assignments and occasional other exercises, including on-line discussions. There will be assignment writeups for each step of the project. There will also be in-class presentations.
For each written assignment, 3 days before the due date, you will be required to put a draft of your document on the web for other class members to read. Each group will be assigned to review another group’s document, and give them written feedback (with a copy to me) within 24 hours. Each group will then have 2 days to revise their document based on their peer’s comments, and turn in the final document to me on the assigned day.
A significant part of the course will involve your participation. Classes will frequently involve discussion and exercises in addition to lectures. The course will also maintain electronic discussions outside of class. Students will be required to participate in these electronic discussions. We will discuss most of "Code Complete" online, and will also discuss the online newsletter, comp.risks. You must read comp.risks, either as a newsgroup or email. Subscription information follows (from the newsgroup). I will not calculate your participation grade as a direct result of the number of electronic postings your make, or the number of lines in your postings. Rather, I will generally watch your effort and participation - as I will do to evaluate your in-class participation.
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
Group Project
The class will be divided into groups of 3–5 people. The groups will be formed near the beginning of the course, and will be kept throughout the semester. Aside from exceptional circumstances, the members of the group can not be switched.
However, if a student is not actively participating in their group, they can be removed from their group. Before this can happen, the group must make their concern made to the student in question several times. Then, I must be notified about the difficulty. If after these repeated efforts, the student still is not actively participating in a group, they will be removed from the group and will have to work on an assignment on their own.
Each group will define the details of their own project, and will then implement it. Each group must implement one of the following projects which will be defined in more detail when we break up into groups in the 3rd week of class:
Shared HTML Text Editor
A Rich Text Object (RTO) is the basic data structure that stores a document with multiple fonts and embedded images. Chapter 2 of "Design Patterns" describes many of the issues and a potential design for a RTO. This project is to create a shared HTML text editor using an RTO structure. Most text editors are implemented with some kind of RTO. A text editor has internal data structures for the RTO, and some external file format. You must use HTML as your external file format. This means that the files you create will be readable in any Web browser. In addition, your editor must allow shared editing over the network with any other person using your software. This means that each user editing a document will see the other’s actions, and will see the updates of the other in real-time.
You will have to decide how to implement sharing, and at what level (if any) you want to implement locking. You must decide upon the protocol for sending document state and changes to the other editors, etc. You will have to decide on the interface for accessing shared documents, and the visual interface for depicting the interactions of the other users. You may want to look at the Java "swing" text object that is being defined in the beta JDK-1.2. While this is a good example of an RTO, it has many more features than you are required to implement for this project. In addition, it does not have any support for shared editing.
Shared Asteroids Game
You must write a networked version of the traditional Asteroids video game. This project must be written as a Java applet so that anyone can play your game within their Web browser (supporting Java-1.1). In addition to all the features of the standard Asteroids game, you must support multiple remote players. You can define the rules of remote play, but they must include at least the ability to simultaneously play in either cooperative or competitive modes in real-time. You are free to add extra features, but must include the basics which are: sound, flying ship with bullets limited in number available at a time and range, asteroids that break up into smaller asteroids, different kinds of enemy ships with different levels of "smarts", special bonuses that allow friction for your ship, longer range bullets, unlimited number of simultaneous bullets, and bonus points. Finally, you must support multiple levels of play that get progressively harder.
Animated Presentation Tool for "Revising Prose"
This project is to write an educational tool for teaching English writing style. Richard Lanham created a video called Revising Prose (RP) for teaching English writing style to college freshman that was used widely in California for decades. This video shows complex and simplified sentence construction, and brings the content alive by animating the text with sound. This project is to write (in applet form) a computerized version of RP. The goal is to write a general purpose animation program that reads in a data file and shows the sentences before and after construction. The entire content of RP must be made available with narration in either continuous or user-controlled form. I.e., you should offer a table of contents so that users can jump to any part – or see the entire contents as if it were a video. For each sentence, three forms of comparing the before and after sentences must be made available. They are: 1) Side by side display of the two sentences; 2) Animated transition of the sentences as in the video; 3) Use of a "lens" that the user can drag over the original sentence to see the resulting sentence. The program must be written in a completely general-purpose style that has no knowledge of the specific content. You must define a data file format that marks up the sentences with appropriate meta-information so that your program can create the three displays. You may define extra information in your data file so that you can specify aspects of the animation (such as color, sounds, animation paths, etc.) I will show part of the "Revising Prose" video in class, and discuss this in more detail in light of the video. At the end of the semester, we will show your project to Richard Lanham and get his feedback.
More details about each project will be discussed in class. Each group should set up (at least) weekly meetings that all members can attend. It is crucial that group members stay in close contact throughout the semester. While everybody has circumstances that prevent them from attending every meeting, if you can't attend a meeting, you should make every effort to let the other group members know in advance. You must keep an attendance log of all group meetings and turn it in at the end of the semester. The log should contain the date, the topic(s) discussed, the attendees, and a note if any members didn't show but let people know in advance. Consider making one person in charge of the meeting log.
Machines
Your ust write your group project in Java, and may use any machine you like. You can get WAM or GLUE accounts on campus if you want to do your development on Unix. Or if every member of your group has a PC, and you want to use a PC development environment, you are welcome to use that. Note that in this case, the group members are responsible for getting their own development software, and there is no on-campus support for your machines.
Software
There are two primary Java development environments. The first is to use Sun’s JDK which is available on Windows, Linux, and UMD Solaris machines for free. It is available on the class account you will receive. You also can download JDK-1.1 for your own machine at http://www.javasoft.com. If you use the JDK, you can use any text editor you like, although I strongly recommend using Emacs. If you haven't learned emacs before, consider spending some time at the beginning of the course learning it. There is a version called xemacs (on unix) that embeds emacs in a simple graphical user interface so you can slowly learn many of the commands.
Alternatively, you can use one of several commercial Java development environments. Microsoft’s J++ is now available for free at http://msdn.microsoft.com/visualj in beta form. There is also another development environment available from Symantec that must be purchased. You can see that at http://www.symantec.com/domain/cafe/vc4java.html .
Writing
This course involves a lot of writing. You are not being graded directly on your writing style, but good writing usually conveys ideas more clearly than poor writing, and the process of writing down your thoughts often helps to clarify them. Thus it is to your advantage to make the effort to organize your thoughts and write well.
Each document is to have one (not five!) editors, and each group member must edit one of the documents. Let us be very clear about what it means to edit a document. The editor has the final responsibility for turning in the document, sets deadlines for what the other members are to write, and may have to apply pressure to the other group members to do their part unless you have another manager for this. Every assignment should end with attributions. Specify who was the editor, who wrote each section, and reference any outside people or articles that helped you.
Grading
The course will largely consist of your group project. Components of the project will be due on an ongoing basis. There will be papers due, presentations made, and demos given. In addition, there may be occasional other individual assignments. There will be no exams. Due to the nature of group projects, it can be difficult to evaluate individuals. One of the mechanisms I will use is to have each student submit private descriptions of what each group member did on each assignment.
All assignments are due at the beginning of the class on the day that they are due. The paper part must be turned in at class, and the electronic part must be submitted by the time of the beginning of class. Late assignments will be strictly penalized. Exceptional circumstances will be considered only if discussed with me in advance. All late assignments will have points deducted as follows:
-20% Up to 24 hours late
-50% Up to 48 hours late
-100% More than 48 hours late
Your final grade will be computed using the following contributions:
10% Participation (in-class and on-line)
10% Misc assignments
10% Functional Specification
5% Social Impact Statement
10% Design Specification
5% Test Plan
50% Final project, in-class presentation, and final writeup
CMSC 435
Fall 1998
Prof. Ben Bederson
(1)
Sep 1 Sep 3
|
Introduction
To Course
Brief introduction to Java Read: Code Complete Ch. 1,2 |
(9)
Oct 27 Oct 29 |
Programming
Tools - CVS and Debuggers
Read: Patterns, Ch. 4 Adapter, Composite, Flyweight Read: Code Complete Ch. 17,18 |
(2)
Sep 8 Sep 10
|
Software
Engineering process
Working in groups Read: Code Complete Ch. 3,4 |
(10)
Nov 3 Nov 5 |
Testing
11/5: Test plan due, Read: Patterns, Ch. 5 Command, Interpreter, Iterator, State Read: Code Complete Ch. 19,20 |
(3)
Sep 15 Sep 17
|
Software
requirements analysis
Form groups Read: Code Complete Ch. 5,6 |
(11)
Nov 10 Nov 12 |
Project
Design & Implementation
11/12: Code midpoint status report due Read: Code Complete Ch. 21,22, 23 |
(4)
Sep 22 Sep 24
|
User Interface,
error handling
Read : Patterns Ch. 1, 2 Read: Code Complete Ch. 7,8 |
(12)
Nov 17 Nov 19 |
Project
Design & Implementation
Read: Handout on Intellecutal Property Read: Code Complete Ch. 24, 25, 26 |
(5)
Sep 29 Oct 1
|
Social aspects,
risks
10/1: Functional requirements due Read: Patterns Ch. 3 Read: Code Complete Ch. 9,10 |
(13)
Nov 24 |
Social Issues
Read: Close to the Machine 1st half Read: Code Complete Ch. 27, 28 |
(6)
Oct 6 Oct 8
|
Scheduling,
Abstraction in design
10/8: Social Impact Statement due Read: UML, Ch. 4, 5 Read: Code Complete Ch. 11,12 |
(14)
Dec 1 Dec 3 |
Social Issues
Read: Closeto the Machine 2nd half Read: Code Complete Ch. 29, 30 |
(7)
Oct 13 Oct 15 |
Object-oriented
techniques
Read: UML, Ch. 6, 7 Read: Code Complete Ch. 13,14 |
(15)
Dec 8 Dec 10 |
Project
Presentations
Final writeup and user manual due |
(8)
Oct 20 Oct 22 |
Object-oriented
techniques
10/20: Design spec due Read: UML, Ch. 8, 9 Read: Code Complete Ch. 15,16 |