1!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1 Lecture 6:!Software Re-Engineering" Why software evolves continuously" Costs of Software Evolution" Challenges of Design Recovery" What reverse engineering tools can and canʼt do"University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2 The Altimeter Example"IF 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 19992!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3 Software Evolves Continuously"21%25%4%43%4%3%corrective adaptive user enhancements efficiency other preventative Data from:!van Vliet, H., Software Engineering: Principles and Practices, Wiley 1999, p449!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4 Program Types"S-type Programs (“Specifiable”)"problem can be stated formally and completely"acceptance: Is the program correct according to its specification?"“evolution” not relevant"A new specification defines a new problem"P-type Programs (“Problem-solving”)"imprecise statement of a real-world problem"acceptance: Is the program an acceptable solution to the problem?"This software may evolve continuously"the solution is never perfect, and can be improved"the real-world changes and hence the problem changes"E-type Programs (“Embedded”)"software that becomes part of the world that it models"acceptance: depends entirely on opinion and judgment"This software is inherently evolutionary"changes in the software and the world affect each other"Source: Adapted from Lehman 1980, pp1061-10633!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5 real world requirements specification PROGRAM abstract view of world solution compare P-type real world PROGRAM abstract view of world requirements specification model E-type formal statement of problem PROGRAM solution real world controls the production of provides maybe of interest to may relate to change change change S-type Source: Adapted from Lehman 1980, pp1061-1063 University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6 Source: Adapted from Lehman 1980, pp1061-1063 Laws of Program Evolution"Continuing Change"Any software that reflects some external reality undergoes continual change or becomes progressively less useful"change continues until it is judged more cost effective to replace the system"Increasing Complexity"As software evolves, its complexity increases… "…unless steps are taken to control it."Fundamental Law of Program Evolution"Software evolution is self-regulating"…with statistically determinable trends and invariants"Conservation of Organizational Stability"During the active life of a software system, the work output of a development project is roughly constant (regardless of resources!)"Conservation of Familiarity"The amount of change in successive releases is roughly constant"4!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7 User requirements always grow"Time Functionality User needs conventional development Lateness Shortfall Inappropriateness Longevity Adaptability (shaded area) (slope of line) Source: Adapted from Davis 1988, pp1453-1455 University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8 E.g. Logica Financial Software"(Source: Lehman et al, 2000)5!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9 E.g. Linux Kernal"(Source: Godfrey & Tu, 2000) University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10 E.g. Hadley Centre Climate Model"6!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 11 Software Geriatrics"Causes of Software Aging"Failure to update the software to meet changing needs"Customers switch to a new product if benefits outweigh switching costs"Changes to software tend to reduce coherence & increase complexity"Costs of Software Aging"Owners of aging software find it hard to keep up with the marketplace"Deterioration in space/time performance due to deteriorating structure"Aging software gets more buggy"Each “bug fix” introduces more errors than it fixes"Ways of Increasing Longevity"Design for change"Document the software carefully"Requirements and designs should be reviewed by those responsible for its maintenance"Software Rejuvenation…"Source: Adapted from Parnas, “Software Aging” 1996 University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 12 Reducing Maintenance Costs"21%25%4%43%4%3%corrective adaptive user enhancements efficiency other preventative Higher quality code!Better testing (verification)!Use of standards!Platform independence!Design for change!Good architecture!Better requirements analysis!prototyping, iterative development!Design
View Full Document
Unlocking...