META-MODEL SEARCH: USING XPATH FOR SEARCHING DOMAIN-SPECIFIC MODELS RAJESH SUDARSAN

Transcription

1 META-MODEL SEARCH: USING XPATH FOR SEARCHING DOMAIN-SPECIFIC MODELS by RAJESH SUDARSAN A THESIS Submitted to the graduate faculty of The University of Alabama at Birmingham, in partial fulfillment of the requirements for the degree of Master of Science BIRMINGHAM, ALABAMA 2004

2 ABSTRACT OF THESIS GRADUATE SCHOOL, UNIVERSITY OF ALABAMA AT BIRMINGHAM Degree M.S. Name of Candidate Committee Chair Program Computer Science Rajesh Sudarsan Jeff Gray Title Meta-Model Search: Using XPath for Searching Domain-Specific Models Model-Integrated Computing (MIC) is a model-based approach to software development, facilitating the synthesis of application programs from models. MIC employs domainspecific models to represent the software, its environment, and their relationship and is well-suited for the rapid design of complex computer-based systems. With MIC, a modeling environment operates according to a modeling paradigm, which is a set of requirements that govern how a system within a domain is to be modeled. The modeling paradigm is captured in the form of formal modeling language specifications called a meta-model. The Generic Modeling Environment (GME) is a meta-programmable tool that is based on the principles of MIC. A common task that is often needed in many tools is the capability to search the artifact that is being created. This capability is often absent in meta-programmable modeling tools like the GME. This can be a serious disadvantage as the size of a model increases to thousands of modeling elements. As a remedy, this thesis discusses a method to search the domain model using XPath a W3C standard that uses logical predicates to search a XML document. To support this research, an XPath search engine was developed that traverses the internal GME representation of the domain model rather than searching an XML file and returns those model entities that match the XPath predicate expression. ii

3 ACKNOWLEDGMENTS I offer my sincere gratitude to my advisor Dr. Jeff Gray, for his attention, guidance, insight, and support during my research and the preparation of this thesis. I would also like to thank Dr. Barrett Bryant and Dr. Alan Shih for their constructive comments and suggestions during the course of this research. Finally, special thanks and loving appreciation to my parents, my family, and my friends for their continuous guidance and support. iii

4 TABLE OF CONTENTS Page ABSTRACT... ii ACKNOWLEDGMENTS... iii LIST OF TABLES... vi LIST OF FIGURES... vii LIST OF LISTINGS... ix LIST OF ABBREVIATIONS...x CHAPTER 1 INTRODUCTION... 1 Example Domains for Applying Search Techniques...2 Search Strategies in Text Preparation Tools...2 Web Search Strategies...4 Search Strategies in Software Development Tools...5 Problem Identification and Thesis Statement...6 Outline of Remaining Chapters OVERVIEW OF SEARCH UTILITY IN DEVELOPMENT TOOLS... 8 Introduction...8 JQuery...8 XQuery...10 XPath...15 Tree Structure of XML documents...16 Expressions...17 Absolute and Abbreviated Location Paths...26 An XPath Example...28 XML Document...28 Sample XPath Expressions...28 iv

5 TABLE OF CONTENTS (Continued) Page 3 DOMAIN-SPECIFIC MODELING AND THE GENERIC MODELING ENVIRONMENT Modeling Concepts Overview...31 The Modeling Paradigm...31 The MultiGraph Architecture...32 Meta-Models and Modeling Environment Synthesis...36 GME...40 GME Modeling Concepts...41 Comparison Between GME and Other Modeling Tools...42 Meta-Modeling...43 Constraint Management...43 Visualization...43 Extensibility XPATH MODEL SEARCH Motivation...45 XMOS Plug-in...47 XMOS Modules...48 XPath Evaluator...48 Translator...50 GME BON...51 Search...54 User Interface...58 Metrics...59 Problems and Limitations in Implementation...59 Case Study...60 Boeing Bold Stroke Mission Computing Avionics Framework...60 ESML...60 Test cases SUMMARY AND CONCLUSION LIST OF REFERENCES...70 v

6 LIST OF TABLES Table Page 1 List of operators for an XPath expression...27 vi

