Semantic Variability Modeling
for Multi-staged Service Composition
Bardia Mohabbati1, Nima Kaviani2, Dragan Gašević3
1Simon Fraser University, 2University of British Columbia, 3Athabasca University, Canada
mohabbati@sfu.ca, nimak@ece.ubc.ca, dgaseavic@acm.org
SPLC – SOAPL 2009
Software Engineering Institute | Carnegie Mellon
SOAPL 2009
Bardia Mohabbati,
25 August 2009
Outline
• Objectives and Introduction
• Motivating Scenario
• Overview
•
•
•
•
•
Analysis and Design
Feature Model and Variability Modeling
Service Requirements Specification
Software Service Products Configuration
Service Discovery and Specialization
• Semantic Variability Modeling
• Feature Model Ontology
• Feature Model Annotation
• Feature Model Specialization
• Conclusion
9/23/2009
2
Objectives
 Adaptive development of software-intensive systems for mobile and
ubiquitous Computing
Pervasive/Ubiquitous computing (ubicomp) is about providing
services and computing capabilities in heterogeneous environments
Heterogeneous computing device
Resource constraints of deployment platform
 Utmost functionality and satisfying non-functionality requirements
(NFRs) in final product
 Service-Oriented Software Development and SPL
9/23/2009
3
Objectives
We exclusively focus variability coming from the different delivery
platform of service oriented architecture
Business Process Layer
Workflow
Variability
Alternative and
Optional Unit
Service
...
Business
Process
...
Unit
Service
Unit
Service
Unit
Service
Unit
Service
...
...
Service
Interface
Service
Interface
Service
Interface
Service
Interface
...
Service Component Layer
...
Logic
Variability
Changing part of
functionality of Unit Service
by adapting service
component
Business
Process
Service Interface Layer
Interface
Variability
Matching Unit Service
Interface and Web services
Interface published in UDDI
Business
Process
Unit Service Layer
Composition
Variability
Different Web services for
a unit services according
to NFR rather than FR
Business
Process
...
Component
Component
Component
Component
...
S. Ho Chang et al
4
Motivating Scenario
Airport Large Screen Display
Service Provider
Ubiquitous Information Service
Remote Service
(Web services)
…
Mobile Devices
9/23/2009
5
Overview
Design
Analysis
Domain Analysis
Product Family
Feature Extraction
Feature Model
Ontology
Representing Variability by
Feature Modeling
Feature Model
Annotation
Service Oriented Product Configuration
Feature Model
Specialization
Configuration
Validation
Software Service Product
Specialization
Soft
Constraint
User’s Requests and
Preferences
Annotated Feature
Model
Hard
Constraint
Device Specification
Device Ontology
Instantiation
Request
Specification
Service Adaptation
9/23/2009
6
Feature Model & Variability Modeling
Functional Requirements
•Core Services in the system
•Carry the objectives of the system
Non-functional Requirements
Replaceable or alterable services
Quality of Service (QoS) requirements
Security requirements
9/23/2009
7
Feature Model Ontology (FMO)
Semantic Feature Model
Ontology is defined as a formal specification of a conceptualization and
utilizes the representation of knowledge contained in feature models.
Semantic representation of features :


