Automated Analysis and Code Generation for Domain-Specific Models George Edwards Center for Systems and Software Engineering University of Southern California

Presentation Outline Background: Domain-Specific Languages and Model-Driven Engineering Research Challenge: Code Generation and Analysis Using Domain-Specific Models Promising Solution: Model Interpreter Frameworks XTEAM: Extensible Toolchain for Evaluation of Architectural Models

Domain-Specific Languages Software and systems modeling languages that are customized for a particular context Concisely and intuitively express the essential features of system designs – No missing or extraneous features – Capture common, reusable patterns – Enforce of architectural constraints – Use symbols and names native to the domain Easily modified, evolved, and composed

DSL Examples Specialized types, attributes, and relationships Constraints on how types may be used Customized symbols and multiple model views

DSL Specification

Common DSL Uses Architecture DSLs Architectural styles Reference architectures Product line architectures Platform DSLs Middleware configuration Deployment descriptors Code generation for application frameworks Analysis DSLs Simulation Model checking Quantification of quality properities

Why Use DSLs? Heterogeneity of platforms and technologies – Examples: multiple types of networks, data models, middleware – Result: A “one-size-fits-all” modeling language doesn’t fit Close and continual interaction with external systems, such as electrical and mechanical systems – Examples: embedded systems, space ground systems – Result: models need to capture interfaces to external systems Strict operating requirements – Examples: real-time data processing, robust fault-tolerance – Result: models need to be analyzable, executable

Model-Driven Engineering Model-driven engineering (MDE) combines domain-specific languages (DSLs) with model interpreters – Metamodels define elements, relationships, views, and constraints – Model interpreters leverage domain-specific models for analysis, generation, and transformation 8

Challenge: Constructing Interpreters 1.Designing, developing, and maintaining DSLs and interpreters is difficult and expensive – A model interpreter must be constructed for each analysis that will be applied to a model – Reusing model interpreters for different DSLs is hard – Little guidance exists on how to construct DSLs and interpreters – The semantics applied to models are opaque (embedded in code) – Requires particular types of expertise – Common topic of research papers in the modeling community 9 Model Interpreter Implementation Tasks 1.Find a computational theory that derives the relevant properties 2.Discover the semantic relationships between the constructs present in the architectural models and those present in the analysis models 3.Determine the compatibility between the assumptions and constraints of the architectural models and the analysis models, and resolve conflicts 4.Implement a model interpreter that executes a sequence of operations to transform an architectural model into an analysis model 5.Verify the correctness of the transformation

Simplifying Insight Automatically synthesize domain-specific model interpreters the same way that domain-specific model editors are synthesized

Solution: Model Interpreter Frameworks Use a model interpreter framework to implement domain-specific analysis – Implements a mapping from metamodel types to target platform types – Configured via plug-ins generated from a metamodel

The eXtensible Toolsuite for Evaluation of Architectural Models A MDE platform for software architectures Includes: – A specialized metamodeling language and metamodel editor – Two metamodel interpreters with paired model interpreter frameworks (model editor and simulation generator) – Example metamodels and framework extensions Provides the extensibility to easily accommodate both new modeling language features and new architectural analyses

XTEAM Usage Providing design rationale Weighing architectural trade-offs Discovering emergent behavior of component assemblies Generating test cases and validating component implementations

XTEAM Simulation Generator

XTEAM Benefits Reduced implementation effort – Effort saved through code generation and reuse – Quantified by: Lines of generated interpreter code Total lines of reused interpreter code Lines of generated code per domain-specific type Lines of reused code per domain-specific type Reduced maintenance effort – Due to relative ease of performing DSL modifications within a metamodel rather than within model interpreter source code – Quantified by number of metamodel objects altered vs. number of classes, methods, and SLOC altered

Implementation Effort Metrics COCOMO Estimates: Nominal settings  23.4 person-months Favorable settings  4.2 person-months

Maintenance Effort Metrics

Summary Building model interpreters to analyze and generate code from domain-specific models is hard Our methodology leverages a metamodel and extensible interpreter frameworks to automatically synthesize domain-specific model analysis tools and code generators

For More Information Visit the XTEAM website: XTEAM Publications: 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 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, 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 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.

Thanks for your attention