Upgrading of component-based application

bloatdecorumΛογισμικό & κατασκευή λογ/κού

30 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

93 εμφανίσεις

Upgrading of component
-
based
application

Program Analysis and Transformation

MSE
-
Seminar

09.12.2008

1

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

2

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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)

Abstraction

09.12.2008

3

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

4

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

5

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

Behavior does not change

09.12.2008

6

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

7

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

8

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

Change management on CBSE

Problem 5:


Dilemma for

the component consumer



Using of the new version


or not ?







Benefits


Less bugs


Performce i mprovements


New features

Costs


New behavi or?


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

9

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

“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

10

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

11

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

12

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

13

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

14

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

15

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

16

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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 &
Di wan
: “
CatchUp
! Capturing and Replaying Refactorings to Support API Evolution


Internati onal Conference on Software Engi neeri ng, 2005

09.12.2008

17

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

18

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

Approaches to reduce the effort for the consumer

Summary:



B
est 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

19

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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




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

20

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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.



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

21

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

CVS
Server

CVS
Client

CVS
Server

09.12.2008

22

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

23

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

Component
1 from
Vender A

Component
2 from
Vendor B

Component
3 from
Vendor C

09.12.2008

24

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

Questions?


09.12.2008

25

© Raphael Gfeller, RaphaelGfeller@sunrise.ch

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

26

© Raphael Gfeller, RaphaelGfeller@sunrise.ch