Upgrading of component

Download Report

Transcript Upgrading of component

09.12.2008

Upgrading of component-based application Program Analysis and Transformation MSE-Seminar

© Raphael Gfeller, [email protected]

1

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.2008

© Raphael Gfeller, [email protected]

2

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 Component based programming (for example JavaBeans, DCOM) Distributed object computing (for example CORBA) Object oriented programming (for example C++, C#, Java) Procedural programming (for example C) 09.12.2008

© Raphael Gfeller, [email protected]

3

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.2008

© Raphael Gfeller, [email protected]

4

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.2008

© Raphael Gfeller, [email protected]

5

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 changes 09.12.2008

Behavior does not change © Raphael Gfeller, [email protected]

6

Change management on CBSE

• Problem 2: Multiple stakeholders are involved Producer, multiple consumer, multiple competitors, state, … • Problem 3: Different interests of the stakeholders 09.12.2008

Size of the circle: Effort for the consumer © Raphael Gfeller, [email protected]

Occurs most 7

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.2008

© Raphael Gfeller, [email protected]

8

Change management on CBSE

Problem 5: Dilemma for the component consumer Benefits •Less bugs •Performce improvements •New features  Using of the new version or not ?

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  focused on the next slides n 09.12.2008

© Raphael Gfeller, [email protected]

9

“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.2008

© Raphael Gfeller, [email protected]

10

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.2008

© Raphael Gfeller, [email protected]

11

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

Example 1: Example 2:

API documentation \ release notes 09.12.2008

© Raphael Gfeller, [email protected]

12

Approaches to reduce the effort for the consumer • Approach 4: Using Naming conventions

Example 1: Example 2:

Old clients still use the old version New clients can us the new features or can still use the old version 09.12.2008

© Raphael Gfeller, [email protected]

13

Approaches to reduce the effort for the consumer • Approach 5: Coexistent

Example 1:

Old clients still use the old version New clients use the new features 09.12.2008

Two versions of the “Person” exist in coexistent within the component © Raphael Gfeller, [email protected]

14

Approaches to reduce the effort for the consumer • Approach 6: COM-Style interface query, Coexistent

Example 1:

Clients using their favorite version 09.12.2008

Two versions of the “Person” exist in coexistent within the component © Raphael Gfeller, [email protected]

15

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:

09.12.2008

Body of the deprecated method © Raphael Gfeller, [email protected]

16

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:

09.12.2008

© Raphael Gfeller, [email protected]

International Conference on Software Engineering, 2005 17

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.2008

© Raphael Gfeller, [email protected]

18

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.2008

© Raphael Gfeller, [email protected]

19

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 apply refactorings to hide the origin of C A .  C B =some functions + C A + refactorings in a illegal way and  It is not obvious that C A has been integrated into C B.

Solution: – Detect refactorings between C A – Replay this refactorings on T  – – Rerun T’ on C B  R’ If R and R’ are equal  is high.

and C B .

T’ the chance that C A has been integrated into C B 09.12.2008

© Raphael Gfeller, [email protected]

20

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.

 Solution: – Detect refactorings between S A – Replay this refactorings on T  – – It is not obvious that S B Rerun T’ on S B  R’ If R and R’ are equal  has cheated .

and S B .

T’ the chance that B has cheated is high.

Remarks: – Only valid if the given problem results in given solution 09.12.2008

© Raphael Gfeller, [email protected]

21

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 CVS Client Optimization: – Transfer refactorings instead of the textual changes, if possible CVS Server CVS Client CVS Server 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 09.12.2008

© Raphael Gfeller, [email protected]

22

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 special versions of C.

reference on one of the  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.2008

© Raphael Gfeller, [email protected]

23

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  API of C A A and C B is doing nearly the same job as C B is similar Optimization: – Test the application with C A  test T, application A and test result R Component 1 from Vender A Realize a tool that: 1.

2.

3.

Find refactoring between C Apply Ref on A  Run T’ on A’  A’, on T R’, store R’ A  and C B T’ 4.

5.

6.

 Ref Program [For all component goto 1] Display all R’ Convert A to use with the best component C.

Component 2 from Vendor B Component 3 from Vendor C 09.12.2008

© Raphael Gfeller, [email protected]

24

Questions?

09.12.2008

© Raphael Gfeller, [email protected]

25

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 09.12.2008

© Raphael Gfeller, [email protected]

26