Proceeding of the 16th International Academic MindTrek Conference 2012
DOI: 10.1145/2393132.2393152
|View full text |Cite
|
Sign up to set email alerts
|

A methodology on extracting reusable software candidate components from open source games

Abstract: Component-Based Software Engineering (CBSE) focuses on the development of reusable components in order to enable their reuse in more systems, rather than only to be used to the original ones for which they have been implemented in the first place (i.e. development for reuse) and the development of new systems with reusable components (i.e. development with reuse). This paper aims at introducing a methodology for the extraction of candidate reusable software components from open source games. The extracted comp… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
1

Citation Types

0
9
0

Year Published

2016
2016
2021
2021

Publication Types

Select...
3
2

Relationship

4
1

Authors

Journals

citations
Cited by 10 publications
(9 citation statements)
references
References 7 publications
(2 reference statements)
0
9
0
Order By: Relevance
“…In this section, we present two illustrative examples and the lessons that we have learned from using the proposed metrics for white‐box reuse purposes. In particular, we examined (a) the reuse process that was introduced by Lambropoulos et al, in which a mobile application was developed, based to the best possible extent on open‐source software reuse; and (b) replicate the reuse process that was introduced by Ampatzoglou et al for providing an implementation of the Risk game, based on reusable components. The first project was a movie management application (see Figure ) that reused artifacts from eight open‐source software systems from the same application domain, whereas the second project was a re‐implementation of the famous Risk game that reused artifacts from four open‐source software systems.…”
Section: Illustrative Examplementioning
confidence: 99%
See 2 more Smart Citations
“…In this section, we present two illustrative examples and the lessons that we have learned from using the proposed metrics for white‐box reuse purposes. In particular, we examined (a) the reuse process that was introduced by Lambropoulos et al, in which a mobile application was developed, based to the best possible extent on open‐source software reuse; and (b) replicate the reuse process that was introduced by Ampatzoglou et al for providing an implementation of the Risk game, based on reusable components. The first project was a movie management application (see Figure ) that reused artifacts from eight open‐source software systems from the same application domain, whereas the second project was a re‐implementation of the famous Risk game that reused artifacts from four open‐source software systems.…”
Section: Illustrative Examplementioning
confidence: 99%
“…The goal of these illustrative examples was to compare the ability of the three examined metrics (ie, REI, FWBR, QMOOD) to subsume the expert's opinion and guide reuse artifact selection. We note that this analysis is a posteriori one; the decisions of Lambropoulos et al and Ampatzoglou et al were not considering these metrics, but were only taken based on the subjective opinion of the developers. Out of the 11 reuse activities, only eight of them were involving the reuse of more than one alternative for reuse (ie, in the rest: the decision was only between to reuse or to build from scratch).…”
Section: Illustrative Examplementioning
confidence: 99%
See 1 more Smart Citation
“…To guide 'reusers' in the selection of the most adaptable asset (among the functionally fitting ones), reusability needs to be assessed, i.e., the degree to which a certain asset can be reused in other systems. To this end, a wide range of reusability indices have been proposed [2], [5]; these indices are calculated as functions of metric scores that quantify factors that influence reusability. However, several research efforts in the literature on reusability assessment (see Section II) suffer from one or both of the following two limitations: (a) only highlight the parameters that should be considered in reusability assessment thus, not providing an aggregated reusability measure, or (b) only consider structural aspects of the software asset, ignoring aspects such as documentation, external quality, etc.…”
mentioning
confidence: 99%
“…To validate the accuracy of the developed index, we have performed a case study on 80 well-known open source assets. In particular, we assess the reusability of the software assets, based on the proposed index and then contrast it to their actual reuse, as obtained by the Maven repository 2 . We note that despite the fact that this accurate reuse metric is available for a plethora of open source reusable assets (already stored in Maven repository), our proposed index can be useful for assessing the reusability of assets that: (a) are not deployed on Maven, (b) are developed in-house, or (c) are of different levels of granularity (e.g., classes, packages, etc.)…”
mentioning
confidence: 99%