1. SE-280 Dr. Mark L. Hornick Design Review Issues

2. SE-280 Dr. Mark L. Hornick 2 Many expensive defects are a result of design problems Software applications need a solid design to be robust – how should designs be specified, and exactly should be reviewed?

3. Even for experienced software developers, design review can be a special problem What kinds of design defects have you found so far? Do you actually have designs that are documented well enough to find real defects in a design review?

4. SE-280 Dr. Mark L. Hornick 4 While PSP focuses on process rather than practice, Design plays an important role So the real question may not be whether to design, but when Coding always involves some level of design, but design during coding mixes different levels of abstraction.

5. SE-280 Dr. Mark L. Hornick 5 The PSP textbook breaks design concerns down into four categories. Inheritance Class Structure Attributes Program Structure Logic Services Messages State Machine ExternalInternal Static Dynamic Inheritance Class Structure Attributes Program Structure Logic Services Messages

6. SE-280 Dr. Mark L. Hornick 6 Four PSP design templates are suggested as ways to document these design concerns. Functional Specification Template (partial) Logic Specification Template Functional Specification Template (partial) Operational Specification Template State Specification Template ExternalInternal Static Dynamic

7. SE-280 Dr. Mark L. Hornick 7 For UML design documentation, these concerns are addressed in similar ways. Class diagrams with embedded descriptions Preconditions, postconditions, and behavior descriptions Use cases and UC diagrams Sequence, Activity, and Communication diagrams State diagrams, Psuedocode ExternalInternal Static Dynamic

8. A functional specification template (FST) in some ways resembles a UML class diagram. Like a UML class diagram, the FST specifies: attributes – name, type, initial value operations – name, arguments, return type However, the FST include additional information: attributes:description of use, constraints operations:contract description: precondition, postcondition, behavior This additional information can be maintained in a UML tool like Enterprise Architect, in the source code (e.g., Javadoc), or both (e.g., code generation). Even if this information is documented in the source code, this activity would normally be done in the design (not coding) phase. It may be beneficial to use formal notation (e.g., JML) to represent design contracts, but that topic is beyond the scope of this course.

9. A Logical Specification Template (LST) specifies details of the planned program logic. The idea is to spell out how the program logic (e.g., for a particular method or set of related methods) will work, including logical tests, loops, functional decomposition, etc. Some of this information can be documented in one or more UML sequence diagrams or activity diagrams (flowcharts) Another common approach is to write pseudo-code (higher-level description of program flow and operations), often in source code comments.