DOCSLIB.ORG

Building Program Understanding Tools Using Visitor Combinators

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Building Program Understanding Tools Using Visitor Combinators Building Program Understanding Tools Using Visitor Combinators Arie van Deursen Joost Visser CWI, P.O. Box 94079 CWI, P.O. Box 94079 1090 GB Amsterdam, The Netherlands 1090 GB Amsterdam, The Netherlands http://www.cwi.nl/˜arie/ http://www.cwi.nl/˜jvisser/ ABSTRACT Visiting source models The intent of the visitor design pat- tern is to “represent an operation to be performed on the el- Program understanding tools manipulate program represen- ements of an object structure. A visitor lets you define a tations, such as abstract syntax trees, control-flow graphs, or new operation without changing the classes of the elements data-flow graphs. This paper deals with the use of visitor on which it operates” [8]. Often, visitors are constructed to combinators to conduct such manipulations. Visitor combi- traverse an object structure according to a particular built-in nators are an extension of the well-known visitor design pat- strategy, such as top-down, bottom-up, or breadth-first. tern. They are small, reusable classes that carry out specific A typical example of the use of the visitor pattern in pro- visiting steps. They can be composed in different constella- gram understanding tools involves the traversal of abstract tions to build more complex visitors. We evaluate the expres- syntax trees. The pattern offers an abstract class Visitor, which siveness, reusability, ease of development, and applicability defines a series of methods that are invoked when nodes of a of visitor combinators to the construction of program under- particular type (expressions, statements, etc.) are visited. A standing tools. To that end, we conduct a case study in the use concrete Visitor subclass refines these methods in order to per- of visitor combinators for control-flow analysis and visualiza- form specific actions when accepted by a given syntax tree. tion as used in a commercial Cobol program understanding tool. Visitors are useful for analysis and transformation of source models for several reasons. Using visitors makes it 1998 ACM Computing Classification System: D.2.9, D.2.2, easy to traverse structures that consist of many different kinds D.2.5, D.2.7 of nodes, while conducting actions on only a selected num- ber of them. Moreover, visitors help to separate traversal from Keywords and Phrases: Program analysis, program compre- representation, making it possible to use a single source model hension, visitor design pattern, software visualization. for various sorts of analysis. Note: Work carried out under projects SEN 1.1, Software Ren- Visitor Combinators Recently, visitor combinators have ovation and SEN 1.3, Domain-Specific Languages. been proposed as an extension of the regular visitor design pattern [14]. The aim of visitor combinators is to compose Note: To appear in Proceedings of the 10th International complex visitors from elementary ones. This is done by sim- Workshop on Program Comprehension (IWCP), IEEE Com- ply passing them as arguments to each other. Furthermore, puter Society, 2002. visitor combinators offer full control over the traversal strat- egy and applicability conditions of the constructed visitors. The use of visitor combinators leads to small, reusable 1. Introduction classes, that have little dependence on the actual structure of the concrete objects being traversed. Thus, they are less brit- Program analysis and source models Program analysis is tle with respect to changes in the class hierarchy on which a crucial part of many program understanding tools. Program they operate. In fact, many combinators (such as the top-down analysis involves the construction of source models from the or breadth-first combinators) are completely generic, relying program source text and the subsequent analysis of these mod- only on a minimal Visitable interface. As a result, they can be els. Depending on the analysis problem, these source models reused for any concrete visitor instantiation. might be represented by tables, trees, or graphs. More often than not, the models are obtained through a se- Goals of the paper The concept of visitor combinators is quence of steps. Each step can construct new models or refine based on solid theoretical ground, and it promises to be a pow- existing ones. Usually, the first model is an (abstract) syntax erful implementation technique for processing source models tree constructed during parsing, which is then used to derive in the context of program analysis and understanding. Now graphs representing, for example, control or data flow. 1 Library Name Args Description Framework Visitable Visitor Identity Do nothing getChildCount visit(Visitable) getChildAt Fail Raise VisitFailure exception setChildAt Not v Fail if v succeeds, and v.v. Sequence v1, v2 Do v1, then v2 Operations Instantation Visitable Visitor Choice v1, v2 Try v1, if it fails, do v2 visitA All v Apply v to all immediate children visitB One v Apply v to one immediate child Hierarchy IfThenElse c,t, f If c succeeds, do t, otherwise do f A B Fwd Try v Choice(v,Identity) TopDown v Sequence(v,All(TopDown(v))) Figure 1. The architecture of JJTraveler. BottomUp v Sequence(All(BottomUp(v)),v) OnceTopDown v Choice(v,One(OnceTopDown(v))) OnceBottomUp v Choice(One(OnceBottomUp(v)),v) this concept needs to be put to the test of practice. AllTopDown v Choice(v,All(AllTopDown(v))) We have implemented ControlCruiser, a tool for analyzing AllBottomUp v Choice(All(AllBottomUp(v)),v) and visualizing intra-program control flow for Cobol. In this paper, we explain by reference to ControlCruiser how visi- Figure 2. JJTraveler’s library (excerpt). tor combinators can be used to develop program understand- ing tools. We discuss design tactics, programming techniques, Instantiation To use JJTraveler, one needs to instantiate the unit testing, implementation trade-offs, and other engineering framework for the class hierarchy of a particular application. practices related to visitor combinator development. Finally, To do this, the hierarchy is turned into a visitable hierarchy by we asses the risks and benefits of adopting visitor combinators letting every class implement the Visitable interface. Also, the for building program understanding tools. generic Visitor interface is extended with specific visit meth- ods for each class in the hierarchy. Finally, a single imple- mentation of the extended visitor interface is provided in the 2. Visitor Combinators form of a visitor combinator Fwd. This combinator forwards every specific visit call to a generic default visitor given to it Visitor combinator programming was introduced in [14] and is at construction time. Concrete visitors are built by providing supported by JJTraveler: a combination of a framework and li- Fwd with the proper default visitor, and overriding some of its brary that provides generic visitor combinators for Java. This specific visit methods. section briefly discusses the key elements of JJTraveler. Though instantiation of JJTraveler’s framework can be done manually, automated support for this is provided by a 2.1. The architecture of JJTraveler generator, called JJForester [10]. This generator takes a gram- mar as input. From this grammar, it generates a class hierar- Figure 1 shows the architecture of JJTraveler (upper half) and chy to represent the parse trees corresponding to the grammar, its relationship with an application that uses it (lower half). the hierarchy-specific Visitor and Visitable interfaces, and the JJTraveler consists of a framework and a library. The applica- Fwd combinator. In addition to framework instantiation, JJ- tion consists of a class hierarchy, an instantiation of JJTrav- Forester provides connectivity to a generalized LR parser [2]. eler’s framework for this hierarchy, and the operations on the Operations After instantiation, the application programmer hierarchy implemented as visitors. can implement operations on the class hierarchy by specializ- Framework The JJTraveler framework offers two generic ing, composing, and applying visitors. interfaces, Visitor and Visitable. The latter provides the min- The starting point of hierarchy-specific visitors is Fwd. imal interface for nodes that can be visited. Visitable nodes Typical default visitors provided to Fwd are Identity and Fail. should offer three methods: to get the number of child nodes, Furthermore, Fwd contains a method visitA for every class A to get a child given an index, and to modify a given child. The in the hierarchy, which can be overridden in order to construct Visitor interface provides a single visit method that takes any specific visitors. As an example, an A-recognizer IsA (which visitable node as argument. Each visit can succeed or fail, only does not fail on A-nodes) can be obtained by an appro- which can be used to control traversal behavior. Failure is in- priate specialization of method visitA of Fwd(Fail). dicated by a VisitFailure exception. Visitors are combined by passing them as (constructor) ar- Library The library consists of a number of predefined vis- guments. For example, All(IsA) is a visitor which checks that itor combinators. These rely only on the generic Visitor and any of the direct child nodes are of class A, and OnceTop- Visitable interfaces, not on any specific underlying class hi- Down(IsA) is a visitor checking whether a tree contains any erarchy. An overview of the library combinators is shown in A-node. Visitors are applied to visitable objects through the Figure 2. They will be explained in more detail below. visit method, such as IsA.visit(myA) (which does nothing), or 2 public class Sequence implements Visitor { public class TopDownWhile extends Choice { Visitor v1; public TopDownWhile(Visitor v1, Visitor v2) { Visitor v2; super(null,v2); public Sequence(Visitor v1, Visitor v2) { setArgument(1,new Sequence(v1,new All(this))); this.v1 = v1; } this.v2 = v2; public TopDownWhile(Visitor v) { } this(v,new Identity()); public void visit(Visitable x) { } } v1.visit(x); v2.visit(x); Figure 5. The TopDownWhile combinator. } } ¢ Figure 3. The Sequence combinator. visitor combinator TopDownWhile v1 ¡ v2 .
Load more

