1. 1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 16 Component-Level Design

3. 3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Component-Level Design  the closest design activity to coding  the approach:  review the design description for the component  use stepwise refinement to develop algorithm  use structured programming to implement procedural logic  use ‘formal methods’ to prove logic

4. 4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Stepwise Refinement open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; take key out; find correct key; find correct key; insert in lock; insert in lock; endif pull/push door move out of way; end repeat

5. 5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Component-Level Design Model  represents the algorithm at a level of detail that can be reviewed for quality  options:  graphical (e.g. flowchart, box diagram)  pseudocode (e.g., PDL)... choice of many  programming language  decision table  conduct walkthrough to assess quality

6. 6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Structured Programming for Procedural Design uses a limited set of logical constructs: sequence conditional — if-then-else, select-case — if-then-else, select-case loops — do-while, repeat until — do-while, repeat until leads to more readable, testable code important for achieving high quality, but not enough

7. 7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 A Structured Procedural Design

8. 8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Decision Tables  List all actions that can be associated with a specific function.  List decisions made during the function.  Associate decisions with actions.  Define rules by indicating what actions occur for a set of conditions.  See pages 428-429

9. 9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Decision Table Conditions12345 Fixed rate acct. TTTTF Variable rate acct. FFFFT Payment on time TTFF Partial payment FTFT Actions Fixed Payment YY Late Charge YY Partial Payment YYY Variable Payment Y

10. 10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Program Design Language (PDL)

11. 11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 PDL  Example of PDL pages 430-431  PDL has the constructs and data definition.  PDL also allows English statements.  Fixed syntax + free syntax

12. 12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design Notation  Design notation should lead to a procedural representation that is easy to understand and review.  Attributes of good design notation are listed on the next 10 slides.

13. 13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Modularity  Design notation should support the development of modular software and provide a means for interface specification.  Page 432

14. 14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Overall Simplicity  Design notation should be relatively simple to learn, relatively easy to use, and generally easy to read.

15. 15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Ease of Editing  The procedural design may require modification as the software process proceeds.  The ease with which a design representation can be edited can help facilitate each software engineering task.

16. 16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Machine Readability  Notation that can be input directly into a computer-based development system offers significant benefits.

17. 17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Maintainability  Software maintenance is the most costly phase of the software life cycle.  Maintenance of the software configuration nearly always means maintenance of the procedural design representation.

18. 18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Structure Enforcement  The benefits of a design approach that uses structured programming concepts have already been discussed.  Design notation that enforces the use of only the structured constructs promotes good design practice.

19. 19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Automatic Processing  A procedural design contains information that can be processed to give the designer new or better insights into the correctness and quality of a design.  Such insight can be enhanced with reports provided via software design tools.

20. 20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Representation  The ability to represent local and global data is an essential element of component-level design.  Ideally, design notation should represent such data directly.

21. 21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Logic Verification  Automatic verification of design logic is a goal that is paramount during software testing.  Notation that enhances the ability to verify logic greatly improves testing adequacy.

22. 22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Code-to Ability  The software engineering task that follows component-level design is code generation.  Notation that may be converted easily to source code reduces effort and error.

23. 23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Summary Component Level Design  Three constructs  Sequence  Selection  Loop  Flowcharts and other graphical representations  Decision tables  Pseudocode and PDL