Software recycling

Software Recycling

Ioannis Stamelos

Aristotle University of ThessalonikiDept of Informatics

Software Engineering Grouphttp://sweng.csd.auth.gr

[email protected]

http://sweng.csd.auth.gr/

Presentation Outline

● Introduction● Software recycling: who, what and why? ● The OPENSME project: Software recycling

techniques and tools

● Software recycling economics

● Conclusion and Future work






Introduction

● Aristotle University of Thessaloniki

● Department of Informatics

● Software Engineering Group

City of Thessaloniki● Capital of Macedonia region, northern Greece

● ~1 M inhabitants, 2nd greek city, major port of Balkan area

● 2300 years of continuous history, joined modern Greece in 1912

Aristotle University of Thessaloniki

● First school (Philosophy) established in 1925

● Largest Greek University

● 45 departments

● > 60.000 students

● > 3.000 staff / teachers

•www.auth.gr

http://www.auth.gr/

Department of Informatics

● School of Physical Sciences

● Established in 1993

● 30 academic staff members

● 4 years Curriculum, 2 Master Programs

● ~700 students

● www.csd.auth.gr

http://www.csd.auth.gr/

Five Research Labs

● Programming Languages and Software

Engineering

● Data Technologies and Engineering

● Information Processing and Artificial Intelligence

● Multimedia (Educational Technologies)

● Networks, Communications and Architecture

Programming Languages and Software Engineering Lab

● 7 staff members● several research associates● 25 PhD students● Major research areas:

– Intelligent Systems– Knowledge Engineering– Software Engineering– Statistics in Information Systems– Web Information Systems

Software Engineering Group (SWENG)

● 3 academic staff members:– Associate Professor I. Stamelos (FLOSS,

Software Engineering)– Associate Professor L. Angelis (Empirical

Software Engineering) – Assistant Professos P. Katsaros (Formal

Methods, Software Quality)

● 3 research associates

● 14 PhD students

● http://sweng.csd.auth.gr

http://sweng.csd.auth.gr/

SWENG: Teaching

● Dept. of Informatics

– Introduction to Software Engineering

– Object Oriented Analysis / Java

– Software Security and Reliability

● Master Courses

– Software Project Management

– Enterprise Information Systems

– Advanced Information Systems Development

(International Hellenic Open University)

SWENG: R&D Activities

● Basic Research

● Funded Applied Research & Development from– Greek Secretariat for Research and Technology– EU (FLOSS topics)– Greek Private Companies– Greek Secretariat for Sports

● Collaboration with other research teams in Greece and in EU:– Malardalen Univ (Vasteras, Sweden), – MERIT (Maastricht), – Tampere Univ (Tampere, Finland), – Univ. Juan Carlos / (Madrid), – Athens Univ. of Business & Economy,– Politecnico di Torino, Univ. LAMSADE (Paris)

SWENG: Major Research Areas

● Software Quality

● Software Cost Estimation

● Software Management and Evaluation

● Software Engineering Education

● Software Architecture

● All the above applied on FLOSS

● Extreme Programming


● Introduction● Software recycling: who, what and why? ● The OPENSME project: Software recycling techniques and

tools


● Future work

Current Situation in the Software World (1)

● After several decades of intense software development

– Incredibly high number of closed source applications, written

in tenths of different languages

– Closed source applications are owned by companies,

organizations, individuals.

– Some may be purchased, some are strictly proprietary


● Modern societies are based on the use of software

● However, large portion of the closed source software is not

used:

– obsolete

– forgotten,

– or even lost


● Hundreds of thousands of open source software applications,

estimated 600.000+:

– Sourceforge alone: >300.000 projects

– 100+ billion lines of code

● Written in many different languages, owned by communities, open

to everyone

● Open source is ~50% of deployed code

● (source: 2012 Future of Open Source Survey, Black Duck

Software)

Software Issues

● Software (either open or closed source) is often

pestered by a multitude of problems:– Bad quality (bugs, low usability, unclear

behaviour, ...)– Bad (internal) documentation (purely commented

code, no analysis&design documentation, no

recorded tests ...)– In addition: Original developers may be no longer

available, many OSS projects are not active at all

