A Methodology and Framework for Creating Domain-Specific Development

A Methodology and Framework for Creating Domain-Specific Development Infrastructures George Edwards Nenad Medvidovic gedwards@usc. edu neno@usc. edu Department of Computer Science University of Southern California Los Angeles, CA, USA

Presentation Outline 1. Background 2. Research Challenges 1. Metamodel Integration 2. Model Transformation 3. Solution Approach 1. Abstract Component Technology 2. Model Interpreter Frameworks 4. Evaluation 5. Conclusions

Domain Knowledge in Software Engineering Expertise about the environment in which the target system operates Leveraged by codifying and reusing patterns, abstractions, and theories Reference architectures define design patterns Middleware platforms provide implementation abstractions Analysis technologies apply computational theories to system models Domain-specific development infrastructures (DSDIs) combine all these elements

Current Industry Practice Domain-knowledge is leveraged in an ad-hoc fashion No explicit codification of high-quality solutions Domain-specific tools built on an as-needed basis Throw-away tools built for a specific project Different tools used to create design and analysis models Design changes must be coordinated and synchronized

The Model Driven Engineering (MDE) Paradigm Architectur e and Design Automated Synthesis of Implementations Automated Analysis of Designs System Models procedure Chunker. Next. Chunk(this: ref where $Is. Not. Null(this, Chunker)) returns ($result: ref where $Is. Not. Null($result, System. String)); // in-parameter: target object free requires $Heap[this, $allocated]; requires ($Heap[this, $owner. Frame] == $Peer. Group. Placeholder || !($Heap[this, $owner. Ref], $inv] <: $Heap[this, $owner. Frame]) || $Heap[this, $owner. Ref], $localinv] == $Base. Class($Heap[this, $owner. Frame])) && (forall $pc: ref : : $pc != null && $Heap[$pc, $allocated] && $Heap[$pc, $owner. Ref] == $Heap[this, $owner. Ref] && $Heap[$pc, $owner. Frame] == $Heap[this, $owner. Frame] ==> $Heap[$pc, $inv] == $typeof($pc) && $Heap[$pc, $localinv] // out-parameter: return value free ensures $Heap[$result, $allocated]; Middleware Platforms Automated Enforcement of Constraints Quality Analysis

The MDE Process Metamodels capture domain concepts Specify domain-specific modeling languages Model interpreters implement transformations Perform analysis and synthesis

Metamodel Composition Challenges Creation of DSDIs requires composition of metamodels Reference architecture roles, patterns, and configurations Middleware type systems and services Analysis formalisms and parameters Lack of semantic definition within metamodels leads to accidental complexity Onerous manual composition of metamodels Lack of rigorous and automated validation mechanisms Imprecise and ambiguous modeling constructs

Model Transformation Challenges Creation of DSDIs requires implementing model transformations Generation of platform-specific code and configuration files Translation into languages used by analysis tools Lack of semantic definition within metamodels leads to accidental complexity High design and implementation complexity Redundant development effort Disproportionate maintenance and evolution costs

Solution Approach (1/2) Utilize an abstract component technology (ACT) to define domain-specific architectural modeling languages An ACT is a metamodeling language specialized for software architectures Associates domain-independent semantics with canonical architectural constructs Can be easily extended to define platform- and domainspecific language constructs

Solution Approach (2/2) 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

The e. Xtensible Toolchain for Evaluation of Architectural Models A modeling environment and accompanying set of analysis frameworks for software architectures Example extensions 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

Modeling in XTEAM

The XTEAM Abstract Component Technology Datum: logical grouping components entities; Link: a logical collection ofofbetween interfaces over Interface: implements communication and with other Group: aan object exchanged betweencomponents Connector: an connection componentsand connectors; Component: alocus of computation; interactsconnectors Architecture: ainteraction pointbetween andcoordination specifies membership in and transfer topology or facilities; data exchange a setentities via interfaces components and connectors control is exchanged. that haveinteract withand/orin a with domain-specific and connectors which information external specific of control defines been instantiated via interfaces

Model Interpreter Frameworks Provide the basis for analysis and synthesis in XTEAM A MIF is a reusable design structure for constructing a family of model interpreters Implements a semantic mapping between a domainindependent component model and analysis models or implementation artifacts Abstracts the details of domain-independent interpretation Produces an representation useful in a wide variety of contexts

