Linking Rules and Conceptual Model in a Domain ... - IEEE Xplore

2015 International Conference on Advanced Computing and Applications

Linking Rules and Conceptual Model in a Domain Specific Language Long-Phuoc Tˆon

Thai-Minh Truong

Faculty of Information and Technology Industrial University of HCMC Ho Chi Minh City, Vietnam [email protected]

Faculty of Computer Science & Engineering HCMC University of Technology, Vietnam Ho Chi Minh City, Vietnam [email protected]

Abstract—The rationale behind domain specific modeling in software engineering is to raise the level of abstraction while boosting automation in software production. Domain-specific languages (DSLs) typically fall into two categories: high-level, script-like languages and visual modeling languages. The code generation engines that come with them are capable of translating what is written (or visually expressed) to executable code. Our goal is to build a DSL for software development that integrates script-like languages into conceptual models, which is analogous to the way the Object Constraint Language (OCL) puts more semantics in UML models (but ours is essentially at a higher level of abstract than OCL/UML). We identify the following problems for such a DSL: i) conceptual models do not adequately capture the logic of games; ii) keeping conceptual models and rules in synch; iii) defining a rule description language that is powerful enough to decoratively capture most game logic and at the same time facilitate the automation, i.e allows a DSL engine to generate executable code. In this paper, we present our DSL that addresses these three problems. We propose a high-level declarative language for capturing rules. We also describe the prototypes we have built for our DSL in this paper.

DSL acts as a front end while the engine plays the role of a back end for software developers. With regard to software automation, computer game development is no exception. The development of a game application involves at a minimum the following blocks: a) defining game rules, game characters, game objects, game scenes, etc.; b) describing platforms the game is supposed to run on; c) adding graphics to establish the look-and-feel of the game; d) programming & testing. Assuming we can define the domain of the games concretely, we may then develop a DSL and its associated engine to automate most of these blocks in order to speed up the development of all the games in this domain [2]. DSLs in game development typically fall into two categories: high-level, script-like languages and visual modeling languages [3]. The code generation engines that come with them are capable of translating what are written (or visually expressed) to executable code. Our goal is to build a DSL for game development that integrate script-like languages into conceptual models. This might look similar to the way the Object Constraint Language (OCL) puts more semantics in UML models but ours is essentially at a higher level of abstract than OCL/UML [4]. For example, concepts that are conceptually represented in our DSL should directly address components or objects that matter in games (e.g., tools, characters, scenes). We identify the following problems for such a DSL: i) conceptual models do not adequately capture the logic of games [5]; ii) keeping conceptual models and rules in synch; iii) defining a rule description language that is powerful enough to decoratively capture most game logic and at the same time facilitate the automation, i.e allow a DSL engine to generate executable code. In this paper, we present our DSL that addresses these three problems. We propose a high-level declarative language for capturing rules. We also describe prototypes we have built for our DSL in this paper.

I. I NTRODUCTION In the history of software engineering, automation has always been desirable as it is a mean to increase productivity of software production. Automation could be achieved by raising the level of abstraction as in the cases of logic programming (e.g., Prolog) and declarative programming (e.g., Lisp, Alloy). These rather formal languages however have limitations. Most notably, the performance of computer programs generated from these languages is relatively low, compared to that of executable code compiled from contemporary programming languages. Moreover, they usually do not support a friendly, interactive graphics user-interface. In recent years, domain-specific software engineering has experienced growing interests from industry and literature [1]. Automation in this case could be enabled by generating executable code for re-occurring structures that repeatedly show up in rather narrow domains. In order for this automation to be achievable, the domain of software systems needs to be developed in a specific way. This requirement gives rise to the definition of a language that allows us to concisely capture the specifications of software systems in a chosen domain. This language is called a domain-specific language (DSL). Code generation is to be done by an associated engine. As such, the 978-1-4673-8234-2/15 $31.00 © 2015 IEEE DOI 10.1109/ACOMP.2015.25

