• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Software recycling
 

Software recycling

on

  • 632 views

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

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

Statistics

Views

Total Views
632
Views on SlideShare
632
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Software recycling Software recycling Presentation Transcript

    • Software Recycling Ioannis StamelosAristotle University of Thessaloniki Dept of Informatics Software Engineering Group http://sweng.csd.auth.gr stamelos@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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Presentation Outline● Introduction● Software recycling: who, what and why?● The OPENSME project: Software recycling techniques and tools● Software recycling economics● 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
    • 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
    • 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)
    • 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?
    • 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.
    • Presentation Outline● Introduction● Software recycling: who, what and why?● The OPENSME project: Software recycling techniques and tools● Software recycling economics● Conclusion and Future work
    • 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 OVERVIEWOpen-Source Software Reuse Service for SMEsGrant 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 approachOPEN-SME adopts an approach that is centred on the role of re-use engineers,charged with discovering and adapting software components to DomainArchitectures, known to the re-users.Although reuse engineers are necessary for an effective reuse, OPEN-SME toolsuite will automate as much as possible the reuse engineers’ tasks.
    • 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.
    • OPENSME Expected Results (contd) 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.
    • 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) OENOPEN-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
    • 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 OpenSource Software (OSS) applications that are available through the OSS searchengines (OCEAN)● During analysis and design the OSS exemplars will provide inspiration for theconcepts of the reference architecture.● The role of the reference architecture is to provide a detailed description for thecommon 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 referencearchitecture will be components that will be discovered with the analysis of theOSS 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.
    • OCEAN: current implementation
    • OCEAN StatusAvailable 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
    • OPEN-SME Tools: COPE Component Adaptation EnvironmentA 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.
    • 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 LifecycleA Reuse Project’s lifecycle consists of the following phases:Analysis phase: the source code of the target F/LOSS project is being analyzedand the results of this analysis are being stored in its “Reuse Project”.Component Recommendation: in this phase COPE automatically suggests classclusters that could serve as reusable components.Component Making: this set of functionalities allows the user to extractcomponents from the reuse project by either using class clusters recommended inthe Cluster Recommendation phase or by selecting a single class that along withits dependencies will form a reusable component.Knowledge Management: in this phase the user provides information for thegenerated components. Using the “Semantic Application” feature, the user candescribe the functionality of each component. Moreover s/he can classify theresulting component to a specific domain and concept and finally upload thecomponent to the COMPARE component repository.
    • Creating a Reuse Project
    • Performing Static Analysis withCOPE
    • Static Analysis Results
    • Source File IndexingSource File Indexing is another analyzer that creates an index from the source filesof a Reuse Project. This index enables the feature of the internal search engineand provides five different fields for targeted search:Full Text: performs search for the specified keywords to the whole class fileName: performs search for the specified keywords to the name of the class fileAttribute: performs search for the specified keywords to the attributes of the classfileMethod: performs search for the specified keywords to the methods of the classfileComment: performs search for the specified keywords to the comments of theclass file
    • Searching text with COPE
    • Documentation GenerationDocumentation Generation creates the Javadoc documentation for the sourcecode of the Reuse Project augmented with UML diagrams for each class andpackage. Internally we reuse the APIVIZ project (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 AnalysisStep 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
    • CoverageThe reuse engineer can be informed about the coverage that the executionscenario achieves
    • Method paths coveredMoreover by selecting a specificmethod from the table in the centre ofthe dialog and clicking to the “Details”button, the Reuse Engineer isprompted with a new dialog whichpresents new coverage information,specifically for the selected method.COPE provides not only the LCSAJand statement coverage metrics forthe selected method but also itvisualizes the paths that were coveredby the execution scenario provided(text highlighted in green).
    • Method Control Flow GraphCOPE provides the option ofdisplaying the Control Flow Graph for aspecific method. By clicking the“Display Control Flow Graph” button,the control flow graph opens in a newdialog
    • Component ValidationComponent 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 components 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 ValidationOnce the AspectJ file has been generated the Reuse Engineer can proceed inperforming validation process by clicking to “Perform Validation Process” button. Ifno errors occur a success message is prompted after a while.
    • Additional validation featuresIn 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.
    • 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 recommendationUsing the Cluster Recommendation options, the Reuse Engineer can easily comeup with some recommendations of class clusters that could form possiblecomponents. For the time being COPE provides two methods for recommendingsuch class clusters:Dependencies Recommender: uses a genetic algorithm in order to form classclusters using the source code of the Reuse Project.Pattern Recommender: forms a cluster for each pattern detected in the sourcecode 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 DialogAll recommenders present a similar dialog to the reuse engineer who can examinethe recommendations
    • Component MakingBased on the analyses and recommendations carried out earlier the Reuse Engineer cannow produce independent software components and then place those components in therepository 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 alongwith their reusability assessment. The reuse engineer can select a class and extract acomponent providing the functionality of the selected class.Adapter Pattern Maker: This component maker presents the clusters produced by thePattern 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 patterninstances.
    • User Interface for ComponentMakersUI for component makers is similar to all makers such as the one for theDependency 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.
    • ComponentPackage
    • 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 withthe Knowledge Manager
    • Classifying the Component in itsDomain
    • Synchronizing with COMPARErepository
    • 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
    • COMPARE Component Repositoryand 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 eachComponent
    • Component Wiki and Forum1210 8 Στήλη 1 6 Στήλη 2 Στήλη 3 4 2 0 Γραμμή 1 Γραμμή 2 Γραμμή 3 Γραμμή 4
    • Users can download thecomponents from their filerepositories
    • Reuse engineers can updatecomponents’ details
    • Overall 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
    • Presentation Outline● Introduction● Software recycling: who, what and why?● The OPENSME project: Software recycling techniques and tools● Software recycling economics● Conclusion and Future work
    • 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 = 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
    • Total Cost of Process elementsTCP = Total Cost of Processb = Relative cost of engineering activities - represents the fraction of cost peractivity. (b is is an estimation and can be provided through simulations (Monte-Carlo) orby regression analysis.)Lc = Labor cost for Reuse EngineerA = Activities additional overheadsR = Proportion of adaptation activities requested (R < 1)N = Number of reuses over which the asset development costs will be amortizedi = 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
    • Presentation Outline● Introduction● Software recycling: who, what and why?● The OPENSME project: Software recycling techniques and tools● Software recycling economics● Conclusion and Future work
    • 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.
    • 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