Creating Domain-Specific Development Infrastructures

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)

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

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

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

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

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

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

11. Problems with MDE (2/2) Model Interpreter Implementation Tasks Find a computational theory that derives the relevant properties Determine the syntax and semantics of theanalysis modeling constructs 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 • 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

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

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

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

16. Prism-MW Middleware Platform

17. Layered Queuing Network Analysis Model

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

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

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

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

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

26. Important Benefits XTEAM’s implementation of the strategy allows architects to: • Provide objective rationale for design decisions based on rigorous and proven analytic theories • 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 • Predict the properties of complex assemblies of off-the-shelf components • Incrementally establish the conformance of component implementations to modeled behaviors

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