# Project #1: A Modular System in SML

Your task for this project will be to design and implement a small modular system using SML. The domain of your project may be anything you like. You may want to choose something related to your research, or something you’re personally interested in, or perhaps to re-implement a system you’ve implemented before.

Project teams may be 1-3 people in size. A larger team should plan on a slightly more ambitious project than the minimum requirements, but the size of the project definitely 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 your projects may vary, but here is a set of minimum criteria for the modular aspects of your design:

• at least 10 different modules
• at least 3 different signatures, of which at least 1 is implemented by multiple modules
• at least 1 functor with at least two instantiations of that functor

The more functional the system is, the better, and completely working systems are fantastic. However, it is also OK to use function stubs or dummy values in strategic places of larger systems. The primary goal of the project is to design a modular system. So stubbed out modules that illustrate interesting or significant modularity concerns are preferable to flat libraries of sophisticated working functions.

Your project 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 your design.

## Milestones

 Apr 24 Initial functionality and project plan (due: 11pm) The goals of this milestone are to: Force you to start writing SML code! Formulate a high-level plan for your project. Get early feedback from me and from your peers. Submit a single .zip file through TEACH that includes: Your SML code so far. This should include several functions implementing basic functionality for your project. Minimum of, say, 100 lines of well-formatted code. You may or may not have already divided this code up into modules—either way is fine. A text file named README.txt or README.md that includes: A brief description of what your project is about. Instructions for how to run and interact with your code, such as sample inputs to execute in the REPL and expected outputs. A text file named PLAN.txt or PLAN.md that includes: A more detailed description of what your project is about. A preliminary list of signatures and modules that you plan to implement, including which modules implement which signatures. Where possible, you should also note the design decisions that you anticipate each module will hide from others. May 12 Final submission and report (due: 11pm) Submit a single .zip file through TEACH that includes: The SML code implementing your project. A text file named README.txt or README.md that includes: A brief description of what your project is about. Instructions for how to run and interact with your code. This should include several different examples illustrating how your code works, including expected outputs. Your project report, described below, submitted as a .pdf file. 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.

## Project report

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 consist of several sections:

1. A high-level overview of what your project is about. This should answer the following questions: What is the domain? Who are the users? What kinds of things can those users do with your project?

2. A list and brief description of all of the signatures, modules, and functors in your project. In the description of signatures and modules, you should highlight especially important types and functions. The goal of this section is to guide the reader through your source code, putting things into their proper context. It isn’t necessary to describe every helper function, but this section should provide a reasonably complete overview of the content of your project.

3. (Most important!) Describe in detail 3-5 design decisions you made during your project, with respect to abstraction and/or modularity. For example, what is a piece of information that you chose to hide and why? How did you decide on a particular way of separating your system into modules compared to another. How did you reduce coupling between two modules? These design decisions should emphasize how you applied ideas from the papers we’ve read (and associated discussions) to the design of your project. It might be helpful here to include snippets from old versions (or hypothetical alternative versions) of your project to compare and contrast with the final version.

The range of 3-5 design decisions is to accommodate different levels of depth. For example, if you made a more obvious design decision, such as to implement a data structure as an abstract data type, there may be only so much you can say and so this might be one of 4-5 such descriptions. However, if you made a design decision with more subtle implications (e.g. that involves trading off one desirable quality for another) or a less obvious solution, then you will have much more to say and also a few alternative designs to discuss, so this might be one of only three such descriptions.