vitruv-tools/vitruv

View-based Development and Model Consistency Framework

vitruv's Issues

Allow definition of local variables in response effects

Repair routines only allow to retrieve model elements or create new ones. Other kinds of variables have to be defined inside code blocks and are only available there.

We should add a local variable mechanism for the effects blocks of a routine, e.g.

def localVariable = { ... }

The variable can be passed to all following code blocks by using the inferred name of the code block and the defined name.

Correspondences to non-existent elements

Sometimes, correspondences that do not have a physical element references are necessary. One example is the mapping from UML to Java. The transformations assume one UML model corresponding to one Java model, whereas the Java model does not exist physically, but consists of several pacakges and compilation units.

Correctly, we have to fake such correspondences (e.g. by letting null correspond to that element). We should provide an explicit mechanisms for kind of "singleton" elements.

Hide Change2CommandTransforming logic from public interface

An application (transformations between two metamodels) has to define exactly one Change2CommandTransforming. However, essentially not the Change2CommandTransforming is what has to be defined by an application but only the metamodel pair and the sequence of ChangeProcessors contained by it.

The Change2CommandTransforming should be hidden in the implementation of the ChangeSynchronizer, just like the CommandExecuting.
Applications have to define a ChangeProcessor, which must also have a composite implementation, allowing to sequence ChangeProcessor like it currently performed by the Change2CommandTransforming.

Remove Change2CommandTransforming

After implementing the separation of command generation and change propagation logic according to #21, the transformation of changes into commands must not be performed by an extra class since it does only perform the wrapping of a ChangeProcessor (respectively ChangePropagationSpecification after #24) into commands.
The currently called CommandExecuting can simply get the ChangeProcessor, wrap it into a command, and execute it. We should also rename the CommandExecuting in that step

Perform add correspondence operation just-in-time

Due to an issue with the TUID update, the correspondence addition is performed after all other operations of a repair routine are executed, although #13 was implemented, introducing the execution of effect operations in the order in which they are defined.

Casacades of routine calls (e.g. the Java class + compilation unit creation in PCM-Java responses) causes issues if the correspondence addition is performed just-in-time. TUIDs are not updated correctly (e.g. the one of the Java class).

We have to investigate why the TUID update does not work, fix the issue and perform the correspondence addition just-in-time, making the ResponseElementStates and their handler obsolete.

Correct Java monitor change propagation data flow

The Java builder instantiates a Java MonitoredEditor which starts monitoring the AST for changes. Instead of informing the builder about the changes and let the builder execute the change propagation, the monitored editor does this. If the builder is removed, the monitor still propagates the changes.

We should move the responsibility for propagating the changes to the builder. The JavaBuilder has to be informed by the monitored editor about changes and propagate them accordigly.

Centralize distributed PCM and Java utilities

Currently, helper methods for querying and modifying PCM and Java models are spread across different helper classes in the PCM-Java transformations.

We should centralize them in the domain.*.util projects (or in secondary util projects if they have dependencies that are unwanted in the main util project).
I suggest implementing separate util classes at least for querying and modifying models in each domain (e.g. PcmModelQueryUtils and PcmModelManpulationUtils).

We could discuss if the util scheme used in the commons project, defining util classes for the different metaclasses that can be used as extensions on them, can be reasonably applied here as well. Potentially most methods cannot be directly assigned to a single metaclass and the remaining methods yield only few methods for a single metaclass. Having many utility classes defining only few methods and only for one metaclass may require high effort to import all classes required in one context and to search for a functionality in the utility classes. This will potentially result in reimplementations of functionality as it requires less effort than searching and importing it.

Combine test project and VSUM creation

In tests, test projects and VSUM projects have to be created separately. We should provide combined util operations.

Disable random option selection of TestUserInteractor

The TestUserInteractor currently selects a random option if no selection is explicitly specified by calling "addNextSelections" in advance. This is a misleading behavior as a test developer either knows that he wants a random selection and, thus, can determine such a random selection strategy or he does not know about the behavior of the TestUserInteractor and gets confused by its indeterministic behavior.

We should therefore

1. disable the random option selection in the TestUserInteractor.
2. add a method for specifying a random selection for the next user interaction.

