Design

Lecture 5 – Practical Issues in DesignPart II

CIS 6101 – Software Processes and Metrics

2

Lecture 5: Design – Part 2Lecture 5: Design – Part 2

24

3

Practice 5: Design Patterns Practice 5: Design Patterns 1/61/6

►Design Patterns (Gamma et al 1995, GRASP Design Patterns (Gamma et al 1995, GRASP patterns, Gang of Four (GoF) Patterns, more) are patterns, Gang of Four (GoF) Patterns, more) are an invaluable resource for software developers.an invaluable resource for software developers. Patterns are a catalogue of solutions to frequently Patterns are a catalogue of solutions to frequently

encountered software development problems.encountered software development problems. Samples include:Samples include:

► Façade pattern, Façade pattern, ► Singleton patter, Singleton patter, ► Information expert, Information expert, ► Adaptor, Adaptor, ► Creator, Creator, ► Observer, Observer, ► Delegation, Delegation, ► Proxy, Proxy, ► Controller, …Controller, …

24

Practice 5: Design Patterns: Practice 5: Design Patterns: 2/62/6

►Trying to solve a known problem? Why Trying to solve a known problem? Why reinvent the wheel?reinvent the wheel?

►Common patterns were not invented. Common patterns were not invented. ►Were observed by some clever, experienced Were observed by some clever, experienced

software developers as software developers as solutionssolutions►Worked time and again in different projects Worked time and again in different projects ►Patterns: Patterns:

known to work, known to work, are heavily tested, and are heavily tested, and have known behavior. have known behavior.

24 4

5

Patterns continued…Patterns continued…3/63/6

► Common VocabularyCommon Vocabulary: The value of design : The value of design patterns as common vocabulary should not be patterns as common vocabulary should not be underestimated underestimated They are ‘named.’ They are ‘named.’

►Once a Once a common problem common problem is recognized as is recognized as fitting a design pattern, team can fitting a design pattern, team can focusfocus on on how the pattern might be how the pattern might be extendedextended toto satisfysatisfy the problem at hand. the problem at hand.

24

6

Common Problems w/Design Patterns Common Problems w/Design Patterns 4/64/6

► 1. Often Overzealously Used.1. Often Overzealously Used. Resulting software can be unnecessarily hard to Resulting software can be unnecessarily hard to

understand and modify due to the complex relationships understand and modify due to the complex relationships between classes. between classes.

Some projects sacrifice the rule of simple design for being Some projects sacrifice the rule of simple design for being clever.clever.

► 2. Design patterns are often used to solve problems 2. Design patterns are often used to solve problems where where a much simpler solution a much simpler solution is possible.is possible. DP are extremely reliable. They solve problems. DP are extremely reliable. They solve problems. Cannot solve all problems;Cannot solve all problems; Sometimes a more ad-hoc solution that involves a small bit Sometimes a more ad-hoc solution that involves a small bit

of code is even better because its simpler!!of code is even better because its simpler!! MistakeMistake: Thinking of design patterns before simplicity.: Thinking of design patterns before simplicity.

24

7

Common Problems w/Design Patterns Common Problems w/Design Patterns 5/65/6

► 3. Are too many different ways to code a pattern.3. Are too many different ways to code a pattern. DPs only provide an DPs only provide an outlineoutline forfor implementationimplementation,, Very possible to have implementations of patterns too Very possible to have implementations of patterns too

complex.complex.

► 4. Use of design patterns can lead to an unhealthy 4. Use of design patterns can lead to an unhealthy emphasis on up-front design.emphasis on up-front design. Some Some spend much time tryingspend much time trying to analyze a problem so a to analyze a problem so a

design patterns might apply. design patterns might apply. If you aren’t sure, If you aren’t sure, don’t use a patterndon’t use a pattern. . SimplicitySimplicity as always should be the primary goal. as always should be the primary goal.

► 5. If you don’t know design patterns, the code can 5. If you don’t know design patterns, the code can appear to be overly complex.appear to be overly complex. May be a very real problem when new developers join a May be a very real problem when new developers join a

project where patterns are used. project where patterns are used. 24

8

Common Problems w/Design Patterns Common Problems w/Design Patterns 6/66/6

24

9

Practice 6: Practice 6: Frequent Quick Design Meetings Frequent Quick Design Meetings (1 of (1 of

4)4)► ImportantImportant to ensure team ‘in on’ to ensure team ‘in on’ designdesign

ddiscussionsiscussions

►OutputsOutputs: shared understanding of : shared understanding of design issuesdesign issues and a and a lightweightlightweight artifactartifact (picture; whiteboard dgm) (picture; whiteboard dgm)

A A departuredeparture from more formal design meetings where from more formal design meetings where output is a output is a documentdocument..

