# 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&mdash;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. &square; ## 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&ndash;server) or a hybrid of any of them. &square; ## 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. &square; ##### 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? &square; ##### 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? &square; ## 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. &square; ## 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.