Design Review Issues

1. Design Review Issues SE-280Dr. 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? SE-280Dr. Mark L. Hornick

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. 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. SE-280Dr. Mark L. Hornick

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

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

7. For UML design documentation, these concerns are addressed in similar ways. External Internal Class diagrams withembedded descriptions Preconditions,postconditions,and behaviordescriptions Static Use cases andUC diagrams Sequence, Activity, and Communicationdiagrams State diagrams, Psuedocode Dynamic SE-280Dr. Mark L. Hornick

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.