Adding Autogenerated Methods at the Model Level

ZainabAlShowely edited this page Jul 17, 2018 · 8 revisions
Clone this wiki locally

This is documentation about the current setup for adding autogenerated API methods at the model level: issue962.

First, the goal is to add the method signatures of all the methods Umple autogenerates at the model level. Previously, all this logic was contained in the generators, and the model did not have any knowledge of the existence of these methods. This made runtime analysis very difficult.

Autogenerated methods at the model level are the same as any other method except (currently) they do not have a method body and their source is set to fAutoAPI. In the code generation phase, these fAutoAPI methods are not emitted like methods provided by the user (i.e. all the logic to generate the body of these methods is generated by the code generators). In the future, it will make sense to transfer over the method body logic to the model, but this will be an immense amount of work. Best to do small steps to achieve this goal.

What needs to be done moving forward: Autogenerated methods for associations need to be fully added at the model level. Methods that have not yet been added are tested for in implementation tests, and can be found in the JUnit test results after uncommenting a call to autogeneratedMethodsCheck in The idea is to have similar logic in UmpleInternalParser as in the getAssociationCode method of the JavaClassGenerator.

Previously, testing was done in the following manner:

  • To test autogenerated associations, the UmpleModel must be set to debugMode and the JavaGenerator used
  • I created a test file: cruise.umple/test/cruise/umple/implementation/ . This is a compiled version of all the generators' association method tests
  • How the tests work: you can see the commit here. Any time a new method is created in the generator, if the model is set to debugMode, an Umple Method is constructed for the method. Then, I check if the class currently being generated has that method. If it doesn't, it means that the autogenerated method was incorrectly not added at the model level and a flag in the model (setDebugAutogenFailed) is set to true -> this will make the test fail. The missing method(s) will be printed out. If the class does contain the method, we get the method and set a flag (setDebugFlag) to true, indicating that this autogenerated method that was added at the model level was actually generated. So, at the end of each test, we iterate through all the classes' fAutoAPI methods (autogenerated methods) and if at least one has setDebugFlag=false, the test fails and the extra methods that existed in the model and were not generated are printed out.

The above is being replaced by the following testing method:

  • All tests that are being run to test features such as attributes and associations, and verify that certain code is output, are being instrumented to also assert that the expected API as specified in UmpleInternalParser matches the API as generated. This will be done by editing method createUmpleSystem() to always verify the match. Then every implementation test will automatically do this check. However, because initially almost all implementation tests would fail, this will be done in such a way such that it can be switched off in production or a pattern can be applied to avoid failing all the tests.