1. Disciplined Software Engineering Lecture #10
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Sponsored by the U.S. Department of Defense

2. Software Design - Overview
constraints
process
representation
Users’ needs
Design dimensions
Design templates

3. Design Constraints
The requirements must parallel design - they will often not be completely understood until you have a working product.
Each design level debugs higher level designs
the specification debugs the requirements
the high-level-design debugs the specification
the detailed design debugs the high-level design
the implementation debugs the detailed design

4. The Design Framework Initial Requirements Completed Design
Gather data on
user requirements
Analyze the
requirements
data
Validate the
design against
the requirements
Obtain answers
to requirements
questions
Conceive of a
high level
design
Refine and
document the
design
Completed Design

5. Development Framework
Requirements
Design
Implementation
User
Unit test
Integration test
System test
Acceptance
Use

6. The Design Cycle - - - - - - - - - - - - - - - - - - - - - - - - -
Requirements
definition
System
specification
System
high-level design
Product 1
specification
Product N
specification
Product 1
high-level design
Product N
high-level design
Component 1-n
specification
Component 1-1
specification
Component 1-n
high-level design
Component 1-1
high-level design
Module 1n1
specification
Module 1nk
specification
Module 1n1
detailed design
Module 1nk
detailed design

7. The Design Process - 1
Software design is the creative process of producing a precise and effective solution to an ill-defined problem.
The design process cannot be
reduced to a routine procedure
automated
precisely controlled or predicted

8. The Design Process - 2 The design process can be structured to
separate the routine from the creative activities
ensure that the design work is properly performed
identify potential design support tools and methods
It is important to separate two issues
how to do the design
how to represent the design when it is completed

9. The Design Process - 3 There are many design methods
none have been proven best for every domain
the best method may depend on the individual
individual preferences are also important
a widely-usable process must work with many different design methods
There are also many types of representations
graphics assist in visualizing structure
formality provides precision
text provides intuitive understanding
all three are often needed

10. The PSP Design Process
The PSP focuses on what a design should contain when it is completed.
This is necessary because
it provides criteria for determining when a given design phase is completed
it provides a basis for reviewing the design
since there is no single best design method, the PSP must be capable of supporting multiple methods

11. Poor Design Representations Cause Defects - 1
Levels of design
an obvious design concept may not be obvious during implementation
reconstructing the design context during implementation is time consuming and error prone
to save time and prevent defects, the design should be precisely recorded when it is conceived

12. Poor Design Representations Cause Defects - 2
Design visibility
complex designs are difficult to visualize
a poor representation compounds this problem
a well-represented design is unambiguous
Design redundancy
a redundant design is often inconsistent
inconsistency breeds errors and causes defects
a quality design has minimum duplication

13. Design Representation - Requirements
The design representation must
precisely define all significant design aspects
include all important details
communicate the designers’ intent
help identify design problems and omissions
Also
the design should be compact and easy to use
the design topics must be readily located
redundancy must be avoided

14. The Users of the Design - 1
The principal users of the design are
implementors
design reviewers
testers and test developers
documenters, maintainers, and enhancers

15. The Users of the Design - 2
The users all need
a clear statement of the program’s logic
a description of all external calls and references
a list of all external variables, parameters, and constants
a specification for all related objects and classes
a description of all files and messages
the specification of all system constraints
the specification of all implementation constraints

16. The Users of the Design- 3
In addition, the design and code reviewers need
a picture of where and how the program fits into the system
a structural view of the product
a precise statement of the program’s external functions
The other users need
typical user scenarios
the specification of special error checks or conditions
the reasons for the design choices

17. The Users of the Design - 4
This is potentially a large amount of material
not all of it is needed immediately
some can be obtained from other sources
it is wise to limit the design workload as much as possible
It is thus important to identify the critical design subset that the designers must provide.
Where possible, the other items should be provided later or by other people or groups.

18. The Users of the Design - 5
The critical materials that must be provided by the designers before implementation are
a clear statement of the program’s logic
a specification of all external calls and references
a list of all external variables, parameters, and constants
a specification for all related objects and classes
a picture of where and how the program fits into the system
a structural view of the product

19. Design Dimensions Object Specification Static Dynamic Internal
External
Attributes
Constraints
Inheritance
Class Structure
State Machine
Services
Messages

20. Design Templates Four design templates are used in the PSP
logic specification template - static, internal
state specification template - dynamic, internal
functional specification template - dynamic and static, external
operational scenario template - dynamic, external

21. Program requirements: Functional specification Program specifications:
The Design Hierarchy
Program requirements:
what the user needs
Functional specification
Operational Scenario
Program specifications:
what the program
does
Logic specification
State specification
High-level design:
how the program
works
Module/object
specifications

22. The Implementation Hierarchy
Module requirements:
what the program needs
Functional specification
Operational Scenario
Module specifications:
what the module
does
Logic specification
State specification
Detailed design:
how the module
works
Module
source code

