6898: Advanced Topics in Software Design: Tasks

Tasks are to be completed before the given lecture.

Reading Questions

The purpose of the reading questions is to prod you to think as you read, and to encourage you to do the reading before the relevant class. The questions are not intended to be hard or take much time to answer; 5 lines or so should be enough to answer each. For each class for which answers are due, please send me (at the address dnj+6898 at mit.edu) a plain text email message with your answers. I will read your answers, but you shouldn't expect comments in response. I won't grade them, but I'll expect students taking the class for credit to make a good effort.

Monday May 13, 2002

Final project presentations today and Wednesday. Your write-up is due in Dan Wilson's office (NE43-511) no later than noon on Thursday May 16. Final presentation schedule is here.

As explained in class, your write-up should contain the following sections, and should be 2-4 pages in length. You can attach any relevant artifacts as appendices (models, code, etc) along with a commentary explaining them.

Wednesday May 8, 2002

Richard Tibbetts will be leading a discussion about type classes. Thanks to Richard for also providing today's questions.

Read about Haskell's type classes in the original paper and in the Haskell manual:

Then answer these questions:

  1. How do type classes compare to Java Interfaces? Mixins? Aspects? Features?
  2. What exactly is ad hoc polymorphism? Do other programming languages have it? How is it implemented? What kind of language features besides type classes can support it?
  3. What kinds of decompositions are type classes good for? Do you have an example of a system where they would be useful?

Monday May 6, 2002

From Martin Fowler's refactoring book

read the following excerpts: a chapter explaining the key idea; a chapter about spotting problems; and a few sample refactorings from the catalog: Read this paper too:

Then answer these questions:

  1. Do you buy the argument that up-front design is often premature? Or would good design obviate the need for some of these refactorings?
  2. What kind of tool support would help with refactoring? What might go wrong if you refactor badly or clumsily?
  3. Do the techniques described in the paper apply to all refactorings? What other kinds of analysis might be used to find opportunities for refactoring?

Wednesday May 1, 2002

I'm giving a talk about research strategy. No tasks in advance for you.

Monday April 29, 2002

Read the introductory chapter of Nam Suh's recent Axiomatic Design book:

This book is pretty hard going, but contains some interesting ideas, so here are some hints for how to go about reading it. Skim the whole chapter first, focusing on the case studies in the boxes. You can omit the material on the Information Axiom (from page 39 to page 53); our focus is on the Independence Axiom. Read carefully the paragraph beginning "Furthermore" on page 21; this is where the motivation for the notion of coupling is explained. Then read the questions, and reread the chapter with the questions in mind.
  1. The model of design here is reminiscent, in the software realm, of top-down design and the distinction between "what" and "how". Zig-zagging is much like the idea of stepwise refinement from the 1970's. Do you think this is a good approach for software development? You might want to look back at Michael Jackson's paper on Problem Frames (available here) which argues for a completely different notion of the distinction between domains.
  2. What are FR's and DP's? Do they have analogies in software? Does the process domain exist in software?
  3. An ideal design has the same number of FR's and DP's. Does this make sense for software?
  4. What do the elements of the design matrix that relates FR's to DP's mean? What would they mean in the context of software?
  5. Roughly speaking, an uncoupled design allows a single DP to be changed to respond to a change in an FR. A decoupled design allows a set of DP's to be adjusted without iteration. Why are these notions important in mechanical engineering? Do they have a significance in software engineering? Is there a relationship to notions of requirements traceability, or to Parnas's notion of avoiding duplication in which a single function is implemented in more than one module?
  6. Roughly speaking, an uncoupled design allows a single DP to be changed to respond to a change in an FR. A decoupled design allows a set of DP's to be adjusted without iteration. Why are these notions important in mechanical engineering? Do they have a significance in software engineering?
  7. In axiomatic design, a system-wide matrix must be constructed for the entire decomposition to ensure that a lower-level decomposition into DP's does not introduce coupling between FR's at a much higher level. Is this a desirable feature of the design method?

