Hypersonic: Model Analysis and Checking in the Cloud Vlad Acretoaie and Harald Störrle Department of Applied Mathematics and Computer Science Technical University of Denmark rvac@dtu.dk, hsto@dtu.dk ABSTRACT complemented by the Teamwork Server plug-in [20] for cen- Context: Modeling tools are traditionally delivered as mono- tralized version control. With this type of modeling tools, lithic desktop applications, optionally extended by plug-ins the main revenue source for tool vendors is the sale of per- or special purpose central servers. This delivery model suf- petual licenses for their product, possibly supplemented by fers from several drawbacks, ranging from poor scalability ongoing technical support fees. Both the rich client architec- to difficult maintenance and the proliferation of “shelfware”. ture and the associated business model suffer from a series Objective: In this paper we investigate the conceptual and of disadvantages, some of a generic nature and some more technical feasibility of a new software architecture for mod- specific to modeling tools. eling tools, where certain advanced features are factored out In many other areas of computing, however, other, more of the client and moved towards the Cloud. With this ap- flexible architectures are commonplace today. In particu- proach we plan to address the above mentioned drawbacks lar, recent technological developments have brought about of existing modeling tools. the widespread adoption of Cloud-based software architec- Method: We base our approach on RESTful Web services. tures. Typically, such architectures involve the deployment Using features implemented in the existing Model Analy- of computationally intensive tasks to a centralized and fully sis and Checking (MACH) tool, we create a RESTful Web transparent shared pool of configurable computing resources service API offering model analysis facilities. We refer to (i. e., “the Cloud”) [18]. In this context, Web applications are it as the Hypersonic API. We provide a proof of concept nowadays a widely used method of delivering software func- implementation for the Hypersonic API using model clone tionality of many different kinds, including lightweight edi- detection as our example case. We also implement a sample tors for parts of UML (e. g., GenMyModel [1], yUML [25]). Web application as a client for these Web services. Though already attracting users, most such Web-based of- Results: Our initial experiments with Hypersonic demon- ferings are currently not able to match traditional desktop strate the viability of our approach. By applying standards tools in terms of features. Nevertheless, modeling in the such as REST and JSON in combination with Prolog as an Cloud does have the potential to address some important implementation language, we are able to transform MACH problems, such as achieving scalability in relation to increas- from a command line tool into the first Web-based model ingly large models and model repositories [16]. clone detection service with remarkably little effort. To realize this potential, we propose a solution where the features required in a fully-fledged modeling environment are hosted remotely and accessed in a transparent way. Playing Keywords the role of basic building blocks for a modeling workflow, Hypersonic, MACH, Models in the Cloud, clone detection, these features should be accessible independently of each Web services, Prolog other and across a variety of devices. Fig. 1 visualizes the contrast between the widely used rich client architecture and the solution we propose. The crucial part of this proposal 1. INTRODUCTION is the identification of features of a modeling environment Until very recently, the only practically viable architecture that should be executed locally, and of those that should be for modeling tools was the traditional rich client architecture executed on remote servers. for desktop applications, sometimes complemented by spe- Arguably one of the most suitable application areas for cialized central servers, e. g., to provide model versioning Cloud-based approaches in modeling is model analysis. We and group collaboration capabilities. Such modeling tools select the requirements of this area as a background for con- are large, monolithical applications, even though some do structing Hypersonic, a test vehicle for demonstrating our offer scripting facilities, application programming interfaces proposed approach for the delivery of modeling services - in (APIs), or a plug-in mechanism to allow for a certain de- this case, model analysis services. To implement Hypersonic, gree of extensibility. A typical example is NoMagic’s Mag- we use the features offered by our existing model analysis icDraw [21], which can be extended through an API, and tool, MACH [27]. In its current form, MACH is a desktop application with a textual user interface. As most desktop BigMDE’14 July 24, 2014. York, UK. Copyright c 2014 for the individual papers by the papers’ applications, it requires installation prior to its usage, as authors. Copying permitted for private and academic pur- well as explicit user actions/approval for installing updates. poses. This volume is published and copyrighted by its edi- With Hypersonic, the features implemented in MACH be- tors. Client Client Client executed locally. To an IT administrator, repeatedly deploying tools to a ... large number of computers implies additional effort. Even if this effort is not incurred by the actual deployment (that Provider 1 Provider 1 Provider k might be expected to be taken care of by the modelers themselves), it becomes inevitable when distributing up- dates and fixes, help-desk services, and possibly ensuring that the tool’s license usage is compliant with the agreement ... entered in with the tool vendor. To the tool provider, delivering a modeling solution as a self-contained product with all the business logic on the Provider x Provider y client side makes it difficult to support the wide array of Provider 1 Provider 1 emerging computing devices. Migrating a large modeling tool to a tablet, smartphone, or Web interface would likely require extensive re-implementation, not to mention that Legend Component suitable for deployment Component suitable for deployment to remote server to local client the hardware requirements of many modeling tools are still prohibitive for mobile devices. Furthermore, separating the Figure 1: Possible software architectures of model- highly critical (and sometimes highly innovative) and non- ing tools: most common solution today (left); mod- critical functionalities of the application is cumbersome, yet eling in the Cloud with Hypersonic (right) still achievable through plug-ins. The distribution of coun- terfeit copies of the tool is also difficult to mitigate. To the MBSD community, all of these factors are limiting, come RESTful Web services. They can be accessed remotely in much the same way as superficial differences between pre- from a wide range of clients, without requiring installation UML modeling languages created niche markets for many or explicit user actions for installing updates. To demon- different tools that were more expensive and less powerful strate the usefulness of our Web service API we also create than the UML tools that emerged after the unification of a sample client in the form of a responsive Web application. mainstream modeling languages in the late 1990’s. In this paper we discuss the application scenarios and In a nutshell, the existing situation is suboptimal. Thus, business cases for Cloud-based modeling services, derive re- we propose a different architecture: compute-intensive fea- quirements and constraints for the associated tools (Chap- tures and features with a high degree of innovation should ter 2), propose a distributed architecture to satisfy these be deployed to and executed in the Cloud rather than on the requirements (Chapter 3), and report on a proof-of-concept client machine. The client and server in this architecture are implementation (Chapter 4). We also provide an overview coupled loosely, by Web services, so that providing a new of related work (Chapter 5) and summarize the conclusions feature amounts to providing a new Web service. Such fea- of our study (Chapter 6). tures can include advanced model analysis tools, code and report generation, and model transformation. Conversely, 2. DEFINING HYPERSONIC features of smaller distinctive value and small change rates, as well as features that require a higher degree of interac- 2.1 Analysing Requirements by Stakeholder tivity, can continue to be implemented as part of the client application. This will likely be the case for pure editing fea- Moving modeling tools to the Cloud is not primarily moti- tures, which many commercial vendors already offer as free vated by technological reasons, but by new application sce- community editions of their tools. narios and business cases. In this section we analyze these We have hinted at a set of criteria for determining which application scenarios and business cases to highlight the features of a modeling tool should be executed locally, and advantages of our proposed architecture. We start by de- which would benefit from being migrated to the Cloud. Ta- scribing the status-quo, considering the stakeholders “tool ble 1 summarizes these criteria and presents examples. provider”, “modeler”, “IT administrator”, and “MBSD com- munity”, where MBSD stands for Model Based Software De- velopment. Observe that all of these stakeholders exist in 2.2 Benefits of Modeling in the Cloud similar ways both in academic and commercial settings. We Several advantages can be achieved by breaking up today’s argue that the current state of the MBSD tool landscape is monolithic modeling tools into one stable, remote part that unsatisfactory for the stakeholders in several ways. provides little added value distinguishing products (e. g., To a modeler, tools come as fixed packages: it is usually the editor), and a second, centralized part that comprises not possible (or not practical) to use one aspect, the editor, more advanced features with a higher change rate and higher say, of one tool, and another aspect of a second tool. For distinctive value. instance, if the modeler appreciates the editing facilities of First, there are the advantages associated with thin-client tool A, but that tool does not provide (adequate) code gen- systems in general: maintaining one central server instead of eration facilities, code generation may be difficult. It may many remote clients reduces the work effort for IT adminis- not be economically viable due to the cost of purchasing two trators and ensures that modelers always have access to the tools, or it may actually be impossible to use the editor of latest version of the modeling tool. It also becomes easier tool A combined with the code generator of another tool, to monitor license usage, which benefits administrators and unless both tools strictly adhere to model interchange stan- tool providers alike. dards. Also, from a modeler’s perspective, resource intensive Second, there are advantages rooted in the specific proper- tasks may take an unreasonably long time to complete when ties of Cloud-based solutions. This includes the availability Local Features Cloud-based Features Property high interactivity & incidence high resource consumption high degree of stability high degree of innovation exchangeable features unique features Examples editing reporting simple syntax checking global consistency checking automatic layout advanced model analysis context specific help check in/out, locking difference visualization difference computation querying and navigation code generation Table 1: Criteria for assigning features to a local client or remote Web service, together with examples of considerable computational resources to each individual based approach to modeling entails some trade-offs. Most user at reduced overall cost, as well as high scalability of the are caused by the distributed nature of the approach. For available resources with an increasing number of users. instance, the process of uploading large models to a Cloud- Third, a scenario in which some modeling facilities are based service may constitute a performance bottleneck. Se- provided as services is conductive to model interchange stan- curity and privacy are also new aspects that come into play, dards conformance. In such a scenario, service providers considering that a centralized warehouse will store models and client tool providers must both conform to model inter- owned by different organizations. These organisations must change standards such as the XML Metadata Interchange be able to trust that not only will their models not be acces- (XMI, [22]) in order to meet the requirements of modelers. sible to other users, but they will also be protected against Fourth, there are advantages brought about by changes unauthorised mining by the modeling service provider. And, in the business model and enabling market mechanisms. perhaps most importantly, the usefulness of the solution is Today, the modeling tool market is dominated by compa- dependent on a working Internet connection. Nevertheless, nies providing feature-complete bundles. A new competitor these drawbacks are common to the majority of Software as can only enter the market by providing a feature-complete a Service (SaaS) solutions, and have not undermined this solution, which all but excludes small companies and aca- architecture style’s acceptance. demic tool providers. Innovative analysis methods, special- ized code generators, and similar tools can only be provided 2.3 A Test Case for Hypersonic as plug-ins to one of the existing platforms, sometimes de- In Section 2.1 we have discussed which types of features pending on the approval of the platform owner. In contrast, lend themselves to deployment as Web services. We now se- with a service-based architecture, tool providers can enter lect one feature, clone detection, as a test case for exploring the market at lower cost, since they only have to provide the proposed architecture (i. e., the Hypersonic API). Our their contribution per se, not a feature complete-tool. They selection is motivated by the following considerations. can also address a larger part of the market, as they provide a generic Web service rather than a platform specific plug- • The feature is well researched, published, and imple- in that applies to only one modeling tool. Modelers, on the mented (see [26] and [27], respectively), and has been other hand, can mix and match services as they like within used by a large number of students in several courses the limits of standardized exchange formats. in which it has demonstrated its usefulness. So, the It is likely that the described change in dynamics of the feature is readily available and arguably valuable. modeling tools market will inspire an increase in competi- tiveness between existing tool providers, while at the same • Clone detection demands significant resources, as it is time providing an incentive for new providers to enter the based on semantic and structural model matching. For market. Both these developments will likely lead to a higher large models, the latency implied by uploading a model degree of innovation. This could translate into new concepts to the Cloud may be offset by savings in run-time from academia dissipating to industrial modeling at a faster achieved by using a powerful machine in the Cloud. pace. Users will thus have both a financial and a technical • Detecting clones is an activity carried out as part of incentive to experiment with new features. the model quality assurance process. It is normally From a financial perspective, tool providers will be able to not executed concurrently to other modeling activities. bill features separately as subscription Web services. This Therefore, in some scenarios, a clone detection feature could reduce unit prices for customers, who only buy the fea- is not required or even useful. For example, models tures they need, and may subscribe to services as they need reverse-engineered from code do not require clone de- them. Spending on expensive “shelfware” can be reduced tection if the code is known to be clone-free. or avoided altogether. For the supplier, this opens the per- spective of a new business model in which a steady stream • It is a unique feature: no UML modeling tool cur- of revenue is generated through subscription services, while rently offers a clone detection feature. This includes features of high distinctive value are much better protected research prototypes other than our own MACH tool. against counterfeiting. It is therefore safe to assert that this feature provides It must be mentioned, though, that adopting a service- a high degree of innovation. 3. ARCHITECTURE loaded by other users. When combined with a role-based au- A first step towards the realization of the ideas presented thentication policy, a sound authentication mechanism such in Section 2 is the definition of a common Web service in- as OAuth is an effective way to manage model access rights. terface accepted by all stakeholders. The details of such an At a technical level, implementing OAuth will require all interface must be the result of a wide reaching discussion, Hypersonic API clients to obtain an access token prior to which is beyond the scope of this paper. Instead, we take using the API. This process can be carried out through a an exploratory approach and design a RESTful Web service separate channel, such as a dedicated API management Web API for the purpose of Cloud-based model analysis. We application. refer to this API as the Hypersonic API. By doing so, we From a file format standpoint, Hypersonic currently sup- study the requirements and potential setbacks of processing ports models stored in the MDXML format, the XMI-based models via RESTful Web services. native format of the MagicDraw modeling tool. That is to In keeping with the REST architectural style [10], the say, some API requests (e. g., POST requests to the mod- Hypersonic API exposes resources for clients to interact with els resource) are expected to have an MDXML document as via HTTP requests. The two exposed resources are models payload. Most API response messages carry a JSON [12] and model. The models resource plays the role of an access document as payload, representing either the result of an point to Hypersonic’s model warehouse, whereas the model analysis operation or a confirmation or error message. resource represents a single model in the warehouse. These The internal components involved in answering a call to resources are manipulated via HTTP requests, where the the Hypersonic API are presented in Fig. 3. The REST- HTTP method determines the operation to be performed. ful API component handles HTTP communication with re- In addition, the Hypersonic URL scheme specifies explicit mote API clients and delegates all actual model processing operations on the model resource as part of the request URL. to the MACH component. It also forwards all models sent The list of supported operations is presented in Table 2. by clients to the XMI2PL component, which performs a for- This architectural approach allows physically decoupling mat translation from the MDXML format to the internal clients from the execution of the various analysis algorithms Prolog-based file format described in [26]. Once translated, exposed by the Hypersonic API. This aspect is part of the models are stored in a dedicated model warehouse for future motivation behind the creation of Hypersonic, since many analysis upon the client’s request. The MACH component of these algorithms are resource demanding on models of exposes several supported model analysis and checking al- non-trivial size. By using such a Web service API, a large gorithms [27]. These algorithms can be applied on models variety of clients can have access to model analysis facili- stored in the warehouse. The MACH component functions ties regardless of their hardware capabilities. Fig. 2 high- as a self contained black-box, hiding all algorithm implemen- lights this aspect, showing that different clients can access tations from other components and returning the produced existing analysis algorithms provided by the MACH tool via results encoded as Prolog lists. The RESTful API compo- the Hypersonic API wrapper. The only prerequisites for nent handles the translation of these lists into JSON analysis API clients are HTTP support, the ability to process docu- reports ready for consumption by the API client. All pro- ments returned by the API, and, optionally, a model viewer. cessing components are executed inside a single instance of Note that all of these prerequisites are entirely reasonable the SWI-Prolog runtime [29], thus allowing seamless inter- for modern mobile devices. component communication. The SWI-Prolog runtime should be deployed to either a public or private Cloud platform. Since all models are Smartphone app stored separately in a model warehouse, several instances of the SWI-Prolog runtime can be deployed, assuming that the model warehouse provides appropriate concurrent ac- Hypersonic API cess policies. Persistent model storage can be provided by a Web app HTTP separate Cloud storage service. Since models are stored as XML and Prolog files, the storage service should support a MACH document-oriented database management system. Desktop client HTTP 4. EVALUATION To demonstrate the feasibility of the architecture described Modeling tool in Section 3, a subset of the proposed Web service API has plug-in been implemented and is publicly accessible1 . Due to the reasons elaborated on in Section 2.3, we have focused on a Figure 2: High-level architecture of Hypersonic Web service providing model clone detection as a minimum useful scenario. Though important for a final release, we have considered features such as user accounts and authen- Additional non-functional considerations must be taken tication beyond the scope of our proof of concept. Both into account to ensure the practicality of the Web service the prototype API and the model warehouse are currently API. Since using the API implies uploading entire models hosted on a dedicated server. They do not benefit from to a remote server, security becomes an important factor. the scalability of a true Cloud deployment, although for the With this in mind, the OAuth [11] authentication protocol current proof of concept this is hardly a limiting factor. is a widely used solution that can provide some important guarantees to Hypersonic users. The most important such 1 The Hypersonic API is available at the following base URL: guarantee is that a user cannot gain access to the models up- http://hypersonic.compute.dtu.dk Resource Method Req. payload Resp. payload Description /models GET — JSON List all uploaded models. /models POST MDXML JSON Upload a model. /model/ GET — MDXML Download a model. /model/ PUT MDXML JSON Replace a model. /model/ DELETE — JSON Delete a model. /model//clones GET — JSON Detect clones in a model. /model//diff/ GET JSON JSON List differences between two models. Options are specified in the request payload. /model//dump GET — JSON List model elements included in a model. /model//dump/ GET JSON JSON List the details of a model ele- ment. Options are specified in the request payload. /model//find/ GET JSON JSON Find a string in a model. Op- tions are specified in the request payload. /model//frequency GET — JSON Compute the meta class fre- quency distribution in a model. /model//similarity/ GET JSON JSON Compute the similarity between two models. Options are speci- fied in the request payload. /model//size GET JSON JSON Compute the size of a model. Options are specified in the re- quest payload. Table 2: List of operations supported by the Hypersonic API SWI-Prolog .pl XMI2PL Model warehouse .xmi .xmi call(…) .pl HTTP API RESTful […] MACH client API HTTP .json Figure 3: Components which participate in responding to a Hypersonic API request Fig. 4 represents a message exchange between a client and ” s i m i l a r i t y ”: 1 8 5 . 7 1 4 3 , the Hypersonic API. The purpose of this exchange is to per- ”kind ”: ” n a t u r a l c l o n e ” , form clone detection on a model. First, the model is added to } the Hypersonic model warehouse by a POST request to the { models resource. Upon this request’s successful handling, a ” t y p e 1 ”: ”package ” , new model resource representing the model is available to the ” i d 1 ”: 1 8 9 , client. The resource has a unique identifier returned in the ”name 1 ”: ”Lend Medium ” , JSON response document of the initial POST request. The ” t y p e 2 ”: ”package ” , client then parses this document and extracts the identifier. ” i d 2 ”: 1 1 9 4 , Thus, the client is subsequently able to use the identifier to ”name 2 ”: ”Lend Medium ” , construct the appropriate URL for a GET request to the ” s i m i l a r i t y ”: 1 2 8 . 7 2 8 7 , clones operation of the identified model resource. The GET ”kind ”: ” n a t u r a l c l o n e ” , request returns a list of clone candidates, also in the form of } a JSON document (see Listing 1). ] } By conforming to the architecture presented in Fig. 3, the effort required to implement the clone detection proof of concept has been minimal. The RESTful API function- ing as a wrapper around MACH’s existing clone detection implementation consists of around 100 lines of Prolog code, largely thanks to the comprehensive support offered by SWI- Prolog for the HTTP protocol. Work on implementing the remaining API calls described in Table 2 is ongoing, as is work on the API management application that must be in place in order to to enable user authentication in API calls. As a preliminary validation of the API’s fitness for pur- pose, we have created a simple, mobile device friendly Web application as an API client2 . The application supports se- lecting a local model file, uploading it to the Hypersonic model warehouse, and requesting a clone report which it subsequently displays in tabular form. The application is written in JavaScript and is executed entirely in the browser (i. e., it does not rely on a server-side script for calling API operations). Though it is so far basic in terms of functional- ity, this sample client exemplifies our vision of Web service driven modeling tools: using Web 2.0 technologies (REST, JavaScript, JSON) to enable advanced model analysis out- Figure 4: HTTP message exchange for model clone side the constraints of the desktop and of traditional mod- detection eling environments. The response document includes a model identifier, the number of detected clones, and a list of discovered clone can- 5. RELATED WORK didates. Each clone candidate is described by two model ele- Model analysis is an activity typically performed in local, ments, where one is a possible clone of the other, a numeric non-distributed environments. As an example, the model similarity metric computed for the two elements following clone detection operation considered here as a proof of con- the approach presented in [26], and a clone “kind” identify- cept has scarcely been addressed in itself, but is closely re- ing the candidate as either a naturally occurring clone or a lated to the intensely studied model matching and differenc- seeded clone. Candidates also Clone candidates are returned ing operations. To name just a few proposals in this area, in the descending order of their similarity scores, i. e., the SiDiff [14] presents a differencing algorithm targeting UML most likely clone is the first one in the list. Class Diagrams, while the approach presented in [19] targets sequence charts, and [17] is a clone detection proposal aimed Listing 1: JSON clone detection report at UML Sequence Diagrams. EMF DiffMerge [8] and EMF { Compare 3.0 [3] represent more generic approaches targeting ”model ”: ”1 ” , the Eclipse Modeling Framework (EMF, [9]). ” c a n d i d a t e s ”: 2 , With the increase in size of industrially relevant models ” c l o n e s ”: [ and the increase in complexity of the operations performed { on these models, the need for distributed, Cloud-enabled ” t y p e 1 ”: ”package ” , modeling solutions has become apparent [5, 16]. So far, the ” i d 1 ”: 2 9 , main driver behind Cloud-based modeling research has been ”name 1 ”: ”R e s e r v e Medium ” , 2 The client application is available at http://www.compute. ” t y p e 2 ”: ”package ” , dtu.dk/~rvac/hypersonic. It is currently under develop- ” i d 2 ”: 9 3 8 , ment, and will be updated to support all operations of the ”name 2 ”: ”R e s e r v e Medium ” , Hypersonic API as they are deployed. Figure 5: Screenshot of the Hypersonic API client Web application the promise of important performance and scalability gains 6. CONCLUSIONS for all modeling activities. Perhaps the most fundamental of these activities, model storage, has attracted several propos- 6.1 Summary als, including ModelBus [4], EMFStore [15], and Morsa [23]. In this paper we have discussed the application conditions, These are all remote model warehousing solutions offering benefits, and general business case for Cloud-based modeling Web service access to the stored models. tools. In particular, we have presented a scenario in which More advanced activities such as model querying and trans- modeling capabilities are delivered as Web services to a wide formation have also been addressed. IncQuery-D [13] is a array of clients, ranging from desktop applications to Web tool which takes the established IncQuery tool and adapts and mobile applications. We have contrasted this scenario it to a scenario where it can be deployed and accessed in with the current status-quo of rich client desktop modeling the Cloud. The Morsa model repository also benefits from tools, reaching the conclusion that, in many respects, the a dedicated query language, MorsaQL [24]. A roadmap for Cloud-based approach is superior. research on Cloud-based model transformations has been To explore our proposal, we have introduced Hypersonic, a presented in [7]. RESTful Web service API aimed at offering high-throughput However, performance gains due to Cloud deployment are processing for Cloud-based model analysis. We have imple- only a part of the overall vision of Hypersonic. Rather than mented this architecture and made it available online. Cur- focusing on the benefits to the application itself (i. e., model rently, the only service it offers is the detection of model analysis), Hypersonic emphasises the benefits brought by a clones, a feature that was previously only available in the Cloud-based approach to the interface and availability of MACH command line tool. Today, MACH is a stand-alone this application. The idea of performing model analysis via desktop tool providing only a textual user interface. Through a RESTful Web service API has yet to receive significant the Hypersonic API, the features of MACH can be made attention in the literature. The closest related proposal is available over the Internet to any API client. As a proof the EMF-REST project [6], aimed at automatically generat- of concept for the utility of the API, we have developed a ing RESTful Web service interfaces for EMF models, much Web application acting as a client to the Hypersonic API like existing EMF tools generate Java APIs for such mod- and providing Web-based model analysis capabilities. els. Like Hypersonic, EMF-REST uses JSON documents to transport information about remotely stored models. Nev- 6.2 Future Work ertheless, while it does provide basic model manipulation The concepts presented in this paper offer us ample oppor- operations, EMF-REST is not designed as a model analysis tunities for future work. As a first step, we will continue the tool. Similarly to Hypersonic, EMF-REST is a tool under development of the Hypersonic API with the aim of reach- ongoing development, one of its current limitations being the ing functional parity with the MACH model analysis tool. lack of full support for HTTP methods other than GET. Once this has been achieved, the API will be deployed to a Cloud platform. In parallel, we will update the sample [14] U. Kelter, J. Wehren, and J. Niere. A Generic Web-based API client to both validate and showcase the Difference Algorithm for UML Models. In K. Pohl, model analysis features of Hypersonic. Second, in order to editor, Proc. Natl. Germ. Conf. Software-Engineering become a practical tool, the API client must offer several (SE’05), number P-64 in Lecture Notes in Informatics, critical features such as user authentication and model se- pages 105–116. Gesellschaft für Informatik e.V. 2005. curity mechanisms. Third, we will carry out a systematic [15] M. Koegel and J. Helming. EMFStore: a Model performance evaluation of MACH in order to substantiate Repository for EMF models. In Proc. 32nd the claim that Cloud-based model analysis can bring signif- ACM/IEEE Intl. Conf. on Software Engineering icant performance benefits. Finally, we intend to develop a (ICSE’10), volume 2, pages 307–308. ACM, 2010. second client for the Hypersonic API in the shape of a plug- [16] D. S. Kolovos, L. M. Rose, N. Matragkas, R. F. Paige, in for MagicDraw. This will permit seamless integration of E. Guerra, J. S. Cuadrado, J. De Lara, I. Ráth, our Web services approach with a commercial modeling tool D. Varró, M. Tisi, and J. Cabot. A Research and complement our existing model querying MagicDraw Roadmap Towards Achieving Scalability in Model plug-in, MQ-2 [2]. As a parallel development, we envision Driven Engineering. In Proc. Ws. Scalability in Model a Web service API similar to Hypersonic for RED, our re- Driven Engineering (BigMDE’13), pages 2:1–2:10, quirements engineering tool [28]. New York, NY, USA, 2013. ACM. [17] H. Liu, Z. Ma, L. Zhang, and W. Shao. Detecting 7. REFERENCES duplications in sequence diagrams based on suffix trees. In 13th Asia Pacific Software Engineering Conf. [1] GenMyModel. http://www.genmymodel.com, retrieved (APSEC), pages 269–276. IEEE CS, 2006. 16.05.2014. [18] P. Mell and T. Grance. The NIST Definition of Cloud [2] V. Acretoaie and H. Störrle. MQ-2: A Tool for Computing. Technical Report 800-145, National Prolog-based Model Querying. In Proc. co-located Institute of Standards and Technology, 2011. Events 8th Eur. Conf. on Modelling Foundations and [19] S. Nejati, M. Sabetzadeh, M. Chechik, S. Easterbrook, Applications (ECMFA’12), pages 328–331. and P. Zave. Matching and merging of statecharts [3] M. Barbero. EMF Compare 3.0. specifications. In Proc. 29th Intl. Conf. Software http://www.eclipse.org/emf/compare. Engineering (ICSE), pages 54–64. IEEE Computer [4] X. Blanc, M.-P. Gervais, and P. Sriplakich. Model Society, IEEE Computer Society, 2007. Bus: Towards the Interoperability of Modelling Tools. [20] NoMagic INC. MagicDraw Teamwork Server. http: In Proc. European MDA Workshops: Foundations and //www.nomagic.com/products/teamwork-server, Applications (MDAFA’03/’04), volume 3599 of LNCS, retrieved 16.05.2014. pages 17–32. Springer Berlin Heidelberg, 2005. [21] NoMagic INC. MagicDraw UML 17.0.3. [5] H. Bruneliere, J. Cabot, F. Jouault, et al. Combining http://www.nomagic.com/products/magicdraw, Model-Driven Engineering and Cloud Computing. In retrieved 16.05.2014. Proc. 4th Ws. on Modeling, Design, and Analysis for [22] Object Management Group (OMG). OMG MOF 2 the Service Cloud (MDA4ServiceCloud’10), 2010. XMI Mapping Specification, Version 2.4.1. [6] J. Cabot. EMF-REST. http://emf-rest.com, http://www.omg.org/spec/XMI/2.4.1, 2013. retrieved 16.05.2014. [23] J. E. Pagán, J. S. Cuadrado, and J. G. Molina. Morsa: [7] C. Clasen, M. D. Del Fabro, and M. Tisi. A Scalable Approach for Persisting and Accessing Transforming Very Large Models in the Cloud: a Large Models. In Proc. 14th Intl. Conf. Model Driven Research Roadmap. In Proc. First Intl. Ws. Engineering Languages and Systems (MODELS’11), Model-Driven Engineering on and for the Cloud volume 6981 of LNCS, pages 77–92. Springer Berlin (CloudMDE’12), pages 3–12, 2012. Heidelberg, 2011. [8] O. Constant. EMF Diff/Merge. [24] J. E. Pagán and J. G. Molina. Querying Large Models http://wiki.eclipse.org/EMF_DiffMerge. Efficiently. Inf. Softw. Tech., pages 586–622, 2014. [9] Eclipse Foundation, Inc. Eclipse Modeling Framework [25] Pocketworks. yUML. http://yuml.me, retrieved (EMF). http://eclipse.org/modeling/emf. 16.05.2014. [10] R. T. Fielding. Architectural Styles and the Design of [26] H. Störrle. Towards Clone Detection in UML Domain Network-based Software Architectures. PhD thesis, Models. J. Softw. Syst. Model., 12(2), 2013. University of California, Irvine, 2000. [27] H. Störrle. UML Model Analysis and Checking with [11] Internet Engineering Task Force (IETF). IETF RFC MACH. In 4th Intl. Ws. Academic Software 6749: The OAuth 2.0 Authorization Framework. Development Tools and Techniques (WASDETT’13), http://tools.ietf.org/html/rfc6749, 2012. 2013. [12] Internet Engineering Task Force (IETF). IETF RFC [28] H. Störrle and M. Kucharek. The Requirements Editor 7159: The JavaScript Object Notation (JSON) Data RED. In ECOOP, ECSA and ECMFA 2013: Joint Interchange Format. Proceedings of Tools, Demos and Posters, pages 32–34, http://tools.ietf.org/html/rfc7159, 2014. 2013. DTU Technical Report 2014-01. [13] B. Izsó, G. Szárnyas, I. Ráth, and D. Varró. [29] J. Wielemaker, T. Schrijvers, M. Triska, and T. Lager. IncQuery-D: Incremental Graph Search in the Cloud. SWI-Prolog. Theory and Practice of Logic In Proc. Ws. Scalability in Model Driven Engineering Programming, 12(1-2):67–96, 2012. (BigMDE’13), pages 4:1–4:4, New York, NY, USA, 2013. ACM.