23. Using Design Templates
These templates comprise one way to represent a design
their intent is to be precise, unambiguous, non-redundant, and complete
use the design templates with the PSP where you can
Other representations may be substituted if they are equally precise, unambiguous, non-redundant, and complete.
Additional representations are acceptable.

24. Template Dimensions Object Specification Static Dynamic Internal
External
Logic
Template
Functional
State
Specification &
Operational
Scenario
Templates

25. Functional Specification Template - 1
The purpose of the functional specification template is to unambiguously define all the external functional services provided by this product
the objects, classes, and inheritance
the externally visible attributes
the precise external functions provided by each object

26. Functional Specification Template - 2
Where possible, each function call and return should be specified in a formal notation.
The functional specifications of related objects/classes should grouped together in common templates.

27. Example Functional Specification Template
ASet (CData)
ListState (0 - 4)
ListPosition(0 - N)
void Push(data D)
:: insert D at position 1 && Reset
Empty’ :: return D.name && delete first
&& reset ||
Empty :: return “Empty”
char *Pop(data &D)
D not in ASet :: Push(D) && Reset && return
true || D in ASet :: Reset&& return false
int AddSet(data D)
D in ASet :: delete(D) && Reset &&
return true || D not in ASet :: Reset &&
return false
int SubtractSet(data D)
D in ASet :: return ListPosition ||
D not in ASet && N==1 :: ListPostition = 1 &&
ListState = 1 && return false ||
D not in ASet && N>1 :: ListPosition = N &&
ListState = 4 && return false
int MemberSet(data D)

28. State Specification Template 1
An object is a state machine when
identical inputs produce different responses
previous history is remembered by the states
The state specification template precisely defines the object’s states and the transitions among them.

29. State Specification Template 2
For each object state machine, the template specifies
the name of every state
the attributes that characterize each state
the attribute values for that state
a brief description of the state
the precise conditions that cause transitions from the state to itself and other states
the precise conditions that cause transitions from any other state to this state

30. Example State Machine*
EmptySet
First&Only
FirstOfSeveral
MiddleOfSeveral
LastOfSeveral
*Note: the transitions of a state to itself are not shown

31. A Partial State Specification
First&Only
the set has one member
N = 1
ListState = 1
ListPosition = 1
EmptySet
Clear || Pop || (SubtractSet(D) && D in ASet)
First&Only
Reset || StepForward || StepBackward ||
(AddSet(D) && D in ASet) || (SubtractSet(D) && D not in
ASet) || MemberSet || Empty || Last || Status || Position
FirstOfSeveral
Push || (AddSet(D) && D not in ASet)
Impossible
MiddleOfSeveral
LastOfSeveral
Impossible

32. State Specification Template Considerations
Define all the object state machines
the trivial ones should be trivial to define
often seemingly simple state machines are not
when state machines involve multiple objects, that could be a sign of poorly selected objects
Check for completeness and consistency
the set of attribute conditions for all the states must be complete and orthogonal
the set of all transition conditions from any given state must be complete and orthogonal

33. Logic Specification Template 1
The logic specification template precisely defines the program’s internal logic
Describe the logic in a convenient notation
a pseudocode compatible with the implementation language is often appropriate
formal notation is also appropriate
the implementors must be fluent with the notation used

34. Logic Specification Template 2
The logic specification template should specify
the logic for each method of each object and for the main program
the precise call to the program or method
the includes
special data types and data definitions
the project name, date, and developer

35. Operational Scenario Template - 1
The operational scenario template is used to ensure that the users’ normal and abnormal interactions with the system are considered and defined both before and during the design.
The operational scenario template can be used
to define test scenarios and test cases
to resolve development questions about operational issues
to resolve requirements discussions with users

36. Operational Scenario Template - 2
The operational scenario template uses a scenario format.
It contains
the principal user actions and system responses
the anticipated error and recovery conditions

37. Assignment #10 Read Chapter 10 in the text.
Using PSP2.1, write program 9A to calculate the degree to which a string of N real numbers is normally distributed.
assume N is >20 and an even multiple of 5
use program 8A to sort the numbers into ascending order.
Read the process and report specifications in Appendix C and the program specifications in Appendix D.

38. The Chi-Square Test
The purpose of the Chi-square test is to determine the degree to which a set of data are distributed in some predetermined way.
In program 9A, the test is made against the normal distribution.
It is also assumed that the number of data items N is greater or equal to 20 and is evenly divisible by 5.

40. The Chi-Square Test - 2 The steps in the Chi-Square test
divide the distribution into equal-area segments (5 in this example)
convert the data to normal form
count the data points in each segment
you would normally expect 4 in each segment
calculate the value of Q
calculate the value of t
find the probability value for this t
if p > 0.2, it is considered a good fit
if p < .05, it is considered a poor fit

41. Messages to Remember from Lecture 10
1. While design is a creative process, its
routine aspects can be defined.
2. The definition of the design products and the
use of established formats can improve the
quality of your designs.
3. Experiment with the 4 PSP design templates
in the course exercises and, if you find them
helpful, use them in your other work.