Loading in 2 Seconds...
Loading in 2 Seconds...
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.
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
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
Outline • Introduction • Problem Statements • Proposed Solution • Conclusion • Future Work
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
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)
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
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
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
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)
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
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
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
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
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