Organization of DSLE part. Overview of DSLE. Model driven software engineering. Engineering. Tooling. Topics:

Transcription

1 Organization of DSLE part Domain Specific Language Engineering Tooling Eclipse plus EMF Xtext, Xtend, Xpand, QVTo and ATL Prof.dr. Mark van den Brand GLT 2010/11 Topics: Meta-modeling Model transformations Domain specific language design and engineering Textual / Faculteit Wiskunde en Informatica PAGE 1 Overview of DSLE g in general DSL Design Model transformations Code generation Models are used everywhere / Faculteit Wiskunde en Informatica PAGE 2 / Faculteit Wiskunde en Informatica PAGE 3

2 Models are abstractions of real life objects Models increase the level of abstraction used for both hardware and software design often manually translated into design documents and code no guarantee for consistency between model, design and resulting code / Faculteit Wiskunde en Informatica PAGE 4 / Faculteit Wiskunde en Informatica PAGE 5 Whole range of modeling languages g are developed over the years: data oriented, e.g., E/R models, class diagrams behaviour oriented, e.g., use cases, state t machines, sequence diagrams, activity diagrams architecture oriented, e.g., package diagrams, component diagrams Standardization initiative of OMG: Unified Modeling Language UML is unified: Class diagrams Object diagrams Use cases State machine diagrams Sequence diagrams Activity diagrams Component diagrams etc. UML is too universal / Faculteit Wiskunde en Informatica PAGE 6 / Faculteit Wiskunde en Informatica PAGE 7

3 Criticism on UML: It contains many diagrams and constructs that are redundant or infrequently used. Problems in learning and adopting. Linguistic incoherence. Capabilities of UML and implementation language Dysfunctional interchange format. UML is too universal : a general purpose modeling language Domain specific extension via: Profile diagram operates at tthe meta model llevel lto show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype Meta modeling / Faculteit Wiskunde en Informatica PAGE 8 / Faculteit Wiskunde en Informatica PAGE 9 Meta-Object Facility (MOF) is a four-layered architecture: M3 Meta-Meta-Model Layer defines structure of the meta-metadata it provides a meta-meta model at the top layer M2 Meta-Model M Layer defines the structure of the metadata the M3-model is used to build meta models the most prominent example is the UML meta model, the model that describes the UML itself M1 Model Layer describes the data in the information layer the M2-models describe elements of the M1-layer For example, models written in UML M0 Model Layer describes objects or data in the information layer / Faculteit Wiskunde en Informatica PAGE 10 / Faculteit Wiskunde en Informatica PAGE 11

4 Meta-Object Facility (MOF) is the OMG standard no implementation EMF is the Eclipse implementation of MOF EMF Model Definition What is an EMF model? Specification of an application s data Object attributes Relationships (associations) between objects Operations available on each object Simple constraints (e.g., multiplicity) on objects and relationships Essentially the Class Diagram subset of UML / Faculteit Wiskunde en Informatica PAGE 12 / Faculteit Wiskunde en Informatica PAGE 13 What does EMF provide Meta-model A general model of models from which any model can be defined Models classes, attributes, relationships, data types, etc. Referred to as Ecore Ecore is just another EMF model EMF is used to implement EMF! Tooling support within the Eclipse framework Runtime environment Reflective and dynamic model invocation XML/XMI default model serialization EMF is middle ground in the modeling vs. programming world Focus is on class diagram subset of UML modeling (object model) Transforms models into efficient, correct, and easily customizable Java code Provides the infrastructure to use models effectively in your code Very low cost of entry Full scale graphical modeling tool not required EMF is free Small subset of UML / Faculteit Wiskunde en Informatica PAGE 14 / Faculteit Wiskunde en Informatica PAGE 15

