1. Traceability links
1.1. Dedicated support for traceability
1.2. Using mechanisms for adding links
1.3. Developers manually encode links in transformation rules
1.4. Storing links in source or target model
1.4.1. GUID
1.4.2. Position in a document
2. Related work
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. Model + Transformation = Target
2.1.4.1. Batch = entire model is transformed, new source
2.1.4.2. Incremental
2.1.4.2.1. Target incrementality
2.1.4.2.2. Source incrementality
2.1.4.2.3. User edit-preserving incrementality
2.2. Model syncronization
2.2.1. Merging hand-written with generated code
2.2.1.1. "Generator is just another developer" = VCS
2.2.1.2. Traditional techniques
2.2.1.2.1. Separation
2.2.1.2.2. Marked sections
2.2.1.3. Problem with our case
2.2.1.3.1. Generated code varies based on pre-generation target code
2.2.2. Traces
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. Generation process phases
3.2.1. Choose feature
3.2.2. Detect related generators
3.2.3. Detect affected target files
3.2.4. For each model element and each related generator
3.2.4.1. Check if affected file is consistent to model element x generator
3.2.4.1.1. If not, error
3.2.4.1.2. if yes, adjust generator state (template choice, common variables etc) and generate task
3.2.4.2. Execute task <=> Generate code for [model element x generator]
3.2.4.3. Change affected files
3.2.4.4. Modify model element state
3.2.4.5. Modify generator state?
3.3. Impact analysis - How to detect affected part of target code = files
3.3.1. Tracing
3.4. Incremental (partial) transformation
3.4.1. Radovi
3.4.2. Change history logs perserve operation (do not have to compute it)
3.4.2.1. We wanted to encourage end-user to experiment
3.4.2.2. All irrelevant changes are tracked
3.4.2.2.1. User creates element, deletes it, creates another with same name, changes something and deletes it...
3.4.3. Model differencing has to compute changes using two model versions
3.4.3.1. Memory intensive
3.4.3.2. Computationally more expensive than batch re-execution
3.4.3.3. If model is partially tracked, it is easier
3.4.3.4. Does not have to go through entire model, only releveant elements (determined by current feature)
3.5. Rule orchestration, coordination of rule invocation execution
3.5.1. Verovatno ne pominjemo u ovom radu, pominjemo u doktoratu
3.6. Partial model definition - posebna tema
3.6.1. Izbegavanje nepotrebnog troška modelovanja čitavog sistema
3.6.2. Poboljšanje performansi ne možemo da izmerimo, ignorišemo
3.6.3. Developing model for entire system
3.6.3.1. Expensive
3.6.3.2. Effort
3.6.3.3. Scalability problems with validation, transformation etc.
3.6.3.4. Major problem for legacy and/or large scale systems (termin "stumbling block")
3.6.3.5. Noticeable degradation in performance
3.6.3.6. "Scalability challanges prevent collaborative work", BergmannScalabilityPreventsCollaborativeWork2015
3.6.4. Možda pisati poseban rad kasnije, videti kog obima/detaljnosti/kvaliteta
3.7. SEAMLESS generated and hand-written code integration
3.7.1. Does not affect architecture
3.7.2. Improves stakeholders acceptance
3.7.2.1. Does not change work-flow dramatically (generator as another developer)
3.7.2.2. Does not require creating model for entire source
3.7.2.3. Dry-run (preview) reduces anxiety
3.7.3. Easier to read
3.7.4. Prerequsites:
3.7.4.1. Incremental transformation - target code must not be re-gerated
3.7.4.2. Tracing - detectiing where to propagete changes
3.7.4.3. Incremental model transformation - detecting performed operations
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
7. Implementation
7.1. Architecture
7.2. Improve diagram
7.3. See diagram from icist paper
7.4. See Tijana's diagrams
7.5. Osmisliti tok predstavljanja po modulima
8. Introduction
8.1. Contributions
8.1.1. HW code is seamlessly integrated (kod Bernaschine je to main contribution)
8.1.2. Novel approach to incremental treansformations
8.1.3. Conflict resolution technique
8.1.4. Propratni doprinosi, verovatno ne za rad
8.1.4.1. Practical aplicability - comparison
8.1.4.1.1. Compare with classical MDE approach
8.1.4.1.2. Anketa neka možda
8.1.4.2. MDE integration guidelines to traditional code-centric development process
8.1.4.2.1. Partial models
8.1.4.2.2. Generated code looks like written
8.1.4.2.3. Generated code follows all company style guidelines and standards
8.2. For traditional MDD integration
8.2.1. MDD integration into mature systems
8.2.1.1. It is risky to re-generate entire functioning modules
8.2.2. Stakeholders
8.2.2.1. Conservative, do not like to change processes
8.2.2.2. For traditional MDD integration
8.2.2.2.1. Architecture has to be changed
8.2.2.2.2. Readability is affected
8.2.2.2.3. Doubt possible benefits (we have some problems now, with MDD we well have new set of problems)
8.2.2.2.4. Requires entire source model
8.2.3. Gocina prezentacija
8.2.4. Rad što je Nnd slao
8.2.5. Možda videti i kod Italijana
8.3. Our main goal
8.3.1. Improve MDD adoptation in the industry
8.3.1.1. Reduce user anxiety by allowing them to experiment before propagating change to files
8.3.1.2. Seamless
8.3.1.2.1. Does not require architecture to change
8.3.1.2.2. Redable code
8.3.1.2.3. According to best practices, company standards
8.3.1.2.4. Reduces mental load since user does not have to change their workflow (no protected blocks, partial classes..). Developers percieve generator as another developer.
8.3.1.3. Partial models
8.3.1.4. Incremental transformation