DOCSLIB.ORG

A GUIDED FRAMEWORK for STRUCTURAL MODELING By

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

ABSTRACT INTUITIVE MODEL TRANSFORMATIONS: A GUIDED FRAMEWORK FOR STRUCTURAL MODELING by Nicholas John DiGennaro As research in Model­Driven Software Engineering (MDSE) continues to innovate the software engineering process, a gap has been created between its potential benefit and actual use. This gap exists due to MDSE education being held back by tools that are not well­suited for learning and use by beginners. To teach new developers MDSE concepts before moving into industrial tools, MDSE educators need a lightweight, model­first, end­to­end teaching tool. The Instructional Modeling Language (IML) is proposed as a solution to fit these needs. This thesis implements for the IML Framework one of the foundational aspects of MDSE: Model Transformations. The ability to apply model transformations to large collections of models contributes to software reuse, allowing developers to dedicate efforts elsewhere. Furthermore, the early work of conceptually modeling systems has a larger payoff as a result of model transformations being used in the code generation process. These benefits are some of the most influential factors for adopting MDSE and must be properly emphasized in education. Model transformations in IML provide students with a guided experience and clear explanations of the model transformation processes. In turn, students are provided with a solid foundation in MDSE and its benefits. INTUITIVE MODEL TRANSFORMATIONS: A GUIDED FRAMEWORK FOR STRUCTURAL MODELING A Thesis Submitted to the Faculty of Miami University in partial fulfillment of the requirements for the degree of Master of Science by Nicholas John DiGennaro Miami University Oxford, Ohio 2021 Advisor: Eric J. Rapos, PhD Reader: Matthew Stephan, PhD Reader: Hakam W. Alomari, PhD ©2021 Nicholas John DiGennaro This Thesis titled INTUITIVE MODEL TRANSFORMATIONS: A GUIDED FRAMEWORK FOR STRUCTURAL MODELING by Nicholas John DiGennaro has been approved for publication by The College of Engineering and Computing and The Department of Computer Science & Software Engineering Eric J. Rapos, PhD Matthew Stephan, PhD Hakam W. Alomari, PhD Table of Contents List of Tables v List of Figures vi Acknowledgements ix 1 Introduction 1 1.1 Motivation . 1 1.2 Contributions . 2 1.2.1 Overview . 2 2 Background & Related Work 3 2.1 Background . 3 2.1.1 Model­Driven Software Engineering . 3 2.1.2 Educational Language Design . 10 2.1.3 Software to Support Teaching Goals . 10 2.2 Related Work . 11 2.2.1 Tools to Support MDSE . 11 2.2.2 Motivating Work . 15 3 Web­Based Model Editor 16 3.1 JointJS . 16 3.2 Technology Stack . 18 3.3 Web Page Structure . 19 3.4 Editor, Palette and Backend . 21 3.5 Properties Table . 27 3.6 Export and Import . 30 4 Code Generation 33 4.1 Metamodel Code Generation . 33 4.2 Instance Model Code Generation . 39 5 Model­to­Model Transformations 42 5.1 Model Transformations Page . 42 iii 5.2 Mapping Rules . 47 5.3 Transforming Instance Models . 56 6 Evaluation 63 6.1 Experimental Design . 63 6.1.1 Web­Based Model Editor . 63 6.1.2 Code Generation . 63 6.1.3 Model­to­Model Transformations . 66 6.2 Results . 67 6.2.1 Code Generation . 67 6.2.2 Model­to­Model Transformations . 70 6.3 Discussion . 71 7 Conclusion 77 7.1 Threats to Validity . 77 7.2 Future Work . 78 7.3 Summary . 78 A Code Generation Complex Example Actual Output 80 References 91 iv List of Tables 2.1 Terminology Comparison. 4 6.1 Code generation evaluation . 68 6.2 ASCII comment evaluation. The Empty Abstract test was unable to be used be­ cause the test was evaluated with the set of files generated for the Inheritance Primitives test, therefore, it has no generated code. The Type and Default Value test was not used because the same metamodel was use for the Type and Value test, therefore, it would be redundant to perform this test. 70 6.3 M2M evaluation, part 1. Class, Attribute and Relation tests. 72 6.4 M2M evaluation, part 2. Complex Mapping and Assisting in Conformance tests. 73 v List of Figures 2.1 Example Model of Simple University System . 5 2.2 Model transformation from M to M’. Adapted from Model­Driven Software Engi­ neering in Practice, figure 8.1 (a) [1].......................... 7 2.3 Code Generation. Adapted from Model­Driven Software Engineering in Practice, figure 8.1 (a) [1]. ................................... 8 3.1 JointJS UML model demos. Obtained from [2].................... 17 3.2 IML Class Pseudocode . 17 3.3 IML Class Example . 17 3.4 JointJS Link Pseudocode . 18 3.5 IML Relations . 18 3.6 Model editor mock­up . 20 3.7 Palette code snippet . 20 3.8 Final version of the model editor UI. 20 3.9 Example of Meta­Model Conformance panel when an instance model is out of con­ formance with its metamodel while instance modeling. 21 3.10 IML class (left) vs UML class (right). This image displays an example UML class from the OMG Unified Modeling Language specification [3]. 22 3.11 Key of visual bounds used in IML model editor. 22 3.12 IML model displaying the ability to represent object attributes. 23 3.13 Palette icon snippet . 23 3.14 Class inheritance example . 24 3.15 Example of a relation cycle. This figure was cropped because it is impossible to create a model of this type in IML. 25 3.16 Find relation cycle pseudocode . 26 3.17 Iml Structural Model, structural model . 26 3.18 Example properties table. The name attribute of the person class from figure 3.3 is selected. 28 3.19 Example properties table in edit mode. The name attribute of the person class from figure 3.3 is selected. 29 3.20 Attribute popup . 29 3.21 Upper bound edit mode . 29 3.22 Type edit mode . 30 vi 3.23 IML model representing a Person class with two attributes name and age. This model also includes an empty class Phone and a relation from Person to Phone. 31 3.24 The XML file that corresponds to the model found in figure 3.23 .......... 31 4.1 Empty abstract class . 33 4.2 Abstract class code snippet . 34 4.3 Primitive attribute generation examples . 36 4.4 Object attribute generation examples . 37 4.5 Constructor generation example . 37 4.6 Pretty print for an object with primitive and object attributes. 38 4.7 ASCII art for class code in figure 4.4......................... 39 4.8 Generated instance code . 40 5.1 Model transformation UI before user interaction . 43 5.2 Model transformation UI after completed transformation . 43 5.3 Model transformation UI after successful source metamodel upload. 44 5.4 Model transformation UI after successful source and target metamodel upload. 45 5.5 Model transformation UI after one defined rule. 46 5.6 Model transformation UI after successful input instance model upload. 47 5.7 Map classes modal. 48 5.8 Map classes modal with drop down. 49 5.9 Map attributes modal. 49 5.10 Map attributes modal with drop down. 50 5.11 Map last attributes of a class mapping. 50 5.12 Mapping success modal. 51 5.13 Mapping to none success modal. 52 5.14 Complex class mapping modal. 52 5.15 Complex class mapping modal with multiple conditions. 53 5.16 Complex Attribute mapping modal. 53 5.17 String operators. 54 5.18 Integer and double operators. 55 5.19 Boolean attribute condition. 55 5.20 Complex rule displayed in transformation rules panel. 56 5.21 Class attribute assignment modal. 57 5.22 Class mapping with saved attribute assignment. 57 5.23 Attribute assignment modal with existing attribute assignment. 58 5.24 Attribute assignment modal. ..
Recommended publications
  • UML Tutorial: Part 1 -- Class Diagrams

    UML Tutorial: Part 1 -- Class Diagrams

    UML Tutorial: Part 1 -- Class Diagrams. Robert C. Martin My next several columns will be a running tutorial of UML. The 1.0 version of UML was released on the 13th of January, 1997. The 1.1 release should be out before the end of the year. This col- umn will track the progress of UML and present the issues that the three amigos (Grady Booch, Jim Rumbaugh, and Ivar Jacobson) are dealing with. Introduction UML stands for Unified Modeling Language. It represents a unification of the concepts and nota- tions presented by the three amigos in their respective books1. The goal is for UML to become a common language for creating models of object oriented computer software. In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML. The Meta-model UML is unique in that it has a standard data representation. This representation is called the meta- model. The meta-model is a description of UML in UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software application. This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also make it easier to write ancillary tools for browsing, summarizing, and modifying UML models. A deeper discussion of the metamodel is beyond the scope of this column. Interested readers can learn more about it by downloading the UML documents from the rational web site2.
  • Interface Types for Haskell

    Interface Types for Haskell

    Interface Types for Haskell Peter Thiemann and Stefan Wehr Institut f¨urInformatik, Universit¨atFreiburg, Germany {thiemann,wehr}@informatik.uni-freiburg.de Abstract. Interface types are a useful concept in object-oriented pro- gramming languages like Java or C#. A clean programming style advo- cates relying on interfaces without revealing their implementation. Haskell’s type classes provide a closely related facility for stating an in- terface separately from its implementation. However, there are situations in which no simple mechanism exists to hide the identity of the imple- mentation type of a type class. This work provides such a mechanism through the integration of lightweight interface types into Haskell. The extension is non-intrusive as no additional syntax is needed and no existing programs are affected. The implementation extends the treat- ment of higher-rank polymorphism in production Haskell compilers. 1 Introduction Interfaces in object-oriented programming languages and type classes in Haskell are closely related: both define the types of certain operations without revealing their implementations. In Java, the name of an interface also acts as an interface type, whereas the name of a type class can only be used to constrain types. Interface types are a proven tool for ensuring data abstraction and information hiding. In many cases, Haskell type classes can serve the same purpose, but there are situations for which the solutions available in Haskell have severe drawbacks. Interface types provide a simple and elegant solution in these situations. A modest extension to Haskell provides the simplicity and elegance of interface types: simply allow programmers to use the name of a type class as a first- class type.
  • Plantuml Language Reference Guide (Version 1.2021.2)

    Plantuml Language Reference Guide (Version 1.2021.2)

    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
  • Chapter 8. Deploying an Osgi Service

    Chapter 8. Deploying an Osgi Service

    Chapter 8. Deploying an OSGi Service The OSGi core framework defines the OSGi Service Layer, which provides a simple mechanism for bundles to interact by registering Java objects as services in the OSGi service registry. One of the strengths of the OSGi service model is that any Java object can be offered as a service: there are no particular constraints, inheritance rules, or annotations that must be applied to the service class. This chapter describes how to deploy an OSGi service using the OSGi blueprint container. The Blueprint Container ........................................................................................................... 92 Blueprint Configuration ................................................................................................... 93 Defining a Service Bean .................................................................................................. 95 Exporting a Service ........................................................................................................ 98 Importing a Service ...................................................................................................... 104 Publishing an OSGi Service .................................................................................................... 113 Accessing an OSGi Service ..................................................................................................... 118 FUSE ESB Deploying into the OSGi Container Version 4.2 91 Chapter 8. Deploying an OSGi Service The Blueprint Container Blueprint Configuration
  • Semantic Based Model of Conceptual Work Products for Formal Verification of Complex Interactive Systems

    Semantic Based Model of Conceptual Work Products for Formal Verification of Complex Interactive Systems

    Semantic based model of Conceptual Work Products for formal verification of complex interactive systems Mohcine Madkour1*, Keith Butler2, Eric Mercer3, Ali Bahrami4, Cui Tao1 1 The University of Texas Health Science Center at Houston, School of Biomedical Informatics, 7000 Fannin St Suite 600, Houston, TX 77030 2 University of Washington, Department of Human Centered Design and Engineering Box 352315, Sieg Hall, Room 208 Seattle, WA 98195 3 Brigham Young University Computer Science Department, 3334 TMCB PO Box 26576 Provo, UT 84602-6576 4 Medico System Inc. 10900 NE 8th Street Suite 900 Bellevue, WA 98004 * Corresponding author, email: [email protected], phone: (+1) 281-652-7118 Abstract - Many clinical workflows depend on interactive computer systems for highly technical, conceptual work 1. Introduction products, such as diagnoses, treatment plans, care Many critical systems require highly complex user interactions coordination, and case management. We describe an and a large number of cognitive tasks. These systems are automatic logic reasoner to verify objective specifications common in clinical health care and also many other industries for these highly technical, but abstract, work products that where the consequences of failure can be very expensive or are essential to care. The conceptual work products risky to human safety. Formal verification through model specifications serve as a fundamental output requirement, checking could reduce or prevent system failures, but several which must be clearly stated, correct and solvable. There is technical obstacles must be solved first. strategic importance for such specifications because, in We focus here on the abstract products of conceptual work turn, they enable system model checking to verify that that are foundational requirements that must be part of machine functions taken with user procedures are actually verification in a modern health care systems.
  • Mixin-Based Programming in C++1

    Mixin-Based Programming in C++1

    Mixin-Based Programming in C++1 Yannis Smaragdakis Don Batory College of Computing Department of Computer Sciences Georgia Institute of Technology The University of Texas at Austin Atlanta, GA 30332 Austin, Texas 78712 [email protected] [email protected] Abstract. Combinations of C++ features, like inheritance, templates, and class nesting, allow for the expression of powerful component patterns. In particular, research has demonstrated that, using C++ mixin classes, one can express lay- ered component-based designs concisely with efficient implementations. In this paper, we discuss pragmatic issues related to component-based programming using C++ mixins. We explain surprising interactions of C++ features and poli- cies that sometimes complicate mixin implementations, while other times enable additional functionality without extra effort. 1 Introduction Large software artifacts are arguably among the most complex products of human intellect. The complexity of software has led to implementation methodologies that divide a problem into manageable parts and compose the parts to form the final prod- uct. Several research efforts have argued that C++ templates (a powerful parameteriza- tion mechanism) can be used to perform this division elegantly. In particular, the work of VanHilst and Notkin [29][30][31] showed how one can implement collaboration-based (or role-based) designs using a certain templatized class pattern, known as a mixin class (or just mixin). Compared to other techniques (e.g., a straightforward use of application frameworks [17]) the VanHilst and Notkin method yields less redundancy and reusable components that reflect the structure of the design. At the same time, unnecessary dynamic binding can be eliminated, result- ing into more efficient implementations.
  • Interface Evolution Via Virtual Extension Methods Brian Goetz Fourth Draft, June 2011

    Interface Evolution Via Virtual Extension Methods Brian Goetz Fourth Draft, June 2011

    Interface evolution via virtual extension methods Brian Goetz Fourth draft, June 2011 1. Problem statement Once published, it is impossible to add methods to an interface without breaking existing implementations. (Specifically, adding a method to an interface is not a source- compatible change.) The longer the time since a library has been published, the more likely it is that this restriction will cause grief for its maintainers. The addition of closures to the Java language in JDK 7 place additional stress on the aging Collection interfaces; one of the most significant benefits of closures is that it enables the development of more powerful libraries. It would be disappointing to add a language feature that enables better libraries while at the same time not extending the core libraries to take advantage of that feature1. V1 of the Lambda Strawman proposed C#-style static extension methods as a means of creating the illusion of adding methods to existing classes and interfaces, but they have significant limitations – for example, they cannot be overridden by classes that implement the interface being extended, so implementations are stuck with the “one size fits all” implementation provided as an extension2, and they are not reflectively discoverable. 2. Virtual extension methods3 In this document, we outline a mechanism for adding new methods to existing interfaces, which we call virtual extension methods. Existing interfaces can be augmented without compromising backward compatibility4 by adding extension methods to the interface, whose declaration would contain instructions for finding the default implementation in the event that implementers do not provide a method body.
  • Dynamic Interfaces

    Dynamic Interfaces

    Dynamic Interfaces Vasco T. Vasconcelos Simon J. Gay Antonio´ Ravara Departamento de Informatica´ Department of Computing Science SQIG at Instituto de Telecomunicac¸oes˜ Faculdade de Cienciasˆ da University of Glasgow, UK Department of Mathematics, IST, Universidade de Lisboa, Portugal [email protected] Technical University of Lisbon, Portugal [email protected] [email protected] Nils Gesbert Alexandre Z. Caldeira Department of Computing Science Departamento de Informatica´ University of Glasgow, UK Faculdade de Cienciasˆ da [email protected] Universidade de Lisboa, Portugal [email protected] Abstract 1. Introduction We define a small class-based object-oriented language in which Standard class-based object-oriented languages present the pro- the availability of methods depends on an object’s abstract state: grammer with the following view: an object is declared to belong to objects’ interfaces are dynamic. Each class has a session type which a certain type, and the type defines various methods; it is therefore provides a global specification of the availability of methods in possible at any time to call any of the methods described in the type. each state. A key feature is that the abstract state of an object However, there are often semantic reasons why it is not appropriate may depend on the result of a method whose return type is an to call a particular method when the object is in a particular inter- enumeration. Static typing guarantees that methods are only called nal state. For example: with a stack, one should not attempt to pop when they are available.
  • Create Mixins with Interfaces and Extension Methods by Bill Wagner

    Create Mixins with Interfaces and Extension Methods by Bill Wagner

    Create Mixins with Interfaces and Extension Methods by Bill Wagner Mixins are small utility classes that define some useful functionality that will usually become part of something larger. For example, a class that implements a serial number to uniquely identify an object, or a timestamp that reports when an object was created. In C++, these mixin classes would be created using regular class definitions, and larger classes that wanted to use the mixin behavior would simply inherit from the mixin, in addition to any base classes it needed. Because the .NET Framework does not support multiple inheritance, we’ve typically used interface to define mixins. That works, but it’s not as powerful. One of the limitations of using interfaces to define mixin behavior is that every class that implements an interface must reimplement every method defined in that interface. That leads many developers to creating minimal interface definitions. (IEqualityComparer<T> has one method, IComparable<T> has only method). In those instances, the interface’s full functionality is completely defined in those small methods. But, what about cases where your interface can, or should, contain many more methods in order to support the developers that want to use the interface? That’s a perfect use case for extension methods. By creating extension methods using the interface, you can inject many more methods into the public definition of the interface, without forcing every developer to re-create those methods whenever he or she implements that interface. I’ve created a simple example based on strings that represent file paths. I often write classes that contain files or directories, usually for offline caches, or similar needs.
  • UML Why Develop a UML Model?

    UML Why Develop a UML Model?

    App Development & Modelling BSc in Applied Computing Produced Eamonn de Leastar ([email protected]) by Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie Introduction to UML Why develop a UML model? • Provide structure for problem solving • Experiment to explore multiple solutions • Furnish abstractions to manage complexity • Decrease development costs • Manage the risk of mistakes #3 The Challenge #4 The Vision #5 Why do we model graphically? " Graphics reveal data.! " Edward Tufte$ The Visual Display of Quantitative Information, 1983$ " 1 bitmap = 1 megaword.! " Anonymous visual modeler #6 Building Blocks of UML " The basic building blocks of UML are:! " model elements (classes, interfaces, components, use cases, etc.)! " relationships (associations, generalization, dependencies, etc.)! " diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)! " Simple building blocks are used to create large, complex structures! " eg elements, bonds and molecules in chemistry! " eg components, connectors and circuit boards in hardware #7 Example : Classifier View #8 Example: Instance View #9 UML Modeling Process " Use Case! " Structural! " Behavioural! " Architectural #10 Use Case Visual Paradigm Help #11 Structural Modeling Visual Paradigm Help #12 Behavioural Modeling Visual Paradigm Help #13 Architectural Modeling Visual Paradigm Help #14 Structural Modeling " Core concepts! " Diagram Types #15 Structural Modeling Core Elements " a view of an system that emphasizes
  • Variable-Arity Generic Interfaces

    Variable-Arity Generic Interfaces

    Variable-Arity Generic Interfaces T. Stephen Strickland, Richard Cobbe, and Matthias Felleisen College of Computer and Information Science Northeastern University Boston, MA 02115 [email protected] Abstract. Many programming languages provide variable-arity func- tions. Such functions consume a fixed number of required arguments plus an unspecified number of \rest arguments." The C++ standardiza- tion committee has recently lifted this flexibility from terms to types with the adoption of a proposal for variable-arity templates. In this paper we propose an extension of Java with variable-arity interfaces. We present some programming examples that can benefit from variable-arity generic interfaces in Java; a type-safe model of such a language; and a reduction to the core language. 1 Introduction In April of 2007 the C++ standardization committee adopted Gregor and J¨arvi's proposal [1] for variable-length type arguments in class templates, which pre- sented the idea and its implementation but did not include a formal model or soundness proof. As a result, the relevant constructs will appear in the upcom- ing C++09 draft. Demand for this feature is not limited to C++, however. David Hall submitted a request for variable-arity type parameters for classes to Sun in 2005 [2]. For an illustration of the idea, consider the remarks on first-class functions in Scala [3] from the language's homepage. There it says that \every function is a value. Scala provides a lightweight syntax for defining anonymous functions, it supports higher-order functions, it allows functions to be nested, and supports currying." To achieve this integration of objects and closures, Scala's standard library pre-defines ten interfaces (traits) for function types, which we show here in Java-like syntax: interface Function0<Result> { Result apply(); } interface Function1<Arg1,Result> { Result apply(Arg1 a1); } interface Function2<Arg1,Arg2,Result> { Result apply(Arg1 a1, Arg2 a2); } ..
  • Using the Bridge Design Pattern for Osgi Service Update

    Using the Bridge Design Pattern for Osgi Service Update

    Using the Bridge Design Pattern for OSGi Service Update Hans Werner Pohl Jens Gerlach {hans,jens}@first.fraunhofer.de Fraunhofer Institute for Computer Architecture and Software Technology (FIRST) Berlin Germany Abstract In the OSGi framework, components cooperate by sharing service objects. The suggested way to replace a service by a newer version consists of updat- ing its containing components which requires a temporary shutdown of the component. Special care must be taken to avoid dangling references to old service instances. As this appears to be an overly expensive strategy, we describe the use of the well-known Bridge design pattern to decouple service replacement from component updates. Instead of registering services only references to instances of automatically generated bridge classes are registered. This solves not only the problem of dangling references but also avoids stopping and starting de- pendent bundles. 1 Introduction The Open Service Gateway Initiative (OSGi)[1] is a consortium that has specified a JavaTM component framework[2] for delivering, activating, and replacing services over wide-area networks to local-area networks and devices. Since OSGi server im- plementations can be quite small, it is a good candidate when looking for supporting runtime evolution in embedded systems. OSGi components interact by sharing so-called service objects. Services are reg- istered by one component and referenced by others. A major problem of OSGi com- ponent exchange at runtime is the replacement of service objects. Shutting down all dependent components and restarting the replaced sub-system, as recommended by OSGi, seems overly expensive. In this paper, we describe the use of the well-known Bridge design pattern to decouple service replacement from bundle updates.