Overview 1 1 Find out why software engineering

  • Slides: 18
Download presentation
Overview 1 1. Find out why software engineering is important ■ 2. see some

Overview 1 1. Find out why software engineering is important ■ 2. see some software engineering failures Get acquainted with – ■ the Chair of Software Agile Engineering Development Accelerating ■ the research through Software Reuse ■ the people ■ the teaching Karlsruher Entwicklertag May 9 th, 2012 Colin Atkinson Software Engineering Prof. Dr. Colin Atkinson 1

Reconciling Agility and Reuse 2 ■ software reuse and agile development have the same

Reconciling Agility and Reuse 2 ■ software reuse and agile development have the same underlying goal - ■ ■ but they are usually not applied at the same time ■ ■ to allow new applications to be built more rapidly and cost effectively agile processes almost exclusively focus on developing new software Challenge ■ make reuse a central part of agile development Test Analysis Code Reuse Software Engineering Prof. Dr. Colin Atkinson Design 2

Component Reuse 3 ■ ■ Software Reuse ■ “the process of creating software systems

Component Reuse 3 ■ ■ Software Reuse ■ “the process of creating software systems from existing software rather than building software systems from scratch. ” [Krueger 92] ■ software component markets famously proposed by Mc. Ilroy in 1968 [Mc. Ilroy 68] ■ the “holy grail” of software engineering, but has failed to take off to the extent expected or desired Software Component ■ any cohesive and compact unit of software functionality with a well defined interface ■ includes simple programming language classes as well as more complex artefacts such as web services and EJBs ■ not focussed on “snippets” Software Engineering Prof. Dr. Colin Atkinson 3

Why “Reuse” Did Dot Take Off 4 ■ Historically, there were there main barriers

Why “Reuse” Did Dot Take Off 4 ■ Historically, there were there main barriers to systematic component reuse ■ Not enough good components to reuse ■ 200 was considered a lot of components in the golden years of reuse research (1980 s and 1990 s) ■ Crude retrieval technology ■ often returned a high proportion of unsuitable components or missed many relevant ones ■ Unfavourable risk/effort balance ■ chances of success through reuse too low to justify the effort involved Software Engineering Prof. Dr. Colin Atkinson 4

What’s Different Today ■ The situation has improved significantly since the turn of the

What’s Different Today ■ The situation has improved significantly since the turn of the millennium ■ Plenty of good components to reuse ■ high bandwidth internet available to all 5 ■ ■ vast repositories of open source code ■ web service revolution Advanced retrieval technology ■ Lucene indexing engine ■ ■ advanced retrieval algorithms Radically different risk/effort balance ■ unobtrusive component recommendation tools becoming available Software Engineering Prof. Dr. Colin Atkinson 5

Merobase 6 ■ One of the largest software component search engines ■ ■ more

Merobase 6 ■ One of the largest software component search engines ■ ■ more than 10 million components Public Features ■ multiple component types ■ source code, binary code, web services, Android apps ■ hybrid search algorithms ■ keyword, name, interface, . . ■ lookup (library, documentation, . . ) ■ service execution ■ metrics ■ …. Software Engineering Prof. Dr. Colin Atkinson 6

7 Software Engineering Prof. Dr. Colin Atkinson 7

7 Software Engineering Prof. Dr. Colin Atkinson 7

8 Software Engineering Prof. Dr. Colin Atkinson 8

8 Software Engineering Prof. Dr. Colin Atkinson 8

Search Result Quality 9 ■ The new generation of code search engines provides dramatically

Search Result Quality 9 ■ The new generation of code search engines provides dramatically enhanced search quality ■ Average precision: ■ ■ ■ Signature-based search string-based search = Name-based = Interface-based = = 16% 17% 54% However, this is not enough to significantly change the “build or buy” trade-off ■ Probability of finding component that are really “fit for purpose” is too low compared to the effort involved in exploring reuse opportunities Need higher precision ■ Semantic search Software Engineering Prof. Dr. Colin Atkinson 9 1%

