1 / 15

Quality of Service-Driven Requirements Analyses for Component Composition: A Two-Level Grammar++ Approach

Quality of Service-Driven Requirements Analyses for Component Composition: A Two-Level Grammar++ Approach. Shih-Hsi Liu 1 , Fei Cao 1 , Barrett R. Bryant 1 , Jeff Gray 1 , Rajeev R. Raje 2 , Andrew M. Olson 2 , and Mikhail Auguston 3. Software Composition and Modeling Laboratory.

Patman
Download Presentation

Quality of Service-Driven Requirements Analyses for Component Composition: A Two-Level Grammar++ Approach

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. Quality of Service-Driven Requirements Analyses for Component Composition: A Two-Level Grammar++ Approach Shih-Hsi Liu1, Fei Cao1, Barrett R. Bryant1, Jeff Gray1, Rajeev R. Raje2, Andrew M. Olson2, and Mikhail Auguston3 Software Composition and Modeling Laboratory Department of Computer and Information Sciences 1 University of Alabama at Birmingham 2 Indiana University Purdue University Indianapolis 3 Naval Postgraduate School

  2. Outline • Introduction • Problem Statements • Proposed Solution • Conclusion • Future Work

  3. Introduction • Objective: construct a Distributed Real-time and Embedded (DRE) system by composing black box components that satisfies functional and non-functional requirements • Component Based Software Engineering (CBSE) and Software Product Line (SPL) concepts: reusability, changeability, productivity, expeditiousness • DRE systems: system resource sensitive (QoS sensitive) - QoS sensitive: decides the correctness of functionalities and margins of Quality of Service (QoS) satisfaction

  4. Problem Statements (1/2) QoS transcends functional properties in DRE systems – reduces the CBSE + SPL virtues and new problems arise in the requirements and design phases: • Component Perspective Problem - numerous QoS properties require evaluation for a DRE system - tangling between functional and non-functional concerns: component perspective composition for QoS-sensitive systems • Abundant Alternative Problem - generated based on different composition decisions and permutations of selected components - different QoS margins generated from various alternatives affect correctness of functionalities (e.g., hard real-time) and magnitude of performance (e.g., soft real-time)

  5. Problem Statements (2/2) • The Composition Semantics Problem - Composition regarding QoS parameters: degrade or upgrade QoS parameters (glue/wrapper code) - Problem: (a) No well-defined semantics for composition regarding QoS Parameters (b) Difficult to evaluate QoS parameters

  6. Proposed Solution – A Grammatical QoS-Driven Approach (1/7) • Motivation of the proposed solution: (a) Separation of concerns concept - paths: a sequence of components that determines how or how well functional tasks perform in terms of application-specific and functionality-determined information - Functional path: how - QoS systemic path: how well (b) Context Free Grammar (CFG) concept - components are operands - composition semantics regarding QoS are operators - production rules are composition decision - a syntax tree is an alternative of SPL

  7. Proposed Solution (2/7) • A Grammatical Concept: Two-Level Grammar++ - The 1st CFG: define a set of parameters The 2nd CFG: define a set of function definitions - Define syntax and semantics of a programming language The 1st CFG: define the syntax by production rules The 2nd CFG: define the semantics of the production rules • A QoS-Driven Concept: A TLG++ Class defines a QoS Parameter - The 1st CFG: define the selected components for the QoS systemic path - The 2nd CFG: define the composition semantics regarding the QoS parameter • An Inference Concept: Jess Rule Engine - The 2nd CFG: define the queries for verifying pre-conditions and post-conditions of composition

  8. Proposed Solution (3/7)

  9. 1 Security  C1 C2 D1 2 D1  C3 D2 | C4 D3 3 D2  C4 C5 | C5 C6 4 D3  C5 D4 | C5 C7 5 D4  C3 C7 1 Signal  C1 C2 E1 2 E1  C3 E2 | C4 E3 | C5 E4 3 E2  C6 C7 4 E3  C3 C5 E5 | C3 C6 5 E4  C4 C6 C7 6 E5  C7 1 CPU  C1 F1 | C2 F2 2 F1  C2 C4 F3 | C3 C4 F4 3 F2  C5 C6 F5 | C5 | C6 F6 4 F3  C7 C6 5 F4  C2 C5 6 F5  C3 C7 7 F6  C1 C4 Proposed Solution (4/7)

  10. Proposed Solution (5/7): Cascading Scenario class Security_1 implements Serializable 2 QoSPath :: Comp_1 Comp_2. 3//…other parameter definition 4 Query_1 := semantics of queryComponent with Comp_1; //verifies the pre-condition 5 Query_2 := semantics of queryComponent with Comp_2; //verifies the pre-condition 6 Query_3 :=if Query_1 && Query_2,then semantics of minimum with 7 Comp_1 and Comp_2,else False, end if; 8 Query_4 := semantics of queryPattern with QoSValue; //verifies the post-cond. of Comp_1 9 //and Comp_2, see if it is out of range 10 if Query_4,then MyRete semantics of UpdatePattern, else “Composition False”, end if. 11 //if Query_4 true, the composed pattern is assured. Update the pattern to the knowledge base 12 semantics of queryComponent with Component : 13 //…the semantics of the query for pre-conditions 14 semantics of minimum with Component1 and Component2 : 15 //…the semantics of the component composition 16 semantics of queryPattern with Double : 17 //…the semantics of the query for post-conditions 18 semantics of UpdatePattern : 19 //…the semantics that updates the verified composed pattern into the knowledge base end class

  11. Proposed Solution (6/7): Cascading Scenario class Security_2 implements Serializable. 2 QoSPath :: Comp_3 ; Comp_4. //…Comp_3 OR Comp_4 as alternatives 3 //…other parameter definition 4 semantics of ProductLine_1 with Component1 : //semantics for Comp_3 OR Comp_4 5 Query_1 := semantics of queryComponent with Component1;//verify the pre-condition 6 if Query_1,then semantics of addition with Security_1 and Component1, else False, end if; 7 Query_2 := Rete semantics of queryPattern with QoSValue; 8 if Query_2,then Rete semantics of UpdateFact, 9 Rete semantics of UpdatePattern, else “Composition False”, end if. 10 //…verify the post-condition 11 semantics of addition with Component1 and Component2 : 12//…semantics of addition 13 //…semantics of queryPattern, UpDateFact and UpdatePattern are ignored here. end class

  12. Proposed Solution (7/7)

  13. Conclusion A straightforward and manageable approach for evaluating and verifying QoS characteristics - separation of concern by the QoS systemic path concept - reduce the overload in the requirements phase by eliminating infeasible alternatives - evaluate individual and system-wide QoS parameters - separation of inference concern by a stand-alone inference engine

  14. Future Work • A component selection procedure for QoS systemic paths • Integrate T-Clipse and Jess: current Jess queries defined in TLG++ is unreadable • A better goal metric: current goal is coarse-grained • Grammar reproduction concept: add mutation and crossover for the 1st CFG: increase the diversity of design space • Toward domain analysis for software product line: commonality and variability analysis at the QoS systemic path abstraction layer

  15. Questions? • More research information http://www.cis.uab.edu/liush • Acknowledgements This research was supported in part by U. S. Office of Naval Research award N00014-01-1-0746

More Related