Department of Computer ScienceUniversity of Southern California
Los Angeles, CA, USA
George [email protected]
Nenad [email protected]
1. Background2. Research Challenges
1. Metamodel Integration
2. Model Transformation
3. Solution Approach1. Abstract Component Technology
2. Model Interpreter Frameworks
4. Evaluation
5. Conclusions
Expertise about the environment in which the target system operates
Leveraged by codifying and reusing patterns, abstractions, and theories
Reference architectures define design patternsMiddleware platforms provide implementation abstractionsAnalysis technologies apply computational theories to system models
Domain-specific development infrastructures (DSDIs) combine all these elements
Domain-knowledge is leveraged in an ad-hoc fashion
No explicit codification of high-quality solutions
Domain-specific tools built on an as-needed basis
Throw-away tools built for a specific project
Different tools used to create design and analysis models
Design changes must be coordinated and synchronized
procedure Chunker.NextChunk(this: ref where $IsNotNull(this, Chunker)) returns ($result: ref where $IsNotNull($result, System.String));
// in-parameter: target object free requires $Heap[this, $allocated]; requires ($Heap[this, $ownerFrame] == $PeerGroupPlaceholder
|| !($Heap[$Heap[this, $ownerRef], $inv] <: $Heap[this, $ownerFrame]) || $Heap[$Heap[this, $ownerRef], $localinv] == $BaseClass($Heap[this, $ownerFrame])) && (forall $pc: ref :: $pc != null && $Heap[$pc, $allocated] && $Heap[$pc, $ownerRef] == $Heap[this, $ownerRef] && $Heap[$pc, $ownerFrame] == $Heap[this, $ownerFrame] ==> $Heap[$pc, $inv] == $typeof($pc) && $Heap[$pc, $localinv]
// out-parameter: return value free ensures $Heap[$result, $allocated];
Automated
Analysis of
Designs
Quality Analysis
AutomatedSynthesis of
Implementations
Middleware Platforms
Architecture and Design
SystemModels
AutomatedEnforcement of
Constraints
Metamodels capture domain conceptsSpecify domain-specific modeling languages
Model interpreters implement transformations
Perform analysis and synthesis
Creation of DSDIs requires composition of metamodels
Reference architecture roles, patterns, and configurations
Middleware type systems and services
Analysis formalisms and parameters
Lack of semantic definition within metamodels leads to accidental complexity
Onerous manual composition of metamodels
Lack of rigorous and automated validation mechanisms
Imprecise and ambiguous modeling constructs
Creation of DSDIs requires implementing model transformations
Generation of platform-specific code and configuration files
Translation into languages used by analysis tools
Lack of semantic definition within metamodels leads to accidental complexity
High design and implementation complexity
Redundant development effort
Disproportionate maintenance and evolution costs
Utilize an abstract component technology (ACT) to define domain-specific architectural modeling languages
An ACT is a metamodeling language specialized for software architectures
Associates domain-independent semantics with canonical architectural constructs
Can be easily extended to define platform- and domain-specific language constructs
Extend a model interpreter framework (MIF) to implement architectural analyses
A MIF is an infrastructure for automated construction of analysis models from domain-specific architectures
Leverages the commonality among domain-specific architectural modeling languages
Provides extension mechanisms to accommodate domain-specific analysis and platform-specific synthesis
Enables a family of analytic techniques to be applied to a component model
A modeling environment and accompanying set of analysis frameworks for software architectures
Example extensions targeted towards resource-constrained and mobile computing environments
Consists of:An abstract component technology
A suite of ACT extensions for analysis and synthesis
A suite of model interpreter frameworks
A suite of MIF extensions for analysis and synthesis
Provides the extensibility to easily accommodate both new modeling language features and new architectural analyses
Architecture: a collection of components and connectors that have been instantiated in a specific topology or configuration
Component: a locus of computation; interacts with other components and connectors via interfaces
Connector: implements communication and coordination facilities; interact with external entities via interfaces
Group: a logical grouping of components and connectors; specifies membership in a set with domain-specific semantics
Link: a logical connection between interfaces over which information and/or control is exchanged.
Interface: an interaction point between entities; defines data exchange and transfer of control
Datum: an object exchanged between components and connectors
Architecture
Group
Link
Datum
Interface
ConnectorComponent
Provide the basis for analysis and synthesis in XTEAMA MIF is a reusable design structure for constructing a family of model interpreters
Implements a semantic mapping between a domain-independent component model and analysis models or implementation artifacts
Abstracts the details of domain-independent interpretation
Produces an representation useful in a wide variety of contexts
Provides extension mechanisms to accommodate domain-specific analysis
Based on object-oriented (OO) design patterns like Template Method, Strategy, and Functor
Enables a family of analytic techniques to be applied to a component model
Traverse the model
Traverse the model
Interpret each object based on type and context
Interpret each object based on type and context
Apply domain-specific semantics at each extension point
Apply domain-specific semantics at each extension point
Invoke the architect-defined framework extension at each extension point
Invoke the architect-defined framework extension at each extension point
Implements a mapping from the XTEAM ACT to a discrete event simulation (DEVS) model
Employs the Strategy pattern to implement domain-specific extensions
Each Concrete Strategy generates code to realize a particular analysis
Invoked at specific times during the interpretation process
Generated code calculates and records analysis results
Synthesizes system implementations from architectural models
Component logic and “glue code” in C++
Middleware configuration files
Employs the Template Method pattern to generate application-specific extensions to the middleware
17
DEVS (analysis) Model Interpreter Framework
Prism-MW (synthesis) Model Interpreter Framework
Lack of automated mechanisms for composing metamodels and applying model transformations
Our methodologyImproves support for automated metamodel composition and model transformationIntegrates and leverages semantics at both the metamodeling tier and the interpreter tier
Bosch Research and Technology Center
The Boeing Company/Future Combat Systems
USC Annenberg Graduate Fellows Program
National Science Foundation
Visit the XTEAM website:
http://www-scf.usc.edu/~gedwards/xteam.html
1. George Edwards and Nenad Medvidovic, A Methodology and Framework for Creating Domain-Specific Development Infrastructures, Proceedings of the 23rd IEEE ACM International Conference on Automated Software Engineering (ASE), September 2008.
2. George Edwards, Chiyoung Seo, and Nenad Medvidovic, Model Interpreter Frameworks: A Foundation for the Analysis of Domain-Specific Software Architectures, Journal of Universal Computer Science (JUCS), Special Issue on Software Components, Architectures and Reuse, 2008.
3. George Edwards, Chiyoung Seo, and Nenad Medvidovic, Construction of Analytic Frameworks for Component-Based Architectures, Proceedings of the Brazilian Symposium on Software Components, Architectures and Reuse (SBCARS), August 2007.
4. George Edwards, Sam Malek, and Nenad Medvidovic, Scenario-Driven Dynamic Analysis of Distributed Architectures, Proceedings of the 10th International Conference on Fundamental Approaches to Software Engineering (FASE), March 2007.
Architecture and design modeling languages capture essential properties of software systems, such as structure, behavior, interaction, and data
Examples: UML, xADL
Reference architectures define generalized software designs that can be customized, parameterized, and specialized within a certain context
Examples: Bold Stroke, MIDAS
Component technologies provide the basis for implementation and deployment of software architectures
A component model defines the well-formedness of component instances/assembliesDevelopment platform and run-time environment enforce the component model
Examples include:Java EECORBA Component Model.NET FrameworkOSGi Service Platform
Quality attributes are system properties that describe how services are performed
Also called non-functional or quality-of-service properties
Evaluation of quality attributes is critical in meeting overall end-user operational goals
Modification of a system that does not meet quality attribute requirements is difficult and expensive
Overall goal:Quantitatively and objectively evaluate quality attributes during system design to arrive at a better overall system
1. A model interpreter must be constructed for each analysis or target platform
2. Model interpreters are dependent on a particular DSML, so they must be rebuilt for each new DSML
Requires system architects and developers to become tool developers – rather than merely tool users – to achieve integrated analysisOrganizations want to develop with third-party, commercially-supported tools to reduce risk and cost
3. Constructing and maintaining DSMLs and interpreters is difficult and complex
Little guidance exists on how to construct DSMLs and interpretersRequires particular type of expertise
Model Interpreter Implementation Tasks
1. Find a computational theory that derives the relevant properties
2. Determine the syntax and semantics of theanalysis modeling constructs
3. Discover the semantic relationships betweenthe constructs present in the architecturalmodels and those present in the analysismodels
4. Determine the compatibility between theassumptions and constraints of the architecturalmodels and the analysis models, and resolveconflicts
5. Implement a model interpreter that executes asequence of operations to transform anarchitectural model into an analysis model
6. Verify the correctness of the transformation
Lack of semantic definition leads to accidental complexity
Onerous manual composition of metamodelsLack of rigorous and automated validation mechanisms
Imprecise and ambiguous modeling constructs
High design and implementation complexityDisproportionate maintenance and evolution costsRedundant development effort
Create a methodology for applying analysis and synthesis tools to domain-specific architectural models that:1. Avoids the difficult task of inventing domain-
specific languages from scratch
2. Eliminates redundant effort in interpreter implementation
3. Allows effective reuse of model interpreters across domain-specific languages
4. Provides a structured process for model interpreter development
5. Simplifies the maintenance and evolution of model interpreters
30
An ACT is a metamodeling language (metalanguage) that specifically targets modeling languages for software architecturesAssociates semantics with metamodel constructs (metatypes)
Defines metatypes that correspond to the fundamental concepts in software architecture
Defined in terms of capabilities, constraints, and properties that remain valid across domains/platformsProperties that vary from one platform to another are undefined
Used to model the capabilities, constraints, and properties of architectural elements in a particular domain or platformModel parameters that are required by a domain-specific analysis technique
Platform-specific constructs that reflect the implementation facilities provided by a middleware
adevsSimulation
Engine
XTEAM ModelInterpreterFramework
GME MetamodelingEnvironment
GMEMetamodeling
Paradigm
XTEAM employs a MDE environment, the Generic Modeling Environment (GME)
XTEAM defines an ACT by composing existing general-purpose ADLs: xADL Core and FSP
GME configures a domain-specific modeling environment with the XTEAM ACT
XTEAM implements model interpreter frameworks
The XTEAM ACT is enhanced to capture domain-specific information
Architecture models that conform to the XTEAM ACT are created
An XTEAM MIF is utilized to generate analysis models
Analysis models are input to an analysis engine
The analysis engine operates on the information captured in ACT extensions to derive quality attributes GME Domain-Specific
Modeling Environment
XTEAM ACT
ApplicationArchitectures
EnergyConsumption
Analysis
End-to-endLatencyAnalysis
MemoryUsage
Analysis
Scenario-driven
AnalysisResults
XTEAM ACTMetamodel
XTEAMArchitecture
Models
XTEAMSimulationGenerators
Application Simulations
32
System models are reactiveActions are performed in response to stimuli
Parallel computation is distributed i.e., not centralized
The state of each process is private
Interaction occurs via asynchronous, typed message passing
A buffer exists between processes
Process behavior may be non-deterministic
Composite structures are defined by the parallel composition of processes
Analysis Type TargetModel
ModelingExtensions
Framework Extensions
Scenario-Driven Dynamic Analysis
Discrete Event Simulation Model
Latency (tasks, resources)
Layered queuing network-based performance model
Reliability (failures, probability of recoveries)
R. Roshandel et. al, software component reliability model
Energy Consumption (hardware characteristics, interface profiles)
C. Seo et. al, energy consumption estimation model
Memory Usage (memory usages)
Ad-hoc memory usage model
Model-Checking Static Analysis
Finite State Model Safety (unsafe conditions)
Safety properties
Liveness (locks/mutually exclusive resources)
Lock/resource acquisition and release
Security (unsecured channels, encryption)
Malicious actors
System Synthesis Prism-MW Code Resource Allocation
Resource pools, on-demand allocation
Network Configuration
Controller Area Network (CAN)
Implements the energy cost estimation model of C. Seo, et al.1
A computational energy cost is incurred when a component’s interfaces are invoked
Interfaces are classified and parameterized according to energy consumption profile
A communication energy cost is incurred when data is transmitted over a wireless network
Depends on data size, network bandwidth, etc.
1. Chiyoung Seo, et al., An Energy Consumption Framework for Distributed Java-Based Systems, ASE 2007.
35
Implements the layered queuing network performance model of Woodside.1
Concurrent processes are modeled as tasks with specified resource requirements
Accept requests from a single queueHas one or more identical worker threadsExecutes one or more classes of service
1. M. Woodside, Tutorial Introduction to Layered Modeling of Software Performance.
36
Implements the reliability estimation model of L. Cheung, et al.1
Represents component behavior with a Markov modelThe probabilities of a failure occurring in each state is determinedAnalytical solving of the model determines the percent of time spent in a failure state
1. L. Cheung, et al., Early Prediction of Software Component Reliability, ICSE 2008.
37
Individual component implementations may become available in a piecemeal fashion
XTEAM allows architects to1. Immediately incorporate
component implementations into a simulated system, increasing the accuracy of analysis results
2. Rapidly test individual components in the context of a wide variety of operational scenarios
Model confidence level: High
Componentimplementation
available
Invoke implementation from behavior model
Integrated simulation and test environment
38
Architects rely on intuition and experience to make important decisions early in the design phase
What architectural style to use
How to allocate functionality among subsystems
What types of connectors to use
XTEAM allows architects to rationalize such decisions with experimental evidence
Model confidence level: Low
Peer-to-peerArchitecture
Client-Server Architecture
PotentialWorkload
0
500
1000
1500
2000
2500
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
Resp
on
se T
ime (m
s)
Invocation
Request File Response Time
Nearly all architectural decisions come down to trade-offs between multiple desirable properties
Emphasis on one system property may yield diminishing returns
XTEAM allows architects to evaluate design alternatives in terms of their impact on multiple non-functional properties
Model confidence level: MediumReplication of components
Decreases response time
Consumes more battery power
0
500
1000
1500
2000
2500
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
Resp
on
se T
ime (m
s)
Invocation
Request File Response Time
S…
22000
22500
23000
23500
24000
0 58944 104612 175249 239514 287914 352870 415963 480308 529223
Rem
ain
ing
En
erg
y (m
J)
Time (ms)
Host A (iPAQ) Battery Power
40
Contemporary large-scale distributed systems contain numerous off-the-shelf components
Detailed information about the behaviors and properties of individual components may be knownComponent assemblies may exhibit unforeseen behavior due to subtle interactions between constituent components
XTEAM allows an architect to determine the emergent properties of a composed system
Model confidence level: High
Off-the-shelf components Highly accurate parameterizationDetermination of
emergent properties
41