The outline of this paper is as follows. Section II gives the background and explores related work. Section III presents our motivation through a case study. Section IV is the core of our paper - it proposes a framework and shows how the proposed framework addresses the problems identified in Section III. Section V draws conclusions and points out future work. 35

II. BACKGROUND AND RELATED WORK

Driven Engineering (MDE) principles. They also provide software developers with tools that help generate executable code on mobile platforms. Mangesh Bedekar’s research group built a DSL for mobile applications [11]. This DSL allows the developers to build a web application that may run on various platforms. The Extensible Markup Language (XML) is primarily used in their DSL, which makes it cross-platform and somehow eases up the process of software specification. Specifically, this DSL has the following blocks: page structure, hypertext, queries for data retrieval, presentation, simple validation rules and a few other business logic for transactions. Tony Clark’s group [6] developed a DSL for mobile applications, too. Their DSL follows the 3-tier approach. Tier 1, namely the application, captures the specification of the application in terms of screen size, layout control, graphics user interface (GUI) elements (could be nested), event-driven architecture and state machine. In this tier, the developer describes her application quickly using a high-level language based on λ-calculus [12]. Tier 2 defines the libraries needed for the implementation. Tier 3 is about specific implementation platforms (e.g., Java, C=.NET, Android). As for the process, some platform libraries that contain specific platform API will be called. This library will contain the callable display, interface, and underlining methods of that platform. And then the engine, that will run the compiled code and make the multiplatform calls using the bundled platform library set. Ajith Ranabahu et al. [13] defined a DSL for mobile applications in cloud computing. In their work, interactive Web applications could be constructed following the create, read, update and delete (CRUD) approach. These applications typically have multiple data structures in a data centric backend and offer a mobile or Web-based front-end to users for manipulating these data structures. The use of cloud in these applications is primarily for scalability, i.e., the application itself would not require a massive processing capability but is likely to receive a large number of simultaneous requests and hence needs to scale accordingly. In our work of defining a DSL for mobile games, we also offer software developers a high-level language for capturing the semantics of their games. Ours is different from the aforementioned work mainly in the way game applications can be visually specified by means of diagramming techniques. In other words, game applications can be dually expressed in terms of diagrams and rule-based description. The software developers may start by drawing a UML model for the conceptualization and later on add more semantics to their UML diagrams. Alternatively, they could directly write up the logic of their games as rules in our high-level language. In both cases, our DSL keeps the conceptual model and the rules in synch, i.e. changes made to concepts in the visual model must be propagated to rules and vice versa. The engine of our DSL takes into account the two models when generating executable code that should be organized following the MVC architecture [14].

A. Domain Specific Languages A Domain Specific Language (DSL) is primarily designed to be used in a certain area/-domain, abstracting away from the software implementation making implementation easier [1]. Though this abstraction is designed to aid the developer, the language should merely be domain complete and not be capable of solving any computational problem. DSLs have existed for many years. Languages that were created for particular domains include Fortran used to allow direct mathematical formula, Structured Query Language (SQL) for database access and manipulation, and Algol for algorithm specification. Recently, the use of DSLs have been proposed and used in different domains including the production of rich web applications [6], smashups of web APIs and services [7], and system integration [8]. Because of the complexities in mobile software development, we notice there are problems for abstraction in the development of mobile devices. B. Conceptual Modeling In Conceptual Modeling, a solution-independent specification is produced whose aim is to make a clear and precise description of the domain elements for the purposes of communication, learning and problem-solving. In the Design phase, this conceptual specification is transformed in a design specification by taking into consideration a number of issues ranging from architectural styles, non-functional quality criteria to be maximized, target implementation environment, etc. The same conceptual specification can potentially be used to produce a number of (even radically) different designs. Finally, in the Implementation phase, a design is coded in a target language to be then deployed in a computational environment. Again, from the same design, a number of different implementations can be produced. Design, thus, bridges Conceptual Modeling and Implementation [9]. C. Engines In computer programming, an engine is a program that performs a core or essential function for other programs [10]. An engine can be a central or focal program in an operating system, subsystem, or application program that coordinates the overall operation of other programs. It is also used to describe a special-purpose program containing an algorithm that can sometimes be changed. The best known usage is the term search engine which uses an algorithm to search an index of topics given a search argument. A search engine is designed so that its approach to searching the index can be changed to reflect new rules for finding and prioritizing matches in the index. In artificial intelligence, the program that uses rules of logic to derive output from a knowledge base is called an inference engine. D. Related work We have surveyed contemporary work on DSL, especially DSLs targeted at mobile applications. Some of these DSLs come with script-like languages. Others follow the Model