Relations and dependencies
feature constrains
[FM Mapping]
Transformation :
F2
F3
Using the Web Ontology Language (OWL)
Constructing mutual disjoint classes
9/23/2009
…
Fi ⊑ ⊤
FMiRule ⊑ ⊤
hasFi ⊑ ObjectProperty
FMiRule ≡ ∃ hasFi. Fi
Fi ⊑ ¬Fj , for i ≤ 1, j ≤ n ∧ i≠j
…
o
o
F1
Fn
Feature Model
Feature Model Ontology
8
Feature Model Annotation
Feature Model Ontology enables us to take advantages of ontology
annotation capabilities in order to enrich the definition of domain assets with
the constraints concerning the non-functional requirements of a domain
[FM Mapping]
F2
F3
`
…
…
F1
…
[FM Annotation]
Fn
Feature Model
Feature Model Ontology (FMO)
AN ⊑ ObjectProperty
AN ⊑FMm, domain(FMm)
⊤ ⊑∀ AN.DCn , range (DCn)
9/23/2009
Device Ontology(DCO)
hasBluetooth_AN ⊑ ObjectProperty
hasBluetooth_AN ⊑ Bluetooth,
domain(BluetoothRule)
⊤ ⊑∀ has Bluetooth_AN.BluetoothDevice,
9
Software Service Products Configuration
 Device Ontology model reflect device capability (NFRs)
 NFRs as Integrity Constraints (IC)- which include and exclude the selection of
services in annotated feature model
 Feature Model Specialization : Stage refinement process which constitute
staged configuration
 Specialization: The features don’t satisfy the NFRs of target deployment
platform are discarded and pruning feature model
 Ontology-based reasoning : consistency checking and verification
o If instances of NFRs ontology are consistent with respect to the annotation properties
defined in feature model
9/23/2009
10
Software Service Products Configuration
Design Time
1.
Creating the feature model
4.
Platform Deployment
Capability analysis
2.
Incorporating NFRs into
designing the feature model
5.
Feature selection
6.
Service composition
7.
Validation and Deployment
3.
9/23/2009
Run Time
Binding Services to the NFR
ontology
11
Software Service Products Configuration
Feature Model Specialization
FMO : Feature Model Ontology
DCO: Device Capability Ontology
K = (O, T, A, R)
T : set of concept axioms (TBox)
A : set of assertional axioms (Abox)
R : set of rules written as inclusion axioms
DEFINITION 1 Let d ∈ DCO be an instance of a device which has n capabilities. Each
capability for device d is an instance (ik) of a concept (Ck ) from DCO such that A⊨Ck(ik)
(1≤k≤n). Sdc = {C1,..,Cn}, represents the set of all concepts Ck from DCO that d supports.
DEFINITION 2 Let SAF
⊑ FMO be a set consisting of concepts CFi such that ∀CFi.⊤|
∃ANi ⊑ CFi ⊓ ∃ANi.Ck where Ck ∈ DCO.
9/23/2009
12
Software Service Products Configuration
Feature Model Specialization
ANj ⊑ ObjectProperty
n
SFA=
 CF
i
i 1
for each Ck ∈Sdc
for each CFi ∈ SAF
if (∃ANj.Cj ⊓ ANj ⊑ CFi and Cj ∈ DCO)
if (Cj ∈ Sdc)
if (A ⊭ CFi(ii) )
SFA ← SFA - {CFi(ii)}
else
SFA ← SFA - {CFi(ii)}
return (SFA)
ANj
DCO
9/23/2009
13
Feature Model Specialization
Model Verification
During the process of the configuration validation, model constraints are checked against
the derived configuration to provide proper assurance in terms of correct exclusion and
inclusion of optional and mandatory features.
OWL-DL reasoning engines: To support automated class subsumption, consistency
reasoning and detection of possible inconsistencies in the specialized feature.
Consistency and conflicts detection : Formulate and define a list of Semantic Web Rule
Language (SWRL ) rules to represent all invalid states
9/23/2009
14
Service Discovery and Specialization
The result of consistency checking in the previous step can be two folded :
 Inconsistent ontology
 Consistent ontology
Design Stage - family composition refinement
Service Specialization based on soft constraints
Deployment of the service-oriented system:
 Web Service Modeling Ontology framework (WSMO)
 Transformation feature model to WSMO service (with ATL transformation language)
 Web service Execution Environment (WSMX)
(the reference implementation for WSMO)
Design
Analysis
Feature
Model
Annotation
Feature
Model
Ontology
Representing
Variability by
Feature Modeling
Domain Analysis
Product Family
Feature Extraction
Service Oriented Product Configuration
Feature Model
Specialization
Configuration
Validation
Software Service
Product
Specialization
Soft
Constraint
User’s Requests
and
Preferences
9/23/2009
Annotated
Feature Model
Hard
Constraint
Device
Specification
Service Adaptation
Device
Ontology
Instantiation
Request
Specification
15
Conclusion
Ontologies as an underlying formalism for representation of feature models to
enrich Feature Model with semantics
Ontology-based approach for feature model annotation with NFRs ontologies
Inference and Ontological Reasoning Over Feature Model
validating (non-) functional requirements
 Semi-automatic Product configuration
 Product consistency check
9/23/2009
16
Thank you 
17