Recommended publications
  • 1 Design Pattern for Open Class (DRAFT) 2 Abstract Factory
    1 Design Pattern for Open Class (DRAFT) Tanaka Akira <[email protected]> A design pattern describes a software architecture which is reusable and exten- sible. [GoF] is the book containing 23 design patterns for OOP languages like C++ and Java. [GoF] describes several trade offs of the patterns. In C++ and Java, a class is defined by only one module. However, there are languages which can define a class by two or more modules: Cecil, MultiJava, AspectJ, MixJuice, CLOS, Ruby, etc. Such class is called "open class" because it is extensible by modules implemented later [Chambers]. For languages with open class, more extensible and/or simpler design patterns exists. We studied design patterns with open class for each GoF design patterns. In this paper, we describe two patterns: the Abstract Factory pattern and the Visitor pattern. 2 Abstract Factory The Abstract Factory pattern is a design pattern for separating class names from the code which generates the object group of related classes for making them configurable. Following figure is the class diagram of the Abstract Factory pattern. Since the example described in [GoF] uses only one concrete factory for each binaries, the required concrete factory is selected statically. The example builds two binaries for Motif and Presentation Manager from a single source code. Two concrete factories are exist for Motif and Presentation Manager. When a binary is built, it is selected which concrete factory is linked. Such static selection can be implemented with the fewer number of classes by open class as following modules. • The module which defines Window and ScrollBar class and their methods which is independent to window systems.
    [Show full text]
  • Tree Visitors in Clojure Update the Java Visitor Pattern with Functional Zippers
    Tree visitors in Clojure Update the Java Visitor pattern with functional zippers Skill Level: Intermediate Alex Miller ([email protected]) Senior Engineer Revelytix 20 Sep 2011 JVM language explorer Alex Miller has recently discovered the benefits of implementing the Visitor pattern using Clojure, a functional Lisp variant for the Java Virtual Machine. In this article, he revisits the Visitor pattern, first demonstrating its use in traversing tree data in Java programs, then rewriting it with the addition of Clojure's functional zippers. I’ve used trees of domain objects in my Java applications for many years. More recently, I’ve been using them in Clojure. In each case, I've found that the Visitor pattern is a reliable tool for manipulating trees of data. But there are differences in how the pattern works in a functional versus object-oriented language, and in the results it yields. About Clojure Clojure is a dynamic and functional programming language variant of Lisp, written specifically for the JVM. Learn more about Clojure on developerWorks: •"The Clojure programming language" •"Clojure and concurrency" •"Solving the Expression Problem with Clojure 1.2" •"Using CouchDB with Clojure" In this article, I revisit domain trees and the Visitor pattern for the Java language, Tree visitors in Clojure Trademarks © Copyright IBM Corporation 2011 Page 1 of 27 developerWorks® ibm.com/developerWorks then walk through several visitor implementations using Clojure. Being a functional language, Clojure brings new tricks to data query and manipulation. In particular, I've found that integrating functional zippers into the Visitor pattern yields efficiency benefits, which I explore.
    [Show full text]
  • Object-Oriented Desgin Visitor Pattern George Blankenship 1
    Object-Oriented Desgin Visitor Pattern CSCI 253 Object Oriented Design: Visitor Pattern George Blankenship Visitor Pattern George Blankenship 1 Overview Creational Patterns Structural Patterns Behavioral Patterns Singleton Composite Chain of Respons. Abstract factory Façade Command Factory Method Proxy Interpreter Prototype Flyweight Iterator Builder Mediator Adapter Memento Bridge Observer Decorator State Strategy Template Method Visitor Pattern George Blankenship Visitor 2 The Elements of a Design Pattern • A pattern name • The problem that the pattern solves – Including conditions for the pattern to be applicable • The solution to the problem brought by the pattern – The elements (classes-objects) involved, their roles, responsibilities, relationships and collaborations – Not a particular concrete design or implementation • The consequences of applying the pattern – Time and space trade off – Language and implementation issues – Effects on flexibility, extensibility, portability Visitor Pattern George Blankenship 3 George Blankenship 1 Object-Oriented Desgin Visitor Pattern The Visitor Pattern: The Problem Represents an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates • many distinct and unrelated operations need to be performed on objects in an object structure an you want to avoid “polluting” their classes with these operations • the classes defining the object structure rarely change but you often want to define new operations over the structure Visitor Pattern George Blankenship 4 Visitor Example • The root of the structure accepts a visitor: root.accept( visitor ) • The root and every child object in the structure have a an accept method: void accept( visitor ) { visitor.visit( this ); for each child of mine child.accept( visitor ) next } • In short order our visitor gets a visit() call from each object in the collection.
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • Permissions, Visitor Pattern
    Selected Topics in Object Oriented Programming Lecture 3: More OOP principles Leonid Barenboim Permissions Permissions define the areas within a program from which a feature (field/ method) can be accessed: private – only within the same class. protected - only within the class and its subclasses. public – from everywhere. Permission in java Java use somewhat different rules: private – only within the same class. package – only within the same package. protected – within the same package and within the subclasses outside the package. public – from everywhere. Selecting the right permission The principle of encapsulation suggests the following rules: All non-static fields should be private Service methods should be public Helper methods should be private/protected Permission rules in specific languages Smalltalk – all fields are private all methods are public Scripting languages (e.g., python) - No permissions! - Everything is public! The Visitor Pattern Reminder: Polymorphism Reminder: Polymorphism Animal animal; animal = new Dog; Animal * animal.say(); \\ “Woof” animal = new Cat; + say() * animal.say(); \\ “Miau” Cat Dog + say() + say() System.out.println(“Miau”) System.out.println(“Woof”) What happens if a method accepts an argument? boolean b; Animal * Animal cat = new Cat(); Animal mouse = new + say() * Mouse(); + eats(mouse: Mouse) : bool * b = cat.eats(mouse); + eats(cat: Cat) : bool * //compilation error Cat Mouse + say() + say() +eats(mouse : Mouse) : bool +eats(mouse : Mouse) : bool +eats(cat : Cat) : bool +eats(cat : Cat) : bool No support for polymorphism of arguments • Java (and many other languages) supports only polymorphism of the receiver (the variable on which the method is invoked). • Polymorphism of the receiver is performed using single dispatch. • Polymorphism of arguments is performed using multiple-level dispatch, which is resource consuming.
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • On the Interaction of Object-Oriented Design Patterns and Programming
    On the Interaction of Object-Oriented Design Patterns and Programming Languages Gerald Baumgartner∗ Konstantin L¨aufer∗∗ Vincent F. Russo∗∗∗ ∗ Department of Computer and Information Science The Ohio State University 395 Dreese Lab., 2015 Neil Ave. Columbus, OH 43210–1277, USA [email protected] ∗∗ Department of Mathematical and Computer Sciences Loyola University Chicago 6525 N. Sheridan Rd. Chicago, IL 60626, USA [email protected] ∗∗∗ Lycos, Inc. 400–2 Totten Pond Rd. Waltham, MA 02154, USA [email protected] February 29, 1996 Abstract Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implemen- tation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the arXiv:1905.13674v1 [cs.PL] 31 May 2019 implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes subtyping separate from inheritance, lexically scoped closure objects independent of classes, and multimethod dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and programming language research and combined in a new, orthogonal manner. We argue that by describing design pat- terns in terms of the proposed constructs and mechanisms, pattern descriptions become simpler and, therefore, accessible to a larger number of language communities.
    [Show full text]
  • A Survey of Design Pattern Based Web Applications
    JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2009 Vol. 8, No. 2, March-April 2009 A Survey of Design Pattern Based Web Applications Sridaran R, Campus Head, ICFAI National College, Vellore-632 006 India. Padmavathi G, Professor and Head, Department of Computer Science, Avinashilingam University for Women, Coimbatore-641 043, India. Iyakutti K, Senior Professor, School of Physics, Madurai Kamaraj University, Madurai-625 019, India. Abstract Pattern-based web applications have become popular since they promote reusability and consistency. In few cases, patterns do not produce the desired effect because of lack of experience in applying them. This situation forces one to think of a suitable re- engineering solution for such applications. The objectives of the paper are three fold. It provides a survey of different pattern-based web applications that will be useful for the application designers. It highlights some of the web applications where patterns have been inappropriately handled. A few re-engineering initiatives for such cases are also analyzed. Key Words: Patterns, Web Applications, Re-engineering, Hypermedia, Semantic web, Partitioning. 1 INTRODUCTION Web application designers need to address many challenges during development in order to comply the quality of service requirements including speed, scalability and security. In recent years numerous non-web based applications have been re-written as web based because of the ever growing business needs. These migration activities are much more complicated and time consuming than a new software development. Most of these challenges are with data handling, organizing, or structuring of the web applications.
    [Show full text]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]
  • Mutable Class Design Pattern Nikolay Malitsky Nova Southeastern University, [email protected]
    Nova Southeastern University NSUWorks CEC Theses and Dissertations College of Engineering and Computing 2016 Mutable Class Design Pattern Nikolay Malitsky Nova Southeastern University, [email protected] This document is a product of extensive research conducted at the Nova Southeastern University College of Engineering and Computing. For more information on research and degree programs at the NSU College of Engineering and Computing, please click here. Follow this and additional works at: https://nsuworks.nova.edu/gscis_etd Part of the Other Computer Sciences Commons, and the Theory and Algorithms Commons Share Feedback About This Item NSUWorks Citation Nikolay Malitsky. 2016. Mutable Class Design Pattern. Doctoral dissertation. Nova Southeastern University. Retrieved from NSUWorks, College of Engineering and Computing. (956) https://nsuworks.nova.edu/gscis_etd/956. This Dissertation is brought to you by the College of Engineering and Computing at NSUWorks. It has been accepted for inclusion in CEC Theses and Dissertations by an authorized administrator of NSUWorks. For more information, please contact [email protected]. Mutable Class Design Pattern by Nikolay Malitsky A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science Graduate School of Computer and Information Sciences Nova Southeastern University 2016 We hereby certify that this dissertation, submitted by Nikolay Malitsky, conforms to acceptable standards and is fully adequate in scope and quality to fulfill the dissertation requirements for the degree of Doctor of Philosophy. _____________________________________________ ________________ Michael J. Laszlo, Ph.D. Date Chairperson of Dissertation Committee _____________________________________________ ________________ Francisco J. Mitropoulos, Ph.D. Date Dissertation Committee Member _____________________________________________ ________________ Amon B.
    [Show full text]
  • Design Pattern Driven Development of Model Transformations
    DESIGN PATTERN DRIVEN DEVELOPMENT OF MODEL TRANSFORMATIONS by HUSEYIN ERGIN JEFF GRAY, COMMITTEE CHAIR JEFFREY CARVER RALF LAEMMEL RANDY SMITH EUGENE SYRIANI SUSAN VRBSKY A DISSERTATION Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Computer Science in the Graduate School of The University of Alabama TUSCALOOSA, ALABAMA 2017 Copyright Huseyin Ergin 2017 ALL RIGHTS RESERVED ABSTRACT Model-Driven Engineering (MDE) is considered a well-established software development ap- proach that uses abstraction to bridge the gap between the problem space and the software implementation. These abstractions are represented by models that make the validation of the real system easier. In MDE, many problems are solved using model transformation, which is a paradigm that manipulates high-level models to translate, evolve, or simulate them. However, the development of a model transformation for a specific problem is still a hard task. The main reason is the lack of a development process where transformations must be designed before implemented. Design patterns provide experiential reuse to soft- ware engineers when faced with recurring problems. In the literature, design patterns have been used to generate partially reusable software designs in order to help developers. There are many design patterns focused development methodologies proposed. However, most of them specialize in object-oriented design patterns. Given the various contexts in which de- sign patterns have been applied, model transformations may also benefit from a patterns approach. Although several studies have proposed design patterns for model transforma- tion, there is still no accepted common language to express them or a methodology that places design patterns at the heart of the development of model transformations.
    [Show full text]
  • Two Implementation Techniques for Domain Specific Languages
    University of Amsterdam Faculty of Science Master’s Thesis Two implementation techniques for Domain Specific Languages compared: OMeta/JS vs. JavaScript Author: Host organization: Nickolas Heirbaut Centrum Wiskunde & Informatica Date approval: Supervisor: 8 October 2009 Dr. Tijs Van Der Storm Contents Abstract 4 Preface 5 1 Introduction 6 1.1 Motivation ....................................... 6 1.2 Research questions ................................... 7 1.3 Organization of this thesis ............................... 7 2 Background and context 8 2.1 Domain-specific languages ............................... 8 2.1.1 Introduction .................................. 8 2.1.2 Development phases .............................. 9 2.1.3 Implementation strategies ........................... 10 2.2 OMeta .......................................... 13 2.2.1 Introduction .................................. 13 2.2.2 Parsing Expression Grammar ......................... 13 2.2.3 OMeta: an extended PEG ........................... 16 2.3 Waebric ......................................... 19 2.3.1 Introduction .................................. 19 2.3.2 Example ..................................... 19 2.3.3 Embedded markup ............................... 20 2.3.4 Juxtaposition .................................. 21 2.3.5 Around parameterization ........................... 21 1 3 Research method 23 3.1 Maintainability ..................................... 25 3.1.1 Program code metrics ............................. 25 3.1.2 Grammar metrics ...............................
    [Show full text]