Transcript Model-Driven Engineering for Development

Model-Driven Engineering for Development-Time QoS
Validation of Component-based Software Systems
James Hill, Sumant Tambe & Aniruddha Gokhale
Vanderbilt University, Nashville, TN, USA
IEEE International Conference & Workshop on
Engineering of Computer Based Systems (ECBS 07)
March 26- 29, 2007
Tucson, AZ, USA
Motivation: Current Model-Driven Engineering Techniques
Many existing MDE techniques for largescaled component-based system focus
primarily on:
a) Structural issues
• Component representation (i.e.,
interfaces & attributes)
• Component assembly & packaging
• System deployment & configuration
b) Functional & operational issues
• Model checking (e.g., checking for
functional correctness)
• Runtime validation of performance
(e.g., running simulations at designtime, or empirical benchmarks at
integration time)
There remains a major gap in evaluating system quality of service (QoS) at
different phases of development to allow design flaws to be rectified earlier in
CBML & WML Presentation the development lifecycle.
James H. Hill
Serialized Phasing is Common in Large-scale Systems (1/2)
System
infrastructure
components
developed first
Level of Abstraction
Application components
developed after
infrastructure is mature
Development Timeline
CBML & WML Presentation
James H. Hill
Serialized Phasing is Common in Large-scale Systems (2/2)
Finished development
Level of Abstraction
System integration
& testing
Integration
Surprises!!!
Development Timeline
CBML & WML Presentation
James H. Hill
Complexities of Serialized Phasing
Level of Abstraction
Still in development
Ready for testing
Complexities
• System infrastructure cannot be
tested adequately until applications
are done
Development Timeline
CBML & WML Presentation
James H. Hill
Complexities of Serialized Phasing
Level of Abstraction
Overall performance?
Complexities
• System infrastructure cannot be
tested adequately until applications
are done
• Entire system must be deployed &
configured properly to meet QoS
requirements
• Existing evaluation tools do not
support “what if” evaluation
Development Timeline
It is hard
to address
these concerns in processes that use serialized
CBML
& WML
Presentation
James phasing
H. Hill
Promising Solution Approach: Emulate Behavior using
Next Generation System Execution Modeling Tools
Component Workload Emulator (CoWorkEr)
Utilization Test Suite (CUTS) Workflow
While target system under development:
1. Use a domain-specific modeling
language (DSML) to define & validate
infrastructure specifications &
requirements
2. Use DSML to define & validate
application specifications &
requirements
3. Use middleware & MDD tools
generate D&C metadata so system
conforms to its specifications &
requirements
4. Use analysis tools to evaluate &
verify QoS performance
5. Redefine system D&C & repeat
Validate
Design
Conformance
Validate
Design
Rules
Conduct
“What If”
Analysis
Enables testing on target infrastructure throughout the development lifecycle
http://www.dre.vanderbilt.edu/~hillj/docs/publications/CUTS-RTCSA06.pdf
CBML
& WML Presentation
James H. Hill
Case Study: Distributed Stock Application (DSA) (1/2)
Usage Patterns by User Type
Implementation Details
Type
Percentage
Response Time (msec)
Basic (Client A)
65%
300
Gold (Client B)
35%
150
• All components are to implemented as CORBA Component Model (CCM)
components using ACE+TAO+CIAO 5.1 middleware
• Target architectures includes 3 separate hosts running Fedora Core 4.
• Each component in the DSA is schedule to complete is development at
different times in development lifecycle
CBML & WML Presentation
James H. Hill
Case Study: Distributed Stock Application (2/2)
Replaceable with
“real” component
Microsoft .NET
Realistic user behavior
Challenges of Continuous QoS Validation
CCM
Realistic behavior
& workload
1. Emulating Business Logic: Emulated components must resemble their
counterparts in both supported interfaces & behavior
2. Realistic Mapping of Emulated Behavior: Behavior specification should
operate at a high-level of abstraction & map to realistic operations
3. Technology Independence: Behavior specification should not be tightly
coupled to a programming language, middleware platform, hardware
technology, or MDE tool
CBML & WML Presentation
James H. Hill
Domain-Specific Modeling Languages for Continuous
QoS Validation
Component Behavior Modeling Language (CBML)
• a high-level domain-specific modeling language for
capturing the behavior of components
– e.g., its actions & states
Workload Modeling Language (WML)
• a domain-specific modeling language
for capturing workload, & used to
parameterize the actions on CBML
CBML & WML were both developed using GME
(http://www.isis.vanderbilt.edu/projects/GME) James H. Hill
CBML & WML Presentation
The Component Behavior Modeling Language
Context
• Component’s behavior can be
classified as: communication & internal
actions
• Need to define these actions as close
as possible to their real counterpart
(i.e., Challenge 1)
Research Contributions of CBML
• Based on the semantics of
Input/Output (I/O) Automata
– i.e., contains representative
elements
• Behavior is specified using a series of
action to state transitions
• Transitions have preconditions that
represent guards & effects have
postconditions that determine the new
state after an action occurs
• Variables are used to store state & can
be used within pre & postconditions
CBML & WML Presentation
James H. Hill
Domain-Specific Extensions to CBML
Context
• Some aspects of componentbased systems are not first-class
entities in I/O automata
– e.g., lifecycle events &
monitoring notification events
• Extended CBML (without affecting
formal semantics) to support
domain-specific extensions
Domain-Specific Extensions environment
• Environment events – input
actions to a component that are
triggered by the hosting system
rather than another component
periodic
• Periodic events - input actions
from the hosting environment that
occur periodically
CBML & WML Presentation
James H. Hill
Ensuring Scalability of CBML
Context
• One of the main goals of higherlevel of abstraction is simplicity &
ease of use
• It is known that one of the main
drawbacks of automata languages
is scalability
Usability Extensions
• Composite Action – contains other
actions & helps reduce model
clutter
• Repetitions - determines how
many times to repeat an action to
prevent duplicate sequential
actions
• Log Action - an attribute of an
Action element that determines if
the action should be logged
Tool Specific – GME add-on that
auto-generates required elements
(e.g., states)
CBML & WML Presentation
James H. Hill
The Workload Modeling Language
Context
• CBML as a standalone language is
sufficient enough to capture
behavior of a component
• For emulation purposes, it does
not capture the reusable objects of
a component & its workload (i.e.,
Challenge 2)
Research Contributions of WML
• Middleware, hardware, platform, &
programming language
independent DSML
• Used to define workload
generators (workers) that contains
actions to represent realistic
operations
• Defined using a hierarchical
structure that resembles common
object-oriented programming
packaging techniques that are
consistent with conventional
component technologies
CBML & WML Presentation
generic action
no payload
executable actions
workload generator
James H. Hill
Integrating WML Models with CBML Models
Context
• CBML & WML are standalone
DSMLs with a distinct purpose
– i.e., model behavior & workload,
respectively
• WML is designed to complement
CBML by provide CBML with
reusable operations that can map to
realistic operations
Integration Enablers
• WML worker elements have
same model semantics as
variables
• WML actions have same
modeling semantics as CBML
actions
• Allows WML elements to be
used in CBML models
CBML
WML action
WML
CBML & WML Presentation
James H. Hill
Integrating Behavioral and Structural DSMLs
Context
• Structural DSML (e.g., the
Platform Independent Component
Modeling Language (PICML))
capture the makeup of
component-based systems
• There is no correlation between a
component’s ports & its behavior
Integration Enablers
• Defined a set of connector
elements that allow structural
DSMLs to integrate with (or
contain) CBML models
• Input ports directly connect to
Input Action elements
• Output actions have the same
name as their output port to
reduce model clutter
– i.e., prevent many to one
connections
CBML & WML Presentation
input connections
output name
James H. Hill
Code Generation for Emulation
Context
• The generation technique should
not be dependent on the underlying
technology
• Although we are targeting CUTS,
would should be able to generate
emulation code for any
benchmarking framework
Generation Enablers
• Emulation layer – represents the
application layer’s “business logic”
where elements in WML used to
parameterize CBML behavior are
mapped to this layer
• Template layer – acts as a bridge
between the upper emulation layer
& lower benchmarking layer to
allows each to evolve independently
of each other
• Benchmark layer – the actual
benchmarking framework (e.g.,
CUTS)
CBML & WML Presentation
component method
template /
benchmarking
emulation
James H. Hill
Concluding Remarks
• We described a MDE generative
approach to address the challenges
of evaluating component-based
system QoS throughout the
development lifecycle instead of
delaying it to integration time
• Our approach included two DSMLs,
namely CBML & WML, which allows
use to generate realistic applications
for emulation early in the
development lifecycle
• Our approach facilitates continuous
system integration – as real
components are completed, they
replace the emulated components
• Likewise, as more is learned about
the system, component’s behavior
can be refined & regenerated
Tools are available as open-source & can be downloaded from:
http://www.dre.vanderbilt.edu/CoSMIC & http://www.dre.vanderbilt.edu/CUTS
CBML & WML Presentation
James H. Hill
Questions
CBML & WML Presentation
James H. Hill