DOC PREVIEW
Toronto CSC 302 - Lecture 6 - Software Re-Engineering

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 6:Software Re-Engineering Cost of Software Maintenance Challenges of Design Recovery What reverse engineering tools can and can’t do Hints on abstraction and design recoveryUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Software Evolves ContinuouslycorrectiveadaptiveuserenhancementsperfectiveefficiencyotherpreventativeData from:van Vliet, H., Software Engineering: Principlesand Practices, Wiley 1999, p4492University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3User requirements always growTimeFunctionalityUser needsidentify requirementsfirst releaseenhancement phasefreeze and replacereplacement deliveredenhancement phaseconventionaldevelopmentLatenessShortfallInappropriatenessLongevityAdaptability(shaded area)(slope of line)Source: Adapted from Davis 1988, pp1453-1455University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Software GeriatricsCauses of Software AgingFailure to update the software to meet changing needsCustomers switch to a new product if benefits outweigh switching costsChanges to software tend to reduce coherence & increase complexityCosts of Software AgingOwners of aging software find it hard to keep up with the marketplaceDeterioration in space/time performance due to deteriorating structureAging software gets more buggyEach “bug fix” introduces more errors than it fixesWays of Increasing LongevityDesign for changeDocument the software carefullyRequirements and designs should be reviewed by those responsible for itsmaintenanceSoftware Rejuvenation…Source: Adapted from Parnas, “Software Aging” 19963University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Reducing Maintenance CostscorrectiveadaptiveuserenhancementsperfectiveefficiencyotherpreventativeHigher quality codeBetter testing (verification)Use of standardsPlatform independenceDesign for changeGood architectureBetter requirements analysisprototyping, iterative developmentDesign for changeGeneralModular structureComprehensibilityGood documentationUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6E.g. The Altimeter ExampleIF not-read1(V1) GOTO DEF1;display (V1);GOTO C;DEF1: IF not-read2(V2) GOTO DEF2;display(V2);GOTO C;DEF2: display(3000);C:if (read-meter1(V1)) display(V1);else { if (read-meter2(V2)) display(V2); else display(3000);}Questions:Should you refactor this code?Should you fix the default value?Source: Adapted from van Vliet 19994University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Why maintenance is hardPoor code qualityopaque codepoorly structured codedead codeLack of knowledge of the application domainunderstanding the implications of changeLack of documentationcode is often the only resourcemissing rationale for design decisionsLack of glamourSource: Adapted from van Vliet 1999University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8RejuvenationReverse EngineeringRe-documentation (same level of abstraction)Design Recovery (higher levels of abstraction)RestructuringRefactoring (no changes to functionality)Revamping (only the user interface is changed)Re-EngineeringReal changes made to the codeUsually done as round trip:design recovery -> design improvement -> re-implementationSource: Adapted from van Vliet 19995University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9Program ComprehensionDuring maintenance:programmers study the code about 1.5 times as long as the documentationprogrammers spend as much time reading code as editing itExperts have many knowledge chunks:programming plansbeaconsdesign patternsExperts follow dependency links…while novices read sequentiallyMuch knowledge comes from outside the codeSource: Adapted from van Vliet 1999University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10Example 1What does this do?for (i=0; i<n; i++) { for (j=0; j<n; j++) { if (A[i,j]) { for (k=0; k<n; k++) { if (A[j,k]) A[i,k]=true; } } }}Source: Adapted from van Vliet 19996University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 11Example 2procedure A(var x: w);begin b(y, n1); b(x, n2); m(w[x]); y := x; r(p[x]);end;procedure change_window(var nw: window);begin border(current_window, no_highlight); border(nw, highlight); move_cursor(w[nw]); current_window := nw; resume(process[nw]);end;Source: Adapted from van Vliet 1999University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 12What tools can doReformatters / documentation generatorsMake the code more readableAdd comments automaticallyImprove Code BrowsingE.g visualize and traverse a dependency graph(simple) Code transformationE.g. Refactoring class browsersE.g. Clone detectors(simple) Design RecoveryE.g. build a basic class diagramE.g. use program traces to build sequence diagrams7University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative


View Full Document

Toronto CSC 302 - Lecture 6 - Software Re-Engineering

Documents in this Course
Load more
Download Lecture 6 - Software Re-Engineering
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 6 - Software Re-Engineering and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 6 - Software Re-Engineering 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?