5 EMF Components EMF Core Ecore meta model Model change notification Persistence and serialization Reflection API Runtime support for generated models Change model and recorder Validation framework EMF Edit Helps integrate models with a rich user interface Used to build editors and viewers for your model Includes default reflective model editor EMF Codegen Code generator for core and edit based components Model importers from Rose, XML, or Java interfaces Simplified Ecore meta-modelmodel EClass models classes themselves identified by name number of attributes number of reference EAttribute models attributes identified by name has a type EDataType represents simple types / Faculteit Wiskunde en Informatica PAGE 16 / Faculteit Wiskunde en Informatica PAGE 17 Simplified Ecore meta-model model EReference models associations between classes identified by name has a type which must be an EClass containment attribute indicating whether the EReference is used as whole- part relationship Classes, abstract classes and interfaces Attributes and Operations / Faculteit Wiskunde en Informatica PAGE 18 / Faculteit Wiskunde en Informatica PAGE 19

6 Creation of abstract class Associations in the meta-model: One way association Bidirectional association / Faculteit Wiskunde en Informatica PAGE 20 / Faculteit Wiskunde en Informatica PAGE 21 Associations in the meta-model: Containment association EMF is suited for modeling domain specific languages Inherit association / Faculteit Wiskunde en Informatica PAGE 22 / Faculteit Wiskunde en Informatica PAGE 23

7 What is a Domain Specific Language g (DSL)? A DSL is a formal, procesable language targeting at a specific aspect of a system Its semantics, flexibility and notation is designed in order to support working with that aspect as good as possible How do we design a Domain Specific Language? g Establish needed language concepts domain specific abstract t corresponding semantics Graphical vs textual tua representation ese Develop tooling / Faculteit Wiskunde en Informatica PAGE 24 / Faculteit Wiskunde en Informatica PAGE 25 Example of a Domain Specific Language g Specifying and Implementing the Controllers of Conveyor Belts We defined a domain specific language g (DSL) for modeling communicating systems Stepwise refinement to adapt the characteristics of the communication channels to the Lego Mindstorms platform State machine based combination of: graphical models and textual models conditional message exchange plus activities plus activities No data yet No timing yet / Faculteit Wiskunde en Informatica PAGE 26

8 Requirements for a DSL: Unambiguous syntax Unambiguous semantics Unambiguous transformability Strongly-typed and deterministic IO Encapsulation at Expressiveness Readability Overview of workshop g in general DSL Design Model transformations Code generation Definition of a (programming) g) language g involves: abstract syntax, so-called signature concrete syntax: textual syntax graphical syntax semantics: static semantics dynamic semantics / Faculteit Wiskunde en Informatica PAGE 30 / Faculteit Wiskunde en Informatica PAGE 31

9 Meta-Meta-Model Grammar world world The 4-layer architecture M3 Meta-Meta-Model (E)BNF/SDF grammar Layer defines structure of the meta-metadata (E)BNF in (E)BNF M2 Java Meta-Model grammar Layer defines the structure of Java the metadata in (E)BNF M1 Java Model program Layer describes the manipulation data in the information (algorithm) layer of objects in the object M0 layer Information Layer M0 data Object we wish layer to describe Objects we wish to manipulate Abstract syntax: defines basic structure of the language (skeleton) is starting point for defining: concrete syntax static semantics dynamic semantics / Faculteit Wiskunde en Informatica PAGE 32 / Faculteit Wiskunde en Informatica PAGE 33 Abstract syntax is a collection of constructors/- functions No information about keywords, priorities, iti associativities, etc. Abstract syntax definition of Booleans: true () -> BoolCon false () -> BoolCon con (BoolCon) -> Bool and (Bool, Bool) -> Bool or (Bool, Bool) -> Bool not (Bool) -> Bool constructor nonterminal Definition of a (programming) language involves: lexical syntax, so-called tokens: identifiers, numbers, strings, if, then, class (keywords) context-free syntax, so-called production rules: Statement ::= if Expression then Statements else Statements fi static semantics: identification and scope resolution type checking dynamic semantics: operational semantics interpretation compilation / Faculteit Wiskunde en Informatica PAGE 34 / Faculteit Wiskunde en Informatica PAGE 35

