Project #2: A Modularly Extensible System
Your task for this project is to design and implement a modularly extensible system. You may use whatever programming language you choose. You may base your design on one of the techniques (e.g. language features or design patterns) we discussed in class, or on some other technique from a supplementary paper or another paper of your choosing.
The hope is that, by applying your chosen techniques, you gain insights that are not obvious from reading alone. The goal is to get to these insights, not to produce a perfect piece of software!
If you choose 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.
A good strategy might be to try implementing your project using two different techniques and comparing the results.
Project teams may be 1-3 people in size. A larger team should plan on a slightly more ambitious 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 be able to understand and explain all aspects of the project.
The size of the project is not fixed. A good project will have many different kinds of objects (cases) and many different kinds of operations on those objects. You should consider the modular extension of your core system with objects and operations that are very different from those in the initial core. The goal is to push the limits of your chosen technique and identify where it breaks down. For example, adding additional arithmetic operators to an expression language will be easy in any approach, but adding features like naming, state, or exceptions might be much more difficult. Similarly, operations that transform the underlying representation of data tend to be more difficult and interesting than operations that can be expressed as folds over that data. Also interesting are modular extensions that can be reused in multiple different contexts, that is, when applied to different core systems.
For your final submission, you may choose to submit either a final report or present your results on the last day of class. I encourage those that choose a project focusing on breadth (i.e. a technique not covered in class) to present, but the choice is yours.
Initial functionality and project plan (due: 11pm)
The goals of this milestone are to:
Submit a single .zip file through TEACH that includes:
Final presentations (in class)
If you choose the final presentation option, you will present your project and the insights you gained from it on the last day of classes.
More details to follow once we know how many groups choose this option.
Final submission and report/slides (due: 11pm)
Note: If you choose the final presentation option, you must still submit your code and a README! However, you should submit the slides for your presentation (in
Submit a single .zip file through TEACH that includes:
All three components of your submission are important! In other words, please don’t neglect the README file. This is crucial for helping me to evaluate your project.
The project report is your chance to demonstrate that you understand and can apply the concepts we’ve been discussing for the last several weeks in class.
Your project report should clearly describe the following things (not necessarily in this order):
Scenario — What is the domain of your system and what is the scenario that requires 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 two different core systems).
System overview — What is the core system and what are the extensions? The extensions should be in two at least two different dimensions (e.g. new cases and new operations on all of the cases). This should provide an overview of your code, but does not need to cover every single function in depth.
Techniques — What technique(s) did you apply? This should refer to specific techniques for supporting modular extensibility, either that we discussed in class or that you researched on your own.
Challenges and Design Decisions — Describe in detail 3-5 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 place where you demonstrate to me your understanding of the course material.
The range of 3-5 challenges or design decisions is to accommodate different levels of depth. If your challenges or design decisions are more obvious applications of the ideas from class, you should lean towards providing 5, while if they are more subtle, 3 is fine.