Disciplined Software Engineering
Lecture #10
•Software Engineering Institute•Carnegie Mellon University•Pittsburgh, PA 15213
•Sponsored by the U.S. Department of Defense
Software Design - Overview
•Design
–constraints
–process
–representation
•Users’ needs
•Design dimensions
•Design templates
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
Gather data onuser requirements
Analyze therequirements
data
Conceive of ahigh level
design
Refine anddocument the
design
Validate thedesign against
the requirements
Obtain answersto requirements
questions
Initial Requirements
Completed Design
Implementation
Design
Unit test
Integration test
System test
Acceptance
Use
User
Requirements
The Design CycleRequirements
definitionSystem
specification
Systemhigh-level design
Product Nspecification
Product Nhigh-level design
Product 1specification
Product 1high-level design
Component 1-1specification
Component 1-1high-level design
Component 1-nspecification
Component 1-nhigh-level design
- - - - - - -
- - - - - - - -
Module 1nkspecification - - - - - - - - - -
Module 1n1specification
Module 1n1detailed design
Module 1nkdetailed design- - - - - - - - - - - - - - - - - - - - - -
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
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
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
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
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
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
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
The Users of the Design - 1
•The principal users of the design are
–implementors
–design reviewers
–testers and test developers
–documentors, maintainers, and enhancers
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
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
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.
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
Design Dimensions
ObjectSpecification
Static
Dynamic
Internal External
Attributes
Constraints
Inheritance
Class Structure
State Machine Services
Messages
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
Logic specification
State specification
Functional specification
Operational Scenario
Module/objectspecifications
The Design HierarchyProgram requirements:
what the user needs
Program specifications:what the program
does
High-level design:how the program
works
Logic specification
State specification
Functional specification
Operational Scenario
Modulesource code
Module requirements:what the program needs
Module specifications:what the module
does
Detailed design:how the module
works
The Implementation Hierarchy
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.
Template Dimensions
ObjectSpecification
Static
Dynamic
Internal External
LogicSpecificationTemplate
FunctionalSpecificationTemplate
State SpecificationTemplate
FunctionalSpecification &OperationalScenarioTemplates
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
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.
Example Functional Specification Template
ASet (CData) ListState (0 - 4)ListPosition(0 - N)
void Push(data D)
char *Pop(data &D)
int AddSet(data D)
int SubtractSet(data D)
int MemberSet(data D)
:: insert D at position 1 && Reset
Empty’ :: return D.name && delete first&& reset || Empty :: return “Empty” D not in ASet :: Push(D) && Reset && returntrue || D in ASet :: Reset&& return falseD in ASet :: delete(D) && Reset &&return true || D not in ASet :: Reset && return false
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
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.
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
–the precise conditions that cause transitions from any other state to this state
Example State Machine*
*Note: the transitions of a state to itself are not shown
EmptySet
First&Only
FirstOfSeveral
MiddleOfSeveral LastOfSeveral
A Partial State Specification First&Only the set has one member
N = 1ListState = 1ListPosition = 1
EmptySet
First&Only
FirstOfSeveral
MiddleOfSeveral
LastOfSeveral
Clear || Pop || (SubtractSet(D) && D in ASet)
Reset || StepForward || StepBackward || (AddSet(D) && D in ASet) || (SubtractSet(D) && D not inASet) || MemberSet || Empty || Last || Status || Position
Push || (AddSet(D) && D not in ASet)
Impossible
Impossible
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
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
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
–includes
–special data types and data definitions
–the project name, date, and developer
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
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
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.
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.