36

III. M OTIVATION In this section, we formulate our research problems. We first give an example about game development in software engineering. Through this example, we identify concrete challenges before coming up with a generalization. Then we look for corresponding characteristics in order to establish a list of research problems. A. Example In this subsection, we briefly describe an example in which a software developer needs to build a gardening game that allows a single player to act as a gardener. She first picks up a few gardening tools (shovels, scissors, sprinkler and more) and starts the game with a collection of plants: rose, tulip, sunflower, daisy, etc. The game employs a set of rules governing how she could grow her garden using resources. The gardener is provided with an initial resources of 1,000 points. She then uses these resources to buy flower seeds (rose costs 10 points, tulip 15 points and sunflowers 10 points). She can sow her garden with the seeds. She grows them and finally has them harvested. This order of gardening activities must be respected. In terms of tools, the gardener has a shovel (used for sowing) that costs 10 points, a sprinkler (used for growing) 15 points and scissors (used for harvesting) 10 points. Additional logic of this game can be summarized in the following. - The activity of sowing costs the gardener some amount of resources: rose 5 points, sunflower 8 points and tulip 7 points. - A flower needs to be grown within 10 seconds after it has been sowed, otherwise it will not grow. - A flower needs to be watered within 10 seconds after it has been grown, otherwise it loses 3 points. - The activity of growth (watering) adds some amount of resources to the flower: rose is added 5 points, sunflower is added 10 and tulip is added 7. - A flower will change its status as bloomed if it has some amount of resources: rose 20 points, sunflower 15 and tulip 20. - A flower needs to be harvested within 8 seconds after it has bloomed. It is deducted 2 points per 8 seconds after it has bloomed. Its resources will be added to the gardener’s resources when she harvest it. - The gardener wins the game when she obtains 3,000 points. The game is over when she loses all her points. Now, the software developers needs to build this game application. Figure 1 is a UML class diagram that conceptually depicts a design for this application. The game logic presented above should be captured in the design model, too. Suppose that, the software developers has a DSL framework. It translates the conceptual and semantic description of the game into executable code [11]. Quite often, their conceptual models and the semantics they define may not come together. We highlight the following problems the software developers may encounter. • Problem 1: How could the software developers specify the ways in which rose, tulip and sunflower are sowed, watered and later harvested? Nutritiously,

Fig. 1. A UML class diagram for the design of the gardening game

•

•

different flower species respond differently to these gardening activities. Our DSL must provide the software developers with a language, perhaps a rule description language, to do it. Problem 2: Rules described for specific flower species need to be considered in the conceptual model given in Figure 1. More specifically, the software developers needs to consider how the rules could fully be described in terms of the concrete classes such as Rose, Tulip and Sunflower? Problem 3: Suppose the software developer wants to extend the game by introducing more characters such as pets, a trader and additional plants. Of course, both the conceptual model and the rules will evolve. The software developers must then consider how to keep the extended rules in synch with the extended conceptual model?

Figure 2 a correlation between generalization and automation in software production. B. Research Problems Based on the analysis of the concrete problems for the aforementioned example in Subsection III-A, we generalize our research problems as follows. Lack of semantics in conceptual modeling. The conceptual models do not adequately capture the logic of application (game). It only describes the structure of the application [15].

37

plants, pets and fields) and other facilities that the characters may use. Second, the rule engine is used for defining game logic level (e.g., when to sow, when to harvest, when to win conditions and when the game is over). Third, the architecture maps to a code generation engine. This code generation part will be reorganized in the model which follows MVC pattern [14]. A. Conceptual Model

