DOCSLIB.ORG

2.11. OCL in UML (Using Papyrus)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
2.11. OCL in UML (Using Papyrus) OCL Documentation OCL Documentation Christian Damus, Adolfo Sánchez-Barbudo Herrera, Axel Uhl, Edward Willink and contributors Copyright 2002 - 2014 Eclipse OCL 5.0 1 1. Overview and Getting Started ....................................................................................... 1 1.1. What is OCL? .................................................................................................... 1 1.2. How Does It Work? ............................................................................................ 1 1.2.1. Editing ................................................................................................... 1 1.2.2. Execution ................................................................................................ 1 1.2.3. Debugging .............................................................................................. 2 1.2.4. Testing ................................................................................................... 2 1.3. Eclipse OCL is Extensible .................................................................................... 2 1.4. Who Uses OCL and Eclipse OCL? ........................................................................ 2 1.5. Who is Behind Eclipse OCL? ............................................................................... 3 1.6. Getting Started ................................................................................................... 3 2. Users Guide ................................................................................................................ 5 2.1. The two Eclipse OCLs ......................................................................................... 5 2.1.1. The Classic Eclipse OCL metamodels .......................................................... 5 2.1.2. The Unified or Pivot Eclipse OCL metamodel ............................................... 5 2.1.3. The transition .......................................................................................... 6 2.1.4. APIs ...................................................................................................... 7 2.2. The Essential OCL Language ................................................................................ 7 2.2.1. Syntax .................................................................................................... 7 2.3. The OCLinEcore Language ................................................................................. 17 2.3.1. Syntax .................................................................................................. 17 2.3.2. Limitations ............................................................................................ 29 2.4. The Complete OCL Language ............................................................................. 29 2.4.1. Syntax .................................................................................................. 29 2.5. The OCL Standard Library Language ................................................................... 35 2.5.1. Syntax .................................................................................................. 35 2.6. Editors ............................................................................................................ 39 2.6.1. Syntax coloring ...................................................................................... 40 2.6.2. Validation ............................................................................................. 40 2.6.3. Hover Text ............................................................................................ 40 2.6.4. Content Assist ........................................................................................ 40 2.6.5. Code Templates ...................................................................................... 41 2.6.6. Open Declaration .................................................................................... 41 2.7. Console ........................................................................................................... 41 2.7.1. Context Object Selection .......................................................................... 41 2.7.2. Editing .................................................................................................. 42 2.7.3. Editor Keys ........................................................................................... 42 2.7.4. Results .................................................................................................. 42 2.7.5. Tool Bar ............................................................................................... 42 2.8. Validity View (new in Luna) ............................................................................... 43 2.8.1. View Tool Bar ....................................................................................... 43 2.8.2. Model Elements Pane .............................................................................. 44 2.8.3. Metamodel Constraints Pane ..................................................................... 46 2.8.4. Constraint Locators ................................................................................. 47 2.9. Debugger (new in Luna) ..................................................................................... 48 2.9.1. Launching ............................................................................................. 48 2.9.2. Stepping ................................................................................................ 50 2.9.3. Variables View ....................................................................................... 51 2.9.4. Breakpoints View ................................................................................... 51 2.9.5. Outline View ......................................................................................... 51 2.10. OCL Integration .............................................................................................. 51 2.10.1. OCL execution in Ecore / EMF Delegates .................................................. 51 2.10.2. Custom Validation Messages ................................................................... 51 2.10.3. CompleteOCL Validation ....................................................................... 52 2.10.4. OCLinEcore for Xtext Validation ............................................................. 53 2.10.5. Complete OCL for Xtext Validation ......................................................... 53 2.11. OCL in UML (using Papyrus) ........................................................................... 53 2.11.1. UML Integration ................................................................................... 53 Eclipse OCL 5.0 ii OCL Documentation 2.11.2. Class Diagram ...................................................................................... 54 2.11.3. State Machine Diagram .......................................................................... 58 2.12. User Interface ................................................................................................. 59 2.12.1. Project Property Pages ........................................................................... 59 2.12.2. Workspace Preference Pages ................................................................... 59 2.12.3. Overall Options .................................................................................... 60 2.12.4. Ecore and UML Options ........................................................................ 61 2.12.5. UML Options ....................................................................................... 62 2.12.6. Model Registry ..................................................................................... 62 2.12.7. Syntax Coloring .................................................................................... 62 2.12.8. Editor Templates ................................................................................... 62 2.12.9. OCLinEcore Options ............................................................................. 63 3. The OCL Standard Library ........................................................................................ 64 3.1. Precedences .................................................................................................... 64 3.2. Bag(T) ....................................................................................................... 64 3.3. Boolean ..................................................................................................... 65 3.4. Class ........................................................................................................ 66 3.5. Collection(T) ......................................................................................... 66 3.6. Enumeration ............................................................................................. 69 3.7. EnumerationLiteral ............................................................................... 69 3.8. Integer ..................................................................................................... 69 3.9. Metaclass(T) ........................................................................................... 70 3.10. OclAny ..................................................................................................... 70 3.11. OclComparable ....................................................................................... 71 3.12. OclElement ............................................................................................
Load more

