UP | HOME
../../

Correct By Design

Table of Contents

1 Correct By Design

  1. Correct By Design i.e., "Correct By Intention/Effort" is a core idea of this course.
  2. How do we judge if a design is "correct"?
    1. Particularly, in the absence of specs? [Cannot]
    2. Is it a judge/jury system? [Yes]
  3. A design D satisfies/ meets a spec S
    1. This can be precisely stated, S \(\models\) D
  4. A spec S is consistent with a requirements document R
    1. This will remain in the judge/jury system.

2 Design D satisfies Spec S, S \(\models\) D

  1. Def: D "satisfies" S, notationally S \(\models\) D. Every property of specs S can be observed in D. Not necessarily vice versa.
  2. S is written in a spec language, SL
  3. D is written in a design language, DL
  4. SL and DL: Plenty in research literature, but not in wide use
  5. S \(\models\) D1, S \(\models\) D2, …, S \(\models\) Dn, … [Multiple designs meet a spec S]
  6. We will use: Discrete math and Logic.

2.1 Satisfies v Models

  1. We use this symbol \(\models\) and call it "models".
  2. We can read the above as: S models D.
  3. Models suggests abstraction.
  4. Satisfies suggests adding concrete details.

3 Design Space Hierarchy

  1. Design D satisfies Spec S, S \(\models\) D
  2. D2 refines D1 versus D2 is an alternate design cf D1
    1. refines: provides more detail
    2. refines: gets closer to the implementation language
    3. alternate: explores a different design idea
    4. alternate: better in some spec axes, worse in others
  3. Design Levels S \(\models\) D1 \(\models\) D2 | … \(\models\) Dn \(\models\) I
    1. In general, this is a tree with many leaves
    2. Siblings are alternates.
    3. One path from the root to an implementation: S \(\models\) D1 \(\models\) D2 | … \(\models\) Dn \(\models\) I
  4. Implementation I: Source Code in a PL
  5. Can/Should we have levels in Specs? Yes! S \(\models\) S1 \(\models\) S2 … \(\models\) Sk

4 End

Copyright © 2018 • www.wright.edu/~pmateti 2018-09-24