Fig. 2. Correlation between generalization and automation in software production

The graphical user interface of our DSL tool consists of 2 parts: Part 1. A DSL conceptual model where software developers can design applications via dragging and dropping the controls. Part 2. An editor where software developers can edit the constraints between objects in the model. The rules in our DSL are automatically executed to check the constraints by rules and support the generation code for the application.

No synch between the conceptual model and game rules. Our DSL allows software developers to design object models for the game and declare the constraints through rules. However, when they change the content of the models, these rules need to be synchronized with them. Beside that, the DSL has limited between generalized and automated (Figure 2). Expressiveness of rule description language. Software developers expect a DSL that is expressive enough to declarative describe the logic of games in terms of rules. The DSL should come with a script-like language that captures the behavior of all the concepts represented.

B. Rule Engine This is an engine that checks the validity between conceptual models and specifications. This Engine built based on predefined rules. In our DSL, the software developers can design conceptual models and specification of the rules. In particular, these rules will be checked for the validity of the semantic processor. They combined with the model to generate source code for the program. List of rules in the gardening game (Table I) are specified by the designer as follows.

C. The proposed DSL In our DSL, the abstract syntax is the core of our technical space (our metamodel). Furthermore, we define that classes may contain operations just like the UML [16]. A new class operation in the integrated meta-model [17] is associated with classes. Overall, with the new abstract syntax, we describe all aspects our DSL designers can use to define meta-models. To provide reasoning based on domain meta-models and models, we implemented several transformations, e.g. The concrete syntax of our DSL may be based on KM3 [18] or others. We extend the grammar of the concrete syntax by new nonterminals which are defined in grammars. In Figure 4, our DSL has a grammar which consists of rules to produce Java statements. We solve the mapping between abstract and concrete syntax by using the our DSL tool for textual concrete syntax specification of DSLs. The rule engine generates source code according to the MVC pattern. Benefit of following the MVC pattern as: easily to cross-platform apps like Android, Windows Phone, IOS. In the Figure 3, we describe the operation of our DSL. We have adjusted this process from the traditional DSL. In our DSL, the script will be divided into 02 parts, Part 1. Conceptual Model, and part 2. The rules. The rule engine will convert two parts to the code enforcement (both the interface and class). Source code enforcement will be organized into programs with MVC pattern.

C. Code Generation Engine The processing is executed by a code generation engine which is a part of our DSL. Our DSL will combine modeling and semantic processing of the specification of the model constraints in applications (games) [19]. The applications are created from our DSL under modeling. The rules for describing the constraints between objects are represented in two forms: The software developers will define some rules. These are rules that describe the content of the game. And some other rules to check the user-defined rules. These rules also actively support the generation of code in MVC pattern. The semantic processing specifications of the models are the constraints that makes automatic code generation becomes more accurate. It makes the development of specific software applications easier and more efficient. In our DSL, the semantic processor can process in many ways, such as building an ontology [20], or a grammar for the language [21], or a language specification the constraints (such as Alloy [22]). In this paper, our objective is to find a new way to build a DSL. That is a combination of modeling and semantic processing to specification (with rules). Our modeling approaches towards MDA [23]. It approaches towards the semantic processing with rule. We will verify this approach to business, which will be improved for our DSL. Our DSL will apply to businesses such as speedVietnam 1 , Anttek 2 . These organizations will join with us in testing the rightness

