Creating Domain-Specific
Development Infrastructures
George Edwards
gedwards@usc.edu
Computer Science Department
University of Southern California
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 27, 2016
2
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 27, 2016
3
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 27, 2016
4
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 27, 2016
5
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
June 27, 2016
6
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 27, 2016
7
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 27, 2016
8
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
Metamodels define
elements, relationships,
views, and constraints
Model interpreters
leverage domain-specific
models for analysis,
generation, and
transformation
June 27, 2016
Metamodeling
Environment
Domain Specific
Modeling Environment
Metamodeling
Language
Domain Specific
Modeling Languages
Metamodel
Interpreter
Metamodels
XTEAM
XTEAMArchitecture
Architecture
Models
Models
Models
Model
Transformers,
Analyzers,
and
Generators
9
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 27, 2016
10
Problems with MDE (2/2)
• Lack of semantics prevents MDE
tools from providing off-theshelf 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
June 27, 2016
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
11
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 domainspecific 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 27, 2016
12
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 27, 2016
13
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
June 27, 2016
14
ADAGE Reference Architecture
June 27, 2016
15
Prism-MW Middleware Platform
June 27, 2016
16
Layered Queuing Network Analysis
Model
June 27, 2016
17
June 27, 2016
18
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 27, 2016
19
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
June 27, 2016
20
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 27, 2016
21
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 Metamodeling
Environment
GME Domain-Specific
Modeling Environment
GME
Metamodeling
Paradigm
June 27, 2016
Finite
State
Processes
adevs
Simulation
Engine
XTEAM ACT
XTEAM
Simulation
Generators
XTEAM
Architecture
Models
XTEAM ACT
Metamodel
xADL
Structures
and Types
XTEAM Model
Interpreter
Framework
ACT
Extensions
Application
Architectures
Energy
Consumption
Analysis
Reliability
Analysis
End-to-end
Latency
Analysis
Application
Simulations
Memory
Usage
Analysis
Scenariodriven
Analysis
Results
22
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 domainspecific 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 scenariodriven, dynamic
analysis
June 27, 2016
23
XTEAM Model Interpreter Frameworks
Analysis Type
Target
Model
Modeling
Extensions
Framework
Extensions
Scenario-Driven
Dynamic Analysis
Discrete Event
Simulation Model
Latency
Layered queuing networkbased performance model
(tasks, resources)
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
Ad-hoc memory usage model
Safety
Safety properties
(memory usages)
Model-Checking Static Finite State Model
Analysis
System Synthesis
June 27, 2016
Prism-MW Code
(unsafe conditions)
Liveness
(locks/mutually
exclusive resources)
Lock/resource acquisition
and release
Security
(unsecured
channels, encryption)
Malicious actors
Dynamic Adaptation
Meta-level components that
perform run-time monitoring,
reconfiguration, and
redeployment
(lifecycle, mobility,
replication)
24
Summary of Contributions
A new strategy for constructing DSDIs that:
1.
Eliminates redundant effort in interpreter implementation
•
2.
Allows effective reuse of model interpreters across domain-specific
languages
•
3.
Analysis engines can be applied off-the-shelf to domain-specific languages
Provides a structured process for model interpreter development
•
4.
A single MIF can be used to implement a broad family of analysis techniques
Architects can systematically implement domain-specific analysis techniques
without having to implement complex model transformations
Simplifies the maintenance and evolution of model interpreters
•
June 27, 2016
Changes to a domain-specific language require changes in each MIF, not in
every interpreter
25
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 27, 2016
26
Relevant Publications
• George Edwards, Chiyoung Seo, and Nenad Medvidovic, Model
Interpreter Frameworks: A Foundation for the Analysis of DomainSpecific 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.
June 27, 2016
27