We also have to counter-check and update all implemented tests that perform actions invoking user interactions, especially in the PCM-Java application.

Multiple response matcher check blocks

At the moment, only one check block at the end of a matcher is allowed.
It is reasonable to allow the definition of an arbitrary number of check blocks at any position within the matcher.
We should add this possibility to define multiple check blocks anywhere within the matcher.

Filter deleted objects in responses accessible elements

Currently, objects retrieved in a repair routine can be accessed in the following, even if they are marked to be deleted.

To avoid unexpected behavior due to already deleted elements, we should remove retrieved elements that are marked to be deleted from the accessible elements after the delete statement.

Generate commands by Change2CommandTransformer instead of ChangeProcessor

Currently, a ChangeProcessor has to return Commands that can be executed afterwards.

It makes no sense that the transformation developer (the one who defines ChangeProcessors) has to think about creating commands, but just wants to define change propagating routines that are executed correctly.

We have to move the logic for creating commands to the Change2CommandTransforming and let the ChangeProcessor simply define a method that executes a change propagation.

Record element modification by Reactions for TUID update

Reactions perform modifications on target models that are not reflected in any way. They are not used for transitively propagating them by triggering further Reactions and are also not investigated for TUID updates.

TUID updates for elements modified by Reactions are currently performed by the Reactions code that triggers the update procedure for certain elements at the correct points of time. This has the drawback that modifications on the Reactions language have to be performed correctly so that the TUID update is still performed correctly. This is error-prone and elaborate.
We should record changes in the models of the VSUM during change propagation through Reactions and perform just-in-time TUID updates just like during modifications by the user. This will potentially require us to perform resource changes just-in-time as the change recorder has to be started for newly created models.

Duplicate models in VirtualModel resource set

The method EcoreResourceBridge#loadResourceAtURI(), which is called by the VirtualModel for loading resources, creates a resource when it cannot be loaded by catching an exception during the creation attempt. Since the resource is not removed from the resource set after trying to load it, it is contained in the resource set twice afterwards.
Explicitly removing the not correctly loaded resource from the resource set results in problems when loading JaMoPP models.

We have to find a way to avoid these resource duplicates without breaking any existing applications.

JML-Java application update to framework modifications

The JML-Java application was not completely updated to be conform with the new change descriptions metamodel.

To have another working casestudy again, we have to complete that adaption and fix issues that may arise from that.

Primitive model types in Reactions

In reaction routines, only model elements, ints and strings can be passed as parameters. We should extend this to all primitive model types provided by Ecore (boolean, long, etc.). This is especially necessary, because boolean parameters are needed.

Move createAndSynchronizeModel into VitruviusEMFCasestudyTest

createAndSynchronizeModel is a generic test method. It is currently defined in the VitruviusChangePropagationTest although it could also be provided in the more generic VitruviusEMFCasestudyTest. We should move it.

Rename predefined test classes

Our predefined test classes have a weird naming: VitruviusCasestudyTest, VitruviusEMFCasestudyTest, VitruviusChangePropagationTest.

We do not use the term "casestudy" anymore. Furthermore, the VitruviusChangePropagationTest is no more specific to change propagation than the VitruviusEMFCasestudyTest. In fact, the VitruviusChangePropagationTest is a VitruviusSingleModelChangePropagationTest, as it provides essential logic that can be used if only one source model is involved. Nevertheless, it is questionable if this should be provided by a base class rather than a utility class.

We have to update the naming an responsibilities of those classes.

Simplification of change descriptions

By now, our change descriptions metamodel provides (compound) descriptions for changes that are pragmatic for our consistency preservation. One example are create and insert changes, which encapsulte the consecutive execution of a create and insert operation. Nevertheless, those changes are only necessary for consistency preservation, but, e.g., not for versioning models.

The change sequences provided by the monitor should only contain the information that is really necessary. Combining create and insert changes can also be performed afterwards. This combination of changes should be done by the tools that require it, in this case the consistency preservation. The monitor should only deliver essential changes.

Action item: Remove compound changes from the change descriptions metamodel and perform the tracing of those changes in the Reactions language.

Restrict referenced element type of reference change in responses

We can only filter changes by the type of the affected object and the modified feature at the moment. Sometimes, you need to decide if the response shall be executed based on the type of the replaced/inserted/removed referenced object. This has to be done in the check block, but the type check has no influence on the type in the call block.

