A detailed presentation of the OPENSME project (finished July 2012) that I gave at the University of Groningen (NL). Introduces the SWENG team, and describes how components are built out of random open source code and put in a repository for future reuse

1. Software Recycling
Ioannis Stamelos
Aristotle University of Thessaloniki
Dept of Informatics
Software Engineering Group
http://sweng.csd.auth.gr
stamelos@csd.auth.gr

2. Presentation Outline
● Introduction
● Software recycling: who, what and why?
● The OPENSME project: Software recycling
techniques and tools
● Software recycling economics
● Conclusion and Future work

3. Presentation Outline
● Introduction
● Software recycling: who, what and why?
● The OPENSME project: Software recycling
techniques and tools
● Software recycling economics
● Conclusion and Future work

4. Introduction
● Aristotle University of Thessaloniki
● Department of Informatics
● Software Engineering Group

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

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

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

10. Five Research Labs
● Programming Languages and Software
Engineering
● Data Technologies and Engineering
● Information Processing and Artificial Intelligence
● Multimedia (Educational Technologies)
● Networks, Communications and Architecture

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

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

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

14. 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)

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

16. Presentation Outline
● Introduction
● Software recycling: who, what and why?
● The OPENSME project: Software recycling techniques and
tools
● Software recycling economics
● Future work

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

18. Current Situation in the
Software World (2)
● 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

19. Current Situation in the
Software World (3)
● 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)

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

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

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

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

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

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

26. 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)

27. 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?

28. OSS Recycling for the benefit of SMEs
 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.

29. Presentation Outline
● Introduction
● Software recycling: who, what and why?
● The OPENSME project: Software recycling
techniques and tools
● Software recycling economics
● Conclusion and Future work

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

31. OPENSME PROJECT OVERVIEW
Open-Source Software Reuse Service for SMEs
Grant agreement no.: FP7-SME-2008-2 – 243768
Duration: 24 months
Start date: 01.07.2010
Number of beneficiaries: 10
Overall budget: €1,498,707

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

33. The 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.

34. OPENSME Expected Results
 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.

35. OPENSME Expected Results (cont'd)
 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.

36. S E A oi tos
M s c in
s s a
R u3
e l
st
Esn O S r h
x t g S ec
i i S a O n or e
p su
e C
C da S r e
a i t oc
nd e u
E i e ad
n ns n
g s A h Nn
Er eg e
c i
C e ous
o M l
d de
R oi oe
es rs
p t i ( CA)
OEN
OPEN-SME Overview
D a E i ern P cs
o i n ne g r e
m n g i o s
Opt
uu
t s R R u4
e l
st
1
ds
R u 6Bs es oe ad otM e
e l : ui s M l n Cs o l
U Ce
s a
e s Fori
Du n
et a
m
a e Cm nn
Op et
o
Me
ol
ds M e en
E is r g
on i
n le
dg
aat to
dP i n
a
R u1
e l
st P cs
r es
o
E i om t
nr n e
v n
D a Oo g
o i nl y
m n t o (O )
CP E
D a
o i
m n St a
owe
f r
E i er g
n nen
g i T tSt s
e ue
s i A het r
r i c e
ct u
P cs
r es
o A p to
dt in
aa
ds
Pe s
ar
t n
R sb
e al
u e
C pnn
o oet
m s
n
R u5
e l
st
CM nn
Op et
o
r P io A
eo t r n
s y d
st
sa c E i e
eR n n
h g
( OPR)
CM E A
Sfw e ee p etS E
o a D l m M
t r vo n s
R u2
e l
st
Ctm
uo
s
St a
owe
f r A lcto
pi a n
p i
E i er g
n nen
g i E i ern
nne g
g i
Tl
os
o Pcs
r es
o
E i ern
n ne g
g i Ai at
rf c
t
Tl
oo I pt
nu
P cs
r es
o
B i es
u ns
s Ai at
rf c
t
P cs
r es
o Gu
r p
o Opt
uu
t
Us
se

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

38. 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).

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

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

41. Process Configuration > Overview

42. Domain Implementation > Overview

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

44. OCEAN: current implementation

45. OCEAN Status
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

46. OPEN-SME Tools: COPE Component Adaptation
Environment
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.

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

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

49. Creating a Reuse Project

50. Performing Static Analysis with
COPE

51. Static Analysis Results

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

53. Searching text with COPE

54. 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/)

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

56. Performing Dynamic Analysis
Step 1
First we select an available component

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

58. Selecting an Execution Scenario

59. Coverage
The reuse engineer can be informed about the coverage that the execution
scenario achieves

60. 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).

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

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

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

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

65. Generated Test Documentation

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

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

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

69. Recommenders Dialog
All recommenders present a similar dialog to the reuse engineer who can examine
the recommendations

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

71. User Interface for Component
Makers
UI for component makers is similar to all makers such as the one for the
Dependency Maker depicted below.

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

73. Component
Package

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

75. Characterizing a component with
the Knowledge Manager

76. Classifying the Component in its
Domain

77. Synchronizing with COMPARE
repository

78. COMPARE current implementation
 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

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

80. COMPARE Home Page

81. Component Searching

82. COMPARE provides a page for each
Component

83. Component Wiki and Forum
12
10
8
Στήλη 1
6 Στήλη 2
Στήλη 3
4
2
0
Γραμμή 1 Γραμμή 2 Γραμμή 3 Γραμμή 4

84. Users can download the
components from their file
repositories

85. Reuse engineers can update
components’ details

86. Overall Architecture

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

88. Presentation Outline
● Introduction
● Software recycling: who, what and why?
● The OPENSME project: Software recycling
techniques and tools
● Software recycling economics
● Conclusion and Future work

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

90. Total Process Cost (TPC)
TPC =
i j
1−R
∑ [(bi∗Lc i )+Ai ] ]+( N )∗∑ [(b j∗Lc j )+A j] ]
i=1 j=1
May be used for pricing calculations, e.g. how much a reuse client should be charged
for the reuse of a specific component

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

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

93. Presentation Outline
● Introduction
● Software recycling: who, what and why?
● The OPENSME project: Software recycling
techniques and tools
● Software recycling economics
● Conclusion and Future work

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

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

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

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

98. THANK YOU FOR ATTENDING
QUESTIONS