Recycling

● Recycling is processing used materials (waste) into new

products to prevent waste of potentially useful materials,

reduce the consumption of fresh raw materials, reduce energy

usage, ... [source:wikipedia]● To reuse is to use an item again after is been used● Recycling is not always economically efficient or even

environmentally helpful

Software Recycling

● Software Recycling is processing existing (either used or

dormant) software to help producing new software products, to prevent waste of potentially useful

development effort, reduce software development costs,

and even reduce energy usage

Software Recycling vs Software Reuse

● Software Reuse is the process of creating software systems

from predefined software components● Software Recycling is the process of systematically building

reusable software components out of existing software, even if

the original application was not meant or designed to be

reused. Such components may then be reused into new

software systems

What to Recycle? ● Open Source Code

– Free access, license issues may exist● Legacy Systems

– Only legacy system owners have such option– However, they may want to donate legacy code under certain

circumstances– An example is the greek public sector: hundreds of software applications

that are not used and could be released as open source.● In any case one must carefully consider the software quality issues

mentioned above– to make software recycling economically efficient and – to produce components of acceptable quality

Who could/should recycle?

● Source: COMPARCH 2012/ROSS workshop, Bertinoro (IT), June

25● Large companies :– Would like to recycle their own code (e.g. IBM, SIEMENS)– Reluctant to use recycled open source components or third party

software because of liability issues (“not invented here”

syndrom)● SMEs have less liability issues because they address broad

markets and/or produce less critical applications– Eager to reuse recycled software– Practical problems exist...

Recycling Open Source Software

● Open Source Software (OSS) reuse has the potential to improve

software quality, shorten time-to-market and bring competitive

advantages to Software Development SMEs.● Currently OSS reuse is restricted to:

– Whole OSS projects (e.g. Apache web server, MySQL

Database)– Opportunistic reuse of isolated classes– Well-known selected infrastructure components (e.g. Apache

Commons)

Technical Challenges

● Valuable OSS components exist in every OSS project. ● However it is difficult to recognize them, extract them, test them,

document them etc.● During software development, usually there is no time for the

aforementioned activities. Developers often prefer to develop new

code from scratch although this code has been written before

many times by many others.● Even when developers recognize the opportunity to reuse OSS

code there are several uncertainties related to the provided

functionality and quality. – What the component does?– How well it does it?

Adoption of Software Reuse solutions by software SMEs is limited because of:o Large initial investments in technology know-how and tools.o Accumulation of reusable modules by a single SME requires multiple

applications in different application domains.o The market presently lacks services that would allow the effective

identification, classification, cataloguing, adaptation and utilization of open source software components.

The OPEN-SME project aims to provide a pragmatic and viable solution that will allow SME Associations to effectively provide Open Source Software Reuse services to their member software SMEs.

OPEN-SME proposal is to extend the landscape of OSS reuse to domain-specific components extracted by arbitrary OSS projects.

OSS Recycling for the benefit of SMEs






The OPENSME Project● OPEN-SME Overview and Contributions● OPEN-SME Tools: OCEAN Search Engine● OPEN-SME Tools: COPE Component Adaptation

Environment● OPEN-SME Tools: COMPARE Component Repository

and Search Engine

OPENSME PROJECT OVERVIEWOPENSME PROJECT OVERVIEW

Open-Source Software Reuse Service for SMEs

Grant agreement no.: FP7-SME-2008-2 – 243768Duration: 24 monthsStart date: 01.07.2010Number of beneficiaries: 10Overall budget: €1,498,707

OPEN-SME main idea

● Introduce a reuse service that will be operated by SME Association Groups

(AGs) (e.g. Vasteras Science Park) on behalf of their SME software

development members.● This service will be operated by software experts of the SME AGs who will

produce components from OSS projects, test them, generate documentation,

resolve licensing etc. asynchronously to application development by SMEs

and independently from the SMEs. The components will be related to

domains that are relevant to the SMEs.● When the SMEs will want to reuse them, the components will already be there.

The OPEN-SME approachThe OPEN-SME approach

