# Presentation: 279707

## 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**

## The Design Framework

**Gather data on**
**user requirements **

**Analyze the**
**requirements**
**data**

**Conceive of a**
**high level**
**design**

**Refine and**
**document the**
**design**

**Validate the**
**design against**
**the requirements**

**Obtain answers**
**to requirements**
**questions**

**Initial Requirements**

**Completed Design**

## Development Framework

**Design**

**Unit test**

**Integration test**

**System test**

**Acceptance**

**Use**

**Development Framework**

**User**

**Requirements**

## The Design Cycle

**Requirements**
**definition**

**System**
**specification**

**System**
**high-level design**

**Product N**
**specification**

**Product  N**
**high-level design**

**Product 1**
**specification**

**Product 1**
**high-level design**

**Component 1-1**
**specification**

**Component 1-1**
**high-level design**

**Component 1-n**
**specification**

**Component 1-n**
**high-level design**

**-  -  -  -  -  -  -  **

**-  -  -  -  -  -  -  -  **

**Module 1nk**
**specification**

**  ****-  -  -  -  -  -  -  -  -  -**

**Module 1n1**
**specification**

**Module 1n1**
**detailed design**

**Module 1nk**
**detailed 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**
**documenters, 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

## 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**

## The Design Hierarchy

**State specification**

**Functional specification**

**Operational Scenario**

**Module/object**
**specifications**

**The Design Hierarchy**

**Program requirements:**
**what the user needs**

**Program specifications:**
**what the program**
**does**

**High-level design:**
**how the program**
**works**

## The Implementation Hierarchy

**State specification**

**Functional specification**

**Operational Scenario**

**Module**
**source 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

## 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 && return**
**true || D in ASet :: Reset&& return false**

**D 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 and other states**
**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**

## A Partial State Specification 

**First&Only**

**the set has one member**
**N  = 1**

**ListState = 1**
**ListPosition = 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 in**
**ASet) || 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 **
**the 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.**

## 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. **

## Slide 39

## 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**

## 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.**