IV. F RAMEWORK In this section, we propose an architecture for DSL following the inspiration presented in [2]. The design composes of three components: a conceptual model, rule engine and code generation engine. First, the conceptual model captures concepts which represent the game characters, game objects (e.g.,

1 http://tocdo.vn/ 2 http://www.anttek.com/

38

Fig. 3. Main processing in our DSL TABLE I L IST OF GAME RULES DEFINED FOR THE GARDENING GAME No 1.

Name New Game

2.

Game Termination

3.

Behavior of tools

Rule definition {Hoe, SHORT, 10} & {Sprinkler, 18, 15} & {Scissor, MINI, 10} {Farmer, 10000} {Sunflower, 10} & {Tulip, 15} & {Rose, 10} {Farmer, 30000, 0} Sowing: {Hoe, Rose} → 5 & {Hoe, Sunflower} → 8 & {Hoe, Tulip} → 7 Growing: {Sprinkler, Rose} → 5 & {Sprinkler, Sunflower} → 10 & {Sprinkler, Tulip} → 7 Harvesting: {Scissors, Rose} → 15} & {Scissors, Sunflower} → 20 & {Scissors, Tulip} → 25

4.

Harvesting rule

(Rose, 20) && (Sunflower, 20) && (Tulip, 15) =⇒ Harvesting

5.

Time rule

Sowing: {Flower, 0} → 5 Growing: {Flower, 3} → 10 Harvesting: {Flower, 2} → 8

6.

Main activities

(Sowing =⇒ Growing) & (Growing =⇒ Harvesting)

and effectiveness of the tool. Results are expected to provide a better DSL which is useful for generating applications [24].

Rule description Declaring and initializing resources of the tools Initializing resource of the main character Initializing resources of the secondary characters Checking the winning condition and the game over condition Sowing rose, sunflower and tulip that costs 5, 8 and 7 points of resource from main character, respectively Growing rose, sunflower and tulip that adds 5, 10 and 7 points of resource to them, respectively Harvesting rose, sunflower and tulip that adds 15, 20 and 25 points of resource to the main character, respectively Rose, Sunflower and Tulip need to be harvested when they obtain 20, 20 and 15 points, respectively Sowing establishes 5 seconds for all flowers and set value 0 of resource to flowers when over 5 seconds. Growing establishes 10 seconds for all flowers and subtracts 3 points of resource to flowers when over 10 seconds. Flowers are to be harvested within 8 seconds or they lose 2 points. Sequence of the gardening activities

considered as the main approach to solve problems for our DSL. Besides, OMG’s MDA (Model-Driven Architecture) is widely publicized [23]. It is also be used to create a variety of tools to support the software developing process, including tools to support model drawing, model transformation and source code generation, such as on Eclipse environment. Combining conceptual model and rules: In this combined approach, software developers describe all the components at conceptual level. The rules are presented in the model as the rules are defined by our DSL. Our DSL combines conceptual model with the rules as a basis for generates code. Rule engine: To simplify the analysis, this is an engine that is based on a list of rules. The rules have been defined to verify

D. Objectives of our framework We develop the DSL framework to fulfill the following objectives. Modeling: Since 200, one of the approaches in building a program is converted from one model to another model called MDD (Model-Driven Development) [25]. In this approach, all the components are represented as models. A other approaches is object-oriented approach. In which, all the components are represented as objects. In our DSL, conceptual model is processed towards modeling. Therefore, MDD approach is

39

E. Illustration In our DSL, software developers who want to design the gardening game will perform the following steps: (see Figure 5 is the processing in our DSL).

Fig. 5. Step by step in our DSL

Step 1: Software developers design the game through graphical models. Then additional components such scenario parameters declared for the game: title, scorewin, scorefail, etc. They design the characters in the game such as tool: shovel, scissors, sprinkler, etc. The characters are cultivation (product): rose, tulip, sunflower, etc. Which character is full of attributes such as status, bonus. The action in rule combine tool and flower. It will be drafted by them. Step 2: Select inspection tools and semantic translation to check syntax and generate source code for the game. The editor checks the syntax of content in our grammar and sync between conceptual models and text. Step 3: Select incurred for the class source code and user interface. Step 4: Compile and execute the program. F. Prototype We also developed a simple tool that allows a software developer to specify an application by modeling. They declare the rules according to grammar. Then, the engine checks the coherence and rationality between model and the rules, converts into executable code. Figure 7 is the user interface in our DSL. In this user interface, software developers will choose control to design conceptual model. It supports them in editing the rules and checking their syntax. The objects in text will be synchronized with conceptual model and vice versa. In the above example, software developers design conceptual model with objects as follow: Flower are tulip, sunflower and rose. The tool are hoe, scissors and sprinkler. The rules are rulegrowing, rulesowing and ruleharvesting. The main character is farmer and has aggregation with the scene . The scene has aggregation with tools and flowers. The software developers continue to edit the content of the game as follows. {Hoe, SHORT, 10} & {Sprinkler, 18, 15} & {Scissors, MINI, 10} means declaring and initializing resources of the tools. Our DSL will check whether the tools exist in conceptual model or not and synchronize between them. For instance, {Farmer, 30000, 0} is the game termination. The editor will support to insert

