Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Design Derived from Dr. Fawcett’s slides CSE784 – Software Studio Fall 2009.

Similar presentations


Presentation on theme: "Software Design Derived from Dr. Fawcett’s slides CSE784 – Software Studio Fall 2009."— Presentation transcript:

1 Software Design Derived from Dr. Fawcett’s slides CSE784 – Software Studio Fall 2009

2 Software Design 2 Software Development Strategy: Organizing ideas and structure Strategy: Organizing ideas and structure –Uses –Partitions and responsibilities –Critical issues Tactics Implementing ideas and structure Tactics Implementing ideas and structure –Activities –Classes and relationships –Algorithms –Data management StrategyTactics ArchitectureDesignImplementation

3 Software Design 3 Design Goals Make each software Component: Design Goals Make each software Component: Simple Simple Understandable Understandable Maintainable Maintainable Selectable Selectable Reusable Reusable Reliable Reliable Robust Robust Flexible Flexible Extendable Extendable

4 Software Design 4 Design Goals: Simplicity Small functions Small functions –Lines of code ≤ 50 Low cyclomatic complexity Low cyclomatic complexity –All functions CC ≤ 10 –Average much lower Small number of functions Small number of functions –Functions per module ≤ 20 –Average much lower

5 Software Design 5 Design Goals: Understandable Self documented Self documented –Manual page read about operations and interface read about operations and interface –Maintenance page see how to build see how to build –Test stub see how it works see how it works Descriptive names Descriptive names –Name describes operation or result Simple Simple

6 Software Design 6 Design Goals: Maintainable Maintenance consists of Maintenance consists of –Fixing latent errors –Modifying existing functionality –Adding new functionality Is maintainable if: Is maintainable if: –Needs no maintenance So simple it obviously has no defects So simple it obviously has no defects Additions made by composing with new components Additions made by composing with new components –Or easy to fix, modify, and extend Used through interface so changes don’t propagate Used through interface so changes don’t propagate Interface can be bound to new implementations Interface can be bound to new implementations Simple so easy to test Simple so easy to test

7 Software Design 7 Design Goals: Selectable Five million lines of code project Five million lines of code project –Has roughly 10, 000 modules Average of 500 lines of code per module Average of 500 lines of code per module –10 functions with 50 lines of code each Need ways to find parts to salvage and reuse Need ways to find parts to salvage and reuse –Need to make quick decisions Localize candidates by functionality or application Localize candidates by functionality or application –has operational summaries in prologue and manual page –Need to quickly evaluate candidates Easy to build Easy to build –has maintenance information with build process Easy to run Easy to run –has test stub

8 Software Design 8 Design Goals: Reusable Selectable Selectable –Has prologue and Manual Page Understandable Understandable –Has module operation description –Meaningful names –Simple structure Low fan-out Low fan-out –Dependent on very few other components Needs no application specific code Needs no application specific code –Uses delegates –Provides base class “hook”

9 Software Design 9 Design Goals: Reliable Understandable model Understandable model No surprises No surprises –Operates according to known model –Processing is repeatable –No race conditions or deadlocks Thoroughly tested Thoroughly tested

10 Software Design 10 Design Goals: Robust Will not crash with unexpected inputs or environment Will not crash with unexpected inputs or environment –Can use AppDomain partitions to isolate processing –Use exception handling to trap unexpected events –Validate user input, especially strings and paths

11 Software Design 11 Design Goals: Flexible Changes don’t propagate Changes don’t propagate –Provide an interface so users don’t bind to your implementation –Change to some implementation detail won’t cause changes to other components Supports changes of implementation Supports changes of implementation –Interfaces guarantee substitutability of any implementing class –Change of entire implementation won’t break using classes

12 Software Design 12 Design Goals: Extendable Supports addition of new implementation Supports addition of new implementation –Use of interface and object factory supports adding new component –No changes to users of the interface and factory

13 End Presentation Software Design 13


Download ppt "Software Design Derived from Dr. Fawcett’s slides CSE784 – Software Studio Fall 2009."

Similar presentations


Ads by Google