After a After a shared understanding, learning, and shared understanding, learning, and collaborationcollaboration..

Emphasis should be on the Emphasis should be on the ►finished product finished product notnot thethe ►design documentation.design documentation.

24

10

Practice 6: Types of Design Meetings: Practice 6: Types of Design Meetings: ((Two)Two) Design DiscussionDesign Discussion and User and User Design Review 2/4Design Review 2/4►Design Discussion: Design Discussion:

Number of team members discuss design Number of team members discuss design decisions of any kind.decisions of any kind.

Held more frequently than design reviews; Held more frequently than design reviews;

Purely ad hoc, Purely ad hoc, Centered on an issueCentered on an issue A deeper discussion of one particular area A deeper discussion of one particular area

of design.of design. Example: discussion of retrieving on PAS, Example: discussion of retrieving on PAS,

FAC, and OSC and combinations of these FAC, and OSC and combinations of these keys.keys.

24

Practice 6: Types of Design Meetings:Practice 6: Types of Design Meetings:Design Discussion and Design Discussion and User Design ReviewUser Design Review

3/43/4► Design ReviewDesign Review: an opportunity for a team to analyze its : an opportunity for a team to analyze its

currentcurrent architecturearchitecture and discuss and discuss short and long range short and long range changeschanges to be made. to be made.

Should be held Should be held every nth iterationevery nth iteration or or added to the added to the agendaagenda in a retrospective. in a retrospective.

Designed to learn; provide Designed to learn; provide positive future design directionpositive future design direction

What areas of current design are What areas of current design are ►not working well not working well andand should be re-factored/rewritten should be re-factored/rewritten ►areas of the code that are too tightly coupled? areas of the code that are too tightly coupled? ►areas of the code that are going to be changed a great areas of the code that are going to be changed a great

deal with upcoming features but are difficult to deal with upcoming features but are difficult to understand or are fragile?understand or are fragile?

12

Results of Meetings Results of Meetings 4/44/4

► A A listlist of of prioritizedprioritized problem areas, problem areas, ► Commitment to Incorporate itemsCommitment to Incorporate items into into

upcoming iterations, and upcoming iterations, and ► Ensure all is Ensure all is recordedrecorded in some kind of bug- in some kind of bug-

tracking system for action.tracking system for action.

► All this presents opportunities to learn about All this presents opportunities to learn about good design and bad design.good design and bad design.

► Excellent opportunity for Excellent opportunity for experiencedexperienced developers to pass on knowledge to developers to pass on knowledge to newbeesnewbees..

24

13

Practice 7: Commitment to Re-architecture Practice 7: Commitment to Re-architecture 1/61/6► Refactoring is powerful but sometimes it may Refactoring is powerful but sometimes it may

be necessary to be necessary to re-architect and replacere-architect and replace some portion to a product. some portion to a product. Especially in a Redesign Effort vice Greenfield Especially in a Redesign Effort vice Greenfield

developmt. developmt.

► Sometimes it may be Sometimes it may be betterbetter to re-architectto re-architect than to try to than to try to bendbend the current the current architecturearchitecture to the require direction. to the require direction.

► Should be looked at Should be looked at as preventive maintenance. as preventive maintenance.

24

14

Practice 7: Re-Architecting…Practice 7: Re-Architecting…2/62/6

►Some of the most common reasons for Some of the most common reasons for considering a re-architecting may be:considering a re-architecting may be: 1. A team has just released the first 1. A team has just released the first

versions of the product.versions of the product.

Bound to make mistakes here, because the Bound to make mistakes here, because the team is learning about the product’s eco-team is learning about the product’s eco-system as they are developing. system as they are developing.

We learn a great deal about the application We learn a great deal about the application area and development AS we develop.area and development AS we develop.

24

15

► 2. Sometimes a product was written for a 2. Sometimes a product was written for a single platformsingle platform (OS, database, networking (OS, database, networking protocol…) and it needs to be protocol…) and it needs to be portedported to a to a new platform.new platform.

Porting is a great opportunity to Porting is a great opportunity to introduce introduce greater abstractiongreater abstraction to hide the platform- to hide the platform-dependent implementations.dependent implementations.

When done well, this type of abstraction should When done well, this type of abstraction should simplify the application and make it easier to simplify the application and make it easier to modify in the future. modify in the future.

Practice 7: Re-Architecting…Practice 7: Re-Architecting…3/63/6

24

16

Practice 7: Re-Architecting…Practice 7: Re-Architecting…4/64/6

►3. There have been 3. There have been changes to the changes to the underlying technologyunderlying technology such as such as system APIs or third party libraries on system APIs or third party libraries on which the app depends.which the app depends.

24

17

