-
Notifications
You must be signed in to change notification settings - Fork 1
JDT event realm
The Java to UML transformation is an incremental transformation maintaining an UML model based on the structural changes of the Java code. The incrementality is achieved by reacting to notifications about changes of the code provided by the JDT Core.
See the current implementation of the JDT-EVM integration here
##Using the JDT core The JDT Core provides the infrastructure of the Eclipse Java IDE. It includes an incremental compiler, models of the code, an API for traversing and modifying Java code, code assist, index based search and a source code formatter. The transformation uses the provided models and the corresponding notification API to track the changes of the code.
###Models provided by the JDT The JDT maintains a high level and a low level model of the java code. The high level lightweight model called Java Model (Java DOM, JDOM) describes the structure of the Java project. It contains elements like packages, java files, types, methods, fields, etc. The low level model called the Document Model contains an AST (Abstract Syntax Tree), a precise and fully resolved compiler parse tree. Sub-method level Java code can be managed through the AST.
As the UML model represents the high level structure of the code, the transformation uses the lightweight Java Model.
###Notifications provided by the JDT The JDT provides notifications of the changes of the code. A notification is sent after any modification of the source if there is no other change for a small time (~1 second). The notification contains an IJavaElementDelta object describing the change.
The delta contains references to the affected JavaElements, a change type (ADDED, REMOVED, CHANGED) and change flags describing the change in more details. For the list of change flags see the corresponding eclipse help page.
##Proposed use of EVM To use the EVM with the JDT notifications a custom event provider has to be implemented (see example). To implement an event provider the event atom, the event types, the activation states and the activation lifecycle have to be defined.
The event atom should contain a changed java element, and additional information if needed. If a change affects more than one java element, then multiple events should be generated for a single change notification.
The event types should basically match the change types of the java element in the event atom. The usual APPEARED, DISAPPEARED, MODIFIED values should be used.
The activation types should also use the usual values of INACTIVE, APPEARED, DISAPPEARED, MODIFIED and FIRED.
Filters should be implemented and used to define more specific rules. There can be filters for the types of the Java elements, their attributes or child elements.