Test-Driven Search 10 ■ most practical way of evaluating a component’s “fitness for purpose”

Test-Driven Search 10 ■ most practical way of evaluating a component’s “fitness for purpose” is to test it ■ can deliver 100% precision b) define desired semantics as tests c) find matching components d) compile components e) establish acceptability through tests identify desired interface reuse public void test. Title. Retrieval () { Movie movie = new Movie("Star Wars", 0); assert. True(movie. get. Title (). equals("Star Wars")); } Software Engineering Prof. Dr. Colin Atkinson 10

Test Driven Search Example 11 ■ desired interface public class Mortgage { public Mortgage(double

Test Driven Search Example 11 ■ desired interface public class Mortgage { public Mortgage(double rate, int years, double loan) {} public double Monthly. Payment() {} public double Total. Payment() {} } ■ excerpt of JUnit test public void test. Mortgage() { private Mortgage m = new Mortgage(4. 5, 12, 250000); assert. Equals(2250. 02, m. Monthly. Payment(), 0. 01); private Mortgage m = new Mortgage(4. 5, 12, 250000); assert. Equals(324, 002. 94, m. Total. Payment(), 0. 01); …. } Software Engineering Prof. Dr. Colin Atkinson 11

Test Driven Search (Merobase) 12 Software Engineering Prof. Dr. Colin Atkinson 12

Test Driven Search (Merobase) 12 Software Engineering Prof. Dr. Colin Atkinson 12

Code Conjurer Eclipse Plugin 13 ■ Seamlessly integrates Merobase driven search into the Eclipse

Code Conjurer Eclipse Plugin 13 ■ Seamlessly integrates Merobase driven search into the Eclipse development environment ■ Main Features ■ code-driven search ■ test-driven search JUnit test driven queries ■ unobtrusive (background) recommendation ■ component dependency resolution ■ interface recommendation ■ code metadata (metrics) ■ Interface adaptation ■ … Software Engineering Prof. Dr. Colin Atkinson 13

Test Driven (Code Conjurer) 14 Software Engineering Prof. Dr. Colin Atkinson 14

Test Driven (Code Conjurer) 14 Software Engineering Prof. Dr. Colin Atkinson 14

15 Software Engineering Prof. Dr. Colin Atkinson 15

15 Software Engineering Prof. Dr. Colin Atkinson 15

Proactive Recommendation Example 16 Software Engineering Prof. Dr. Colin Atkinson 16

Proactive Recommendation Example 16 Software Engineering Prof. Dr. Colin Atkinson 16

Conclusion 17 ■ Test-driven search fits naturally into agile, test driven development ■ ■

Conclusion 17 ■ Test-driven search fits naturally into agile, test driven development ■ ■ Is the key enabling technology for integrating reuse-oriented and agile development ■ ■ When used together with a test-driven development strategy like XP, test-driven search makes the effort involved in finding suitable components almost zero can accelerate the agile development process Get involved. . ■ Code Conjurer http: //www. code-conjurer. org/ ■ ■ use it, provide feedback, help enhance it (open source) make your own tools search-driven ■ ■ publically accessible Merobase API create your own code search engine ■ ■ merobase can crawl any content in CVS, SVN, . . repositories Further information: atkinson@informatik. uni-mannheim. de Software Engineering Prof. Dr. Colin Atkinson 17

For Further reading 18 ■ W. Janjic, M. Schumacher, Der Herr der Codes, Eclipse

For Further reading 18 ■ W. Janjic, M. Schumacher, Der Herr der Codes, Eclipse Magazin, 2. 12, S&S Media Gmb. H, Frankfurt am Main, 2012 ■ Software Engineering Prof. Dr. Colin Atkinson O Hummel, W Janjic, C Atkinson, Code conjurer: Pulling Reusable Software out of Thin Air, IEEE Software 25 (5), 2008 18