OSLC Arch Management: Supporting Impact Analysis

In the OSLC AM domain resources are incredibly varied. There is no fixed set of properties (literal or relations) that apply to all resources in this domain. When performing impact analysis it isn't all that clear which references indicate an impact and which do not.

For this discussion, we are only considering resources that are expressed in RDF (for the time being).

Properties of a resource are either literal types or references to URIs. These URIs may be actual resolvable, typed resources. They might also just be URNs (ie. enumerations).

The term "Link" is really just a shorthand way of refering to a resource property whose value references another resource. In RDF terms it is a propery whose value is a URI. It is expressed as a statement with a property type (i.e link type) that is the predicate, the object is the referenced resource, and the subject is the resource that 'owns' the property.

This representation of a link is uni-directional.

We want to avoid strongly typing the resource on either end of a link type predicate. (i.e. testedByTestCase ). We can be less restrictive, and say that a link type predicate can specify that the subject will 'treat' or consider the object 'like' a resource of a certain type but there should be no hard assumption or requirement that it is one.

We have noticed that predicates (link types) are named in ways where semantically the relationship is actually dependent (i.e. impactable) in the other direction.

For example the following CM properties:

• affectedByDefect
• affectsPlanItem

How the predicate is worded directly affects the impact analysis. For example, if A is affectedByDefect B, then any change in B will impact A, however the reverse is indeterminant. This means that if the target of the relationship changes then the source is impacted.

On the other had with a relationship like A affectsPlanItem B. If B changes it does not imply A is impacted, however if A changes then B is impacted. Or if the source of the relationship changes the target is impacted.

It would be nice if all relationships were consistent (i.e. if the target changes the source is impacted), however we can not garantee this.

Guidelines for link predicate definition

1. In general the default 'impact determiniation' of a relationship is that if the target changes, it impacts the source resource. If the source changes, it is undetermined if the target is affected.
2. If this is not the case then ontology writers should explicitly indicate that which direction impact is felt (i.e. both, neither, target to source, or source to target).

When things change

Impact analysis is all about change. When something changes(or is proposed to change), we want to know what the 'impact' of this change is. Impact in this sense means which resources might also have to change to maintain the integrity of the system.

Because there are so many different link types, with very different semantic meaning, it is difficult to completely automate this.

Depending on the link type, the dependent resource may or may not need to change because of a change in the other resource the link is pointing to.

There may be some type of meta information we'd want to capture on a link type predicate that says things like; the owner of this property will change if any of these properties in the target resource change. A change in property means a change in a literal, or a 'changed' resource on the other end of another link.

Question: do we allow/address impact through un-changed resources. For example suppose A -> B -> C (A linked to B, B linked to C). C changes, but does not trigger a change in B, but does impact A? Is that allowed?