Design

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.