Fig. 4. Grammar in our DSL

and generate source code for the application (game). The rule engine divides the text into propositions (simple sentences). This first stage is based on a semicolons (;) of the punctuation, and on a complex process of syntax analysis. Code generation: Our DSL has developed a process that is a compiler. It converts scripts (model concepts and rules) into executable source code for applications (games). Editor: Our DSL build an editor. In this editor, software developers can design the models of the application. They design the constraints between objects in the model. These models are described as UML models. Moreover, software developers can describe the content of the constraints in the model by text.

40

code automatically from conceptual mode and vice versa. Growing: {Sprinkler, Rose} → 5 & {Sprinkler, Sunflower} → 10 & {Sprinkler, Tulip} → 7 means

growing roses, sunflowers and tulips that adds 5, 10 and 7 points of resource to them, respectively. Harvesting: {Scissor, Rose} → 15} & {Scissor, Sunflower} → 20 & {Scissor, Tulip} → 25 means harvesting rose,

sunflower and tulip need to be harvested when they obtain 20, 20 and 15 points, respectively. Harvesting: {Flower, 2} → 8 means flowers are to be harvested within 8 seconds or they lose 2 points.

Fig. 7. Main window of the editor in our DSL

the application. The structure of the program will be divided into 3 packages. Packages 1 is the Model. Package 2 is the View and package 3 is the Controller. The model captures the behavior of the game application. The view has organized user interface and the controller has organized the handle of the object in the game application. V. C ONCLUSION Contribution. In this paper, we have proposed a new way to access and build a DSL tool, which has created a syntax specification for objects and their constraints in game applications (based on semantic processing). In our DSL, the rules describe the scenario of a game application. The conceptual models describe the objects in this game. The rule engine is an engine that allows the link between the rules and the conceptual models. Also, it generates executable code for game applications. With our DSL, the software developers can build a game application quickly (via 4 steps). Our main contributions can be summarized as follows: 1) Why you should link the conceptual models with the rules. 2) The connection between conceptual models and rules to be made between the combination modeling with semantics. 3) An editor tool with graphic user interface to support the proposed DSL. 4) Reorganizing the structure of the source code generated from the DSL towards MVC pattern. Future Work. To make our DSL complete, we aim to do the following tasks. i) developing engine specification draft and design tools in the conceptual model; ii) adding semantics to the rule specification more completely; and iii) implementation

Fig. 6. A metal model for Role-player games: to be customized

Figure IV-F shows an UML class diagram representing the key elements described before. The diagram is simple but general, and can be applied to almost any game made by our DSL. The central classes, quite intuitively, are SecondaryCharacter and PrimaryCharacter. Product and Tool induce a parent child relationship among SecondaryCharacter, which is characterized by the type of the character. We choose to model this relationship by making gObject an association class connected to the GameObject association for Rule. To keep the model simple we consider only 1-Primarycharacter joints. The association between Rule and the class Action basically models the intrinsic property that tells which relative activities is allowed by the Rule. Finally, when the software developer takes the final steps in our DSL, the tool will automatically generate source code for

41

