The first mini-project aims to give you experience in the analysis and design of a small yet real-world application. As all real-world systems, this includes dealing with incomplete specifications, unexpected interactions between requirements, multiple platforms and unforeseeable future changes. Also, it is impossible to create a "design only" exercise: Knowledge of algorithms, communications, operating systems and data structures will also be required to complete the exercises. There is more than one "correct" solutions for each project, so your creativity, and your ability to explain your ideas simply, will be tested as well. It is time to sum up your knowledge in computers.
You will work on one of six problems offered below; you may also offer your own by email, but offers must be challenging enough to be accepted. Since only three groups are allowed to work on the same project, request to work on a subject by sending David an email with your two top requested problems. Projects will be given to groups on a FCFS basis; if your top choice is taken, you'll be given your second one. You'll receive email notification of the subject on which you will work.
These are the offered problems:
 |
Programmers' Editor (3 out of 3 taken - CLOSED) |
|
Configuration Control (3 out of 3 taken - CLOSED) |
|
Support Center (3 out of 3 taken - CLOSED) |
|
Spreadsheet (1 out of 3 taken) |
|
Database Server (3 out of 3 taken - CLOSED) |
|
Java API Design (3 out of 3 taken - CLOSED) |
You should submit a written detailed design of the problem you are working on.
Start with a detailed description of the requirements of the application. This includes both the exercise description and your additions to it. Focus on how you chose to implement general requirements (for example, what exactly "support dynamic changes of cache behavior" meant for you), and how you handled interactions between requirements (for example, how do you undo a command sent over the web?).
You may choose to implement some requirements simply, and others with many improvements and options. You must implement all the requirements in the problem specification, but feel free to add your own ideas. The more sophisticated the implemented requirements, the higher your grade.
Then, For each requirement, explain your design solution: Class diagrams to understand its structure, sequence diagrams to understand how the objects interact, and plain text to explain what is not clear from the diagrams. In short, use whatever you need to clearly explain how you implement the requirement.
The explanations should be low-level ones, at the level of detail similar to what we have done in class. This should include which object calls what method when, in which objects data is stored, time and memory complexity and so on. When using a design pattern - and you should use plenty - it suffices to just say to use the pattern for a specific problem, and no further explanations or diagrams are required. However, be sure that you use the pattern exactly as-is and don't need some variant of it. If you need to slightly change a pattern to match your needs, it is enough to shortly explain where the change is.
All problems require the use of some algorithms and data structures to solve. You are expected to find these, explain where they are coded and how they are used inside your design. Designing algorithms in part of the work - explain the data structures and algorithms you use, except if you use well-known ones in which mentioning their names is enough (for example, running a typological search over a directed graph).
Plan your design to be version 1.0 of the application. This means that you should invest most of your effort in designing, and less in algorithms and data structures. For example, if you need to design a scheduler, don't use a complex priority + fairness + customizable scheduling algorithm which uses a complex internal table. Instead, use simple round-robin scheduling, but make it to be very easy to write new scheduling algorithms, change schedulers at runtime or activate multiple schedulers together. This is what a good version 1.0 needs: Get a finished, working product as soon as possible, release it to the market, and then start working on improvements for version 2.0.
After the designs, your report should list the areas in which your design is very well prepared to change - places in which it is very easy to add or change algorithms, support new tools, port to another platform or operating system, and so on. The more flexible the design, the higher the grade. Then list changes which will be very difficult to implement with your design. This should not count against you - every design has them, and you should be able to identify them. Explain why you chose not to invest time in dealing with these changes.
Finally, include a short summary, containing your major personal lessons for this exercise.
You may work either alone on in a pair. Groups of three will not be allowed. Pairs are encouraged, since working alone will not mean making a smaller project. Also, you would benefit a lot from discussing your ideas with someone else before writing them down.
Do not cooperate with other pairs working on your subject. The works of teams working on similar subjects will be checked together, and suspicions of joint work will result in a much lower grade. Two teams working separately on a design problem will usually reach a very different solution, and this is what is expected. Remember that this exercise is half the grade of the entire course - this explains its size and required effort, and the fact that copying work here will be considered as severe as copying in a test.
The exercise can only be submitted electronically via email to David. You can submit files in Word, HTML, Visio, Rose or the common graphics formats. The deadline is midnight of Sunday, January 7th, 2001.
The exercise's grade will be combined of 80% for reading the submitted work, and 20% for answering oral questions about your design choices. The oral questions are aimed to clarify unclear parts of the written work, and to see whether you considered other possible designs, and why you decided not to use them.