7 LIST OF FIGURES Figure Page 1 Screenshot of Microsoft Word search tool Special character codes available for searching Google advanced search options Screenshot of JQuery browser in Eclipse Equivalent tree representation of the XML document Multigraph Architecture Four layered meta-modeling architecture Meta-model for finite state machine Constraint-based meta-model for an FSM A domain-specific model of an ATM teller machine Hierarchical representation of the entities in GME Existing find utility in GME Architecture of the XMOS plug-in Input for XPath Expression Code snippet of the storetoken Class Code snippet from the iinterpreter module Classes in the Builder Object Network Sample code using the methods available in BON Code snippet of the search module (branching for /, // and *)...56 vii

8 20 Source code for staroperator in the search module Screenshot of the XPath Model Search plug-in (XMOS) Bold Stroke component interaction represented in ESML Internal representation of BM PushPullComponent in ESML Result for case Result for case Result for case Result for case viii

9 LIST OF LISTINGS Listing Page 1 An element constructor XQuery expression Snippet of an XML document Usage of FLWOR expression Use of quantified expressions A sample XML file An XML file for XPath axes example CD catalogue XML document...28 ix

10 LIST OF ABBREVIATIONS API BON CBS COM CORBA DCOM DSME EJB ESML FCO FLWOR FSM GME IDE IR MDA MFC MGA MIC MIPS Application Programmer Interface Builder Object Network Computer-Based Systems Component Object Model Component Object Request Broker Architecture Document Component Object Model Domain-Specific Modeling Environment Enterprise Java Beans Embedded Systems Modeling Language First Class Object For-Let-Where-Order-Return Finite State Machine Generic Modeling Environment Integrated Development Environment Information Retrieval Model Driven Architecture Microsoft Foundation Classes MultiGraph Architecture Model-Integrated Computing Model-Integrated Program Synthesis x

11 MOF OCL OMG PLA QoS SQL SSPF UI UML URI VB W3C XML XMOS XSLT Meta-Object Facility Object Constraint Language Object Management Group Product-Line Architecture Quality of Service Structured Query Language Saturn Site Production Flow User Interface Unified Modeling Language Uniform Resource Identifier Visual Basic World Wide Web Consortium Extensible Markup Language XPath Model Search Extensible Stylesheet Language Transformations xi

12 1 INTRODUCTION The theory of Information Retrieval (IR) [36, 53, 63] is focused on the science of data collection and management, in association with mechanisms that provide rapid access to the collected information [4, 30]. The retrieval of stored information involves accessing, manipulating, and displaying data according to the user s requirements. Information retrieval differs from traditional data retrieval techniques [3] in the way queries on the information are interpreted. A majority of data retrieval techniques (e.g., Structured Query Language (SQL) queries to extract data from the database [29]) operate by searching for an exact match of the data in the database. In comparison, IR generally searches for items that partially match the given requirements and then selects the best item out of the selection. In many domains, the vastness of available information makes it difficult to find the right information among the noise generated from false positive matches. In such cases, it is important to retain and organize the given facts in such a way that rapid retrieval is possible. For many common tasks (e.g., word processing, web usage, or software development), searching for a particular item is often time-consuming. The replacement of a naïve and inefficient search method with one that is useful and intelligent, often leads to a substantial increase in retrieval speed. In fact, perhaps one of the most famous volumes in computer science devotes much discussion to the topic of searching [21]. An efficient search tool or technique is essential to retrieving correct information rapidly.

13 2 Example Domains for Applying Search Techniques The keys to successful search involve choosing the correct search tool and knowing how to properly apply the available search strategies. Search tools are a common feature in most application programs. As the necessity for precision searching increases, users will desire more options in order to prune the search space in additional contexts. The following sections briefly highlight the capabilities of commonly available searching techniques. Search Strategies in Text Preparation Tools Searching from a specified keyword is the feature supported most commonly by search tools. For example, using the Find/Replace [22, 23] tool in Microsoft Word as an example (Figure 1), a user can find and replace a specified text, and replace the formatting, paragraph marks, page breaks, and other items. Support for wildcards and regular expressions can add additional flexibility to the search technique. In the domain of text preparation tools, special codes may be included in the search expression (e.g., paragraph mark (^p), tab character (^t), line break (^l)) to assist in detecting formatting attributes in a document. In the case of the Find/Replace utility, there are options for specifying whether to use wildcards for searching, or match case, or match only the whole words. A user can also be given the option of specifying whether the text to be searched sounds like an English word. Figure 2 gives a list of special characters available to users in Microsoft Word.

14 3 Fig. 1. Screenshot of Microsoft Word search tool Fig. 2. Special character codes available for searching

15 4 Web Search Strategies In Web-based searching (e.g., Google) [5], the key task is to sift through noise to rule out false positives amid a mass of possible matches. A number of options are provided to assist a Web surfer in minimizing the size of the retrieved search result. The advanced search options permit the user to specify whether he or she wants to search using all the words, only the exact phrase, or any of the words specified. The user can also instruct the search engine to fetch only those pages that have been modified after a certain date, or those pages that are available only in a particular language. The user can also search the keywords using Boolean conditions. The ability to provide multiple search options offers tremendous assistance in attaining satisfactory results. As the vastness of a specific search domain expands, it also increases the number of options required to minimize the search results. Fig. 3. Google advanced search options

16 5 Figure 3 shows the advanced search feature in the Google search engine. The accuracy of the search result can be increased by selecting the appropriate options. The advanced search option can also be specified using the advanced search operators that are available on the advanced search page of Google. Search Strategies in Software Development Tools An important feature that needs to be present in any program development environment is the ability to search/replace and edit the properties of an application under development. In Integrated Development Environment (IDE), such as Visual Studio [59] and Eclipse [50], searching is restricted to finding the keywords, constants, and variables used in that environment. The search keyword can also be a regular expression in Visual Studio. Searching also plays an important role in domain-application modeling during software development. The term domain generally denotes a group of entities that share the same characteristics or exhibit similar functionality. From a software engineering perspective, domain refers to the class of existing systems of a single product-line architecture (PLA)[1, 34]. A software product line, or PLA, is a set of software systems that share a set of common features or have a common architecture. The products that will be developed using this architecture will have these common properties in addition to the specific properties needed to make the product unique. Thus, the models that are developed to denote the characteristics of such systems are referred to as domain models [10, 15]. Domain engineering [48] focuses on the creation of domain models and architectures that aid in building reusable software components. The domain model often

17 6 evolves over time as users modify the system to meet changing requirements. The model that is described in the domain has properties that are common to the domain. These models are used by application developers to understand the functionalities and capabilities offered by the current PLA and to build systems based on such models. The searching of models through an application domain involves matching the search string with the property value of every model that describes it. Unlike the programming environments, the tools available in the modeling environment do not support advanced search capabilities, such as using expressions for searching, which reduces the flexibility of the search. Problem Identification and Thesis Statement In modeling tools like the Generic Modeling Environment (GME) [24, 26, 28], there are a limited number of search options available to the user to locate a particular kind of model. The current feature requires the user to provide the value of the artifact to be searched. If an exact match is not found, then the search result will be null. However, this feature will not be helpful when the user wants to provide a domain range of values for searching the artifact. Thus, in the case of current modeling tools, a search string cannot include an expression involving relational operators. This research discusses the development of a minimal, but scalable, solution for adding advanced features and flexibility to the search feature of modeling tools. The research discusses a method to search efficiently for a modeled artifact using XPath (See Chapter 2). In this research, XPath is used with an application development environment for developing a search plug-in. A plug-in is a small piece of software that adds

18 7 additional features to a larger software application. This plug-in is customized to work with the GME, a visual programming environment toolkit for creating domain-specific models [17]. Due to the limitations in the existing search utility in GME, this research aims to provide a more complex and flexible search technique for an efficient searching of models in GME. The tool will be initiated from the GME menu. The search predicate is specified using a query string written in XPath, and the output of the search is a list of all models that match the given predicate. Outline of Remaining Chapters The remaining chapters provide a review of the related literature for the investigated research as well as concluding remarks. Chapter 2 surveys the literature on query languages that are available to specify search tasks in software development. Query languages such as JQuery [7, 16, 45], XQuery [69], and XPath [37, 67] are compared. Chapter 3 discusses in detail the literature on modeling and meta-modeling [25], as used in this thesis. It also briefly discusses specific topics of the GME toolkit [24, 26, 28] that are relevant to this research. Chapter 4 describes the investigation into model search and the implementation of a prototype plug-in. A summary chapter provides a conclusion to the thesis.

19 8 OVERVIEW OF SEARCH UTILITY IN DEVELOPMENT TOOLS Introduction There are numerous tools and techniques that are based on the principle of searching using regular expressions (e.g., JQuery [7, 16, 45], XQuery [69], and XPath [37, 67]). JQuery is a query-based code browser. XPath is a language for addressing parts of an extended markup language (XML) document and is extensively used in both extensible stylesheet language transformations (XSLT) [70] and XPointer [68]. XQuery is a query language that uses the structure of XML intelligently and can express queries across all types of data, whether physically stored in XML or viewed as XML via middleware [2]. This chapter provides a description of these related approaches. A large section of the chapter is devoted to a description of XPath, which plays a key role in this research. JQuery The JQuery [54] tool is developed by the Software Practices Lab at the University of British Columbia. The initial focus of JQuery was to develop an Eclipse [50] plug-in to enable identification of software artifacts. It is a flexible, query-based Java source code browser, which allows users to create different browser views depending upon the input query. A JQuery user can formulate independent logic queries and execute them against the source code at runtime. Each query, when executed, defines a unique browser view for the source code under test. The user can either choose from a variety of existing

20 9 queries or modify the existing queries to create new browser views. Individual elements in the tree can then be queried individually in the same fashion. The user also has the flexibility to specify the way the query results are organized. The results can be viewed in a hierarchical tree viewer using a simple variables editor interface. Figure 4 shows the view of a JQuery browser inside Eclipse. Fig. 4. Screenshot of JQuery browser in Eclipse In JQuery, a user can either edit the existing global queries or add new queries. The above screenshot shows an edit query dialog box. When the user right-clicks on the query dialog box, JQuery provides a list of templates for the available queries. TyRuBa

21 10 [46] forms the foundational support for JQuery. TyRuBa is a logic programming language implemented in Java. The JQuery query language is defined as a set of TyRuBa predicates that operate on facts generated from the Eclipse JDT's abstract syntax tree. XQuery XML [14, 62, 66] is a cross-platform, extensible, text-based standard for storage and representation of data. It is extensible because, unlike HTML, it does not have a predefined format for representation of data. XML is one of the most important technologies for the development of Web services. It was mainly designed to improve the functionality of the web by providing more flexibility to the representation of information. To use this flexibility to full potential, a query language was required to retrieve individual documents, to perform context-sensitive searching, to provide dynamic indexing, to transform data into new XML representations, and to perform queries on documents with embedded data (e.g., catalogues, patient health records, and employment records). XQuery [69] was designed to meet these requirements. The standardization of XQuery can be used not only with XML, but also with those formats similar to XML-nested, named trees with attributes. XQuery is a functional language in which each query is an expression that evaluates to a value. An XQuery program is just an expression (Boolean, arithmetic, conditional, or logical) that is specified together with some optional attributes. The standard specifies the result of the expression but does not specify how it will be calculated.

22 11 The data model that XQuery uses is based on that of XPath [11, 37] and XML Schema, which defines each XML document as a tree of nodes. XQuery is a version of XML syntax called XQueryX. The primitive data types used in XQuery are numbers, Boolean values, strings of characters, data types to represent date and time, and other XML-related data types. The contexts with respect to which the expression is evaluated are namespaces, variables, functions, date and time, context item (current node or atomic value), context position (in the sequence being processed), and context size (of the sequence being processed). In XQuery, there are seven main types of expressions that can be used with both sequential and nested input files. These expressions are as follows: 1. Path Expressions: Path expressions are based on the syntax of XPath, the XML standard for specifying paths in an XML document. These are the simplest kinds of query expressions. For example, the following is a simple path expression: document( ATM.xml ) //activity[title= Deposit ]//amount[@value] The result is the list of different amounts deposited in the ATM machine. The result is given as a list of XML fragments, each rooted with an amount element. The initial context for the path expression is given by the document ( ATM.xml ). 2. Element Constructors: This type of expression is used when a query needs to create new element nodes. Each new node will have a namespace associated with it. These namespaces affect the serialization of these newly created element nodes. Listing 1 shows

23 12 an example of an element constructor XQuery expression. In element constructors, an XQuery expression is enclosed within { and }. In the above expression, the variables $name, $depto, $id, and $NETspecialist will evaluate to its corresponding value and construct an element node, as shown in Listing 2. <employee empid="{$id}"> <name>{$name}</name> <job>{$job}</job> <deptno>{$deptno}</deptno> <salary>{$netspecialist }</salary> </employee> Listing 1: An element constructor XQuery expression 1 <employee empid="101010"> 2 <name>john Doe</name> 3 <job>software Analyst</job> 4 <deptno>300</deptno> 5 <salary>111000</salary> 6 </employee> Listing 2: Snippet of an XML document In addition, these constructors can also be associated with constant values instead of variables. 3. FLWOR: The main engine of XQuery is the FLWOR expression. FLWOR is the acronym for For-Let-Where-Order-Return. This query expression generalizes the SELECT-FROM-HAVING-WHERE construction in SQL [13]. The if-then-else construct is also embedded inside the FLWOR construct. The FLWOR expression supports iteration and binding of intermediate results. Listing 3 shows an example usage

24 13 of a FLWOR expression. For will bind the department number to variable $d and generate an ordered list of the bindings. The let statement will further create an ordered list binding the employee number to variable $e. for $d in document("depts.xml")//deptno let $e := document("emps.xml")//employee[deptno = $d] where count($e) >= 10 order by avg($e/salary) descending return <big-dept> { $d, <headcount>{count($e)}</headcount>, <avgsal>{avg($e/salary)}</avgsal> } </big-dept> Listing 3: Usage of FLWOR expression The Where statement filters the list depending upon the input condition. Order will sort the list by the given criteria. Return constructs a result for each tuple. The result in this case is a list of departments with at least 10 employees, sorted by their average salaries. 4. Expressions involving operators and functions: XQuery provides the functionality of various operators and functions similar to those available in computer languages (e.g., arithmetic operators, comparison operators, logical operators, and sequence-related operators). Some of the built-in functions in XQuery include AVG, SUM, COUNT, MAX, and MIN, in addition to the XML document and node set-related functions such as DOCUMENT, EMPTY and DISTINCT.

25 14 5. Quantified Expressions: Quantified expressions are used to quantify items in a given node set, or decide on the properties of all of the elements in a list. The most commonly used expressions are some-in-satisfies and every-in-satisfies. Through the some-insatisfies expression it is possible to identify whether at least one node of a set of nodes satisfies a predicate. The every-in-satisfies expression is used to test whether all nodes of a set satisfy a predicate. The evaluation of these quantified expressions always returns true or false. for $b in document("bib.xml")//book where some $p in $b//paragraph satisfies (contains($p,"sailing") AND contains($p,"windsurfing")) return $b/title Listing 4: Use of quantified expressions The Quantified expression in Listing 4 for the some-in-satisfies expression will list all books that contain sailing and windsurfing in the same paragraph. 6. Expressions that test or modify data types: XQuery supports standard data types (based on XML Schema's type system [47]), as well as user-defined data types. Constants can be written using literals (such as string, integer, and float) or constructor functions (such as true(), date( )). An instance of operator allows runtime validation of any value relative to the data type or XML Schema. A typeswitch/case operator allows branching based on the data type.

26 15 XPath XPath is a XML Path language [52, 60] whose primary purpose is to select parts of an XML document. XPath 2.0 can be described as an expression language for the evaluation of sequences with support to query XML documents. XSLT [70] is a language that is used to transform one XML document to another XML document. XSLT is designed to be used with XSL, which is a styling language for XML. XSL specifies the styling of the XML document s transformation into a new XML document. XPointer [37, 68] is an XML Pointer language that is used to locate a resource whose Internet media type is text/xml, application/xml, text/xml-external-parsed-entity, or application/xml-external-parsed-entity for any given Uniform Resource Identifier (URI). URI is a short string that identifies a resource on the World Wide Web. Because XPointer is based on XPath, it supports the addressing of nodes of XML documents. The choice of the nodes in a XML file is based on various properties, such as element type, attribute value, character content, and relative position. XPath provides a common syntax and semantics so that its functionality can be used with both XSL Transformations and XPointer. In addition to this, XPath also provides basic facilities for manipulation of strings, numbers, and Boolean data types. When compared with XQuery, the language syntax of XPath is defined in a stricter fashion. XPath expressions [11] usually operate on the abstract, logical structure of an XML document. XQuery uses XPath for specifying a path expression. In addition to its use in addressing XML documents, an XPath expression specifies a pattern that can be used for matching and checking whether a node matches the pattern.

27 16 Tree Structure of XML documents XPath models an XML document as a tree of nodes. There are different types of nodes, including element nodes, attribute nodes, and text nodes. The abstract document model that XPath uses divides each XML document into seven types of nodes: 1. Root It specifies the document itself. 2. Element It identifies an element in the tree. Its children are the text nodes, comments, processing instructions, attributes, namespaces or another element node. 3. Text It is the total uninterrupted text between two tags (including the white space). 4. Attribute It defines an attribute for a node other than the namespace. 5. Comment It is the additional information that describes the node. 6. Processing Instruction It is the processing instruction data for the node. 7. Namespaces It is a namespace mapping in scope on an element. Listing 5 shows a sample XML file. This file stores the information about withdraw and deposit transactions from a bank account. <?xml-stylesheet type="text/xsl" href="cat.xsl"?> <transaction date=" "> <deposit pin="id2345"> <title>depositing Money</title> <!-- Are we sure the pin is right??? --> <amount> </amount> </deposit> <withdraw pin="id7823"> <title>withdrawing Money</title> <!-- Are we sure the pin is right??? --> <amount> </amount> </withdraw> </transaction> Listing 5: A sample XML file

28 17 Figure 5 represents the equivalent tree representation of the XML file from Listing 5. The symbols in the text circle represent the values of the attributes and element nodes. Kind of Nodes Root Transaction Element Attribute Text Root Deposit Withdraw date pin title comment amount title comment amount pin Fig. 5. Equivalent tree representation of the XML document Expressions The primary construct in XPath is the expression that forms the syntactic building blocks in XPath. The different kinds of XPath expressions are as follows: 1. Primary expressions These include strings, numbers, Boolean, location paths, predicates, function calls, and variable reference. 2. Complex expressions These include unions, filters, and relational expressions. The evaluation of an XPath expression produces an object, or a collection of objects that exist in the associated XML tree. Four fundamental data type objects can be returned as a result from an XPath expression:

29 18 1. Node-set. 2. Boolean. 3. Number. 4. String. The XPath expression syntax has operators and functions to manipulate all four data types, in addition to the literal forms for strings and numbers. Expression evaluation in XPath always occurs with respect to a context. At runtime, XSLT and XPointer specify the context for an XPath expression. This is because the templates are always associated with a specific source node in XSLT, starting with the document root node that is associated with the root template (match= / ). In XSLT, this source node is referred to as a current node and provides the context for evaluating the XPath language expression within the template. Primary expression. The XPath expression syntax includes literal forms for strings and numbers as well as operators and functions for the manipulation of XPath data types. The primary use for XPath literals and operators is predicates. The different expression constructs are as follows: 1. Literals: XPath uses literal numbers and strings, and supports all numbers in the form of integers, decimal numbers, or double-precision floating point numbers. Decimal numbers denoted in exponential form are treated as double-precision floating point numbers. The XPath string literals are denoted in single or double quotes. For example, models or models represent the same string literal. There are no

30 19 Boolean or node-set literals. 2 Operators: XPath provides the following operators for basic floating point arithmetic: Addition (+), Subtraction (-), Multiplication (*), Division (/), and Mod operator (%). Other operators provided by XPath for comparisons and boolean logic in an expression are <, >, <=, >=,!=, =, or (Boolean or), and (Boolean and). 3. Functions The different kinds of functions defined by XPath operate on and return the four fundamental XPath data types. Some functions take a variable number of arguments, and other functions that do not have an argument operate on the context node. XPath has the capability to automatically convert the arguments to the required data type. Some of the different types of functions are as follows: Node-set functions Some of the node-set functions defined in XPath are as follows: 1. number last() Returns the number of nodes in the context node list that is same as the last node in the list. 2. number position() Returns the position of the context node in the context node list. 3. string local-name (node-set?) Returns the full prefixed name of the first node in the argument node-set, or the name of the context node if the argument is omitted. 4. node-set id (object) Returns the node-set containing the single element node with the specified id determined by the ID attribute.

31 20 String functions Some of the string functions defined in XPath are: 1. string string (object?) Returns the string value of the argument. 2. string concat (string, string, string...) Returns the string after concatenating all its arguments. 3. Boolean starts-with (string, string) Returns true if the first string starts with the second string. 4. Boolean contains (string, string) Returns true if the first string contains the second string. Boolean functions Some of the boolean functions defined in XPath are as follows: 1. Boolean Boolean (object) Converts the argument to a Boolean variable. 2. Boolean not (boolean) Returns true into false and false to true. 3. Boolean true() Function always returns true. 4. Boolean false () Function always returns false. Number functions - Some of the number functions defined in XPath are as follows: 1. number number (object?) This function converts string objects into numbers. For example 53 and will be converted to their appropriate numeric values. 2. number floor (number) Returns the largest integer less than or equal to the argument. 3. number ceiling (number) Returns the smaller integer less than or equal to the argument.

32 21 Arithmetic expressions. XPath provides arithmetic operators for addition, subtraction, di vision, multiplication, and modulus. In subtraction, the operator must be preceded by a white space; otherwise, it will be interpreted as a variable. For example, a b will be interpreted as a name, and a b or a b will be treated as an operation. XPath supports two types of division operators- div and idiv. The div operator returns a decimal result, whereas idiv returns an integer value. Location path expressions. One important kind of expression is a location path. A location path selects a set of nodes relative to the context node. This set may be empty, may contain a single node, or may contain several nodes. These nodes can be element nodes, attribute nodes, text nodes, or a combination of any of the seven types of nodes. A location path is built out of successive location steps. Each location step has an axis, a node test and, optionally, one or more predicates. 1. Axes. An axis [33] in a location step specifies the tree relationship between the context node and the nodes selected by the location step. An axis specifies the direction along which a location step should move. There are thirteen types of axes that are generally used in predicates in a location path. Each of these axes selects a different subset of nodes depending upon the context node on which it acts upon. Of these thirteen axes, self, child, descendent-or-self, parent, and attribute are used in the abbreviated location path syntax whereas descendent, ancestor, ancestor-or-self, preceding, preceding-sibling, following, following-sibling, and namespace are used with the unabbreviated location path syntax. The difference between the two categories is the use of a double colon (::) between the axes and the node test in case of unabbreviated location

33 22 path syntax. Consider the following XML file (Listing 6) that stores the information about the different shares with their market quotes (The following example is adapted from [62]). Assume that the context node is the middle Quote element whose value is Reliance. The set of node(s) for each of the above mentioned axes are as follows: a. The self axis is the node itself. In this case, it contains one node, the middle Quote element (i.e., the context node). b. The child axis contains all child nodes of the context node. In this case, it contains one node: an element node with the local name Price. c. The descendant axis contains all nodes completely inside the context node. All the child nodes will be recursively added until the innermost child is reached. In this case, it contains two nodes: an element node with the local name Price and a text node with the value "24.85," in that order. d. The descendant-or-self axis contains all descendants of the context node and the context node itself. In this case, it has three nodes: an element node with the local name Quote, an element node with the local name Price, and a text node with the value "24.85," in that order. e. The parent axis returns the node that most immediately contains the context node. In this case, it contains a single element node with the local name Body. f. The ancestor axis contains the root node and all the element nodes that contain the context node. In this example, it has three nodes: an element node with the local name Body, an element node with the local name Market, and the root node in that order.

34 23 <?xml version="1.0"?> <Market xmlns:xlink=" xmlns=" <Body> <Quote symbol="infosys"> <Price currency="usd">7.02</price> </Quote> <Quote symbol="reliance"> <Price currency="usd">24.85</price> </Quote> <Quote symbol="larsen"> <Price currency="usd">68.59</price> </Quote> </Body> </Market> Listing 6: An XML file for XPath axes example g. The ancestor-or-self axis returns all ancestors of the context node and the context node itself. In this example, it contains four nodes: an element node with the local name Quote, an element node with the local name Body, an element node with the local name Market, and the root node in that order. h. The preceding axis contains all non-attributes, non-namespace nodes that come before the context node in the document order and do not contain the context node. In this case the axis contains four nodes: a text node containing the string 7.02, an element node named Price, an element node named Quote, and a comment node, in that order. i. The preceding-sibling axis contains all non-attribute, non-namespace nodes that come before the context node in the document order and that have a common parent. In this case it has one node: an element node with the name Quote and the symbol Infosys.

35 24 j. The following axis contains all non-attributes, non-namespace nodes that follow the context node in document order and that are not descendants of the context node. In this case it has three nodes: a Quote element node, a Price element node, and a text node containing the string k. The following-sibling axis results all non-attribute, non-namespace nodes that follow the context node in document order and have the same parent node. Here, it contains one node: an element node with the name Quote and the symbol Larsen. l. The attribute axis contains the attributes of the context node. In this case, it has one attribute node with the name symbol and the value Reliance. m. The namespace axis contains two namespace nodes, one with the name xlink and the value and the other with an empty string name and the value. Thus, the result of evaluating an expression that is a location path is the node-set contain ing the nodes selected by the location path. Location paths can recursively contain expressions that are used to filter sets of nodes. 2. Node tests. The node test specifies the types of the nodes that will be selected by the location step along the specified axis. The different node tests are Name, *, prefix:*, comment(), text(), node(), processing-instruction(), and processing- To understand the use of these node-test functions, consider the instruction( value ). previous sample XML file in Listing 6. Let the context node be the middle Quote element

36 25 with attribute value Reliance. Some of the sample location paths using node-test functions are as follows: a. self::* selects the middle Quote element that serves as the context node. b. descendant::text() This node test function text() selects any text node. In this case, it selects those text nodes that are descendents of the context node. The result is a set of one node: a text node with the value c. preceding::comment() This location path will select all the comment nodes that precede the context node. In this case, it returns an empty node-set, as there are no comments in the XML document. d. following-sibling::processing-instruction() Because there are no processing instructions in the XML document, the above location path returns an empty node-set. e. ancestor::node() This location path will select any ancestor node of the current context node (i.e., text node, attribute node, or element node). 3. Predicates. The predicates further filter the node set selected by the location step. Every predicate is an XPath expression and is denoted by square brackets ( [] ). Predicates are evaluated for each node selected by the location step. The result is either a numeric value or a Boolean value. If the result is a numeric, then XPath compares the number to the context position to the context node. If the number and the position match, then the predicate evaluates to true and the node is kept in the node-set. If the predicate does no t result in a number, then XPath converts the result into a Boolean value using the

37 26 boolean function. If the result is true, the node is kept in the current node-set; otherwise, it is removed from the current node-set. Some examples that show the use of location paths using predicates are given as follows. Assume that the mkt prefix is mapped to the namespace (The following example is adapted from [62]). 1. child::mkt:quote[child::mkt:price < 10] This location step returns a node-set containing all the Quote elements whose price is less than ten. 2. child::mkt:quote[string(attribute::symbol)] Because there is no Quote element with symbol as the attribute, the above location step will return an empty set. 3. child::mkt:quote[child::mkt:price] this location step finds those Quote children of the context node that have at least one Price child. Absolute and Abbreviated Location Paths The location paths in the predicates need not be always defined relative to the context node. The location paths defined without context nodes start with a forward slash (/). In such case, it means that the location path starts from the root node of the document. The following examples show the usage of absolute location path predicates. 1. /descendant::*/attribute:* This returns a node-set containing all attribute nodes in the document. 2. /descendant-or-self::node() This returns a node-set containing all non-attribute, non-namespace nodes in the document. 3. / This selects the root node of the document.

38 27 Instead of using the expanded syntax for the location paths, abbreviated syntax can be used. For example, 1. child::name can be replaced with name; 2. The predicate attribute::name can be replaced 3. parent::node() can be replaced by... XPath expressions are constructed using operators and special characters. Table 1 lists these operators and characters. / Child operator; selects immediate children of the left-side collection. // Recursive descent; searches for the specified element at any depth.. Indicates the current context. * Wildcard; selects all elements regardless of the element Attribute; prefix for an attribute Attribute wildcard; selects all attributes regardless of name. : Namespace separator; separates the namespace prefix from the element or attribute name. ( ) Groups operations to explicitly establish precedence. [ ] Applies a filter pattern. [ ] Subscript operator; used for indexing within a collection. Table 1: List of operators for an XPath expression In this research towards developing an XPath search plug-in, only a subset of the above functions and operators is implemented, so a proof of concept for using XPath in an application domain will be established.

39 28 An XPath Example X ML Document The concepts for writing an XPath predicate using the literals, operators, and functions can be explained better with an example. Listing 6 shows an XML file that stores the catalog information about audio CDs. The information that is stored about each CD is the album name, artist name, and the price of the CD. Listing 6 gives a CD catalog XML document: <? xml version="1.0" encoding="iso "?> <catalog> <cd country="usa"> < album>the Wall</album> < artist>pink Floyd</artist> <price>10.90</price> </cd> <cd country="uk"> <album>patience</album> <artist>george Michael</artist> <price>9.90</price> </cd> <cd country="usa"> <album>the Very Best Of Rod Stewart </album> <artist>rod Stewart</artist> <price>9.90</price> </cd> </catalog> Listing 7: CD catalogue XML document Sample XPath Expressions The following XPath expressions can be used for the purpose of extracting information from the above XML document.

40 29 1. To display the price of all CDs. To display the price the XPath predicate should select all the price elements of all the cd elements of the catalog elements. Expression: /catalog/cd/price 2. List the title, artist and price of all CDs. This requires the selection of all the child elements of all the cd elements of the catalog element by the XPath predicate. Expression: /catalog/cd/* 3. List all information about everything in the catalogue This requires the selection of all elements in the document. Expression: //* 4. Select the first CD This requires selection of the first cd child element of the catalog element by the predicate. Expression: /catalog/cd[1] 5. Select the last CD This requires selection of the last cd child element of the catalog element by the predicate. Expression: /catalog/cd[last()] 6. Select the CD whose price is $10.90 For this the XPath predicate should select and return all the cd elements of the catalog element that have a price element with a value of Expression: /catalog/cd[price=10.90]

41 30 7. List all the countries of origin CDs present in the catalogue This requires selection of all attributes named country by the predicate. Expression: country 8. List those CDs that have some information associated with it. This requires selection of all cd elements that have any attribute by the predicate. Expression: 9. List all the album and the corresponding artist information This requires selection of all the album and artist elements of the cd element of the catalog element by the XPath predicate Expression: /catalog/cd/album /catalog/cd/artist

42 31 DOMAIN-SPECIFIC MODELING AND THE GENERIC MODELING ENVIRONMENT Computer-based systems (CBS) require a tight integration between information processing and the physical environment. Model-Integrated Computing (MIC) [6, 8, 42] addresses the problem of designing CBS by providing rich model analysis and modelbased program synthesis tools for developing domain-specific modeling environments [25]. MIC is often characterized by its approach using Model-Integrated Program Synthesis (MIPS) environments. It is a model-based approach to software development allowing the synthesis of application programs from models created using customized, domain-specific modeling environments. It uses meta-models to define the domain modeling language and model integrity constraints to ensure that the domain models are developed according to the semantics specified in the meta-model. These concepts are introduced in the following sections. Modeling Concepts Overview The Modeling Paradigm Models are an abstract representation of real-world systems or processes. A modeling paradigm defines the family of models that can be created using the resultant modeling environment. The process begins by formulating the domain s modeling paradigm. The modeling paradigm is a set of requirements that specifies the ontology of

43 32 the domain. It determines the manner in which models within that domain are to be created by describing the various entities that exist in the domain, and their associations. A meta-model for a domain is defined as the modeling paradigm captured in the form of a formal mo deling language. Meta-models contain descriptions of the entities, attributes, and relationships that are available in the target-modeling environment. A modeling environment can be configured from a meta-model. Both domain and modeling experts participate in the task of formulating the modeling paradigm. The modeling paradigm usually evolves to a stable form only after a significant amount of testing and use. This is due to the fact that the domain users generally find it difficult to specify the exact nature of the modeling environment. As the system matures, the modeling paradigm becomes stable. However, because the system itself must evolve, the modeling paradigm must change to reflect this evolution. Changes to the paradigm result in new modeling environments, and new modeling environments require evolution of previous models [39]. The MultiGraph Architecture In the past, support for modeling often resulted in tools that were not flexible and could only be used in specific contexts. The necessity arose for a single modeling tool that would support numerous domain-specific modeling paradigms; i.e., a tool that could be meta-configured based on high-level descriptions of the domain to which the environment would be applied. MultiGraph Architecture (MGA) [41] was developed as an architecture that would be able to differentiate between generic and domain-specific components and support the development of domain-specific models using meta-models

44 33 of the domain [32]. MGA was developed at Vanderbilt University as a toolkit for creating domain-specific MIPS environments. A MIPS environment operates according to a domain-specific set of requirements that describe how any system in the domain can be modeled. These modeling requirements specify the following information: 1. Types of entities and relationships that can be modeled and how to model them. 2. Entity relationship attributes. 3. The number and types of aspects necessary to partition the design space logically and efficiently. 4. How to represent, store, and retrieve the semantic information from the models. 5. Analysis requirements and run-time requirements. Figure 6 shows the components of the MultiGraph Architecture. The meta-level descriptions for a domain are specified as a set of formal specifications. A meta-level translation from the modeling language is then performed to synthesize the domainspecific modeling environment (DSME). The generated DSME consists of three main components that are used to build domain models and store it in a model database: a domain-specific model builder used to create and modify models of domain-specific systems, the models themselves, and one or more model interpreters used to extract and translate semantic knowledge from the models. The process of model building must satisfy two main criteria: 1. It should describe an artifact that uses a certain type of formalism, and

45 34 2. It should satisfy the constraints that capture the semantics of the domain. This integrated set of models may represent all or part of various domain-specific systems for a particular domain. The tool-specific model interpreters then translate the models into alternative software artifacts (e.g., synthesis to programming languages or simulation code). The translation often takes place in conjunction with code libraries and some form of middleware technologies. (e.g., Common Object Resource Broker Architecture (CORBA)[61], or Enterprise Java Beans (EJB)[51]). Meta Programming Interface Formal Specifications Environment Application DSME Model Builder Application Domain A1 A2 A3 Meta level Translation Models Model Interpretation Model Interpreters Fig. 6. Multigraph Architecture The MGA provides a rich set of graphical idioms for the meta-model to choose from to implement the entities and relationships of the application domain. Constraints in MIC are specified using the Object Constraint Language (OCL) [19, 44]. Explicitly defined constraints in MIC always result in the formation of a set in the modeling paradigm. An example of an OCL constraint is given below:

46 35 parts( Start )->size()=1 This constraint states that the number of instances of an entity named Start should not be more than 1. An example of a meta-model where this constraint can be used is shown in Figure 9. When changes in the overall system require new application programs, the models are updated to reflect these changes, the interpretation process is repeated, and the applications and data streams are automatically regenerated from the models. These new models, when used for the application development, reflect the new structure and behavior of the application, thus resulting in its evolution. Because all changes to the system are expressed using the domain-specific language (i.e., semantic domain) and not the implementation language, it supports greater changeability of the application. For example, consider the case of the Saturn automobile manufacturing plant in Spring Hill, Tennessee. The site has approximately 10,000 operations. Some of the operations include stamping, molding, fabrication, casting, machine assembly, and fluid fill. To increase the throughput, the company needs to constantly monitor and analyze the plant s functions and operation so that it can identify the production bottlenecks and other factors that require immediate action. In the company s traditional information system, the plant s relevant data is gathered, and then each operation s capacity is visualized and analyzed. These activities help in identifying the bottlenecks in the operation and formulate an engineering and business plan to resolve it. As a result, each time a solution had to be tested, the system had to be changed manually and the results re-recorded. This increased the production and maintenance cost of the plant and decreased the productivity. In order to provide a solution for this problem domain, the Saturn Site

47 36 Production Flow (SSPF) system was designed [18]. The different units in the manufacturing plant and the associated data were modeled using the MIC approach that identified the different entities and the relationships between them, and the properties that have a bearing effect on the production flow of the system. In case of a bottleneck in the operation, the team managers and the members were able to find an optimal solution by designing a new model or changing the existing models and executing the entire system. The verification and testing of the application could be done during the production without manually updating the system. The result of this approach increased the throughput by 10% [18]. In addition to this, changing the system according to the user s specifications and responding to changing business needs of the plant also became much easier. Meta-Models and Modeling Environment Synthesis The meta-modeling activity generally follows a four-layer conceptual framework. At the core of the MGA MIPS environment is the GME. This component is responsible for maintaining the model structures and providing operations to manipulate them. Metamodels consist of Unified Modeling Language (UML) class diagrams and OCL constraints. Figure 7 shows the layered framework for meta-modeling using the Meta- Object Facility (MOF) [56]. MOF is an Object Management Group (OMG) standard for representing meta-models. In the framework, the meta-modeling language is capable of defining modeling languages for a wide variety of domains. As a result, at the topmost level of the hierarchy, it describes itself in the form of the meta-meta-model. The meta-model

48 37 Metamodeling Language Meta-metamodel Language for defining metamodels Metamodel Specify Metamodeling Language An instance of a meta-metamodel. Defines the language for specifying a model. Model Specify Domain modeling Language An instance of a metamodel. Defines the language for describing the information domain. Specify Computer-Based System An instance of a model. Defines a specific information domain. Fig. 7. Four Layered meta-modeling architecture specifies the language or the semantics for defining meta-models. The domain models are defined using the domain modeling language that follows the semantics specified in the meta-model. These domain models are used to specify the CBS models. An example of a meta-model in GME designed for a Finite State Machine (FSM) is shown in Figure 8. The meta-model defines the semantics for modeling a FSM. The FSM has a Start state, an End state, and a normal State for denoting operations such as withdraw money, depositing money, and taking receipt.

49 38 Fig. 8. Meta-model for Finite state machine Fig. 9. Constraint-based meta-model for an FSM

50 39 Figure 9 shows an OCL constraint view of the FSM meta-model discussed above. This figure shows the usage of the constraint explained in the section The MultiGraph Architecture. An example of a domain-specific model constructed using the meta-model of Figure 8 for an FSM is given in Figure 10. Fig. 10. A domain-specific model of an ATM teller machine The Start state in the domain model corresponds to the semantics of the Start state in the meta-model. The other states (Ready, Card_Inserted, Validate_User, Withdraw, Deposit, Take_Receipt, and Receipt) are modeled using the State entity of the meta-model.

51 40 GME Domain-specific environments can be modeled using such well-known tools as Matlab/Simulink or Labview [64], the high cost involved in the development of these environments restricts them from being used for designing large environments. The GME [24, 26, 28] resolves this issue by providing a universal design environment that can be configured for a wide range of domains. GME uses the MIC approach to model domainspecific environments. Some of the features of GME include the following: It is used primarily for model-building. The models take the form of graphical, attributed entity-relationship diagrams. The dynamic semantics of a model is determined during the model interpretation process. It supports various techniques for building large-scale, complex models. These concepts are discussed in detail in the next section. It contains one or more integrated model interpreters that perform translation and analysis of models currently under development. Meta-modeling is the primary method to customize a GME modeling environment. The meta-modeling language in GME is based on the UML class diagram notation. All of the modeling semantics and the OCL constraints are automatically enforced in the target GME instance. Additional methods for customizing GME include decorators, interpreters, and add-ons. Decorators are simple software components that are used for domain-specific visualization of the models; they are based on the decorator pattern [1]. Interpreters and add-ons are external software components that interface with GME and provide additional domain-specific functionality, including code generation.

52 41 GME Modeling Concepts GME supports various concepts, such as hierarchy, multiple aspects, set, references and explicit constraints, for building complex domain-specific models [27]. In GME, a Project contains a set of Folders. Folders are containers in GME that are used to hold Models, Atoms, References, Connections, and Sets. Atoms are the elementary objects in GME that cannot be further subdivided. Each kind of atom is associated with a predefined set of attributes that can be later modified by the user. For example, if the user is designing a digital circuit model, then the AND gate, the XO R gate, and OR gate will form the fundamental, indivisible units of the design. These gates will be represented using atoms in GME. Models are compound objects that can contain one or more models, atoms, connections, sets, or references. The modeling paradigm determines what kinds of parts are allowed with each model, but the modeler determines the number of those parts using explicit constraints. Any object in the environment will have at most one parent, and that parent must be a model, except the root model, which does not have a parent. The simplest way to express a relationship between two objects in GME is with a Connection. Connections can be directed or undirected. In order to connect two entities, they must have the same parent in the containment hierarchy. References are used to associate different kinds of models at different levels of hierarchy, or different model hierarchies altogether. A reference must appear as a part in the model. This establishes the relationship between the model that contains the reference and the object that is referred to.

53 42 Comparison Between GME and Other Modeling Tools There are two other configurable environments that are comparable to GME in terms of supported features, the maturity of the environment, and the number of real- Sets are used to specify a relationship among group of objects. The only condition that must be satisfied by all the members of the set is that they should have the same parent and be visible in the same Aspect. The hierarchical representation of the entities in GME is shown in Figure 11. Root (Model) Atoms Models Sets Connections References Fig. 11. Hierarchical representation of the entities in GME. The GME has a modular and extensible architecture. External components for GME can be written in any language (C++, Visual Basic, C#, and Python) that supports the Component Object Model (COM) [40]. The GME has a built-in constraint manager that enforces all domain constraints during model building. GME provides meta-model composition for reusing and combining existing modeling languages and supports model libraries for reuse at the model level [20].

54 43 world applications that can be modeled. They are Dome, by Honeywell Laboratories [49], and MetaEdit+, by MetaCASE Consulting of Finland [43, 55]. The four key areas that are essential to providing support for widely different modeling methodologies are meta-modeling, constraint management, visualization, and extensibility. Meta-Modeling Dome and GME implement the functionality of meta-modeling as just another type of modeling paradigm. MetaEdit+ prompts the user with a series of dialog boxes to specify the meta-model in a non-graphical way. The validity of models due to modifications i n the meta-mo del is not handled completely in Dom e and MetaEdit+. In GME, new versions of meta-models do not affect existing models until they are explicitly upgraded to the new version [38]. Constraint Management Dome and MetaEdit+ handle only certain types of frequently used constraints. GME, on the other hand, has a full-featured constraint manager that supports OCL. To make the constraint management interactive and flexible, constraints are sometimes associated with editing of events and priorities. Visualization When compared to MetaEdit+ s built-in symbol editor, GME and Dome provide only the choice of simple built-in symbols and bitmap files provided by the user. For complex visualization, GME relies on user-defined drawing routines.

55 44 Extensibility The restricted and proprietary nature of the model interface in Dome and MetaEdit+ make it difficult to add new features. On the other hand, the component-based architecture of GME makes it easily extensible. The user has access to the meta and model information through the public COM interfaces. Events are also made public through the COM interfaces. When any component makes a change to the models, all other interested components are notified. The toolset can be extended using any programming language that supports COM. GME stores and outputs the model and meta information as an XML file. These advantages of GME make it more suitable for use as a standard toolkit in modeling any domain-specific environment. The modeled domain supports the changeability of the application through its domain-specific models. When the properties of the models are modified, it results in a new set of models having a different behavior. To achieve this changeability, the particular set of models whose property has been changed has to be located. Searching is therefo re required to locate a single model or a set of models from the modeled domain having specific attributes. The motivations of this research for an efficient search plug-in and its implementation details are discussed in the next chapter.

56 45 XPATH MODEL SEARCH Motivation Manual searching is feasible when the number of models in the domain is small. When the number of modeling elements grows exponentially (e.g., some models contain thousands of entities), then an efficient, scalable search technique is required to match the attributes and locate the models. The search feature currently available in GME is capable of searching through the models in a simplistic manner, but the number of attributes that can be matched is limited to those that are present in the output XML file. The current search utility also does not support composition of two or more search conditions to be expressed in a query. This leads to a serious disadvantage when the search domain contains thousands of entities. Another limitation in the search utility is the lack of case sensitiveness in the names of the objects to be searched. Figure 12 shows the current implementation of the search utility in GME. In this figure, the user specifies one or more of the following values: 1. Name of the model 2. Role name 3. Attribute name 4. Kind name 5. Data type (integer, float, String, or Boolean) 6. Value

57 46 The user s search string is restricted to the selection of one or more fixed checkboxes of the element type that the user wants to search (i.e., atoms, models, references, sets, inheritance references). Fig. 12. Existing find utility in GME The user cannot add wildcard characters or any inequality (such as < or >) as part of the search string, or search the domain using regular expressions. This reduces the flexibility in the search capability. To improve the efficiency of searching, the user must be able to synthesize new queries by composition of two or more queries. This research discusses the development of a search plug-in for GME that uses an XPath predicate to specify the search criteria. XPath was chosen to be the input language for specifying the search predicates due to its capability to traverse the hierarchical tree structure present in

58 47 GME. It also provides the user the flexibility to compose new search queries by joining two or more sub-queries. XMOS Plug-in The XPath Model Search (XMOS) plug-in (developed as a prototype of the model search concept) uses XPath predicates to define a search query. The plug-in can be used to locate the required objects in the model database. The current version of the plug-in does not provide the capability to replace the searched object by another object. The XPath query is specified using the entities present in the meta-model of the current domain. The query predicates, when parsed using an XPath parser, output tokens that can be used for searching through the models. The main modules involved in the building of this XPath search plug-in are as follows: 1. XPath Evaluator a. XPath Expression b. XPath Parser 2. Translator/Interpreter module 3. Builder Object Network (BON) Application Programmers Interface (API) 4. Search module 5. User Interface module The architecture of the XMOS plug-in is shown in Figure 13. The XPath Evaluator parses the input search predicate (an XPath expression) and provides a parse tree to the Translator/Interpreter module. The interpreter module organizes the tree into searchable tokens and stores them in a customized data structure. The XMOS plug-in uses these

59 48 tokens to search through the GME Builder Object list and outputs the objects that match the search criteria. The objects that can be searched using this plug-in are models, atoms, references, sets, and connections. XPath Evaluator XPath Expression Customized parsed tokens Translator (Customized Data Structure) XPath Parser GME Builder Object Network API Search Algorithm Model list User Interface Fig. 13. Architecture of the XMOS plug-in XMOS Modules The section presents an overview of the modules of XMOS. The user interface for the plug-in was developed in C++ using Microsoft foundation classes (MFC) [57]. XPath Evaluator The XPath Evaluator is divided into two main sub-modules: a module for receiving the input from the user, and a module for evaluating the input expression for its syntactic correctness and generating a parse tree for it. The input expression is given using an MFC edit box. Figure 14 shows a screenshot of the input dialog box.

60 49 The second sub-module is the XPath parser. The parser used in this plug-in is a part of the TinyXPath project [65]. The project is an open-source implementation of XPath specifications and evaluates an XPath expression on input XML files. The built-in parser evaluates the XML tree nodes and stores the intermediate results. Fig. 14. Input for XPath Expression The parser supports most of the XPath expressio ns and conforms to the W3C XPath specification, though there are some known limitations to the library. It reads in the input expression and checks the syntactic correctness of the expression. This parse tree is constructed in a customized manner for the syntactically correct expressions, and the tokens are stored in a stack. These to kens are extracted from the stack and stored in a vector as part of the storetokens class. Different get and set methods are provided to access this vector.

61 50 class storetokens{ private: vector <int> list; vector <char *> tokenstrings; vector <int> asciilist; public: storetokens(){tokenstrings.clear();} ~storetokens(){} void inserttokens(int token){list.push_back(token);} void inserttokens(char * token) {tokenstrings.push_back(token);} void insertasciitokenvect (vector <int> alist){asciilist=alist;} vector <char*> gettokens() {return tokenstrings;} vector <int> getasciilist() {return asciilist;} void settokens(vector <char*> tokenlist){tokenstrings.swap(tokenlist);} void PrintTokens(); void RemoveSpacesInAsciiList(); // void RemoveAmbiguity(); }; Fig. 15. Code snippet of the storetokens Class Translator The translator module uses the tokens from the storetokens object for interpretation. From the token list, every token is interpreted with respect to the previous token. For example, if the first token in the XPath expression is a slash (/), then the next expected node can be slash (/), star (*), or a node name. The first slash indicates that the searching starts from the root node. Thus, when slash (/) is encountered as a second consecutive token, the tokens are combined to interpret it as a double-slash and the searching technique is set to recursive descent. If a star (*) is encountered as the second token, then the expression is interpreted to search for any kind of GME object. The node name is used to search for an object with the name that is a child of the root node. For every token, a corresponding function call to interpret the token is invoked using a mapping function. Figure 16 shows a code snippet of the translator module. This code shows the mapping of keywords to integer values.

62 51 1 // The enumerated set of keywords used in XPath 2 enum keywords { null, at, digit, space, slash, dot, minus, under, colon, semi_colon, 3 double_quote, simple_quote, dollar, opening_parenthesis, closing_parenthesis, star, 4 plu s, comma, less_than, equalto, greater_ than 5. 6 } 7 8 //This mapping function maps every keyword with a integer value. If the match is 9 not //obtained it returns a zero int mapping(char * tokenstring){ 12 if ( strcmp(tokenstring,"null")= =0) return null; 13 if (strcmp(tokenstring,"at")= =0) return at; 14 if (strcmp(tokenstring,"dot")= =0) return dot; 15 if (strcmp(tokenstring,"space")= = 0) return space; 16 if (strcmp(tokenstring,"slash")==0) return slash; 17 if (strcmp(tokenstring,"minus")= =0) return minus; 18 if ( strcmp(tokenstring,"under")= =0) return under; 19 if (strcmp(tokenstring,"colon")= =0) return colon; } Fig. 16. Code snippet from the interpreter module GME BON In GME, a modeling project is used to describe a system in a modular and structured way. In addition to this, it also allows the computer to process the data from the models automatically. The complexity of the models varies for different processing tasks. To facilitate the automatic processing of model data, GME provides access to the model information. To meet this requirement, the GME provides several methods to access the data. One of the methods is by building a GME interpreter. Interpreters are not stand-alone programs, but are components that are loaded at runtime. Other methods provided by GME to access model information are plug-ins, decorators, and add-ons. All of these methods use one of the following two technologies to provide an interface to access data:

63 52 1. BON This framework provides a powerful but easy to use interface for writing application programs that can be attached to GME as a plug-in. BON provides a network of C++ objects, and each of these objects represents an object in the GME model database. The C++ methods provide access to read/write object properties, attributes, and relations. 2. COM interface - Because GME is based on the Component Object Model/Document Component Object Model (COM/DCOM) [57] architecture, it provides a COM interface to access the GME internal data structures. There are several noted differences between using raw COM and the BON API to write a GME interpreter. The COM API is more difficult to understand and use than the BON API, but raw COM has the potential to offer more control to invoke more functionality. In the case of BON, the API is much easier to understand and use, but the number of available features is limited. Figure 17 shows the different classes in the BON API. All classes have CBuilderObject as the common base class. This class represents the common functionality available to all First Class Objects (FCOs). The generic modeling concepts in GME (i.e., atoms, models, connections, sets, and references) that are used to represent the entities and relations are referred to as FCOs. The classes CBuilderAtom, CBuilderModel, and CBuilderConnections contain the methods to create and access atoms, models and connection objects in the GME model database. The classes CBuilderReference (along with the classes CBuilderModelReference and CBuilderAtomReference) and CBuilderSet represent the functionality and specific methods for creating and accessing sets and references in the GME model database.

64 53 Interpreter Interface Classes CBuilder CBuilderObject CBuilderFolder CBuilderModel CBuilderAtom CBuilderReference CBuilderConnection CBuilderSet CBuilderReferencePort CBuilderModelReference CBuilderAtomReference Fig. 17. Classes in the Builder Object Network (Taken from GME tutorial lesson 3) CBuilderReferencePort is a pseudo-object that is only present in the BON. Two classes that are external to the CBuilderObject hierarchy are CBuilder and CBuilderFolder. The CBuilder class represents the GME project as a whole and provides access to the root folder and other folders, as well as to other project attributes and settings. The class CBuilderFolder represents the folder objects and other methods for navigating the folder hierarchy and root FCOs. Figure 18 shows a sample code snippet using some of the methods available in the BON. This code snippet recursively searches from the root for a specific CBuilderObject using the name of the object to be searched. In this code, the data type CBuilderObjectList in line 6 stores the list of all the CBuilder objects that are children of the current CBuilderModel returned by the method call GetChildren(). This list is traversed using an iterator of the data type POSITION in line 8. While iterating through

65 54 the objects, every object name that matches (line 13) the name of the object to be searched is stored in an output list (line 15). This process recursively continues for every object whose type is a model (line 18). 1 void getrelativenode (CBuilderModel *modelname,const char *nodetobesearched){ 2 3 CBuilderObject *result; 4 bool found=false; 5 6 const CBuilderObjectList *childrenlist=modelname->getchildren(); 7 8 POSITION childrenpos =childrenlist->getheadposition(); 10 while (childrenpos) { result=childrenlist->getnext(childrenpos); 13 if (strcmpi(result->getname(),nodetobesearched)==0) 14 { 15 relativenoderesult.push_back(result); 16 } 17 if (result->getobjtype()==objtype_model) 18 getrelativenode((cbuildermodel *)result,nodetobesearched); 19 } 20 } Fig. 18. Sample code using the methods available in BON. Search The algorithm used for searching the objects in a GME model involves the use of BON objects. Whenever a token is received, the process of interpretation and searching is performed in a sequential manner. Depending upon the interpretation, corresponding BON objects are invoked and a search is performed for the particular token. For example, if the search token is a model name, then a CBuilderModelList object is invoked that will store all the models returned by the method GetModels(). A search is performed on this list to match the model name given in the search predicate. For the next token, this matched list of CBuilderObjects is searched by a match for the next token. For the first

66 55 token, only the input list encompasses all the CBuilderObjects objects in the project. In a similar manner, the search is invoked for all the tokens given in the search predicate. The result of the search is the list of all CBuilderObjects returned after all the tokens have been processed. For example, if the search string is //*, the first token to be processed is slash (/). Interpretation of this token sets the starting point of the search as the root of the GME model tree. When the next token is also a slash, then the previous token and the current to ken are combined together and interpreted as double-slash (//). Interpretation of this token will set th e search strategy as recursive descent. The next token star (*) acts as a wildcard charact er. This token, when interpreted with respect to the previous token (d ouble-slash), r esults in the recursive search for all CBuilder objects present in the project starting from the root to the leaf. Figure 19 shows the part of the code from the search module. In the code, line 7 maps the curren t token to an integer value which is dispatched on the value (slash, double-slash, star). The case statement for the slash in line 9 sets the current node value as rootnode to indicate that the search has to begin from the root. Line 30 identifies that the double-slash operator has been found and sets the current node as a relative node. When the control branches to the star operator in line 45, the control is further delegated to a method staroperator (Figure 20). Figure 20 shows the implementation of one of the methods in the search module. This method is invoked whenever a star (*) token is interpreted. The method checks for two conditions. If the current node is a root node or a relative node, then the search is performed on all the CBuilder objects present in the project and returns them as the

67 56 search result. If the current node is other than a relative node or root node, then the search is recursively performed on the search result returned by the previous token. 1 void GMEInterpretation (storetokens *store){ 2 const CBuilderModelList *rootmodels=(cbuildermodellist *)bobjects->getdiags(); 3 CBuilderFolder *rootfolders=bobjects->getrootfolder(); 4 while(tklistiterator!=tokenlist.end()) 5 { 6 previous=map;map=0; 7 map=mapping(*(tklistiterator)); 8 switch(map){ 9 case slash: 10 if (start==0){ 11 temp=tklistiterator+1; 12 start=1; 13 currentnode=rootnode; 14 expectednode=childnode; 15 exprstart=root; 16 } 17 else if (start==1) 18 { 19 expectednode=childnode; 20 currentnode=parentnode; 21 predicateready=false; 22 } 23 else if (start==1 && expectednode==childnode) { results.clear(); 26 AfxMessageBox("Syntax Error", MB_OK MB_ICONSTOP); 27 error=true; 28 } 29 break; 30 case dslash: 31 predicateready=false; 32 if (currentnode==rootnode) 33 { 34 expectednode=childnode; 35 currentnode=relativecontext; 36 exprstart=relativenode; 37 } 38 if (currentnode==parentnode && expectednode==childnode) 39 { 40 results.clear(); 41 AfxMessageBox("Syntax Error", MB_OK MB_ICONSTOP); 42 error=true; } break; 45 case star: if(start==1) 46 { 47 predicateready=true; 48 staroperator(rootfolders,currentnode); 49 } 50 break; 51 } Fig. 19. Code Snippet of the Search module (Branching for /, // and *)

68 57 1 void staroperator(const CBuilderFolder *rootfolders, expect_key currentnode) 2 { 3 const CBuilderFolderList *subfldrs=rootfolders->getsubfolders(); 4 const CBuilderModelList *rootmodels=rootfolders->getrootmodels(); 5 if (currentnode==rootnode currentnode==relativecontext) 6 { 7 POSITION modelpos =rootmodels->getheadposition(); 8 while(modelpos){ 9 CBuilderModel *mods=rootmodels->getnext(modelpos); 10 getchildtree(mods); 11 } 12 vector <CBuilderModel *>::iterator treeiter; 13 treeiter = childrens.begin( ); 14 while (treeiter!=childrens.end()){ 15 objectinfo info= storeobjectinfo(*(treeiter)); 16 intermediate.push_back(info); 17 treeiter++; 18 } 19 POSITION pos =subfldrs->getheadposition(); 20 while(pos) { 21 CBuilderFolder *rootname=subfldrs->getnext( pos); 22 getchildtree_folders(rootname); 23 } 24 treeiter = childrens.begin(); 25 while (treeiter!=childrens.end()){ 26 objectinfo info= storeobjectinfo(*( treeiter)); 27 intermediate.push_back(info); 28 treeiter++; 29 } 30 }else{ 31 childrens.clear(); 32 if (results.size()>0){ 33 while (objiter!=results.end()) 34 { 35 objectinfo objinfo = *(objiter); 36 getchildtree(objinfo.model); 37 vector <CBuilderModel *>::iterator treeiter; treeiter = childrens.begin(); while (treeiter!=childrens.end()){ 40 objectinfo info= storeobjectinfo(*(treeiter)); 41 intermediate.push_back(info); treeiter++; } 44 objiter++; 45 } 46 } 47 } 48 storeglobalresult(intermediate); 49 } Fig. 20. Source Code for staroperator in the search module.

69 58 User Interface The user interface (UI) for this plug-in is created using MFC in Visual Studio 6. The UI is developed as a dialog box that receives its handle from the main window of GME. The dialog box consists of an edit box for entering the XPath expression. It also has a list control box that is used to display the search results as a multi-tab output. The different tabs in the output window are the Object name, location path, location coordinate s, and the type of the object (atom, model, reference, set, or connection). The path tab display s the path of the component from its level in the hierarchy to the topmost model. The Location tab gives the exact coordinates of the components within the window i n which it is located. The coordinates are not returned for those components whose ob ject type is other than a model or an atom. Fig. 21. Screenshot of the XPath Model Search plug-in (XMOS)

70 59 Even from the entire list of models that are present in the final output list, the location of only non-abstract models are computed. The search button invokes the search and the cancel button unloads the dialog box. Figure 21 shows the screenshot of the user interface dialog box for the plug-in. Metrics The complete source code of the plug-in includes the partial source code of the parser and the code for interpreting and searching the components in the project. The parser code contains about 1500 lines of code, whereas the interpreter and search algorithm contains approximately 7000 lines of code. There are 38 source files in the project, including the BON API files that are actively used in the execution of this plugin. Problems and Limitations in Implementation The BON API that provides an interface for building interpreters, plug-ins, and add-ons has some implementation limitations. One of the limitations of the BON API can be realized when using it with MFC dialog boxes. If a plug-in or an interpreter module has an MFC dialog box associated with it, then these dialog boxes have to be created as a modal dialog box and not as modeless. Modal dialogs, once invoked, will not allow the users to access the parent window, whereas modeless dialogs allow users to work with the parent window.

71 60 Case Study The XMOS search plug-in was used for searching models developed using the Embedded Systems Modeling Language (ESML) [1]. This section describes the models developed in ESML for denoting scenarios in the Boeing Bold Stroke Mission Computing Avionics Framework [1] that will be used as an experimental case study for this plug-in. Boeing Bold Stroke Mission Computing Avionics Framework Bold Stroke is a product-line architecture written in C++ that was developed by Boeing in 1995 to support families of mission computing avionics applications for a variety of military aircraft. Mission computing software such as Bold Stroke is responsible for controlling navigational sensors, weapon deployment sub-systems, and cockpit panel displays that are used by a fighter pilot. Bold Stroke is a multi-threaded, real-time system that has hard and soft deadlines. It is a very complex framework with several thousand components implemented in over a million lines of code. ESML This section describes a modeling environment for specifying properties of Bold Stroke usage scenarios. The ESML is a domain-specific graphical modeling language developed for modeling real-time mission computing embedded avionics applications. Its goal is to address the issues arising in system integration, validation, verification, and testing of embedded systems. ESML has been defined within the GME. There are representative

72 61 ESML models for all of the Bold Stroke usage scenarios that have been defined by Boeing. GME provides methods for instantiation of a new graphical modeling environment supporting the visual specification and editing of ESML models. The modeling scenarios for Boeing Bold Stroke can be easily denoted in ESML, as both of them support real-time event channels. In this model, components are complex, ported objects (typically consisting of multiple instances of different classes), which interact with each other through two mechanisms: Procedure invocation via component Receptacles (clients expressed dependencies on other component s interfaces) to Facets (public server component interfaces), Event propagation through a publish/subscribe mechanism. The above two mechanisms are typically combined in a push-directed-pull interaction pattern. In this combined mode of operation, a publisher component notifies subscriber components about the availability of data, and the subscribers, when triggered, call back through their receptacles to the facet of the supplier to retrieve that data. This technique provides more adaptive and configurable behavior to support reuse and fine grain incorporation of Quality of Service (QoS) properties. ESML supports three main modeling categories to represent an embedded system: a) Components, b) Component Interactions, and c) Component Configurations. Figure 22 illustrates the components and interactions for a specific scenario within Bold Stroke (i.e., the MC_BasicMP scenario). The MC_BasicMP represents the basic multi-process product scenario of Bold Stroke. This scenario provides insight into a small subset of aspects that are related to weapon system avionics software development, and at the same

73 62 time addresses issues of component distribution. The Action and concurrency components are specified in this diagram. The embedded systems built using ESML are typically multi-threaded. Thread types with their rates and priorities can be declared inside processors. By design, threads are related to subscribe ports: when the component receives a notification via the subscribe port, an associated thread wakes up and executes the component s code. Fig. 22. Bold Stroke component interaction represented in ESML Figure 23 shows the modeling capabilities of ESML to represent an internal configuration of a component. The BM PushPullComponent is represented in the figure. For this

74 63 component, the concurrency control mechanism along with an internal data element and a facet descriptor is specified. Fig. 23. Internal representation of BM PushPullComponent in ESML Test cases The XMOS plug-in was verified against different test cases using the Bold Stroke ESML models. Case 1, Case 2, and Case 3 are tested on the MC BasicMP model scenario. Case 4 is tested on the MC ConcurrencyMP model scenario. Some of the test cases and the results obtained are illustrated below: Case 1: Locate all the concurrency elements that have an attribute Lock Type set to Null Lock and whose lock strategy is not Recursive Thread Mutex.

75 64 XPath expression for the above case (result shown in Figure 24): Lock" Recursive Thread Mutex ] Fig. 24. Result for case 1 Case 2: Search for all data elements whose value is set to 5 and all log elements whose logging kind is set to On Read. XPath expression for the above search condition is (result shown in Figure 25): //data[@value=5] and //log[@kind= On Read ]

76 65 Fig. 25. Result for case 2 Case 3: Locate all data elements whose value is set to 5 or all log elements whose logging kind is set to On. XPath expression for th e above search condition is (result shown in Figure 26): //data[@value=5] or //log[@kind= On ]

77 66 Fig. 26. Result for case 3 Case 4: Locate all components whose time period is greater than and all components whose data size is equal to 32. The XPath expression for this case is (result shown in Figure 27): //*[@period>20000] and //*[@datasize=32]

78 Fig. 27. Result for case 4 67