XTEAM: Architecture-Based Modeling and Analysis Tools

with Metamodeling

Nenad Medvidovicneno@usc.edu

George Edwardsgedwards@usc.edu

george@bluecellsoftware.com

Computer Science DepartmentUniversity of Southern California

Blue Cell SoftwareLos Angeles, CA

XTEAM Project

• Processes, notations, tools, and designs that enable

automated synthesis of domain-specific

toolsets for architecture modeling, analysis, and

code generation

• Example application areas:

– Embedded and real-time systems

– Safety- and mission-critical systems

– Cloud and grid systems

XTEAM Capabilities

• Metamodeling

Domain-specific language definition

• Architecture modeling

System design and requirements

definition

• System simulation and

code generation

Design and requirements analysis

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];

XTEAM Collaboration

• Real-time

distribution of

model updates

• Automatic checks

for consistency

• Conflict notification

and resolution

XTEAM Use Cases• Providing design rationale

and feasibility evidence

• Weighing architectural trade-

offs

• Discovering emergent

behavior of component

assemblies

• Testing component

implementation prototypes

5

Domain-Specific Languages (DSLs)

• Customized for a particular

family of problems

(the domain)

• Concise and intuitive

– No missing or extra features

– Capture patterns

– Enforce constraints

– Use native symbols and terms

• Can be modified, evolved, and

composed

Model-Based Systems Engineering using DSLs

• DSLs for requirements and architecture modeling and analysis

– Metamodels define DSL syntax

– Model interpreters define DSL semantics

• COTS tools provide only partial support for DSLs

– Metamodel editor with built-in metamodeling language

– Metamodel interpreter that configures metaprogrammable model

editor

Metamodel Editor

Metaprogrammable Model Editor

Model Execution

Environment (Semantic Domain)

MetamodelInterpreter

ModelInterpreter

Off-the-shelf

Auto generated

Built by engineer

Domain-Specific Model

Domain-Specific Model

Domain-Specific ModelMetamodel

Metamodeling Language

Domain-Specific Language

Executable Model

Executable Model

Executable Model

“The difficulty of building and maintaining a DSM solutionstems essentially from the complexity of the mapping between the concept instances expressed in the DSML and the code that has to be generated.”

A. L. Santos et al. Automating the Construction of Domain-Specific Modeling Languages for Object-Oriented Frameworks. Journal of Software and Systems, 2010.

Problems with MBSE using DSLs• Building and maintaining

code generators for DSLs

is inherently difficult

– High design complexity

– Disproportionate

maintenance and evolution

costs

– Hard to verify correctness

– Redundant development

effort

– Opaque semantics

embedded in source code

“There is a fundamental problemin keeping the model interpreters up to date with metamodel changes ... Current practice requires each model interpreter to be modified manually after each metamodel schema change. This can be a very time-consuming and error prone task for complex model interpreters of considerable size.”

Jing Zhang. Metamodel-Driven Model Interpreter Evolution. Conference on Object Oriented Programming Systems Languages and Applications, 2005.

“Checking mathematicalproperties like correctness or completeness of transformations based on common programminglanguages is very difficult...”

I. Malavolta, H. Muccini, P. Pelliccione, and D. Tamburri. Providing Architectural Languages and Tools Interoperability through Model Transformation Technologies. IEEE Transactions on Software Engineering, 2009.

“The state-of-the-art of modelinterpreter writing needs to be advanced to enhance thereusability and maintainability of this software...”

G. Karsai. Structured Specification of Model Interpreters. Engineering of Computer-Based Systems, 1999.

“Writing translators by hand...in addition to being inefficient, has yet another serious drawback: the semantic mapping between the input and the output is vaguely specified...[Building model interpreters] is the most time consuming and error prone phase of the MIC approach...”

G. Karsai, A. Agrawal, F. Shi, J. Sprinkle. On the Use of Graph Transformation in the Formal Specification of Model Interpreters. Journal of Universal Computer Science, 2003.

FCS: A Real World Example• DSL with hundreds of types

– Modified on a daily basis

• Automated generation of:

– Discrete event simulations

– Middleware configuration files

– Fault trees

– Spreadsheets for documentation

Tool building and maintenance required approximately five full-time MDE experts

Synthesize domain-specific code generators

using the same mechanisms that have proven

successful for synthesizing domain-specific model

editors.

XTEAM Solution Approach

Metamodel Editor

Metamodel

Metamodel Interpreter

A

Model Editor Framework

Metamodel Interpreter

B

Code Generator Framework

Target Platform

Presentation Semantics

Platform Semantics

Application Model(Abstract

Representation) Executable

Code

Types and Views

Presentation Properties

Platform Properties

Presentation Logic

Presentation Rules

Code Generation Logic

Code Generation Rules

Target Display

Visualized Model

Selected Applications of XTEAM• MIDAS: wireless sensor network (WSN) applications for

building monitoring and control

• RoboPrism: analysis, implementation, deployment, and

monitoring framework for mobile robotics systems

• SASSY: automated run-time generation of service-oriented

architectures

• RESIST: dynamic reliability estimation and proactive

adaptation in situated software systems

• FUSION: self-tuning self-adaptive software systems

• PATFrame: predictive tools for UAS T&E

Proposed Next Step: Model Checking

• Used to verify requirements and design– Safety, security, and other properties

– Successfully used in real-time and embedded systems

Existing model checkers do not provide metamodeling

Answer

Yes (if model satisfies rqmts)

Counter-example (if model does not satisfy rqmts)

• Well-known tools: SPIN/dSPIN, SMV, Java Pathfinder/JPF

Model Checking

Application Model

System Requirement

s

Planned Research Approach

• Refine the XTEAM

metamodeling language

– Include sufficient semantic

information for mapping to

model checking input

• Implement

metaprogrammable model

checker

– Metamodel interpreter

– Model interpreter framework

Define Metatypes

Develop Components

Define/refine core architectural

metatypes

Embed semantic assumptions in

metatypes

Attach semantic properties to

metatypes

Implement model interpreter framework

Implement metamodel interpreter

Semantic Definitions• Embedded semantic assumptions

– Independent of the metamodel

– Capabilities

• Behaviors that metatypes exhibit by default

– Responsibilities

• Information required to map metatypes to the semantic

domain• Semantic

properties

– Capture semantic

variability among

metamodels

– Values map to a

semantic configuration

Outcome and Benefits

• End product: MBSE toolset with model

checking and metamodeling capabilities– DSLs: customizable, concise, intuitive modeling

– Model checking: formal verification of requirements and

design

– No model interpreter development

• Generally 4 person-months to 24 person-months of effort

– Predictable cost and timeline for tool development

• Less risk than a conventional DSL tool chain

Conclusions

• Ready-to-use tool exists today

– Metamodeling and DSL definition

– Architecture modeling

– Discrete event simulation

• Future plans

– Model checking

– Enhanced real-time collaboration

– Automated composition of metamodels

Additional Information• XTEAM Website:

http://softarch.usc.edu/~gedwards/xteam.html

• Papers:– George Edwards and Nenad Medvidovic, Model Interpreter Frameworks, Technical Report USC-CSSE-

2009-514, Center for Software and Systems Engineering, Univ. of Southern California, July 2009.

– George Edwards and Nenad Medvidovic, A Highly Extensible Simulation Framework for Domain-

Specific Architectures, Technical Report USC-CSSE-2009-511, Center for Software and Systems

Engineering, University of Southern California, May 2009.

– 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.

– 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.

– 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.

– 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.