Disciplined Software Engineering Lecture #10

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. Initial Requirements 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

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

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

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. Object Specification Internal External Static Attributes Constraints Inheritance Class Structure Dynamic State Machine Services Messages Design Dimensions

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

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

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

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) :: insert D at position 1 && Reset void Push(data D) 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)

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. EmptySet First&Only FirstOfSeveral MiddleOfSeveral LastOfSeveral Example State Machine* *Note: the transitions of a state to itself are not shown

31. A Partial State Specification First&Only the set has one member N = 1 ListState = 1 ListPosition = 1 Clear || Pop || (SubtractSet(D) && D in ASet) EmptySet Reset || StepForward || StepBackward || (AddSet(D) && D in ASet) || (SubtractSet(D) && D not in ASet) || MemberSet || Empty || Last || Status || Position First&Only FirstOfSeveral Push || (AddSet(D) && D not in ASet) Impossible MiddleOfSeveral LastOfSeveral 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.