Design Decisions

Heiko Klare edited this page Apr 12, 2017 · 5 revisions

Table of Contents

The Reactions Language

The reactions language was formerly called response language. Some of the documentation still following this naming scheme.

Conceptual Decisions

Reactions

  • Reactions can specify a single element type of whose creation/deletion/insertion/removal to react to
    • Sometime it may seem reasonable to specifiy multiple elements, because one wants to react to any of them but they do not have a common superclass to specify
    • We decided not to allow to define multiple elements because we then have to determine a common supertype which, on the one hand, may just be EObject, which is not very helpful, or, on the other hand, may be ambiguous as both classes implement the same, different metaclasses, so we may pick an arbitrary common supertype, which could be confusing for the user.

Separation of responses and repair routines

  • The original response language allowed the definition of responses and repair routines with the following characteristics:
    • Repair routines define reusable routines for restoring a specific consistency/semantic overlap after a certain kind of modification of its elements
    • Responses define in reaction to which events (changes) a repair routine is called (i.e. when a semantic overlap may get inconsistent due to a change)
    • Responses define an implicit repair routine that can call other reusable repair routine
  • We changed the design as follows:
    • Responses still define in reaction to which events a repair routine is called
    • Responses do not define an implicit repair routine any more but simply delegate to explicit repair routines.
  • Benefits:
    • Reusability
      • Every repair routine is reusable and not potentially hidden as an implicit routine of a response
      • Also reduces the effort for extracting routines later
    • Clear responsibilities
      • Responses and repair routines have completely distinct responsibilites
      • No need to think about which part of a responses belongs to the response and what belongs to its implicit repair routine
    • Expressive naming of accessible model elements
      • In responses, model elements within the change are accessed by its properties like change.newValue without knowing what newValue is
      • Repair routines have named arguments, so that the model elements that are used in during repair have expressive names
  • Drawbacks:
    • Verboseness
      • It requires more effort to explicitly define the routine with its inputs and delegate to it from the response (if the repair routine is not reused)
      • More first-level elements blow up responses documents because several routines were hidden in responses before

Concrete Syntax Change Log

To increase the understandability of reactions and their conformance with mainstream programming languages, we performed a major refactoring of the syntax in 10/2016 as described in the following.

Renamed Keywords

  • response renamed to reaction
  • effect renamed to action
  • add "for" after "value replaced"
  • add "in" after "inserted" or "removed"
  • renamed "root created" to "root inserted" and "root deleted" to "root removed"
  • renamed "initialized as" to "and initialize" (to avoid usage of Xbase's typecast keyword "as")

Minor Changes

  • create action: name of created element first then equals sign (to avoid usage of Xbase's typecast keyword "as")
  • for retrieve statement (required or optional): start with val and name of retrieved element, then equals sign, then retrieve
  • reaction name optional
  • new header: reactions ReactionsName in reaction to changes in SourceMM execute actions in TargetMM

Major Changes

  • new change type "element", qualified meta class name , ("created"|"deleted") and optionally allow to specify "created and" or "deleted and" for list entry and for root changes
    • temporary solution: write explicit "create and insert" respectively "delete and remove" and keep to the current way in which the monitor only produces these cases
    • later: add new possibility to have insert without create and remove without delete later
  • optional last statement in a routine: return, variable declaration and assignment possible when routine is called, we have to generate not only correct return type for the method but also final variable declarations and assignments when they are called
  • have a new "execute action block" and only allow calls in "call action block"
  • address metaclasses via Metamodel::Metaclass instead of Metamodel.Metaclass
  • make simple name addressing of metaclasses default, replace keyword using simple names with using qualified names enabling addressing of metaclasses via qualified names, which may be neccessary due to naming conflicts.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.