1. XTEAM: Automated Synthesis of Domain-Specific Code Generators George Edwards gedwards@usc.edu Introduction to the Center for Systems and Software Engineering

2. Brief Introduction to CSSE Established in 1993 as CSE –Merged in 2006 with SAE to form CSSE Focus on research and teaching –MSCS with emphasis in SE –Graduate Certificate in SAE –Two Certificate and Advanced Degree programs Objective is to solve scientific problems with industrial relevance

3. CSSE Affiliates 22 industrial affiliates –8 from aerospace industry –12 from other industries –2 international 12 government affiliates –6 government agencies incl. US Army TACOM and Research Labs –6 FFRDCs and consortia 7 academic affiliates –5 universities –2 research centers 3 visiting associates

4. Research Focus Areas Architecture Economics Process Testing & analysis

5. Software Architecture Research Modeling Analysis Implementation Deployment Dynamic adaptation Architectural styles Software connectors Architectural recovery

6. XTEAM Project Overview Processes, notations, tools, and designs that enable automated synthesis of end-to-end domain-specific toolsets for software architecture modeling, analysis, and code generation Example application areas: –Systems-of-systems and ultra-large-scale systems –Safety- and mission-critical systems –Cloud and grid systems

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

8. Model-Driven Engineering (MDE) MDE leverages DSLs for architecture modeling –Metamodels define DSL syntax (types, properties, views, and constraints) –Model interpreters define DSL semantics (analysis, code generation, etc.) MDE platforms provide (some) tool support –Metamodel editor with built-in metamodeling language –Metamodel interpreter that configures a metaprogrammable model editor Metamodel Editor Metaprogrammable Model Editor Model Execution Environment (Semantic Domain) Metamodel Interpreter Model Interpreter Off-the- shelf Auto generated Built by engineer Domain-Specific Model Metamodel Metamodeling Language Domain-Specific Language Executable Model 8

9. “The difficulty of building and maintaining a DSM solution stems 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 MDE 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 problem in 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 mathematical properties like correctness or completeness of transformations based on common programming languages 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 model interpreter writing needs to be advanced to enhance the reusability 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.

10. FCS: A Real World Example > $100 billion US Army program 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

11. 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 Model Interpreter Framework Target Platform Application Model (Abstract Representation) Application Model (Abstract Representation) Executable Model Executable Model Target Display Visualized Model

12. XTEAM Toolset 12 Windows/C++/Visual Studio Fedora Linux SVN Repository JVM Prism-MW Lightweight Architectural Middleware XDEVS Discrete Event Simulation Engine GME Model Editor GME Model Editor XTEAM Metalanguage MS COM XDEVS Metainterpreter Prism-MW Metainterpreter GME Metainterpreter XDEVS MIF Prism-MW MIF Prism-MW Applications (Java) Prism-MW MIF Extensions C++ XDEVS MIF Extensions XDEVS Simulations (C++) MS COM XTEAM Models (XML/HTTP) XTEAM Metamodels (XML/HTTP) Off-the-Shelf Component XTEAM Component Connector Languages and Platforms XTEAM DSLs

13. XTEAM Simulations Providing design rationale Weighing architectural trade-offs Discovering emergent behavior of component assemblies Validating component implementations 13

14. Providing Design Rationale 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-peer Architecture Client-Server Architecture Potential Workload

15. Weighing Architectural Trade-offs 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: Medium Replication of components Decreases response time Consumes more battery power

16. Evaluating Component Assemblies Contemporary large-scale distributed systems contain numerous off-the- shelf components –Detailed information about the behaviors and properties of individual components may be known –Component 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 componentsHighly accurate parameterization Determination of emergent properties

17. Incremental System Validation Individual component implementations may become available in a piecemeal fashion XTEAM allows architects to 1.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 Component implementation available Invoke implementation from behavior model Integrated simulation and test environment

18. For More Information CSSE Website: http://csse.usc.edu/csse/ XTEAM Website: http://www-scf.usc.edu/~gedwards/xteam.html