University of Southern California Dissertations and Theses

Automated synthesis of domain-specific model interpreters

(USC Thesis Other)

Automated synthesis of domain-specific model interpreters

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content AUTOMATED SYNTHESIS OF DOMAIN-SPECIFIC MODEL INTERPRETERS by George Edwards A Dissertation Presented to the FACULTY OF THE USC GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulllment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (COMPUTER SCIENCE) August 2010 Copyright 2010 George Edwards Dedication I dedicate this work to my childhood friend Dave McGregor, who taught me to write my rst computer program and opened my eyes to the amazing world of computers. ii Acknowledgments I could never have completed the long, arduous road to the Ph.D. without the help of many people. I have had numerous wonderful teachers over the years. Among these, a few stand out as truly exceptional mentors. In particular, I would like to thank my Ph.D. advisor, Neno Medvidovic. Neno exemplies every characteristic a graduate student could ask for in an advisor: he is a brilliant scientist, a skilled educator, and a tireless advocate for his students. I would also like to thank the other members of my dissertation committee, Barry Boehm and Sandeep Gupta, for their very constructive critiques of my work. This dis- seration is undoubtedly stronger because of their input. My undergraduate advisors, Doug Schmidt and Andy Gokhale, were instrumental in my intellectual development. They taught me the fundamental skills of a computer scientist and inspired my interest in software engineering. I owe both of them a debt of gratitude for accepting me into their research group and taking the time to share their immense knowledge and expertise with me. I would like to issue my heartfelt thanks to Manuel Beltran, my internship mentor at Boeing. Manuel introduced me to the practical side of software engineering and was iii a major in uence on my formulation of a dissertation topic. I would also like to thank Leslie Liu and Randy Moulic, my internship mentors at IBM Research, for their valuable feedback on this project. Anyone who has done graduate research knows that it is a team endeavor. I have been privileged to work with a particularly smart and fun group of grad students. Sam, Chiyoung, Dave, Daniel, Josh, Yuriy, Ivo, Farshad, and Jae | thanks for everything. It was a joy working with you. Lastly, I would like to express my immense gratitude to my parents, Richard and Carolyn Edwards, for their unwavering encouragement and wise advise. Throughout my life, they have always ensured that every opportunity is available to me. iv Table of Contents Dedication ii Acknowledgments iii List Of Figures vi Abstract ix Chapter 1 Introduction 1 1.1 Concepts and Terminology 4 1.2 Motivation and Research Problem 12 1.3 Solution Approach 18 1.4 Contributions 21 Chapter 2 The XTEAM Approach 24 2.1 Platform Development 25 2.2 Platform Architecture 33 Chapter 3 The XTEAM Implementation 40 3.1 Example Application 41 3.2 Metamodeling 47 3.3 Interpretation 72 3.4 Simulation 88 Chapter 4 Evaluation 110 4.1 Applications 111 4.2 Experiments 127 Chapter 5 Related Work 137 5.1 Model-Driven Engineering Platforms 138 5.2 Other Related Technologies 147 Chapter 6 Conclusions 157 6.1 Future Research Directions 159 References 163 v List Of Figures 1.1 Relationships among instances, types, and metatypes in a multi-level type system. 9 1.2 The model-driven engineering (MDE) process. 11 1.3 Proposed mechanism for synthesizing domain-specic model interpreters. 19 2.1 Activities and tasks in the XTEAM MDE platform development process. 26 2.2 Overview of the XTEAM platform components for domain-specic mod- eling, analysis, and code generation. 35 3.1 Component view of the XTEAM implementation. 42 3.2 The Lunar Lander application modeled in (a) AADL and (b) the Myx architectural style. 44 3.3 The internal structure of the GameData component of the Lunar Lander. 44 3.4 The internal structure of the GameInterface component of the Lunar Lander. 45 3.5 The internal structure of the GameControl component of the Lunar Lander. 45 3.6 The XTEAM metatypes and their properties. 48 3.7 Denition of the MyxApplication domain-specic architecture type. 52 3.8 Denition of the MyxBrick domain-specic component type. 55 3.9 Denition of the MyxSynchronousInterface and MyxAsynchronousInter- face domain-specic interface types. 57 3.10 Denition of the MyxLink domain-specic link type. 59 vi 3.11 Denition of the JavaThread and JavaFile domain-specic resource types. 62 3.12 Denition of the JavaClass domain-specic implementation type. 64 3.13 Denition of the JavaMethodDecl domain-specic operation type. 65 3.14 Denition of the JavaMethod domain-specic task type. 67 3.15 Denition of the JavaObject domain-specic data type. 68 3.16 The XTEAM metamodel for the Myx architectural style. 70 3.17 The XTEAM metamodel constraints for the Myx architectural style. 71 3.18 Conceptual depiction of XTEAM model interpreter functions. 74 3.19 A code snippet from a metainterpreter code generator module showing a decision point based on derived semantics. 77 3.20 Conceptual depiction of the code generation module of an XTEAM-gener- ated domain-specic interpreter. 79 3.21 A code snippet showing how domain-specic type denitions are captured using type objects. 83 3.22 A code snippet showing how a decorator allows metatype instances to be customized with domain-specic behavior. 85 3.23 A code snippet showing how a template method applies domain-specic semantics in a structured manner. 87 3.24 Conceptual depiction of the XDEVS simulation engine functions. 95 3.25 A code snippet showing how an XDEVS event listener implements an en- ergy consumption analysis technique. 106 3.26 An energy consumption analysis of the Lunar Lander application computed by an XDEVS simulation. 107 3.27 Performance and reliability data computed by an XDEVS simulation of the Lunar Lander. 108 4.1 An embedded sensor network system analyzed with XTEAM models. 113 4.2 An autonomous mobile robotics system partially designed using XTEAM. 116 vii 4.3 The accuracy of an energy consumption estimation technique, computed by comparing XTEAM simulation data to measured values. 118 4.4 XDEVS simulation data characterizing the behavior of dierent redun- dancy strategies in a volunteer computing network. 120 4.5 XTEAM models of an automatically generated service-oriented architec- ture (a) before and (b) after adaptation. 122 4.6 The reliabilities of dierent congurations and components of a mobile emergency response system, as estimated by XTEAM simulations. 123 4.7 The accuracy of performance predictions produced by a queuing-network- based learning model implemented in XTEAM. 125 4.8 A decision support system that utilizes XTEAM as an adaptive architec- ture framework (AAF). 126 4.9 Nine metamodels used in the evaluation. 132 4.10 The code complexity metrics of the XDEVS and Prism-MW MIFs. 132 4.11 The implementation eort metrics computed for the XTEAM evaluation. 133 4.12 The maintenance eort metrics computed for the XTEAM evaluation. 135 6.1 The composition of three metamodel fragments. 161 viii Abstract Software architecture models are specications of the principal design decisions about a software system that primarily govern its structure, behavior, and quality. Architecture models provide a blueprint for how the system is implemented, serve as a basis for ex- perimentation with and rationalization of design decisions, and enable the automation of software engineering tasks. Domain-specic languages (DSLs) are modeling languages that are dened and customized for a particular family of problems or systems (the do- main). DSLs are able to concisely and intuitively express software architecture models because they natively include the design abstractions that are most useful and natural for the system under development. However, because DSLs have non-standard semantics that cannot be known a priori, leveraging architecture models specied in a DSL for automated quality analysis, code generation, and other activities requires the implementation of specialized tools, called model interpreters, that perform these functions. Implementation and maintenance of domain-specic model interpreters are widely recognized as dicult and complex tasks that incur a signicant burden on software engineers and reduce the appeal of the DSL approach. ix In this dissertation, I describe XTEAM, an integrated set of processes, notations, tools, and designs that enable the automated synthesis of model interpreters for DSLs. The key elements of XTEAM are (1) semantics embedded in the DSL specication (called a metamodel), (2) a metamodel interpreter that automatically synthesizes transformation rules derived from those semantics, and (3) a reusable model interpreter framework that applies those transformation rules in an ecient and structured way to domain-specic models. The impact of XTEAM is that software engineers can use a DSL and perform automated model analysis, code generation, and other types of model transformation and manipulation without having to develop custom tools, greatly reducing the time, eort, expense, and risk associated with domain-specic modeling. XTEAM has been and continues to be used successfully on a number of software engineering projects, and experimental evaluation of XTEAM indicates that, even when pessimistic assumptions are made, XTEAM automates what would otherwise require multiple person-months of eort. x Chapter 1 Introduction The ability of software engineers to overcome barriers of complexity and scale and create high-quality software stems from the eective use of design abstractions. Design abstrac- tions, such as objects, components, aspects, and services, are codied within software modeling and programming languages, which engineers use to dene the structure and behavior of software systems. Consequently, a core goal of software engineering research is to dene and support the most powerful and useful design abstractions possible, so that engineers may rapidly and easily express their design intent and synthesize systems that realize that intent. Within industries that require large-scale software-intensive systems and systems-of- systems, such as aerospace and telecommunications, there is a growing recognition among software engineers that codifying a software system's architecture is crucial to conquering complexity and scale [53, 54, 100]. The software architecture constitutes the principal design decisions about the system that primarily determine and govern its structure, be- havior, and quality [126]. Therefore, the design decisions that are part of the architecture of a given system are only a subset of the complete system design, but are crucial to 1 the success of the development eort. By capturing a system's software architecture in a machine-processable model, software engineers are able to experiment with design alter- natives [6], weigh trade-os among design goals [77], discover design aws [22], quantify system quality attributes [67], and so on. Moreover, given the appropriate tool support, architecture models can facilitate and automate numerous subsequent activities, including implementation, integration, testing, deployment, and maintenance [59]. By investing ef- fort in software architecture modeling early, software engineers hope to secure later eort reductions, reduce risk, and ultimately build systems better, faster, and cheaper. Given the growing importance of software architecture models in distributed systems development, software engineering research has investigated and proposed new design abstractions for modeling architectures [93]. However, the set of design decisions that are deemed suciently important to be considered part of the architecture vary widely from one system to another. For example, for highly resource-constrained systems, design deci- sions that aect memory footprint may be considered important, while for safety-critical systems, design decisions that aect failure propagation may be considered important. As a result, software engineers are demanding the ability to customize the set of design abstractions used for modeling software architectures based on the needs and goals of each development program, application family, or product line [121]. The model-driven engineering (MDE) paradigm encompasses processes and tools that allow software engineers to easily dene and use their own special-purpose sets of design abstractions called domain-specic languages (DSLs) [116]. DSLs are customized for use within a specic context, allowing engineers to capture design decisions using the most suitable and natural abstractions for the given situation. As a result, DSLs are 2 able to concisely and intuitively express the essential features of software system designs, i.e., software architectures. These advantages have been characterized as providing a stakeholder-driven [28] and problem-oriented [116] approach to system design. However, a signicant technical barrier has prevented widespread adoption of MDE: the relative diculty of using domain-specic models in support of automated design analysis, code generation, and other capabilities. DSLs contain non-standard types and semantics that cannot be known a priori, so using domain-specic models for design anal- ysis and code generation requires custom-built analysis tools and code generators [114]. As a result, constructing domain-specic models is far easier than using them for system analysis and generation [75]. The tight coupling between DSLs and their supporting tools signicantly reduces the appeal of MDE because it requires a supporting toolset to be built from scratch for each DSL, increasing the time, eort, and expense of architecture modeling (when it is meant to accomplish just the opposite). The contribution of this dissertation is an integrated set of processes, notations, tools, and designs, named XTEAM, that address this shortcoming by enabling rapid, automated synthesis of complete, end-to-end domain-specic toolsets for software architecture mod- eling, analysis, and code generation. Individual tools within such toolsets, called model interpreters, are created by conguring, adapting, and extending reusable tool frame- works, called model interpreter frameworks, based on a formal DSL specication, called a metamodel. Tools of this type are termed metaprogrammable. In support of this core contribution, this dissertation also provides a demonstration of the viability and capa- bilities of the XTEAM approach through a working implementation and an evaluation of the utility and benets of XTEAM based on case studies and experimentation. The 3 evaluation of XTEAM shows that it can be applied to a large variety of software ar- chitecture modeling languages, it encapsulates most of the model interpreter complexity within reusable components, and it signicantly reduces model interpreter development and maintenance eort. 1.1 Concepts and Terminology This section summarizes the foundational concepts and denes the key terms used in this dissertation. 1.1.1 Architecture Modeling A software or system architecture is the set of principal design decisions for the system [57, 107,126]. An architecture model is a specication of an architecture using formal or semi- formal notations. An architecture model generally comprises a combination of graphical diagrams and structured text. The model captures design decisions as a set of entities in the model, relationships among those entities, and attributes of the entities. The entities in architecture models are derived from architecture concepts and design abstractions. Although design abstractions vary among systems and models, most archi- tectures include notions of components, connectors, and interfaces [93]. Components are loci of computation and information that implement application functionality and ser- vices. Connectors support interaction among components by providing communication and coordination facilities. Interfaces are interaction points or ports between components and connectors. Additionally, the following concepts provide the foundations for architecture modeling: 4 Architectural styles are named collections of constraints on design decisions. Archi- tecture models may incorporate the constraints of a particular architectural style to ensure that they are obeyed. Reference architectures and product-line architectures dene generalized software designs that can be customized, parameterized, and specialized for use within a cer- tain context. The roles, patterns, and congurations of a reference architecture can be captured by an architecture model. This reies reference-architecture-specic design abstractions as rst-class model entities and ensures that the modeled ap- plication architecture conforms to the reference architecture. Middleware platforms and application frameworks provide implementation con- structs and run-time services, supplying applications with reusable realizations of recurring patterns and algorithms. Architecture models may be designed for com- patibility with the type system of a middleware platform (called a middleware com- ponent model). This lets architects specify how middleware services are utilized. Analysis technologies apply computational theories to system models in order to derive information about the properties or behavior of a system. The mathematical formalisms leveraged by an analysis technology can provide the basis for architec- ture models. This ensures that architecture models include the system parameters necessary for analysis and obey the constraints imposed by the analysis technique. Models of software architectures are used for a variety of purposes in software en- gineering [20]. First, architecture models are used to document software designs and 5 communicate design decisions among system stakeholders, including designers, program- mers, and administrators. In this capacity, the architecture model provides a reference or blueprint for how the system is (or will be) implemented. Second, architecture models are used to analyze the system design to optimize and verify its behavior. In this role, the architecture model serves as a basis for experimentation with and rationalization of design decisions. Third, architecture models are used to automatically generate a variety of useful artifacts, such as source code, conguration les, and test cases [59]. In these cases, architecture models enable the automation of software engineering tasks. 1.1.2 Modeling Languages An architecture modeling language (sometimes called an architecture modeling notation or architecture description language) denes a vocabulary, lexicon, and symbols for specify- ing architecture models. Many dierent types of architecture languages exist. Graphical languages use drawings and diagrams to describe entities, while textual languages use words and characters. Structured languages impose precise rules on the form of model content, while unstructured languages do not restrict the form of content. Precise lan- guages have an unambiguous meaning, while imprecise languages have loosely dened meaning. The level of structure and precision of a language is commonly referred to as its level of formality. The expressiveness of a language indicates the space of possible systems that models conforming to the language can describe. Architecture modeling languages are dened by syntax and semantics [68]. Syntax denes the set of models that are valid in terms of the classes of entities, or types, in the language; every entity in a model is an instance of exactly one type. The syntax 6 also denes the properties of each type, which may be relationships among entities (e.g., containment or inheritance) or attributes (e.g., an identier). The semantics of a modeling language dene the meaning or consequence of models or model entities within a certain context, or semantic domain. For example, the semantics of a language may dene the eect of executing the model within a particular environment. A language may have multiple sets of semantics that apply in dierent semantic domains. 1 For the purposes of this dissertation, it is useful to distinguish between standardized and domain-specic architecture modeling languages. A standardized language is dened by a specication that has been agreed upon by a software or systems engineering com- munity and then publicized so that anyone may learn the language and build tools that support the language. Standardized languages are designed to be widely applicable and be useful in a variety of contexts. The goal of standardizing a language is to create a large base of engineers who are trained in how to use the language and a body of inter- changeable tools for building and manipulating models. For training and tools to work across organizations and projects, engineers and tool developers must agree to abide by the language specication and may not modify the language independently. 1 This dissertation employs the denitions of syntax and semantics used in the architecture modeling community, which are slightly dierent than those used by the formal programming languages community. Strictly speaking, both communities dene syntax as the set of models or expressions that are valid in the language, while semantics is dened as the result of executing a valid model or expression. However, formal programming languages have generally distinguished between static semantics and dynamic semantics. Static semantics are language constraints, such as type constraints and scoping rules, that are checked at compile-time but are not easily expressible in a context-free grammar. Static semantics are instead specied using context-sensitive techniques such as attribute grammars, and are therefore labeled as semantics, even though they are ocially part of the syntax because they dene the set of valid expressions in the language. Architecture modeling languages, on the other hand, are generally not specied with a context-free grammar, and static semantics are easily specied using syntactic techniques. As a result, in architecture modeling, the more precise denition of syntax, which includes static semantics, can be employed, and semantics refers just to dynamic semantics. 7 A domain-specic language (DSL), on the other hand, is dened and used by a group of engineers for a particular family of problems or systems (the domain). DSLs are therefore designed to have a narrow focus and to be useful only in limited contexts. The goal of using a DSL is to create models that are customized and specialized, and are therefore more concise and intuitive. A DSL may be modied in arbitrary ways by users of the language based on the needs of the modeling project. The classication of languages as standardized or domain-specic is an informal one, but nonetheless has great importance for practical reasons: standardization implies the availability of trained users and o-the-shelf tool support, but also implies that the language may not be modied. 1.1.3 Metamodels and Type Systems A formal specication of a modeling language is called a metamodel. A metamodel is itself a collection of diagrams and text that denes the syntax of a modeling language. A metamodel species the types of entities in the language, their properties, the available views of the model, and constraints on how types may be used (i.e., what constitutes a well-formed model). A notation used to construct metamodels is called a metamodeling language or metalanguage. The types present in a metalanguage are called metatypes. Each metatype instance in a metamodel denes a type in a modeling language. The concept of metamodeling can be extended to an arbitrary number of levels: a metalanguage can itself be specied by a meta-metamodel, which is in turn specied in a meta-metalanguage, and so on. As a result, the use of metamodeling results in a multi- level type system. In a multi-level type system, every model entity at leveln is an instance of an entity at level n + 1. Equivalently, every model entity at level n (except those at 8 Defines Metalanguage Metatype Type Metamodel Metamodel Object Modeling Language Model Object Model Instance of Instance of Conforms to Conforms to Level n + 1 Level n Specification of Instance facet Type facet Figure 1.1: Relationships among instances, types, and metatypes in a multi-level type system. level 0) is a type denition for a class of entities at level n1. For example, instantiating a metatype at the metamodeling level creates a new type denition at the modeling level. Because every entity in a multi-level type system is both an instance and a type, entities are described through both a type facet and an instance facet [4]. The type facet denes the kinds of relationships and attributes that instances of the type (residing at the level below) must have. The instance facet species the instance's relationships with other instances (at the same level) and assigns values to the attributes of the instance, as required by its type denition (residing at the level above). The relationships among instances, types, and metatypes are depicted in Figure 1.1. 9 1.1.4 Model Transformation and Interpretation Automated design analysis and code generation using architecture models is achieved through model transformation [122]. A model transformation maps an input model to some output, which could be another model specied in a dierent language, a set of analysis results, or anything else a program can produce. Model transformation allows a single model to be used for a variety of purposes. For example, model transformations are commonly used to automatically generate, from an architecture model, other models required by a specic analysis technique or implementation code for a specic run-time platform. In practical terms, a model transformation is usually implemented by a program called a model interpreter. A model interpreter reads the data contained in models, manipulates that data, and produces output for a particular semantic domain. By dening the meaning of models in that semantic domain, a model interpreter denes (one set of) semantics for the language. Model execution takes place in the semantic domain. The semantic domain may be implemented by an external application (e.g., an analysis tool) or run-time environment (e.g., a middleware platform). 1.1.5 Model-Driven Engineering Model-driven engineering (MDE) [116] (sometimes referred to as model-integrated com- puting [123]) is a system creation and evolution paradigm that leverages metamodeling to create domain-specic languages (DSLs) and utilizes model interpreters to automate design analysis and code generation. 10 Metamodel Interpreter Metamodeling Language Metamodels Metamodeling Layer Modeling Layer GME Modeling Environment Metaprogrammable Model Editor Domain-Specific Modeling Languages Domain-Specific Models Metamodel Editor Model Interpreter Run-Time Environment Semantic Domain Layer Executable Models Execution Semantics Figure 1.2: The model-driven engineering (MDE) process. The MDE paradigm is realized via the appropriate processes and tool support. MDE platforms are toolsets that facilitate and automate MDE processes. An MDE plat- form minimally includes a metamodel editor, a metamodel interpreter (or metainterpreter for short), and a metaprogrammable model editor. The Generic Modeling Environment (GME) [58] and the Eclipse EMF/GEF/GMF family of tools [36] are well-known exam- ples of MDE platforms. Figure 1.2 illustrates the process of using an MDE platform. Software engineers rst use the metamodel editor to create a metamodel that denes a DSL. The metamodel specication process consists of instantiating the types available in the metalanguage (the metatypes) and setting the values of their properties. The available metatypes vary from one MDE platform to another. Each metatype instance captures the type denition for a class of domain-specic model entities. Once a metamodel has been specied, the engineer invokes the MDE platform's metainterpreter, which takes the metamodel as input and produces a set of conguration les or plug-ins for the metaprogrammable model editor as output. The conguration les or plug-ins specify how to manage internal representations of domain-specic models, 11 enforce constraints on model well-formedness, visually render models, and modify models based on engineer commands, according to the DSL syntax. A model editor that has been congured for a particular DSL becomes a domain-specic model editor. Software engineers view and modify domain-specic models using the congured, domain-specic model editor. Domain-specic models, by themselves, are useful for architecture documentation and communication. However, utilizing domain-specic models for automated design analysis and code generation requires model interpreters that implement transformations of the domain-specic models to other forms. Current MDE platforms do not provide built- in model interpreters for design analysis and code generation. Instead, they require software engineers to implement their own model interpreters by accessing an application programming interface (API) provided by the model editor to extract and manipulate the information contained in models and generate output that can be directly executed within the target semantic domain. This shortcoming with existing MDE platforms provides the motivation for this dissertation, and is elaborated next. 1.2 Motivation and Research Problem Domain-specicity in architecture models confers a number of benets, but also incurs some drawbacks. The advantages and disadvantages of standardized and domain-specic languages are essentially the inverse of each other. Therefore, the disadvantages of using a DSL are precisely the lack of those advantages present in the standardized approach: care must be taken to create a well-designed language, engineers must be trained to use 12 the language, and tools must be built to support modeling activities using the language. This section explores the benets of domain-specic modeling to explain the motivation for using and improving MDE processes and tools, and describes the important drawbacks of existing MDE platforms. This dissertation addresses one of these drawbacks. 1.2.1 Language Design and Training Building large, complex, detailed models is a time-intensive task. One of the biggest determinants of how much eort is required to create a model is the modeling language used [76]. A poorly designed modeling language can result in the duplication of infor- mation, the inclusion of unnecessary information, internal inconsistencies and con icts, onerous input processes, and other negative eects that increase modeling time and cost. Therefore, utilizing a well-designed language is essential for a successful modeling ef- fort [95]. Widely-used standardized modeling languages, such as the Unied Modeling Lan- guage (UML) [127], are produced through careful consideration by teams of experts over multiple iterations. Therefore, in most respects they are very well-designed, complete, and eective. Engineers obtain the benets of all the extensive work and signicant ex- pertise that went into the language design simply by adopting the language. However, standardized languages do suer from two design weaknesses. First, standardized lan- guages must appeal to a wide spectrum of users. As a result, they include a large number of features, but within the context of any given modeling project, only a subset of the features are used. This, in turn, leads to lengthy language specications that are hard to understand and models that contain many unused elements. Second, standardized 13 languages are produced through consensus and group decision-making, resulting in the classic design-by-committee problem: the language design may re ect competing goals and priorities, rather than a unied, coherent vision. In domain-specic modeling, the responsibility for producing the DSL metamodel falls on application software engineers, rather than modeling language experts. The creation of semantically powerful, exible, and intuitive modeling languages, even with the benet of metamodeling environments, is inherently challenging [106]. Furthermore, DSL devel- opment requires both domain expertise and metamodeling expertise; that is, a language developer must command a thorough understanding of the central and elemental concepts in the target domain and must be adept in the mechanisms for codication of those con- cepts. This poses an obstacle because domain experts are commonly not metamodeling experts, and vice-versa. As a result, DSL specication is usually an iterative, interactive process involving metamodeling experts and domain experts. On the other hand, a DSL is generally much smaller and simpler than a standardized language because it is tailored for a narrow purpose. Promising solutions to the DSL design challenge include techniques for increasing metamodel reuse and automating composition of metamodels from metamodel frag- ments [129, 131]. For example, the Microsoft DSL Tools [23] platform allows engineers to specify DSLs by instantiating and then customizing a pre-specied language template. However, this can be considered an essential challenge of domain-specicity { to create a customized language, some language design eort is required. Finally, when a new DSL is created, or whenever a DSL is modied, software engineers must be trained how to use the new or updated language. This challenge is mitigated by 14 two factors. First, the user base of software engineers for a DSL is generally fairly small { one or several teams within a single organization or group of collaborating organizations. Second, as noted above, DSLs tend to be smaller and simpler than standardized lan- guages because they are not intended to be widely applicable, and are therefore easier to learn. However, software engineer training is also an essential challenge of domain-specic modeling. 1.2.2 Tool Development Because DSLs are not standardized, tools that leverage models for common functions like analysis and code generation must be custom-built for each language. This requires application software engineers to become tool developers { rather than merely tool users { to achieve integrated design analysis and code generation. Application engineers want to develop with third-party, commercially-supported tools to reduce risk and cost [80]. The implementation of domain-specic model interpreters frequently requires a signi- cant investment of resources. Domain-specic modeling editors provide APIs for model interpreters to access and manipulate the information contained in models, but in many cases, a complex semantic mapping between languages is required that is dicult to de- ne and implement. For example, such a mapping is required to transform architecture models, which are at a very high level of abstraction, into executable simulations or pro- gram code, which are at a lower level of abstraction. Model interpreters are complex and dicult to build and maintain, which incurs a signicant burden on software engineers using a domain-specic modeling approach [114]. Implementing model interpreters is widely recognized as a dicult problem [75]. 15 To implement a domain-specic model interpreter, software engineers must: 1. discover the semantic relationships between the types present in the DSL and those present in the semantic domain; 2. verify that the DSL contains sucient and suitable information to perform a trans- formation to the semantic domain; 3. determine the compatibility between the assumptions and constraints of the DSL and the semantic domain, and resolve con icts between the two; 4. design a model interpreter that executes a sequence of operations that perform the model transformation; 5. implement the model interpreter in a way that is acceptably ecient and scalable; and 6. verify the correctness of the transformation implemented by the interpreter. Current MDE platforms cannot provide built-in model interpreters for analysis and code generation because their metatypes lack sucient semantics for their instances to be automatically mapped to other forms, such as executable code. Rather, the metatypes only contain sucient semantics to synthesize a custom model editor (i.e., to automati- cally map metatypes to graphical display elements). The consequences of this limitation are: High design and implementation complexity. Developing custom-built model interpreters for analysis and code generation requires developing complex seman- tic mappings between languages [114]. Model transformation is recognized as a 16 suciently dicult problem that implementations of specic transformations, such as tools that map design models to performance or reliability models, are com- monly published in the software engineering research literature [11, 25]. Further- more, model interpreters have been found to be the primary source of errors in MDE toolchains that apply analytic theories to architecture models [83]. Disproportionate maintenance and evolution costs. Due to their tight cou- pling, whenever a modication is made to a DSL, a corresponding non-trivial change must be made to all interpreters of the DSL. The ability to easily evolve metamod- els and languages is, in theory, one of the most attractive benets of MDE, so the diculty in evolving interpreters is a signicant obstacle [135]. Redundant development eort. Model interpreters are often developed in a one-o fashion due to a lack of eective mechanisms for facilitating reuse of in- terpreter logic [74]. For example, if a new development project begins that uses a dierent reference architecture but requires the same types of architectural analysis, interpreters are often rebuilt. Opportunities for factoring out reusable transforma- tion operations are thus discarded. The overhead and maintenance costs associated with employing the MDE process, as outlined above, make it a less attractive development strategy for small- and medium- scale software systems. This is re ected in the fact that MDE has experienced widespread industry adoption in large-scale defense and aerospace programs, but relatively limited adoption in small business and desktop application development [98]. 17 1.3 Solution Approach The aim of the research described in this dissertation is to drastically reduce the time and eort required to create end-to-end domain-specic modeling, analysis, and code generation toolsets by automatically synthesizing domain-specic tools using metamod- els. Existing MDE platforms automatically synthesize only one of the tools needed for an end-to-end toolset | the domain-specic model editor. The approach described in this dissertation utilizes the same mechanism that is used by current MDE platforms to synthesize domain-specic model editors to synthesize the other tools needed for an end-to-end toolset | the domain-specic analysis tools and code generators. Recall that existing MDE platforms synthesize domain-specic model editors by (1) incorporating into metamodels information about how model objects should be presented in the synthesized domain-specic editor, (2) implementing a highly exible, congurable model editor that allows model objects to be presented in a variety of ways, and (3) implementing a metainterpreter that generates conguration les or plug-ins for the con- gurable model editor that specify how each object should be presented, according to the information in the metamodel. Analogously, the mechanism for synthesizing domain- specic model interpreters developed in this dissertation is to: 1. Dene metatypes and metatype properties that capture the semantics of domain- specic types for a particular semantic domain. 2. Implement a congurable model interpreter, called a model interpreter framework, that allows model objects to adopt a variety of semantics. Conceptually, the model interpreter framework can be viewed as a library of model transformation operations 18 Model Repository Metamodel Editor Metamodel Configurable Model Editor Model Editor Config Files Configurable Code Generator Code Generator Config Files Configurable Analysis Tool Analysis Tool Config Files Editor Metainterpreter Presentation Semantics Generator Metainterpreter Code Generation Semantics Analysis Metainterpreter Analysis Semantics Type Definitions Analysis Definitions Code Generation Definitions Presentation Definitions Application Model Presentation Interpretation Synthesis Interpretation Analysis Interpretation MDE Platform Component Model Key Metatype Properties Semantics Framework Extension Model Interpreter Framework Figure 1.3: Proposed mechanism for synthesizing domain-specic model interpreters. that can be exibly applied to model elements in multiple ways to account for semantic variability. 3. Implement a corresponding metainterpreter that generates conguration les or plug-ins for the model interpreter framework, called framework extensions, that specify the semantics of each object, according to the property values assigned to the object's type denition in the metamodel. The conceptual similarity between the model editor and model interpreter components in this approach is depicted in Figure 1.3. 19 The proposed approach can be formalized by the following three hypotheses: H1. If the set of algorithms A for a model transformation T : M ) M 0 rely only on the properties p 0 :::p n of the metatype instances that dene M, then A along with the values of p 0 :::p n is a sucient specication to perform T on any input model m that conforms to M to produce an output model m 0 that conforms to M 0 . This hypothesis states that if the semantics of any object in a domain-specic model can be inferred from the object's type denition in a metamodel, then any domain- specic model for which a metamodel is specied can be automatically transformed into the semantic domain. H2. A model interpreter I that implements T can be automatically synthesized from (1) a model interpreter framework I frame that implements A and (2) a framework extension generated by a metainterpreterI meta that encodes rules, derived from the values of p 0 :::p n , for applying A. Furthermore, I frame and I meta can be implemented without a priori knowledge of M. This hypothesis states that the transformation can be performed by applying trans- formation operations from a pre-implemented library to domain-specic models according to their inferred semantics. H3. The specication and modication ofp 0 :::p n are easier than the specication and modication of I, as measured by implementation code complexity and reuse. This hypothesis states that the additional work required to specify metatype proper- ties is less than the work required to implement a model interpreter. 20 1.4 Contributions The primary contribution of this dissertation is XTEAM 2 , an integrated set of processes, notations, tools, and designs that enable rapid, automated synthesis of complete, end- to-end domain-specic toolsets for software architecture modeling, analysis, and code generation. More specically, this high-level contribution includes the following novel elements: 1. Denition of the processes performed by MDE platform developers in utilizing XTEAM. The XTEAM conceptual approach is a blueprint for creating MDE platforms. I identify the several related design tasks XTEAM requires to be performed to implement the blueprint. 2. Denition of the XTEAM MDE platform architecture. The XTEAM ar- chitecture denes a structure for an MDE platform, in terms of components and their interactions, and the behavior of components, in terms of their functionality. I present the XTEAM architecture and explain the rationale for its elements. 3. Specication of the XTEAM metalanguage. XTEAM denes a software architecture-based metalanguage for the specication of domain-specic architec- ture modeling languages. The XTEAM metatypes and metatype properties include embedded semantic assumptions and specications for selected semantic domains. I enumerate and specify the types and properties in the XTEAM metalanguage. 4. Implementation of the XTEAM MDE platform. The XTEAM MDE plat- form software is an implementation of the XTEAM approach, and can be thought 2 The name XTEAM stands for eXtensible Toolset for Evaluation of Architecture Models 21 of as an open-source reference implementation or prototype for MDE platform de- velopers utilizing the approach. The XTEAM software includes both stand-alone components and extensions o-the-shelf MDE platform components to create an end-to-end MDE toolset for software architecture modeling, analysis, and code gen- eration. I describe the interfaces and function of each of the XTEAM components. 5. Identication of benecial design solutions in XTEAM components. Flex- ible, scalable designs for the XTEAM components can be achieved through appli- cation of specialized design patterns. I identify these patterns and illustrate how they were applied in the XTEAM software. 6. Design and implementation of XDEVS. XDEVS is a highly modular, extensi- ble discrete event simulation engine. XTEAM includes the capability to automati- cally synthesize domain-specic model interpreters that target the XDEVS run-time environment (as well as other types of model interpreters). XDEVS allows software engineers to instrument simulations to collect data about dynamic system func- tional behavior and quality characteristics and substitute default simulation engine modules with domain-specic modules that exploit domain knowledge. 7. Discussion and evaluation of XTEAM. XTEAM has been applied in a team setting to several industrial applications and research prototypes and it has been evaluated using a set of experiments that quantify its benets. I provide the lessons learned and evaluation results and discuss the trade-os and limitations of XTEAM. 22 This dissertation is organized as follows. Chapter 2 describes the XTEAM conceptual approach, including the MDE platform development processes and architecture. Chap- ter 3 describes the XTEAM metalanguage, components, design solutions, and XDEVS. Chapter 4 evaluates and discusses the benets and drawbacks of XTEAM. Chapter 5 surveys the related work in MDE and software architecture research. Finally, Chapter 6 summarizes the XTEAM research contributions and considers a promising future research direction. 23 Chapter 2 The XTEAM Approach The XTEAM approach comprises a new MDE platform development process and architec- ture. The result of using the XTEAM process and instantiating the XTEAM architecture is an MDE platform implementation that includes analysis and code generation capabili- ties that can be applied to any DSL specied using the platform. The XTEAM approach can be leveraged to implement a wide variety of dierent MDE platforms with diering capabilities. This chapter denes the high-level tasks performed when using the XTEAM approach and presents the key components of the XTEAM architecture. This dissertation adopts the following terminology to refer to the dierent roles played by engineers in MDE. MDE platform developers build metaprogrammable modeling, anal- ysis, and synthesis toolsets (i.e., MDE platforms) for use by others. MDE platform de- velopers are experts in the scientic theories underlying modeling languages and model transformation. MDE platform users are the members of an application development team who leverage an MDE platform to solve problems and build applications. There are two classes of MDE platform users: metamodelers and application engineers. Metamod- elers are responsible for dening DSLs. Metamodelers are experts in modeling language 24 design, software and systems architecture, and the relevant domain. Because DSL de- nition is so critical, metamodelers are generally the most experienced and knowledgeable members of an application development team. Application engineers are responsible for building models of specic applications using a DSL. Application engineers also apply analysis and code generation tools to their models to improve their designs and produce an implementation. Of these dierent types of engineers, MDE platform developers are the fewest in number, followed by metamodelers, with application engineers being the most numerous. Of course, in some cases, a single individual may adopt two or even all three of these roles. 2.1 Platform Development The XTEAM process includes three activities. First, MDE platform developers select the set of analysis and code generation capabilities to be supported by the platform. Second, MDE platform developers extend the semantics of the platform metatypes to enable those capabilities. Third, MDE platform developers create a metainterpreter and model interpreter framework that together permit automatic synthesis of tools that implement those capabilities. These three primary activities and their constituent tasks are shown in Figure 2.1. 2.1.1 Capability Selection The choice of what analysis and code generation capabilities to support is a fundamental decision when using the XTEAM MDE platform architecture, and must be made based on the expected usage of the MDE platform. This decision determines what semantics 25 Select Capabilities Define Metatypes Develop Components Identify candidate semantic domains Evaluate candidate semantic domains Define/refine core architectural metatypes Embed semantic assumptions in metatypes Attach semantic properties to metatypes Implement model interpreter framework Implement metamodel interpreter Figure 2.1: Activities and tasks in the XTEAM MDE platform development process. will be included within metamodels. Numerous methods could be used to select a set of capabilities. This section outlines one possible method, which was the method used to select capabilities for the XTEAM implementation. The XTEAM method for selecting capabilities consists of two tasks: identifying can- didate semantic domains and evaluating candidate semantic domains. Identifying Candidate Semantic Domains To identify appropriate candidate semantic domains, MDE platforms developers must understand the contexts in which the platform will be applied, and identify common needs for analysis and code generation. Important questions are: 26 To what types of analysis are problems in the expected contexts amenable? For example, do they contain discrete or continuous elements? Do they contain many simple replicated objects or complex hierarchical objects? What o-the-shelf analysis tools exist that provide one or more analysis capabili- ties that help solve common problems in the expected contexts? For example, are mathematics libraries (e.g., Mathematica [132]) or numerical solvers (e.g., MAT- LAB [91]) commonly used? What form of languages and instruction sets are most often used to specify systems in expected contexts? For example, are the languages object-oriented or based on some other abstraction, such as spatial dimensions? On what platforms and in what environments do systems in the expected contexts execute? For example, are there middleware platforms or application frameworks that are used to implement these types of systems? Based on the answers to these questions, MDE platform developers compile a list of potentially relevant semantic domains. Evaluating Candidate Semantic Domains Evaluating candidate semantic domains involves weighing a number of practical consid- erations. These considerations can be roughly grouped into the following categories: Cost. The cost of supporting a candidate semantic domain is primarily based on the time and eort needed to implement the necessary interpretation components 27 in the MDE platform. The relative time and eort required can be estimated based on how complex the semantic domain is, and how dicult it is to transform models to the semantic domain, relative to other candidates. Payo. The payo of supporting a candidate semantic domain is based on the expected proportion of application contexts that use the semantic domain and the value provided to each application. At the end of this task, MDE platform developers create a prioritized list of seman- tic domains for which their MDE platform will support automated synthesis of model interpreters. 2.1.2 Metalanguage Denition Once a set of analysis and/or code generation capabilities has been selected, the next activity in the XTEAM approach is to move the semantics required for those capabili- ties, which were previously embedded within a manually coded model interpreter, into the metamodel. This process allows a metainterpreter to automatically generate all the information needed to create analysis and code generation tools. In order to automatically synthesize a model interpreter that implements an analysis or code generation capability, a complete semantic mapping from domain-specic ele- ments to semantic domain elements must be dened within the metamodel. Each type of domain-specic element is represented in the metamodel by a metatype instance, so each metatype instance must dene a semantic mapping to a set of semantic domain constructs. Thus, the set of semantics that must be included in a metamodel are exactly 28 the semantics that are sucient to infer, for each metatype instance, a mapping to the relevant semantic domain constructs. The XTEAM method for dening a metalanguage that allows specication of seman- tics consists of three tasks: dening a core set of metatypes based on canonical software and system architecture concepts, embedding semantic assumptions in those metatypes, and attaching properties that capture semantic variability to the metatypes. Dening Core Architectural Metatypes Metalanguages are generally centered around a small set of basic metatypes, which I refer to as the core metatypes. The core metatypes are derived from basic information representation paradigms, such as the object-oriented or the relational data model. The set of core metatypes varies from one MDE platform to another [79]. For example, the GME platform [58] denes Model, Atom, Connection, Set, and Reference metatypes, while the core metatypes of the Eclipse GMF platform [35] are EClass, EAttribute, EReference, and EDataType. XTEAM is intended for software architecture-based modeling, analysis, and code gen- eration. Therefore, the XTEAM metalanguage should be suciently exible to capture the range of abstractions and patterns commonly used for modeling software and systems architectures. A set of such abstractions and patterns is often referred to as a component model. A component model denes the types used to specify a component-based system and imposes rules that dene the well-formedness of component instances and assemblies. Component models dene the types of interfaces that a component may expose, the pat- terns of interaction between components and their run-time environments, and so on. 29 For example, component-based middleware platforms, such as the CORBA Component Model and Java EE, explicitly dene and adhere to a component model. Similarly, a product-line architecture is, in essence, a component model to which individual prod- ucts within the product line must adhere. Architectural styles, such as client-server or publish-subscribe, are also component models. To arrive at an initial set of core metatypes for the XTEAM implementation, a liter- ature review was used to factor out the common elements within a variety of component models. This exercise initially identied the following metatypes: architecture, com- ponent, resource, interface, link, implementation, task, datatype, and property. These metatypes are described in detail in Chapter 3. Embedding Semantic Assumptions Once a set of core metatypes has been chosen, the next task is to attach partial seman- tics to each metatype. Automatically synthesized model interpreters will assume that these partial semantics hold for all domain-specic types dened by an instance of the metatype. Crucially, the semantics of metatypes should be loosely dened and only incor- porate assumptions shared among a broad family of DSLs. Semantics that vary from one application context to another remain unspecied, and engineers are expected to specify these variable semantics using properties, as described below. Semantic assumptions have two positive aects on the MDE platform. First, seman- tic assumptions are automatically incorporated into a metamodel whenever a metatype is instantiated. Software engineers reuse the semantics implicitly when they specify the types in their DSLs, simplifying the XTEAM metamodeling process and metalanguage 30 and increasing the usability of the MDE platform as a whole. Second, semantic assump- tions are incorporated directly into XTEAM interpretation components, simplifying their implementations and increasing the scalability and eciency of the MDE platform. The use of semantic assumptions results in a tradeo between the ability to syn- thesize supporting toolsets and DSL exibility. One the one hand, attaching additional semantics to metatypes increases the space of possible model editors, analysis engines, and code generators that can be synthesized by an MDE platform. For example, current MDE platforms can synthesize model editors because their metatype semantics include visualization, presentation, and editing concerns, but they lack the semantics necessary to synthesize other types of tools. One the other hand, attaching additional semantics to metatypes decreases the space of possible DSLs that can be specied in an MDE platform. For example, if metatypes include xed semantics for graphical rendering and editing, they cannot be used to specify a textual language (at least, not in any straight- forward or intuitive way). One possible approach to arriving at a set of semantic assumptions is co-rene- ment [66]. Co-renement begins with an initial candidate set of metalanguage semantics (e.g., the semantics re ecting the well-understood constructs and abstractions underlying architecture-based software development [126]) and target platform semantics (e.g., the semantics of a middleware platform selected to implement the architectures). Expand- ing the metalanguage semantics strengthens restrictions on DSL denition, but weakens restrictions on automated model interpreter generation; expanding the semantics of the target platform (if possible) has the inverse result. Thus, through an iterative process, the semantics of each can be brought into alignment. 31 Attaching Semantic Properties In addition to embedded semantic assumptions, XTEAM attaches semantics to metatypes through properties. Properties are typed attributes and associations with other meta- types. In contrast to semantic assumptions, metatype properties are used to capture domain-specic semantics that vary from one context to another. The semantics of a domain-specic type within a certain context can be automatically inferred from the property values of its metatype instance. The use of properties to infer domain-specic semantics implies that there is a nite set of dierent possible semantics from which software engineers can choose, and each possible combination of property values that may be assigned to a metatype instance implies a single semantics. Therefore, to dene appropriate metatype properties, the MDE platform developers must enumerate the set of possible semantics for each metatype and specify a mapping from property values to semantic options. The use of properties has the advantage that metamodel developers are not required to write intricate formal semantic specications using a complex notation such as Structured Operational Semantics [109]. Instead, software engineers can congure semantics using menus and automatically check properties for consistency. For example, the rendering of domain-specic types within the model editors of today's MDE platforms does not need to be specied because their rendering semantics are encoded within the properties of their metatypes. However, because the set of allowed properties for each metatype is xed by the metalanguage, the semantics that can be captured are restricted by the designer of the metalanguage (i.e., the MDE platform developer). 32 2.1.3 Component Development The nal activity in the XTEAM process is development of the components within the MDE platform. First, some components must be developed regardless of the interpreta- tion capabilities supported, including a metamodel editor, a metaprogrammable model editor, and a model repository. The development of these components is not addressed in this dissertation. Second, for each interpretation capability, a metainterpreter and a model interpreter framework must be implemented. The next section discusses these components in the context of the XTEAM architecture. 2.2 Platform Architecture The XTEAM architecture is an extension of the canonical MDE platform architecture and includes both components that are provided by existing platforms as well as novel components that are not. Figure 2.2 depicts the roles and interactions of the MDE platform components that participate in analysis and code generation in XTEAM. In contrast to the canonical MDE platform architecture, each interpretation capability is implemented through a paired metainterpreter and model interpreter framework (MIF). The editing components of the XTEAM architecture operate similarly to existing MDE platforms. Metamodelers create a metamodel using the metamodel editor. When invoked, a metainterpreter produces a model editor framework extension. The model editor framework is congured with the framework extension to produce a domain-specic model editor. Application engineers create domain-specic application models using the domain-specic model editor. 33 The interpretation components of the XTEAM architecture | MIFs and their as- sociated metainterpreters | are not present in other existing MDE platforms. These metainterpreters take as input a metamodel that includes metatype properties needed to map domain-specic models a target semantic domain. The metainterpreter derives the semantics of domain-specic types from their metatype property denitions and deter- mines a set of rules for transforming each domain-specic type to the semantic domain. The metainterpreter encodes the transformation rules in an MIF extension for a specic MIF, which implements the actual transformation logic (e.g., operations and algorithms). The MIF extension, which may take the form of conguration les or plug-ins, modies, extends, and controls the functionality of the MIF using extension points built into the MIF. The extended MIF takes a domain-specic model as input and outputs an executable or analyzable model specied in the form required by the target semantic domain. Given the conceptual similarity between the mechanisms used for synthesizing editors and interpreters, it may seem obvious that domain-specic model interpreters can be syn- thesized using this metaprogramming mechanism. There are two primary reasons that MDE platform developers have not attempted to do so to date. First, MDE platform developers strove for maximum exibility. They assumed that the variety of problems to which their MDE platforms would be applied is much larger than just software architec- ture problems. Therefore, they designed their platforms such that they could be used for many DSLs other than software architecture DSLs. Operating on this assumption, the space of possible DSLs is so large that it is impossible to predict (1) the types of semantic information that will be needed in metamodels or (2) the types of model interpreters that will be useful. Therefore, they concluded that a model editor is the only common 34 Metamodel Editor Model Editor Framework Application Model MDE Platform Component Model Data Flow Generates Model Key Model Interpreter Framework Execution Environment Metamodel Type Definitions Presentation Definitions Execution Definitions Metainterpreter Metainterpreter Presentation Semantics Execution Semantics Presentation Rules Transformation Rules Executable Model Transformation Logic Metatype Properties Semantics Framework Extension Execution Logic Presentation Logic Figure 2.2: Overview of the XTEAM platform components for domain-specic modeling, analysis, and code generation. 35 tool among all domains. Second, MDE platform developers have been concerned that incorporating semantic denitions into metamodels would decrease usability. Noting the limited adoption of compiler-compiler technologies developed in past decades due to their dependence on complete formal semantic denitions [16], they believed that a mechanism that required such denitions would be dicult to use, error-prone, and not scalable. This dissertation contends that both of these reasons are misguided. With regard to the rst reason, it is indeed true that MDE platforms have been applied in an astounding variety of contexts. However, a huge proportion of those contexts are some form of software architecture modeling or software-intensive system architecture modeling. A model interpreter that is useful in many software architecture modeling contexts can achieve a high level of reuse. With regard to the second reason, it is again true that formal semantic denition languages are complex and hard to use. However, semantics can be can be captured in other, simpler ways. In fact, the method that existing MDE platforms use to capture information that denes how domain-specic objects behave in a model editor is a simple semantic denition mechanism, and has proven highly usable, scalable, and successful. This method is to embed semantic assumptions into metatypes and allow selection of semantic variability through metatype properties. Therefore, XTEAM (1) explicitly limits its intended scope to the space of software architecture modeling languages, and (2) utilizes metatype properties and assumptions to capture semantics. 36 2.2.1 Metainterpreters In XTEAM, each metainterpreter is responsible for synthesizing domain-specic model interpreters for a single semantic domain. A metainterpreter accomplishes this by con- trolling how model transformation operations, implemented in an MIF, are applied to domain-specic model objects. Notionally, an MIF can be thought of as a virtual machine whose instruction set is the set of implemented transformation operations. In this analogy, the metainterpreter is akin to a compiler whose function is to generate programs to be executed by the MIF virtual machine. Alternatively, the combination of the metainterpreter and MIF can be viewed as a compiler-compiler [2,16,56] that generates compilers for DSLs. For reasons of scalability and maintainability, MIFs in XTEAM are implemented as object-oriented frameworks that include extension points based on design patterns [46]. Extension points are utilized through subclassing and instantiation of particular objects. Therefore, metainterpreters generate classes and instructions that realize and exploit these design patterns. The primary functions of a metainterpreter are (1) deriving the semantics of each domain-specic type, and (2) realizing the semantics of each type in a set of transforma- tion rules. The semantics of each domain-specic type are selected from the set of possible semantics permitted by the MDE platform. Each possible semantics corresponds to a dif- ferent usage of MIF extension points. Therefore, a metainterpreter includes (1) a function that takes as parameters the property values of a metatype instance and returns a seman- tic denition from the set of possible semantics, and (2) a function that takes a semantic denition as a parameter and returns a set of MIF extension point usages. 37 2.2.2 Model Interpreter Frameworks In XTEAM, a model interpreter framework (MIF) is a template for constructing a family of model interpreters. In order to be useful, such a framework must encapsulate trans- formation logic or algorithms that (1) are useful in a wide variety of contexts and (2) can be exibly applied in dierent ways to achieve dierent semantics. As noted above, an MIF is conceptually analogous to a virtual machine that provides an instruction set composed of model transformation operations and executes programs over that instruction set. Transformation steps that only depend on embedded semantic assumptions (i.e., not metatype properties) are \hard-coded" into the MIF and are pro- tected from modication by MIF extensions. Transformation steps that vary based on metatype properties are \programmable" via an extension point. However, an MIF is not a library of functions; rather, it is an active component that can be extended and enhanced in specic, predened ways. Therefore, an MIF is best viewed as an application framework. Well-known design patterns, such as Strategy, Template Method, and Functor [55], can then be used to create extension points in the MIF. Classes and objects that exploit MIF extension points provide the missing part of the MIF and complete a domain-specic model interpreter. The rationale for implementing an MIF as an application framework, rather than as virtual machine, is threefold. First, an application framework achieves performance and scalability by internalizing program control logic and invoking application extensions, rather than being passively invoked by application control logic (this is known as inver- sion of control). Second, an application framework can strictly control the ways that 38 its behavior can be modied, and thereby ensure that assumptions (including embedded semantic assumptions) are not violated. Third, application frameworks are designed as a collection of loosely-coupled modules for maximum reuse; in the case of MIFs, this prop- erty reduces the impact of metalanguage changes by scoping the required modications. 2.3 Summary The XTEAM approach represents a set of enhancements to the standard MDE platform development approach that aim to provide o-the-shelf model interpretation capabilities. The XTEAM approach requires selecting a set of interpretation capabilities to support; dening or enhancing a metalanguage to incorporate embedded semantic assumptions and properties that are sucient to infer a mapping for each type, but still permit domain-specic semantic variability; and implementing a metainterpreter and MIF that leverage semantic assumptions and properties to synthesize domain-specic model inter- preters. Metainterpreters infer domain-specic semantics from metatype property values and generate rules for applying transformation operations to domain-specic model ob- jects. MIFs implement transformation operations in an object-oriented framework to ensure scalability, extensibility, and maintainability. 39 Chapter 3 The XTEAM Implementation The XTEAM implementation is an end-to-end MDE platform that leverages the XTEAM approach. The XTEAM implementation reuses several o-the-shelf components, includ- ing the metaprogrammable model editor of GME [58] (an open source MDE platform), the SVN version control system [3], and the Prism-MW lightweight architectural middleware platform [88]. The custom-built components of XTEAM are: A metamodel editor created through conguration of the GME model editor with the XTEAM metalanguage. A metainterpreter that congures the GME model editor based on XTEAM meta- models. A metaprogrammable MIF, called the XDEVS MIF, that generates discrete event simulations implemented in C++ that run in the XDEVS discrete event simulation engine. A metaprogrammable MIF, called the Prism-MW MIF, that generates application code implemented in Java that runs on the Prism-MW middleware platform. 40 A metainterpreter, called the XDEVS metainterpreter, that generates extensions for the XDEVS MIF from XTEAM metamodels. A metainterpreter, called the Prism-MW metainterpreter, that generates extensions for the Prism-MW MIF from XTEAM metamodels. Figure 3.1 depicts these components, along with the open-source and o-the-shelf components in the toolset. XTEAM metamodels and application models are stored in XML format in an SVN repository. XTEAM metamodels are created and modied in the XTEAM metamodel editor, which was created by conguring GME's model editor with the XTEAM meta-metamodel (i.e., specication of the XTEAM metalanguage in GME). Once a metamodel has been created, the XTEAM metainterpreters can be invoked to automatically synthesize (1) a domain-specic model editor (the GME model editor con- gured for an XTEAM DSL), (2) a domain-specic XDEVS simulation generator (the XDEVS MIF congured with an extension), and (3) a domain-specic Prism-MW applica- tion generator (the Prism-MW MIF congured with an extension). XTEAM application models are created and modied in a domain-specic model editor. Once an application model has been created, the domain-specic simulation generator and domain-specic application generator can be invoked to automatically synthesize XDEVS simulations and Prism-MW applications, respectively [42,43]. 3.1 Example Application The discussion in this chapter relies on an example application called the Lunar Lander to clarify key points. The Lunar Lander has been used as an instructional tool for a wide 41 Microsoft Windows/C++ GME Model Editor GME Model Editor Fedora Linux SVN Repository C++ Runtime JVM Prism-MW XTEAM Model XTEAM Model Data XTEAM Metamodel Off-the-Shelf Component GME Editor Metainterpreter XDEVS Metainterpreter Prism-MW Metainterpreter XDEVS MIF Prism-MW MIF XDEVS XTEAM Metalanguage XTEAM Component Platform/Language XDEVS MIF Extension Prism-MW MIF Extension Prism-MW Application XTEAM DSL XDEVS Model XTEAM Automatically Generated Component Model Data Flow Generates Model (built by application engineers) Key Figure 3.1: Component view of the XTEAM implementation. 42 variety of software architecture concepts, such as architectural styles, reference architec- tures, architecture description languages, and architectural analysis [126]. Consequently, many dierent variations of the Lunar Lander exist, spanning a wide range of sophisti- cation and complexity, which makes it a good candidate for demonstrating how XTEAM can model and analyze applications using a variety of DSLs. The Lunar Lander is a ight simulation game in which the user attempts to pilot a spacecraft to a safe landing on the moon. The player is able to control the thrust and direction of the spacecraft, and the game informs the player of the current status of the craft, including the altitude, velocity, and fuel level, through a heads up display (HUD). Most of the Lunar Lander variations consist of three top-level components, GameControl, GameInterface, and GameData, which contain a total of about 20 sub-components; some variations also include explicit software connectors [126]. Figure 3.2 shows top-level views of XTEAM models of two possible Lunar Lander variations. Variation (a) is modeled using the AADL notation [51], and variation (b) is modeled using the Java-based Myx architectural style [28]. As these screenshots suggest, XTEAM allows each variation to be modeled using the respective types, relationships, constraints, symbols, etc., of AADL and Myx. For example, AADL includes elements of the execution platform, such as data storage and processing devices, while Myx includes explicit connectors, such as the Proxy in the Lunar Lander model. Figures 3.3, 3.4, and 3.5 show the internal structure of the GameData, GameInterface, and GameControl components, respectively, in the Myx Lunar Lander model. This chapter uses the Myx version of the Lunar Lander to demonstrate concepts. The Myx architectural style is designed for composable, tool-integrating environments 43 (a) (b) Figure 3.2: The Lunar Lander application modeled in (a) AADL and (b) the Myx archi- tectural style. Figure 3.3: The internal structure of the GameData component of the Lunar Lander. 44 Figure 3.4: The internal structure of the GameInterface component of the Lunar Lander. Figure 3.5: The internal structure of the GameControl component of the Lunar Lander. 45 (particularly Eclipse [39]) and is intended to maximize exibility and decoupling. Myx borrows heavily from the C2 [125] and Weaves [61] architectural styles. Myx includes the following key elements [28]: Myx components implement capabilities or functions in applications by processing data and providing services. Myx connectors support the transfer of data and control. Myx components and connectors are collectively referred to as bricks. Myx applications have at least one main thread of control, but bricks may create additional threads. Myx interfaces act as portals through which bricks interact. Interfaces may be either synchronous or asynchronous | the invoker of a synchronous interface blocks until the invocation completes. Furthermore, each interface is designated as either provided or required | provided interfaces are used to expose services, while required interfaces are used to access services. Finally, the interfaces of each brick are assigned to either the brick's top domain or bottom domain, which is used to induce layering. All interfaces are dened by a set of Java method signatures. All data exchanged across interfaces must be serializable. Myx links are connections between interfaces. Links are non-directional | the di- rection of ow along the link is dictated by the associated interfaces. Each link con- nects exactly two interfaces. The following types of connections are permitted: syn- chronous top-to-bottom (procedure call), asynchronous top-to-bottom (request), and asynchronous bottom-to-top (notication). Therefore, synchronous required interfaces are always in the top domain, synchronous provided interfaces are always 46 in the bottom domain, and asynchronous interfaces may be in either domain. A top-to-bottom link is an upward link and a bottom-to-top link is downward link (although this might seem backwards at rst). Therefore, synchronous invocations are always upward. Finally, links cannot create cycles or connect a brick to itself. The next section shows how all the elements and constraints of the Myx style were specied in an XTEAM metamodel. 3.2 Metamodeling Metamodels in XTEAM are designed to include sucient semantics to infer mappings of DSL types to particular semantic domains. This is achieved through the use of a meta- language that includes mechanisms for the specication of semantics. As prescribed by the XTEAM approach, the XTEAM metalanguage (1) is founded on canonical architec- tural constructs, (2) associates semantic assumptions with metatypes, and (3) includes metatype properties that capture semantic variability [45]. This section describes the XTEAM metalanguage in terms of its constituent metatypes, and enumerates the em- bedded assumptions and properties of each metatype. Figure 3.6 depicts the XTEAM metatypes and their properties (attributes and asso- ciations). Pertinent to the chosen domain, an architecture denes an executable system as an assembly of components, resources, and other types, as well as their relationships and conguration. A component denes a reusable package of service interfaces and encapsulates computation and data that realize those services. Each interface denes 47 signature output input mapping connection state port platform functionality domainProperty behavior application destination source Architecture Resource Component form DataType Interface control synchronous queuing delay capacity loses routing Link type Property class units protocol name Entity definition entrant Task Implementation composite model opaque instantiable Operation Figure 3.6: The XTEAM metatypes and their properties. a component interaction point in terms of data exchange and transfer of control. Im- plementations capture computational logic and program state in terms of sequences of instructions, state-transition systems, and data objects. Links represent logical connec- tions among interfaces over which information and/or control is exchanged. Resources are entities provided by the application execution environment that are utilized by com- ponents to manipulate, store, and transmit information. Finally, data types represent objects exchanged between components or maintained as part of a component's state. The semantic assumptions embedded in XTEAM metatypes can be categorized as capabilities and responsibilities, which are inherited by all instances of the metatype. Ca- pabilities describe behaviors (e.g., services and functions) that instances of the metatype 48 exhibit by default in the semantic domain, independent of the metamodel | these be- haviors do not need to be specied in application models. The logic that realizes capabilities must be either implemented \natively" in the target semantic domain or the MIF must generate this logic. Responsibilities dene the minimal information required to map the instances of the metatype to the semantic domain, independent of the metamodel | these behaviors must be specied in application models. To illustrate this, consider the fragment of the XTEAM metamodel for Myx shown in Figure 3.8. The gure shows that the MyxComponent and MyxConnector types | instances of which appear in the Lu- nar Lander model of Figure 3.2(b) | are themselves instances of the XTEAM Component metatype. This species that run-time instances of MyxComponent and MyxConnector | such as the GameControl and Proxy objects in the Lunar Lander | have the capabilities and responsibilities of all XTEAM Components. For example, these components have the capability to send messages to and invoke the services of other components. Similarly, these components have the responsibility to either specify a sub-architecture (dening a set of subcomponents and their connections) or an implementation (dening a set of concrete behaviors in the form of executable instructions). It is the dened capabilities and responsibilities of XTEAM metatypes, along with their property values, that makes their domain-specic instances automatically processable by MIFs. The properties specied for each XTEAM metatype (along with embedded semantic assumptions) dene semantic mappings to a set of graphical display elements in the model editor, a set of simulation objects that run in XDEVS, and a set of application objects that run on Prism-MW. The way instances of a domain-specic type are mapped to each 49 of these semantic domains depends on the values assigned by the metamodeler to the properties of the metatype instance that denes the domain-specic type. For example: The icon property is dened for all the core XTEAM metatypes. The presentation semantics of the icon property specify that instances of the relevant type will be rendered in the editor using the image given by the value of the attribute. Since the properties used to dene presentation semantics are adopted from GME, they are not discussed further in this dissertation, and are not shown in Figure 3.6. The units property is dened for the Resource metatype. The value of the units property determines whether instances of a resource type will be simulated as a group of distinct XDEVS resources (e.g., a thread pool) or a single divisible XDEVS resource (e.g., a capacity-limited data store). The composite property is dened for the Component metatype. The value of the composite property (along with other properties) determines whether instances of a component type are implemented as a Prism-MW Component or ExtensibleCom- ponent. Some properties are relevant to only one semantic mapping, while others are used for two or all three. In many cases, a semantic variation is derived from the values of multiple properties; dierent combinations of property values create dierent mappings. All the properties of the XTEAM metalanguage, including the above examples, are described in detail below in the context of each metatype. Note that there is also a Property metatype in the XTEAM metalanguage. This metatype should not be confused with the properties of the other metatypes, such as 50 those mentioned above: the Property metatype species an attribute or association of a domain-specic type. For example, direction is a domain-specic attribute of the MyxLink type in the Myx DSL. Values are assigned to the domain-specic properties of instances at the modeling level (i.e., within application models). 3.2.1 Architecture Metatype Each instance of the Architecture metatype in a metamodel denes a type of domain- specic component execution environment. Architectures provide containers for compo- nents, logical links among component interfaces, and resources that execute component implementations. Therefore, an architecture assembles other elements into a complete system. The types of components, links, and resources supported by (allowed to exist within) a given type of architecture are part of the architecture's domain-specic type denition. A fully-specied architecture represents an executable system. \Win32 ap- plication," \sensor network," and \web site" are possible examples of domain-specic architecture types. Capabilities: Every architecture type includes, by default, the ability to instantiate constituent components, connect the interfaces of components by instantiating links, and retrieve references to all provided resources. Also, architectures have the ability to create new instances of resources that are designated as instantiable. Responsibilities: Architectures must provide all resources required by component implementations (it is a responsibility of implementations to declare the resources they require). Properties: 51 <<platform>> <<platform>> <<application>> <<connection>> MyxBrick <<Component>> MyxApplication <<Architecture>> MyxLink <<Link>> JavaThread <<Resource>> JavaFile <<Resource>> 1..* 0..* 1..* 0..* Figure 3.7: Denition of the MyxApplication domain-specic architecture type. application: Denes the types of components that may be instantiated/deployed in the architecture. connection: Species the types of links that may be established in the architecture. platform: Designates the types of resources that may be provided in the architec- ture. Example: Figure 3.7 shows an example architecture type denition from the Myx metamodel. A MyxApplication is a system assembled from MyxBricks, MyxLinks, Java- Threads, and JavaFiles. A MyxApplication must include at least one MyxBrick and at least one JavaThread. 52 3.2.2 Component Metatype Each instance of the Component metatype denes a domain-specic component type. A component is an independently deployable and instantiable unit of computation and information. Components encapsulate reusable blocks of logic and data in the form of component implementations and dene interaction points between implementations and external entities in the form of interfaces. Domain-specic type denitions for components specify compatible implementation and interface types. \JavaBean," \web server," and \COM object" are possible examples of domain-specic component types. Capabilities: Components have the ability to manage and prioritize interactions between internal implementations and external links. An interaction event occurs when- ever components communicate. For example, a method call returning, a message being sent, a shared object being modied, and a semaphore being released are all interactions. Components may multiplex/demultiplex, lter, and monitor interactions. Components also have the ability to delegate externally initiated interactions to component implemen- tations and transmit internally initiated interactions to external entities via established links. Responsibilities: First, every component must specify a mapping from each im- plemented interface to either the type-equivalent interface of a sub-component or a set of tasks that implement the provided service. Second, components must have access to links to all interfaces that it invokes. Third, components must ensure all interaction takes place via interfaces and must protect internal information and behavior from being manipulated directly. 53 Properties: port: Species the types of interfaces through which the component's implemen- tation(s) may interact. Each port is assigned a direction: implements or invokes. The direction determines the allowed modes of interaction and ow of information across the interface (this is elaborated fully under the Interface metatype below). functionality: Designates the types of implementations that may be used to realize the component's provided services. composite: Indicates that the component is a hierarchy of subcomponents. Example: Figure 3.8 shows example component type denitions from the Myx meta- model. MyxBrick is an abstract base type, while MyxComponent and MyxConnector are concrete subtypes. A MyxBrick may implement MyxProvidedInterfaces and invoke MyxRequiredInterfaces. One or more JavaClasses dene the behavior of a MyxBrick. MyxBricks run in MyxApplications. 3.2.3 Interface Metatype Each instance of the Interface metatype denes a type of domain-specic component interaction point. Interfaces specify collections of operations. Operations, in turn, specify data exchanges in terms of strongly typed inputs and outputs (e.g., parameters and return values). Operations also specify control exchanges in terms of passed execution threads. The domain-specic type denition for an interface restricts the allowed types of data and control exchanges. \HTTP port," \publish-subscribe API," and \web service interface" are possible examples of domain-specic interface types. 54 <<application>> <<functionality>> MyxBrick <<Component>> MyxComponent <<Component>> MyxConnector <<Component>> <<port>> MyxProvidedInterface <<Interface>> direction=implements <<port>> MyxRequiredInterface <<Interface>> direction=invokes JavaClass <<Implementation>> MyxApplication <<Architecture>> composite=true 0..* 0..* 1..* 1..* Figure 3.8: Denition of the MyxBrick domain-specic component type. As noted above, the relationship between an interface and a component has a des- ignated direction of either implements or invokes. The interface direction aects the semantics of the interface in several ways. First, the ow of information in the two di- rections is opposite: an invoking component sends the interface's inputs and receives its outputs; an implementing component receives the inputs and sends the outputs. Second, the mode of interaction | either method-based or message-based | is derived from the directions of the interfaces that are connected via given link: method-based interactions occur when an invoked interface (e.g., an object reference) is linked to an implemented interface (e.g., an object), while message-based interactions occur when two invoked in- terfaces are linked (e.g., two send-message/receive-message interfaces). Capabilities: Interfaces ensure type conformance, mode conformance, and control conformance. Type conformance implies that exchanged data adheres to input and output 55 data type denitions. Mode conformance implies that the participants in an interaction are uniformly method-based or message-based. Control conformance implies that an execution thread is transferred from the source of an interaction to the target of an interaction if and only if both the source and target interfaces expect it. Interfaces also have the ability to block an execution thread to create synchronous interactions. Responsibilities: Every interface must declare at least one operation. Properties: signature: Indicates the operation types that may be specied by the interface type. control: Enables exchange of control ow across the interface type (e.g., the caller passes a thread which is returned by the callee). This property is used to dieren- tiate interface types over which an execution thread may pass (e.g., a Java method call). synchronous: Forces synchronization across the interface; the interface invoker(s) and invokee(s) experience interactions simultaneously. Note that an interface may be synchronous but not result in exchange of a thread of control. queuing: Allows queuing of interactions over the interface. This property must be enabled for asynchronous interfaces. Example: Figure 3.9 shows example interface type denitions from the Myx meta- model. MyxInterface is an abstract base type for all other interfaces. A MyxInterface declares one or more JavaMethodDecl operations. A MyxSynchronousInterface passes 56 MyxSynchronousInterface <<Interface>> synchronous=true queuing=false control=true MyxAsynchronousInterface <<Interface>> synchronous=false queuing=true control=false <<signature>> JavaMethodDecl <<Operation>> MyxInterface <<Interface>> 1..* Figure 3.9: Denition of the MyxSynchronousInterface and MyxAsynchronousInterface domain-specic interface types. a thread of control, the invoker and invokee experience interactions simultaneously, and interactions cannot be queued. A MyxAsynchronousInterface does not pass a thread of control, the invoker may initiate an interaction that is experienced by the invokee later, and interactions may be queued. 3.2.4 Link Metatype Each instance of the Link metatype denes a type of domain-specic connection between interfaces. A link represents a communication medium over which information may ow. Links designate each connected interface as either a source or a destination. Sources and destinations may be m-to-n; a link may have multiple sources and/or destinations. The types of interfaces that may be connected by a given type of link and the types of architectures in which the link may exist are included in the domain-specic type denition. \OSGi weld," \TCP connection," and \shared memory" are possible examples of domain-specic link types. 57 Capabilities: Links have the ability to route data between sources and destinations, possibly considering the operations, modes, and past interactions of interfaces. Links also may impose delays (e.g., transmission delay) and alter exchanged data (e.g., corrupt messages). Responsibilities: Links that impose a delay must specify a function or algorithm for computing the delay for each interaction. The function may utilize information about the interaction in question, the current or past state of the link, etc. Links that have a maximum capacity must specify the behavior that occurs when the link is saturated (common behaviors are to drop the rst or last interaction). Links that perform routing must specify whether type routing or identity routing is used. Type routing determines the destination(s) of an interaction based on the source input and output data types. Identity routing uses a handle or identier held by the source to nd matching destinations. Properties: source and destination: Dene the interface types that are permitted to be a source or destination of the link type, respectively. delay: Imposes delay (latency) across the link. When delay is enabled with syn- chronous interfaces, both sources and destinations experience the event after the delay has occurred. capacity: Establishes a limit on the amount of data the link can transmit. The limit is specied as a rate for links with delay and a volume for links with no delay. routing: Allows routing over the link, in cases where the link is m-to-n. 58 <<destination>> <<source>> <<connection>> MyxApplication <<Architecture>> <<destination>> <<source>> delay=true capacity=false routing=false MyxLink <<Link>> 1 1 MyxProvSyncIntf <<Interface>> MyxReqSyncIntf <<Interface>> MyxSyncLink <<Link>> MyxAsyncLink <<Link>> MyxProvAsyncIntf <<Interface>> MyxReqAsyncIntf <<Interface>> 0..* 1 1 Figure 3.10: Denition of the MyxLink domain-specic link type. Example: Figure 3.10 shows example link type denitions from the Myx metamodel. MyxLink is an abstract base type. MyxLinks impose a small communication delay (that of a Java method call). MyxLinks do not have a maximum capacity because Java allows multiple threads to concurrently invoke a single object. Therefore, multiple invocations of a required interface of a single Myx brick instance cause multiple threads to execute the implemented behavior of the corresponding provided interface. MyxLinks do not per- form routing. The MyxSyncLink concrete subtype connects exactly one MyxReqSyncIntf to exactly one MyxProvSyncIntf, while the MyxAsyncLink type connects exactly one MyxReqAsyncIntf to exactly one MyxProvAsyncIntf. This imposes the constraints that required interfaces must be connected to provided interfaces, synchronous interfaces must be connected to other synchronous interfaces, and asynchronous interfaces must be con- nected to other asynchronous interfaces. 59 3.2.5 Resource Metatype Each instance of the Resource metatype denes a type of domain-specic resource. Re- sources are provided by the computing environment and are used by implementations to perform tasks. Resources require some amount of simulated time in order to fulll task requests, and it is contention over resources that results in the emergent behavior of applications. Each resource may optionally permit an arbitrary level of parallelism | a resource may be capable of servicing multiple requests simultaneously. Resources may be processing resources (e.g., CPUs or threads), communication resources (e.g., network interfaces), or data resources (e.g., les or buers). Capabilities: Resources automatically accept, queue, execute, and return service requests. Resources schedule requests according to a rst-in-rst-out (FIFO) discipline, manage the allocation of pooled or divisible resources to requests, and maximize request execution parallelism as allowed by the metatype property specication. Responsibilities: Resources are required to specify the available quantity of the resource (the capacity), which may be a positive real number if the resource is continuous or a natural number if the resource is discrete. Continuous resources provide a divisible amount of service execution capacity, that may be allocated in any size block. For exam- ple, bandwidth may be modeled as a continuous resource. Discrete resources provide a quantity of indivisible units, which can only be allocated in whole. Threads in a thread pool are an example of a discrete resource. Resources must also specify a scheduling discipline if FIFO is not appropriate. Properties: 60 class: Species whether the resource is a computation (processing) resource, a communication resource, or an information (data) resource. Computation resources service requests simultaneously up to the capacity; the capacity of a computation resource is always a natural number. However, an individual request cannot be serviced in parallel (e.g., two computation resource units cannot service a single request in half the time). Communication resources, on the other hand, always utilize their full capacity. Thus, a given request will execute twice as fast if twice as many units of the communication resource are available. Information resources can service an innite number of read requests simultaneously, but must block all other requests to service a write request. units: Denes whether the units of the resource are continuous or discrete. protocol: Allows the resource to exhibit holding behavior, in which the resource is held until released by the service requester. This allows component implementations to acquire multiple resources simultaneously. instantiable: Permits the resource to be created on demand. Example: Figure 3.11 shows two example resource type denitions from the Myx metamodel. Both JavaThreads and JavaFiles can be utilized by components in MyxAp- plications. JavaThreads perform computational tasks such as processing data. Each thread cannot be divided among multiple tasks simultaneously, so the units property is set to discrete. JavaFiles may be used to perform information storage and retrieval tasks. A le can be subdivided so that multiple tasks can be performed simultaneously. Both 61 <<platform>> <<platform>> MyxApplication <<Architecture>> JavaThread <<Resource>> JavaFile <<Resource>> class=computation units=discrete protocol=holding instantiable=true class=information units=continuous protocol=holding instantiable=true 1..* 0..* Figure 3.11: Denition of the JavaThread and JavaFile domain-specic resource types. JavaFiles and JavaThreads can be held while a task acquires other needed resources and can be created on demand. 3.2.6 Implementation Metatype Each instance of the Implementation metatype denes a type of domain-specic compo- nent implementation. An implementation is a set of concrete behaviors corresponding to the services it implements. Behaviors are described as sequences of tasks with arbitrarily complex, programmer-dened control ow. Tasks are initiated whenever a message or interface invocation is delegated to the implementation, or when an interface of another component invoked by the implementation returns. \Java class," \CORBA servant," and \Apache HTTP Server" are possible examples of domain-specic implementation types. Capabilities: Implementations automatically send service requests to all resources required to perform an executing task. If simultaneous resource access is required, the implementation tracks which resources are currently held and releases them once the task has completed. 62 Responsibilities: Every implementation must specify all resource dependencies that the implementation expects its execution environment (represented by an architecture) to satisfy. Properties: behavior: Denes the types of tasks performed by the implementation. state: Species the types of data objects that may be part of the implementation's state. All tasks within an implementation have a shared state. binding: Restricts the types of resources that the implementation can or must utilize in order to perform its tasks. This property can be used to ensure that an implementation only utilizes appropriate resources. model: The programming model used to dene the implementation behavior. Cur- rently, routine-based and event-based programming models are supported. opaque: Indicates whether the control ow among tasks and input/output depen- dencies in the implementation are specied; in other words, whether the implemen- tation is a \black box". In an opaque implementation, the modeler is free to initiate arbitrary tasks and invoke arbitrary interfaces implicitly in task denitions. In a non-opaque implementation, causality among tasks, inputs, and outputs must be explicit. Including this information in a model enables many types of analysis that cannot be performed otherwise. However, it can be bypassed if doing so would be burdensome or analysis that utilizes this information is not required. 63 <<state>> <<behavior>> <<binding>> <<binding>> <<functionality>> MyxBrick <<Component>> JavaClass <<Implementation>> composite=true model=routine opaque=true JavaThread <<Resource>> JavaFile <<Resource>> JavaMethod <<Task>> JavaObject <<DataType>> 1..* 1..* 0..* 0..* 1..* Figure 3.12: Denition of the JavaClass domain-specic implementation type. Example: Figure 3.12 shows an example implementation type denition from the Myx metamodel. A JavaClass provides the executable specication for a MyxBrick. JavaClasses utilize JavaThreads and JavaFiles to execute instructions and store data. The behavior of a JavaClass is given by a set of JavaMethods (the class methods), and the state of a JavaClass is dened by a set of JavaObjects (the class member variables). JavaClasses use the routine-based programming model and are designated as opaque so that application engineers can put arbitrary programming language statements in task denitions. 3.2.7 Operation Metatype Each instance of the Operation metatype denes a type of domain-specic service access point in terms of data and control exchange. Operations may be grouped together within an interface (i.e., an interface may dene multiple operations). \C++ method signature," 64 <<mapping>> returnValue <<output>> <<signature>> parameter <<input>> JavaObject <<DataType>> 0..1 0..* JavaMethodDecl <<Operation>> JavaMethod <<Task>> MyxInterface <<Interface>> 1..* 0..* Figure 3.13: Denition of the JavaMethodDecl domain-specic operation type. \XMLHttpRequest," and \event callback" are possible examples of domain-specic op- eration types. Responsibilities: Operations must specify a type and identier for each input and output (or parameter and return value), although operations may have zero inputs and outputs (e.g., a method with no parameters and no return value). Properties: input and output: Dene the data types that are permitted to be the respective inputs and outputs to the operation type. Example: Figure 3.13 shows an example operation type denition from the Myx metamodel. A JavaMethodDecl takes zero or more JavaObjects as input parameters and outputs zero or one JavaObject as a return value. 3.2.8 Task Metatype Each instance of the Task metatype denes a type of domain-specic task. Each task requires a set of resources, such as CPU time or le access, to execute. When a task is initiated, requests are sent to all required resources. Each resource schedules the 65 task's request according to its own scheduling policy. Once all resource requests have been satised, the task may perform computations, update the implementation's state, invoke required interfaces, or initiate other tasks within the implementation. Note that, by default, a task does not have to hold all required resources simultaneously | one resource request can be satised while other resource requests are blocking | although simultaneous resource access can be enabled. Capabilities: Tasks can perform computations and read and write to the state of the implementation in which they execute. Tasks can also initiate invocations of component interfaces and launch other tasks. Responsibilities: Tasks must specify their behavior, either as executable code snip- pets or as state transition diagrams. If the task is included in a non-opaque implemen- tation, it must dene the conditions under which it initiates other tasks or interactions. Tasks must also specify the service demand placed on each resource whenever the task is executed, which may depend on the implementation state, the input data, probabilistic values, and so on. Properties: mapping: Denes the types of operations that the task may perform. definition: Indicates whether the behavior of the task is modeled as a state transition diagram or as a code snippet. entrant: Species whether the task may be executed simultaneously by multiple dierent resources. 66 JavaMethod <<Task>> definition=code entrant=true <<mapping>> JavaMethodDecl <<Operation>> 0..1 <<behavior>> JavaClass <<Implementation>> 1..* Figure 3.14: Denition of the JavaMethod domain-specic task type. Example: Figure 3.14 shows an example task type denition from the Myx meta- model. A JavaMethod executes when a corresponding JavaMethodDecl is invoked (not all JavaMethods are mapped to a JavaMethodDecl because some methods may be pri- vate). JavaMethods are dened by code snippets, and may be executed simultaneously by multiple threads. 3.2.9 DataType Metatype Each instance of the DataType metatype denes a type of domain-specic data. Data types store information and are used to represent the state of implementations and the messages and parameters exchanged during interactions. \C++ struct," \video stream," and \database table" are possible examples of domain-specic data types. Capabilities: Data types include the ability to copy themselves (for pass-by-value semantics) and provide a global reference to themselves (for pass-by-reference semantics). Responsibilities: Data types must dene their content in terms of other data types or primitive types (integer, string, boolean, enumeration, etc.). Data types must dene the size and value of instances, which may be real or simulated. For example, the size 67 <<state>> returnValue <<output>> parameter <<input>> JavaObject <<DataType>> 0..1 0..* JavaMethodDecl <<Operation>> JavaClass <<Implementation>> form=object 0..* Figure 3.15: Denition of the JavaObject domain-specic data type. of a data object can be randomly chosen from a distribution if real data values are not used, which is common in large-scale simulations. Properties: form: The form of the data; may be either object, stream, or relational. Object data is composed of structured units called elds. Information contained in object data is accessed by referencing individual elds. Stream data is composed of a continuous, one-dimensional body of data. Information in stream data is accessed by referencing a position in the stream. Relational data is composed of tables. Information in relational data is accessed by referencing rows, columns, or cells in the table. Example: Figure 3.15 shows an example data type denition from the Myx meta- model. A JavaObject is composed of a number of elds, which may be other Java objects or primitive types. 3.2.10 Example Metamodel The full Myx metamodel is shown in Figure 3.16. It integrates all the snippets given as ex- amples, and also includes several domain-specic properties: topDomain, bottomDomain, 68 direction, type, and serializable. All XTEAM properties are given one of the fol- lowing types: boolean, enum, string, integer, real, reference, or set. Reference properties are pointers to some other type specied in the metamodel. Set properties are collections of one of the other types. The topDomain and bottomDomain properties of MyxBrick are sets of references to MyxInterfaces, and designate which interfaces are in the top and bottom domains of each brick. The direction property of MyxLink is either upward or downward, and indicates whether the link is top-to-bottom or bottom-to-top. The type property of MyxAsynchronousInterface is either request or notification, and (redundantly) implies the domain of the interface: required request interfaces are al- ways in the top domain, required notication interfaces are always in the bottom domain, etc. Finally, the serializable property of JavaObject species whether the object is serializable. The properties in the Myx metamodel enable the denition of additional constraints that capture the Myx style constraints not already embedded in the metamodel. These constraints are written as OCL [104] invariants and are enforced by GME's built-in con- straint manager. A sample of Myx metamodel constraints are listed in Figure 3.17; some other possible constraints are not listed (e.g., an interface cannot be in both the top and bottom domain of a brick). Obviously, many aspects of the Myx metamodel as given could be specied dierently. For example, some of the properties given are redundant | the same information is captured in multiple ways | which allows models to be double-checked for consistency but also requires some extra modeling work. Similarly, the inheritance hierarchy for 69 <<port>> <<destination>> <<source>> <<connection>> <<mapping>> returnValue <<output>> direction=implements <<signature>> parameter <<input>> JavaObject <<DataType>> MyxAsynchronousInterface <<Interface>> 0..1 0..* JavaMethodDecl <<Operation>> <<state>> <<behavior>> <<binding>> <<binding>> <<functionality>> MyxBrick <<Component>> JavaClass <<Implementation>> composite=true model=routine opaque=true <<platform>> <<platform>> MyxApplication <<Architecture>> JavaThread <<Resource>> JavaFile <<Resource>> class=computation units=discrete protocol=holding instantiable=true class=information units=continuous protocol=holding instantiable=true <<destination>> <<source>> delay=true capacity=false routing=false MyxLink <<Link>> 1 1 <<application>> MyxComponent <<Component>> MyxConnector <<Component>> <<port>> direction=invokes MyxRequiredInterface <<Interface>> MyxProvidedInterface <<Interface>> MyxProvSyncIntf <<Interface>> MyxReqSyncIntf <<Interface>> JavaMethod <<Task>> synchronous=false queuing=true control=false MyxSynchronousInterface <<Interface>> synchronous=true queuing=false control=true definition=code entrant=true MyxSyncLink <<Link>> MyxAsyncLink <<Link>> MyxProvAsyncIntf <<Interface>> MyxReqAsyncIntf <<Interface>> form=object MyxInterface <<Interface>> 1..* 0..* 1..* 0..* 0..* 0..* 1..* 1..* 1..* 0..* 0..* 1..* 0..1 type=set<MyxInterface> topDomain <<Property>> type=enum {upward, downward} direction <<Property>> type=enum {request, notification} type <<Property>> type=set<MyxInterface> bottomDomain <<Property>> type=boolean serializable <<Property>> 1 1 Figure 3.16: The XTEAM metamodel for the Myx architectural style. 70 Constraint Description Contextual Classifier OCL Invariant A link cannot connect a brick to itself. MyxLink inv self.source.myxBrick <> self.destination.myxBrick All data exchanged across interfaces must be serializable. JavaMethodDecl inv self.input.forAll( p | p.javaObject.serializable) and self.output.javaObject.serializable Synchronous required interfaces are only permitted in the in the top domain. MyxReqSyncIntf inv self.invokes.forAll( i | i.myxBrick.topDomain.includes(self)) Synchronous provided interfaces are only permitted in the bottom domain. MyxProvSyncIntf inv self.implements.forAll( i | i.myxBrick.bottomDomain.includes(self)) Synchronous links are only permitted in the upward direction. MyxSyncLink inv self.source.myxBrick.topDomain.includes( self.source) and self.destination.myxBrick.bottomDomain.includes( self.destination) Required request interfaces are only permitted in the top domain. MyxReqAsyncIntf inv self.type = #request implies self.invokes.forAll( i | i.myxBrick.topDomain.includes(self)) Required notification interfaces are only permitted in the bottom domain. MyxReqAsyncIntf inv self.type = #notification implies self.invokes.forAll( i | i.myxBrick.bottomDomain.includes(self)) Upward asynchronous links are only permitted between request interfaces. MyxAsyncLink inv self.direction = #upward implies (self.source.type = #request and self.destination.type = #request) Downward asynchronous links are only permitted between notification interfaces. MyxAsyncLink inv self.direction = #downward implies (self.source.type = #notification and self.destination.type = #notification) Figure 3.17: The XTEAM metamodel constraints for the Myx architectural style. 71 interfaces could be structured dierently and achieve the same goals. The metamodel given is only intended to be a demonstration of XTEAM's metalanguage. 3.2.11 Summary The XTEAM metatypes | Architecture, Component, Interface, Link, Resource, Implementation, Operation, Task, DataType, and Property | can be used to spec- ify domain-specic architecture modeling languages. DSLs specied using the XTEAM metatypes are subject to semantic constraints in some respects, but are free to exhibit a variety of semantics in other respects. The degree of permitted semantic variability is a consequence of the capabilities and responsibilities assigned to each metatype and the exibility of the metatype properties. 3.3 Interpretation Interpretation in XTEAM is achieved through automatically generated domain-specic model interpreters. As already described, domain-specic interpreters are generated by conguring a model interpreter framework (MIF) with a domain-specic extension gener- ated by a corresponding metainterpreter. Each such metainterpreter-MIF pair generates domain-specic interpreters for a single semantic domain. The XTEAM implementation contains two such pairs: one for the XDEVS discrete event simulation engine and one for the Prism-MW lightweight middleware platform. The XDEVS and Prism-MW metain- terpreters and MIFs share a set of core design solutions. Since the purpose of the XTEAM implementation is to serve as reference and demonstration for MDE platform develop- ers utilizing the XTEAM approach, this section focuses on these shared design solutions 72 and describes them in terms of a generic metainterpreter and MIF, rather than focusing on particulars of either the XDEVS or Prism-MW metainterpreters and MIFs. All the implementation details described in this section apply to both metainterpreter-MIF pairs. To use XTEAM, rst a metamodel and domain-specic model are created using the editor components of the toolset. Internally, each XTEAM model (and metamodel) is dened by a network of C++ objects. When the metainterpreter is invoked, it takes an XTEAM metamodel as input, derives the simulation semantics or application semantics of DSL types, and produces an MIF extension as output. MIF extensions are implemented as C++ plug-in classes. The MIF extensions are compiled into the MIF, also implemented in C++, to produce a domain-specic XDEVS or Prims-MW code generator. This domain- specic interpreter takes a domain-specic model as input and produces either an XDEVS simulation or Prism-MW application as output. Both an XTEAM metainterpreter and an XTEAM-generated domain-specic model interpreter are structured as two distinct modules: one for model traversal, and another for code generation. The modularization of traversal and code generation functions has been termed the visitor-traverser style, and is commonly used to increase the understand- ability and maintainability of programs that perform actions on a network of objects [74]. XTEAM leverages and extends this style to make code generation adaptable for dierent DSLs. The high-level design of an XTEAM model interpreter is shown in Figure 3.18. In both a metainterpreter and a domain-specic interpreter, the model traversal module contains the logic for navigating through the model (or metamodel) and invoking the code generator on each model object. In a domain-specic interpreter, this module is provided 73 Model Object Network Model Interpreter Model Traversal Module Perform traversal Invoke code generator Code Generation Module Component Visitor Link Visitor Interface Visitor Figure 3.18: Conceptual depiction of XTEAM model interpreter functions. by (built into) the MIF on which the interpreter is based. The code generator modules of a metainterpreter and a generated domain-specic interpreter are dierent. The code generation module of a metainterpreter is a relatively straightforward implementation of the Visitor pattern [55]. The code generation module of a domain-specic interpreter also leverages the Visitor pattern, but it consists of two distinct sets of classes that operate at dierent levels of the type system. One set of classes are built into the MIF and operate on metatypes, while the other set of classes are dened in the automatically generated MIF extension and operate on domain-specic types. The former set of classes implement code generation operations. The latter set of classes encode rules for applying those operations. Thus, the code generation module of an XTEAM-generated domain- specic model interpreter is a combination of MIF classes and automatically generated classes. 74 3.3.1 Metainterpreter Implementation The traversal module of an XTEAM metainterpreter species the sequence in which to visit objects representing metatype instances in a metamodel. The traversal sequence could potentially vary among metaintepreters in general. For example, some metainter- preters might use a top-down approach, while others process objects bottom-up. How- ever, both the Prism-MW and XDEVS metainterpreters process metamodels top-down, allowing this code to be reused. The traversal module is initialized with an object repre- senting the metamodel root. Starting with the root object, the traversal module navigates through the metamodel object network, successively invoking the code generation module on each object. For each type of object (that is, each metatype), the traversal module is encoded with instructions prescribing the next objects to be traversed. The code generator module of an XTEAM metainterpreter must examine each meta- type instance in a metamodel, determine the semantics of that instance, and specify what operations (implemented in the MIF) to invoke to generate the appropriate code. This is achieved in the following way. A visitor method generates MIF extension code for each metatype. Each possible point of variability that can be accommodated by the MIF is designated as a decision point. For example, the choice of whether or not to generate code that queues interactions arriving on an interface is a decision point. In general, decision points could include the use of optional operations or selection from a set of alternative operations. For each decision point, a method is implemented that determines the appropriate choice based on the metamodel. Most decision points have a small number (two or three) possible choices, so in many cases, the decision can be derived 75 through a relatively straightforward mapping of some set of property values to a choice. For example, the decision of whether or not to generate queuing code for an interface is a binary one that is derived from a single property value. Other decision points are more complex. For example, the determination of whether an interface is method-based or message-based requires examining the types of links that connect the interface. Complex semantics like mode of interaction can be determined once and then taken into account at numerous decision points. The output of the code generator module is a C++ class for each metatype instance. The generated class includes all the instructions for generating the dierent parts of the output | header les, method implementations, etc. Dierent concerns are encapsulated within dierent methods. For example, the class generated for a domain-specic link type includes separate methods for generating code that initializes the link and code that implements the relaying behavior of the link. These methods do not necessarily correspond exactly with decision points | most methods include multiple decision points. Figure 3.19 shows a code snippet from the interface visitor method of the XDEVS metainterpreter code generator module. The visitor rst checks the mode of interaction of the interface type. If it is method-based, it generates a call to the MIF operation that generates XDEVS code to handle method returns by transferring control and return values back to the calling implementation object. 76 // Interface visitor method void XDEVSMetaVisitor::visitInterface(Interface * intf) { ... file << "Interface::generateTypeChecker();\n"; file << "Interface::generateMessageBuilder();\n"; if (intf->getInteractionType() == METHOD_BASED) { file << "Interface::generateReturnHandler();\n"; } ... } // Generated code for the domain-specific interpreter void MyxInterface::generateInvocationBehavior() { ... Interface::generateTypeChecker(); Interface::generateMessageBuilder(); Interface::generateReturnHandler(); ... } Figure 3.19: A code snippet from a metainterpreter code generator module showing a decision point based on derived semantics. 3.3.2 Domain-Specic Interpreter Implementation The traversal module of an XTEAM-generated domain-specic interpreter is implemented by an MIF. The traversal module performs two passes through the object network rep- resenting a domain-specic model in a top-down fashion. 1 The rst pass generates class denitions for all the types in a model. The second pass generates code that instantiates these types into an initial conguration and commences execution. The decision to place all model traversal code within the MIF, rather that generating this code and placing it in an MIF extension, preserves the property of inversion of control, which is a key dierentiator between an application framework and class library. An application framework controls the thread of execution, and invokes user-dened 1 Again, this refers to the XDEVS and Prism-MW MIFs; other MIFs could perform model traversal dierently. 77 code (or, in this case, generated MIF extension code), rather than the other way around. Inversion of control simplies usage of the framework. Since an MIF is a special case of application framework, it makes sense to adhere to this principle. In the case of MIFs, inversion of control simplies the implementation of metainterpreters. As previously alluded to, the code generation module of an XTEAM-generated do- main-specic interpreter incorporates, but goes far beyond, conventional usage of the Visitor pattern. Also, this module includes two groups of classes: one group that is built into the MIF, and one group that is dened in an MIF extension. Figure 3.20 depicts the function of the code generator module of a domain-specic interpreter. The MIF extension instantiates classes built into the MIF corresponding to each metatype, called metatype classes, and denes new classes corresponding to domain-specic types (shown as Design Solution 1). The metatype classes in the MIF provide default implementations of specic steps within interpretation algorithms in methods that can be easily reused according to domain-specic rules (Design Solution 2). The MIF implements the high- level structure of interpretation algorithms, but delegates the execution of the algorithms' steps to framework extensions through extension points (Design Solution 3). Each ex- tension point is used to generate code for a specic concern, such as link initialization, relaying behavior, and delaying behavior. Each of the three design solutions enumerated above is explained through a context, goal, challenge, solution, and example. The context reviews key aspects of the XTEAM or MDE approaches that are relevant to the particular design solution. The goal states a desired behavior or quality of the metainterpreter or MIF. The challenge details the obstacles to achieving the goal and explains why achieving the goal requires an innovative 78 Link Visitor Component Visitor Extension Domain-Specific Interpretation Domain-Specific Interpretation Interface Visitor Interface Visitor Extension Link Visitor Extension Metamodel Interpreter Metamodel Domain-Specific Model Framework Extension Execution Environment Executable Model Derivation of Semantics Domain-Specific Model Interpreter Model Interpreter Framework Extension Points Domain-Independent Interpretation Domain-Independent Interpretation Component Visitor Generates Input Generates Input Design Solution 3 Design Solution 1 Design Solution 2 Figure 3.20: Conceptual depiction of the code generation module of an XTEAM-generated domain-specic interpreter. 79 design. The solution presents a design pattern or implementation technique that over- comes the challenge and achieves the goal. The example shows how the design solution operates in the case when the XDEVS metainterpreter and MIF are applied to the Myx metamodel and Lunar Lander application model. Design Solution 1 Context: Instantiating a metatype in a metamodel creates a domain-specic type whose semantics are derived from the properties of the metatype instance. The metamodeler lls in the attributes of the metatype instance and creates associations between the metatype instance and other metatype instances in the metamodel. The values of these properties, and the semantics they imply, are xed for all instances of the domain-specic type dened by the new metatype instance. At the same time, domain-specic properties may be attached to the domain-specic type. Domain-specic properties are assigned values within application models and vary among instances. XTEAM metamodels are naturally implemented in object-oriented programming lan- guages as networks of objects. Each object is an instance of a class that represents a particular metatype; the class denes member variables corresponding to the metatype's properties and methods that implement the metatype's behavior. Goal: Ensure consistency of metatype properties, and avoid duplication of common properties. 80 Challenge: Object-oriented programming languages provide two obvious ways of representing domain-specic type denitions: subclassing and instantiation. Using sub- classes of metatype classes to represent domain-specic types has two negative conse- quences. First, instances of a given domain-specic type are allowed to have dierent values for metatype properties that are supposed to be identical and xed for all in- stances. Second, identical metatype properties are captured within every domain-specic instance, resulting in massive duplication and redundant information as there may be many thousands of object instances in a model. Yet, using instances of metatype classes to represent domain-specic types does not work either: one would not be able to cre- ate domain-specic instances because there is no way to create instances of instances in widely-used object-oriented languages such as C++. Solution: Separate metatype and domain-specic properties using the Type Object pattern [90]: capture metatype properties in a type class and capture domain-specic properties in an object class, as depicted by the gray projections in Figure 3.20. Each XTEAM metatype has a corresponding type class in the MIF. Metatype prop- erties that capture simulation and application semantics are specied as attributes of the type class. The metainterpreter produces code that creates and initializes an in- stance of one of these type classes for each metatype instance in the metamodel. The metainterpreter also generates an object class denition for each metatype instance. Example: Figure 3.21 shows a simplied XTEAM code snippet that illustrates this solution. The LinkType class is the type class for the link metatype, and is built into the simulation generator framework for automatic reuse. The delay and capacity variables of this class are metatype properties. The MyxLink class is the object class that is 81 automatically generated for the MyxLink domain-specic type from the Myx metamodel. The direction variable is a domain-specic property. Design Solution 2 Context: Embedded semantic assumptions are dened for each metatype. These seman- tics may be further constrained or otherwise altered by domain-specic semantics that are dened for each domain-specic type. Goal: Allow domain-specic behavior to customize metatype instances. Allow meta- types and domain-specic types to be used interchangeably to simplify model manipula- tion. Challenge: The separation of type class and object class hierarchies (required by Design Solution 1) results in the following problems. First, model objects cannot be ma- nipulated by the metainterpreter and MIF without knowing whether they are metamodel objects or domain-specic model objects. This prevents reuse of many common model manipulation functions. Second, the MIF must be exposed to the implementations of both metatype semantics and domain-specic type semantics in order to know when to apply each of them. Third, interfaces are duplicated | once for the type class and once for the object class. These problems increase the complexity of the MIF and reduce its exibility and extensibility. Solution: Attach domain-specic behavior to metatype instances using the Deco- rator pattern [55]. Provide a common interface for behavior via an abstract base class. Implement domain-specic behavior in object classes and delegate domain-independent 82 //Type class for Link metatype class LinkType { // Metatype properties bool delay; bool capacity; ... set<Interface *> sources; set<Interface *> destinations; }; class Link { LinkType * type; Link(LinkType * type_param) : type(type_param) {} }; LinkType * myxLinkType = new LinkType; myxLinkType.delay = true; ... //Object class for MyxLink type class MyxLink : public Link { // Domain-specific properties typedef enum { UPWARD, DOWNWARD } DirectionType; DirectionType direction; MyxLink(LinkType * type_param) : Link(type_param) {} }; MyxLink * myxLinkInstance = new MyxLink(myxLinkType); myxLinkInstance.direction = MyxLink::UPWARD; Figure 3.21: A code snippet showing how domain-specic type denitions are captured using type objects. 83 behavior to type classes, as indicated in the connections between domain-specic and domain-independent interpretation boxes in Figure 3.20. Each XTEAM metatype has a common interface for the manipulation of metamodel and model objects. Each XTEAM metatype also has a corresponding decorator class, which is invoked by instances of object classes to reuse implementations of domain- independent behavior at the appropriate times and in the appropriate manner. Example: A code snippet illustrating this solution is shown in Figure 3.22. The LinkIntf class denes a common interface to link type classes and object classes. The Link class acts as a decorator and allows subclasses to customize the behavior of instances of the LinkType class, such as the way messages are relayed across links. These classes are built into the MIF. The MyxLink class, generated by the metainterpreter, denes the domain-specic relaying behavior of the MyxLink type from the Myx metamodel in the generateRelayBehavior() method. Design Solution 3 Context: Algorithms for generating a certain type of output (such as an executable simulation) often exhibit recurring structures. The application of domain-specic seman- tics within those algorithms must ensure that constraints imposed by the target semantic domain are not violated. Goal: Factor out the common structure of model interpreter algorithms (e.g., model traversal) for reuse and control domain-specic extensions. 84 // Common interface for Link behavior class LinkIntf { virtual void generateRelayBehavior() = 0; }; // Type class for Link metatype class LinkType : public LinkIntf { virtual void generateRelayBehavior() { // Domain-independent behavior ... } }; // Decorator class for Link metatype class Link : public LinkIntf { virtual void generateRelayBehavior() { type->generateRelayBehavior(); } LinkType * type; }; //Object class for MyxLink domain-specific type class MyxLink : public Link { virtual void generateRelayBehavior() { // Domain-specific behavior ... Link::generateRelayBehavior(); // Domain-specific behavior ... } }; Figure 3.22: A code snippet showing how a decorator allows metatype instances to be customized with domain-specic behavior. 85 Challenge: Analysis tools, middleware platforms, simulation engines, and other se- mantic domains impose constraints on the systems they execute. For example, com- ponents that execute in a given middleware platform may be restricted in the type of interfaces they expose or the way they interact with other components. MIFs must en- sure that they do not generate code that violates those constraints. Yet exposing the MIF to the implementation details of semantic domains increases its complexity and decreases its extensibility. Solution: Implement model interpreter algorithms using the Template Method pat- tern [55] by dening algorithm structure in decorator classes and implementing specic steps within those algorithms | which may involve domain-specic behavior | in object classes using extension points, as shown in Figure 3.20. The XTEAM MIFs implement template methods within decorator classes for generating the output simulation code for each object in a domain-specic model. Portions of the code that are allowed to be cus- tomized through domain-specic semantics are generated by virtual methods of object classes that implement domain-specic semantics (as in Design Solution 2). The template method ensures that domain-specic semantics are applied in a manner that ensures ad- herence to the constraints of the target semantic domain (the XDEVS simulation engine or Prism-MW run-time environment). Example: The code snippet in Figure 3.23 shows the generateCode() method of the Link class, which is built into the MIF. This method captures the structure of the algo- rithm used for generating the XDEVS or Prism-MW objects that implement link objects 86 class Link { generateCode(); virtual void generateRelayBehavior(); virtual void generateDeliveryBehavior(); }; class MyxLink : public Link { virtual void generateRelayBehavior(); virtual void generateDeliveryBehavior(); }; Link::generateCode() { ... this->generateRelayBehavior(); ... this->generateDeliveryBehavior(); ... } Figure 3.23: A code snippet showing how a template method applies domain-specic semantics in a structured manner. in a domain-specic model. Steps in the algorithm that realize the relaying and deliv- ery behavior, implemented by thegenerateDeliveryBehavior() andgenerateRelayBe- havior() methods, are generated by the metainterpreter. 3.3.3 Summary The XTEAM implementation leverages a core set of design solutions in both the XDEVS and Prism-MW metainterpreters and MIFs. These design solutions overcome technical barriers to allow ecient and exible component implementations. XTEAM represents metamodels as networks of instances of metatype classes implemented in C++. Metatype classes capture property values and implement capabilities and responsibilities. XTEAM represents domain-specic types through the combination of (1) an instance of a metatype class (which captures the instance facet) and (2) a subclass of a metatype class (which 87 captures the type facet). Domain-specic types apply transformation operations imple- mented in metatype classes according to domain-specic semantics. The MIF ensures adherence to semantic constraints and achieves scalable performance by controlling the contexts in which domain-specic semantics are applied. 3.4 Simulation Executing the XDEVS metainterpreter of XTEAM on a metamodel results in a fully con- gured domain-specic model interpreter that formerly had to be programmed manually. The synthesized model interpreter generates simulations from domain-specic models that execute in XDEVS, a discrete event simulator. XDEVS is a stand-alone simulator for analyzing the dynamic behavior of complex systems [44]. The XDEVS MIF code, which is built into XTEAM, is reused as-is within the domain-specic simulation generator, and the MIF extension code, which is automatically generated by XTEAM, is plugged into the domain-specic simulation generator. Together, the MIF and MIF extension comprise the domain-specic interpreter. The XTEAM approach is designed to be suitable for synthesizing interpreters that target third-party, o-the-shelf, and industry-standard platforms and tools. Therefore, the details of XDEVS are, in some sense, tangential to the core research contributions of this dissertation. However, I created XDEVS in parallel with XTEAM to solve a dierent set of research challenges, and XDEVS incorporates its own set of technical innovations and presents research contributions distinct from those of XTEAM. This 88 section describes the motivation for building XDEVS, the design of XDEVS, and the use of XDEVS simulations, including those generated by XTEAM interpreters. 3.4.1 Discrete Event Simulation A discrete event simulation [5] consists of a network of nodes that interact by exchanging messages. A simple node is an active entity with state, while a compound node is an instantiation of a group of simple and compound nodes and their interconnections. Com- pound nodes can be constructed in a hierarchy of arbitrary depth. Nodes send and receive messages via ports which are attached to the ports of other nodes via links. Compound nodes transparently pass messages between their internal nodes and external nodes by mapping their external ports to the ports of internal nodes. Every node state transition and message exchange is an event that occurs at a discrete time step during the simulation execution. When applied to software systems, the nodes in a discrete event simulation correspond to computational resources that request services from each other. Each node queues requests, spends some time processing each request, updates its state, and produces output. The behavior of nodes, such as the frequency with which they request services and the amount of time they spend processing requests, is often modeled stochastically. The emergent behavior of the system results from resource contention, node interaction patterns, and other factors. One of the most important features of discrete event simulations is their exibility. Discrete event simulations have been used to analyze the performance, dependability, re- source consumption, and other properties of software systems. Discrete event simulations 89 can also model highly dynamic systems with entities that come and go and adapt their behavior based on their environment. Finally, discrete event simulations can be combined with models of continuous systems, such as the physical environment, to produce hybrid models with both discrete and continuous elements. 3.4.2 XDEVS Motivation The development of XDEVS was motivated by two shortcomings with existing o-the- shelf simulation engines: the lack of an architecture-based programming model and the inability to customize the engine to leverage domain knowledge. First, existing simulators require engineers to use either a routine-based or event-based programming model for describing the behavior of simple nodes. In a routine-based model, the logic describing the behavior of each node runs in its own thread which is scheduled by the simulation engine. The node receives input and output by invoking send and receive methods. In an event-based model, logic than handles input messages is invoked by the simulation engine whenever a message arrives. The input-handling logic produces output by invoking a send method. While the routine-based and event-based programming models are simple and intuitive for describing many types of systems, they are not well-suited for describing complex software architectures, as illustrated by the following examples: Most architecture models (including XTEAM models) include a representation of the component execution environment. In these models, an architecture both serves as a container for internal components and provides access to platform services. Using conventional simulation environments, an architecture may be modeled as a 90 compound node. Using this approach, an architecture essentially becomes a \card- board box" for a set of component and connector instances, mapping the interfaces of internal elements to external links. However, this only fullls part of the role required of an XTEAM architecture: it does not dene a complete execution envi- ronment that includes platform services and resources, such as access to persistent storage and network interfaces. To provide this capability, a more complex and non-obvious mapping to a set of compound as well as simple nodes must be imple- mented. Almost all architecture models separate component interfaces from implementations to ensure modularity and separation of concerns. Moreover, components frequently implement multiple interfaces. With conventional simulators, a compound node can model an interface as a set of ports, and map those ports to the ports of sub-nodes that model the implementation of that interface. However, this prevents a node from implementing multiple interfaces because each node can only be contained within a single compound node. Thus, it is not possible to model a software component that implements multiple interfaces in this way. In other words, the conventional discrete event simulation approach couples the interface of a node with its implementation. Using the basic types used in existing simulators, each component may be modeled as either a simple or compound node. This modeling approach has a major short- coming however: it couples the logic that describes how a task is performed with the entities that actually perform the task, which is an example of failure to ensure sep- aration of concerns. This distinction is critical in software architectures: software 91 components describe reusable units of functionality, but that functionality is actu- ally executed by shared resources (processors, threads, etc.). Consequently, there is no straightforward mapping from software components to discrete event nodes. Usually, rather than mapping software components to simple and compound nodes, software components are mapped to requests for shared resources (such as proces- sor time), and the shared resources, not the software components, are modeled as nodes in the simulation. This solution remains unsatisfactory, however, because it is an awkward way to describe a software architecture. As the above examples show, mapping a software architecture to a discrete event simula- tion is not straightforward, primarily due to the programming model adopted by existing simulators. Second, existing simulators limit the ways that the simulation infrastructure can be customized to improve eciency. Eciency is critical to discrete event simulations be- cause they are often used to analyze complex, large-scale systems with thousands or mil- lions of interacting objects. During the execution of a simulation, the simulation engine must determine, from a potentially extremely large set, the next events to execute, the recipients of output messages, and the next state of each node. Without constraints on the behavior of nodes, the simulation engine must assume worst-case conditions, e.g., that any node can produce output or change state arbitrarily. On the other hand, applying domain knowledge can expose opportunities for considerable improvement in algorithm eciency, resulting in better scalability. 92 Unfortunately, modifying the core scheduling, routing, and event handling algorithms of current discrete event simulation platforms is dicult because they were not designed with such customizability in mind. Commercial simulators, such as Simulink [26], are closed-source and, while plug-in interfaces are available to add on certain types of func- tionality, the core simulation algorithms cannot be modied. Open-source simulators can, in theory, be modied arbitrarily, but they are not designed (or documented) for easy extensibility or customization. Open-source simulators, such as Adevs [99] and OM- NeT++ [128], provide a simulation kernel in which functionality for scheduling, routing, dispatching, and event handling is tightly coupled. The rationale behind this design is to improve performance, but the result is that it is dicult to modify or replace individual simulator services or reuse custom algorithms across multiple systems. 3.4.3 XDEVS Design The XDEVS simulation engine is assembled from independent components that imple- ment interfaces to dierent simulation services. The structure of the core framework components and their interactions are based on design patterns that have been success- fully applied to other types of application frameworks. A very small simulation kernel only implements sucient functionality to ensure that the constraints of the discrete event formalism are enforced. Engineers are able to modify the core framework com- ponents (without needing to consider possible side-eects), mix-and-match simulation algorithms, and reuse custom-built components within dierent projects. This architec- ture can actually improve performance in many cases because the simulation algorithms can be customized to take advantage of opportunities for domain-specic optimization. 93 The core XDEVS framework components are: a simulation kernel, which controls the main processing loop; a scheduler, which manages the simulation clock and orders pending events; a router, which determines the destinations of outputs and the handlers for inputs; and a notier, which allows the simulation behavior to be analyzed. Figure 3.24 depicts the high-level design of the XDEVS simulation engine. The simulator kernel executes a loop in which each iteration computes what happens in the simulation at a discrete point in simulated time. Each iteration through the loop is comprised of three strictly ordered steps: 1. The kernel asks the scheduler to compute the next event that will occur in the simulation. The scheduler advances the simulation clock to the time at which is this event occurs, removes the event from the heap of scheduled events, and returns a handle to the event back to the kernel. Multiple events can occur simultaneously in discrete event simulation, in which case all occurring events are returned. The kernel then pushes the event information to the notier for analysis and invokes the simulation object(s) responsible for handling the event. At this point, application behavior implemented in simulation objects executes, possibly producing new outputs and causing new events to be scheduled. 2. The kernel requests the router to determine all outputs that must be transmitted in the simulation. The router determines the destinations of all outputs, removes them from the list of pending outputs, and returns the outputs back to the kernel. The 94 Application Simulation Objects XDEVS Simulation Engine Simulator Kernel Get next event(s) Handle event(s) Get new output(s) Transfer output(s) Get new input(s) Handle input(s) Scheduler Router Notifier Event Listener simulated time elapses Event heap Pending output(s) Pending input(s) Notify Configuration New events, inputs, outputs Simulation Log Figure 3.24: Conceptual depiction of the XDEVS simulation engine functions. kernel again pushes this information to the notier and invokes the simulation ob- ject(s) responsible for transmitting the outputs to their destinations, as determined by the router. Again, application behavior implemented in simulation objects executes, possibly producing new inputs and causing new events to be scheduled. 3. The kernel requests the router to determine all inputs that must be handled in the simulation. The router determines the handlers of all inputs, removes them from the list of pending inputs, and returns the inputs back to the kernel. The kernel again pushes this information to the notier and invokes the appropriate simulation objects. Again, application behavior implemented in simulation objects executes, possibly causing new events to be scheduled. 95 Scheduler The XDEVS scheduler component is responsible for producing a global ordering of events, including state transitions and message exchanges. Events that are planned for future time steps are passed to the scheduler along with an occurrence time using the Command pattern [55]. This pattern allows events to be parameterized, queued for later execution, and unwound to back up the simulation, without the scheduler knowing what individual events represent. At every simulation step, the scheduler must be able to eciently determine the next event(s) that will occur and update its internal representation of scheduled events by adding new events as they are created and removing events that are no longer planned for execution. The optimal data structures and algorithms for searching and updating the set of scheduled events depends heavily on the characteristics of the system being simulated. For example, in systems where entities are continuously created and destroyed, it is benecial for the scheduler to support ecient removal of scheduled events that refer to destroyed entities. Similarly, in some systems, it may be possible for already-scheduled events to change their occurrence time without warning, and the scheduler must take this possibility into account. In other systems, where such changes are not allowed, using a scheduler that plans for and accommodates this possibility will be inecient. The scheduler, as the global arbiter of event ordering, is also responsible for \breaking ties," i.e., choosing an ordering among events that occur at the same discrete time step. For example, when multiple entities are scheduled to transition state simultaneously, the scheduler may enforce a bottom-up evaluation of state transitions (i.e., evaluating 96 primitive entities at the leaves of the model rst), a top-down ordering, or some other discipline. Again, the most ecient and appropriate policy varies from one domain to another. Router The XDEVS router component is responsible for determining the destinations of messages that are output by application simulation objects and the handlers for messages that are input to application simulation objects. For each output, the router determines the set of recipients and encodes this information within the message itself. In XDEVS, it is possible for a single simulation model to contain multiple routers that distribute dierent types of events, implement dierent routing protocols, or service dierent simulation entities. The determination of which router handles each event is always made dynamically in accordance with the simulation conguration (described below). In most simulations, the router's primary activity is eciently nding paths between model entities, given a directed graph of logical connections. However, in some cases, quite dierent types of algorithms and data structures are required. For example, a router that performs publish-subscribe event distribution must also implement routines for retrieving the list of subscribers for each published message. Notier and Event Listeners Event listeners are used by simulation programmers to implement architecture analysis techniques and record the run-time behavior of application objects in a simulation. Event listeners register with a notier and subscribe to events using the Observer [55] pattern, 97 allowing them to be automatically and eciently invoked at the appropriate times. Event listeners indicate the events in which they are interested based on the event type and the application object that initiates the event. All events that occur in a simulation are pushed to the notier, which then noties all interested event listeners. Event listeners have access to all the event data and are able to record it or use it to compute other useful information. For example, event listeners may record the frequency of a certain type of service request, compute the latency observed by service clients, track the size of request queues, and so on. The notier is responsible for invoking the callback methods of the appropriate event listeners when events occur in a simulation. Conguration An assembly of XDEVS modules that represent a complete simulation engine is repre- sented by an XDEVS conguration. The conguration is implemented by a Singleton class [55] to ensure that a unique instance is used throughout a given simulation. A programmer-dened conguration subclass denes the implementation that will be used for each XDEVS module and initializes each module by passing initialization parameters and connecting modules to each other. Also, the conguration provides an interface to all XDEVS modules and includes an event logger. When the event logger is enabled for debugging, it records all events that occur during the simulation with a tunable level of verbosity. 98 3.4.4 XDEVS Programming Model The XDEVS simulation engine uses a software architecture-based programming model. XDEVS still executes a model composed of a hierarchy of simple and compound nodes, preserving the properties and features of the discrete event formalism, but these types only exist \under the hood" of the simulation. Engineers describe their systems in terms of components, interfaces, shared resources, and other architectural types. The interfaces of system services, the logic that describes how those services are implemented, and the resources that execute that logic are totally decoupled. The core classes used by programmers to implement XDEVS simulations closely re- semble the XTEAM metatypes (Architecture, Component, Interface, etc.) because both are based on fundamental architectural abstractions. Simulation programmers dene subclasses of these classes and, as with the event-based programming model, implement methods that react to events in the simulation by changing state and/or emitting mes- sages (of course, this code can alternatively be automatically generated from an XTEAM model). The simulation engine is responsible for managing all the events in the simula- tion and invoking the methods of simulation objects appropriately. However, in contrast to the simple node construct used by conventional simulators, which only reacts to mes- sages arriving on a port, XDEVS simulation objects are triggered by architectural events, such as the invocation of an interface, the establishment of a link, the termination of a component, or a request for a resource. Programmers can then describe the behavior of their systems in terms of these high-level behaviors, rather than just primitive messages. 99 Each type of XDEVS object reacts to dierent types of events and is capable of emitting dierent types of events. Architecture Class To create an architecture type, simulation programmers implement a subclass of the XDEVS::Architecture class. The subclass must implement methods that are triggered when a component, link, or resource in the architecture is created or destroyed. Com- monly, these methods update the state of the execution environment to re ect the new system conguration. Architecture classes also must implement methods that provide access to system resources. These methods may be used to control the assignment of resources based on system state, impose delays to simulate access overhead, or raise exception events that simulate a resource failure. Component Class Programmers implement component types for use in a simulation by subclassing the XDEVS::Component class. The subclass must implement methods that are triggered when the component's implementation(s) interact with external components. These methods may be used to lter and monitor interactions. These methods are also used to trigger methods of implementations and links to dispatch incoming interactions and transmit outgoing interactions. 100 Interface Class Programmers create dierent types of component interaction points in a simulation by subclassing the XDEVS::Interface class. The subclass must implement methods that are triggered when an operation of the interface is invoked or returns, or a message is sent or received. These methods may be used to examine parameters or message data and simulate adapter or indirection overhead. Link Class Subclasses of the XDEVS::Link class implement the types of connections among compo- nent interfaces that are needed for a simulation. Link subclasses implement methods to: handle the initiation of interactions, which cause the link to commence a transmission; dene the eects of transmission, which may alter, corrupt, reformat, or otherwise manip- ulate the data; dene the duration (simulated time required) to perform transmissions; and handle the completion of a transmission, which may cause the link to update its state (e.g., to re ect newly available bandwidth). Resource Class Resources provided by simulated computing environments are dened by programmer- implemented subclasses of the XDEVS::Resource class. Resources include methods that execute when a resource request is received or a resource request completes. Both of these methods are generally used to update the state (availability) of the resource and/or add and remove requests from the request queue. For example, alternative scheduling 101 disciplines (e.g., priority scheduling) can be implemented in these methods in a straight- forward way. Also, resources must implement methods that compute and return the simulated time at which executing requests will complete. Implementation Class Programmers implement a subclass of the XDEVS::Implementation class to create a com- ponent behavior and state denition. Implementations dene methods that are triggered when an interface invocation is delegated to the implementation, or when an interface in- voked by the implementation returns. These methods initiate tasks that represent atomic behaviors supported by the implementation. To initiate a task, an implementation must send service requests to all resources required to perform the task. Operation Class A subclass of the XDEVS::Operation class represents a specic, invokable application service entry point in a simulation. Methods of operation classes are triggered by invo- cation or completion of the operation represented by the class. These methods are not commonly used, but may be used to add delay (e.g., to simulate indirection overhead) or alter parameters (e.g., to simulate the function of an adapter), if it is not appropriate to include this logic in the interface class (e.g., if some operations of an interface impose delay but others do not). 102 Task Class The types of tasks used in a simulation are implemented by subclasses of the XDEVS::Task class. Tasks must dene a single method that species the consequences of executing the task. During execution, tasks may perform computations, initiate new tasks, update the state of the implementation, and/or invoke additional interfaces. DataType Class Subclasses of the XDEVS::DataType class dene the types of objects that are exchanged by components over links, capture the state of implementations, dene the parameters and return values of operations, and so on. Data types are not required to implement any methods or respond to any simulation events. However, these methods almost always include \helper" methods needed for analysis. For example, numerous analyses require information relating to the size of data being exchanged or processed by components. A simulation that does not utilize real application data might dene a method that returns a stochastic value for the size of data objects in the data type class. 3.4.5 XDEVS Use An XDEVS simulation is created by (1) implementing all the application classes that will be used in the simulation, (2) implementing event listeners that monitor and record properties of interest, (3) specifying an XDEVS conguration that instantiates and ini- tializes an implementation of each of the XDEVS engine modules, and (4) compiling the application classes and event listeners by including the XDEVS conguration and linking to the XDEVS library. The compilation produces an executable le that rst requests 103 an XDEVS run list. The run list species how many times the simulation should be executed, what parameters (e.g., random number seeds) to use for each run, and what information to display during run execution. The simulation executable then performs all runs and terminates. The following are examples of architectural analysis techniques that have been imple- mented and applied using XDEVS: Performance. Event listeners dened for performance analysis utilize an XDEVS simulation of a Layered Queuing Network (LQN) [133]. LQNs are used to cal- culate performance metrics such as latency, throughput, and utilization. XDEVS LQN simulations measure and record the end-to-end latency of request-response in- teractions. The observed latencies depend on numerous factors, including the load applied to the system, the computational resources available, the size of data sets, and other stochastic factors. Reliability. Event listeners dened for reliability analysis leverage an XDEVS sim- ulation of a Hidden Markov Model (HMM) [110] to calculate component reliability. Component reliability is dened as the percentage of time the component spends in a normal operational mode [112]. Potential faults specied in the architecture model occur with the probabilities dened by the architect. In response, the sys- tem may take recovery actions to mitigate the fault, such as instantiating back-up components or changing the system deployment. While the system performs these recovery actions, it is considered to be in a failure mode, and the reliability drops accordingly. 104 Energy consumption. Event listeners dened for energy analysis use an en- ergy consumption estimation technique [117] that denes equations to calculate the energy used by executing software based on a number of application-specic and platform-specic parameters. The total energy cost is the sum of the computational energy cost, due to CPU and memory usage, and the communication energy cost, due to sending and receiving data over a wireless network. Figure 3.25 shows a code snippet from one of the event listeners, EnergyCostInput- Listener, used for the energy consumption analysis. An instance of the EnergyCost- InputListener is created for every component in a simulation. The EnergyCostInput- Listener subscribes to component input events and computes the computational and communication energy costs incurred by each event using domain-specic properties (e.g., host) as well as characteristics of the event data. Figure 3.26 demonstrates how the data produced by this analysis can be used to show the drain on the battery of a theoretical GameHost device during execution of the Lunar Lander application. To illustrate one possible way XDEVS simulations can inform architectural decision- making, again using the the Lunar Lander application as an example, suppose an engineer wishes to evaluate how replication of the GameData component within the Lunar Lander might aect performance and reliability. On one hand, performance will likely suer because additional processing resources will be consumed to run an extra copy of the component and keep the two copies synchronized. On the other hand, if one of the copies fails, the other will remain available to service requests, improving system reliability. The determination of whether this trade-o is benecial depends on the complex interactions 105 void EnergyCostInputListener::handle(Event * event) { //Retrieve the relevant interfaces and components EnergyInterface * dst_interface = dynamic_cast<EnergyInterface *>(event->dst()->parent()); EnergyComponent * src_component = dynamic_cast<EnergyComponent *>(event->src()->parent()->parent()); // Determine the computational energy cost double computational_energy_cost = computeInvocationEnergyCost( dst_interface, event->data()); double communication_energy_cost = 0; // If the components are in different process spaces if (src_component->host() != this->component->host()) { // Determine the communication energy cost communication_energy_cost = event->data()->size() * this->component->host()->receiveEnergyCost() + this->component->host()->receiveEnergyOverhead(); } // Record the energy usage EnergyLogger::instance()->record_energy_usage( this->component, computational_energy_cost + communication_energy_cost, XdevsConfiguration::instance()->time()); } Figure 3.25: A code snippet showing how an XDEVS event listener implements an energy consumption analysis technique. 106 0 50 100 150 200 250 0 1000 2000 3000 4000 5000 GameData Request Latency Simulation Time (s) Observed Latency (ms) 0.9992 0.9993 0.9994 0.9995 0.9996 0.9997 0.9998 0.9999 1 0 1000 2000 3000 4000 5000 GameData Component Reliability Component Reliability Simulation Time (s) Replication No replication 57000 57200 57400 57600 57800 58000 58200 58400 58600 0 1000 2000 3000 4000 5000 Remaining Energy (J) Simulation Time (s) GameHost Battery Power Figure 3.26: An energy consumption analysis of the Lunar Lander application computed by an XDEVS simulation. and behavior of numerous components, the current execution environment, and other factors. Using XTEAM and XDEVS, two possible designs for the Lunar Lander were simu- lated. The simulations produced the end-to-end latency and failure rate data graphed in Figure 3.27. The two graphs quantify the intuition stated above. Using this data, an engineer could determine whether the performance cost of replication is acceptable, or whether the system reliability requirements can be met without replication. The engineer can make an informed architectural decision and provide quantitative rationale for that decision. 107 0 50 100 150 200 250 0 1000 2000 3000 4000 5000 GameData Request Latency Simulation Time (s) Observed Latency (ms) 0.9992 0.9993 0.9994 0.9995 0.9996 0.9997 0.9998 0.9999 1 0 1000 2000 3000 4000 5000 GameData Component Reliability Component Reliability Simulation Time (s) Replication No replication Figure 3.27: Performance and reliability data computed by an XDEVS simulation of the Lunar Lander. 3.4.6 Summary XDEVS simulations are dened using an architecture-based programming model. The behavior of simulation objects is specied by implementing methods that react to sys- tem events. Code that implements these methods can be automatically generated from XTEAM models. The XDEVS simulation engine is organized as a set of components that interact to execute simulation models. These components implement basic functions required for simulation execution, including scheduling, routing, dispatching and exception handling. The core algorithms that provide these functions are encapsulated within independently substitutable modules. Each module implements an abstract interface that denes the operations the module provides. 108 Architectural analysis techniques are applied to XDEVS models using event listeners. Event listeners subscribe to particular system events; implement algorithms and equations that compute system properties, such as performance, reliability, and eciency; and record or display the observed dynamic behavior of the system for review by a software architect. 109 Chapter 4 Evaluation The goal of XTEAM is to simplify, automate, and accelerate the development of domain- specic architecture modeling and code generation toolsets. The utility of XTEAM hinges on (1) usability and applicability in software engineering contexts and (2) reduction of interpreter development and maintenance eort. This section provides two types of evi- dence that XTEAM achieves these goals. First, XTEAM has been successfully applied in the context of at least eight distinct software engineering research projects to date. These projects were not conceived or tar- geted for the purpose of evaluating of XTEAM; rather, each project had goals independent of XTEAM. XTEAM was selected for use by the project teams because it provided capa- bilities they deemed helpful. Section 4.1 describes each project, how XTEAM was used in the project, and the outcome. Second, a set of experiments was performed to evaluate XTEAM in more a controlled setting. These experiments examined the code complexity, code reuse, and code gen- eration in XTEAM as applied to each of a group of nine representative metamodels. The experiments were intended to quantify the reduction in interpreter development and 110 maintenance eort achieved by XTEAM. Section 4.2 provides the experimental results and discusses what conclusions can be drawn from the results. 4.1 Applications Over the four years since the initial version of XTEAM was published and made available for download [40], a number of dierent research projects have leveraged it as a plat- form for designing next-generation applications, examining the behavior of experimental distributed system architectures, evaluating novel architectural analysis techniques, and implementing complementary model-based and architecture-based software engineering capabilities. Collectively, these projects demonstrate that XTEAM works as described. Additionally, these projects highlight the following important properties of XTEAM: XTEAM's metamodeling capabilities are exible. The DSLs developed using XTEAM come in a wide variety of forms and serve a number of dierent purposes. For example, some DSLs are oriented primarily towards non-functional analysis, while others are focused on dynamic architectural changes. XTEAM DSLs have been (and continue to be) utilized in application domains ranging from embed- ded systems to net-centric operations. This diversity of form and purpose among these DSLs shows that XTEAM did not sacrice too much exibility by embedding semantic assumptions and constraints in metamodels. The XTEAM architecture lends itself to enhancement and extension. Many of the projects that utilized XTEAM added additional capabilities to it or integrated it with other tools. These projects leveraged the open interfaces and 111 standardized data formats within XTEAM to create plug-ins, converters, and other external components that implemented new functions or provided a bridge to other modeling, analysis, and implementation platforms. The XTEAM implementation is modular and reusable. Some projects used only a subset of XTEAM's components and embedded those components within new applications and frameworks. This represents a somewhat unanticipated use of XTEAM, but is nevertheless encouraging because it shows that XTEAM's com- ponents are loosely coupled, adaptable, and versatile. XTEAM is suciently robust, scalable, and user-friendly for use by third-parties. While XTEAM is currently not as feature-rich or mature as some MDE platforms, it is reliable and well-documented. In some cases, research teams have downloaded it and successfully used it with relatively little or no support from the XTEAM developer. The remainder of this section describes eight software and systems engineering re- search projects that utilized XTEAM. 4.1.1 Embedded Sensor Network Systems The MIDAS project [47,89,120] was a multi-year research eort led by Bosch Research and Technology Center that leveraged XTEAM in the development of next-generation wireless sensor network (WSN) applications for building monitoring and control. As depicted in Figure 4.1, MIDAS is a product line of embedded systems that include: sensors that monitor the environment; gateways that act as a bridge between sensors and the rest of 112 H a n d h e l d Figure 4.1: An embedded sensor network system analyzed with XTEAM models. the system; hubs that perform computationally intensive tasks (such as data visualization) and provide an administrative interface; and handheld devices that allow mobile access to the administrative interface. Applications in the MIDAS product line include security systems, climate control systems (temperature, humidity, etc.), and other systems with specic fault-tolerance and dynamic service discovery requirements [120]. Three crucial separate architectural decisions formed the basis of the XTEAM meta- model for MIDAS. First, the MIDAS product-line architecture [89] denes roles for MI- DAS components (gateways, hubs, etc.) and rules governing their composition. There- fore, the metamodel includes Gateway, Operator, Sensor, and Service component types that correspond to the roles in the reference architecture, allowing MIDAS application 113 models to be built using these abstractions. Second, MIDAS systems utilize three dis- tinct architectural styles: publish-subscribe, service-oriented, and peer-to-peer. The con- straints of these styles were incorporated into the MIDAS metamodel in a way that applied stylistic constraints to components selectively based on their position in the application structure (i.e., any given component adheres to only one style). Finally, performance and reliability were identied as key quality attributes for MIDAS. The information required to estimate the impact of architectural decisions on these quality attributes was captured via domain-specic properties in the MIDAS metamodel. The use of XTEAM models allowed the MIDAS research team to capture the architec- ture of multiple applications in the MIDAS product line using abstractions with which the domain experts were already familiar. XTEAM automatically ensured architectural con- straints (derived from the product-line architecture and architectural styles) were obeyed in each individual application. Most importantly, XTEAM allowed MIDAS engineers to generate simulations that were used to analyze the performance, reliability, and eciency of dierent application congurations. For example, the MIDAS infrastructure provides support for transparent replication of components to improve reliability. However, this replication comes at a cost in terms of higher resource usage. XTEAM-generated sim- ulations served as the basis for experimentation with dierent replication strategies and helped engineers determine the optimal number of replicas for various components. 4.1.2 Autonomous Mobile Robotics Systems A multi-organizational research team developed an architecture-driven modeling, anal- ysis, implementation, deployment, and monitoring framework for mobile systems that 114 included XTEAM as one of its core components [41,87,124]. The framework addresses a wide variety of issues and challenges in mobile software development, such as uctuating execution contexts and infrastructure heterogeneity, through an integrated set of tools and platforms. The framework includes two o-the-shelf tools in addition to XTEAM: Prism-MW [88] and DeSi [97]. The framework was used to build two mobile robotics applications: an environment exploration application and a convoy application. The environment exploration appli- cation consisted of a team of robots that cooperatively mapped an unknown landscape. The robots' goal was to determine the location of all obstacles in a two-dimensional space with the minimum amount of movement. The convoy application, pictured in Figure 4.2, consisted of a team of robots that autonomously assembled themselves into a single-le procession and followed a leader robot to a goal destination. Each follower robot tracks the location of the robot directly preceding it in the convoy using an array of sensors. XTEAM constitutes the design-time modeling and analysis capabilities of the inte- grated mobility framework. Specically, for the mobile robotics applications, XTEAM's modeling facilities were used to specify several candidate architectures for each applica- tion, capture relevant system parameters and quality objectives, and model fault miti- gation strategies. XTEAM's XDEVS simulation generator was used to assess dierent congurations of components, estimate the probability of network disconnection, and predictively assess the eects of dynamically incorporating new functionality into the ap- plications. Finally, XTEAM's Prism-MW application generator was used to synthesize the skeleton structure of the system implementation. 115 Figure 4.2: An autonomous mobile robotics system partially designed using XTEAM. 4.1.3 Software Energy Consumption Estimation A researcher at the University of Southern California invented an architectural analy- sis technique that estimates the energy consumption of executing software components and then used XTEAM to evaluate the accuracy and precision of the technique's un- derlying theoretical equations [117{119]. Energy eciency has gained recognition as a critical quality property for mobile software that runs on battery-powered devices. The energy consumption technique computes the energy consumed by a software component as a sum of its computational energy costs and communication energy costs. Computa- tional energy costs include all energy consumed by CPU processing, memory accesses, I/O operations, and so on. A computational energy cost is incurred whenever one of a component's interfaces is invoked. Communication energy costs, on the other hand, include energy consumed during transmission or receipt of data over a wireless network. 116 A communication energy cost is incurred whenever a component interacts with remote components. Both computational and communication energy costs are calculated from a number of input parameters, such as data sizes, network bandwidth, and host platform characteristics, using a set of equations. To determine how accurately the technique estimates the actual energy consumed by a real software system, the energy cost parameters were captured as domain-specic properties in an XTEAM metamodel and the energy cost equations were implemented in XDEVS event listeners. Then, several open-source Java applications were modeled in XTEAM, XDEVS simulations were generated, and the simulations were executed to produce energy consumption estimates. These estimates were compared with the actual energy consumed by the various applications, as measured using a digital multimeter. XTEAM allowed numerous scenarios, with diering message sizes and component de- ployments, to be rapidly simulated. The results of the study, a sample of which are shown in Figure 4.3, demonstrated that the technique produces estimates that are within 7% of the actual value in all tested cases. 4.1.4 Redundancy for Volunteer Computing Systems A collaborative team involving researchers from the University of Washington and the University of Southern California employed XDEVS as a stand-alone simulator to investi- gate the dynamic behavior of novel redundancy strategies in volunteer computing systems [14, 15]. The redundancy strategies, termed progressive redundancy and iterative redun- dancy, utilize adaptive voting algorithms to reliably identify erroneous computations pro- duced by faulty and untrusted participants in an open network. Progressive redundancy 117 3 hosts, 8 components -4.3 5 hosts, 17 components 1.3 7 hosts, 25 components 3.1 9 hosts, 33 components 1.7 -5 -4 -3 -2 -1 0 1 2 3 4 3 hosts, 8 components 5 hosts, 17 components 7 hosts, 25 components 9 hosts, 33 components Error rate (%) Figure 4.3: The accuracy of an energy consumption estimation technique, computed by comparing XTEAM simulation data to measured values. and iterative redundancy leverage information about the reliability of volunteer comput- ers to automatically adjust the level of redundancy for specic computational tasks at run-time. These redundancy strategies are far more ecient than traditional redundancy and voting mechanisms because they eliminate redundancy where it provides little benet and inject redundancy where it is most valuable. XDEVS simulations empirically veried the expected, theoretical behavior of pro- gressive redundancy and iterative redundancy in terms of the simulated time required to complete computations, the number of replicated tasks generated, the average number of replicas per task generated, the maximum number of replicas generated for any sin- gle task, the number of tasks that achieved a correct result, the average response time 118 per task, and the maximum response time for any task [15]. Moreover, XDEVS pro- vided dynamic views of the system behavior that could not be generated from theoretical analysis. For example, the graphs in Figure 4.4 show that, if the average reliability of volunteer nodes in the system changes at run-time (Figure 4.4(a)), progressive (PR) and iterative redundancy (IR) automatically respond by increasing or decreasing the number of replicas of tasks (the cost factor), while traditional redundancy (TR) does not adapt (Figure 4.4(b)). As a result, progressive and iterative redundancy reduce the uctuations in eective system reliability (Figure 4.4(c)). 4.1.5 Composition of Service-Oriented Software Systems XTEAM is an important component of the SASSY framework, a model-driven toolset for automated run-time generation of service-oriented architectures (SOAs) developed at George Mason University [49, 94]. SASSY automatically generates architectures for service-oriented software systems from activity-based models, termed service activity schemas (SASs), by optimizing a utility function expressed in terms of quality-of-service (QoS) metrics. SASSY leverages architecture patterns to guide the architecture gen- eration process. SASSY also continuously monitors the system QoS at run-time and dynamically adapts the architecture when QoS metrics uctuate. The architecture models generated by SASSY, called system service architectures (SSAs), are XTEAM models. However, SASSY automatically updates these models based on run-time monitoring data and dynamic adaptations. The SSAs capture a dynamic view of an executing system, and serve as a basis for run-time architectural reasoning. This demonstrates a unique and unanticipated reuse of the XTEAM modeling components. 119 (a) (b) (c) Figure 4.4: XDEVS simulation data characterizing the behavior of dierent redundancy strategies in a volunteer computing network. 120 Views of two SASSY models { showing an architecture before and after adaptation { are given in Figure 4.5. The SASSY framework developers chose to utilize XTEAM because of the archi- tectural constructs underlying the XTEAM metalanguage, which allowed them to model large-scale systems, and because of the ability to incorporate domain-specic types, which allowed them to create service instance objects in SSAs [94]. 4.1.6 Resilient Situated Software Systems The RESIST framework extends XTEAM to enable dynamic reliability estimation and proactive adaptation in situated software systems [24]. RESIST utilizes run-time moni- toring data and contextual information to derive ne-grained predictions of component reliability. The component-level reliability estimation technique trains and solves special- ized Hidden Markov Models (HMMs) using the Baum-Welch algorithm [110] to determine the probability that a component is in a failure state at any given time. RESIST then compositionally determines the expected reliability of possible component assemblies and selects the best alternative. System-level reliability estimates in RESIST are derived from the computed component-level reliabilities, the architectural style in which the compo- nents are assembled, and the system's operational prole. XTEAM models are used to capture architectural congurations in RESIST. The XTEAM metamodel for RESIST includes domain-specic types and properties needed for RESIST reliability computations, including state transition probabilities and failure probabilities. RESIST automatically generates a new XTEAM model whenever an ar- chitectural reconguration decision is made at run-time, and performs an architectural 121 (a) (b) Figure 4.5: XTEAM models of an automatically generated service-oriented architecture (a) before and (b) after adaptation. 122 (a) 0.840 0.880 0.920 0.960 1.000 Configuration Reliability Navigator Failure Probability Config 1 Config 2 Config 3 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator Heat Sensor 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator Heat Sensor 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator 1 Navigator 2 Heat Sensor (b) 0.840 0.880 0.920 0.960 1.000 Configuration Reliability Navigator Failure Probability Config 1 Config 2 Config 3 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator Heat Sensor 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator Heat Sensor 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator 1 Navigator 2 Heat Sensor (c) 0.840 0.880 0.920 0.960 1.000 Configuration Reliability Navigator Failure Probability Config 1 Config 2 Config 3 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator Heat Sensor 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator Heat Sensor 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator 1 Navigator 2 Heat Sensor (d) 0.840 0.880 0.920 0.960 1.000 Configuration Reliability Navigator Failure Probability Config 1 Config 2 Config 3 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator Heat Sensor 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator Heat Sensor 0.980 0.985 0.990 0.995 1.000 Component Reliability Navigator Failure Probability Controller Navigator 1 Navigator 2 Heat Sensor Figure 4.6: The reliabilities of dierent congurations and components of a mobile emer- gency response system, as estimated by XTEAM simulations. di to determine what changes to make to the running system. Also, XTEAM simula- tions were used to evaluate the impact of architectural reconguration decisions made by RESIST. For example, Figure 4.6 shows the reliability of a mobile emergency response system, as estimated by XTEAM simulations. Figure 4.6(a) shows the reliability of the full system for three possible congurations as a function of the failure probability of a Navigator component. Figure 4.6(b), (c), and (d) show the reliabilities of individual components, also as a function of the Navigator failure probability, for the three possible congurations. 123 4.1.7 Self-Tuning Self-Adaptive Software Systems The FUSION system intelligently and eciently adapts software systems by adding and removing features based on their impact on system goals, and uses XTEAM to capture architecture models [48]. Features represent individual system capabilities. Operationally, FUSION combines two automated decision cycles. The adaptation cycle detects whether any system goals are not met based on monitored system behavior, plans feature changes (if necessary) by maximizing a utility function, and performs all steps necessary to realize the feature changes. The learning cycle normalizes monitored system behavior, measures how features changes have impacted system behavior, detects when system behavior deviates from the predicted behavior, and renes its predictive model accordingly. The XTEAM metamodel for FUSION includes domain-specic types for specifying goals and features. Features are mapped to XTEAM architecture model fragments, which are weaved together to form a complete architecture model with the given features. When- ever feature changes are required, a new architecture is generated and, as with RESIST, an architectural di is performed using XTEAM models to determine what components, connectors, and other elements need to be added, removed, or recongured. Furthermore, XTEAM-generated queuing network simulations were used in the evaluation of FUSION to create a simulated workload for the prototype FUSION implementation, stochastically inject unexpected events, and serve as a basis for comparison of learning models. For example, Figure 4.7 compares the accuracy of performance predictions for a specic ser- vice interface in a travel reservation system produced by three dierent learning models 124 (a) 0 5 10 Prediction Error% Time 0 20 40 60 Prediction Error% Time 0 50 100 150 Prediction Error% Time 0 50 100 150 200 Prediction Error% Time Time FUSION Offline Learning QN (b) 0 5 10 Prediction Error% Time 0 20 40 60 Prediction Error% Time 0 50 100 150 Prediction Error% Time 0 50 100 150 200 Prediction Error% Time Time FUSION Offline Learning QN (c) 0 5 10 Prediction Error% Time 0 20 40 60 Prediction Error% Time 0 50 100 150 Prediction Error% Time 0 50 100 150 200 Prediction Error% Time Time FUSION Offline Learning QN (d) 0 5 10 Prediction Error% Time 0 20 40 60 Prediction Error% Time 0 50 100 150 Prediction Error% Time 0 50 100 150 200 Prediction Error% Time Time FUSION Offline Learning QN 0 5 10 Prediction Error% Time 0 20 40 60 Prediction Error% Time 0 50 100 150 Prediction Error% Time 0 50 100 150 200 Prediction Error% Time Time FUSION Offline Learning QN Figure 4.7: The accuracy of performance predictions produced by a queuing-network- based learning model implemented in XTEAM. | FUSION's adaptive learning model, a static learning model, and a queuing-network- based learning model | under (a) normal trac, (b) varying trac, (c) database indexing failure, and (d) randomized DoS trac. XTEAM was used to implement the queuing network model (note that, the data shown indicates the accuracy of a specic learning model implemented using XTEAM, not the accuracy of XTEAM itself). 4.1.8 Test and Evaluation of Net-Centric Systems The PATFrame project is an ongoing initiative funded by the United States Depart- ment of Defense and led by the Massachusetts Institute of Technology in which XTEAM plays an integral role [33, 52, 64, 65]. The PATFrame project develops decision support technologies for testing and evaluation of unmanned and autonomous systems-of-systems (UASoS). PATFrame assists engineers planning distributed operational tests by predict- ing potentially undesirable emergent behavior and prioritizing tests based on cost, risk, and schedule. 125 Normative Descriptive Prescriptive Decision Support System Real Options Systems Dynamics Leading Indicators ... PATFrame Decision Support Technologies PATFrame Core Models PATFrame Adaptive Architecture Framework Assessment of Effectiveness Testbed Ontology Modeling Language for Adaptive Test System Architectures Modeling, Analysis, Simulation, and Synthesis Toolsuite Risk Models Parametric Models Design of Experiments Figure 4.8: A decision support system that utilizes XTEAM as an adaptive architecture framework (AAF). XTEAM constitutes the core of PATFrame's adaptive architecture framework (AAF) for UASoS test systems. The AAF allows the construction of models that capture au- tonomous behavior and generates simulations that detect undesirable emergent behavior. The XTEAM metamodel for PATFrame is strongly in uenced by the adaptive layered architectural style [41] for autonomous systems. Figure 4.8 depicts the overall PATFrame approach and the role of the AAF built using XTEAM. 4.1.9 Summary XTEAM has been successfully used in a number of software engineering research projects. Each of these projects utilized XTEAM's metamodeling facilities to dene domain-specic 126 types, and most of them also utilized XTEAM's automated interpreter synthesis capa- bilities to generate XDEVS simulations and/or Prism-MW applications. 4.2 Experiments While a number of projects have successfully utilized XTEAM for a wide range of ap- plications, the diverse and uncontrolled ways in which the XTEAM components were applied make it dicult to quantify the benet achieved in each instance or perform an \apples-to-apples" comparison. To evaluate the utility of XTEAM in a controlled, exper- imental setting, I developed a number of software architecture DSLs based on a diverse set of component-based metamodels. I was able to successfully simulate domain-specic system models that conformed to these metamodels using the XTEAM simulation gen- erator components and the XDEVS discrete event simulation engine. Since the novelty of XTEAM results in the ability to generate simulations without writing any custom code by hand (generating simulations from architecture models is, by itself, not new), I evaluated XTEAM according to the programming eort saved. This section rst denes the evaluation metrics and then presents the results of applying XTEAM to nine subject DSLs. 4.2.1 Metrics The experimental evaluation of XTEAM used two categories of metrics. Implementation eort metrics indicate the eort saved through code generation and reuse. Maintenance 127 eort metrics indicate the relative ease of performing DSL modications within a meta- model, as aorded by XTEAM, rather than within model interpreter source code, as would have been necessary previously. Implementation Eort Metrics XTEAM automates model interpreter development both by automatically reusing code (the MIF) and automatically generating code (the MIF extensions). To quantify the interpreter implementation eort that XTEAM avoids, the size and complexity of the XDEVS and Prism-MW MIFs and the XDEVS MIF extensions generated from nine subject metamodels were examined. The metrics used to evaluate the complexity of the XDEVS and Prism-MW MIFs are as follows. These commonly-used complexity indicators [73] are not aected by the size of the code base because they are calculated on a per-statement, per-method, or per-class basis. Each complexity metric was computed for both the XDEVS and Prism-MW MIF. Percent branches: The percentage of all statements that result in a break in the sequential execution of the program. Average methods per class: The total number of methods divided by the total number of classes. Both inline and non-inline class and template class implementa- tions are counted. Average statements per method: The total number of statements found inside methods divided by the number of methods. 128 Average depth: The weighted average of the depth of all statements. Depth is the number of nested blocks in which a statement appears. Average complexity: The average complexity of all methods. The complexity is the number of execution paths through a method, computed using the method of McConnell [92]. Max depth: The maximum depth of any statement. Max complexity: The maximum complexity of any method. The metrics used to evaluate the size of the XDEVS MIF and MIF extensions are as follows. Each metric was computed for the XDEVS interpreter generated from each of the nine subject DSLs. Number of domain-specic types: The number of types in the DSL, which provides an indication of metamodel size and complexity. Lines of generated code: Source lines of code (SLOC) automatically generated by the XDEVS metainterpreter in the form of MIF extensions. Total code reuse: The sum of (1) the 16,243 SLOC in the XDEVS MIF and (2) the generated SLOC in the MIF extension for each metamodel. Generated code per domain-specic type: The average SLOC generated for each domain-specic type denition in the metamodel. Reused code per domain-specic type: The average reused interpreter SLOC for each domain-specic type in the metamodel. 129 Maintenance Eort Metrics One of the primary advantages of XTEAM is the ability to make DSL changes and rapidly regenerate the DSL's supporting interpreters, rather than having to modify the code of these interpreters manually. To quantify the interpreter maintenance eort that XTEAM avoids, the size and complexity of changes to XDEVS MIF extensions caused by changes to the nine subject DSLs were examined. The metrics used to evaluate the interpreter maintenance eort savings are as follows. Each set of metrics was computed by (1) performing a set of modications to a DSL, (2) regenerating the XDEVS MIF extension for the DSL, and (3) ding the new MIF exten- sion with the previous MIF extension to determine the impact of the DSL changes. The rst metric provides an indication of the level of eort needed to achieve a modication using the XTEAM approach; the remaining metrics indicate the level of eort that would be required using a conventional approach. Metamodel objects altered: The number of modied objects in the DSL meta- model, which provides an indication of the eort needed to achieve a modication using the XTEAM approach. Number of classes altered: The number of generated classes that were aected by the metamodel change, which provides an indication of how widely scattered the required code modications were. Number of methods altered: The number of generated methods in which at least one statement changed. 130 Total lines of code altered: The SLOC aected by the metamodel change, which provides an indication of the magnitude of the required code modications. Lines of code altered per domain-specic type: The SLOC changed divided by the number of metamodel objects changed, which provides an indication of how the magnitude of the required code modications compares to the magnitude of the metamodel modication. 4.2.2 Results Figure 4.9 summarizes the subject metamodels used in the evaluation. Figure 4.10(a) shows the complexities of each of the XTEAM MIFs according to the seven complexity metrics. The complexity measurements do not include a large amount of peripheral code included within the MIF that performs functions such as data structure initialization and interface adaptation. This code is excluded because it is reasonable to assume that a developer may reuse such code even without an MIF. On the other hand, the core transformation logic cannot be readily reused without the use of a strategy, such as the XTEAM approach, that enhances in some way the standard interpreter development paradigm. Because the units of each metric are dierent, the values have been normalized to permit them to be displayed on a single graph. Figure 4.11a displays the size metrics for the XDEVS MIF extensions generated from the subject metamodels. The values shown only include generated and reused code in the domain-specic interpreters; none of the model editor components, nor any code generated for a specic application model (such as Lunar Lander), were included in the metrics. 131 Category Metamodel Description Metamodeling languages Ecore Metamodeling language used in Eclipse modeling tools such as EMF; targeted for object-oriented and Java-based systems. Design and architecture modeling languages AADL Modeling language targeted for specification and analysis of real-time embedded systems and complex systems of systems. xADL 2.0 Core A common set of fundamental modeling abstractions for software architectures. Architectural styles C2 Component- and message-based architectural style for constructing flexible and extensible software systems. Client/server Ubiquitous request/response architectural style. Pipe-and-filter Architectural style in which separate programs concurrently process data streams. Pub/sub Architectural style based on asynchronous and anonymous message distribution. Middleware component models and application frameworks Myx.fw Framework for development of Eclipse plug-in applications. Prism-MW Lightweight middleware targeted for applications in embedded and mobile settings. Figure 4.9: Nine metamodels used in the evaluation. % Branches Avg Methods /Class Avg Stmts /Method Avg Depth Avg Complexity Max Depth Max Complexity Lines of Code XDEVS MIF 15.7 5.75 19.3 23.4 42.4 9 29 16243 Prism-MW MIF 21.1 5 35.6 2.74 7.96 8 35 8053 Figure 4.10: The code complexity metrics of the XDEVS and Prism-MW MIFs. 132 Metamodel Domain- Specific Types Lines of Generated Code Total Code Reuse Generated Code /Type Total Reuse /Type AADL 86 2306 18549 27 216 Ecore 76 1277 17520 17 231 xADL Core 53 1195 17438 23 329 C2 42 1268 17511 30 417 Client/server 34 1091 17334 32 510 Pipe-and-filter 29 957 17200 33 593 Pub/sub 50 1779 18022 36 360 Myx.fw 62 1493 17736 24 286 Prism-MW 54 1678 17921 31 332 (a) 16500 17000 17500 18000 18500 19000 15 20 25 30 35 40 Lines of Generated Code per Domain-Specific Type Total Lines of Reused Code 1 2 3 4 5 6 7 8 9 1AADL 2ECore 3xADL 4C2 5Client/server 6Pipe-and-filter 7Pub/sub 8Myx 9Prism-MW (b) Figure 4.11: The implementation eort metrics computed for the XTEAM evaluation. 133 Figure 4.11b illustrates the relationship between metamodel size and two metrics | generated code per type and total code reuse. The diameter of each circle represents the size of the corresponding metamodel. The larger metamodels generally result in greater overall reuse, but the reuse benets are amortized over a larger metamodeling eort, resulting in a smaller benet per domain-specic type. This reinforces the intuition that, for very large metamodels, more implementation eort is avoided, but metamodeling consumes a larger share of the overall eort. A way to interpret these numbers is to apply the widely-used COCOMO II soft- ware cost estimation model [10]. With all nominal settings, and a project size of 17,500 SLOC, COCOMO II estimates that 23.4 person-months are required to implement a domain-specic simulation generator. With favorable settings, such as high team cohe- sion, programmer expertise, and personnel continuity, 4.2 person-months of eort are estimated. Thus, even in the best circumstances, the cost of manual implementation of model interpreters is substantial. Figure 4.12 shows the maintenance eort metrics for seven DSL modications. Each DSL modication used a dierent starting metamodel and applied a dierent set of mod- ications, in order to obtain a broad sample. Modications included introducing new inheritance and containment relationships, changing metamodel properties, and adding or removing types. The resulting changes in the generated code were dependent on the specic modications made. For example, inheritance modications tended to aect a large number of classes but may not have changed any methods within those classes (as in the case of client/server). Containment modications aected a smaller number of classes but resulted in more new code (as in the case of AADL). 134 Metamodel Types Affected Classes Altered Methods Altered Code Altered/ Type Lines of Code Altered AADL 2 3 10 64.5 129 Client/server 4 10 1 5 20 C2 2 4 1 7 14 Ecore 1 4 4 19 19 Publish/subscribe 1 3 4 22 22 Myx.fw 5 8 12 20.4 102 Prism-MW 4 7 14 21 84 0 5 10 15 20 25 30 0 5 10 15 20 25 30 Types Affected Classes Altered Methods Altered Code Altered/Type Figure 4.12: The maintenance eort metrics computed for the XTEAM evaluation. While the number of lines of code altered in response to the changes was, in some cases, quite small, these changes tended to be spread over a relatively large number of classes and methods in comparison to the relatively small number of metamodel objects that were altered. This implies that modications required for DSL evolution are more widely scattered, and therefore more time-consuming to implement, in interpreter source code than in a metamodel. Moreover, a metamodel may be more understandable and 135 therefore easier for a new engineer to modify, which is important when the DSL must be maintained over a period of time. 4.2.3 Summary XTEAM was evaluated during a set of experiments that quantied the implementation eort and maintenance eort saved. Nine DSLs derived from various architectural styles, design languages, and implementation platforms served as experimental subjects for ap- plying XTEAM and computing the evaluation metrics. Although the true eort savings achieved will vary widely across dierent modeling projects, the evaluation data indicate that a savings of at least several person-months of eort will be obtained in most cases. 136 Chapter 5 Related Work The software engineering sub-disciplines of architecture modeling, model-driven engi- neering, model transformation, system quality analysis, automated program synthesis, and system simulation are all active areas of research. These research areas also bene- t from an extensive | in some cases, decades long | foundation of prior innovations and research breakthroughs. Obviously, such a rich and vast body of work cannot be adequately summarized in this dissertation. Therefore, this chapter addresses research related to XTEAM in the following way. First, a survey of MDE platforms is provided, focusing on specic projects and their similarities to and dierences from XTEAM. This work represents the ongoing research and development eorts most closely related to XTEAM. Second, the most important achievements in other, more tangentially related research areas are pointed out, with an emphasis on characterizing the overall state of the eld of study. 137 5.1 Model-Driven Engineering Platforms This section discusses two categories of MDE platforms. Production MDE platforms are those platforms in use by a large, active community of engineers (i.e., thousands to tens of thousands of users). These platforms are highly usable, feature-rich, robust, and mature, but they lack the most advanced capabilities newly invented by researchers. Experimental MDE platforms are research prototypes that implement novel, untested techniques and theories; XTEAM falls into this category. These platforms are oriented towards implementation, demonstration, and evaluation of a very specic capability or innovation, and therefore provide a much narrower set of features, may contain bugs and defects, and are not as user-friendly. These platforms are often modied or extended versions of production MDE platforms. Obviously, this categorization is informal and somewhat subjective, but nonetheless captures the essential dierence in focus and intent among available MDE platforms. 5.1.1 Production MDE Platforms This subsection describes three production MDE platforms: the Generic Modeling En- vironment (GME) [58], the Eclipse Graphical Modeling Framework (GMF) family of tools [34{36], and the MetaEdit+ Workbench [96]. GME The Generic Modeling Environment (GME) [58] is an open-source MDE platform devel- oped at Vanderbilt University's Institute for Software Integrated Systems. (As noted in 138 Chapter 3, the XTEAM implementation reuses several components of GME and inte- grates them with custom-built components to create novel capabilities.) In development and use for over a decade, GME is highly robust and scalable. GME is built on top of Microsoft's COM technology, is integrated with Microsoft Visual Studio, and runs on Microsoft Windows. GME's metamodeling language, called MetaGME, is based on variants of the UML Class Diagram notation [105,113] and the Object Constraint Language (OCL) [71,104]. The core metatypes of MetaGME, which are termed rst class objects (FCOs), are: Model, a compound object with an internal structure; Atom, an elementary object with no internal structure; Reference, a pointer to some other object; Connection, a binary association of objects; and Set, a grouping of objects. The allowed relationships among FCOs in a metamodel in restricted by FCO type; for example, only Models and Sets may have a containment relationship to other FCOs. All FCOs may have attributes. In addition to the GME FCOs, several auxiliary metatypes are used to construct GME metamodels: Folders organize other model objects in a hierarchical tree structure. Aspects dene views, which are implemented as tabbed windows in the GME model editor, in which only particular object types are visible. Constraints capture OCL-like expressions that dene complex rules governing model well-formedness. GME provides some facilities to assist the construction of model interpreters. First, GME can automatically generate a customized, high-level API, called the Builder Object Network 2 (BON2) interface, for programmatically extracting information from and ma- nipulating domain-specic models. The BON2 API contains C++ methods for reading and writing model object properties and traversing a C++ object network representing a 139 model. Second, transformations of GME models from a source DSL to a target DSL can be specied graphically, and the code implementing transformations can be automatically generated, using the Graph Rewriting And Transformation (GReAT) tool [122]. GReAT denes a transformation language (itself a DSL) for pattern-based specication of model transformation rules and implements an interpreter for generating transformation code. Eclipse EMF/GEF/GMF The Eclipse Graphical Modeling Framework (GMF) [35] is an open-source platform for developing custom graphical editors for the Eclipse software development environ- ment [39]. GMF builds on other Eclipse-based tools, namely the Eclipse Modeling Frame- work (EMF) [36] and Graphical Editing Framework (GEF) [34]. EMF, GEF, and GMF all heavily utilize Eclipse's extensible plug-in system and are implemented in Java. GMF separates metamodeling concerns into several dierent models to enable inde- pendent reuse. A domain model denes the types and relationships for a DSL, a graphical denition denes the display elements that will be rendered in the generated editor, and a mapping denition relates types in the domain model to elements in the graphical de- nition. Also, an optional tooling denition can be used to create auxiliary editor features (menus, toolbars, etc.). GMF uses these models to create a generator model, in which additional options for generating the model editor can be set. From the generator model, GMF generates the code for a set of plug-ins that create a domain-specic model editor in Eclipse. From a scientic standpoint, the most important of these models is the domain model. GMF domain models are specied using the Ecore language. The most important types in Ecore (sometimes referred to as the Ecore kernel) are: EClass, a typical class 140 in the object-oriented sense; EAttribute, a typed value associated with the instances of a class; EDataType, a primitive native Java type; and EReference, a binary association between classes. Several related Eclipse projects focus on the development of model transformation tools that can be used with GMF. The ATL Transformation Language (ATL) toolset [38] uses a specialized rule-based language for specifying model transformations from a source language to a target language. Therefore, ATL is conceptually analogous to GReAT, except that it uses a textual (rather than graphical) language for specifying rules, and operates on DSLs specied in Ecore (rather than MetaGME). The Java Emitter Template (JET) [37] toolset is oriented towards generation of code from EMF or GMF models. Like JavaServer Pages (JSP), JET templates consist of text to-be-output with embedded Java expressions and expression fragments (called scriptlets), which perform model navigation, extract model data, and so on. Using a set of JET templates, the JET compiler generates Java classes that implement a code generator. MetaEdit+ MetaEdit+ is a commercial MDE platform [78,96]. MetaEdit+ is packaged and licensed in two separate applications: MetaEdit+ Workbench provides a metamodel editor for dening DSLs and a generator editor for dening code generators, while MetaEdit+ Modeler provides a domain-specic model editor. Metamodeling in MetaEdit+ is form-based; that is, domain-specic types are created by lling in the elds of dialog boxes. The core metatypes of MetaEdit+ are: Graph, a container for other types; Object, a basic model building block; Property, an attribute 141 of another type; Role, a specication of how an object participates in a relationship; and Relationship, an association between objects. MetaEdit+ segments the metamodeling process into distinct steps. First, the DSL types and properties are created. Next, con- straints and well-formedness rules are specied by instantiating rule templates. Finally, the DSL notation is dened in terms of symbols and graphical display elements. MetaEdit+ provides two mechanisms for implementing code generators. First, code generators can be implemented externally and utilize MetaEdit+'s API to extract model data. This is approach is similar to the approach adopted by GME. Second, code genera- tors can be implemented using MetaEdit+'s code generator templates. Templates utilize a basic scripting language for model navigation and data extraction, and are conceptually similar to Eclipse JET templates. 5.1.2 Experimental MDE Platforms This subsection describes a number of experimental MDE platforms, which were primarily developed in an academic research setting. CALM and Cadena Cadena is an extensible environment for the modeling and development of component- based architectures [62, 72]. The Cadena Architecture Language with Metamodeling (CALM) supports the specication of platform- and domain-specic component models, which are leveraged by Cadena to provide automated enforcement of architectural con- straints. In this way, CALM and Cadena provide a modeling environment that can be readily integrated with a wide variety of component technologies. 142 CALM is based on a three-tiered typing system. At the style tier, an architect denes the kinds of components, connectors, and interfaces that exist within a particular com- ponent model or architectural style. The style tier is essentially a metamodeling layer that denes a language of architectural constructs. At the module tier, the component and interface types that may exist within a specic application architecture are declared. Finally, at the scenario tier, component types are instantiated into a particular congu- ration or assembly. At each tier, Cadena automatically enforces the constraints imposed by the type system dened at the tier above. The modeling capabilities of CALM and Cadena provide a powerful and intuitive mechanism for creating application architectures that conform to domain-specic com- ponent models. Cadena also complements an integrated model-checking infrastructure, Bogor, which enables automatic verication of the logical properties of a system, such as event sequencing. However, Cadena provides little support for the implementation of additional, dynamic types of quality attribute analysis. Thus, Cadena requires engineers to develop model interpreters from scratch in most cases. PACC Predictable Assembly from Certiable Components (PACC) is a proposed framework for the integration of component technologies and analysis technologies [130]. PACC can be used to determine the emergent properties of a highly complex assembly of software com- ponents when certain characteristics of the individual components can be certied. PACC relies on component design tools and run-time environments to enforce the assumptions required by each analysis technique applied to the system. 143 One implementation of PACC is prediction-enabled component technology (PECT). A PECT instance includes a construction framework and one or more reasoning frame- works [18]. The construction framework constitutes the design and implementation fa- cilities, such as modeling environments and code generators, that are used to develop a component-based system. The construction framework relies on an abstract component technology, or ACT, to represent component models and run-time platforms. The ACT can be either explicitly dened, e.g., by a component metamodel, or implicitly dened via the capabilities of and constraints on components developed using the construction framework. Software architecture and design models, or constructive models, that con- form to the ACT are created in the construction framework. A reasoning framework, on the other hand, constitutes the analysis facilities to be applied to the system. A reason- ing framework applies system analysis techniques, or property theories, through the use of an analysis environment. Discrete event simulators and fault-tree analysis tools are examples of analysis environments. Interpretations transform constructive models into analysis models. Component characteristics, which constitute the parameters of property theories, are codied in a components analytic interface. This interface is leveraged by the reasoning framework to apply a system-wide quality analysis. PACC leverages many of the core concepts of MDE within the context of component- based systems to support analysis of the quality attributes of large-scale component assemblies. PACC establishes a clear and intuitive way of organizing and relating the salient elements and features of component technologies and analysis technologies, and outlines a strategy for integrating component models and analysis models that leverages 144 their complementary characteristics. For these reasons, PACC provides a useful concep- tual framework for additional research in the modeling and analysis of component-based systems. However, PACC does not address the fundamental challenge of domain-specic model interpreter development. DUALLY The DUALLY framework supports interoperability among domain-specic architecture languages and tools supporting those languages [86]. DUALLY leverages software en- gineer-dened mappings between each DSL metamodel and a core set of architectural concepts codied in a metamodel, called A 0 . Thus, the analysis and code generation tools available for any DSL for which a mapping has been dened can be applied to architecture models specied in other DSLs. Although DUALLY eliminates the need to manually program model transformations, it still requires dening the mappings between languages. Since A 0 is based on software architecture concepts, and bears a strong re- semblance to the XTEAM metalanguage in this respect, its expressiveness and exibility with respect to DSLs is similar to XTEAM. However, DUALLY exacerbates the model traceability problem of relating analysis results or bugs in generated code to the source ar- chitecture model: introducing additional model transformations makes traceability even more challenging. ALFAMA The ALFAMA DSL workbench [114] automates the construction of DSLs and code gener- ators for application frameworks. ALFAMA leverages an aspect-oriented domain-specic 145 modeling (DSM) layer that both (1) denes specialization aspects that modularize frame- work hot-spots (extension points) and (2) associates those aspects with DSL concepts. The DSM layer allows engineers to bypass metamodel and code generator development. This results in an approach that is, in some ways, the reverse of XTEAM: rather than enhancing metamodels to eliminate interpreter development, ALFAMA enhances inter- preters to eliminate metamodel development. This has many merits but also some draw- backs. First, high-level metamodels are more maintainable than low-level source code. Therefore, it may be advantageous to expend some additional eort on metamodel de- velopment rather than DSM layer development. Second, inferring DSLs from framework hot-spots tightly couples the DSL to a particular framework. This makes it dicult to use the DSL with other frameworks, a limitation not present in XTEAM. As with XTEAM, the automation gains of the ALFAMA approach reduce DSL exibility in some circumstances. xADL and ArchStudio The The eXtensible Architecture Description Language (xADL) is an inherently exten- sible architecture modeling language that can be enhanced to support domain-specic concepts [29,30]. The language is dened by XML schemas; a core schema species stan- dard architectural constructs common to all ADLs, while extension schemas | written by domain experts and tailored to the needs of specic projects | specify new modeling elements as needed. While xADL represents a promising step towards the exibility and customizability required by contemporary large-scale distributed systems development, xADL's focus is 146 primarily architecture representation rather than analysis, simulation, or the generation of implementation/conguration/deployment artifacts. xADL's supporting toolset, Arch- Studio [27], consists of syntactic tools that are semantically agnostic (much like parser generators for programming languages). Therefore, the ArchStudio requires a signicant eort investment to enforce semantic consistency within architecture models (i.e., the source code must be modied). This is in contrast to XTEAM, in which semantics are embedded in DSL metamodels and are automatically used to enforce constraints and synthesize model interpreters. 5.2 Other Related Technologies XTEAM leverages and complements a number of related technologies, the most important of which are summarized in this section. 5.2.1 Modeling Standards The Unied Modeling Language (UML) is the most widely used software and systems modeling technology in industry [127]. UML is developed and maintained by the Ob- ject Management Group (OMG) [101]. UML 2.0 includes thirteen types of diagrams, which capture an applications structure, behavior, and interaction, and provides sev- eral improvements over the previous version (UML 1.x). First, the expressiveness of the language is enhanced through the denition of new constructs for representing the archi- tectures of distributed, component-based systems. This allows modelers to use higher- level abstractions than the previous object-oriented constructs. Second, developers can specify domain-specic variants of the language using the Meta-Object Facility (MOF), 147 which allows the language to be modied and extended [103]. Other lightweight extension mechanisms, such as proles and semantic variations, provide more constrained forms of extensibility. Because UML is standardized, it benets from the availability of a wide variety of vendor-provided environments and tools. However, the UML standard has been criticized for being overly large, complex, and unwieldy. This is a result of both the intent to support modeling across a wide spectrum of domains, as well as the community-driven specication process. The complexity of the UML metamodel inhibits the straightforward and rapid development of language extensions. Furthermore, UML intentionally leaves the semantics of a number of constructs undened. This allows users to plug in the semantics that are most convenient, useful, or appropriate for a given modeling eort, but also makes it dicult to implement analysis engines that apply rigorous formal theories to system models; such engines can only be implemented once all semantic variation points are dened. These drawbacks hinder the utility of applying UML within a model-driven process. Model Driven Architecture (MDA) is a specic model-based development process, also developed and standardized by the OMG [102]. In the MDA process, engineers rst produce platform-independent models (PIMs) in UML. PIMs specify the system to the greatest extent possible without including any details about the platform that will be used to implement the system. For example, PIMs may specify what software components exist and what data types are exchanged between components, but would not specify the language used to implement a component or the physical format of data. A model interpreter is then used to generate platform-specic models (PSMs) from a PIM. 148 A PSM is a set of UML diagrams, just like a PIM, and it contains the same structural and behavioral information as the PIM from which it is derived, but it is further rened and enhanced with platform-dependent information. Finally, another model interpreter is used to generate running code from a PSM. MDA is experiencing increasing adoption in industry, and a wide variety of commercial tools exist that implement some or all of the stages of the MDA process. MDA has been successfully applied to a number of projects, and tangible benets have been demonstrated (at least anecdotally). The primary criticism of MDA is that it is totally reliant on and integrated with UML. This means that engineers utilizing MDA are forced to use UML to model their systems, even when another language is more appropriate. 5.2.2 Product-Line Architectures A product-line architecture (PLA) is a reusable architecture for a family of closely related applications or systems that codies both the commonality and the variability among those systems [21]. PLAs facilitate and direct the usage of reusable assets, such as software components, test suites, and deployment plans, to ensure that applications in the product line fulll specied requirements. At the same time, PLAs constrain the ways in which assets can be customized to create a given application. For example, a PLA may specify that some components are required for all applications in the product line, while other components are optional. Similarly, a PLA may dictate that two components cannot be used together, or that use of one component necessitates use of another. PLAs represent a form of design reuse, which is a very powerful form of reuse (as compared 149 to reuse of source code, for example) and can drastically reduce development time while improving system quality. PLA techniques are relevant to XTEAM for several reasons. First, DSLs are a natural mechanism for codifying and leveraging PLAs: both DSLs and PLAs dene reusable sets of abstractions and rules governing how the abstractions may be composed. Moreover, both DSLs and PLAs are intended to address a particular problem domain. A DSL can be dened such that any application whose model conforms to the DSL metamodel is guaranteed to conform to the PLA. Second, XTEAM itself can be considered a PLA: it mandates the components required to create a specic MDE platform (the product) that is in the class of MDE platforms (the product line) that automatically synthesize domain- specic interpreters. Third, initial attempts to apply PLA techniques to the composition of architecture modeling languages have shown a great deal of promise. These techniques leverage the variability management and asset composition mechanisms dened for soft- ware product lines for metamodel composition, allowing the rapid creation of languages that incorporate features from multiple other languages. The integration of such mech- anisms with XTEAM interpreter generation capabilities have the potential to create a powerful synergy and allow an even higher degree of automation and customizability. Current research on PLAs is investigating a number of challenging open problems. Numerous techniques have been proposed to specify, manage, and control the variability in PLAs [7, 13, 63, 111, 134]. The use of type checking and model checking mechanisms to verify product line compositions has shown promising results [31,82]. Numerous stud- ies undertaken to empirically quantify the benets of PLAs are demonstrating how the 150 economic value of the PLA approach varies in dierent contexts, projects, and organiza- tions [8,9,69]. 5.2.3 Application Frameworks Application frameworks are semi-complete software applications built from an integrated collection of congurable implementation modules (classes, components, etc.) [50]. As such, application frameworks are key enablers for PLAs. Applications frameworks heavily leverage architecture patterns and object-oriented design patterns to create extension points through which the framework can be customized for a particular application. For example, extension points may enable selection of one of several possible algorithms for performing a specic function, replacement of default behaviors with programmer-dened behaviors, or instantiation of an optional feature. Because they can drastically simplify and accelerate application development, frameworks are now almost universally used in particular problem domains (e.g., graphical user interface development). The use of application frameworks is central to XTEAM. First, XTEAM MIFs are a particular subclass of application framework. Like all application frameworks, XTEAM MIFs depend on object-oriented design patterns to create reusable implementation struc- tures with embedded extension points. Second, an application framework is one of the most powerful semantic domains that a DSL can target. Because application frameworks provide high-level, domain-specic implementation constructs in a controlled, structured environment, application models built using DSLs that include these abstractions can focus on variation and conguration, and do not need to specify all the dierent facets of the system. 151 Although application framework technology is now mature, research eorts are contin- uing to improve their eectiveness, increase the scope of their applicability, and integrate them with other complementary technologies, such as MDE, DSLs, and PLAs. For exam- ple, methods have been developed for capturing framework extensions with aspects [115] and automatically constructing DSLs for specifying framework-based applications [114]. 5.2.4 Architecture Analysis and Simulation Software analysis and simulation are used to provide condence (or in some cases, proof) that a given software system will function according to its requirements. Analysis and simulation techniques generally fall into two categories: model-based and code-based. Because the focus of this dissertation is model-based software engineering, only model- based analysis and simulation techniques are discussed in this section. Model-based analysis techniques are used to determine the properties and behaviors of a system design or architecture. Because such designs are, by denition, not complete specications, these analysis techniques rely on critical assumptions about the systems to which they are applied. The assumptions that must be made vary widely from one form of analysis to another. However, all analysis techniques require that the system design contains a specic set of information and that the language constructs used to describe the system conform to a given set of semantics. The most common form of simulation is discrete event simulation [5]. A discrete event simulation models a system as a set of interacting entities and a sequence of events. The state of the system entities and the transmission of events takes place instantaneously at discrete time steps. Discrete event simulations have been used widely across a variety of 152 domains because they have been shown to be extremely exible. In the software world, discrete event simulations are commonly used to represent queuing systems, allowing system performance characteristics to be determined empirically rather than analytically. A large number of discrete event modeling environments and simulation platforms have been developed by both research institutions and commercial entities [26,99,128]. Another widely-used analysis technique is model checking [19]. Model checking repre- sents a family of techniques for verifying the conformance of a nite state model to a set of desired properties. Model checking is used extensively for real-time and safety-critical software to ensure that designs will meet requirements and constraints. Although mod- eling notations dier among model checker implementations, most tools use an extended form of nite state machines to capture the system model along with some variant of com- putation tree logic (CTL) or propositional temporal logic (PTL) to specify the properties to be veried. Many dierent model checking tools are currently available [12,32,81]. 5.2.5 Compiler-Compilers Compiler-compilers, also known as compiler generators, are programs that automatically produce the source code for a compiler given an input language and a target instruction set [2, 17, 56, 70]. Research interest in compiler-compilers was highest during the late 1970s and early 1980s [16], and has since declined. Today, the term compiler-compiler is sometimes used to refer to parser generators, programs that generate scanners and parsers (a compiler front-end) from a grammar describing a language syntax. Parser generators are now mature and in widespread use, while true compiler-compilers that generate a complete compiler, including a code generator (the back-end), are not. There are two 153 reasons commonly cited for this outcome: rst, automatically generated compilers failed to produce ecient code; and second, compiler-compilers required complex, detailed, and complete semantic denitions (usually based on denotational semantics [60]) that were dicult to produce. As noted previously, XTEAM MIFs (when paired with a corresponding metainter- preter) bear a strong conceptual resemblance to compiler-compilers: both generate pro- grams for translating input models or programs specied in one language to a dierent target language. However, XTEAM diers from traditional compiler-compilers is several critical ways: 1 1. XTEAM operates on architecture languages specied by a metamodel rather than formal languages specied by a grammar. Metamodels dene languages in terms of types and properties (which may be attributes or relationships) rather than expres- sions or words. Even textual architecture languages map naturally to types and properties, and are therefore easily described by a metamodel, while formal textual languages in general do not. Both metamodels and grammars can be represented by a directed graph, but the graph representing a grammar is always a tree, and the edges in the tree have only a single interpretation (composition). In contrast, the graph representing a metamodel may take any form, and the edges (properties) in such a graph can have many dierent interpretations (inheritance, composition, association, etc.). Consequently, metatypes and grammar tokens are not isomor- phic, and metamodels capture more information than grammars in a more intuitive 1 Parser generators are purely syntax based, do not synthesize code generators, and are therefore not comparable to XTEAM. 154 way [1]. XTEAM exploits this potential heavily by using properties to congure DSL semantics. 2. XTEAM adopts a very dierent approach to semantic specication, which is less powerful in theory (arbitrary semantics cannot be captured), but is also much more practical. By utilizing a pre-decided set of properties to dene semantics, meta- modelers using XTEAM do not have to develop complex semantic denitions using denotational semantics, structural operational semantics [108], or some other for- malism. This makes semantic specication in XTEAM much simpler and easier. 3. The semantic domains targeted by XTEAM, such as middleware platforms and ap- plication frameworks, are in their own right very powerful platforms that provide high-level design abstractions, which contrasts sharply with the very low-level ma- chine instruction sets targeted by compiler-compilers. This makes it much easier for XTEAM to generate ecient code because optimizations are already built into the platform. Despite the above dierences, XTEAM does exhibit similarities to some compiler- compilers beyond conceptual resemblance. In particular, the Production-Quality Com- piler-Compiler (PQCC) project adopted a similar architecture to XTEAM [85]. PQCC utilized a skeleton compiler that performed traversal and pattern matching functions on an intermediate representation of a program, and a table generator that produced a database of patterns and corresponding code sequences to be generated. Therefore, PQCC's skeleton compiler is analogous to XTEAM's MIFs, and PQCC's table generator is analogous to XTEAM's metainterpreters. 155 5.3 Summary XTEAM represents a unique approach to MDE platform design and implementation. Although many MDE platforms have been proposed in the research literature, and robust and feature-rich MDE platforms are available, none provide XTEAM's combination of an architecture-based metalanguage and automatic interpreter synthesis. It is the integration of these two complementary features that produces XTEAM's innovative capabilities. XTEAM leverages a number of important research achievements of others in the areas of product-line architectures, application frameworks, architecture analysis, and system simulation. XTEAM enhances and supplements these technologies by providing the processes and tools necessary for their unication into a seamless architecture-based design and development system. 156 Chapter 6 Conclusions The goal of the work described in this dissertation is to simplify and accelerate the de- velopment of domain-specic model interpreters for software architecture quality analysis and automated program synthesis. To accomplish this, I conceived the XTEAM ap- proach, a new conceptual process and architecture for MDE platform development, and I implemented the XTEAM software, a novel MDE platform that utilizes the approach. XTEAM allows software engineers to automatically synthesize model interpreters for any DSL, provided that (1) the DSL metamodel is specied using a metamodeling language embedded with sucient semantics, and (2) the necessary underlying components (a metainterpreter and model interpreter framework) are provided by the MDE platform. The XTEAM approach prescribes three activities necessary for MDE platform de- velopers to create an MDE platform that allows model interpreters to be automatically generated. First, MDE platform developers must select the types of interpreters that the MDE platform will generate. Interpreters that are widely applicable and target commonly used platforms and tools are the best candidates. Second, MDE platform developers must dene (or enhance) a metalanguage so that it includes embedded semantic assumptions 157 and metatype properties. Embedded semantic assumptions free metamodelers of the bur- den of specifying some semantics, while metatype properties allow semantic variability to be specied in an intuitive, straightforward, and practical way. Third, MDE plat- form developers must implement a metainterpreter and model interpreter framework for each type of interpreter to be automatically synthesized. The metainterpreter derives the semantics of domain-specic types from the embedded assumptions and property speci- cations in a metamodel and generates rules for applying model transformation operations to domain-specic models that achieve those semantics. The model interpreter frame- work implements transformation operations and applies them according to the generated rules. The XTEAM implementation provides the ability to automatically synthesize a do- main-specic model editor, discrete event simulation generator, and Java application generator from any XTEAM metamodel. Discrete event simulations generated by the synthesized simulation generators run in XDEVS, an architecture-based discrete event simulation engine. Java applications generated by the synthesized application genera- tors run on Prism-MW, a lightweight architectural middleware platform. The XTEAM metalanguage denes a set of nine core metatypes in terms of their capabilities, responsi- bilities, and properties. The XTEAM metainterpreters and model interpreter frameworks leverage numerous object-oriented design patterns and apply them in new ways to ensure eciency, exibility, composability, and maintainability. Numerous research projects have utilized the XTEAM implementation for designing next-generation applications, examining the behavior of experimental distributed system 158 architectures, evaluating novel architectural analysis techniques, and implementing com- plementary model-based and architecture-based software engineering capabilities. Collec- tively, these applications demonstrate the versatility, extensibility, reusability, and robust- ness of XTEAM and its constituent components. Also, a set of controlled experiments quantied the benets of XTEAM in terms of interpreter implementation eort and main- tenance eort saved. The experiments showed that, even when pessimistic assumptions are made, XTEAM automates what would otherwise require multiple person-months of eort. 6.1 Future Research Directions Many exciting research problems remain open in the areas of architecture modeling and model-driven engineering. This section outlines one possible future research project that is particularly relevant to XTEAM: developing methods for automatically composing DSLs based on type inference rules. An automated DSL composition technology would be the natural complement to XTEAM's automated interpreter generation capabilities. Architectural analysis techniques implemented in platforms like XDEVS, such as en- ergy consumption estimation, require specic information to be included in models in the form of domain-specic properties. Similarly, utilization of middleware services im- plemented in platforms like Prism-MW, such as dynamic adaptation, require the use of domain-specic constructs. This implies that, although an XDEVS simulation can be generated from any XTEAM model, not all XTEAM models can be analyzed with re- spect to energy consumption. Likewise, while a Prism-MW application can be generated 159 from any XTEAM model, not all XTEAM models can leverage Prism-MW's dynamic adaptation capabilities. Only those DSLs that include the necessary information can do so. Clearly, there is a coupling between DSL constructs and specic analysis techniques and platform services. Ideally, a metamodeler should be able to indicate the analyses and services that are needed for a modeling eort, and automatically import the required types and properties into a metamodel. To achieve this, two things are needed: (1) a library of analyses and platform services along with corresponding DSL fragments that dene all required types and properties, and (2) a mechanism for automatically integrating any DSL fragment into an arbitrary metamodel. In existing MDE platforms, this second requirement cannot be implemented because the semantics of the domain-specic types in an arbitrary metamodel are not specied, making it impossible to know how the types and properties in a DSL fragment relate to them. However, in XTEAM, the use of embedded semantics can allow the relationships among DSL fragments to be automatically inferred. Type inference is used to automatically deduce the types of data values in a program. For example, the sum of two integers can be inferred to be an integer, while the sum of an integer and a oating point number is a oating point number. Analogously, type inference could be used to automatically deduce the types of elements in a composed metamodel. The \sum" of an abstract component type and a concrete component type might be a new component type with all the properties of both types. However, it is not clear whether the new component should be concrete or abstract, and whether this information is somehow inferable. 160 Server <<Component>> WebServer <<Component>> EnergyInterface <<Interface>> EnergyComponent <<Component>> <<port>> PrintServer <<Component>> type=enum {overhead, coefficient, enumeration} energyProfileType <<Property>> JavaComponent <<Component>> C++Component <<Component>> JavaWebServer <<Component>> C++WebServer <<Component>> JavaPrintServer <<Component>> C++PrintServer <<Component>> EnergyTCPSocket <<Interface>> <<port>> type=enum {overhead, coefficient, enumeration} energyProfileType <<Property>> + + = JavaServer <<Component>> C++Server <<Component>> <<port>> TCPSocket <<Interface>> EnergyServer <<Component>> Figure 6.1: The composition of three metamodel fragments. Figure 6.1 illustrates this issue. Fragments of three metamodels are composed into a single metamodel through pairwise \addition" of all like types, followed by a refactoring of the inheritance hierarchy to move all common properties to base classes; both these steps can be completely automated. However, in the composed metamodel, both JavaServer and EnergyTCPSocket are produced through combination of an abstract type and a concrete type. Depending on the context, it is possible that the intent is for JavaServer to be abstract but EnergyTCPSocket to be concrete. In summary, there appear to be at least some aspects of metamodel composition that are automatable. However, detailed rules for doing so that can handle the majority of 161 cases that arise must be determined. A related open question is under what conditions it is even possible to compose fragments, manually or otherwise. Important research has already made advances in this area. xADL and ArchStudio lay the foundation for the modularization of DSLs into (manually) composable units [28]. Special operators | equivalence, implementation inheritance, and interface inheritance | can be used to simplify metamodel composition [84]. Product-line conguration tech- niques can capture the concerns addressed by a DSL fragment and the dependencies and con icts between DSL fragments [131]. An automated metamodel composition mecha- nism would likely leverage some or all of these innovations. 162 References [1] Marcus Alanen and Ivan Porres. A Relation Between Context-Free Grammars and Meta Object Facility Metamodels. Technical Report 606, Turku Centre for Computer Science, March 2003. [2] Frances E. Allen, J. Lawrence Carter, Janet Fabri, Jeanne Ferrante, William H. Harrison, Paul G. Loewner, and Louise Trevillyan. The Experimental Compiling System. IBM Journal of Research and Development, 24(6):695{715, November 1980. [3] Apache Subversion. subversion.apache.org/. [4] Colin Atkinson and Thomas Kuehne. Meta-Level Independent Modelling. In Pro- ceedings of the International Workshop on Model Engineering (IWME), pages 12{ 16, Cannes, France, June 2000. [5] Jerry Banks, John Carson, Barry L. Nelson, and David Nicol. Discrete-Event Sys- tem Simulation. Prentice Hall, 2009. [6] Jakob Eyvind Bardram, Henrik Brbak Christensen, and Klaus Marius Hansen. Architectural Prototyping: An Approach for Grounding Architectural Design and Learning. In Proceedings of the 4th Working IEEE/IFIP Conference on Software Architecture (WICSA), pages 15{24, Oslo, Norway, June 2004. [7] Pierre-Yves bens, Patrick Heymans, Jean-Christophe Trigaux, and Yves Bontemps. Generic Semantics of Feature Diagrams. Computer Networks: The International Journal of Computer and Telecommunications Networking, 51(2):456{479, February 2007. [8] Gunter Bockle, Paul Clements, John D. McGregor, Dirk Muthig, and Klaus Schmid. Calculating ROI for Software Product Lines. IEEE Software, 21(3):23{31, May 2004. [9] Barry Boehm, A. Winsor Brown, Ray Madachy, and Ye Yang. A Software Product Line Life Cycle Cost Estimation Model. In Proceedings of the International Sympo- sium on Empirical Software Engineering (ISESE), pages 156{164, Redondo Beach, California, August 2004. 163 [10] Barry W. Boehm, Chris Abts, A. Winsor Brown, Sunita Chulani, Bradford K. Clark, Ellis Horowitz, Ray Madachy, Donald J. Reifer, and Bert Steece. Software Cost Estimation with COCOMO II. Prentice Hall, 2000. [11] Andrea Bondavalli, Mario Dal Cin, Diego Latella, Istvn Majzik, Andrs Pataricza, and Giancarlo Savoia. Dependability Analysis in the Early Phases of UML-based System Design. International Journal of Computer Systems Science & Engineering, 16(5):265{275, September 2001. [12] Marius Bozga, Conrado Daws, Oded Maler, Alfredo Olivero, Stavros Tripakis, and Sergio Yovine. Kronos: A Model-Checking Tool for Real-Time Systems. In Pro- ceedings of the International Conference on Computer-Aided Verication (CAV), pages 546{550, Vancouver, Canada, June/July 1998. [13] T. J. Brown, R. Gawley, R. Bashroush, I. Spence, P. Kilpatrick, and C. Gillan. Weaving Behavior into Feature Models for Embedded System Families. In Proceed- ings of the 10th International Software Product Line Conference (SPLC), pages 52{64, Baltimore, Maryland, August 2006. [14] Yuriy Brun, George Edwards, and Nenad Medvidovic. Injecting Robustness into Autonomic Grid Systems. Technical Report USC-CSSE-2009-510, Center for Sys- tems and Software Engineering, University of Southern California, May 2009. [15] Yuriy Brun, George Edwards, Jae young Bang, and Nenad Medvidovic. Smart Redundancy for Distributed Computation. Technical report, Center for Systems and Software Engineering, University of Southern California, July 2010. [16] R. G. G. Cattell, Joseph M. Newcomer, and Bruce W. Leverett. Code Generation in a Machine-independent Compiler. ACM SIGPLAN Notices, 39(4):1{13, April 2004. [17] Roderic G.G. Cattell. A Survey and Critique of Some Models of Code Generation. Technical Report CMU-CS-77-Cattell, Department of Computer Science, Carnegie Mellon University, 1977. [18] Sagar Chaki, James Ivers, Natasha Sharygina, and Kurt Wallnau. The ComFoRT Reasoning Framework. Computer Aided Verication, 3576:164{169, July 2005. [19] Edmund M. Clarke and Bernd-Holger Schlinglo. Model Checking. In Proceed- ings of the 17th Conference on Foundations of Software Technology and Theoretical Computer Science, pages 54{56, Kharagpur, India, December 1997. [20] Paul Clements, David Garlan, Len Bass, Juddith Staord, R. Nord, J. Ivers, and R. Little. Documenting Software Architectures: Views and Beyond. Pearson Edu- cation, 2002. [21] Paul Clements and Linda Northrop. Software Product Lines. Addison-Wesley Pro- fessional, 2001. 164 [22] Daniele Compare, Paola Inverardi, and Alexander L. Wolf. Uncovering Archi- tectural Mismatch in Component Behavior. Science of Computer Programming, 33(2):101{131, February 1999. [23] Steve Cook, Gareth Jones, Stuart Kent, and Alan Wills. Domain-Specic Develop- ment with Visual Studio DSL Tools. Addison-Wesley Professional, 2007. [24] Deshan Cooray, Sam Malek, Roshanak Roshandel, and David Kilgore. RESIST- ing Reliability Degradation through Proactive Reconguration. In Proceedings of the 25th IEEE/ACM International Conference on Automated Software Engineering (ASE), Antwerp, Belgium, September 2010. [25] Vittorio Cortellessa, Antinisca Di Marco, and Paola Inverardi. Software Model to Performance Model Transformations. In Proceedings of the 27th International Conference on Software Engineering (ICSE), pages 728{729, St Louis, Missouri, May 2005. [26] James B. Dabney and Thomas L. Harman. Mastering Simulink. Prentice Hall, 2003. [27] Eric Dashofy, Hazel Asuncion, Scott Hendrickson, Girish Suryanarayana, John Georgas, and Richard Taylor. Archstudio 4: An Architecture-based Meta-modeling Environment. In Companion Proceedings to the 29th International Conference on Software Engineering (ICSE), pages 67{68, Minneapolis, Minnesota, May 2007. [28] Eric M. Dashofy. Supporting Stakeholder-driven, Multi-view Software Architecture Modeling. PhD thesis, University of California, Irvine, California, 2007. [29] Eric M. Dashofy, Andre van der Hoek, and Richard N. Taylor. A Highly-Extensible, XML-based Architecture Description Language. In Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA), page 103, Amsterdam, The Netherlands, August 2001. [30] Eric M. Dashofy, Andre van der Hoek, and Richard N. Taylor. An Infrastructure for the Rapid Development of XML-based Architecture Description Languages. In Proceedings of the 24th International Conference on Software Engineering (ICSE), pages 266{276, Orlando, Florida, May 2002. [31] Benjamin Delaware, William R. Cook, and Don Batory. Fitting the Pieces To- gether: A Machine-Checked Model of Safe Composition. In Proceedings of the 7th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 243{252, Amsterdam, The Netherlands, August 2009. [32] Claudio Demartini, Radu Iosif, and Riccardo Sisto. dSPIN: A dynamic extension of SPIN. In Proceedings of the 6th International SPIN Workshop, pages 261{276, Toulouse, France, September 1999. 165 [33] Indira Deonandan, Ricardo Valerdi, Jo Ann Lane, and Filiberto Macias. Cost and Risk Considerations for Test and Evaluation of Unmanned and Autonomous Sys- tems of Systems. In Proceedings of the 5th IEEE International Conference on Sys- tem of Systems Engineering (SoSE), Loughborough, United Kingdom, June 2010. [34] Eclipse Graphical Editing Framework Project. www.eclipse.org/gef/. [35] Eclipse Graphical Modeling Framework Project. www.eclipse.org/gmf/. [36] Eclipse Modeling Framework Project. www.eclipse.org/emf/. [37] Java Emitter Templates. www.eclipse.org/emft/projects/jet/. [38] The ATL Transformation Language. www.eclipse.org/m2m/atl/. [39] The Eclipse Foundation. www.eclipse.org. [40] George Edwards. A Model-Driven Framework for Architectural Evaluation of Mo- bile Software Systems. In UCI Institute for Software Research (ISR) Research Forum, Irvine, California, June 2006. [41] George Edwards, Josh Garcia, Hussein Tajalli, Daniel Popescu, Nenad Medvidovic, Gaurav Sukhatme, and Brad Petrus. Architecture-Driven Self-Adaptation and Self- Management in Robotics Systems. In Proceedings of the International Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), pages 142{151, Vancouver, Canada, May 2009. [42] George Edwards, Sam Malek, and Nenad Medvidovic. Scenario-Driven Dynamic Analysis of Distributed Architectures. In Proceedings of the 10th International Conference on Fundamental Approaches to Software Engineering (FASE), pages 125{139, Braga, Portugal, March 2007. [43] George Edwards and Nenad Medvidovic. A Methodology and Framework for Cre- ating Domain-Specic Development Infrastructures. In Proceedings of the 23rd IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 168{177, L'Aquila, Italy, September 2008. [44] George Edwards and Nenad Medvidovic. A Highly Extensible Simulation Frame- work for Domain-Specic Architectures. Technical Report USC-CSSE-2009-511, Center for Systems and Software Engineering, University of Southern California, May 2009. [45] George Edwards, Chiyoung Seo, and Nenad Medvidovic. Construction of Analytic Frameworks for Component-Based Architectures. In Brazilian Symposium on Soft- ware Components, Architectures and Reuse (SBCARS), Sao Paulo, Brazil, August 2007. 166 [46] George Edwards, Chiyoung Seo, and Nenad Medvidovic. Model interpreter frame- works: A foundation for the analysis of domain-specic software architectures. Journal of Universal Computer Science Special Issue on Software Components, Ar- chitectures and Reuse, 14(8):1182{1206, April 2008. [47] George Edwards, Chiyoung Seo, Daniel Popescu, Sam Malek, and Nenad Med- vidovic. Self-* Software Architectures and Component Middleware in Pervasive Environments. In Proceedings of the 5th International Workshop on Middleware for Pervasive and Ad-hoc Computing (MPAC), pages 25{30, Newport Beach, Cali- fornia, November 2007. [48] Ahmed Elkhodary, Naeem Esfahani, and Sam Malek. FUSION: A Framework for Engineering Self-Tuning Self-Adaptive Software Systems. In Proceedings of the 18th ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE), Santa Fe, New Mexico, November 2010. [49] Naeem Esfahani, Sam Malek, Joao P. Sousa, Hassan Gomaa, and Daniel A. Menasce. A Modeling Language for Activity-Oriented Composition of Service- Oriented Software Systems. In Proceedings of the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems (MODELS), pages 591{605, Denver, Colorado, October 2009. [50] Mohamed Fayad and Douglas C. Schmidt. Object-Oriented Application Frame- works. Communications of the ACM, 40(10):32{38, October 1997. [51] Peter H. Feiler, David P. Gluch, and John J. Hudak. The Architecture Analysis & Design Language: An Introduction. Technical Report CMU/SEI-2006-TN-011, Software Engineering Institute, Carnegie Mellon University, February 2006. [52] Susan Ferreira, Ricardo Valerdi, Nenad Medvidovic, John Hess, Indira Deonandan, Tsoline Mikaelian, and Gayle Shull. Unmanned and Autonomous Systems of Sys- tems Test and Evaluation: Challenges and Opportunities. In Proceedings of the 4th Annual IEEE Systems Conference, San Diego, California, April 2010. [53] Roy T. Fielding and Richard N. Taylor. Principled Design of the Modern Web Architecture. ACM Transactions on Internet Technology, 2(2):115{150, May 2002. [54] Ian Foster, Carl Kesselman, and Steven Tuecke. The Anatomy of the Grid: En- abling Scalable Virtual Organizations. International Journal of High Performance Computing Applications, 15(3):200{222, August 2001. [55] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Pat- terns: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Publishing Co., Inc., 1995. [56] Harald Ganzinger, Robert Giegerich, Ulrich Moncke, and Reinhard Wilhelm. A Truly Generative Semantics-Directed Compiler Generator. ACM SIGPLAN No- tices, 17(6):172{184, June 1982. 167 [57] David Garlan and Mary Shaw. An Introduction to Software Architecture, pages 1{40. World Scientic Publishing Co., Inc., 1993. [58] The Generic Modeling Environment. www.isis.vanderbilt.edu/Projects/gme/. [59] Aniruddha Gokhale, Krishnakumar Balasubramanian, Arvind S. Krishna, Jai ganesh Balasubramanian, George Edwards, Gan Deng, Emre Turkay, Jerey Par- sons, and Douglas C. Schmidt. Model Driven Middleware: A New Paradigm for Developing Distributed Real-time and Embedded Systems. Science of Computer Programming Special Issue on Foundations and Applications of Model Driven Ar- chitecture (MDA), 73(1):39{58, September 2008. [60] Michael J. C. Gordon. The Denotational Description of Programming Languages: An Introduction. Springer-Verlag New York, Inc., 1979. [61] Michael M. Gorlick and Rami R. Razouk. Using Weaves for Software Construction and Analysis. In Proceedings of the 13th International Conference on Software Engineering (ICSE), pages 23{34, Austin, Texas, May 1991. [62] John Hatcli, Xinghua Deng, Matthew B. Dwyer, Georg Jung, and Venka- tesh Prasad Ranganath. Cadena: An Integrated Development, Analysis, and Ver- ication Environment for Component-Based Systems. In Proceedings of the 25th International Conference on Software Engineering (ICSE), pages 160{173, Port- land, Oregon, May 2003. [63] Scott A. Hendrickson and Andre van der Hoek. Modeling Product Line Architec- tures through Change Sets and Relationships. In Proceedings of the 29th Interna- tional Conference on Software Engineering (ICSE), pages 189{198, Minneapolis, Minnesota, May 2007. [64] John Hess. Test and Evaluation of a SoS using a Prescriptive and Adaptive Testing Framework. In Proceedings of the 5th IEEE International Conference on System of Systems Engineering (SoSE), Loughborough, United Kingdom, June 2010. [65] John Hess, Gaurav Agarwal, Karl K. Cowart, Indira Deonandan, C. Robert Kenley, Tsoline Mikaelian, and Ricardo Valerdi. Normative and Descriptive Models for Test and Evaluation of Unmanned and Autonomous Systems of Systems. In Proceedings of the 20th Annual INCOSE International Symposium, Chicago, Illinois, July 2010. [66] Scott A. Hissam, Gabriel A. Moreno, Judith A. Staord, and Kurt C. Wallnau. Packaging Predictable Assembly. In Proceedings of the IFIP/ACM Working Con- ference on Component Deployment (CD), pages 108{124, Berlin, Germany, June 2002. [67] Anne Immonen and Eila Niemela. Survey of Reliability and Availability Predic- tion Methods from the Viewpoint of Software Architecture. Software and Systems Modeling, 7(1):49{65, February 2008. 168 [68] Ethan Jackson and Janos Sztipanovits. Formalizing the Structural Semantics of Domain-Specic Modeling Languages. Software and Systems Modeling, 8(4):451{ 478, September 2009. [69] Isabel John and Michael Eisenbarth. A Decade of Scoping: A Survey. In Proceed- ings of the 13th International Software Product Line Conference (SPLC), pages 31{40, San Francisco, August 2009. [70] S. C. Johnson. A Portable Compiler: Theory and Practice. In Proceedings of the 5th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (POPL), pages 97{104, Tucson, Arizona, January 1978. [71] Anneke G. Kleppe Jos B. Warmer. The Object Constraint Language: Getting Your Models Ready for MDA. Addison-Wesley Longman Publishing Co., Inc., 2003. [72] Georg Jung and John Hatcli. A Type-centric Framework for Specifying Heteroge- neous, Large-scale, Component-oriented, Architectures. In Proceedings of the 6th International Conference on Generative Programming and Component Engineering (GPCE), pages 33{42, Salzburg, Austria, October 2007. [73] Dennis Kafura and Geereddy R. Reddy. The Use of Software Complexity Metrics in Software Maintenance. IEEE Transactions on Software Engineering, 13(3):335{ 343, March 1987. [74] Gabor Karsai. Structured Specication of Model Interpreters. In Proceedings of the IIEE Conference and Workshop on Engineering of Computer-Based Systems (ECBS), pages 84{90, Nashville, Tennessee, March 1999. [75] Gabor Karsai, Aditya Agrawal, Feng Shi, and Jonathan Sprinkle. On the Use of Graph Transformation in the Formal Specication of Model Interpreters. Journal of Universal Computer Science, Special Issue on Formal Specications of Computer- Based Systems, 9(11):1296{1321, November 2003. [76] Gabor Karsai, Holger Krahn, Claas Pinkernell, Bernhard Rumpe, Martin Schindler, and Steven Volkel. Design Guidelines for Domain Specic Languages. In 9th Work- shop on Domain-Specic Modeling, Orlando, Florida, October 2009. [77] Rick Kazman, Mark H. Klein, and Paul C. Clements. ATAM: Method for Architec- ture Evaluation. Technical Report CMU/SEI-2000-TR-004, Software Engineering Institute, Carnegie Mellon University, September 2000. [78] Steven Kelly. Towards a Comprehensive MetaCASE and CAME Environment: Conceptual, Architectural, Functional and Usability Advances in MetaEdit+. PhD thesis, University of Jyvaskyla, Jyvaskyla, Finland, 1997. [79] Heiko Kern. The Interchange of (Meta) Models between MetaEdit+ and Eclipse EMF Using M3-Level-Based Bridges. In Proceedings of the 8th Workshop on Domain-Specic Modeling, pages 14{19, Nashville, Tennessee, October 2008. 169 [80] Charles W. Krueger. Software Reuse. ACM Computing Surveys, 24(2):131{183, June 1992. [81] Marta Z. Kwiatkowska, Gethin Norman, and David Parker. PRISM: Probabilis- tic Symbolic Model Checker. In Proceedings of the 12th International Conference on Computer Performance Evaluation, Modelling Techniques and Tools (TOOLS), pages 200{204, London, United Kingdom, April 2002. [82] Kim Lauenroth, Klaus Pohl, and Simon Toehning. Model Checking of Domain Artifacts in Product Line Engineering. In Proceedings of the 2009 IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 269{ 280, Auckland, New Zealand, November 2009. [83] Chokchai Leangsuksun, Hertong Song, and Lixin Shen. Reliability Modeling Using UML. In Proceedings of the International Conference on Software Engineering Research and Practice (SERP), pages 728{729, Las Vegas, Nevada, June 2003. [84] Akos Ledeczi, Greg Nordstrom, Gabor Karsai, Peter Volgyesi, and Miklos Maroti. On Metamodel Composition. In Proceedings of the 2001 IEEE International Con- ference on Control Applications (CCA), pages 756{760, Mexico City, Mexico, September 2001. [85] Bruce W. Leverett, Roderic G.G. Cattell, Steven 0. Hobbs, Joseph M. Newcomer, Andrew H. Reiner, Bruce R. Schatz, and William A. Wulf. An Overview of the Production-Quality Compiler-Compiler Project. IEEE Computer, 13(8):38{49, Au- gust 1980. [86] Ivano Malavolta, Henry Muccini, Patrizio Pelliccione, and Damien Tamburri. Pro- viding Architectural Languages and Tools Interoperability through Model Transfor- mation Technologies. IEEE Transactions on Software Engineering, 36(1):119{140, January 2010. [87] Sam Malek, George Edwards, Yuriy Brun, Hussein Tajalli, Josh Garcia, Ivo Krka, Nenad Medvidovic, Marija Mikic-Rakic, and Gaurav Sukhatme. An Architecture- Driven Software Mobility Framework. Journal of Systems and Software, 82(6):972{ 989, November 2010. [88] Sam Malek, Marija Mikic-Rakic, and Nenad Medvidovic. A Style-Aware Architec- tural Middleware for Resource-Constrained, Distributed Systems. IEEE Transac- tions on Software Engineering, 31(3):256{272, March 2005. [89] Sam Malek, Chiyoung Seo, Sharmila Ravula, Brad Petrus, and Nenad Medvidovic. Reconceptualizing a Family of Heterogeneous Embedded Systems via Explicit Ar- chitectural Support. In Proceedings of the 29th International Conference on Soft- ware Engineering (ICSE), pages 591{601, Minneapolis, Minnesota, May 2007. [90] Robert C. Martin, Dirk Riehle, and Frank Buschmann, editors. Pattern Languages of Program Design 3. Addison-Wesley Longman Publishing Co., Inc., 1997. 170 [91] MATLAB. www.mathworks.com/products/matlab/. [92] Steve McConnell. Code Complete. Microsoft Press, 2004. [93] Nenad Medvidovic and Richard N. Taylor. A Classication and Comparison Frame- work for Software Architecture Description Languages. IEEE Transactions on Soft- ware Engineering, 26(1):70{93, January 2000. [94] Daniel A. Menasce, John M. Ewing, Hassan Gomaa, Sam Malek, and Joao P. Sousa. A Framework for Utility-Based Service Oriented Design in SASSY. In Proceedings of the First Joint WOSP/SIPEW International Conference on Performance Engi- neering, pages 27{36, San Jose, California, January 2010. [95] Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and How to Develop Domain-Specic Languages. ACM Computing Surveys, 37(4):316{344, December 2005. [96] MetaEdit+ Workbench. www.metacase.com/mwb/. [97] Marija Mikic-Rakic, Sam Malek, and Nenad Medvidovic. Improving Availability in Large, Distributed Component-Based Systems via Redeployment. In Proceedings of the Third International Working Conference on Component Deployment (CD), pages 83{98, Grenoble, France, November 2005. [98] Parastoo Mohagheghi and Vegard Dehlen. Where Is the Proof? - A Review of Experiences from Applying MDE in Industry. In Proceedings of the 4th European conference on Model Driven Architecture Foundations and Applications (ECMDA- FA), pages 432{443, Berlin, Germany, June 2008. [99] Alexander Muzy and James J. Nutaro. Algorithms for Ecient Implementations of the DEVS & DSDEVS Abstract Simulators. In Proceedings of the 1st Open Inter- national Conference on Modeling & Simulation (OICMS), page 401407, Auvergne, France, June 2005. [100] Linda Northrop, Peter Feiler, Richard P. Gabriel, John Goodenough, Rick Linger, Tom Longsta, Rick Kazman, Mark Klein, Douglas Schmidt, Kevin Sullivan, and Kurt Wallnau. Ultra-Large-Scale Systems: The Software Challenge of the Future. Carnegie Mellon University, 2006. [101] Object Management Group. www.omg.org. [102] Object Management Group. MDA Guide, v1.0.1 edition, June 2003. [103] Object Management Group. Meta Object Facility (MOF) Core Specication, v2.0 edition, January 2006. [104] Object Management Group. Object Constraint Language, v2.0 edition, May 2006. [105] Object Management Group. Unied Modeling Language Superstructure, v2.1.2 edi- tion, November 2007. 171 [106] Richard F. Paige, Jonathan S. Ostro, and Phillip J. Brooke. Principles for Model- ing Language Design. Information and Software Technology, 42(10):665{675, July 2000. [107] Dewayne E. Perry and Alexander L. Wolf. Foundations for the Study of Software Architecture. ACM SIGSOFT Software Engineering Notes, 17(4):40{52, October 1992. [108] Gordon D. Plotkin. A Structural Approach to Operational Semantics. Technical Report DAIMI FN-19, Computer Science Department, Aarhus University, 1981. [109] Gordon D. Plotkin. The Origins of Structural Operational Semantics. Journal of Logic and Algebraic Programming, 60{61:3{15, July{December 2004. [110] Lawrence R. Rabiner. A Tutorial on Hidden Markov Models and Selected Appli- cations in Speech Recognition, pages 267{296. Morgan Kaufmann Publishers, Inc., 1990. [111] Mark-Oliver Reiser and Matthias Weber. Multi-Level Feature Trees: A Pragmatic Approach to Managing Highly Complex Product Families. Requirements Engineer- ing, 12(2):57{75, May 2007. [112] Roshanak Roshandel, Somo Banerjee, Leslie Cheung, Nenad Medvidovic, and Leana Golubchik. Estimating Software Component Reliability by Leveraging Architec- tural Models. In Proceedings of the 28th International Conference on Software Engineering (ICSE), pages 853{856, Shanghai, China, May 2006. [113] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unied Modeling Lan- guage Reference Manual. Pearson Higher Education, 2004. [114] Andre L. Santos, Kai Koskimies, and Antonia Lopes. Automating the Construction of Domain-Specic Modeling Languages for Object-Oriented Frameworks. Journal of Systems and Software, 83(7):1078{1093, July 2010. [115] Andre L. Santos, Antonia Lopes, and Kai Koskimies. Framework Specialization Aspects. In Proceedings of the 6th International Conference on Aspect-Oriented Software Development (AOSD), pages 14{24, Vancouver, Canada, March 2007. [116] Douglas C. Schmidt. Guest Editor's Introduction: Model-Driven Engineering. IEEE Computer, 39(2):25{31, February 2006. [117] Chiyoung Seo. Prediction of Energy Consumption Behavior in Component-Based Distributed Systems. PhD thesis, University of Southern California, Los Angeles, California, 2008. 172 [118] Chiyoung Seo, George Edwards, Sam Malek, and Nenad Medvidovic. A Framework for Estimating the Impact of a Distributed Software System's Architectural Style on its Energy Consumption. In Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA), pages 277{280, Vancouver, Canada, February 2008. [119] Chiyoung Seo, George Edwards, Daniel Popescu, Sam Malek, and Nenad Medvi- dovic. A framework for estimating the energy consumption induced by a distributed system's architectural style. In Proceedings of the 8th International Workshop on Specication and Verication of Component-Based Systems (SAVCBS), pages 27{ 34, Amsterdam, The Netherlands, May 2009. [120] Chiyoung Seo, Sam Malek, George Edwards, Daniel Popescu, Nenad Medvidovic, Brad Petrus, and Sharmila Ravula. Exploring the Role of Software Architecture in Dynamic and Fault Tolerant Pervasive Systems. In Proceedings of the 1st Interna- tional Workshop on Software Engineering for Pervasive Computing Applications, Systems, and Environments (SEPCASE), Minneapolis, Minnesota, May 2007. [121] Carol A. Sledge. Reports from the Field on System of Systems Interoperability Challenges and Promising Approaches. Technical Report CMU/SEI-2010-TR-013, Software Engineering Institute, Carnegie Mellon University, March 2010 2010. [122] Jonathan Mark Sprinkle. Metamodel Driven Model Migration. PhD thesis, Van- derbilt University, Nashville, Tennessee, 2003. [123] Janos Sztipanovits and Gabor Karsai. Model-Integrated Computing. IEEE Com- puter, 30(4):110{111, April 1997. [124] Hussein Tajalli, Josh Garcia, George Edwards, and Nenad Medvidovic. PLASMA: A Plan-based Layered Architecture for Software Model-Driven Adaptation. In Pro- ceedings of the 25th IEEE/ACM International Conference on Automated Software Engineering (ASE), Antwerp, Belgium, September 2010. [125] Richard N. Taylor, Nenad Medvidovic, Kenneth M. Anderson, E. James Whitehead, Jr., and Jason E. Robbins. A Component- and Message-based Architectural Style for GUI Software. In Proceedings of the 17th International Conference on Software Engineering (ICSE), pages 295{304, Seattle, Washington, May 1995. [126] Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. Software Architecture: Foundations, Theory and Practice. Wiley Publishing, 2009. [127] Unied Modeling Language. www.uml.org. [128] Andras Varga. The OMNeT++ Discrete Event Simulation System. In Proceedings of the European Simulation Multiconference (ESM), pages 319{324, Prague, Czech Republic, June 2001. 173 [129] Marcus Voelter. A Family of Languages for Architecture Description. In Pro- ceedings of the OOPSLA Workshop on Domain-Specic Modeling, pages 86{93, Nashville, Tennessee, October 2008. [130] Kurt C. Wallnau. Volume III: A Technology for Predictable Assembly from Certi- able Components. Technical Report CMU/SEI-2003-TR-009, Software Engineering Institute, Carnegie Mellon University, April 2003. [131] Jules White, James H. Hill, Sumant Tambe, Aniruddha Gokhale, Douglas C. Schmidt, and Je Gray. Improving Domain-specic Language Reuse through Software Product-line Conguration Techniques. IEEE Software Special Issue: Domain-Specic Languages and Modeling, 26(4):47{53, July/Aug 2009. [132] Wolfram Mathematica. www.wolfram.com/products/mathematica/. [133] Murray Woodside. Tutorial Introduction to Layered Modeling of Software Per- formance. Technical report, Department of Systems and Computer Engineering, Carleton University, May 2002. [134] H. Ye and H. Liu. Approach to Modelling Feature Variability and Dependencies in Software Product Lines. IEE Proceedings - Software, 152(3):101{109, June 2005. [135] Jing Zhang. Metamodel-Driven Model Interpreter Evolution. In Companion to the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), pages 214{215, San Diego, Cal- ifornia, October 2005. 174

Abstract (if available)

Abstract Software architecture models are specifications of the principal design decisions about a software system that primarily govern its structure, behavior, and quality. Architecture models provide a blueprint for how the system is implemented, serve as a basis for experimentation with and rationalization of design decisions, and enable the automation of software engineering tasks. Domain-specific languages (DSLs) are modeling languages that are defined and customized for a particular family of problems or systems (the domain). DSLs are able to concisely and intuitively express software architecture models because they natively include the design abstractions that are most useful and natural for the system under development.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Deriving component‐level behavior models from scenario‐based requirements

PDF

Techniques for methodically exploring software development alternatives

PDF

Domain-based effort distribution model for software cost estimation

PDF

Calculating architectural reliability via modeling and analysis

PDF

Design-time software quality modeling and analysis of distributed software-intensive systems

PDF

Architectural evolution and decay in software systems

PDF

A user-centric approach for improving a distributed software system's deployment architecture

PDF

Architecture and application of an autonomous robotic software engineering technology testbed (SETT)

PDF

Software connectors for highly distributed and voluminous data-intensive systems

PDF

Constraint-based program analysis for concurrent software

PDF

Automated repair of presentation failures in Web applications using search-based techniques

PDF

The incremental commitment spiral model process patterns for rapid-fielding projects

PDF

Process implications of executable domain models for microservices development

PDF

Improved size and effort estimation models for software maintenance

PDF

A reference architecture for integrated self‐adaptive software environments

PDF

Domain specific software architecture for large-scale scientific software

PDF

Proactive detection of higher-order software design conflicts

PDF

Analysis of embedded software architecture with precedent dependent aperiodic tasks

PDF

Software architecture recovery using text classification -- recover and RELAX

PDF

A unified framework for studying architectural decay of software systems

Asset Metadata

Creator Edwards, George Thomas (author)

Core Title Automated synthesis of domain-specific model interpreters

School Viterbi School of Engineering

Degree Doctor of Philosophy

Degree Program Computer Science

Degree Conferral Date 2010-08

Publication Date 08/06/2010

Defense Date 04/15/2010

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag automatic code generation,discrete event simulation,domain-specific languages,model-driven engineering,OAI-PMH Harvest,Software Architecture

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Medvidovic, Nenad (committee chair), Boehm, Barry W. (committee member), Gupta, Sandeep K. (committee member)

Creator Email gedwards@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-m3328

Unique identifier UC1171416

Identifier etd-Edwards-3819 (filename),usctheses-m40 (legacy collection record id),usctheses-c127-374413 (legacy record id),usctheses-m3328 (legacy record id)

Legacy Identifier etd-Edwards-3819.pdf

Dmrecord 374413

Document Type Dissertation

Rights Edwards, George Thomas

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Repository Name Libraries, University of Southern California

Repository Location Los Angeles, California

Repository Email cisadmin@lib.usc.edu