Please enable JavaScript.

Coggle requires JavaScript to display documents.

Summary (MDSE (Methodology (Concepts, Notations, Process and rules, Tools)…

- - - - Application level: Models of the application are defined, transformation rules are performed and actual running components are generated
      - Application domain level: Definitions of the modeling language, transformations and implementation platforms for a specific domain are defined
      - Metalevel: Conceptualization of models and of transformations are defined.
    - - Modeling level: Where models are defined.
      - Realization level: Solutions are implemented through artifcats that are actually in use within running systems
      - Automation level: Mappings form modeling to the realization levels are put in place.
  - - - Code generation
        
        Advantages
        
        Strategies to maximize benefit
      - Model interpretation
        
        Advantages and properties
    - - Model-driven Interoperability
        
        Decomposition
        
        Semantic
        
        Syntactic
        
        Bridging process
        
        Injection (t2m)
        
        Transformation (m2m)
        
        Extraction (m2t)
    - - Model discovery
      - Model understanding
      - Model (re)generation
  - - - System: The subject of the MDA, e.g. a program, a component, multiple components that make up a system etc.
      - Problem space/domain: The context/environment where the system operates
      - Solution space: Spectrum of possible solutions that satisfy the system requirements
      - Model: Any representation of the system and/or its environment
      - Architecture: Specification of the parts and connectors of the system, and the rules for interactions of the parts using the connectors
      - Platform: A set of subsystems and technologies that provide a coherent set of functionalities oriented towards the achievement of a specified goal.
      - Viewpoint: A description of a system that focuses on one or more particular concerns
      - View: A model of a system seen under a specific viewpoint
      - Transformation: The conversion of a model into another model
    - - CIM
      - PIM
      - PSM
    - - Intentional: mappings are defined at the metamodel level.
      - Extensional: mappings defined at the model level (they're defined on an extension, that is an instance of a metamodel).
        Edit
- - - - Out-place: transformations generate the output model from scratch
      - In-place: transformations rewrites the input model by creating, deleting and updating elements in it, until it has a output model. This perfectly fits for endogenous transformations.
    - - Exogenous, out-place
        
        ATL
        
        Anatomy
        
        Helpers: are auxiliary function that enables the possibility of factorizing ATL code used in different points of the transformation. Helpers do not generate target elements, but can only return values that can be used by the rules.
        
        ATL maps elements from source model to target model. It has a from keyword that defines the input model, and a create-keyword that defines the output model. Then you have:
        
        Rules that describe how parts of the target model should be generated from parts of the source model(s)
        
        Matched Rules: Automatically matched by the ATL engine
        
        Lazy Rules: Explicily called from another rule
        
        Phases
        
        1) Target elements initialization: The trace model for storing trace links between source and target elements is initialized. Each execution of a matched rule is stored in the trace model by creating a trace link pointing from the matched input element to the created output element. You'll see this in phase 2.
        
        2) Target elements allocation: Here it searches for matches, and allocates target elements when there are matches. Note that the elements are created, but their features aren't set in this phase.
        
        3) Target elements initialization: Each allocated target model element is initialized, their features are set.
      - Enogenous, in-place
        
        Graph-transformations: are an approach to enogenous in-place transformations. It's based on the fact that models and metamodels can be expressed as graphs, and therefore can be manipulated using graph transformation techniques. It is a declarative rule-based technique. It is often possible to use the abstract and concrete syntax of the modeling language to define the rules for the transformation.
        
        Graph grammar: consist of a set of graph transformation rules and an inital graph, that's often called the host graph to which the rules are applied. The rules are comprised of a left hand side (LHS) and a right hand side (RHS), where the LHS is the precondition for the rule, and the RHS has the post-condition for the rule. This means that a rule has the following effect:
        
        All eleemnts that only reside in the LHs are deleted
        
        All elements that only exist in the RHS are added
        
        All elements that reside in both sides are preserved.
        
        Negative Application Conditions must not be satisfied
        
        Advanced (NAP)
        
        Alternative notations: Instead of using the abstract syntax of the modeling language, you can use the concrete syntax for higher readability.
        
        Rule prioritization: For helping the transformation chose which rule to execute first, you can use rule priority, or you can use rule orchestration with a programming-like control-flow often called graph transformation units for defining loops, conditionals etc.The two approaches are summarized under the term programmable graph transformations.
        
        Analysis: Graph theory makes it possible to do graph analysis to reason about about the termination of a graph transformation system.
  - - - How to generate? That is, how are you to implement the generation of the parts you chose to the language you chose in the two previous steps.
      - What is generated? Langauge, paradigms, etc. You don't want the generated code to reinvent the wheel
      - How much is generated? The essential here is which parts can be generated
    - - 1) Load models
      - 2) Produce code
      - 3) Write code
    - - Separated static/dynamic code: Separates the static code and the dynamic code by having a template-based approach. They have the static code, and meta-markers for where the dynamic code (code based on model information) should be placed.
      - Explicit output structure: It supports templates for the output code. You create a template for a type of output file, and use meta-markers to define where the generated code should be placed.
      - Declarative query language: Within meta-markers there's code that accesses the information in the input models. OCL is often allowed for specifying meta-markers.
      - Reusable base functionality: It supports templates for the output code. You create a template for a type of output file, and use meta-markers to define where the generated code should be placed.
    - - Abstracting templates: It's important that developers can understand the generated code (see the Turing test for generated code in chapter 3), therefore you should base your templates on actual developer code.
      - Reusing templates: Current M2T transformation languages support polymorphism among the templates, so that you can write a general one and specialize it. The transformation maps each given element to the most appropriate template. You can also override features of a parent template. This should be utilized.
      - Step-by-step: There's still a big gap between the model and code level, so doing the model to code transformation to a chained transformation is probably a good idea. Divide-and-conquer!
      - Separating transformation logic from text: The most complex computations, e.g. queries on the input model or the computation of the output Strings, should be refactored into queries or libraries which the templates import. The templates thereby show more clearly the final structure.
      - Mastering code layout: The code layout is determined by the template layout, therefore it can be challenging to produce a nice final layout, as the template can have e.g. many conditionals and loops. You can solve this my using post-processing beautification (XPand does this). There are also special operators in most M2T languages for e.g. ignoring line breaks in templates, or for separating elements produced in loops.
      - Synch problems: In some cases it simply isn't possible to move manually written code when the generator has run again, despite having protected areas, e.g. if you rename a class that holds protected code, the protected code will be lost or still be in the old generated class file, as the generator will create a completely new file. (In the case of partial code-generation)
