Modeling Features at Runtime

Abstract

International audienceA feature represents a functional requirement fulfilled by a system. Since many maintenance tasks are expressed in terms of features, it is important to establish the correspondence between a feature and its implementation in source code. Traditional approaches to establish this correspondence exercise features to generate a trace of runtime events, which is then processed by post-mortem analysis. These approaches typically generate large amounts of data to analyze. Due to their static nature, these approaches do not support incremental and interactive analysis of features. We propose a radically different approach called live feature analysis, which provides a model at runtime of features. Our approach analyzes features on a running system and also makes it possible to grow feature representations by exercising different scenarios of the same feature, and identifies execution elements even to the sub-method level. We describe how live feature analysis is implemented effectively by annotating structural representations of code based on abstract syntax trees. We illustrate our live analysis with a case study where we achieve a more complete feature representation by exercising and merging variants of feature behavior and demonstrate the efficiency or our technique with benchmarks

PAMELA: An annotation-based Java modeling framework

“…This is also the case of PAMELA. Examples of such approaches are: AC-Contrat [15] which provides runtime verification of properties for context-aware applications; Ramses [8] focused on dynamic adaptations; and [10] that performs feature analysis. [21] wraps running systems in standard UML-like models in order to perform analysis and management tasks by using off-the-shelf MDE tools and techniques whereas FAME [13] is a polyglot library that keeps metamodels accessible and adaptable at runtime (Synchronization of changes between models and code are, however, limited for languages such as Java).…”

Sub-method, partial behavioral reflection with Reflectivity: Looking back on 10 years of use

“…Therefore, these operations must be specified and applied on-demand to the running program. Reflectivity's features can be applied in such an unanticipated way, which is a reason for one to choose Reflectivity as an implementation layer [19,44]. That capability is 5:15 fundamental to projects aiming to dynamically change and/or to control behavior of a running program [11,12,13,14,19,43,44], to enable/disable reflective features on-the-fly [56], or to provide on-demand, instant access to dynamic data [47,49,50,51].…”

“…Interactive feature analysis [19] Dynamic instrumentation of all methods of the system to produce an execution trace for a dedicated execution.…”

“…Consequently, it is important to establish a correspondence between a feature and the source code it is related to. Contribution Denker, Ressia, Greevy, and Nierstrasz [19] provided a model at run time of features called live feature analysis that can establish a map of the different part of the system involved in a user feature.…”

“…Second, partial behavioral reflection provides means to specify when reflection will be triggered, and which entities of the execution context will be reified. This enables fine and customized scoping of the reified context [19,44,47,49,50,51,64,65]. Finally, the combination of sub-method and partial behavioral reflection is needed to define and apply controlled and fine grained behavioral variations.…”