Model Interpreter Framework Design Provides extension mechanisms to accommodate domain-specific analysis Based on objectoriented (OO) design patterns like Template Method, Strategy, and Functor Enables a family of analytic techniques to be applied to a component model Invoke the Apply Interpret Traverse architectdomaineach the model defined specific object framework semantics extension based onat at each type and extension context point

Discrete Event Simulation MIF Implements a mapping from the XTEAM ACT to a discrete event simulation (DEVS) model Employs the Strategy pattern to implement domain-specific extensions Each Concrete Strategy generates code to realize a particular analysis Invoked at specific times during the interpretation process Generated code calculates and records analysis results

Prism-MW MIF Synthesizes system implementations from architectural models Component logic and “glue code” in C++ Middleware configuration files Employs the Template Method pattern to generate application-specific extensions to the middleware 17

Comparison of Complexity (1/2) DEVS (analysis) Model Interpreter Framework 1 0. 8 0. 6 0. 4 0. 2 pl om C C SL O ex ity h ax M Reliability Extension M ax Av g C om pl D ep t ex ity h ep t D Av g et /M Energy Extension ts St m g M et ho Latency Extension % ho d la ss ds /C Br an ch es 0 Framework Core

Comparison of Complexity (2/2) Prism-MW (synthesis) Model Interpreter Framework 1 0. 8 0. 6 0. 4 0. 2 CAN Network Extension Resource Pool Extension C SL O ex i om pl D M ax C M ax pl om Av g C ty h ep t ex ity h ep t D Av g /M ts m St Av g M et % ho Br ds /C et ho d la ss an ch es 0 Framework Core

Conclusions Lack of automated mechanisms for composing metamodels and applying model transformations Our methodology Improves support for automated metamodel composition and model transformation Integrates and leverages semantics at both the metamodeling tier and the interpreter tier

Collaboration and Support Bosch Research and Technology Center The Boeing Company/Future Combat Systems USC Annenberg Graduate Fellows Program National Science Foundation

For More Information Visit the XTEAM website: http: //www-scf. usc. edu/~gedwards/xteam. html

Backup Slides

Selected Relevant Publications George Edwards and Nenad Medvidovic, A Methodology and Framework for Creating Domain-Specific Development Infrastructures, Proceedings of the 23 rd IEEE ACM International Conference on Automated Software Engineering (ASE), September 2008. 2. 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. 3. 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. 4. George Edwards, Sam Malek, and Nenad Medvidovic, Scenario-Driven Dynamic Analysis of Distributed Architectures, Proceedings of the 10 th International Conference on Fundamental Approaches to Software Engineering (FASE), March 2007. 1.

Design Modeling and Reference Architectures Architecture and design modeling languages capture essential properties of software systems, such as structure, behavior, interaction, and data Examples: UML, x. ADL Reference architectures define generalized software designs that can be customized, parameterized, and specialized within a certain context Examples: Bold Stroke, MIDAS

Middleware and Component Technologies Component technologies provide the basis for implementation and deployment of software architectures A component model defines the well-formedness of component instances/assemblies Development platform and run-time environment enforce the component model Examples include: Java EE CORBA Component Model. NET Framework OSGi Service Platform

Analysis of Quality Attributes 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 Modification of a system that does not meet quality attribute requirements is difficult and expensive Overall goal: Quantitatively and objectively evaluate quality attributes during system design to arrive at a better overall system

Problems with MDE 1. A model interpreter must be constructed for each analysis or target platform 2. Model interpreters are dependent on a particular DSML, so they must be rebuilt for each new DSML Requires system architects and developers to become tool developers – rather than merely tool users – to achieve integrated analysis Organizations want to develop with third-party, commercially-supported tools to reduce risk and cost 3. Constructing and maintaining DSMLs and interpreters is difficult and complex Little guidance exists on how to construct DSMLs and interpreters Requires particular type of expertise 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

The Problem with MDE Onerous manual composition of metamodels Lack of rigorous and automated validation mechanisms Imprecise and ambiguous modeling constructs in A te t th rp e tie re r te r m At od the tie e r l m et At t am he tie o r de l Lack of semantic definition leads to accidental complexity High design and implementation complexity Disproportionate maintenance and evolution costs

