1. Creating Domain-Specific Development Infrastructures George Edwards gedwards@usc.edu Computer Science Department University of Southern California

2. Presentation Outline Background –Domain-Specific Software Engineering –Model-Driven Engineering Motivation and Challenges Solution Approach –Abstract Component Technology –Model Interpreter Frameworks The eXtensible Toolchain for Evaluation of Architectural Models (XTEAM) June 1, 20152

3. Domain-Specific Software Engineering Domain-specific software engineering (DSSE) leverages the characteristics of an application domain to create high-level design abstractions Captures domain knowledge to enable reuse of design solutions and implementation artifacts Includes: –Domain-specific reference architectures –Domain-specific middleware –Domain-specific analysis technologies –Domain-specific modeling June 1, 20153

4. Domain-Specific Reference Architectures Domain-specific reference architectures define generalized software designs that can be customized for a certain context Can be applied to a wide range of systems within a given domain Examples: –ADAGE avionics reference architecture –Sun Oracle 10g Grid Reference Architecture –MIDAS reference architecture for sensor network applications June 1, 20154

5. Domain-Specific Middleware Domain-specific middleware implements services that are tailored for the needs of a particular domain –Provides reusable implementations of recurring tasks and algorithms Developers avoid reinventing solutions to common problems within a domain –Improves system quality –Decreases development time and effort Examples: –Boeing Bold Stroke middleware for avionics –syngo platform for medical imaging –Prism-MW multilayered computing infrastructure for mobile and embedded applications June 1, 20155

6. Domain-Specific Analysis Technologies Domain-specific analysis technologies derive information about quality attributes that are of particular importance for a given domain 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 June 1, 20156 Overall goal: Quantitatively and objectively evaluate quality attributes during system design to arrive at a better overall system

7. Domain-Specific Modeling The key to effectively utilizing DSSE Allows architects to create more meaningful representations of software systems –Customized precisely for the needs of a particular project –Incorporates domain concepts as first-class modeling constructs –Allows more concise and intuitive expression of software designs Provides the basis for integration of domain-specific reference architectures, middleware, and analysis –Can capture: Patterns, roles, and views defined by a domain-specific reference architecture Facilities and services provided by a domain-specific middleware Parameters and constraints required by an analysis technology June 1, 20157

8. Domain-Specific Development Infrastructures A domain-specific development infrastructure (DSDI) is created through the integration of a domain-specific reference architecture, middleware, analysis technologies, and modeling languages Challenge: the high cost of DSDI development, maintenance, and evolution –Customized platforms and tools may intentionally avoid the use of common standards –The cost of infrastructure development is amortized over comparatively fewer projects –DSDIs encodes valuable intellectual property, such as architectures and algorithms Mandates that tool development and maintenance be done in-house Preventing tools from being marketed externally June 1, 20158

9. Model-Driven Engineering Model-driven engineering (MDE) combines domain-specific modeling languages (DSMLs) with model analyzers, transformers, and generators –Models are the central engineering artifacts throughout the engineering lifecycle –Model transformations allow a single system model to be used for a variety of purposes June 1, 20159 Metamodels define elements, relationships, views, and constraints Model interpreters leverage domain-specific models for analysis, generation, and transformation

10. Problems with MDE (1/2) Metamodels specify only the syntax of language elements, and provide no mechanism for capturing semantics –Disregards the useful commonality among families of DSMLs –The burden of defining semantics is placed solely on software architects The creation of metamodels is essentially unconstrained –Constructing and maintaining DSMLs is difficult and expensive Requires software architecture, metamodeling, and domain expertise Metamodeling experts are usually not domain experts, and vice versa –Provides architects with no guidelines for creating metamodels Increases the effort required to create DSMLs Potentially decreases DSML quality June 1, 201510

11. Problems with MDE (2/2) Lack of semantics prevents MDE tools from providing off-the- shelf analysis and synthesis capabilities –A model interpreter must be constructed for each analysis or synthesis that will be applied to a design model –Model interpreters are dependent on a particular DSML, so they must be rebuilt for each new DSML –Architects have no principled method for interpreter development 11June 1, 2015 Model Interpreter Implementation Tasks 1.Find a computational theory that derives the relevant properties 2.Determine the syntax and semantics of the analysis modeling constructs 3.Discover the semantic relationships between the constructs present in the architectural models and those present in the analysis models 4.Determine the compatibility between the assumptions and constraints of the architectural models and the analysis models, and resolve conflicts 5.Implement a model interpreter that executes a sequence of operations to transform an architectural model into an analysis model 6.Verify the correctness of the transformation

12. Proposed Solution Utilize an abstract component technology (ACT) to define domain-specific architectural modeling languages –An ACT is a metalanguage for software architectures –Defines metatypes that correspond to the fundamental concepts in software architecture, such as component, connector, interface, and link –Specifies constraints imposed by analysis technologies that must be satisfied for predictions to be valid –Can be easily used 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 June 1, 201512

