2 12 09 Software Design Principles and Guidelines Adam Porter Feb 10 2009 Overview Design Principles Important design concepts Useful design principles Design Guidelines Motivation Design Rules of Thumb 1 2 12 09 Goals of the Design Phase Identify the software architecture Decompose system into modules Modules are program units that should be independent have well specified interfaces and have high cohesion and low coupling Determine relationships between modules Identify module dependencies Determine the form and protocol for inter module communication Goals of the Design Phase cont d Specify module interfaces Interfaces should be well defined facilitate independent module testing improve group communication Describe module functionality Informally e g comments or documentation Formally e g via module interface specification languages 2 2 12 09 Notional Design Phases Preliminary design External design describes the real world model Architectural design decomposes the requirement specification into software subsystems Detailed design Specify each subsystem Further decompose subsystems if necessary Note in design phases the orientation moves from customer to developer From what to how Key Design Concepts and Principles Important design concepts and design principles Decomposition make big systems from smaller ones Abstraction suppress irrelevant details Modularity components should stand alone Information Hiding modules hide secrets Hierarchy limit inter module dependencies Separating Policy and Mechanism what how Each concept helps manage software system complexity and improve software quality 3 2 12 09 Decomposition Principle Design decomposes large systems into smaller pieces Basic concept is very simple 1 Select a piece of the problem initially all of it 2 Determine its components using some approach e g functional vs data structured vs object oriented 3 4 Determine how the components interact Repeat 1 3 until some termination criteria is met e g components can be implemented by 1 person in a few days Decomposition cont d What decomposition strategy should you use Execution steps Data types Programmer assignments 4 2 12 09 Abstraction Principle Decomposition strategy should yield abstractions Abstraction manages complexity by emphasizing essential characteristics and suppressing implementation details Allows postponement of certain design decisions Abstraction Something reduced to its essential characteristics Representations Algorithms Architecture Communications protocols Abstraction cont d Programming languages have continued to raise level of abstraction Procedural abstraction Data abstraction Control abstraction closed subroutines Abstract data types ADTs iterators loops atomic blocks etc 5 2 12 09 Modularity Principle Decomposition strategy should promote modularity Module A self contained software component Module characteristics should possess well specified abstract interfaces should have high cohesion and low coupling Modularity cont d Modularity facilitates software quality factors Extensibility well defined abstract interfaces Reusability low coupling high cohesion Compatibility design bridging interfaces Portability hide machine dependencies 6 2 12 09 Coupling Coupling is the interdependence of one module on another Modules should have low coupling Low coupling tends to limit the effect of changes Coupling created by Passing parameters Passing unnecessary data structures Communicating via shared signals Sharing global data Branching into referencing or modifying each other s data or statements Cohesion Intuitively cohesion refers to the assoc of elements within a module Elements should be strongly and genuinely related to each other and should support one well defined function or purpose High cohesion is desirable Note difficult to measure Examples of low cohesion Temporal cohesion e g do a bunch of unrelated things at shutdown Procedural cohesion e g unrelated functions done sequentially Sequential cohesion e g output of one function is input to another 7 2 12 09 More on Modularity Tactics for ensuring modular designs Language Support for Modular Units Few Interfaces Small Interfaces Explicit Interfaces Information Hiding Modularity Tactics cont d Language Support for Modular Units Modules must correspond to syntactic units in the language used Few Interfaces Every module should communicate with as few others as possible e g Law of Demeter www ccs neu edu home lieber LoD html Small Interfaces If any two modules communicate at all they should exchange as little information as possible 8 2 12 09 Modularity Tactics cont d Explicit Interfaces Whenever two modules A and B communicate this must be obvious from the text of A or B or both Information Hiding A module s internal details should be private to the module unless it is specifically declared public Information Hiding Principle Decomposition strategy should make change easier Information hiding is one kind of abstraction Details of design decisions that are subject to change should be hidden behind abstract interfaces Needs some extra language support Enforce communication only through well defined interfaces Desired outcome Each component exposes as little information as possible If internal details change client should be minimally affected Shorthand Modules encapsulate secrets 9 2 12 09 Information Hiding cont d Some examples of information that can be hidden Data representations Underlying data structures Algorithms Multiple variations of generic algorithm Input and Output Formats Machine dependencies byte ordering character codes Policy mechanism distinctions Lower level module interfaces Separating when vs how access control caching Ordering of low level operations The Open Closed Principle A satisfactory module decomposition technique should yield modules that are both open and closed Open Module is one still available for extension Necessary because requirements and specifications change Closed Module is one available for use by other modules usually given a well defined stable description and packaged in a library Necessary because otherwise changes ripple through user code 10 2 12 09 The Open Closed Principle cont d Modularity is not enough to support this principle Object oriented languages use interfaces inheritance and dynamic binding to solve this problem Hierarchy Principle reduce inter module dependencies by restricting the topology of their relationships A relation defines a hierarchy if it
View Full Document
Unlocking...