EIG incremental change marks
Marks are used to denote status of software components during different stages of Incremental Change. JRipples uses next 5 marks, meaning of which varies depending on the current stage of Incremental Change process – Concept Location, Impact Analysis or Change Propagation.
Important note. The marks in the list are organized by their priorities: during an incremental change activity, a mark with a higher priority can replace a mark with a lower priority, but not vice a versa. The priorities are used in propagation rules.
Located or Impacted or Changed mark denotes that the software component contains a concept of interest during concept location, component is impacted during impact analysis and is changed during change propagation. It also means that this component may affect the components it interacts with as well.
Propagating mark denotes that the software component was inspected and found to be irrelevant for the current task. However, it also means that this component may transitively affect the components it interacts with.
Unchanged mark denotes that the software component was opened and found to be irrelevant for the current tasks, i.e. component does not contain a concept of interest during concept location, component is not impacted during impact analysis and is not changed during change propagation. It also denotes that the visited-marked component does not affect any of the components it interacts with.
Next mark denotes that the software component may be affected by the recent change in the status of one or more components it interacts with. For example, during impact analysis it means that some of the related components were marked as impacted and thus the current component should be inspected as it may be impacted as well.
Blank mark denotes unknown status of the software component. This typically means that component was never opened, inspected, modified etc.
Viewing and changing marks
Mark of a component can be viewed and changed in a number of ways. Please note that a change in a mark can trigger propagation rules; this, in turn, can automatically change the marks of the other components that the current component interacts with.
Viewing marks
The most convenient way is to use one JRipples views like a one shown below.
Marks can also be viewed and changed in any other Eclipse view that handles Java objects. For example, the picture below shows JRipples marks in the Package Explorer view.
JRipples marks in the Eclipse Outline view.
Changing marks
Mark of a component can be changed through a context menu of this component. The image below shows the context menu typically available in JRippes views.
The effects of mark changes are explained in details in propagation rules section.
Assigning a mark to a component, and trigger propagation rules at the granularity of this component.
Assign a mark and trigger propagation rules at a granularity of members or parents of the component.
Assigning a mark to a component and trigger propagation rules while limiting the set of the neighbors of the component to a single selected neighbor (edge).
Finally, a mark can be assigned to a group of software components, source code of which are selected in Eclipse editor. This will trigger propagation rules at the granularity of code fragments.
Please note that if node’s context menus show no marks as in picture on the left, or JRipples submenu is grayed out in Java elements’ context menus, then the node’s mark can not be currently changed as imposed by the propagation rules. For example, components with the Blank mark can not be assigned a mark as they have not being reached yet by the change process in the dependency graph. Also, grayed out JRipples submenu in the context menus of a Java elements in Eclipse views may indicate that the element is currently not in the dependency graph of JRipples. For example, as JRipples supports analysis of only one selected project, elements of all other projects in Eclipse workspace will not be in the dependency graph of JRipples.