13. Abstract Component Technology An ACT is a domain- and platform-independent metalanguage –Defines semantics for metalanguage constructs Defined in terms of capabilities, constraints, and properties that remain valid across domains/platforms Properties that vary from one platform to another are undefined ACT metamodels capture the capabilities, constraints, and properties of architectural elements in a particular domain or platform –Modify standard constructs and define new constructs –Used to specify: Patterns and roles defined by a reference architecture Model parameters that are required by a domain-specific analysis technique Platform-specific constructs that reflect the implementation facilities provided by a middleware June 1, 201513

14. ACTs: Use and Benefits Metamodeling mechanisms enable construction and manipulation of ACTs –Metamodel composition enables the combination of constructs from multiple languages –Metamodel enhancement allows the definition of new, customized language constructs June 1, 201514 Reduces the burden of language development on software architects Permits the reuse of common tool infrastructures across development projects and domains

15. ADAGE Reference Architecture June 1, 201515

16. Prism-MW Middleware Platform June 1, 201516

17. Layered Queuing Network Analysis Model June 1, 201517

18. June 1, 201518

19. Model Interpreter Frameworks A MIF is an infrastructure for constructing a family of model interpreters –Implements a semantic mapping between a domain-independent component model and analysis models –Abstracts the details of domain-independent interpretation –Produces an artifact 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 Can be reused by a software architect to rapidly construct analysis models from domain-specific architectures June 1, 201519

20. MIFs: Use and Benefits Assumptions –System models contain domain-independent elements that are sufficient to implement an interpretation –The interpretation of domain-independent elements is not dependent on the interpretation of domain-specific elements –Domain-specific constraints do not violate domain-independent constraints June 1, 201520 Allows interpreter construction tasks to be performed only once for a broad family of analysis techniques Provide built-in analysis capabilities along domain specific extensibility

21. The eXtensible Toolchain for Evaluation of Architectural Models (XTEAM) A modeling environment and accompanying set of analysis frameworks for software architectures –Implements and demonstrates my methodology –Currently 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 June 1, 201521

22. June 1, 201522 adevs Simulation Engine XTEAM Model Interpreter Framework GME Metamodeling Environment GME Metamodeling Paradigm The XTEAM Toolchain 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 xADL Structures and Types Finite State Processes ACT Extensions Application Architectures Energy Consumption Analysis Reliability Analysis End-to-end Latency Analysis Memory Usage Analysis Scenario- driven Analysis Results XTEAM ACT Metamodel XTEAM Architecture Models XTEAM Simulation Generators Application Simulations

23. The XTEAM Discrete Event Simulation MIF Implements a mapping from the XTEAM ACT to a discrete event simulation (DEVS) model Employs the Strategy pattern to enable an architect to implement domain- specific extensions –Each Concrete Strategy generates code to realize a particular analytic theory –Invoked at specific times during the interpretation process June 1, 201523 Generated code calculates and records analysis results Invoked when a component sends or receives data, calls an interface, starts or completes a task, etc. Provides scenario- driven, dynamic analysis

24. XTEAM Model Interpreter Frameworks June 1, 201524 Analysis TypeTarget Model Modeling Extensions 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 ModelSafety (unsafe conditions) Safety properties Liveness (locks/mutually exclusive resources) Lock/resource acquisition and release Security (unsecured channels, encryption) Malicious actors System SynthesisPrism-MW CodeDynamic Adaptation (lifecycle, mobility, replication) Meta-level components that perform run-time monitoring, reconfiguration, and redeployment

25. Summary of Contributions A new strategy for constructing DSDIs that: 1.Eliminates redundant effort in interpreter implementation A single MIF can be used to implement a broad family of analysis techniques 2.Allows effective reuse of model interpreters across domain-specific languages Analysis engines can be applied off-the-shelf to domain-specific languages 3.Provides a structured process for model interpreter development Architects can systematically implement domain-specific analysis techniques without having to implement complex model transformations 4.Simplifies the maintenance and evolution of model interpreters Changes to a domain-specific language require changes in each MIF, not in every interpreter June 1, 201525

26. Important Benefits XTEAM’s implementation of the strategy allows architects to: 1.Provide objective rationale for design decisions based on rigorous and proven analytic theories 2.Apply multiple classes of analyses to a single, unified system architecture model, such that design alternatives can be evaluated with respect to complex trade-offs 3.Predict the properties of complex assemblies of off-the-shelf components 4.Incrementally establish the conformance of component implementations to modeled behaviors June 1, 201526

27. Relevant Publications George Edwards, Chiyoung Seo, and Nenad Medvidovic, Model Interpreter Frameworks: A Foundation for the Analysis of Domain- Specific Software Architectures, submitted for publication.Model Interpreter Frameworks: A Foundation for the Analysis of Domain- Specific Software Architectures 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.Construction of Analytic Frameworks for Component-Based Architectures 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.Scenario-Driven Dynamic Analysis of Distributed Architectures June 1, 201527