1. Upgrading of component-based application Program Analysis and Transformation MSE-Seminar 09.12.20081© Raphael Gfeller, RaphaelGfeller@sunrise.ch

2. Agenda Component-based Software Engineering, CBSE – History – Benefits – Challenges Change management on CBSE – Approaches to reduce the effort for the consumer New fields of application Questions References 09.12.20082© Raphael Gfeller, RaphaelGfeller@sunrise.ch

3. Component-based Software Engineering, CBSE Component-based Software Engineering also known as Component-Based Development (CBD) or Software Componentry -focus that software should be developed by combining prefabricated components together (like in the field of electronics or mechanics) In contrast to object-oriented programming, (OOP) which -focus on modeling real-world interactions Abstraction 09.12.20083© Raphael Gfeller, RaphaelGfeller@sunrise.ch

4. Component-based Software Engineering, CBSE History 1968, Idea that software should be componentized from Douglas McIlroy  pipes and filters are included in UNIX 1986, definition of the modern concept of software component by Brad Cox  Objective-C (Smalltalk-style messaging to C) 1990, IBM invents their System Object Model 1990, as a reaction, Microsoft released OLE 1.0 – OLE custom controls (OCX) 1993, Component Object Model (COM) as an interface standard for software componentry was introduced by Microsoft 09.12.20084© Raphael Gfeller, RaphaelGfeller@sunrise.ch

5. Component-based Software Engineering, CBSE Benefits Decrease of development time and total cost because systems are not developed from scratch. Results in standard and reusable architectures Separation of skills because much complexity is packaged into specific frameworks. Fast access to new technology because we can acquire components instead of developing them in house. Improved reliability by shared components … Challenges Change management (many stakeholders involed)  focused in this presentation Robustness (input validity, error handling) Composable with other components Realizing an independent component … 09.12.20085© Raphael Gfeller, RaphaelGfeller@sunrise.ch

6. Change management on CBSE Problem 1: A new version of a component may Change the behavior or Not change the behavior (no behavior changes are often done by refactorings) Behavior changesBehavior does not change 09.12.20086© Raphael Gfeller, RaphaelGfeller@sunrise.ch

7. Change management on CBSE Problem 2: Multiple stakeholders are involved Producer, multiple consumer, multiple competitors, state, … Problem 3: Different interests of the stakeholders Size of the circle: Effort for the consumer Occurs most 09.12.20087© Raphael Gfeller, RaphaelGfeller@sunrise.ch

8. Change management on CBSE Problem 4: There is no deterministic reaction by the consumer if a new component is shipped. Possible reaction: Ignore the new version Adapt his software for using the new component. – That is the most common approach Adapt the shipped component to make it compatible with the exiting application – source code has to be available Create a compatibility wrapper for the new component 09.12.20088© Raphael Gfeller, RaphaelGfeller@sunrise.ch

9. Change management on CBSE Problem 5: Dilemma for the component consumer  Using of the new version or not ? Benefits Less bugs Performce improvements New features Costs New behavior? Upgrading the software Retest the software Decision drivers: Group change steps (remove features, add features, bug fixing, …) together  better ratio between benefits and efforts for the consumer Reduce the effort to adapt the new versio n  focused on the next slides 09.12.20089© Raphael Gfeller, RaphaelGfeller@sunrise.ch

10. “Using the new version of a component in a successful way; Implicates that the changes between the current and the new one are known!” 2008, Raphael Gfeller 09.12.200810© Raphael Gfeller, RaphaelGfeller@sunrise.ch

11. Approaches to reduce the effort for the consumer Detection of behavioral changes Communicated within release notes Detected by the consumer by doing faithful Unit Testing's.  To reduce the effort for the consumer, the producer should write release notes careful! 09.12.200811© Raphael Gfeller, RaphaelGfeller@sunrise.ch

12. Approaches to reduce the effort for the consumer Detection of non behavioral changes Approach 1: No communication Approach 2: Communicated within release notes A pproach 3: Using helper keywords within the programming language API documentation \ release notes Example 1: Example 2: 09.12.200812© Raphael Gfeller, RaphaelGfeller@sunrise.ch

13. Approaches to reduce the effort for the consumer Approach 4: Using Naming conventions Old clients still use the old version New clients can us the new features or can still use the old version Example 2: Example 1: 09.12.200813© Raphael Gfeller, RaphaelGfeller@sunrise.ch

14. Approaches to reduce the effort for the consumer Approach 5: Coexistent Old clients still use the old version New clients use the new features Example 1: Two versions of the “Person” exist in coexistent within the component 09.12.200814© Raphael Gfeller, RaphaelGfeller@sunrise.ch

15. Approaches to reduce the effort for the consumer Approach 6: COM-Style interface query, Coexistent Clients using their favorite version Example 1: Two versions of the “Person” exist in coexistent within the component 09.12.200815© Raphael Gfeller, RaphaelGfeller@sunrise.ch

16. Approaches to reduce the effort for the consumer Approach 7: Automatic approach based on approach 3 – Find code that is marked as deprecated – Find calls to deprecated code – Calls to deprecated code are replaced by their bodies Realized by Jeff H. Perkins  Can handle about 80% of all deprecated code Example 1: Body of the deprecated method 09.12.200816© Raphael Gfeller, RaphaelGfeller@sunrise.ch

