Predicate URIs in Impact Analysis

Impact analysis is all about accessing the 'impact' of change on a set of resources. Typically it will begin with one or more resources that have or will change. Change in this sense means some or all of their properties will be different. Properties for our discussion can be grouped into two categories; literals and references. Literals being things like strings, booleans, datetimes and even enumerations that are represented with URI or URNs. References are URIs that point to other resources. Those other resources are resolvable, and are most likely OSLC typed resources (i.e. OSLC AM Resource, OSLC RM Requirement).

We had a long discussion on the direction of impact in the definition of a predicate uri. We discussed Steve Speicher's comments on the last meeting's minutes. Specifically his explanation of why some of the property definitions were worded in a way that made the object impacted by a change in the subject, and others that made the subject impacted by a change in the object. He said that in some of the scenarios they developed either the one resource was not RDF, or the user in the scenario didn't have rights to modify the one resource.

In our discussions so far we have not run into these situtations, and in the case of non-RDF resources, we would have recommended a proxy resource for use in OSLC references.

Analysis begins with the set of changed resources. Resources in an impact analysis can be considered; changed, impacted or suspect. A resource that is changed, is one of resources that starts the impact analysis off, and whose changed properties are known. An impacted resource is a resource that is expected to be effected. That means in order for the system of resources to maintain its integrity (i.e. all properties accurate) the impacted resource will have to be changed. Finally a suspect resource is one that there is some indication that the resource might have to change, but that it is not conclusive and a manual examination should be made.

Determining if a resource is suspect or impacted is very dependent on the relationship type (i.e. predicate URI). Lets look at a simple example. Suppose we have a requirement Req1, that describes the need for a protocol in an API. There is a work item WI1 that specifies some work to be done to implement the requirement. The work item is linked to the requirement with an Implements type of link. The developer assigned to the work item creates a sequence diagram resource D1 that describes this protocol. The sequence diagram is linked to the work item with a Architects type of link.

Lets say there is a change (or proposed) change to the requirement. Is the work item impacted? Is it suspect? That depends on the type of relationship (and direction). In our scenario the work item implements the requirement, and therefore any substantial change in the requirement should affect the work item (or the activities instigated by the work item). We can say the work item is impacted by the changed requirement.

What about the sequence diagram? Is it also impacted? This determination is less certain, and like before depends on the type of relationship. In this case the diagram architects the work item. So it will be impacted if the work item changes in a way that affects the architecture. A change in one of the requirements it references (via implements), would probably qualify. If however the change in the work item was a priority, or change in owner, the design resource probably isn't impacted or even suspect.

This leads us to look at the type of change (or impact) in a resource. The affect on impact is dependent on the type of link and the type of change. It is possible to refine the impact determination with additional information. For example we can define a predicate URI's impact analysis properties with information that include:

• direction of impact (target impacts subject, subject impact target, both or neither)
• list of properties (including rdf:type) in dependent resource that indicate an impactable change

With this information about link type predicate uris, an impact analysis tool can provide significantly better help in performing semi-automated impact analysis.

(JL): Maybe we should create an exhaustive list of all the OSLC resources (CCM, QM, RM...) and try to identify which ones affect AMR when they change (and vice versa). It would help identify the different scenarios to cover for impact analysis, andthe resources involved in each scenario.

Scenarios

Access impact of change

A set of resources is changed or proposed to change. What is the impact on the other resources in the system (context). What resources are impacted or suspect?

Identify impact dependencies?

Given a resource or model, what resources could produce an impact on it if they were changed.