Refactoring Delta-Oriented Product Lines to achieve Monotonicity

Delta-oriented programming (DOP) is a flexible transformational approach to implement software product lines. In delta-oriented product lines, variants are generated by applying operations contained in delta modules to a (possibly empty) base program. These operations can add, remove or modify named elements in a program (e.g., classes, methods and fields in a Java program). This paper presents algorithms for refactoring a delta-oriented product line into monotonic form, i.e., either to contain add and modify operations only (monotonic increasing) or to contain remove and modify operations only (monotonic decreasing). Because of their simpler structure, monotonic delta-oriented product lines are easier to analyze. The algorithms are formalized by means of a core calculus for DOP of product lines of Java programs and their correctness and complexity are given

Earth Observatory Satellite system definition study. Report 3: Design cost trade-off studies and recommendations

An analysis of the design and cost tradeoff aspects of the Earth Observatory Satellite (EOS) development is presented. The design/cost factors that affect a series of mission/system level concepts are discussed. The subjects considered are as follows: (1) spacecraft subsystem cost tradeoffs, (2) ground system cost tradeoffs, and (3) program cost summary. Tables of data are provided to summarize the results of the analyses. Illustrations of the various spacecraft configurations are included

Earth Observatory Satellite system definition study. Report 5: System design and specifications. Volume 1: Baseline system description

A system baseline design oriented to the requirements of the next generation of Earth Observatory Satellite missions is presented. The first mission (EOS-A) is envisioned as a two-fold mission which (1) provides a continuum of data of the type being supplied by ERTS for the emerging operational applications and also (2) expands the research and development activities for future instrumentation and analysis techniques. The baseline system specifically satisfies the requirements of this first mission. However, EOS-A is expected to be the first of a series of earth observation missions. Thus the baseline design has been developed so as to accommodate these latter missions effectively as the transition is made from conventional, expendable launch vehicles and spacecraft to the Shuttle Space Transportation System era. Further, a subset of alternative missions requirements including Seasat, SEOS, SMM and MSS-5 have been analyzed to verify that the spacecraft design to serve a multi-mission role is economically sound. A key feature of the baseline system design is the concept of a modular observatory system whose elements are compatible with varying levels of launch vehicle capability. The design configuration can be used with either the Delta or Titan launch vehicles and will adapt readily to the space shuttle when that system becomes available in the early 1980's

A Framework for Seamless Variant Management and Incremental Migration to a Software Product-Line

Context: Software systems often need to exist in many variants in order to satisfy varying customer requirements and operate under varying software and hardware environments. These variant-rich systems are most commonly realized using cloning, a convenient approach to create new variants by reusing existing ones. Cloning is readily available, however, the non-systematic reuse leads to difficult maintenance. An alternative strategy is adopting platform-oriented development approaches, such as Software Product-Line Engineering (SPLE). SPLE offers systematic reuse, and provides centralized control, and thus, easier maintenance. However, adopting SPLE is a risky and expensive endeavor, often relying on significant developer intervention. Researchers have attempted to devise strategies to synchronize variants (change propagation) and migrate from clone&own to an SPL, however, they are limited in accuracy and applicability. Additionally, the process models for SPLE in literature, as we will discuss, are obsolete, and only partially reflect how adoption is approached in industry. Despite many agile practices prescribing feature-oriented software development, features are still rarely documented and incorporated during actual development, making SPL-migration risky and error-prone.Objective: The overarching goal of this PhD is to bridge the gap between clone&own and software product-line engineering in a risk-free, smooth, and accurate manner. Consequently, in the first part of the PhD, we focus on the conceptualization, formalization, and implementation of a framework for migrating from a lean architecture to a platform-based one.Method: Our objectives are met by means of (i) understanding the literature relevant to variant-management and product-line migration and determining the research gaps (ii) surveying the dominant process models for SPLE and comparing them against the contemporary industrial practices, (iii) devising a framework for incremental SPL adoption, and (iv) investigating the benefit of using features beyond PL migration; facilitating model comprehension.Results: Four main results emerge from this thesis. First, we present a qualitative analysis of the state-of-the-art frameworks for change propagation and product-line migration. Second, we compare the contemporary industrial practices with the ones prescribed in the process models for SPL adoption, and provide an updated process model that unifies the two to accurately reflect the real practices and guide future practitioners. Third, we devise a framework for incremental migration of variants into a fully integrated platform by exploiting explicitly recorded metadata pertaining to clone and feature-to-asset traceability. Last, we investigate the impact of using different variability mechanisms on the comprehensibility of various model-related tasks.Future work: As ongoing and future work, we aim to integrate our framework with existing IDEs and conduct a developer study to determine the efficiency and effectiveness of using our framework. We also aim to incorporate safe-evolution in our operators