1. Department of Computer Science University of Southern California Los Angeles, CA, USA George Edwards gedwards@usc.edu Nenad Medvidovic neno@usc.edu

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

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

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

5. procedure Chunker.NextChunk(this: ref where $IsNotNull(this, Chunker)) returns ($result: ref where $IsNotNull($result, System.String)); // in-parameter: target object free requires $Heap[this, $allocated]; requires ($Heap[this, $ownerFrame] == $PeerGroupPlaceholder || !($Heap[$Heap[this, $ownerRef], $inv] $Heap[$pc, $inv] == $typeof($pc) && $Heap[$pc, $localinv] // out-parameter: return value free ensures $Heap[$result, $allocated]; Automated Analysis of Designs Quality Analysis Automated Synthesis of Implementations Middleware Platforms Architectur e and Design System Models Automated Enforcement of Constraints

6. Metamodels capture domain concepts Specify domain-specific modeling languages Model interpreters implement transformations Perform analysis and synthesis

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

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

9. 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 domain- specific language constructs

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

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

13. Architecture: a collection of components and connectors that have been instantiated in a specific topology or configuration Component: a locus of computation; interacts with other components and connectors via interfaces Connector: implements communication and coordination facilities; interact with external entities via interfaces Group: a logical grouping of components and connectors; specifies membership in a set with domain-specific semantics Link: a logical connection between interfaces over which information and/or control is exchanged. Interface: an interaction point between entities; defines data exchange and transfer of control Datum: an object exchanged between components and connectors

14. 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 domain- independent 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

15. 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 Traverse the model Interpret each object based on type and context Apply domain- specific semantics at each extension point Invoke the architect- defined framework extension at each extension point

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

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

18. DEVS (analysis) Model Interpreter Framework

19. Prism-MW (synthesis) Model Interpreter Framework

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

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

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

24. 1. George Edwards and Nenad Medvidovic, A Methodology and Framework for Creating Domain-Specific Development Infrastructures, Proceedings of the 23rd 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 10th International Conference on Fundamental Approaches to Software Engineering (FASE), March 2007.

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

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

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

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

29. Lack of semantic definition leads to accidental complexity Onerous manual composition of metamodels Lack of rigorous and automated validation mechanisms Imprecise and ambiguous modeling constructs High design and implementation complexity Disproportionate maintenance and evolution costs Redundant development effort At the metamodel tier At the model tier At the interpreter tier

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

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

32. adevs Simulation Engine XTEAM Model Interpreter Framework GME Metamodeling Environment GME Metamodeling Paradigm 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 32

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

34. 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 CodeResource Allocation Resource pools, on-demand allocation Network Configuration Controller Area Network (CAN)

35. 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. 1. Chiyoung Seo, et al., An Energy Consumption Framework for Distributed Java-Based Systems, ASE 2007.An Energy Consumption Framework for Distributed Java-Based Systems 35

36. 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 1. M. Woodside, Tutorial Introduction to Layered Modeling of Software Performance.Tutorial Introduction to Layered Modeling of Software Performance 36

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

38. Individual component implementations may become 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. 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 38

39. 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 Client-Server Architecture Potential Workload

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

41. 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 Off-the-shelf componentsHighly accurate parameterization Determination of emergent properties 41