Department of Computer Science University of Southern California Los Angeles, CA, USA George Edwards [email protected] Nenad Medvidovic [email protected].

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