This seminar is intended to help you develop abilities to help you become a more qualified computer professional. One of the skills that is difficult to teach in most classes but which is essential to your success in any real programming project is that of design. This course is going to focus on teaching how to do a good object oriented design. During the course of the semester you will be working with other students in groups to create a solution to a single, significant problem.
Texts - There is no required text for this course (I don't feel comfortable giving a required text for a 1 hour course). However, there should be so I would recommend that you get a book on Object-Oriented Design and/or UML. I recently read the book "Fundamentals of Object-oriented Design in UML" by Meilir Page-Jones. It is a remarkably well written book that could help you in many ways well beyond the scope of this course. It's also only $40 and you should be able to find it quite readily.
Tools - To help you with this project you will be using an automated design tool called Together by TogetherSoft. This piece of software can be downloaded for free from www.TogetherSoft.com. You will want to go to the Together Community site to get a noncommercial license for the software. This piece of software is a UML design tool that can work with a number of object-oriented languages.
The problem that you are to solve this semester is to create a system to work as the hub of a multi-user game program. The system you develop should have the following characteristics.
1. It should be extensible. This implies that you should be able to very easily add new games into it. The nature of the games added should not be significant. This system should handle a large variety of games to maximize its flexibility.
2. It should be scalable. This goes hand in hand with #1, only here the objective is to make sure that what you develop can handle the load of not only adding more games, but also more users.
3. It should be accessible. The system you create should be available to as many computer users as possible across many platforms and many environments. It would be a big plus if it were at least somewhat accessible through the web as well as through a standard application interface.
A sample session on the system would begin with the user logging in and being presented with a list of the games that he/she can play as well as potentially other information or options related to the individual games (i.e. how many people playing) or the system as a whole (change password). When the user selects one of the games, a new window would be opened in which that game can be played.
It should be noted that while I consistently refer to the options the user is given as games they do not have to fit this mold. Perhaps the simplest application that could be plugged into this system would be a multi-user chat board instead of a game. This would exhibit the most basic functionality of the system and because it is a function that most games would want to allow anyway, its creation can be quite instructive. In reality what you are being asked to design is a general framework for grouping together any multi-user client-server applications that someone might want to have accessible from a single location.
As one would guess from the nature of this course, the primary evaluation will be based upon the design that you produce for your part of the project. Most of the work for the course will be done in small groups (3-4 people). Each group will work on a distinct section of the system. You will be turning in various artifacts of the analysis and design for the section assigned to your group over the course of the semester. If time permits, you will also produce a simple implementation/prototype of your section.
It should be noted that one of the keys to success for your group and the project as a whole will be communication, not only between the members of your group, but also with other groups. The interaction between the various components in this project is critical for it to actually work. I will be setting up an monitoring some discussions under Blackboard where I expect each of the groups to participate in communicating what they have come up with. If nothing else, this project could teach you just how hard it is to build a large project on a moving foundation.
Your grade for the course will be based on what is submitted by your group for each of the following analysis, design, and implementation artifacts. It will also be weighted by the results of group surveys that will help me to judge how great a contribution each member of the groups has provided.
1. Whole project ideas - This is a write-up of your ideas concerning the project as a whole. It should encompass all of the most significant design decisions in the problem, including questions such as what pieces it should be broken into, and what languages or tools should be used.
2. Analysis of problem segment - For this you will be expected to turn in a complete description of the segment of the problem that your group will be working on. The analysis can be a plain English document though more formal descriptions can be more useful when you progress to the design phase. Part of what this should include is how this component fits in with the complete program. As part of this it should begin to specify the public interface of your component. Some of these things have to be uniform for a number of groups.
3. Description of public interface - For this you will submit a formal description of what the public interface for your component of the project is. The main description will be a UML diagram of your publicly visible classes and their public interfaces. It should also include narratives on the function of each of the public methods and what they are used for as a separate document. For this class this narrative should also include some indication of the implementation that the public interface is hiding as well. In general you would not do this, but it will give me a chance to more closely monitor your progress. If you wish to separate this into distinct paragraphs that would probably be wise.
4. UML - Near the end of the semester I will expect a complete UML diagram showing the overall design of your group's component of the project. It should also include the connections to the relevant components created by other groups. This will allow a coherent picture of the entire project can be presented.
5. Final submission and presentation including prototype demonstrations - This presentation by the group will showcase the design that you have built during the course of the semester. It will culminate with a presentation by each group of some implementation of their component, preferably in conjunction with the other components.
This is a rough schedule of what will be covered during the semester. It is subject to extreme alteration but it should give you an idea of what we will be covering and what work you are expected to have completed by specific dates.
Date |
Topics | Due |
1-16 | Introduction and problem description | |
1-23 | Common Session | |
1-30 | Open discussion of project ideas | Whole project ideas |
2-6 | General discussion of Java and RMI | |
2-13 | Common Session | |
2-20 | Public Interfaces (start UML class diagrams) | Analysis |
2-27 | UML class diagrams | |
3-6 | Common Session | Public Interface |
3-20 | Common Session | |
3-27 | Common Session | |
4-3 | Other UML diagrams | |
4-10 | More UML diagrams | UML |
4-17 | Common Session | Presentations |
4-24 | Common Session | Final Submission |
Group Evaluation Forms (Word Document, PS)
Use Case Diagram Links
Use Case Diagrams: Tips and FAQ
Lecture 1: Use Cases and Use Case Diagrams
Modeling with UML (Use Case Diagrams & Classes)
UML Second Pass: Use Case Diagrams
Use Case Diagrams
Sequence Diagrams Lecture Slides
Java Links
Java Tutorials from Sun - This includes both basic and advanced tutorials. One is on RMI.
Java API Docs - This page links to the API documentation for different versions of Java. You should probably use the 1.3 version.
Other Tutorials