Wednesday April 24, 2002

Read two papers about the Design Structure Matrix (DSM). The first paper (in HBR) is an easy-to-read overview of the DSM and its use in organizing product development tasks. The second is about using coupling between components to develop an architecture that chunks them into clusters appropriately.

Then answer these questions:
  1. How do dependences in the DSM differ from the kind of dependences we've been studying?
  2. Where role do specs play in the first paper?
  3. How might the DSM apply to software? Consider, for example: whether a software system's architecture is more of less fluid than a mechanical system's; whether specs play a greater or lesser role; whether software iterations can be planned in advance; etc.
  4. The second paper considers various axes on which components might interact. What analogous axes are there for software? Is there a relationship to aspects?

Monday April 22, 2002

In class, we'll continue our discussion of dependences by considering some common idioms that arise in object-oriented programs, and seeing how we can capture their dependence structures. We'll compare the new dependence diagram that I described last time with Parnas's uses relation.

There's no additional reading for this class. Just make sure you've read and understood the papers from last time, especially the Parnas paper. You will probably also want to look over the slides from the last class to make sure you understand the elements of the new dependence diagram.

Your task is to construct some dependence diagrams in advance of class so that you have thought about the issues and are ready to discuss them. Please bring your answers to these questions on paper to class on Monday.

Consider a phone book program that provides storage and retrieval of phone numbers and addresses. For each of these fragments of the program, draw two diagrams: a Parnas uses diagram, and a new dependence diagram as described in my last lecture.

Wednesday April 17, 2002

Exercise 2 is due at the start of class today.

Read Parnas's seminal paper on the 'uses' relation, and the excerpts on dependences and coupling gathered from some recent textbooks. Copies of these excerpts are available in Dan Wilson's office (NE43-511).

Then answer these questions:
  1. There are several notions of dependence here: Parnas's uses relation; Liskov's module dependences; coupling from structured analysis; package dependences in UML. Are they the same? Are some more appealing than others? How clearly do the various authors define these notions?
  2. How much of software design is about eliminating or reducing dependence? Can one have two few dependences?

Wednesday April 10, 2002

Greg Sullivan will be our guest speaker. His topic will be "Design Patterns in a Dynamic Language". Read the paper in advance of class.

Monday April 1, 2002

The second exercise is available here. It's due on Wednesday April 17.

Read the 1997 ECOOP papers on feature-oriented and aspect-oriented programming. You may also want to read the more recent paper on Aspect-J, which applies aspects to Java. More information on aspects is available at www.aosd.net, and on AspectJ at www.aspectj.org.

Then answer these questions:
  1. What's the difference between an aspect and a feature?
  2. Could aspects be the fundamental structuring mechanism of a program, or are they always an add-on, something considered afterwards for incremental development?
  3. Are aspects and features compatible with the paradigm of object-oriented programming? Would they be more or less easily implemented in Objective CAML?

Wednesday March 20, 2002

In class, we'll discuss the module system of Objective Caml, which is based on that of Standard ML, but with better support for separate compilation. To prepare for this, read Leroy's paper:

For background on what structures, signatures and functors are all about, read the relevant parts of Bob Harper's book on programming with Standard ML, which is full of insights and wonderful examples, and is very clearly explained. Part 3 explains the module system. If you plan to use OCaml in your programming exercise, you should also read the relevant parts of the OCaml manual. Part 1 is a tutorial; Chapter 2 is about modules. It doesn't explain much, but it does give some nice examples. To really get to grips with Caml, download the distribution and play with it. You'll find distributions and much more at http://www.ocaml.org.

Then answer these questions:

  1. What practical advantages does ML's module system offer over Java's? Some issues to consider: separate compilation; interfaces vs. classes; exporting types, exceptions and values together; whether packages have specifications; making dependences explicit.
  2. ML uses sharing constraints to solve the 'diamond import problem'. Where do sharing constraints crop up in Units? Why are they not needed in Java?

