1 / 20

Automated Analysis and Code Generation for Domain-Specific Models

Automated Analysis and Code Generation for Domain-Specific Models. George Edwards Center for Systems and Software Engineering University of Southern California gedwards@usc.edu. Presentation Outline. Background: Domain-Specific Languages and Model-Driven Engineering

baris
Télécharger la présentation

Automated Analysis and Code Generation for Domain-Specific Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Automated Analysis and Code Generation for Domain-Specific Models George Edwards Center for Systems and Software Engineering University of Southern California gedwards@usc.edu

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

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

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

  5. DSL Specification

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

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

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

  9. Challenge: Constructing Interpreters Model Interpreter Implementation Tasks Find a computational theory that derives the relevant properties Discover the semantic relationships betweenthe constructs present in the architecturalmodels and those present in the analysismodels Determine the compatibility between theassumptions and constraints of the architecturalmodels and the analysis models, and resolveconflicts Implement a model interpreter that executes asequence of operations to transform anarchitectural model into an analysis model Verify the correctness of the transformation • 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

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

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

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

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

  14. XTEAM Simulation Generator

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

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

  17. Maintenance Effort Metrics

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

  19. For More Information Visit the XTEAM website: http://www-scf.usc.edu/~gedwards/xteam.html 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 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.

  20. Thanks for your attention

More Related