of the tool which generates source code in java languages from the rule engine. R EFERENCES [1] M. Fowler, Domain-specific languages. Addision Walley, 2010, vol. 2. [2] M. M. J. Heering and A. Sloane, “When and how to develop domainspecic languages,” ACM Computing Surveys, vol. 37(4), pp. 316–344, 2005. [3] C. Atkinson and T. Khne., Concepts for comparing modeling tool architectures. Springer Berlin Heidelberg, 2005. [4] N. O. T. Kosar, Comparing general-purpose and domain-specific languages. Computer Science and Information Systems, 2010. [5] D.-H. Dang, A.-H. Truong, and M. Gogolla, “Checking the Conformance between Models Based on Scenario Synchronization,” J. UCS, vol. 16, pp. 2293–2312, 2010. [6] S. O. D. Kramer, T. Clark, “MobDSL: A Domain Specific Language for multiple mobile platform deployment,” Networked Embedded Systems for Enterprise Applications (NESEA), vol. 20, pp. pp 25–26, 2010. [7] J. B. M. Frigerio and D. Caldwell, “A Domain Specific Language for kinematic models and fast implementations of robot dynamics algorithms,” arXiv preprint arXiv, vol. 20, 2013. [8] A. T. A. Nordmann and S. Wrede, “A Domain-Specific Language and Simulation Architecture for the Oncilla Robot,” ICRA 2013 Workshop on Developments of Simulation Tools for Robotics & Biomechanic, vol. 20, pp. 25–26, 2013. [9] P. K. AVan Deursen and J. Visser, “Domain-Specific Languages: An Annotated Bibliography,” Sigplan Notices, vol. 6, pp. 25–36, 2009. [10] E. Friedman-Hill, JESS in Action. Manning Greenwich, CT, 2003. [11] M. B. AA. Birla, “MobiDSL - a Domain Specific Language for Mobile,” in The 9th OOPSLA workshop on Domain-Specific Modeling (DSM’09), Birla, 2009, pp. 130–150. [12] A. R. Meyer, “What is a model of the lambda calculus?” Information and control, vol. 52, no. 1, pp. 87–122, 1982. [13] A. Manjunatha, “A Domain Specic Language Based Method to Develop Cloud-Mobile Hybrid Applications,” in Kno.e.sis Center Wright State University, Dayton, Ohio, 2010, pp. 50–60. [14] M. H. F. Buschmann and C. Frank, Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects. John Wiley & Sons, 2013, vol. 2. [15] F. Paterno, Model-based design and evaluation of interactive applications, 2000, vol. 2. [16] H. Gomaa, Designing software product lines with UML. IEEE, 2005. [17] G. Nordstrom, J. Sztipanovits, G. Karsai, and A. Ledeczi, “Metamodeling-rapid design and evolution of domain-specific modeling environments,” in Engineering of Computer-Based Systems, 1999. Proceedings. ECBS’99. IEEE Conference and Workshop on. IEEE, 1999, pp. 68–74. [18] F. Jouault, J. Bzivin, and A. Team, “KM3: a dsl for metamodel specification,” in In proc. of 8th FMOODS, LNCS 4037. Springer, 2006, pp. 171–185. [19] I. K. J. Bzivin, F. Jouault and P. Valduriez, “Model-Based DSL Frameworks,” ATLAS (INRIA & LINA), vol. 2, 2007. [20] G. Guizzardi, “On ontology, ontologies, conceptualizations, modeling languages, and (meta) models,” Frontiers in artificial intelligence and applications, vol. 155, p. 18, 2007. [21] D. Jackson, Software Abstractions: logic, language, and analysis. MIT press, 2012. [22] C. Huang, Y. Kamei, K. Yamashita, and N. Ubayashi, “Using alloy to support feature-based DSL construction for mining software repositories,” in Proceedings of the 17th International Software Product Line Conference co-located workshops. ACM, 2013, pp. 86–89. [23] J. M. J. Miller, “Model driven architecture (mda),” Object Management Group, Draft Specification ormsc, vol. 2, 2001. [24] R. Gronback, Eclipse modeling project: a domain-specific language (DSL) toolkit. Addsion Walley, 2009, vol. 20. [25] T. Stahl, M. Voelter, and K. Czarnecki, Model-driven software development: technology, engineering, management. John Wiley & Sons, 2006.

42