Reengineering of Software-Components for Prediction of Extra-Functional Properties

Universität Karlsruhe (TH) Research University • founded 1825 Reengineering of Software-Components for Prediction of Extra-Functional Properties Reen...
3 downloads 1 Views 406KB Size
Universität Karlsruhe (TH) Research University • founded 1825

Reengineering of Software-Components for Prediction of Extra-Functional Properties Reengineering Component Behaviour Focus: Performance Prediction

Klaus Krogmann ([email protected]) Chair Software Design and Quality Institute for Program Structures and Data Organization (IPD) Faculty of Informatics, Universität Karlsruhe (TH)

Performance Prediction

Performance meta-model of a component based software architecture

Krogmann: Reengineering Software-Component Behaviour

Performance data ▪ Execution time ▪ Response time

07-05-13

2

Component Performance

[Becker2006a] Krogmann: Reengineering Software-Component Behaviour

07-05-13

3

Black-Box vs. Grey-Box Execution Time of a()? b() 2ms c() 3ms ComponentB

a() ?ms ComponentA

d() 5ms ComponentC

Krogmann: Reengineering Software-Component Behaviour

07-05-13

4

Overview Motivation Example: Desired outcome Assumptions Idea: Process / How Conclusion

Photo: pixelquelle.de

▪ ▪ ▪ ▪ ▪

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

5

Performance Prediction ▪ A pure black-box view of components is not sufficient to predict component performance ▪ How to gain a grey-box view of existing components? – Control flow – Data flow – Abstraction level: information influencing component performance

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

6

Service Effect Specification getListWithLittleEntropy

public List getListWithLittleEntropy (List listToSort, int count) { while(mode) {



// some simple internal action for(int x = 0; x < count; x++) { listToSort.add(new Integer(x)); }



if(count > 100) { //external call: collectionComponent.sort(listToSort); }

CollectionComponent.sort()

//external call: mode = collectionComponent. isEntropyLessThan(listToSort, count);

CollectionComponent.isEntropyLessThan()

} return listToSort; }

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

7

Expected Result of Analysis (1) Resource Demanding SEFF ▪ Parametric dependencies / variable usage ▪ Resource usages ▪ Stochastic expressions ▪ Allows reasoning on – Functional dependencies – “QoS-Attributes” of component / SEFF – Execution probabilities Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

8

Expected Result of Analysis (2) ▪ Parametric dependencies / variable usage – In: Input parameter – Used for • • • • • •

Internal actions Branching (branch selection) External calls (variable usage) Loops (# iterations) Time between resource acquisition and release Return values

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

9

Expected Result of Analysis (3) ▪ Parametric resource usages – CPU (cycles) – Used memory – Network

▪ Abstractions / Approximations – not the “real dependency”

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

10

Idea ▪ Combination of – Static source code analysis for control flow structure – Analysis of components at runtime

▪ Use machine learning (i.e. genetic algorithms) to get the required the abstraction level

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

11

Assumptions (1) ▪

Given – Source code – Component boundaries and component interfaces (including roles) (Æ predefined what internal and external calls of a SEFF are)

▪ ▪

Assumption: Source code can be compiled All external services can either be simulated or mocked (Æ related work exists)

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

12

Assumptions (2) ▪

Testing approach: – Components are monitored at runtime – Not the whole input space can be covered within finite time – Need to find adequate test data Æ Assumed that such test data is given • Test data is independent from a specific usage profile

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

13

Intended Process

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

14

Genetic Algorithm ▪ In: – Measuring data from tracing – Optimization function • Coverage with measuring data of tracing • Complexity of expression evaluation

– Initial Building Blocks

▪ Out – Equation (parameterized)

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

15

Initial Building Blocks

void process(int a){ doIt1(); do { doIt2(); a++; } while (a < 10) } [Overall_runtime] = [method_init] + [const1] + ( [while(a)] * [const2] );

sequence

nesting

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

16

Example: Internal Action int f(int p) { for(int i = 0; i < 1000; i++) { p++; p += 1; //do some useless calculations p -= 1; } return p; } ▪ Functional: f(p): p + 1000 ▪ Execution time: f(p): O(1) J constant ▪ Both values are relevant for SEFF annotations Krogmann: Reengineering Software-Component Behaviour

07-05-13

17

Limitations ▪ Reconstruction of concurrency is not planned ▪ The monitored behaviour usually depends on the chosen test cases to monitor the source code at run-time. ▪ Instrumentation of source code for monitoring purposes can create very big amounts of measuring data.

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

18

Conclusion ▪ Approach to reengineer component internals to enable performance prediction ▪ Combination of static and dynamic reengineering ▪ Use of genetic algorithms for finding abstractions of parametric dependencies

Motivation ` Example: Outcome ` Idea: Process ` Conclusion Conclusion Krogmann: Reengineering Software-Component Behaviour

07-05-13

19

Suggest Documents