OPEN-SME adopts an approach that is centred on the role of re-use engineers, charged with discovering and adapting software components to Domain Architectures, known to the re-users. Although reuse engineers are necessary for an effective reuse, OPEN-SME tool suite will automate as much as possible the reuse engineers’ tasks.

Result 1 (R1): The OPEN-SME generic and customizable Domain Engineering Process that will guide the definition, implementation, and maintenance of Domain Architectures for any given Application Domains, as well as the identification and adaptation of available OSS components to these Domain Architectures.

Result 2 (R2): The OPEN-SME generic and customizable Application Engineering Process that will guide the exploitation of the Domain Engineering outcomes in the framework of a systematic, component-based, and reuse-oriented Software Product Development Methodology.

Result 3 (R3): The Open Source Search Engine (OCEAN) that will provide unified access to existing OSS search engines (e.g. Google Code Search, Koders, etc.) and will allow the initial retrieval of open source software modules to be analyzed and adapted by the Domain Engineering Activities.

OPENSME Expected Results

Result 4 (R4): The OPEN-SME Component Adaptation Environment (COPE) generic tooling framework specification and the different COPE instances (as per selected Application Domain requirements) that will support in a holistic manner the different activities of the Domain Engineering Process.

Result 5 (R5): The OPEN-SME Component Repository and Search Engine (COMPARE) that will allow software re-users to effectively search, browse, and retrieve the assets produced by the Domain Engineering Process as well as provide a communication bus supporting the effective exchange and processing of structured information flows between the software reuse stakeholders.

Result 6 (R6): The OPEN-SME generic Business Models and Cost Models pertaining to the commercialization of the OPEN-SME approach in real-world business cases.

