OORPT Object-Oriented Reengineering Patterns and Techniques 10. Testing and Migration Prof. O....
-
date post
21-Dec-2015 -
Category
Documents
-
view
220 -
download
1
Transcript of OORPT Object-Oriented Reengineering Patterns and Techniques 10. Testing and Migration Prof. O....
OORPTObject-Oriented Reengineering Patterns and Techniques
10. Testing and Migration
Prof. O. Nierstrasz
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.2
Roadmap
> Tests: Your Life Insurance> Migration Strategies
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.3
Roadmap
> Tests: Your Life Insurance— Write Tests to Enable Evolution— Grow Your Test Base Incrementally— Use a Testing Framework— Test the Interface, Not the Implementation— Write Tests to Understand— Record Business Rules as Tests— Other patterns
> Migration Strategies
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.4
A Map of Reengineering Patterns
Tests: Your Life Insurance
Detailed Model Capture
Initial Understanding
First Contact
Setting Direction
Migration Strategies
Detecting Duplicated Code
Redistribute Responsibilities
Transform Conditionals to Polymorphism
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.5
What and Why ?
Definitions> Restructuring refers to transforming a system from one representation to
another while remaining at the same abstraction level.— Chikofsky & Cross, ’90
> Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure — Fowler, ’99
Motivation> Alter the source-code to
— solve problems identified earlier— without introducing new defects— and while the system remains in operation
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.6
The Reengineering Life-Cycle
Requirements
Designs
Code
(0) requirementanalysis
(1) modelcapture
(2) problemdetection (3) problem
resolution
(4) program transformation
(3) problem resolution(4) program transformationissues• reliability• time• risk
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.7
Forces — Testing
> Many legacy systems don’t have tests> Software changes introduce new bugs> You can’t test everything> Concurrency and user interfaces are hard to test> Testing is usually everyone’s lowest priority> Knowledge concentration poses high risk> Customers pay for features, not tests> Customers don’t want buggy systems> Good programmers don’t need tests> New tools and techniques are more fun than testing> Testing is akin to street-cleaning
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.8
Tests: Your Life Insurance
Write Tests to Enable Evolution
Grow Your TestBase Incrementally
Managing testsUse a Testing
Framework
Test the Interface,Not the Implementation
Record BusinessRules as Tests
Designingtests
Write Teststo Understand
• Test Fuzzy features• Test Old Bugs• Retest Persistent Problems
Regression Testafter Every Change
Migration StrategiesMigration Strategies
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.9
Write Tests to Enable Evolution
Problem: How do you minimize the risks of change?Solution: Introduce automated, repeatable, stored tests
Automated tests are the foundation of reengineering
Long-term evolutionLong-term evolution
System documentationSystem documentation Architectural evolutionArchitectural evolution
System ConfidenceSystem Confidence Turnover Risk minimizationTurnover Risk minimization Confidence in ChangeConfidence in Change
Automated TestsAutomated Tests
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.10
Grow Your Test Base Incrementally
> Problem: When can you stop writing tests?> Solution: When your tests cover all the code!
— … however– you're paid to reengineer, not to write tests– testing ALL the code is impossible– design documentation is out-of date
» semi-automated black-box testing is not an option
Answer: Grow Your Test Base Incrementally• first test critical components
(business value; likely to change; …)• keep a snapshot of old system
(run new tests against old system)• focus on business values• test old bugs + new bugs that are reported
Answer: Grow Your Test Base Incrementally• first test critical components
(business value; likely to change; …)• keep a snapshot of old system
(run new tests against old system)• focus on business values• test old bugs + new bugs that are reported
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.11
Use a Testing Framework
> Problem: How do you encourage systematic testing?> Solution: Use a framework to structure your tests
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.13
Test the Interface, Not the Implementation
> Problem: How do you protect your investment in tests?> Solution: Apply black-box testing
— Test interfaces, not implementations– Be sure to exercise the boundaries
— Test scenarios, not paths– Use tools to check for coverage
— Beware;– Enabling testing will influence your design!
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.14
Write Tests to Understand
> Problem: How to decipher code without adequate tests or documentation?
> Solution: Encode your hypotheses as test cases
— Exercise the code— Formalize your reverse-engineering hypotheses— Develop tests as a by-product
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.15
Solution: Record Business Rules as Tests- canonical examples exist- can be turned into input/output tests
Solution: Record Business Rules as Tests- canonical examples exist- can be turned into input/output tests
Record Business Rules as Tests
> Problem: How do you keep your system in sync with the business rules it implements?
> A Solution: Good documentation + Good design— … however
– business rules are too complex to design well– documentation & design degrades when the rules change– business rules become implicit in code and minds
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.16
Example: Payroll Business Rule
> A person or couple gets an amount of money for every child he, she or they raise. Basically parents get CHF 150,- per month for every child younger than 12 years, and CHF 180,- for every child between 12 and 18 and for every child between 18 and 25 as long as the child is not working and is still in the educational system. A single parent gets the full 100% of this money as long as he or she is working more than 50%. Couples get a percentage of the money that is equal to the summed working percentages of both partners.
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.17
Example: Payroll Test Case
"--- input-cases are extracted from a database"singlePerson80WithOneKidOf5 := extract....couplePerson40occupationWithOneKidOf5 := extract....couplePerson100occupationWithOneKidOf5 := extract....couplePersonWithOneKidOf14 := extract....
"--- tests compare expected output against actual output"self assert: singlePerson80occupationWithOneKidOf5 moneyForKid
= 150.self assert: couplePerson40occupationWithOneKidOf5 moneyForKid
= 150*4.self assert: couplePerson100occupationWith2KidsOf5 moneyForKid
= 150*2.self assert: couplePersonWithOneKidOf14 moneyForKid
= 180.
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.18
Other patterns
> Retest Persistent Problems— Always tests these, even if you are making no changes to this
part of the system
> Test Fuzzy Features— Identify and write tests for ambiguous or ill-defined parts of the
system
> Test Old Bugs— Examine old problems reports, especially since the last stable
release— DeLano and Rising, 1998
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.19
Roadmap
> Tests: Your Life Insurance> Migration Strategies
— Involve the Users— Build Confidence— Migrate Systems Incrementally— Prototype the Target Solution— Always Have a Running Version— Regression Test After Every Change— Make a Bridge to the New Town— Present the Right Interface— Public vs. Published Interface— Deprecate Obsolete Interfaces— Conserve Familiarity— Use Profiler Before Optimizing
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.20
A Map of Reengineering Patterns
Tests: Your Life Insurance
Detailed Model Capture
Initial Understanding
First Contact
Setting Direction
Migration Strategies
Detecting Duplicated Code
Redistribute Responsibilities
Transform Conditionals to Polymorphism
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.21
The Reengineering Life-Cycle
Requirements
Designs
Code
(0) requirementanalysis
(1) modelcapture
(2) problemdetection (3) problem
resolution
(4) program transformation
(3) problem resolution(4) program transformationissues• reliability• time• risk
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.22
Forces — Migration
> Big-bang migration often fails> Users hate change> You need constant feedback to stay on track> Users just want to get their work done> The legacy data must be available during the transition
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.23
Migration
Migrate SystemsIncrementally
ConserveFamiliarity
HowUse Profiler
before Optimizing
Build ConfidenceInvolve the UsersHow Why
Why
Prototype theTarget Solution
Always Have aRunning Version
Regression Testafter Every Change
Present theRight Interface
Distinguish Publicfrom Published Interfaces
DeprecateObsolete Interfaces
Make a Bridgeto the New Town
How
Tests, yourLife-Insurance
Tests, yourLife-Insurance
Where to
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.24
Involve the Users
> Problem: How to get users to accept change?> Solution: Get them involved by giving them what they
want
— Start with the Most Valuable First— Prototypes can help raise enthusiasm, but may also raise
expectations too high— Deploy early to increase commitment
– Diverts energy from development– Pays back in quality feedback
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.25
Build Confidence
> Problem: How do you overcome skepticism?> Solution: Deliver results in short, regular intervals
— Requires time to sync with users— Requires effort to support the changes— Requires care not to alienate original developers— Requires regular, big demos to convince management
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.26
Migrate Systems Incrementally
> Problem: When should you deploy the new system? > Solution: As soon as possible
— Decompose the legacy system into parts— Tackle one part at a time (Most Valuable First)— Put suitable tests in place— Decide whether to wrap, reengineer, or replace— Deploy, support and obtain feedback— Iterate
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.27
Prototype the Target Solution
> Problem: How do you evaluate the target solution?> Solution: Develop a prototype
— Evaluate the technical risks– New system architecture– Migrating legacy data– Adequate performance …
— Exploratory prototype?– Explore specific issues, then throw it away!
— Evolutionary prototype?– Capture new architecture– Migrate, wrap, reengineer or reimplement parts
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.28
Always Have a Running Version
> Problem: Maintaining confidence during development> Solution: Integrate changes on a daily basis
— Use version and configuration management tools— Maintain exhaustive regression tests where needed— Plan short iterations — Continuous Integration
– If necessary, re-architect the system to enable short build times
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.29
Regression Test After Every Change
> Problem: Making sure changes don’t break the system> Solution: Run the regression tests at each “stable”
point
— You must relentlessly write tests!– Write new tests whenever new (untested) bugs are discovered– Take time to convince your team of the Joy of Testing
— If testing takes too long, categorize tests– But run all the tests at least once a day
— Consider writing tests up front— Remember to Retest Persistent Problems
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.30
Bridge
1:read() 2:write()
1.1:read()
1.2:write() 2.1:write()
Legacy System
New System
Data Store
Make a Bridge to the New Town
> Problem: How to migrate data?
> Solution: Convert the underlying files/databases/…
— ... however– Legacy and new system
must work in tandem– Too much data; too
many unknown dependencies
– Data is manipulated by components
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.31
Present the Right Interface
> Problem: How do you prevent the legacy design from polluting the new system?
> Solution: Wrap old services as new abstractions
— Identify the new abstractions you want— Wrap the legacy services to emulate the new interface
– Avoid directly accessing old procedural interfaces– Avoid wrapping as pseudo-OO «utility» classes
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.32
Solution: Distinguish between “public” and“published” interface
• public = stable target interface• published = available, but unstable
(use at your own risk)• language features (protected, friends, …)• naming conventions
Solution: Distinguish between “public” and“published” interface
• public = stable target interface• published = available, but unstable
(use at your own risk)• language features (protected, friends, …)• naming conventions
Public vs. Published Interface
> Problem: How to design interface for target solution?> Solution?: Think deeply
— ... however– Enable migration to target system ASAP– Avoid freezing the interface of target component– Costly ripple-effects of changes to public interface
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.33
Deprecate Obsolete Interfaces
> Problem: How to modify an interface without invalidating all clients?
> Solution: Flag the old interface as «deprecated»
— Old and new interfaces can co-exist for a time– Deprecated usage can be lazily patched
— Various techniques possible– Documentation (easy to ignore)– Move or rename old interfaces (painful)– Add warnings to deprecated code (should be non-intrusive)
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.34
Conserve Familiarity
> Problem: How to avoid disrupting Users’ work? > Solution: Avoid radical changes
— Avoid alienating users— Introduce a constant, small number of changes with each
release
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.35
Use Profiler Before Optimizing
> Problem: When should you rewrite inefficient code?> Solution: Only when you have benchmarks that prove it
is worthwhile
— “Do it, then do it right, then do it fast”
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.36
Conclusion
> Avoid risk— small increments (“chicken little”)— develop suite of regression tests
> … at acceptable cost— Migration costs as much as new development !— But you avoid "hidden costs"
– team morale in maintenance team– satisfying two customer bases
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
OORPT — CHAPTER
X.37
License
> http://creativecommons.org/licenses/by-sa/2.5/
Attribution-ShareAlike 2.5You are free:• to copy, distribute, display, and perform the work• to make derivative works• to make commercial use of the work
Under the following conditions:
Attribution. You must attribute the work in the manner specified by the author or licensor.
Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one.
• For any reuse or distribution, you must make clear to others the license terms of this work.• Any of these conditions can be waived if you get permission from the copyright holder.
Your fair use and other rights are in no way affected by the above.
Attribution-ShareAlike 2.5You are free:• to copy, distribute, display, and perform the work• to make derivative works• to make commercial use of the work
Under the following conditions:
Attribution. You must attribute the work in the manner specified by the author or licensor.
Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one.
• For any reuse or distribution, you must make clear to others the license terms of this work.• Any of these conditions can be waived if you get permission from the copyright holder.
Your fair use and other rights are in no way affected by the above.