Starting to Design Project 0

• Chapter 4 of the book discusses design
  • Sections 6 through the end of the chapter. Reread these.
  • I also like the case study starting on page 377 as an example
• You need to practice designing projects
  • Even if you could just write the code from scratch.
  • Planning is one of the aspects that marks the difference between a professional and a hobbyist.
  • As projects grow there is no way to implement them without planning of some sort.
• Good design
  • Provides a plan on how to implement the code.
  • Allows us to spot abstractions and reusable sections of the code.
  • Allows for the creation of useful sub-routines.
  • Simplifies the problem solving process.
• I recognize that planning is difficult
  • For most of us it is not the "fun" part.
  • We really are not sure how to do it.
  • And we are not sure if our designs will work.
• But you need to practice.
• I do not expect perfection
  • You will receive credit if
    1. You make an honest attempt
    2. You supply all of the required parts.
    3. You follow the instructions.
    4. You do not provide code. (Your submission will be worth 0 if you do)
• Please understand, you should have no repeated code in your programs.
  • Design with sufficient functions to eliminate this.
• What are the two design methodologies mentioned in chapter 4?
  • How does each work?
• What does functional cohesion mean?
  • A property of a module in which all concrete steps are dedicated toward solving just one problem, and any significant sub problems are written as abstract steps. (From the book)
  • In my opinion
    • Each function does one thing.
    • The name of the function indicates what that thing is.
    • The function is either all low level (concrete) code or high level (abstract) code.
    • But not a mixture of both.
• How do we do a design?
  • I like what our author says on page 166
    1. Think about how you would solve the problem (subproblem) by hand.
    2. Write down the major steps
    3. If a step is simple enough that you can see how to implement it directly in C++, it is a concrete level; it doesn't need any further refinement.
    4. If you have to think about implementing a step as a series of smaller steps or as several C++ statements, it is still at an abstract level. (write an additional module)
    5. If you are trying to write a series of steps and start to feel overwhelmed by details, you probably are bypassing one more more levels of abstraction. Stand back and look for pieces that you can write as more abstract steps.
• Let's start the design document
  • The template here
• Structure Charts
  • You might use a uml tool to create the structure chart.
    • umlet
    • There are many tools, you don't need to use this one.
    • There are many ways to make a structure chart, but I would use the book, pate 380 as my example.
  • Document from the
    • First Class
    • Second Class
• Write an algorithm.
  • What is the purpose of the algorithm?
    • Should it be in code?
    • Should it be high level English paragraphs?
  • What is pseudo-code (Page 166 of the book)
  • I expect
    • Sufficient detail to convince me that you can implement your algorithm.
    • But not code.
    • You to use control structures (if, while, for)
    • But not code
  • I really don't want
    • Semi-colons (;)
    • Variable declarations.
    • Parameter lists.