The Extensible Tool-chain for Evaluation of Architectural Models

1. The Extensible Tool-chain for Evaluation of Architectural Models George Edwards gedwards@usc.edu Center for Systems and Software Engineering University of Southern California

2. Presentation Outline • Introduction and Background • Architecture Description Languages • Model-Driven Engineering • Project Overview • Goals and Approach • XTEAM • Extensible Modeling Environment • Model Interpreter Framework • Scenario-Driven Dynamic Analysis • Key Capabilities • Ongoing and Future Work

3. Background - ADLs • Architecture Description Languages (ADLs) • Capabilities: • Capture crucial design decisions • Can be leveraged throughout the software development process • Shortcomings: • Rely on rigid formalisms • Focus on structural elements • Lack support for domain-specific extensibility Chart is taken from Medvidovic et al., A Classification and Comparison Framework for Software Architecture Description Languages

4. Background - MDE • Model-Driven Engineering (MDE) • Combines domain-specific modeling languages with model analyzers, transformers, and generators • Domain-Specific Modeling Languages (DSMLs) • Codify domain concepts and relationships as first-class modeling elements Metamodels define elements, relationships, views, and constraints Model interpreters leverage domain-specific models for analysis, generation, and transformation

5. Project Goals • Provide an extensible infrastructure to aid software architects… …provide design rationale “Using a peer-to-peer architectural style for System X will result in greater scalability.” …weigh architectural trade-offs “Increasing the reliability of Service Y will incur an increase in latency.” …evaluate off-the-shelf component assemblies “The set of components selected will meet system energy consumption requirements.” …test and validate systems incrementally “The prototype of Component Z is not behaving as expected.”

6. High-Level Approach

7. GME Metamodeling Environment GME Domain-Specific Modeling Environment XTEAM Model Interpreter Framework adevs Simulation Engine GME Metamodeling Paradigm XTEAM ADL XTEAM Simulation Generators Application Simulations XTEAM Architecture Models XTEAM ADL Metamodel xADL Structures and Types Finite State Processes Scenario-driven Analysis Results Memory Usage Analysis ADL Extensions Energy Consumption Analysis End-to-end Latency Analysis Application Architectures Reliability Analysis The XTEAM Tool-chain • XTEAM employs a metaprogrammable graphical modeling environment (GME) • XTEAM composes existing general-purpose ADLs: xADL Core (structures and types) and FSP (behavior) • GME configures a domain-specific modeling environment with the XTEAM ADL • Architecture models that conform to the XTEAM ADL are created • XTEAM implements a model interpreter framework • The XTEAM ADL is enhanced to capture domain-specific information • The XTEAM Model Interpreter Framework is utilized to implement simulation generators • Application simulations execute in the adevs discrete event simulation engine • Simulations operate on the information captured in ADL extensions to perform scenario-driven analysis

8. Extensible Modeling EnvironmentCapturing Domain-Specific Architectures • Key Challenges: • Development of ADLs is inherently difficult • Combining extensibility with formal semantics • Solution: Codify ADLs as metamodels • ADL composition enables the combination of constructs from multiple ADLs within a single model • ADL enhancement allows the definition of new, customized ADL constructs Reuse of existing ADLs maximizes the potential for reuse of the tool infrastructure. Incremental language extensions enable a specific architectural analysis technique.

9. Model Interpreter FrameworkImplementing Architectural Analyses • Key Challenge: • Implementation of semantic mappings is time-consuming and error prone • Solution: Utilize a model interpreter framework • Transforms architectural models into executable simulations • Provides empty “hook” methods that are implemented by the architect to perform analysis calculations and record measurements

10. Scenario-Driven Dynamic Analysis • Allows the architect to rapidly investigate the consequences of design decisions in terms of their impact on non-functional properties • Results depend heavily on the environmental context (e.g., the load put on the system) • May contain elements of randomness and unpredictability (e.g., the timing of client requests) • The set of scenarios to be simulated should include high-risk situations and boundary conditions

11. Project Goals • Provide an extensible infrastructure to aid software architects… …provide design rationale “Using a peer-to-peer architectural style for System X will result in greater scalability.” …weigh architectural trade-offs “Increasing the reliability of Service Y will incur an increase in latency.” …evaluate off-the-shelf component assemblies “The set of components selected will meet system energy consumption requirements.” …test and validate systems incrementally “The prototype of Component Z is not behaving as expected.”

12. Providing Design Rationale Client-Server Architecture • 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 • Model confidence level: Low Peer-to-peer Architecture Potential Workload Comparison of latency  P2P achieves greater scalability

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

14. Evaluating COTS Assemblies • Contemporary large-scale distributed systems contain numerous off-the-shelf 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 Determination of emergent properties Off-the-shelf components Highly accurate parameterization

15. Incremental System Validation • Individual component implementations may become available in a piecemeal fashion • XTEAM allows architects to • Immediately incorporate component implementations into a simulated system, increasing the accuracy of analysis results • Rapidly test individual components in the context of a wide variety of operational scenarios • Model confidence level: High Component implementation available Invoke implementation from behavior model Integrated simulation and test environment

16. Ongoing and Future Work • Evaluate XTEAM using a real-world security application that operates in an embedded, wireless environment • Collaboration with Bosch RTC • Integrate XTEAM with other complementary architecture-based development tools • DeSi (model interchange) • Prism-MW (code generation) • Mae (product line architectures) • Further define ways in which our approach can be integrated with widely-used architectural development processes • Architecture Trade-off Analysis Method (ATAM) • Prediction-Enabled Component Technology (PECT)