10 There is no standardized way of defining abstract syntax SSL (specification formalism of the Synthesizer Generator) Signature-like (Meta-modeling) SSL (grammar specification formalism of the Synthesizer Generator) describes it as follows: A collection of rules that define phyla and operators A phylum is a nonempty set of terms A term is the application of a k-ary operator to k terms of the appropriate phylum A k-ary operator is a constructor function mapping k terms to a term A phylum can be considered a nonterminal phyl 0 : op(phyl 1 phyl 2 phyl k ) / Faculteit Wiskunde en Informatica PAGE 36 / Faculteit Wiskunde en Informatica PAGE 37 SSL notation of the definition of the abstract syntax of Booleans: boolcon : True() False() bool : Con(boolcon) And(bool bool) Or(bool bool) Signature describes it as follows: A collection of functions that define sorts and operators A sort represents a nonempty set of terms A term is the application of a k-ary operator to k terms of the appropriate sort A k-ary operator is a constructor function mapping k terms to aterm A sort can be considered a nonterminal op(sort( 1, sort 2,, sort k ) sort 0 / Faculteit Wiskunde en Informatica PAGE 38 / Faculteit Wiskunde en Informatica PAGE 39

11 Signature notation of the definition of the abstract syntax of Booleans: true () -> BoolCon false () -> BoolCon con (BoolCon) -> Bool and (Bool, Bool) -> Bool or (Bool, Bool) -> Bool not (Bool) -> Bool Meta-modeling is the analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems. Relation between meta-models and grammars? Is every meta-model a context-free grammar? Is every context-free grammar a meta-model? / Faculteit Wiskunde en Informatica PAGE 40 / Faculteit Wiskunde en Informatica PAGE 41 Models and meta-models: Warmer et.al.: A model is a description of (part of) a system written in a welldefined language A meta-model is a model that defines the language for expressing a model A meta-model is the collection of concepts (things, terms, etc.) within a certain domain and an attempt at describing the world around us for a particular purpose. Meta-models are also referred to as a precise definition of the constructs and rules needed for creating semantic models. The meta-model of a language, also known as abstract syntax, is a description of all the concepts that can be used in that language. Syntax Grammar Program Meta-model MDE Model Schema DBMS Schema XML Document Data / Faculteit Wiskunde en Informatica PAGE 42 / Faculteit Wiskunde en Informatica PAGE 43

12 First alternative meta-model for Booleans: Every operator (not, or, and) is modeled as a separate class Constructors (true, false) are modeled as enumeration Second alternative at e meta-model for Booleans: Binary operator is modeled as a separate class Unary operator is modeled as a separate class Operators are modeled as enumerations Constructors (true, false) are modeled as enumeration First alternative for Boolean meta-model Signature: true () -> BoolCon false () -> BoolCon BoolCon -> Bool AndBool -> Bool OrBool -> Bool NotBool -> Bool and (Bool, Bool) -> AndBool or (Bool (Bool, Bool) -> OrBool not (Bool) -> NotBool / Faculteit Wiskunde en Informatica PAGE 44 / Faculteit Wiskunde en Informatica PAGE 45 First alternative for Boolean meta-model First alternative for Boolean meta-model / Faculteit Wiskunde en Informatica PAGE 46 / Faculteit Wiskunde en Informatica PAGE 47

13 Second alternative for Boolean meta-model Signature: true () -> BoolCon false () -> BoolCon BoolCon -> Bool BinaryBool -> Bool UnaryBool -> Bool bin (BinaryOp, Bool, Bool) -> BinaryBool una (UnaryOp, Bool, Bool) -> UnaryBool not () -> UnaryOp and () -> BinaryOp or () -> BinaryOp Second alternative for Boolean meta-model / Faculteit Wiskunde en Informatica PAGE 48 / Faculteit Wiskunde en Informatica PAGE 49 Second alternative for Boolean meta-model / Faculteit Wiskunde en Informatica PAGE 50