Research

Get Started. It's Free
or sign up with your email address
Rocket clouds
Research by Mind Map: Research

1. Exensible Architecture

2. MDE

2.1. Model transformation

2.1.1. Round-trip engineering (RTE)

2.1.2. "Lazy" partial model transformation

2.1.3. Bi-directional or one way?

2.1.4. SCALABILITY

2.2. Merging hand-written with generated code

2.2.1. "Generator is just another developer" = VCS

2.2.2. Traditional techniques

2.2.2.1. Separation

2.2.2.2. Marked sections

2.2.3. Problem with our case

2.2.3.1. Generated code varies based on pre-generation target code

2.3. Traceability links

2.3.1. Dedicated support for traceability

2.3.2. Using mechanisms for adding links

2.3.3. Developers manually encode links in transformation rules

2.3.4. Storing links in source or target model

2.3.4.1. GUID

2.3.4.2. Position in a document

3. Our case

3.1. Error detection

3.1.1. Generator model state + transformation = target code

3.1.1.1. Matrix [generator x model element]

3.1.1.2. Pattern-based partial transformation

3.2. Features

3.2.1. Generator groups

3.2.2. Include/exclude

3.2.3. Affect target files partially

3.3. Generation process phases

3.3.1. Choose feature

3.3.2. Detect related generators

3.3.3. Detect affected target files

3.3.4. For each model element and each related generator

3.3.4.1. Check if affected file is consistent to model element x generator

3.3.4.1.1. If not, error

3.3.4.1.2. if yes, adjust generator state (template choice, common variables etc) and generate task

3.3.4.2. Execute task <=> Generate code for [model element x generator]

3.3.4.3. Change affected files

3.3.4.4. Modify model element state

3.3.4.5. Modify generator state?

3.4. Impact analysis - How to detect affected part of target code = files

3.4.1. Mapping source model to files => configuration

3.4.2. Originally, impact analysis detects parts of SOURCE model

3.4.2.1. Da li i mi treba tako?

3.4.2.2. Da li se i naš pristup može podvesti pod to?

3.5. Developing partial transformation (or partial models?)

3.5.1. Videti sa Nndm

3.5.1.1. Izbegavanje nepotrebnog troška modelovanja čitavog sistema

3.5.1.2. Poboljšanje performansi ne možemo da izmerimo, ignorišemo

3.5.1.3. Možda pisati poseban rad kasnije, videti kog obima/detaljnosti/kvaliteta

3.5.2. Developing model for entire system

3.5.2.1. Expensive

3.5.2.2. Effort

3.5.2.3. Scalability problems with validation, transformation etc.

3.5.2.4. Major problem for legacy and/or large scale systems (termin "stumbling block")

3.5.2.5. Noticeable degradation in performance

3.5.2.6. "Scalability challanges prevent collaborative work", BergmannScalabilityPreventsCollaborativeWork2015

3.5.3. Partial transformations

3.5.3.1. Radovi

3.5.4. Model + Transformation = Target

3.5.4.1. Batch = entire model is transformed, new source

3.5.4.2. Incremental

3.5.4.2.1. Target incrementality

3.5.4.2.2. Source incrementality

3.5.4.2.3. User edit-preserving incrementality

3.5.5. Change history logs perserve operation (do not have to compute it)

3.5.5.1. We wanted to encourage end-user to experiment

3.5.5.2. All irrelevant changes are tracked

3.5.5.2.1. User creates element, deletes it, creates another with same name, changes something and deletes it...

3.5.6. Model differencing has to compute changes using two model versions

3.5.6.1. Memory intensive

3.5.6.2. Computationally more expensive than batch re-execution

3.5.6.3. If model is partially tracked, it is easier

3.5.6.4. Does not have to go through entire model, only releveant elements (determined by current feature)

3.6. Rule orchestration, coordination of rule invocation execution

4. Solution evaluation

4.1. "A comparison of mechanisms for integrating handwritten and generated code for object-oriented programming languages"

5. List of problems

5.1. Target incrementality vs user edit-preseving incrementality vs source incrementality vs ...

5.2. Traceability links

5.2.1. GUID

5.2.2. paths

5.3. Model validation before and after transformation

5.3.1. According to metamodel

5.3.2. Valid target model (code) => i.e. according to target syntax

5.4. Partial models/partial transformation

5.4.1. should we focus on that?

5.5. Software evolution

5.6. Rule orchestration - priority (weak)

6. Examine more closely

6.1. Does redundant computation occur?

6.1.1. Many tools perform redundant

6.2. Transformation related to software evolution

6.2.1. Generation process can be considered part of softer evolution

6.2.2. Client requirements change

6.2.3. Maintainance

6.2.4. Bug fixes

6.2.5. Testing process

6.3. Generators grouped into Features

6.3.1. Do we for every transformation iterate over all model elements?

6.3.2. Should we?

6.3.3. Is it possible to group model elements?

6.3.4. Example