Project: A Modularly Extensible System
Overview
As your final project, you will design, implement, revise, and/or extend a modularly extensible system.
The specific parameters of the project are extremely flexible. You’ll propose an initial idea, your classmates and I will provide feedback, and then we’ll negotiate an appropriate scope. As we get further into the course, you may want to apply new ideas and techniques from the papers we read, and your plans may change. This is great since it means you’re learning something useful!
Ambitious projects and projects with research potential (or that fit into your current research) are strongly encouraged. The goal is not to produce a perfect piece of software that completely solves the problem you set out to solve, but rather to gain insights by applying the ideas from class. Often the value, challenges, and nuances of a technique are not obvious from reading and discussion alone. An ambitious project that doesn’t quite solve the intended problem but poses several challenging design decisions is much better than a simple project, perfectly executed.
Project teams may be 1-3 people in size. A larger team should plan on a slightly larger project, but the size of the project doesn’t need to scale linearly with the size of the team. Regardless, all team members should be able to clearly identify their contributions to the project and should understand and be able to explain all aspects of the project.
Guidelines
While the specifics of your project are flexible and negotiable, here are some rough minimum qualities that I think all reasonable projects must have.
First, it should consist of several modules with well-defined interfaces. What exactly constitutes a module and interface depends on your choice of programming language.
The organization into modules and choice of interfaces should demonstrate an understanding of the concerns we discuss in class. For example, you should be able to explain how the principals of information hiding (Parnas) or coupling/cohesion (Stevens et al.) influenced the design.
Second, it should have a need for and support modular extensibility, ideally in multiple dimensions (e.g. adding both new kinds of things and new operations on things).
Your support for modular extensibility should advance the discussion from class in one of two ways:
If you apply a technique that was the focus of one the papers that we discussed, your main contribution should be adding depth to the discussion that we already had. For example, what problems did you encounter that we may have missed? Were you able to devise workarounds for limitations of the technique? Is it more suited for certain kinds of extensions but not others?
If you choose a technique that was only mentioned or cited in the papers we read, or that we never discussed at all, your main contribution can be adding breadth to our discussion by comparing the technique (e.g. its advantages and limitations) with other techniques that we spent more time on.
Milestones
| May 22 |
Project proposal The goals of this milestone are to:
You will submit a single
See the full description of the project report below for more details on each of these sections. For the initial proposal, your draft should be detailed and polished enough that your readers can understand exactly what it is you plan to do, but it is expected to be shorter and rougher around the edges than your final submission. Being concise is good as long as your goals are clear! Parts of your project will be unknown at this point, and other parts will change–all of this is OK. The important thing is to present a relatively clear vision of what you plan to do so that we can provide specific advice for you going forward. |
| Jun 3 |
Project milestone At this milestone, you should be 60-70% done with your project according to your current plan. You should have a clear story about why modularity and modular extensibility are important in your project, a clear vision about how these qualities will be achieved, and significant progress toward realizing that vision. The submission will look similar to your final submission (see below), including your code and a draft report that includes a discussion of challenges and design decisions you have encountered so far. It’s crucial that your project is not already “finished” at this stage! At this milestone you will receive detailed feedback from me and from your peers, which you should use to revise the direction of your project. You will also still be learning new techniques in class, which may influence the strategies you choose to apply. You will submit a single
All three components of your submission are important! In other words, please don’t neglect the README file. This is crucial for helping me and your peers to evaluate your project. |
| Jun 12 |
Final submission and report Submit a single
As before, all three components of your submission are important! Please don’t neglect the README file, which is crucial for helping me evaluate your project. |
Project report
The project report is your chance to demonstrate that you understand and can apply the concepts we’ve been discussing throughout the term.
Your project report should clearly describe the following things. I assume these will each be their own section in your report, but you are free to choose some other format if it makes more sense for your project.
Domain and modularity scenario — What is the domain of your system and what is the scenario that requires modularity, abstraction, and modular extensibility?
A scenario might involve two different people (e.g. a library maintainer of the core system and a client programmer who wants to add the extensions) or might involve a situation where reuse is important (e.g. want to extend the same core system in two different ways in different contexts, or want to reuse the same extensions in two different core systems).
System overview — What are the modules and interfaces in your system? What are the modular extensions? Ideally, the extensions should be in at least two different dimensions (e.g. new cases and new operations on all of the cases). This section should provide an overview of the code in your code, but does not need to cover every single function in depth.
Techniques — What modularity and extensibility technique(s) did you apply and how? This should refer to specific techniques for supporting modularity, abstraction, and/or modular extensibility, either that we discussed in class or that you researched on your own.
Challenges and design decisions — Describe in detail 3-7 challenges encountered (e.g. limitations of your chosen technique) and/or design decisions made during the development of your project. For challenges, you should describe what you did to overcome or circumvent these challenges. For design decisions, you should describe your rationale for making those decisions.
In this section, it is crucial to refer to the papers, examples, and discussions from class. This is the most important part of your final project: the place where you demonstrate to me your understanding of the course material.
The range of 3-7 challenges or design decisions is to accommodate different levels of depth. If your challenges or design decisions are more straightforward or obvious applications of the ideas from class, you should lean towards describing more such decisions, while if they are more subtle design decisions that require in-depth discussion, fewer is fine.