Order matters when elements from extended aspect are mapped in other instantiation

Issue #63 resolved
Matthias Schoettle created an issue

Consider the following example:

  1. SlotMachine: Contains a class Reel with the operation setPosition(int pos)
  2. SlotMachineGUI: Contains the class ReelView
  3. SlotMachineGUI extends SlotMachine
  4. SlotMachineGUI depends on Observer with the following mapping:
    • |Subject to SlotMachine.Reel
    • |modify to SlotMachine.Reel.setPosition(...)
    • |Observer to ReelView
    • |update to ReelView.update(Reel reel)

Issue #58 resolved the issue that the mappings didn't get updated when you weave SlotMachine first.

However, if you weave Observer first, the following scenario occurs: The Weaver tries to weave |Subject into SlotMachine.Reel, i.e., the extended aspect gets modified, resulting in an exception, because notifications are delivered to that aspect.

The order in which the aspects are woven should not matter. Even though it makes sense that extended aspects are woven first, a modeller might want to see the result of instantiating another aspect and getting just that result.

Comments (3)

  1. Matthias Schoettle reporter
    • changed status to open

    The expected result should be:

    • the weaver creates a skeleton class (Reel in the example given)
    • the weaver also adds any mapped operation (setPosition(...) in the example)
    • the weaver updates the mappings to the copied elements
    • the weaver will then weave the lower-level class into the copy
  2. Matthias Schoettle reporter

    Resolved issue #63: When preprocessing, mapping of elements from another aspect is detected. In that case the class (skeleton) and operation(s) are copied to the current aspect and the mappings changed to ensure proper weaving.

    In the MessageViewWeaver when copying message views, this case is detected as well (however, only if the message view does not have a specification). If there is a message view defined in the other aspect, a MessageViewReference is created, which references the proper message view and then only "affected by" needs to be merged from the lower-level message view.

    → <<cset 2908b5835473>>

  3. Log in to comment