1 / 35

Lecture # 17 Good Software Design

SWE 316: Software Design and Architecture. Handout. Lecture # 17 Good Software Design. Practical tips for creating good design Introduce practical tips for creating good design. The slides and the material of this chapter are adopted from:

melita
Download Presentation

Lecture # 17 Good Software Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SWE 316: Software Design and Architecture Handout Lecture # 17Good Software Design • Practical tips for creating good design • Introduce practical tips for creating good design The slides and the material of this chapter are adopted from: “Object-Oriented Software Engineering: Practical Software Development using UML and Java”, 2nd Ed. By Timothy C. Lethbridge and Robert Laganière

  2. 2/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Topics: Principles leading to good design • DP 1: divide and conquer • DP 2: increase cohesion where possible • DP 3: reduce coupling where possible • DP 4: keep the level of abstraction as high as possible • DP 5: increase reusability where possible • DP 6: reuse existing designs and code where possible • DP 7: design for flexibility • DP 8: anticipate obsolescence • DP 9: design for portability • DP 10: design for testability • DP 11: design defensively

  3. 3/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Principles leading to good design • Overall goals of good design: • Increasing profit by reducing cost and increasing revenue • Ensuring that we actually conform with the requirements • Accelerating development • Increasing qualities such as Usability Efficiency Reliability Maintainability Reusability

  4. 4/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 1: divide and conquer • Trying to deal with something big all at once is normally much harder than dealing with a series of smaller things • Separate people can work on each part. • An individual software engineer can specialize. • Each individual component is smaller, and therefore easier to understand. • Parts can be replaced or changed without having to replace or extensively change other parts.

  5. 5/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Ways of dividing a software system • A distributed system is divided up into clients and servers • A system is divided up into subsystems • A subsystem can be divided up into one or more packages • A package is divided up into classes • A class is divided up into methods

  6. 6/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 2: increase cohesion where possible • A subsystem or module has high cohesion if it keeps together things that are related to each other, and keeps out other things • This makes the system as a whole easier to understand and change • Type of cohesion: -Functional -Layer -Communicational -Sequential -Procedural -Temporal -Utility

  7. 7/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 2: increase cohesion where possible (2)

  8. 8/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 2: increase cohesion where possible (3)

  9. 9/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 2: increase cohesion where possible (4) • Mixing different types of cohesion

  10. 10/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 3: Reduce coupling where possible • Coupling occurs when there are interdependencies between one module and another • When interdependencies exist, changes in one place will require changes somewhere else. • A network of interdependencies makes it hard to see at a glance how some component works. • Type of coupling: -Content -Common -Control -Stamp -Data -Routine Call -Type use -Inclusion/Import -External

  11. 11/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 3: Reduce coupling where possible

  12. 12/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 3: Reduce coupling where possible

  13. 13/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 3: Reduce coupling where possible • Content Coupling • A module modifies data that is internal to another component • It should always be AVOIDED • e.g., modify public instance variable

  14. 14/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 3: Reduce coupling where possible • Control Coupling • This occurs when one procedure calls another using a ‘flag’ or ‘command’ that explicitly controls what the second procedure does.

  15. 15/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 3: Reduce coupling where possible • Stamp Coupling • This occurs whenever a class is declared as the type of a method argument. • Some stamp coupling is necessary • What’s wrong in this implementation?

  16. 16/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 4: Abstraction as high as possible • Abstractions --- keeping things simple ! • keep the level of abstraction as high as possible • Ensure that your designs allow you to hide or defer consideration of details, thus reducing complexity • A good abstraction is said to provide information hiding • Abstractions allow you to understand the essence of a subsystem without having to know unnecessary details

  17. 17/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Abstraction and classes • Classes are data abstractions that contain procedural abstractions • Abstraction is increased by defining all variables as private. • The fewer public methods in a class, the better the abstraction • Superclasses and interfaces increase the level of abstraction • Attributes and associations are also data abstractions. • Methods are procedural abstractions • Better abstractions are achieved by giving methods fewer parameters

  18. 18/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 5: Increase reusability where possible • Design for reuse ---- Design with reuse • Design the various aspects of your system so that they can be used again in other contexts • Generalize your design as much as possible • Follow the preceding three design principles • Increase cohesion • Reduce coupling • Increase abstraction • Simplify your design as much as possible

  19. 19/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 5: Increase reusability where possible • How? • Generalize your design as much as possible • Save instances of Employee class in a binary file • Instead, consider saving any class to binary file • Another example, generalize sorting • Design your system with hooks • An aspect of the design deliberately added to allow other designers to add additional functionality • Extensible compiler example

  20. 20/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 6: reuse existing designs and code • Design with reuse is complementary to design for reusability • Actively reusing designs or code allows you to take advantage of the investment you or others have made in reusable components

  21. 21/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 7: design for flexibility (adaptability) • Actively anticipate changes that a design may have to undergo in the future, and prepare for them • Reduce coupling and increase cohesion • Create abstractions • Do not hard-code anything • E.g., constants should be in a configuration file • Leave all options open • Do not restrict the options of people who have to modify the system later • Use reusable code and make code reusable

  22. 22/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 8: Anticipate Obsolescence • Plan for changes in the technology or environment so the software will continue to run or can be easily changed • Avoid using early releases of technology • Avoid using software libraries that are specific to particular environments • Avoid using undocumented features or little-used features of software libraries • Avoid using software or special hardware from companies that are less likely to provide long-term support • Use standard languages and technologies that are supported by multiple vendors

  23. 23/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 9: design for portability • Have the software run on as many platforms as possible • Avoid the use of facilities that are specific to one particular environment • E.g. a library only available in Microsoft Windows • Some programming languages, such as Java, make this easy because the language itself is designed to allow software to run on different platforms unchanged. • Another important portability issue has to do with text files: the characters used to terminate lines differ from platform to platform.

  24. 24/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 10: Design for Testability • Take steps to make testing easier • Design a program to automatically test the software • Ensure that all the functionality of the code can by driven by an external program, bypassing a graphical user interface • In Java, you can create a main() method in each class in order to exercise the other methods

  25. 25/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 11: Design defensively • Never trust how others will try to use a component you are designing • Handle all cases where other code might attempt to use your component inappropriately • Check that all of the inputs to your component are valid: the preconditions • Example: method to check if a certain date is working day

  26. 26/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 11: Design defensively • What’s wrong with this implementation? • Design by Contract • Each method has a specific contract with its caller

  27. 27/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions DP 11: Design defensively • Using Asserting • identify possible logic errors during development.

  28. 28/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Techniques for making good design decisions • Using priorities and objectives to decide among alternatives • Step 1: List and describe the alternatives for the design decision. • Step 2: List the advantages and disadvantages of each alternative with respect to your objectives and priorities. • Step 3: Determine whether any of the alternatives prevents you from meeting one or more of the objectives. • Step 4: Choose the alternative that helps you to best meet your objectives. • Step 5: Adjust priorities for subsequent decision making.

  29. 29/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Example priorities and objectives • Imagine a system has the following objectives, starting with top priority: • Security: Encryption must not be breakable within 100 hours of computing time on a 400Mhz Intel processor, using known cryptanalysis techniques. • Maintainability. No specific objective. • CPU efficiency. Must respond to the user within one second when running on a 400MHz Intel processor. • Network bandwidth efficiency: Must not require transmission of more than 8KB of data per transaction. • Memory efficiency. Must not consume over 20MB of RAM. • Portability. Must be able to run on Windows 98, NT 4 and ME as well as Linux

  30. 30/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Example evaluation of alternatives

  31. 31/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Example evaluation of alternatives

  32. 32/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Cost-benefit analysis to choose among alternatives • To estimate the costs, add up: • The incremental cost of doing the software engineering work, including ongoing maintenance • The incremental costs of any development technology required • The incremental costs that end-users and product support personnel will experience • To estimate the benefits, add up: • The incremental software engineering time saved • The incremental benefits measured in terms of either increased sales or else financial benefit to users

  33. 33/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Some general principles of good design • Use good design patterns, patterns of call-return or cooperative objects, event-structure should be consistent • Modular – logically partitioned into elements that perform specific functions and sub-functions. • Should have distinct representations of data, interfaces and components • Functions and components should be independent • Interfaces between components should be kept as simple as possible. • Use a repeatable method that transforms the requirements through analysis to high-level and then low-level design • Don’t reinvent the wheel.

  34. 34/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions CRC cards • CRC stands for Classes, Responsibilities, Collaborations. • CRC cards allow people to break away from the procedural mode of thought and more fully appreciate object technology. • One common way of checking for a good design and guiding its refinement is to use CRC cards. • Although CRC is not part of UML, they add some very useful insights throughout a development.

  35. 35/35 Intro Principles (1-2) Principles (3-4) Principles (5-7) Principles (8-11) Design Decisions Summary • Overall goals of good design: • Increasing profit by reducing cost and increasing revenue • Ensuring that we actually conform with the requirements • Accelerating development • Increasing qualities such as • Design principles leading to good design: • Divide and conquer • Increase cohesion where possible • Reduce coupling where possible • Keep the level of abstraction as high as possible • Increase reusability where possible • Reuse existing designs and code where possible • Design for flexibility • Anticipate obsolescence • Design for portability • Design for testability • Design defensively

More Related