Recommended publications
  • Xtext / Sirius - Integration the Main Use-Cases
    Xtext / Sirius - Integration The Main Use-Cases White Paper December 2017 SUMMARY Chapter 1 Introduction 1 Chapter 2 Let’s start 2 Chapter 2.1 What modeling is about? 2 Chapter 2.2 Benefits of graphical modeling 3 Chapter 2.3 Benefits of textual modeling 5 Chapter 3 What is Xtext? 6 Chapter 4 What is Sirius? 8 Chapter 5 Xtext & Sirius in action 10 Chapter 5.1 Case 1: Editing the same models both graphically and textually 10 Chapter 5.2 Case 2: Embedding an Xtext Editor into Sirius 15 Chapter 6 How may we help you? 18 Introduction Introduction You are going to create a domain-specific modeling tool and you wonder how users will edit and visualize the models: textually with a dedicated syntax and a rich textual editor ? or graphically with diagrams drawn with a palette and smart tools? Both approaches are interesting and can be used complementary: While text is able to carry more detailed information, a diagram highlights the relationship between elements much better. In the end, a good tool should combine both, and use each notation where it suits best. In this white paper, we will explain the benefits of each approach. Then we will present Eclipse Xtext and Eclipse Sirius, two open-source frameworks for the development of textual and graphical model editors. And finally, we will detailed two use-cases where these two technologies can be integrated in the same modeling workbench. 1 Let’s start Let’s start What modeling is about? Before presenting the graphical and textual modeling approaches, it is important to briefly clarify what we mean by modeling.
    [Show full text]
  • RCP Applications
    Helios Wayne Beaton The Eclipse Foundation Copyright © 2010 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 What is Eclipse? Copyright © 2010 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 Eclipse is a Java IDE .Language-aware editors, views, ¼ .Refactoring support .Integrated unit testing and debugging .Incremental compilation and build .Team development support Copyright © 2010 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 3 Eclipse is an IDE Framework .Eclipse + JDT = Java IDE . First class framework for Java, language aware editor, incremental build, integrated debugging, ... .Eclipse + CDT = C/C++ IDE . First class framework for C/C++, language aware editor, refactoring, search .Eclipse + PDT = PHP IDE .Eclipse + JDT + CDT + PDT = Java, C/C++, PHP IDE . Ruby, TCL, JavaScript, ... Copyright © 2010 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 4 Eclipse is a Tools Framework .Plug-ins make Eclipse whatever you need it to be .Platform of frameworks and exemplary tools .Tools extend the platform using bundles/plug-ins . Business Intelligence and Reporting Tools, Web Tools, Data Tools, Eclipse Modeling Framework, ... Copyright © 2010 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 5 Eclipse is a Application Framework .Remove the IDE elements; you're left with a general-purpose application framework . Linux, Windows, Mac OSX, UNIX, embedded . Rich widget set, graphics . Native-OS integration (drag and drop, OLE/XPCOM integration) .A platform for rich clients Copyright © 2010 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0 6 Eclipse is Runtimes! .Remove the UI elements and you©re left with a general-purpose component model .
    [Show full text]
  • EMF-REST: Generation of Restful Apis from Models
    EMF-REST: Generation of RESTful APIs from Models Hamza Ed-douibi, Javier Luis Cánovas Izquierdo, Abel Gómez, Massimo Tisi, Jordi Cabot AtlanMod team (Inria, Mines Nantes, LINA), Nantes, France {hamza.ed-douibi,javier.canovas,abel.gomez-llana, massimo.tisi,jordi.cabot}@inria.fr Abstract. In the last years, RESTful Web services have become more and more popular as a lightweight solution to connect remote systems in distributed and Cloud-based architectures. However, being an architectural style rather than a specification or standard, the proper design of RESTful Web services is not triv- ial since developers have to deal with a plethora of recommendations and best practices. Model-Driven Engineering (MDE) emphasizes the use of models and model trans- formations to raise the level of abstraction and semi-automate the development of software. In this paper we present an approach that leverages on MDE tech- niques to generate RESTful services. The approach, called EMF-REST, takes EMF data models as input and generates Web APIs following the REST princi- ples and relying on well-known libraries and standards, thus facilitating its com- prehension and maintainability. Additionally, EMF-REST integrates model and Web-specific features to provide model validation and security capabilities, re- spectively, to the generated API. For Web developers, our approach brings more agility to the Web development process by providing ready-to-run-and-test Web APIs out of data models. Also, our approach provides MDE practitioners the ba- sis to develop Cloud-based modeling solutions as well as enhanced collaborative support. 1 Introduction Web services have increasingly become popular mainly because they simplify clien- t/server decoupling and foster interoperability.
    [Show full text]
  • Code Smell Prediction Employing Machine Learning Meets Emerging Java Language Constructs"
    Appendix to the paper "Code smell prediction employing machine learning meets emerging Java language constructs" Hanna Grodzicka, Michał Kawa, Zofia Łakomiak, Arkadiusz Ziobrowski, Lech Madeyski (B) The Appendix includes two tables containing the dataset used in the paper "Code smell prediction employing machine learning meets emerging Java lan- guage constructs". The first table contains information about 792 projects selected for R package reproducer [Madeyski and Kitchenham(2019)]. Projects were the base dataset for cre- ating the dataset used in the study (Table I). The second table contains information about 281 projects filtered by Java version from build tool Maven (Table II) which were directly used in the paper. TABLE I: Base projects used to create the new dataset # Orgasation Project name GitHub link Commit hash Build tool Java version 1 adobe aem-core-wcm- www.github.com/adobe/ 1d1f1d70844c9e07cd694f028e87f85d926aba94 other or lack of unknown components aem-core-wcm-components 2 adobe S3Mock www.github.com/adobe/ 5aa299c2b6d0f0fd00f8d03fda560502270afb82 MAVEN 8 S3Mock 3 alexa alexa-skills- www.github.com/alexa/ bf1e9ccc50d1f3f8408f887f70197ee288fd4bd9 MAVEN 8 kit-sdk-for- alexa-skills-kit-sdk- java for-java 4 alibaba ARouter www.github.com/alibaba/ 93b328569bbdbf75e4aa87f0ecf48c69600591b2 GRADLE unknown ARouter 5 alibaba atlas www.github.com/alibaba/ e8c7b3f1ff14b2a1df64321c6992b796cae7d732 GRADLE unknown atlas 6 alibaba canal www.github.com/alibaba/ 08167c95c767fd3c9879584c0230820a8476a7a7 MAVEN 7 canal 7 alibaba cobar www.github.com/alibaba/
    [Show full text]
  • Becontent: a Model-Driven Platform for Designing and Maintaining Web Applications*
    beContent: a model-driven platform for designing and maintaining Web applications? Antonio Cicchetti1, Davide Di Ruscio2, Romina Eramo2, Francesco Maccarrone2, and Alfonso Pierantonio2 1 School of Innovation, Design and Engineering Malardalen¨ University, SE-721 23, Vaster¨ as,˚ Sweden [email protected] 2 Dipartimento di Informatica Universita` degli Studi dell’Aquila Via Vetoio, Coppito I-67010, L’Aquila, Italy fdiruscio|romina.eramo|francesco.maccarrone|[email protected] Abstract. Model Driven Engineering (MDE) is increasingly gaining acceptance in the development of Web Applications as a mean to leverage abstraction and render business logic resilient to technological changes. This paper describes the beContent project with its modeling languages and tools, which aims at the auto- mated generation of rich Web applications. 1 Introduction The beContent project [1] aims at defining an infrastructure (see Figure 1) consisting of a coordinated collection of languages and tools which permit to shorten systems’ life-cycle and ease maintainence tasks. The gluing element of the project is the be- Content metamodel (BMM) which is based on a previous work of the authors [2]. The metamodel defines the abstract syntax of the modeling languages: a diagrammatic and a textual concrete syntax, called beContent modeling language (BML) and beContent textual language (BTL), respectively, endowed with a round-tripping mechanism. In other words, they can interchangeably be used for specifying a system and, for instance, whenever a diagrammatic specification undergoes a modification the textual counterpart is consistently updated and the other way round. This has been possible by using the AMMA framework [3] and an additional component such as GMF [4].
    [Show full text]
  • Document Generation Tutorial
    Document generation tutorial Table of contents 1 Installation procedure .................................................................................................................. 4 2 Default generation from a Papyrus model ............................................................................... 4 3 Configure Document Generator in the Workbench ................................................................ 4 4 DOCX and ODT Document Generator...................................................................................... 8 4.1 Creation of a document generator .................................................................................................... 8 4.2 Configure the generation : <config> tag .......................................................................................... 8 4.2.1 Define generation output ............................................................................................................................... 8 4.2.2 Define global parameters for the template................................................................................................... 9 4.2.3 Pre-defined parameters .................................................................................................................................. 9 4.2.4 Use of variables inside parameters ............................................................................................................. 10 4.3 Define script execution context : <context> tag ............................................................................
    [Show full text]
  • An Extended Survey of Open Source Model-Based Engineering Tools
    An Extended Survey of Open Source Model-Based Engineering Tools Report prepared for Ericsson by: Kenn Hussey, Bran Selic, and Toby McClean Revision E (May 11, 2010) Zeligsoft 115, rue Principale, Suite 300 Gatineau, QC J9H 3M2 T (819) 684-9639 F (819) 684-5249 http://www.zeligsoft.com Zeligsoft Introduction This report presents the results of a study that was undertaken, by Zeligsoft on behalf of Ericsson, to investigate the current state of the art and trends in the domain of open source modeling tools and capabilities. The study had the following objectives: To describe the different open source projects, tools, and capabilities that are currently available, with special focus on the Eclipse environment; To identify the state of the different projects, tools, and capabilities To identify which organizations are involved in developing open source capabilities in this domain; and To identify which organizations are using open source capabilities in this domain. Open Source Modeling Survey (rev.1) 1 Zeligsoft Executive Summary During the analysis phase, it became apparent that there is significant fragmentation and duplication of effort in the domain of open source modeling tools, even within the narrow context of the Eclipse ecosystem where some of the technology is fairly mature. Consequently, it seems apparent that a major consolidation is needed to ensure a critical mass of contributors required for long-term survival and evolution of the various projects; as things currently stand, there is some concern as to the availability of long-term support for key capabilities. There is also a noticeable shift from vendor-driven to end-user-driven development in open source; this shift will require strong end-user participation to be viable in the long term.
    [Show full text]
  • An EMF-Like UML Generator for C++
    An EMF-like UML Generator for C++ Sven Jager,¨ Ralph Maschotta, Tino Jungebloud, Alexander Wichmann and Armin Zimmermann Systems and Software Engineering Group, Computer Science and Automation Department, Technische Universitat¨ Ilmenau, Ilmenau, Germany Keywords: Model based Software Development, Code Generation, Meta Modeling, C++, UML, MOF, Ecore. Abstract: Model-driven architecture is a well-known approach for the development of complex software systems. The most famous tool chain is provided by Eclipse with the tools of the Eclipse modeling project. Like Eclipse itself, these tools are based on Java. However, there are numerous legacy software packages written in C++, which often use only an implicit meta-model. A real C++ implementation of this meta-model would be necessary instead to be used at run time. This paper presents a generator for C++ to create the classes, meta-model packages, and factories to realize modeling, transformation, validation, and comparison of UML models. It gives an overview of its workflow and major challenges. Moreover, a comparison between Java and C++ implementations is given, considering different benchmarks. 1 INTRODUCTION et al., 2013). Such a C++ meta-model could be used, for instance, to configure dialog properties at runtime, to realize a runtime Object Constraint Lan- The Model Driven Architecture (MDA) approach as guage (OCL) (OMG, 2012) for the checking of model defined by the Object Management Group (OMG) elements, or to execute a behavior which is described is a well-known family of standards which unifies by activity diagrams. every step of the development of an application from Platform-Independent Model (PIM) through There are mainly two possibilities to create such Platform-Specific Models (PSM) to generated code meta-model representations.
    [Show full text]
  • Obeo Accelerates Growth, Increases Exposure As a Strategic Member of the Eclipse Foundation
    Obeo Accelerates Growth, Increases Exposure as a Strategic Member of the Eclipse Foundation Case Study 1 Eclipse Foundation Case Study Building a Stronger Open Source Strategy at the Eclipse Foundation pen source software has been key to Obeo’s product strategy since the company was created in 2005 in France. The original Obeo team was very small — three O company founders and an intern — and they believed an open source strategy was the best way to increase usage of Acceleo, the company’s software for model-driven development, and build brand awareness. The strategy was successful. Today, Obeo a clear view of the factors that helped Obeo build employs dozens of people, partners with major credibility and market awareness. industry players, and has a global customer base. “Our growth, especially our growth outside of The company is also a member of the Eclipse France, would not have been possible without the Foundation Board of Directors. reputation we built by participating in the Eclipse Cédric Brun is Obeo’s Foundation,” he says. “Our involvement in the CEO. He was also the Eclipse Foundation helped us to be recognized in company’s first intern. our technical niche in just a few years.” With his long history Obeo specializes in open source solutions to create and leadership role at and transform complex industrial systems, IT the company, Brun has applications, and corporate digital operations. The Cédric Brun, CEO, Obeo COPYRIGHT (C) 2020, ECLIPSE FOUNDATION, INC. | THIS WORK IS LICENSED UNDER A CREATIVE COMMONS ATTRIBUTION 4.0 INTERNATIONAL LICENSE (CC BY 4.0) 2 Eclipse Foundation Case Study Acceleo software has always been open source, but it was not originally hosted at the Eclipse “Open source has been an Foundation.
    [Show full text]
  • Model Driven Engineering : Basic Concepts
    Model Driven Engineering : Basic Concepts Lesson 3 Model to Text Transformations : ACCELEO Guglielmo De Angelis CNR - IASI / ISTI [email protected] model transformation MMM model transformation MMM M2M model transformation MMM M2M M2T what is ACCELEO ● it is a framework supporting automatic model transformations – programming language – execution framework – originally developed by Obeo, now in the Eclipse Modeling Framework ● ACCELEO has been designed following MDE principles – enabling the automatic generation of text form a given metamodel (e.g. UML, MOF, EMF) ● available documentation : – Acceleo 3 Web Site ● http://www.eclipse.org/acceleo/ – The Official Documentation ● http://www.eclipse.org/acceleo/documentation/ – The Offical Acceleo Wiki ● http://wiki.eclipse.org/Acceleo about ACCELEO ● ACCELEO is a framework supporting the implementation, and the execution of MODEL 2 TEXT transformations about ACCELEO ● Acceleo is a framework supporting the implementation, and the execution of MODEL 2 TEXT transformations Acceleo Transformator (i.e. the program) Acceleo Execution Engine about templates – 1 ● a template can be seen as a document which it is partially specified – common structure for all the instances of the document – “empty fields” containing istance-specific information ● examples of documents are : – textual documents – models – source codes about templates – 2 Common Structure about templates –3 Generated Parts definition ● the type of the elements which can be elaborated in each “empty field” of a template
    [Show full text]
  • An EMF-Based Toolkit for Creation of Domain-Specific Data Services
    An EMF-based Toolkit for Creation of Domain-specific Data Services Andreas Bender, Stefan Bozic and Ivan Kondov Steinbuch Centre for Computing (SCC), Karlsruhe Institute of Technology (KIT), Hermann-von-Helmholtz-Platz 1, 76344 Eggenstein-Leopoldshafen, Karlsruher, Germany Keywords: Metamodel, Eclipse Modeling Framework, Dataflow, Data Model, Workflow, Application Integration, Web Service. Abstract: Development of composite workflow applications in science and engineering is troublesome and costly due to high heterogeneity of data representations and data access interfaces of the underlying individual components. As an effective solution we present a generic toolkit enabling domain experts to develop data models and automatically generate a self-contained data access service. We defined a custom metamodel based on Ecore which can be readily used to create domain-specific data models. Using the generated data access service, instances of the modeled data residing on heterogeneous and distributed resources, such as databases and cloud data stores, are accessible from the individual application components via a language-independent Web service interface. We discuss the framework architecture, the toolkit implementation, the deployment process, as well as the performance of the data access service. Workflow designers as target users would benefit from the toolkit by using it for rapid and cost-efficient application integration. 1 INTRODUCTION (MDE) (Schmidt, 2006) have been adopted to develop systems at such a level of technical abstraction that The complexity of applications for simulation and application domain experts can develop composite data analysis in science and engineering has increased applications by integrating existing components fol- dramatically over the recent years. Such applications, lowing their design rather than spending efforts with often designed in the form of generic workflows, the technicalities of the underlying computing envi- combine multiple software components originating ronment.
    [Show full text]
  • MODEL-TO-TEXT TRANSFORMATIONS Teaching Material for the Book Model-Driven Software Engineering in Practice by Marco Brambilla, Jordi Cabot, Manuel Wimmer
    CHAPTER 9 MODEL-TO-TEXT TRANSFORMATIONS Teaching material for the book Model-Driven Software Engineering in Practice by Marco Brambilla, Jordi Cabot, Manuel Wimmer. Morgan & Claypool, USA, 2012. Copyright © 2012 Brambilla, Cabot, Wimmer. www.mdse-book.comMarco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Content . Introduction . Programming Languages based Code Generation . M2T Transformation based Code Generation . Mastering Code Generation Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. INTRODUCTION www.mdse-book.comMarco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Introduction Terminology . Code generation . Wikipedia: „Code generation is the process by which a compiler‘s code generator converts a syntactically-correct program into a series of instructions that can be executed by a machine.“ . Code Generation in Action (Herrington 2003): „Code generation is the technique of using or writing programs that write source code.“ . Code generation (http://en.wikipedia.org) . Compiler Engineering: component of the synthesis phase . Software Engineering: program to generate source code . Résumé: Term Code Generation is overloaded! Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice. Morgan & Claypool 2012. Introduction Code Generation - Basic Questions . How much is generated? . Which parts can be automatically generated from models? . Full or partial code generation? . What is generated? . Which kind of source code to generate? . The less code to generate, the better! . How to generate? . Which languages and tools to use for developing code generators? . GPLs vs. DSLs Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering In Practice.
    [Show full text]