Note: All assignments must be done with exactly one partner.
As programmers it is tempting for us to get our hands dirty with code immediately after receiving the specs. In any complex software development, there are many moving parts and pieces that can quickly turn out project into spaghetti code. It is imperative that before we open vim we take a step back, plan out the code we are going to write, and create a design to follow. One tool software engineers use for this is Unified Modeling Language (UML) which help visualize our project’s architecture. In this assignment you will create a design document to map out your first coding assignment, Assignment 2. This will include a simple UML diagram to represent your components and their dependencies. You can read more about creating UML diagrams from this slide deck.
Your assignment is to write a design document that you will use for reference when developing your Assignment 2 submission. It’s purpose is as an exercise to get you to start designing before you start coding. Like any good agile method, what you write in the design document is a starting point for your design, not a road map that you must rigidly follow (because that would be waterfall development, and this is not a government project). You should create a document with the following sections
- Title Page: including the title “Assignment 1: Design”, the date, the quarter and year, and the authors names
- Introduction: Give a brief overview of your design
- Diagram: This will be the UML diagram for your system, and should show all classes you plan on developing. This diagram can take up multiple pages if necessary.
- Classes/Class Groups: descriptions of each class/class group that you plan on developing, this can be as simple as a description of what each class accomplishes and how, or a pseudo code level class definition. A class group would be a group of classes that all inherit from a single base class (composite classes are an example). For class group give a description of the base class, as well as the subtle differences between the child classes. Make sure to describe any key design choices, such as why you chose certain containers for key data members, why a class needs to pointer member to another class, or how a key function will generally be written
- Coding Strategy: how you and your partner plan to break up the work, who will be in charge of which segments and how you will integrate the segments together
- Roadblocks: issues that you think will arise during development and what strategy you will use to overcome them
When you create your design document, do not think only about the current assignment. Think about how you would also extend the assignment to have new functionality (an important exercise in software construction, as new functionality is almost always necessary).
Please use some drawing program to create your UML diagram. UML diagrams that are drawn by hand and scanned/photographed and added to your design document will not be allowed. Programs such as GIMP, GraphViz, or even Google Docs should be capable of creating these diagrams.
Submit your design document as a single PDF to your groups GitHub repo.
Your documents will be graded using the following breakdown
| Points | Section |
|---|---|
| 40 | UML Diagram |
| 30 | Class Descriptions |
| 20 | All Other Sections |
| 10 | Structure |
| 100 | Total |