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

1 University of Alabama at Birmingham2 Indiana University Purdue University Indianapolis 3 Naval Postgraduate School

Software Composition and Modeling Laboratory

Department of Computer and Information Sciences

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

Proposed Solution (3/7)

NO

NO

NO

NO

Query QoS information of new component(s)

Evaluate All Orthogonal QoS Parameters

Evaluate All Sets of Non-orthogonal QoS Parameters

Evaluate Cumulative Goals of the Alternatives

YES

Write TLG classes for QoS Parameters and convert them into Java by T-Clipse

The Jess Rule

Engine and the

Knowledge Base

Evaluate All Strict QoS Parameters

YES

YES

YES

Save the assured pattern back as a new fact

Proposed Solution (4/7)

1 Security C1 C2 D1 2 D1 C3 D2 |

C4 D33 D2 C4 C5 |

C5 C64 D3 C5 D4 |

C5 C75 D4 C3 C7

1 Signal C1 C2 E12 E1 C3 E2 | C4 E3 | C5 E43 E2 C6 C74 E3 C3 C5 E5 | C3 C65 E4 C4 C6 C76 E5 C7

1 CPU C1 F1 | C2 F22 F1 C2 C4 F3 | C3 C4 F4 3 F2 C5 C6 F5 | C5 | C6 F64 F3 C7 C65 F4 C2 C56 F5 C3 C77 F6 C1 C4

Proposed Solution (5/7): Cascading Scenario

class Security_1 implements Serializable2 QoSPath :: Comp_1 Comp_2.3 //…other parameter definition4 Query_1 := semantics of queryComponent with Comp_1; //verifies the pre-condition5 Query_2 := semantics of queryComponent with Comp_2; //verifies the pre-condition6 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_19 //and Comp_2, see if it is out of range10 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 base12 semantics of queryComponent with Component :13 //…the semantics of the query for pre-conditions14 semantics of minimum with Component1 and Component2 : 15 //…the semantics of the component composition16 semantics of queryPattern with Double :17 //…the semantics of the query for post-conditions18 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 alternatives3 //…other parameter definition4 semantics of ProductLine_1 with Component1 : //semantics for Comp_3 OR Comp_45 Query_1 := semantics of queryComponent with Component1;//verify the pre-condition6 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 addition13 //…semantics of queryPattern, UpDateFact and UpdatePattern are ignored here.end class

Proposed Solution (7/7)

Security

Goal(C

1,C2,C

3,C4,C

5) = infeasible

Goal(C

1,C2,C

4,C5,C

7) = infeasible

Goal(C

1,C2,C

3,C5,C

6) = 0.36

Goal(C

1,C2,C

4,C5,C

6,C3,C

7) = infeasible

Battery Life

Goal(C

2,C6,C

1,C4) = infeasible

Goal(C

1,C2,C

4,C7,C

6) = infeasible

Goal(C

1,C3,C

4,C2,C

5) = infeasible

Goal(C

2,C5,C

6,C3,C

7) = 0.35

Goal(C

2,C5) = 0.225

Signal

Goal(C

1,C2,C

5,C4,C

7,C6) = 0.34

Goal(C

1,C2,C

4,C3,C

6) = infeasible

Goal(C

1,C2,C

4,C3,C

5,C7) = infeasible

Goal(C

1,C2,C

3,C6,C

7) = infeasible

Time

Goal(C

2,C6,C

1,C4) = infeasible

Goal(C

2,C5) = 0.66

Goal(C

2,C5,C

6,C3,C

7) = 0.35

Goal(C

1,C3,C

4,C2,C

5) = infeasible

Goal(C

1,C2,C

4,C7,C

6) = infeasible

CP

U

Usage

Goal(C

2,C6,C

1,C4) = infeasible

Goal(C

2,C5) = infeasible (<66%

)

Goal(C

2,C5,C

6,C3,C

7) = 0.256

Goal(C

1,C3,C

4,C2,C

5) = infeasible

Goal(C

1,C2,C

4,C7,C

6) = infeasible

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

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

Questions?