Practice 7: Re-Architecting Practice 7: Re-Architecting 5/65/6

► A A single threaded application needs to single threaded application needs to be multi-threadedbe multi-threaded. . If the goal is to If the goal is to maximize the usage of multiple maximize the usage of multiple

processorsprocessors, single-threaded software most often , single-threaded software most often needs to be rewritten to break up its tasks into needs to be rewritten to break up its tasks into separate units of computation.separate units of computation.

►Without rework, usually the only work that Without rework, usually the only work that can be done is to can be done is to optimize loopsoptimize loops or or small small sections of codesections of code.. This type of optimization This type of optimization will not maximize use will not maximize use

of additional processors.of additional processors.24

18

Practice 7: Re-Architecting Practice 7: Re-Architecting 6/66/6

►Sometimes a section of code is Sometimes a section of code is particularly defect prone, particularly defect prone, is difficult to modify, is difficult to modify, and/or excessively coupled to other and/or excessively coupled to other

sections of the architecture.sections of the architecture.

Break it up. Divide and conquer. Be Break it up. Divide and conquer. Be simple.simple.

24

19

Practice 8: Design for Reuse Practice 8: Design for Reuse 1/51/5

► Reusable software has fewer defects and Reusable software has fewer defects and cleaner interfaces than non-reusable software.cleaner interfaces than non-reusable software.

►We We don’t wantdon’t want to duplicate code. to duplicate code.►We want to We want to reusereuse code. code.

►When coupled with When coupled with automated testsautomated tests of the of the interfaces for each use, the resulting software interfaces for each use, the resulting software has a much greater chance of being extremely has a much greater chance of being extremely low in defects than if it were used only once.low in defects than if it were used only once.

24

20

Practice 8: Reusable Software Practice 8: Reusable Software Doesn’t Emerge Doesn’t Emerge 2/52/5

Some key architectural decisionsSome key architectural decisions may need to may need to be made as be made as earlyearly as possible and carried through as possible and carried through the project to make the project to make subsequentsubsequent workwork easiereasier and and lessless proneprone to needing to be redone. to needing to be redone.

► Example: If Example: If extensibilityextensibility is possible is possible design the plug in architecture early and design the plug in architecture early and then use it heavily, then use it heavily, so that all new features are developed as plug-ins.so that all new features are developed as plug-ins.

► Without this up front design architecture work, Without this up front design architecture work, the risk is that the system might be extensible the risk is that the system might be extensible butbut notnot in a sustainable way.in a sustainable way.

24

21

Practice 8: Why Reusable Code? Practice 8: Why Reusable Code? 3/53/5

► ToTo eliminateeliminate duplicatedduplicated code!code!► Tempting to just Tempting to just copy and pastecopy and paste a section of code. a section of code.

May be savings in effort in the short term, but over the May be savings in effort in the short term, but over the long term, will be large amount of wasted effort.long term, will be large amount of wasted effort.

► Duplicated code Duplicated code not onlynot only makes the size of the program larger, makes the size of the program larger, but alsobut also adds to adds to

►complexity and is a common source of error complexity and is a common source of error

Problem is Problem is fixedfixed in in one copyone copy of code but of code but notnot anotheranother..

24

22

Practice 8: Reusable Software Practice 8: Reusable Software 4/54/5

►ReusableReusable softwaresoftware also also easeseases replaceabilityreplaceability..

► If some portion of the architecture needs to If some portion of the architecture needs to be replaced, be replaced, it is always easierit is always easier to to taketake outout oneone section and change its interfacessection and change its interfaces than it is to try and than it is to try and replacereplace entire system. entire system.

► No interface changes required? Better.No interface changes required? Better.► At least we can At least we can

reuse automated tests on the reuse automated tests on the interfaceinterface to ensure to ensure your new implementation has the your new implementation has the same behaviorsame behavior..

24

23

Practice 8: Completely Practice 8: Completely Componentized Software not a Componentized Software not a New Idea New Idea 5/55/5► Notion of has been around since the introduction of Notion of has been around since the introduction of

OOP. OOP. ► The notion of software ICs (software chips that can be The notion of software ICs (software chips that can be

wired together much like chips on a printed circuit wired together much like chips on a printed circuit board) comes from the success of board) comes from the success of product line product line manufacturingmanufacturing..

► Idea of fully componentized reuse as in manufacturing Idea of fully componentized reuse as in manufacturing still largely eludes the software industry.still largely eludes the software industry.

► ► However, despite the complexity, still possible to attain However, despite the complexity, still possible to attain

a high degree of reuse.a high degree of reuse.► This aids sustainability by allowing teams to be more This aids sustainability by allowing teams to be more

responsive to opportunities and to avoid duplicating responsive to opportunities and to avoid duplicating effort.effort.

24