A software system can be viewed as a set of components and their interoperations and can be formally modeled as dependency graph as described in [1], [2], and and [3]. In a nutshell, in this graph components are represented as nodes and interactions are represented as edges among the nodes. As the software evolves and changes, its components change too. Moreover, a change, introduced in a one component, may propagate through the interoperation dependencies to other components as well. To reflect the change process in the graph, we use marks.
If being simplified, a mark denotes a status of each component during the incremental change process. For example, a class may be inspected, changed etc - see an example in the figure above [3]. Moreover, marks denote the statuses of each component in respect to the statuses of other components this component interacts with. For example, if a component was changed, all the components it interacts with should be inspected for the possibility of a secondary change.
This property of respective meaning of the marks is enforced by propagation rules that describe how the status of every component should be updated to reflect a change in a status of another component it interacts with. Example of a basic change propagation rule was given above, where to reflect a change in a component all the neighbors of this component were updated as well. Propagation rules help to ensure that changes to a software system under analysis are done in a consistent and correct way.
The described graph, which contains components, their interoperations, marks and has a set of propagation rules defined, serve as a fundation of JRipples.