17. Approaches to reduce the effort for the consumer Approach 8: Automatic approach, Record and replay refactoring – Producer records all applied refactorings Extension to the refactoring engine – Recorded refactorings are shipped – Consumer replays the refactorings Demonstrated by Johannes Henkel and Amer Diwan in CatchUp Example 1: Source: Henkel & Diwan: “CatchUp! Capturing and Replaying Refactorings to Support API Evolution” International Conference on Software Engineering, 2005 09.12.200817© Raphael Gfeller, RaphaelGfeller@sunrise.ch

18. Approaches to reduce the effort for the consumer Approach 9: Automatic approach, detects refactorings  used by approach 8 Uses – a fast syntactic analysis that finds candidates for refactoring – a precise semantic analysis step that finds the refactoring Demonstrated by Daniel Dig in RefactoringCrawler Detects up to 85% of applied refactorings 09.12.200818© Raphael Gfeller, RaphaelGfeller@sunrise.ch

19. Approaches to reduce the effort for the consumer Summary: Best method to be used is approach 8 “Record and replay refactoring”  Less effort for the producer and consumer  Information is collected on the source Unfortunately the tool chain is not existent  Further work has to be done – Publicize this approach – Realizing a tool chain than can be used by everyone – Make these tools as a standard fitting for modern development environment – Shipping refactoring logs should be a part of new setup and deployment assistants. 09.12.200819© Raphael Gfeller, RaphaelGfeller@sunrise.ch

20. New fields of application Based on approach 9: Detect an illegal usage of a component Situation: – Company A writes a well tested component C A, test T, test results R, – Company B writes a component C B that includes C A in a illegal way and apply refactorings to hide the origin of C A.  C B =some functions + C A + refactorings  It is not obvious that C A has been integrated into C B. Solution: – Detect refactorings between C A and C B. – Replay this refactorings on T  T’ – Rerun T’ on C B  R’ – If R and R’ are equal  the chance that C A has been integrated into C B is high. 09.12.200820© Raphael Gfeller, RaphaelGfeller@sunrise.ch

21. New fields of application Based on approach 9: Detect cheating of students Situation: – Students have to solve a given problem in Java including writing of Unit Tests  Solution 1-n – A cheating student B will use the solution from student A. Apply refactoring to hide its cheat.  S B =some edits + S A + refactorings.  It is not obvious that S B has cheated. Solution: – Detect refactorings between S A and S B. – Replay this refactorings on T  T’ – Rerun T’ on S B  R’ – If R and R’ are equal  the chance that B has cheated is high. Remarks: – Only valid if the given problem results in given solution 09.12.200821© Raphael Gfeller, RaphaelGfeller@sunrise.ch

22. New fields of application Based on approach 8: Reduce the transferred data in a CVS Situation: – Textual changes are transmitted from the client to the server – Assume that the often used method doLog is renamed to doLogging.  large amount of data has to be transferred Optimization: – Transfer refactorings instead of the textual changes, if possible Requirements – Client has to be able to record refactorings – Server has to have knowledge about the project structure like Microsoft Team Foundation Server does – Server has to be able to replay refactorings CVS Client transmit the changed file CVS Server CVS Client transmitt refactoring CVS Server 09.12.200822© Raphael Gfeller, RaphaelGfeller@sunrise.ch

23. New fields of application Based on “approach 8” and “Reduce the transferred data in a CVS “: Extend change management within a small company Situation: – A Company uses their common code C in different Projects P 1-n – During evolution, multiple versions of C exits. P 1-n reference on one of the special versions of C.  Bug fixing of C becomes painful Optimization: – Server has to have knowledge about all projects in a company. – Transmitted refactorings are forwarded to the C and to the referenced projects P 1-n that are using C.  Only one version of C exists. All projects within the company are using the actual version of the C. 09.12.200823© Raphael Gfeller, RaphaelGfeller@sunrise.ch

24. New fields of application Based on “approach 9”: Component Evaluation Situation: – Normally more than one component does the same job.  Evaluation is a time intensive job. Assumption: – If a component C A is doing nearly the same job as C B  API of C A and C B is similar Optimization: – Test the application with C A  test T, application A and test result R Realize a tool that: 1.Find refactoring between C A and C B  Ref 2.Apply Ref on A  A’, on T  T’ 3.Run T’ on A’  R’, store R’ 4.[For all component goto 1] 5.Display all R’ 6.Convert A to use with the best component C. Program could do the job with Component 1 from Vender A could do the job with Component 2 from Vendor B could do the job with Component 3 from Vendor C 09.12.200824© Raphael Gfeller, RaphaelGfeller@sunrise.ch

25. Questions? 09.12.200825© Raphael Gfeller, RaphaelGfeller@sunrise.ch

26. References Gfeller Raphael, Upgrading of component-based application, [Online] 7.12.2008. [Citied 7.12.2009] http://wiki.ifs.hsr.ch/SemProgAnTr/wiki.cgi?AUTOMATEDUPGRADINGOFC OMPONENT-BASEDAPPLICATIONS http://wiki.ifs.hsr.ch/SemProgAnTr/wiki.cgi?AUTOMATEDUPGRADINGOFC OMPONENT-BASEDAPPLICATIONS 09.12.200826© Raphael Gfeller, RaphaelGfeller@sunrise.ch