1 / 19

Resource-based Approach to Feature Interaction in Adaptive Software

This work explores a resource-based approach to tackle feature interactions in adaptive software, emphasizing dynamic adaptation and assurance issues. It presents the RAFTING project focusing on critical infrastructure protection through adaptable software programs. The study delves into adaptive software components, feature interactions, and outlines implementation scenarios like wireless image retrieval. The resource-centric perspective simplifies feature interaction detection and is well-suited for component-based software development. Feature-resource relationships are defined in terms of usage and production percentages, offering insights into system specifications.

jamesrosa
Download Presentation

Resource-based Approach to Feature Interaction in Adaptive Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Resource-based Approach to Feature Interaction in Adaptive Software Betty H.C. Cheng Software Engineering and Network Systems Laboratory Michigan State University http://www.cse.msu.edu/SENS Authors: Jesús Bisbal andBetty H.C. Cheng jesus.bisbal@upf.edu, chengb@cse.msu.edu ACKNOWLEDGEMENTS: This work has been supported in part by grants: NSFEIA-0000433, CDA-9700732,EIA-0203060, EIA-0130724, ITR-0313142, Department of the Navy, and Office of Naval Research under Grant No. N00014-01-1-0744.

  2. Context… • Aspects of self-management problem being addressed? • Self-management involves dynamic adaptation • Focus on assurance issues of self-management • Feature interaction • What aspects are you NOT dealing with? • Adaptation mechanisms • ADLs for self-management/adaptation • Programming Languages • Domains, properties, or applications targeting? • Mobile computing applications • Component-based software development • Assurance issues RAFTING

  3. RAPIDware Project • Ongoing project in SENS Laboratory • Funded by U.S Office of Naval Research • Critical Infrastructure Protection /Adaptable SW Program • Goal: Software (middleware) that can protect itself from: • Hardware and software component failures • Changing environmental conditions • Changing requirements (e.g. security policies) • Malicious entities • Applications: • Dynamic power management • Dynamic error correction for data transmission/receipt • Dynamically changing security algorithms and policies • Dynamic introduction of fault-tolerant capabilities RAFTING

  4. Example RAPIDware Activities • Transparent shaping • Automated weaving adaptive behavior into existing programs [WOSS02,ICAC04,DOA04,ICDCS04] • Rigorous software engineering of adaptive code • Safe adaptation using dependency analysis [WADS’04] • Synthesis of fault-tolerant code from specifications [DSN04] • Adaptive overlay networks [ICNP’03, ICDCS’04] • Middleware-kernel interaction [MPAC’04] • Decision-making software using machine learning techniques [ICDL’04] • Adaptive energy management [IWQoS’04] RAFTING

  5. Outline • Adaptive software components • Feature interactions • Resource-based approach • Implementation: wireless image retrieval scenario • Future work RAFTING

  6. Adaptive Software Components • Dynamically adapt at run-time • Reactive to environmental or user requirement changes • Adaptive mechanisms actively investigated • Assurance of adaptation mechanisms somewhat neglected to date RAFTING

  7. Feature Interactions • Widely investigated by the telecommunications industry • Receiving increasing attention from other domains: • Whenever several software entities control a shared resource • “A feature interaction occurs when the behavior of one feature is affected by the behavior of another feature, or another instance of the same feature” [L. Blair et al., 2001] • Ex: electronic mail, web services, component-based software RAFTING

  8. Feature Interactions • Off-line (design-time) approaches: • Formally describe each feature (e.g. FOPL, CTL) • Reason about interactions (e.g. theorem provers, model checking) • Requires a priori knowledge of complete set of features • On-line approaches (run-time) approaches: • Features Manager mediates between features to avoid interactions • Requires training phase or domain-specific knowledge RAFTING

  9. RAFTING: Resource-based Approach to FeaTure InteractioN • Premise: • For practical purposes all feature interactions are or can be thought as being caused by resource contention • Shifts focus from features to resources used by those features • Simplifies feature interaction detection process • Well-suited to component-based software development using third-party vendor COTS • Vendors do not disclose internal workings of components, only externally observable behavior RAFTING

  10. Resource-based Approach to Feature Interaction • Features are seen as information transformation processes (i.e., services) • Resources are the required inputs and outputs Resource1 Output1 Resource2 Feature Output2 Resource3 ... Outputm ... Resourcen RAFTING

  11. Goal1 Goal2 Output11 Resource11 ... Feature1 ... Goaln ... Output1q Resource1p ... Resourcem1 Outputm1 Featurem ... ... Resourcemr Outputmt Resource-based Approach to Feature Interaction • Goals are the requirements of the overall behavior obtained by composing a set of features RAFTING

  12. Resource-based Approach to Feature Interaction • Feature-Resource Relationships defined in terms of usage and production of a resource • USES(%) • Describes how a feature uses a given resource or perform its task • PRODUCES(%) • Indicates that a feature produces a resource • Resources can be rather abstract: • E.g.: time could be considered a resource in order to describe time-dependent relationships RAFTING

  13. Resource-based Approach to Feature Interaction • System specifications: • Features • Resources • Relationships • Goals • General objective: • a generic features manager will only require this information in order to mediate between features RAFTING

  14. Wireless Image Retrieval Scenario • Setup: • Producer/consumer architecture • Producer(s) run on mobile devices and transmit information over a wireless link • E.g.: iPAQs, wearables, and other handhelds • Consumer runs on a more powerful device (desktop) and processes information • Dynamic Adaptation Scenario: • Limited resources of producers requires dynamic adaptation to fulfill quality of service (QoS) goals: • Insertion/Removal of Forward Error Correction (FEC) filter to improve quality of communication link • Modification of Image Resolution to reduce battery consumption, when possible RAFTING

  15. Goal:‘Maximize battery life Goal: Quality of image Res: Bandwidth Res:Battery lifetime (%) left on device Fea: Resolution of images being captured Fea: FEC on (for high loss rate) or off (for low loss rate) For demonstration purposes only. Control over the environment. Wireless Image Retrieval Scenario • Producer application • Device equipped with camera RAFTING

  16. Wireless Image Retrieval Scenario • Consumer application (e.g., headquarters) • Receives informationtransmitted from several producers RAFTING

  17. Future Work • Can all interesting interactions be modeled using this resource-centric approach? • If not, which ones can? • Resolution policies expressed in terms of resources (for uniformity) or in terms of features (users’ perspective) RAFTING

  18. Happy Halloween! RAFTING

  19. Questions? RAFTING

More Related