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 Design –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. 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

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

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

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 –documentors, 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 InternalExternal Attributes Constraints Inheritance Class Structure State MachineServices 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. Logic specification 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

22. Logic specification 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

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 InternalExternal Logic Specification Template Functional Specification Template State Specification Template Functional 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) 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

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 –the precise conditions that cause transitions from any other state to this state

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

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

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