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.