Overall Research Goals Create a methodology for applying analysis and synthesis tools to domain-specific architectural models that: 1. 2. 3. 4. 5. Avoids the difficult task of inventing domain-specific languages from scratch Eliminates redundant effort in interpreter implementation Allows effective reuse of model interpreters across domain-specific languages Provides a structured process for model interpreter development Simplifies the maintenance and evolution of model interpreters 30

Abstract Component Technology An ACT is a metamodeling language (metalanguage) that specifically targets modeling languages for software architectures Associates semantics with metamodel constructs (metatypes) Defines metatypes that correspond to the fundamental concepts in software architecture Defined in terms of capabilities, constraints, and properties that remain valid across domains/platforms Properties that vary from one platform to another are undefined Used to model the capabilities, constraints, and properties of architectural elements in a particular domain or platform Model parameters that are required by a domain-specific analysis technique Platform-specific constructs that reflect the implementation facilities provided by a middleware

The XTEAM Toolchain XTEAM employs a MDE environment, the Generic Modeling Environment (GME) XTEAM defines an ACT by composing existing general-purpose ADLs: x. ADL 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 Metamodeling Paradigm XTEAM ACT Metamodel GME Domain-Specific Modeling Environment XTEAM Model Interpreter Framework adevs Simulation Engine XTEAM ACT XTEAM Simulation Generators XTEAM Architecture Models Application Architectures Energy Consumption Analysis End-to-end Latency Analysis Application Simulations Memory Usage Analysis Scenariodriven Analysis Results 32

Characteristics of XTEAM Models System models are reactive Actions are performed in response to stimuli Parallel computation is distributed i. e. , not centralized The state of each process is private Interaction occurs via asynchronous, typed message passing A buffer exists between processes Process behavior may be non-deterministic Composite structures are defined by the parallel composition of processes

XTEAM Interpreter Frameworks Analysis Type Target Modeling Extensions Framework Extensions Scenario-Driven Dynamic Analysis Discrete Event Simulation Model Latency (tasks, resources) Layered queuing networkbased performance model Reliability (failures, R. Roshandel et. al, software component reliability model probability of recoveries) (hardware characteristics, interface profiles) C. Seo et. al, energy consumption estimation model Memory Usage Ad-hoc memory usage model Energy Consumption (memory usages) Safety properties Liveness (locks/mutually Lock/resource acquisition and release Security (unsecured Finite State Model Safety (unsafe conditions) exclusive resources) Model-Checking Static Analysis Malicious actors channels, encryption) System Synthesis Prism-MW Code Resource Allocation Resource pools, on-demand allocation Network Configuration Controller Area Network (CAN)

Energy Consumption Estimation Implements the energy cost estimation model of C. Seo, et al. 1 A computational energy cost is incurred when a component’s interfaces are invoked Interfaces are classified and parameterized according to energy consumption profile A communication energy cost is incurred when data is transmitted over a wireless network Depends on data size, network bandwidth, etc. Host A (i. PAQ) Battery Power Remaining Energy (J) 24500 24000 23500 23000 22500 22000 0 200000 400000 600000 Time (ms) 1. Chiyoung Seo, et al. , An Energy Consumption Framework for Distributed Java-Based Systems, ASE 2007. 35

End-to-End Latency Estimation Implements the layered queuing network performance model of Woodside. 1 Concurrent processes are modeled as tasks with specified resource requirements Accept requests from a single queue Has one or more identical worker threads Executes one or more classes of service Response Time (ms) Request File Response Time 2500 2000 1500 1000 500 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 Invocation 1. M. Woodside, Tutorial Introduction to Layered Modeling of Software Performance. 36

Reliability Estimation Implements the reliability estimation model of L. Cheung, et al. 1 Represents component behavior with a Markov model The probabilities of a failure occurring in each state is determined Analytical solving of the model determines the percent of time spent in a failure state 1. L. Cheung, et al. , Early Prediction of Software Component Reliability, ICSE 2008. 37

Incremental System Validation Individual component Component implementations may become implementation 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. Invoke implementation from behavior model Rapidly test individual components in the context of a wide variety of operational scenarios Model confidence level: High Integrated simulation and test environment 38

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 Client-Server Architecture Peer-to-peer Architecture Potential Workload

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 Decreases response time Replication of components Consumes more battery power 40

Evaluating Component Assemblies Contemporary large-scale distributed systems contain numerous off-theshelf 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 components Highly accurate parameterization Determination of emergent properties 41