MoMS: Multi-objective miniaturization of software

Abstract

Abstract-Smart phones, gaming consoles, and wireless routers are ubiquitous; the increasing diffusion of such devices with limited resources, together with society's unsatiated appetite for new applications, pushes companies to miniaturize their programs. Miniaturizing a program for a hand-held device is a time-consuming task often requiring complex decisions. Companies must accommodate conflicting constraints: customers' satisfaction with features may be in conflict with a device's limited storage, memory, or battery life. This paper proposes a process, MoMS, for the multi-objective miniaturization of software to help developers miniaturize programs while satisfying multiple conflicting constraints. It can be used to support the reverse engineering, next release problem, and porting of both software and product lines. The process directs the elicitation of customer pre-requirements, their mapping to program features, and the selection of the features to port. We present two case studies based on Pooka, an email client, and SIP Communicator, an instant messenger, to demonstrate that MoMS supports optimized miniaturization and helps reduce effort by 77%, on average, over a manual approach.

MoMIT: Porting a JavaScript Interpreter on a Quarter Coin

“…In Figure 1 we present the distribution of percentage changes in performance metrics for the 86 JS-interpreter selected features. This value is calculated using Equation (5). We observe that the boxes are flat in the three performance metrics studied, indicating that there is little variation of percentage change values among features.…”

“…Ali et al proposed MoMs, a multi-objective approach for the miniaturization of applications based on user's prerequisites, storage occupation and CPU consumption [5]. They apply their approach to two applications (an email client and a instant messenger) and show that they could reduce the effort by 77% on average, over a manual approach.…”

“…Steps to benchmark the selected JS interpreter features. Input : S, harness, file with features, codeSizeJ, memU sJ, execT imeJ, runs Output: report f ile 1 report f ile = ∅ 2 forall row ∈ file with features do 3 Save feature and its test value on (cf g) 4 Generate j based on cf g 5 Compile harness with j 6 if compilation fails then 7 Continue with next row Write δcodeSize, δmemU s, δexecT ime to report f ile 19 end 20 Close report f ile 21 return report f ile 22 end 23 return report f ile Algorithm 1 receives as an input a JS file (S); a C file with an embedded JS interpreter (harness), which is the code that we miniaturize and port to a constrained device; a file containing JS interpreter's features with the values we are interested to test (file with features), and the performance metric values measured by executing S using default Duktape features (j); and the number of time to execute harness. Since execution time and memory usage may vary from run to run due to the non-deterministic way that CPUs and operating system task schedulers work, we set runs = 10 to control for possible variations of measurements.…”

Requirements Traceability for Object Oriented Systems by Partitioning Source Code

“…However, we cannot claim that the same results would be achieved with other systems. Different systems with different identifiers' quality ,reverse engineering code approach, requirements, using different software artifacts and other internal or external factors [24] may lead to different results. However, the three selected systems have different source code quality and requirements.…”

“…Requirements: In a previous work [24], we used PRE-REQUIR [8] to recover requirements for Pooka and SIP. We recovered 90 and 82 functional requirements for both systems respectively.…”