OPENSME Expected Results (cont'd)

OPEN

-SM

E Ov

ervi

ewExisting OSS Search

Engines and Repositories

Open sourCe sEArch eNgine (OCEAN)

Candidate Source Code Modules

COmponent adaPtation Environment(COPE)Domain

Engineering Process

Reusable Components

Application Engineering Process

COMponent rePository And seaRch Engine(COMPARE)

EngineeringProcess

Tool Input

OutputUses

Artifact

Artifact Group

SMEs Associations

Software Development SMEs

Result 1

Domain Engineering Process

R1Domain Engineering Process

Outputs

Custom Software Engineering Tools

Result 2

Result 3

Result 5

Result 4

Result 6

: Bus

iness Mod

els an

d Cos

t Mod

els

BusinessProcess

Use Case Models

Feature Models

Software ArchitectureTest Suites Adaptation

Paterns

Domain Ontology

R.O.D.E. Domain Engineering Process

● Exemplar-based Reuse-Oriented Domain Engineering Process● Process Definition● Process Configuration● Domain Analysis● Domain Design● Evolution● Modeled with EPFComposer

Open-SME domain engineering approach

●Domain analysis and design should be carried out using as exemplar Open Source Software (OSS) applications that are available through the OSS search engines (OCEAN)●During analysis and design the OSS exemplars will provide inspiration for the concepts of the reference architecture.●The role of the reference architecture is to provide a detailed description for the common domain concepts and their organization to a typical architecture.●Domain implementation will not implement the domain concepts from scratch. The main input for the implementation of the domain concepts of the reference architecture will be components that will be discovered with the analysis of the OSS exemplar projects using the Component Adaptation Environment toolset (COPE).

Open-SME domain engineering approach

RODE process is presented in terms of Phases. Each one of the phases comprising the process, is performed only once with

the exception of the Evolution Phase. The purpose of the process is to build up all the necessary tools, reusable

assets, artifacts, documents, models. Allows SME-AGs the capability of providing the services of Open-SME, while

performing a continuous, on-going, evolution of assets.

RODE Process composition

Phases: 6 Iterations: 3 Activities: 9 Tasks: 18 Publishable Artifacts: 150+ Fully documented on opensme.eu/rode A couple of example phase definitions with EPF Composer follow in the next

slides

Process Configuration > Overview

Domain Implementation > Overview

OPEN-SME Tools: OCEAN Search Engine

● Open Source Search Engine (OCEAN) provides unified access

to existing OSS search engines (e.g. Google Code Search,

Koders, Merobase etc.)● It is used by Reuse Engineers during the domain engineering

activity of the RODE process (http://opensme.eu/rode) ● The advantages of using OCEAN instead of directly using the

underlying OSS search engines include:– The capability to search more search engines

simultaneously – The capability to store results in a database– An API for access to OCEAN from other applications.

http://opensme.eu/rode

OCEAN: current implementation

Available through: ocean.gnomon.com.gr

User provides information such as search keywords, desired language and license, maximum number of returned results etc.

OSS search engines problems:» Volatility: Google code search is no longer available» Lack of reliability: Merobase API presents problems

Krugle and Koders search engines have been added through web scrapping

Interface to Merobase is now available through web scrapping as well

OCEAN Status

A Desktop Application that:→ Identifies and models primary concepts of the domain (using: Knowledge Manager)→ Analyses the different aspects (using: Static Analysis, Design-pattern Analysis, etc.)

of an Open-Source project → Comprehends the project (using: the outcome of the Analysis, Documentation

Generation, in-project Search)→ Detects candidate components (using the outcomes of the project Analysis and

project Comprehension)→ Generates components (using: the various Component Makers)→ Validates them (using: Dynamic Analysis)→ Classifies the produced component (using: Knowledge Manager)→ Uploads the Component to COMPARE.

OPEN-SME Tools: COPE Component Adaptation Environment

The concept of a ‘Reuse Project’

● SME AGs experts, called reuse engineers create reuse

projects. ● A “Reuse Project” serves as an extended version of a

regular F/LOSS project. It combines the source code

related information (of the original F/LOSS project) with the

information resulting from the analysis process carried out

by the reuse engineer.

Reuse Project Lifecycle

A Reuse Project’s lifecycle consists of the following phases:

Analysis phase: the source code of the target F/LOSS project is being analyzed

and the results of this analysis are being stored in its “Reuse Project”.

Component Recommendation: in this phase COPE automatically suggests class

clusters that could serve as reusable components.

Component Making: this set of functionalities allows the user to extract

components from the reuse project by either using class clusters recommended in

the Cluster Recommendation phase or by selecting a single class that along with

its dependencies will form a reusable component.

Knowledge Management: in this phase the user provides information for the

generated components. Using the “Semantic Application” feature, the user can

describe the functionality of each component. Moreover s/he can classify the

resulting component to a specific domain and concept and finally upload the

component to the COMPARE component repository.

Creating a Reuse Project

Performing Static Analysis with COPE

Static Analysis Results

Source File Indexing

Source File Indexing is another analyzer that creates an index from the source files

of a Reuse Project. This index enables the feature of the internal search engine

and provides five different fields for targeted search:

Full Text: performs search for the specified keywords to the whole class file

Name: performs search for the specified keywords to the name of the class file

Attribute: performs search for the specified keywords to the attributes of the class

file

Method: performs search for the specified keywords to the methods of the class

file

Comment: performs search for the specified keywords to the comments of the

class file

Searching text with COPE

Documentation Generation

Documentation Generation creates the Javadoc documentation for the source

code of the Reuse Project augmented with UML diagrams for each class and

package. Internally we reuse the APIVIZ project (http://code.google.com/p/apiviz/)

http://code.google.com/p/apiviz/

http://code.google.com/p/apiviz/

Performing Dynamic Analysis

● Dynamic Analysis, gives the opportunity to the Reuse Engineer to test and

validate the components he extracts from COPE’s Reuse Projects. More

specifically, Dynamic Analysis can provide the following information:– Statement Coverage of the Component– Statement Coverage per Method of the Component– Linear Code Sequence and Jump (LCSAJ) coverage of the Component– LCSAJ Coverage per Method of the Component– Control Flow Graph per Method of the Component

● In order for the Dynamic Analysis to be performed at least one component

should have been generated using one of the available Component Makers

Performing Dynamic Analysis Step 1First we select an available component

Execution Scenarios

● The reuse engineer needs to define the execution scenario for the component

to be tested. An execution scenario consists of a fully functional class that

uses the main functionality of a specific component.

● Essentially the reuse engineer after extracting the components’ source files it

performs some testing on the component using either JUnit tests or simple

programs. These programs which test the component’s functionality are

called in COPE terminology execution scenarios.

Selecting an Execution Scenario

Coverage

The reuse engineer can be informed about the coverage that the execution

scenario achieves

Method paths covered

Moreover by selecting a specific

method from the table in the centre of

the dialog and clicking to the “Details”

button, the Reuse Engineer is

prompted with a new dialog which

presents new coverage information,

specifically for the selected method.

COPE provides not only the LCSAJ

and statement coverage metrics for

the selected method but also it

visualizes the paths that were covered

by the execution scenario provided

(text highlighted in green).

Method Control Flow Graph

COPE provides the option of

displaying the Control Flow Graph for a

specific method. By clicking the

“Display Control Flow Graph” button,

the control flow graph opens in a new

dialog

Component Validation

Component Validation is a five step process:

1. Class Selection: The candidate classes include those that implement a provided

interface of the component or the class from which the component was extracted.

2. Select Included / Exclude Interfaces: The provided interfaces of the extracted

component should be added to the included interfaces list whereas the required

interfaces of the component should be added to the excluded list.

3. Select Include Exclude Scope: This defines the scope of the validation process. The

reuse engineer may select from the most general package (as it is recommended), up

to a specific class.

4. Select Test Generation Properties: The reuse engineer must define the input (to be

tested) and output interfaces.

5. AspectJ: Aspect Oriented Programming is used to trace component's behavior as it is

executed. An AspectJ file is generated according to the fields of 1, 2 and 3 steps.

Reuse Engineer may make any change in the displayed code and save the changes.

Performing Validation

Once the AspectJ file has been generated the Reuse Engineer can proceed in

performing validation process by clicking to “Perform Validation Process” button. If

no errors occur a success message is prompted after a while.

Additional validation features

In addition the reuse engineer can:● Visualize the FSM of the component validation process● Generate automatically test cases using the ModelJUnit library (

http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/)● All products of the testing and validation process are included in an

automatically generated HTML website which documents the testing coverage

and validation results in detail.● This test documentation package is included in the component’s package for

the benefit of reusers.

http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/

http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/

Generated Test Documentation

Design Pattern Analysis

● Pattern analysis is scanning the source code of the Reuse Project for design

patterns. Not only it identifies the type of the pattern but it is also able to

determine the classes that participate on this specific pattern. ● Design patterns’ participants for certain patterns may be good starting points

for components’ extraction.

Class cluster recommendation

Using the Cluster Recommendation options, the Reuse Engineer can easily come

up with some recommendations of class clusters that could form possible

components. For the time being COPE provides two methods for recommending

such class clusters:

Dependencies Recommender: uses a genetic algorithm in order to form class

clusters using the source code of the Reuse Project.

Pattern Recommender: forms a cluster for each pattern detected in the source

code of the Reuse Project.

Class-based component extraction

● For component extraction another very useful approach is to select a class

and extract a component based on this class. ● The resulting component will have the interface of the public methods of the

class and will include all the required classes for the reuse of this class. ● The reuse engineer can select this class based on the metrics that are

presented in the main window, and especially the Cluster Size, Layer and R

(our own reusability index) metrics. ● Classes which are lower in the layered digraph of the project (have small layer

value), have few dependencies (have small Cluster Size) and have larger R

value (are more reusable) are good candidates for reusable components. ● The reuse engineer can extract components by right-clicking any class from

the main window that seems promising based on the aforementioned metrics

and extract a component for this class.

Recommenders Dialog

All recommenders present a similar dialog to the reuse engineer who can examine

the recommendations

Component Making

Based on the analyses and recommendations carried out earlier the Reuse Engineer can

now produce independent software components and then place those components in the

repository using the ‘Knowledge Manager’ feature.

Four different kinds of component makers:

Interface Maker: This component maker uses as input the clusters produced by the

“Dependencies Recommender”

Dependency Maker: This component maker presents all the classes of the project along

with their reusability assessment. The reuse engineer can select a class and extract a

component providing the functionality of the selected class.

Adapter Pattern Maker: This component maker presents the clusters produced by the

'Pattern Recommender' and displays clusters involved in Adapter pattern instances.

Proxy Pattern Maker: This component maker presents again the clusters produced by the

“Pattern Recommender” but this time it displays only clusters involved in Proxy pattern

instances.

User Interface for Component MakersUI for component makers is similar to all makers such as the one for the

Dependency Maker depicted below.

Generated Components

● Extracted components will be opened for further processing using an IDE (e.g.

Eclipse or NetBeans). ● The reuse engineer will use the IDE to comprehend the component, create

test cases for it or execution scenarios, discover further dependencies that are

required which are not recoverable through static analysis (e.g. data

dependencies). ● The component can then be tested dynamically using the test cases or

execution scenarios that were developed by the reuse engineer. ● Next we will discuss the component extracted from the component makers and

have a closer look to their structure before looking at importing these

components in the COMPARE component repository with the help of the

Knowledge Manager.

Component Package

The Knowledge Manager

● The Knowledge Manager provides the Reuse Engineer

with a way of providing meta-information for the

components s/he generates. Moreover s/he can classify

those components to a specific domain and concept.● Moreover, the Knowledge Manager serves as an

intermediate between the COPE platform and the

component repository of COMPARE.

Characterizing a component with the Knowledge Manager

Classifying the Component in its Domain

Synchronizing with COMPARE repository

The Component Repository and Search Engine (COMPARE) is a web portal that allows SME software re-users to search and discover:→ software artefacts, → technical documents, → test suites related to open-source software.

In addition, it allows the stakeholders of the Domain Engineering Process (reuse engineers, domain experts, component testers and certifiers) to manage and maintain the assets stored in the repository.

The end-users can be endowed by using the advanced filtering capabilities as well as by accessing information about the verification and certification attributes of a component.

Finally, it provides a communication mechanism between the re-users and the reuse-engineers

COMPARE current implementation

COMPARE Component Repository and Search Engine

● Components extracted from COPE and/or other components can be uploaded

in a component repository and search engine for access by the SMEs

developers.● OPEN-SME project has developed the COMPARE Component Repository and

Search Engine.● Some of the features of COMPARE is that is supports storing, cataloguing and

searching of components but it also builds an social environment around its

component providing for example a Wiki page and a forum page for each

component.

COMPARE Home Page

Component Searching

COMPARE provides a page for each Component

Component Wiki and Forum

Γραμμή 1 Γραμμή 2 Γραμμή 3 Γραμμή 40

2

4

6

8

10

12

Στήλη 1Στήλη 2Στήλη 3

Users can download the components from their file repositories

Reuse engineers can update components’ details

Overall ArchitectureOverall Architecture

Summarizing COPE innovation features

● Component recommendation algorithms based on– Class dependencies– Design pattern instances– Individual classes (e.g. domain entity classes) that the reuse engineer identifies

as interesting● Cluster reduction based on class cycle analysis and manipulation● “Pivoting”, to produce components that contain already produced

components (leading to component variants)● Integration of the above with typical static (e.g. measurement) and dynamic

analysis (execution scenarios coverage), and documentation tools● Management of the entire recycling process






Software recycling business models

● Several business models are possible:– SME AGs offer recycling service for free to member SMEs,

charging other SMEs or large companies– Recyling service offered for a subscription fee– Repository access is charged– Pure open source models are also possible, based on

additional services, like component maintenance, testing,

documentation, training etc.● Pricing models must be established

Total Process Cost (TPC)

TPC =

May be used for pricing calculations, e.g. how much a reuse client should be charged

for the reuse of a specific component

∑i=1

i

[(bi∗Lc i)+Ai ]]+( 1−RN

)∗∑j=1

j

[(b j∗Lc j)+A j ] ]

Total Cost of Process elements

TCP = Total Cost of Process

b = Relative cost of engineering activities - represents the fraction of cost per

activity. (b is is an estimation and can be provided through simulations (Monte-Carlo) or

by regression analysis.)

Lc = Labor cost for Reuse Engineer

A = Activities additional overheads

R = Proportion of adaptation activities requested (R < 1)

N = Number of reuses over which the asset development costs will be amortized

i = the range of additional requested activities (e.g. certification)

j = the range of all activities minus the i activities

Software Recycling Process Yield

● Throughput Yield (TPY), is defined as the number of units coming out of a

process divided by the number of units going into that process over a specified

period of time. Only good units with no rework are counted as coming out of an

individual process (source: Wikipedia).● For Software Recycling this may be interpreted as “the amount of produced

components' code (measured in terms of lines of code) divided by the amount of

code of the processed OSS projects over a specified period of time”.● Potentially, if component variants are produced, the same OSS code may be

contained more than once in components, leading to a yield that is higher than

100%! ● Yield depends mainly on project design quality (well designed projects will yield

more components in less time), on reuse engineer ability (different people have

very different productivities) and quality of the tooling for recycling






Component Generation

● Components have been generated in OPENSME since February 2012● Three reuse engineers have worked part-time to recycle a number of OSS

projects from different domains, producing 86 components up to now. Projetcs

are:– BorgCalendar (Office Automation), CentraView/Ebineutrino (ERP/CRM),

GanttProject (Process/Project management), Plazma (User Interface),

RosJava (Robotics), Vuze (utility), Zxing (Android), Jbpm (Process/Project

management)● Example component: AztecReader (from Zxing)● Time needed to extract one component with this semi-automated procedure and

produce basic documentation (excluding testing) varies from ten minutes to three

man-hours● Average size of generated components is ~1K lines of code

Concluding remarks

● OPEN-SME tries to bridge the gab between reusing whole OSS projects and

the opportunistic reuse of small granules (e.g. classes).● The inspiration from this comes from the success of OSS component libraries

such as the Apache Commons (http://commons.apache.org/). OPEN-SME

wishes to extend this by providing components from existing OSS projects.● More components means more attention from the developers● More domain specific components means more value from reuse● OPEN-SME provides domain and application engineering processes and three

tools that hopefully will enable OSS component reuse for software

development SMEs.

http://commons.apache.org/

http://commons.apache.org/

Future Work

● Currently, only Java source code may be analysed– Implementation of C, C#, C++, PhP, etc code parsing is planned. Only parsing is

necessary to populate an internal data base on which the various COPE tools operate ● Component generation for more domains, further population of the component repository

for already examined domains● Large scale reuse in SME software applications. Up to now only limited trials have been

run to test the repository and generated components● Improvement of algorithms used for component identification, isolation and extraction

(Pivoting, class cluster analysis, design pattern analysis)● Further support of the reuse engineer cognitive process for isolating components (e.g.

through semantic analysis on the code, program comprehension techniques)● Calibration of recycling cost models (i.e. calculation of coefficients, assessment of

probabilities for expected tasks according to component/project etc.)● Financial/dynamical modeling of the software recycling process

References

● 'Federated Search for Open Source Software Reuse', Fotios Kokkoras, Konstantinos Ntonas, Apostolos

Kritikos, George Kakarontzas and Ioannis Stamelos, Proc. 38th Euromicro SEAA 2012● 'Extracting Components from Open Source: The Component Adaptation Environment (COPE)

Approach', George Kakarontzas, Ioannis Stamelos, Stefanos Skalistis and Athanasios Naskos, Proc. 38th

Euromicro SEAA 2012● 'Towards Open Source Software System Architecture Recovery Using Design Metrics', Eleni

Constantinou, George Kakarontzas, Ioannis Stamelos, PCI 2011, 15th Panhellenic Conference, IEEE Computer Society Press

● ‘A Semi-Automated Process For Open Source Code Reuse’ Apostolos Kritikos, George Kakarontzas and

Ioannis Stamelos, Proceedings of the 5th International Conference on Evaluation of Novel Approaches in Software Engineering (ENASE '10), pp. 179-185, 22-24 July 2010, Athens, Greece

● 'Reusability Assessment of Object-Oriented Software: A Metrics-Based Approach', George Kakarontzas;

Eleni Constantinou; Apostolos Ampatzoglou; Ioannis Stamelos, forthcoming● 'Component Certification as a Prerequisite for Widespread OSS ReuseKakarontzas, G., Katsaros, P.,

Stamelos, I.' , Electronic Communications of the European Association of Software Science and Technology

(EASST), Vol. 33: Foundations and Techniques for Open Source Software Certification, 2010

THANK YOU FOR ATTENDING

QUESTIONS