Design Review Issues SE280 Dr Mark L Hornick

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

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

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?

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

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

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

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

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.

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.