1 / 23

Design

Design. Lecture 5 – Practical Issues in Design Part II CIS 6101 – Software Processes and Metrics. Lecture 5: Design – Part 2. Practice 5: Design Patterns 1/6.

hunter-goff
Download Presentation

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. Design Lecture 5 – Practical Issues in Design Part II CIS 6101 – Software Processes and Metrics

  2. Lecture 5: Design – Part 2

  3. Practice 5: Design Patterns 1/6 • Design Patterns (Gamma et al 1995, GRASP patterns, Gang of Four (GoF) Patterns, more) are an invaluable resource for software developers. • Patterns are a catalogue of solutions to frequently encountered software development problems. • Samples include: • Façade pattern, • Singleton patter, • Information expert, • Adaptor, • Creator, • Observer, • Delegation, • Proxy, • Controller, …

  4. Practice 5: Design Patterns: 2/6 • Trying to solve a known problem? Why reinvent the wheel? • Common patterns were not invented. • Were observed by some clever, experienced software developers as solutions • Worked time and again in different projects • Patterns: • known to work, • are heavily tested, and • have known behavior.

  5. Patterns continued…3/6 • Common Vocabulary: The value of design patterns as common vocabulary should not be underestimated • They are ‘named.’ • Once a common problem is recognized as fitting a design pattern, team can focus on how the pattern might be extendedtosatisfy the problem at hand.

  6. Common Problems w/Design Patterns 4/6 • 1. Often Overzealously Used. • Resulting software can be unnecessarily hard to understand and modify due to the complex relationships between classes. • Some projects sacrifice the rule of simple design for being clever. • 2. Design patterns are often used to solve problems where a much simpler solution is possible. • DP are extremely reliable. They solve problems. • Cannot solve all problems; • Sometimes a more ad-hoc solution that involves a small bit of code is even better because its simpler!! • Mistake: Thinking of design patterns before simplicity.

  7. Common Problems w/Design Patterns 5/6 • 3. Are too many different ways to code a pattern. • DPs only provide an outlineforimplementation, • Very possible to have implementations of patterns too complex. • 4. Use of design patterns can lead to an unhealthy emphasis on up-front design. • Some spend much time trying to analyze a problem so a design patterns might apply. • If you aren’t sure, don’t use a pattern. • Simplicity as always should be the primary goal. • 5. If you don’t know design patterns, the code can appear to be overly complex. • May be a very real problem when new developers join a project where patterns are used.

  8. Common Problems w/Design Patterns 6/6 • In sum, DPs are valuable • Shouldn’t be ignored. • Simple design practice, • teamwork, • experience, • knowledge and • collaboration • are the best ways to minimize the risks in design while maximizing he potential returns.

  9. Practice 6: Frequent Quick Design Meetings (1 of 4) • Important to ensure team ‘in on’ design discussions • Outputs: shared understanding of design issues and a lightweightartifact (picture; whiteboard dgm) • A departure from more formal design meetings where output is a document. • After a shared understanding, learning, and collaboration. • Emphasis should be on the • finished product notthe • design documentation.

  10. Practice 6: Types of Design Meetings: (Two)Design Discussion and User Design Review 2/4 • Design Discussion: • Number of team members discuss design decisions of any kind. • Held more frequently than design reviews; • Purely ad hoc, • Centered on an issue • A deeper discussion of one particular area of design. • Example: discussion of retrieving on PAS, FAC, and OSC and combinations of these keys.

  11. Practice 6: Types of Design Meetings:Design Discussion and User Design Review 3/4 • Design Review: an opportunity for a team to analyze its currentarchitecture and discuss short and long range changes to be made. • Should be held every nth iteration or added to the agenda in a retrospective. • Designed to learn; provide positive future design direction • What areas of current design are • not working well and should be re-factored/rewritten • areas of the code that are too tightly coupled? • areas of the code that are going to be changed a great deal with upcoming features but are difficult to understand or are fragile?

  12. Results of Meetings 4/4 • A list of prioritized problem areas, • Commitment to Incorporate items into upcoming iterations, and • Ensure all is recorded in some kind of bug-tracking system for action. • All this presents opportunities to learn about good design and bad design. • Excellent opportunity for experienced developers to pass on knowledge to newbees.

  13. Practice 7: Commitment to Re-architecture 1/6 • Refactoring is powerful but sometimes it may be necessary to re-architect and replace some portion to a product. • Especially in a Redesign Effort vice Greenfield developmt. • Sometimes it may be betterto re-architect than to try to bend the current architecture to the require direction. • Should be looked at • as preventive maintenance.

  14. Practice 7: Re-Architecting…2/6 • Some of the most common reasons for considering a re-architecting may be: • 1. A team has just released the first versions of the product. • Bound to make mistakes here, because the team is learning about the product’s eco-system as they are developing. • We learn a great deal about the application area and development AS we develop.

  15. Practice 7: Re-Architecting…3/6 • 2. Sometimes a product was written for a single platform (OS, database, networking protocol…) and it needs to be ported to a new platform. • Porting is a great opportunity to introduce greater abstraction to hide the platform-dependent implementations. • When done well, this type of abstraction should simplify the application and make it easier to modify in the future.

  16. Practice 7: Re-Architecting…4/6 • 3. There have been changes to the underlying technology such as system APIs or third party libraries on which the app depends.

  17. Practice 7: Re-Architecting 5/6 • A single threaded application needs to be multi-threaded. • If the goal is to maximize the usage of multiple processors, single-threaded software most often needs to be rewritten to break up its tasks into separate units of computation. • Without rework, usually the only work that can be done is to optimize loops or small sections of code. • This type of optimization will not maximize use of additional processors.

  18. Practice 7: Re-Architecting 6/6 • Sometimes a section of code is • particularly defect prone, • is difficult to modify, • and/or excessively coupled to other sections of the architecture. • Break it up. Divide and conquer. Be simple.

  19. Practice 8: Design for Reuse 1/5 • Reusable software has fewer defects and cleaner interfaces than non-reusable software. • We don’t want to duplicate code. • We want to reuse code. • When coupled with automated tests of the interfaces for each use, the resulting software has a much greater chance of being extremely low in defects than if it were used only once.

  20. Practice 8: Reusable Software Doesn’t Emerge 2/5 Some key architectural decisions may need to be made as early as possible and carried through the project to make subsequentworkeasier and lessprone to needing to be redone. • Example: If extensibility is possible • design the plug in architecture early and • then use it heavily, • so that all new features are developed as plug-ins. •  Without this up front design architecture work, the risk is that the system might be extensible butnotin a sustainable way.

  21. Practice 8: Why Reusable Code? 3/5 • Toeliminateduplicatedcode! • Tempting to just copy and paste a section of code. • May be savings in effort in the short term, but over the long term, will be large amount of wasted effort. • Duplicated code • not only makes the size of the program larger, • but also adds to • complexity and is a common source of error • Problem is fixed in one copy of code but notanother.

  22. Practice 8: Reusable Software 4/5 • Reusablesoftware also easesreplaceability. • If some portion of the architecture needs to be replaced, it is always easier to takeoutonesection and change its interfaces than it is to try and replace entire system. • No interface changes required? Better. • At least we can • reuse automated tests on the interface to ensure your new implementation has the same behavior.

  23. Practice 8: Completely Componentized Software not a New Idea 5/5 • Notion of has been around since the introduction of OOP. • The notion of software ICs (software chips that can be wired together much like chips on a printed circuit board) comes from the success of product line manufacturing. • Idea of fully componentized reuse as in manufacturing still largely eludes the software industry. • However, despite the complexity, still possible to attain a high degree of reuse. • This aids sustainability by allowing teams to be more responsive to opportunities and to avoid duplicating effort.

More Related