6.898 Advanced Topics in Software Design
Spring 2002
Exercise 2: Programming A Directions Finder
Due: Wednesday, April 17th at 2:30pm

Please prepare a hard copy of your solution and bring it to class on the due date.

The purpose of this exercise is to give you some experience with modern module structuring mechanisms. You can implement your program in Objective Caml, Jiazzi, or Haskell. I'm open to other suggestions of languages with interesting module systems, so ask me if you'd like to try something else (and it isn't Java or C++).

The exercise is actually one that I prepared last term for 6.170, although the focus here is very different. You are not required to produce any particular design documentation, nor to document your code with specifications, nor even to test it systematically. The purpose is to experiment with different ways to modularize it. That said, to ensure that you build something credible, I do expect to see evidence that your program runs successfully. Moreover, I think it highly unlikely that you will succeed in obtaining running code by mindless hacking; I recommend that you think carefully about the specification before you start coding, and develop a plan for the design as a whole, at least in outline form. You will probably want to develop your program incrementally; it will help you reflect on your design if you keep a careful record of design decisions you have made (and especially those you revoked).

Your task is to develop a program that computes directions on the Boston T. A user inputs a pair of station names, and the program generates instructions directing the user what lines to take, where to change, etc. The challenge is to implement this in a modular fashion. If you use a graph representation of the subway, for example, you should make it fairly general, so it could be reused in other programs. There is a tricky tradeoff here: it should be general enough to allow new functionality to be added easily, and to allow reuse in similar applications, but not so general that it makes the overall task of writing the application much harder. I'm providing you with the T map as a text file here; you can reformat this to make parsing easier if you want to. You may find it helpful to refer to the 6.170 problem set.

You should hand in:

  1. A brief specification of your program that highlights any particular complications you handled or simplifications you made.
  2. The code itself, organized and commented to be comprehensible to an expert developer.
  3. An explanation of the design with some illustrative sketches (such as a dependence diagram), and a discussion of its merits and deficiences.
  4. A brief discussion of the merits and deficiencies of the implementation language that had an impact on your work, and anything else you learned from this exercise.

Daniel Jackson, March 22, 2002