Wednesday March 13, 2002

Read these papers:

For an interesting application of units, optionally read this one too: Then answer these questions:
  1. Compare the linking model in units to Cardelli's theoretical model. What are some of the key differences? Consider things like ability to hide fragments, packaging exports into groups, subtyping, mutual references, etc.
  2. In the mixins paper, Findler and Flatt say that "... support [for] external connections [is] crucial to software engineering" (Section 7, Page 8). What does this mean? Does Java provide it? And do you believe this claim?
  3. The units framework allows linking to be done at runtime, with the links selected dynamically. What useful things could be done with this feature?

Monday March 11, 2002

Read Cardelli's paper:

Don't be intimidated by the volume of mathematical material; the paper's actually very straightforward. It gives a formal model of linking that treats the linking step as substitution of an expression for a variable; this allows the standard technique for describing type checking in lambda calculus to be applied to type checks within and across modules. (If you're not familiar with basic notions of lambda calculus and type inference, though, you may find it a bit of a struggle.) Answer these questions:
  1. Cardelli asks "When does a module system really support modularization?". What does he mean by "modularization", and what else would a module system offer?
  2. Give an example of a linkset with two different linking paths (that is, two different sequences of steps that resolve the cross references between modules).
  3. What does the restriction in Definition 6.1 -- that one of the environments involved must be empty -- mean in practice?
  4. Suppose linking were not confluent. What problems would this cause in practice?
  5. How well does this theory fit the linking model of Java?

Wednesday March 6, 2002

Read the paper about problem frames:

Then answer these questions:
  1. Jackson says: "Even methods and approaches that claim the title of 'problem analysis' usually prove, on closer inspection, to deal entirely with putative or outline solutions." Does this criticism apply to Fowler's Analysis Patterns?
  2. What are the domains and shared phenomena in your lift description? Which problem frames fit it?

Monday March 4, 2002

Read the chapters from Fowler's book, and the new chapter on Accountability patterns (but feel free to skip the implementation discussions):

Then answer these questions:
  1. What exactly are these patterns of? Who would use them?
  2. Give an example of an instance of one of the accountability patterns in the organization of MIT.
  3. Make precise some of the "uniqueness constraints" discussed in the Identification Scheme pattern of Chapter 5 using Alloy.

Wednesday February 27, 2002

Read the following:

Read enough of the following to get some idea of what ASMs are about:

Look into OCL, the constraint language of UML, by reading some of the stuff on IBM's web site http://www-3.ibm.com/software/ad/library/standards/ocl.html.

Also look at the support for OCL offered by the University of Bremen's USE tool: http://www.db.informatik.uni-bremen.de/projects/USE/.

Answer the following questions:

  1. How do signatures in Alloy compare to schemas in Z? Are there things you can do with schemas but not with signatures, and vice versa?
  2. Do you accept the argument that OCL is simpler and easier to use than Z because it's less mathematical?
  3. What does the USE tool do? How does this compare to the Alloy Analyzer?
  4. Which of these languages (OCL, Z, ASM, Alloy) is appropriate for modelling object-oriented systems?

Monday February 25, 2002

Exercise 1 is due at the start of class today.

Wednesday February 20, 2002

The first exercise is now available here. It's due on Monday February 25th, but I strongly encourage you to start it early. First, it's quite challenging, and if you leave it until the last minute, you may not get it done. Second, it should be fun, and you won't enjoy it if you're under pressure. Third, I find that elapsed time helps: if you get stuck, a day away from it will clear your mind and your subconscious may well get you unstuck. Fourth, you'll benefit from the peer review meeting on February 20th if you've already thought about the problem. You should aim to have at least started the main problem (the Elevator System design) by that date.

Wednesday February 13, 2002

Read the following:

Answer the following questions:

Monday February 11, 2002

Read the following items:

Answer the following questions: