UP | HOME
2020-09-17 | ../../

Overview of Design

1 Overview

  1. Remember this cliche What : How :: Spec : Design
  2. Designing (verb): Discovering a "how" procedure for the "what does it do" given in the spec.
  3. A spec is an IO relation. More ../Specs
  4. Waterfall implies that, when working on a spec, we do not yet have a design or implementation.
  5. For complex products, we have hierarchies of abstractions, designs, and design spaces.
  6. The section headings below are clickable links.

2 Examples of Spec/ Design

  1. Several example specs and design are shown.
  2. Ex: Knuth's Common Words Problem: Requ, Specs, Design and Impl. Published. [There will be lectures on this.]
  3. Ex: Req, Spec, Design and Proof of a Pretty Printer for PLs Published. [There will be lectures on this.]

3 Correct by Design

  1. Correct By Design; i.e., "Correct By Intention/Effort"
  2. How do we judge if a design is "correct"?
  3. Precise def of "A design D satifies/meets a spec S"
  4. A spec S is consistent with a requirements document R. How do we check this? Judge/jury system.

4 Design By Contract (DbC)

5 Design Documentation

  1. Recall that: A spec is a relationship between IO, expressed using discrete math, logic, and grammars. We prefer it to be declarative. But, occasionally we do use an older version of a program to be a spec for a new version to be built, with additional spec details added.
  2. A design is a how-to expressed in a high-level notation, far higher than typical programming languages such as C++ and Java.

5.2 Design Rationale and Knowledge

  1. "A design rationale is the explicit listing of decisions made during a design process, and the reasons why those decisions were made."
  2. Design knowledge is the collection of techniques and past designs. Usually narrowed down by the topic. E.g., design knowledge of compilers, clients-servers.

5.3 Structure of the Document

5.4 Req Doc vs Spec Doc vs Design Doc vs Impl Doc

  1. See our [Projects] page.

5.5 Literate Programming ./literate.html

6 Object Oriented Design

The above sections did not assume OOP/OOD. This does.

6.1 The Liskov Substitution Principle

  1. Liskov Substitution Principle (LSP) is the L in SOLID Principles of OOD. It clarifies the meaning of inheritance beyond mere syntax. The principle applies to best practices in all OOP languages; certainly to: C++, Java, Scala, and Python. The clarification is crystal clear in the presence of pre- post conditions and class invariant.

6.2 SOLID Principles

  1. Principles of Class Design (aka SOLID)
  2. (SRP) The Single Responsibility Principle
  3. (OCP) The Open Closed Principle: Classes and methods should be open for extension (of functionality) and closed for modification.
  4. (LSP) The Liskov Substitution Principle: Subtypes must be substitutable for super type. A sub class must enhance functionality, but not reduce.
  5. (ISP) The Interface Segregation Principle
  6. (DIP) The Dependency Inversion Principle. [In our course, I prefer the DbC.]

6.3 OODesign Patterns

  1. A design pattern is a solution template for problems of a certain pattern.
  2. A pattern codifies expert knowledge.

6.4 Design Smells

  1. "Design smells indicate violation of fundamental design principles and negatively impact design quality"
  2. Code smells has extensive literature. Design smells not so much.

6.5 Refactoring

  1. Refactoring is the modification of software source code to improve software qualities while preserving functionality.
  2. Enhancement is not refactoring.
  3. Refactoring is part of maintenance

6.6 AntiPatterns

  1. "An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive."

7 End

Copyright © 2017 • www.wright.edu/~pmateti • 2020-09-17