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.

Resources

Here is the set of OSLC defined resource types

Core resources:

Discussion
A Discussion resource is intended to represent a sequence of comments or notes regarding the associated resource.

CM resources:

Change Request
The Change Request resource is a single definition used to define many kinds of change requests such as: defect, enhancement, task, bug, activity, etc. There are a fair number of common properties between these different kinds of change requests and can use some of the properties in the follow definition to identify them.

RM resources:

Requirement

Requirement Collection

QM resources:

Test Plan

Test Case

Test Script

Test Execution Record

Test Result

SCM resources (pre-final):

Object version

A resource representing a specific version of an object that is being controlled in the SCM system. In some SCM systems, this concept is called a configuration item. Objects frequently represent files and directories, but might also represent other resources such as requirements, models, assets, etc. Note that providers might restrict resources of some types to having a single version - for example, frequently change sets have only a single version, whereas files typically might have many versions.

Configuration

A resource representing a set of object versions arranged in a hierarchy. A configuration has links to specific versions of any number of objects as immediate members forming the top level of the hierarchy. Each of those top-level objects versions may have links to any number of other object versions, with potentially a variety of containment relationships. For example, a configuration might contain a specific version of a file system directory object, and under that specific versions of any number of subdirectories and files.
The members of a configuration are defined as both the immediate top-level members and the members of those members, recursively, but excluding the members of any sub-configurations (members that are themselves configurations).
The contents of a configuration is not necessarily frozen; the contents of and properties of the members might change, and the versions of the members might change. Some providers might support only a single version of a configuration, other might support multiple versions of a configuration, with each version containing a different set of object versions, in a potentially different hierarchy. With some providers, directories can contain symbolic links and configurations (sub-configurations) as well as files and subdirectories. Providers may support other types of resources as members of a configuration, such as requirements, test cases, etc.

Baseline

A frozen configuration. If you look at the same baseline in the future, it will normally have the same members (not all providers can guarantee complete immutability - for example, administrative actions might modify data). In some providers, baselines might be able to contain other baselines, while with other providers that might not be possible. Some providers might support only a single version of a baseline.

Component

A configuration or set of configurations may be divided into components representing some user-defined set of object versions and/or sub-configurations; for example, components might be used to represent physical components or software modules. A provider is not required to implement components; they are used only as a way of limiting the scope of the closure over links. Components might or might not be resources; they might be dynamic sets of object versions chosen by other criteria such as property values. A provider can also treat each configuration and sub-configuration in a hierarchy as being separate components.

Change set

A set of changes to be made to one or more configurations, where each change is described in terms of members (direct or indirect) that should be added to, replaced in, or removed from some configurations.

Directory version or file version

A resource describing some specific version of a directory or file in the SCM system. Directories can contain files, subdirectories, and (in some providers) symbolic links and sub-configurations.

Directory or file

A resource representing all versions of some particular directory or file.

Symbolic link version

A kind of object version representing some specific version of a symbolic link, as used in UNIX file systems. A symbolic link holds a string property containing an absolute or relative file system path; this path might or might not point to a file system representation of some other SCM resource.

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.