Refactor updater factory and add combined evaluation assertions

Author: PresiProdanov

ref-code-adaptation/REQUIREMENTS.md

@@ -50,39 +50,41 @@ Last updated: 15.06.2026
     be injectable through the `adapt` entry point so Spoon can be replaced by
     another updater implementation without changing the adapter orchestration.
   - Implemented: [ ]
-  - Addressed: [ ]
-  - Notes: Spoon remains the default implementation, but callers should be able
-    to provide an updater through an interface-based parameter.
+  - Addressed: [x]
+  - Notes: Spoon remains the default implementation. `CodeAdapter` now accepts a
+    `CodeUpdaterFactory` through its `adapt` entry points, and every isolated
+    mapping/incarnation run receives a fresh updater instance.
 
-- [ ] R-006: Document evaluation test cases
+- [x] R-006: Document evaluation test cases
   - Source/date: 15.06.2026
   - Details: Add `evaluation.md` documentation that explains the purpose,
-    inputs, mappings, expected behavior, and known limitations of the evaluation
-    test cases.
-  - Implemented: [ ]
-  - Addressed: [ ]
-  - Notes: The documentation should include testcase 1 and explain why it is
-    currently expected to report an error.
+    inputs, mappings, expected behavior of all testcases in the codeAdaptation resources, that are not in the subdirectories (13 test classes).
+  - Implemented: [x]
+  - Addressed: [x]
+  - Notes: `evaluation.md` documents the 13 numbered evaluation resource cases.
+    Testcase 1 is documented with the current post-R-007 behavior: it is
+    expected to run successfully, not report the former association-role
+    conflict.
 
-- [ ] R-007: Make evaluation testcase 1 functional
+- [x] R-007: Make evaluation testcase 1 functional
   - Source/date: 15.06.2026
   - Details: Testcase 1 should be converted from an error-only expectation into
     a functioning evaluation test case, or the underlying modeling/adaptation
     conflict should be resolved so the case can run successfully.
-  - Implemented: [ ]
-  - Addressed: [ ]
+  - Implemented: [x]
+  - Addressed: [x]
   - Notes: Current analysis target: testcase 1 reports an association-role field
     conflict because role-derived fields from the Observer/Observable mappings
     are ambiguous for the manual adaptation path.
 
-- [ ] R-008: Introduce a central CD lookup/index structure
+- [x] R-008: Introduce a central CD lookup/index structure
   - Source/date: 15.06.2026
   - Details: Add a central class or data structure, comparable to the
     preprocessing/index approach in cd4analysis, that traverses each class
     diagram AST once and stores frequently used type/member relationships in
     maps.
-  - Implemented: [ ]
-  - Addressed: [ ]
+  - Implemented: [x]
+  - Addressed: [x]
   - Notes: Adaptation code should look up CD types, attributes, methods, and
     associations from this index instead of repeatedly iterating the whole AST
     or resolving through utility methods such as `CDUtil`/`CDDiffUtil` at every

ref-code-adaptation/evaluation.md

@@ -0,0 +1,31 @@
+# Ref-Code-Adaptation Evaluation Cases
+
+This document describes the numbered evaluation resources under
+`src/test/resources/de/monticore/codeAdaption/evaluation`. Each case contains a
+reference CD, a concrete CD, and either adapter handwritten code, concrete
+handwritten code, or both.
+
+## Case Overview
+
+| Case | Purpose | Inputs | Mappings | Expected behavior | Test coverage |
+| --- | --- | --- | --- | --- | --- |
+| `testcase_1` | University/user-role case with two mappings over shared concrete types. | `Reference.cd`, `Concrete.cd`, `reference/` | `stud`, `prof` | Adapts both mappings successfully. The former association-role conflict is resolved by treating roles as generated fields owned by the opposite association side. | `CodeAdapterTestCase1` |
+| `testcase_2_cd4code` | CD4Code user-role case with generated follow-up code. | `Reference.cd`, `Concrete.cd`, `hwc/` | `stud` | Adapts the reference handwritten code to `Student`/`HiwiRole` and then runs Java generation for the concrete CD. | `CodeAdapterTestCase2a` |
+| `testcase_6_builder_pattern` | Builder pattern expansion for multiple concrete target types. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `buildPat` | Creates `PersonBuilder` and `TaskBuilder`, adapts setters/build methods, and keeps existing concrete classes. | `BuilderPatternAdapterTest` |
+| `testcase_7_controller_worker_observer` | Combined builder and observer adaptation where workers are observers. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `buildPat`, `observer` | Generates/adapts controller and worker builder/observer code while preserving concrete worker classes. | `ControllerWorkerAdapterTest` |
+| `testcase_8_controller_worker_observer_reversed` | Variant of controller/worker observer adaptation with reversed observer modelling. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `buildPat`, `observer` | Adapts the same pattern combination when the observer interface/class relation is represented differently. | `ControllerWorkerAdapterReversedTest` |
+| `testcase_9_strategy_pattern` | Strategy pattern adaptation. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `strategy` | Adapts context and strategy types/methods to payment processing classes and strategies. | `StrategyAdapterTest` |
+| `testcase_10_singleton_pattern` | Singleton pattern adaptation for multiple concrete singleton classes. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `singleton` | Produces singleton-style code for `DatabaseConnection` and `Logger` and preserves the application code. | `SingletonAdapterTest` |
+| `testcase_11_template_method_pattern` | Template method adaptation with several concrete processors. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `template` | Adapts the abstract template and concrete processor methods for CSV, JSON, and XML processors. | `TemplateMethodAdapterTest` |
+| `testcase_12_strategy_singleton_pattern` | Combined singleton and strategy adaptation. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `singleton`, `strategy` | Adapts configuration manager singleton behavior and storage strategy variants. | `StrategySingletonAdapterTest` |
+| `testcase_13_template_observer_pattern` | Combined template method and observer adaptation. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `template`, `observer` | Adapts data pipeline template methods and observer notification/update code. | `TemplateObserverAdapterTest` |
+| `testcase_14_adapter_factory_combined` | Combined adapter and factory pattern resource case. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `adapter`, `factory` | Adapts a shipping port/carrier adapter with factory creation. | `CombinedPatternEvaluationTest` |
+| `testcase_15_composite_decorator_combined` | Combined composite and decorator pattern resource case. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `composite`, `decorator` | Adapts renderable components, groups, and decorators. | `CombinedPatternEvaluationTest` |
+| `testcase_16_observer_command_combined` | Combined observer and command pattern resource case. | `Reference.cd`, `Concrete.cd`, `adapter/`, `concrete/` | `observer`, `command` | Adapts event bus observers that are also workflow commands and a command queue invoker. | `CombinedPatternEvaluationTest` |
+
+## Notes
+
+- Cases 6 through 13 are covered by pattern-focused JUnit tests in the main
+  `de.monticore.codeAdaption` test package.
+- Cases 14 through 16 are covered by executable wrappers in
+  `CombinedPatternEvaluationTest`.