We should add a statement for filtering the change by the dynamic referenced object type. If (in the future) changes are not passed as objects but by rolling out their parameters, the reference can be correctly typed as well.

Return Optional by optional reactions retrieval

Using a "retrieve optional..." statement in the Reactions currently results in having the element assigned to the specified variable if existing, or having null assigned to the variable otherwise.

Java 8 provides Optionals, a type that encapsulates an element if existing (== functional maybe). I think it would be nice to pass an Optional to the routine rather than null or a value, as this makes it clearer that there might be no element referenced by the variable.

Reponse language triggers in past tense

Currently, triggering changes in the response language are defined in present tense, e.g. "insert in list" or "replace value".

To emphasize that the change already happened, we should specify such triggers in past tense.

Remove implicit routines from response language

Each response defines an implicit routine from which other explicit routines can be called.
For developers, it is confusing and unclear which parts of a response belong to the routine and which are exclusive for the response. Furthermore, parameters in an explicit routine are (or at least can be) expressively named, while the parameter of an implicit routine is the change whose features have generic names with implicit semantics.

We should remove these implicit routines, replacing them with a call block (cf. #9) to make a response only define the trigger and which routines are called, whereas all routines are explicit and are responsible for the consistency repair of one specific consistency/semantic overlap.

Plain Java element references in routine parameters not working

Plain Java elements in the routine parameter list are not correctly handled by the code generator. All elements are mapped to parameters with the type ''void'' in the generated code.
This has to be fixed.

Add "before" changes trigger to responses

Responses are currently executed after a change occured. Sometimes, it is more convenient to execute some transformation logic right before the change was performed. This is especially useful for changes that remove elements because the containment can only be checked before performing the change.

Additionally to the "after" changes execution of responses, we should add a "before" changes execution. This requires the complete change transforming mechanism to be extended by the possibility to define if a transformation has to be executed before and after the change, so that the change synchronization mechanism can execute these transformations at the correct points-of-time.

Extend restrictions on element/feature combination in Reactions

In a Reaction, the combination of element type and feature is not checked for conformity. For example, you can specify to react to the insertion of a BasicComponent into a parameter reference, which can never occur.

We should add a conformity checker, which determines if the specified element is a subtype or supertype of the type of the specified feature. This should be implemented in the scoping mechanism to also have a correctly reduced feature set in the auto-completion.

Change name of routine call methods

Currently, a routine XY can be called via callXY(). This seems to be confusing for developers and ís especially unnessary.

We should make routines simply callable by their names and introduce the convention to use the default Java method naming style (camelCase) for routine names.

Support ressource with multiple roots in Reactions

Reactions (and the change propagation in general) do only support the creation of resource with one root element. Some metamodels (e.g. UML with stereotypes) require the support of models with more than one root element. We have to extend our model creation mechanism to support that.

Immediate Resource Creation in Persistence Process

If a new model shall be created and persisted, we currently write this intent to the ChangePropagationResult of a transformation. The model resource is not created until the transformation execution has finished, but afterwards when processing the ChangePropagationResult. This means that anything that has to do with the model resource during further transformations will not work, e.g., the application of stereotypes that are represented as root elements in the same resource (c.f. SysML).

We should modify the persistence process, so that the resource is created in the moment when the intent is made and only the persistence of the resource is delayed. Concretely, calling the persistProjectRelative method in a Reactions should immediate create a resource in the VSUM and only the persistence should be performed afterwards.

Make response routine effect optional

The effect block of a routine is currently mandatory as a routine without any effect does not make any sense.

After implementing the call block from #9, routine can also just call other routines, which makes their effects optional. Therefore, we should make effects optional.

Use IDs in change descriptions

EMFStore uses an ID mechanism, which manages objects by IDs. It uses a map from IDs to EObjects and simply stores the IDs in the changes. This makes it more simple to identify if, for example, a create and an insert change belong together, as only the ID must be checked.

We can exploit the proxy URI to store the ID while changes are not resolved and use the ID to resolve the object from the map. The mechanisms for mapping IDs to objects can be adapted from EMFStore.
As a consequence, changes belonging to the same object can be identified more easily, as only the ID must be checked, but not the objects themselves. Furthermore, correspondences can also rely on EObjects or their IDs rather than TUIDs.

Unify naming of change proagation classes

We have quite different names for the artifacts related to the change propagation process. To emphasize what they do, we should unify that naming.
The change propagation process could also be called transformation or synchronization, but we decided to adjust the naming to a change propagation terminology.
We have worked out the following names:

ChangeSynchronizer -> ChangePropagator
ChangeProcessor -> ChangePropagationSpecification
TransformationResult -> ChangePropagationResult

Anything missing?

Acronym capitalization

Currently, several acronyms are capitalized in Java/Xtend identifiers (especially class names) although this is discouraged. We have to convert these identifiers into correct camelCase writing.

Acronyms that I figured out are:

• PCM
• SEFF
• EJB
• POJO

Access to change reacting to any change

When reacting to any change in a reaction, the change has to be provided to the call block instead of specific arguments. Currently, no information about the change is available.

Reactions code generator cannot handle nsURIs of the form http://asinglewordwithoutdot

If a metamodel with a nsURI of the form http://asinglewordwithoutdot is used in a reaction, then the code generator tries to generate code in a package with a name that contains the complete nsURI and thus fails because of the ":"

ClassLoader in VirtualModel

The VirtualModel expects a ClassLoader instance.
This is currently never needed. We should remove that.

Accessibility in the response matcher check block

In the check block of a matcher, only the input elements of the repair routine are accessible. Correspondence model and user interacting cannot be referenced although they should be accesible inthe matcher.

Run MIR Generator by Run Configuration

The MIR Generator execution can be started using the context menu of a project at the moment.
A better integration into the Eclipse framework would be the provision of a run configuration.

This would allows to ...

• add configuration options to the transformation generator and
• run the generator during the Maven build

Change descriptions for cascading removals and opposite references

1. Currently, the deletion of a subtree within a model is only represented by a single change that represents the element removal. We have to extend that change so that it also represents the removal of the contained elements and references to these elements. This representation is necessary for rolling back the change. If applying the change to another model / model state, these consequential changes do not have to be executed, because that subtree might look different. Therefore, we have to explicitly represent the consequential changes as subchanges of the causing removal.

2. Currently, changing a reference which has an opposite produces weird and potentially unexpected change sequences (although they are correct).
   We should think about wrapping modifications of opposite references together. In general, the description should be similar to the one for a reference removal with the cascading cross reference removal (which we also represent as an unrelated sequence of changes).

Test

Language for defining domains

Domains have to be defined in a predefined, recurring structure, whose reproduction is expensive and error-prone.
We should provide an Xtext-based language for defining a domain with a generator that produces the necessary artifacts including:

• Domain class
• DomainProvider class
• plugin.xml with extension definition
• Reexports of the domain metamodels in the manifest

JML monitor independence from JML-Java application

The JML monitor has dependencies to the JML-Java application implementation.

We have to remove these dependencies to make the JML domain work completely independent from the Java domain.
Potentially the JML monitor has further issues due to the incomplete adaption to the new change descriptions metamodel. The adaption has to be completed and tested to make the monitor run as expected again.

Increase change editability

Changes currently have limited editability. It is only possible to add changes to a composite change but no changes can be removed or replaces. To achieve that, a new change has to be created from the old one. This is especially used in the ChangeProcessors, which return the modified change.

Instead of repeatedly creating new changes, they should be made editable (at least remove existing changes from a composite) and not returned in ChangeProcessors any more.

Monitoring delete changes

A delete operation is transformed into a single delete change by our monitor at the moment. As we want to be able to execute this operation in the reverse direction, we have to represent the complete state of the deleted element and the subtree of it as changes as well. This requires the containment tree to be disassembled, attribute and references be reset to default values as well as cross references to be removed.
The mechanisms can be adapted from EMFStore, which already has an implementation for deleting an object.

Integrate MIR Generator into Maven Build

The code generated by the MIR languages is currently commited to our repositories. Any changes of one of the MIR languages requries all applications to be recompiled and committed.
To avoid that, we should find a way of integrating the MIR generator into the Maven build.

We can try to reuse the Maven configuration in kit-sdq/BuildUtilities/jamopp-p2. There, we use a Maven plugin for executing an Eclipse application from command line, so we could reuse that for calling the MIR generator on a project.
This may be a nice hack until we solve #28 and provide a run configuration for the generator.

Raise abstraction of the VSUM

Currently, Vitruvius defines a VSUM that is only responsible for managing metamodels and models (domain and correspondence models). The consistency between the models is achieved by the external ChangeSynchronizer.

The conceptual idea is to have a VSUM that abstracts from a set of models and makes them look as if they were a single model, i.e. the internal models especially have to be synchronized within the VSUM.

We have to rename the current VSUM and implement a new one that abstracts from the consistency mechanism, such that changes can be performed to the models loaded in the VSUM and are synchronized automatically.

Allow collection retrieval in Reactions

Reactions do only allow the retrieval of a single element in the matcher.
Sometimes it is necessary to retrieve a collection of elements, as it is only know that an element corresponds to an arbitrary number of elements of a certain type. For example, in the families-persons scenario, a person in the persons modelcan be member of several families in the families model (e.g. one son and several fathers). Assuming that it is allowed to be father in several families, it is not possible to restrict the retrieval to a single member with the "with"-condition.

We have to possibilies to integrate such a retrieval into the reactions:

1. We allow to specify "retrieve collection of ..." statements that write the collection of elements to the specified variable, which can be processed within the routine.
2. We allow to specify a single "retrieve collection of..." statement per routine, which results in the execution of the routine for each of the elements in the collection.

Which behavior is more reasonable? The second one assumes that a consistency relation does only contain a static number of elements, thus of you retrieve a collection, each of the elements in the collection belongs to a single consistency relation, which you can restore in one routine execution. The first possibility is more flexible and should thus be only used if we think that it is possible to have one consistency relation which all these elements belong to, so that it is necessary to be able to reference all of them in one routine execution.

Call blocks in response language

Currently, explicit routines can be called anywhere in the execution block of any other routine.
This can be confusing because in correspondences added in the calling routine are not yet added to the correspondence model when executing the called routine although the add operation was defined above the execution block.

To make clear what assumptions can be made when calling another routine, we should add an explicit call block at the end of a response/routine in which other routines can be called and for which it is obvious that the rest of the response/routine was already completely executed.

Replace generic responses execute block with semantic update blocks

Currently, a routine in the response language defines an execution block within its effect to define anything that cannot be expressed with statements of the external response DSL.
During runtime, the execute block is executed at a specific point-of-time between the external statements to avoid failures. This is confusing to developers as they do not know which of the statements were already executed before the execute block and which were not.
Furthermore, the execute block is necessary to perform model modification to restore consistency, which are create, update and delete operations on model elements. Since create, retrieve and delete statements are already defined as external statements, only their initialization or update has to be defined in the execute block. Therefore, we can attach a code block to each create statements for the initialization of the element and defined update blocks for the retrieved elements to have to logic attached to the element they belong to.

An example for the difference in the routine definition looks as follows (relying on the modified syntax with curly braces and call blocks from #9, #11 and #12):

Old:

match: {
    retrieve element: retrievedElement ...
    retrieve element: toDeleteElement ...
}
effect: {
    create element: createdElement ... 
    add correspondence between createdElement and retrievedElement
    delete element: toDeleteElement
    execute: {
        createdElement.x =...
        bar.y = ...
    }
call: {
    createSomething(...);
}

New:

match: {
    retrieve element: retrievedElement ...
    retrieve element: toDeleteElement ...
}
effect: {
    create element: createdElement ... and initialize: {
        createdElement.x =...
    }
    add correspondence between createdElement and retrievedElement
    delete element: toDeleteElement
    update bar: {
        bar.y = ...
    }
call: {
    createSomething(...);
}

Although the old version is more concise, it is unclear when the correspondence is created (you could assume it is created before the execute block, but it is not) and the update logic for different models elements is mixed up in the execute block.

Surround response language blocks with curly braces

We currently go without curly braces known from GPPLs in the response language since the end of a block is clear in our syntax due to the language design, except for Xtend code blocks.
For developers, it seems to be natural to have blocks enclosed with curly braces, as the range of a block can be recognized more quickly.

We should add curly braces to surround all blocks in the response language, e.g. match, effect etc.