# Software Design
Today we will undertake an extended design exercise. Please pair up
with someone else to do most of this exercise, because discussion of
design is one of the ways we can learn the most about it. Toward the
end of the exercise, you will present your design to another pair of
students and review one another's designs, so keep written notes as you
go.
## Requirements
You are asked to design a software system to meet the following user
requirements.
**Purpose and scope:** the purpose of the system is *automated grading
of programming assignments.* The system assumes that the submissions
are available as inputs, and produces grades as output. The system is
meant to be used by a single grader. Collection of submissions from
student is out of scope, as is returning grades to students—that
is, you could imagine this system complementing CMS rather than
replacing it.
**Requirements:**
1. The grader can define a set of unit test cases to evaluate all
submissions against.
2. The grader can specify the point values of test cases.
3. The grader can identify a subset of the submissions to be graded.
4. The system is not isolated to a single computer but may make use
of the computational power afforded by a network of computers.
The system may grade submissions in parallel on that network
to speed up grading.
5. Grading a submission requires automatically compiling it, running it,
and collecting the test case results.
6. The system produces a grade for each student, and a file of results
stating which test cases passed vs. failed.
7. The system produces a report for the grader showing the percentage of
submissions that pass each test case, and a report showing the
grades for all submissions.
##### Exercise: requirements [5 min]
Read the requirements above and discuss them with your partner. Come
to a consensus about what they entail. There will of course be some
ambiguities in the above requirements, as they are so brief. Resolve
those in a way that seems reasonable to you, making sure to take notes
on what you decide.
□
## Architecture
##### Exercise: components and connectors [5 min]
Design the architectural components of this system: the large scale,
run-time units of the system. Design the connectors: the means by
which the components will communicate. Draw a C&C diagram showing
the architecture of the system. Comment on whether the architecture
you have designed is an instance of one of the common patterns
we discussed in lecture (pipe and filter, shared data,
client–server) or a hybrid of any of them.
□
## Design
##### Exercise: high-level design [10 min]
Design the modules that will implement your architecture. Whereas
components are about run-time units of a system (i.e., its behavior),
the modules are about the compile-time units of a system (i.e., its
source code).
Begin by identifying just a handful of modules that would provide the
functionality needed for the components. For each module, design its
interface: its name, its "mission statement" (ideally a one-sentence
description of its functionality), the types it will contain, and the
functions on those types.
It's okay to work at a high-level here: you aren't writing legal OCaml
code right now, just sketching ideas on paper. By analogy think of this
more like writing pseudocode than code.
□
##### Exercise: MDD [5 min]
Draw a module dependency diagram (MDD) for the modules you have
designed. Investigate the fan-in and fan-out of each modules.
Comment on the coupling that you observe between modules. Does
that cause you to revise your design?
□
##### Exercise: detailed design [10 min]
Return to one of the modules that you have just designed at a high
level. Try to choose a module that has some interesting functionality,
so that this exercise will be challenging.
Refine the design of that module to an actual OCaml interface (i.e., a
`.mli` file). This might cause you to invent a few submodules or
to factor the module into a couple pieces. Write brief specifications
for each of the functions in your modules.
Comment on the cohesion you observe in the modules for which you have
now done the detailed design. Does that cause you to revise your
design?
□
## Review
##### Exercise: design review [5-10 min x 2]
Join up with another pair of students. Let's call one pair the "Red Pair"
and the other pair the "Blue Pair".
1. Red Pair: Present your design to Blue Pair.
2. Blue Pair: Remember that design review is non-judgmental and focuses on
clarifying and improving the design. Try to answer the following
questions about the design you just saw:
* Is the design complete? Does it meet the requirements? Given the extent
to which the design has been finished, are sufficient specifications
provided?
* Is the design simple and modular? Does it exhibit good use of
partitioning and abstraction? Does it have high cohesion and low
coupling?
* Do you think the design would be implementable and testable?
What problems might you foresee?
3. Now swap: Blue Pair, present your design to Red Pair. Red Pair, review
that design.
□
## Secret
We have a [secret][]. Don't read it until you've finished the rest of the
recitation. :)
[secret]: rec2.html
## Solutions
Prof. Clarkson would like to post a handful of student-created solutions
to this recitation as examples of design. Would you like to submit
yours for consideration? If so, please write it up in a PDF and send
that PDF to your recitation TAs. They will pass along the best from
your section to Prof. Clarkson, who will select from those some great
solutions. The deadline for sending to your TAs is five days after your
recitation occurs.