- - - - Focus
      - Style
      - Notation
      - Internality
      - Execution
  - - - 3 steps to create
        
        Domain analysis (purpose, realization, context)
        
        Language design (formalize identified design concepts)
        
        Language validation
    - - TCS (Xtext)
        
        Anatomy
        
        Model information: it has to support the the model information that's stored in the abstract syntax. You'll have to define names for model elements, and also type together with the name of each attribute.
        
        Keywords
        
        Scope borders
        
        Separation characters
        
        Links
        
        Approaches
        
        Generic TCS
        
        Langauge-specific
        
        Metamodel first: You create the metamodel, and base the TCS on that. You create a textproduction rule for each metamodel class.
        
        Grammar first: Start by developing a grammar defining the abstract and concrete syntax at once as a single specification. It is inspired by EBNF. The metamodel is automatically inferred from the grammar by dedicated metamodel derivation rules. This approach is originally followed by Xtext for developing TCS-based languages for EMF.
      - GCS (Sirius)
        
        Anatomy
        
        Graphical symbols
        
        Compositional rules: define how these graphical symbols are nested and combined
        
        Mapping the graphical symbols to the elements of the abstract syntax (which graphical symbol should be used for which modeling concept)
        
        Approaches
        
        Mapping-centric: .gmfgraph-model, .gmftool-model, .gmfmap-model --> A generator transforms the three models into a graphical modeling editor for the DSL you've created.
        
        Annotation-centric: Directly annotate the metamodel with information about how elements are visualized. It's used by e.g. EuGENia-framework, which allows you to annotate an Ecore-based metamodel with GCS information.
        
        API-centric: Allows you to create graphical modeling editors directly on the code level by providing a dedicated programming framework. This is the apporach of Graphiti.
    - - Denotional semantics (mapping)
      - Operational semantics (simulator)
      - Translational semantics (code-generator)
- - - - Typed
      - Declarative
      - Side-effect free
      - A specification language