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

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

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

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 Object Specification 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

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

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

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 Object Specification Static Dynamic Internal External Logic Template Functional State Specification & Operational Scenario Templates

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) :: 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)

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* EmptySet First&Only FirstOfSeveral MiddleOfSeveral LastOfSeveral *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 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

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.

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.