Hi all,
Following code doesn't work when I use LinkRef in place of Link for Out-links and Link inplace of LinkRef for In-links. What is the reason for this? What is difference between Link and Linkref?
Object o
Module m = current
//LinkRef lref
Link lref
ModName_ srcModRef
for o in m do
{
for lref in o->"*" do
{
srcModRef = target lref
print fullName(srcModRef)"\n"
}
}
ashokanumula - Mon Oct 31 16:40:49 EDT 2011 |
|
Re: What is difference between Link and Linkref?
llandale - Mon Oct 31 19:08:16 EDT 2011
Not sure how to say it right.
A "Link" is a handle on the actual thing. It belongs to the Source module, which must be open in order to see the Link. A "LinkRef" is some sort of wierd reference to the link and has less information associated with it.
Perhaps there are other features, but a LinkRef can be seen in the Target module even when the Source module is not yet open; whereas Links cannot. As described in the manual, when dealing with Inlinks you first should loop through the incoming LinkRefs, get full name or ModName_ of the source module, and open that module (presumably read invisible standard view). You can then see the incoming links and should proceed with the normal for lnk in obj <-"*" loop.
Maybe some other folks use LinkRefs more creatively, but that's all I do with them.
|
|
Re: What is difference between Link and Linkref?
OurGuest - Tue Nov 01 07:40:22 EDT 2011
The help files are rather vague on definitions. To provide a complete definition someone would have to know about the internal architecture of DOORS. However, a working definition could be something like:
LinkRef information is available when the target of a link is available.
Link information is available when the source of a link is available.
Link information and LinkRef information have some similarities but they are not equal.
|
|
Re: What is difference between Link and Linkref?
ashokanumula - Tue Nov 01 14:40:21 EDT 2011
Thanks Louie and OurGuest for response.
|
|
Re: What is difference between Link and Linkref?
llandale - Wed Nov 02 09:53:05 EDT 2011
I guess the following: LinkRef is used by DOORS as a mechanism for displaying incoming link indicators. Although I really don't understand where the LinkRef would be stored, its different from a Link and that's why sometimes the link indicators get messed up, and why you can fix that mess-up by opening up the modules edit, accessing all the links (which probably re-sets the LinkRef), and then saving both modules, even though you've made no changes.
|
|
Re: What is difference between Link and Linkref?
Mathias Mamsch - Wed Nov 02 10:41:11 EDT 2011 llandale - Wed Nov 02 09:53:05 EDT 2011
I guess the following: LinkRef is used by DOORS as a mechanism for displaying incoming link indicators. Although I really don't understand where the LinkRef would be stored, its different from a Link and that's why sometimes the link indicators get messed up, and why you can fix that mess-up by opening up the modules edit, accessing all the links (which probably re-sets the LinkRef), and then saving both modules, even though you've made no changes.
Links can have attributes. Infact they have attributes like "Created On", "Last Modified By", etc. which can be read from the link just like object attributes. Now when you have an inlink the source module, may or may not be open. If it is not open the information of the link (i.e. its attributes) has not been loaded. That is where LinkRef comes into play. It is a reference to a link. Since the source module is not open you cannot access link attributes or delete links from a link reference. It just tells you, where the source object of the link is, so you can go there and get a real Link from there.
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: What is difference between Link and Linkref?
llandale - Wed Nov 02 17:13:31 EDT 2011 Mathias Mamsch - Wed Nov 02 10:41:11 EDT 2011
Actually it is pretty easy. A Link is something that has a source object and a target object. It is stored with the source, i.e. outlinks are stored in the module where they originate from. That is why you need edit to make an outlink but not an inlink.
Links can have attributes. Infact they have attributes like "Created On", "Last Modified By", etc. which can be read from the link just like object attributes. Now when you have an inlink the source module, may or may not be open. If it is not open the information of the link (i.e. its attributes) has not been loaded. That is where LinkRef comes into play. It is a reference to a link. Since the source module is not open you cannot access link attributes or delete links from a link reference. It just tells you, where the source object of the link is, so you can go there and get a real Link from there.
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: What is difference between Link and Linkref?
Mathias Mamsch - Wed Nov 02 20:55:05 EDT 2011 llandale - Wed Nov 02 17:13:31 EDT 2011
But where is it stored? How does the target object know it has a reference to a link?
I think there is a confusion coming from the terms out-link and in-link. Technically there is no such thing in DOORS. There are echoed and non-echoed links. Links are always stored at the source. For echoed links you have a link reference also stored at the target. In the module editor you have for every link an "outgoing link indicator". For echoed links you have an "incoming link indicator".
From a DXL perspective you can only get a "Link" handle if the source module (and therefore the link) has been loaded. You can get a Link either from the source object or the target object once the source has been loaded. DXL will in this case automagically know the Links that have an object either as source or target (for Link in Object -> ...). If the source is not loaded, then you can still find link references 'LinkRef' (which actually refer to the echo part of a not yet loaded echoed Link) on an object. You can use it to load the source, therefore making DOORS load the 'Link' and then receive it from the object.
Maybe that clears things up, Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: What is difference between Link and Linkref?
llandale - Thu Nov 03 18:36:33 EDT 2011 Mathias Mamsch - Wed Nov 02 20:55:05 EDT 2011
This is for echoed links. An echoed link means, that the source object will store the link, but also the target object will store a link reference (in inlinks.dtc). A non-echoed link will not have a link reference at the target. In this case I am talking about data in the database.
I think there is a confusion coming from the terms out-link and in-link. Technically there is no such thing in DOORS. There are echoed and non-echoed links. Links are always stored at the source. For echoed links you have a link reference also stored at the target. In the module editor you have for every link an "outgoing link indicator". For echoed links you have an "incoming link indicator".
From a DXL perspective you can only get a "Link" handle if the source module (and therefore the link) has been loaded. You can get a Link either from the source object or the target object once the source has been loaded. DXL will in this case automagically know the Links that have an object either as source or target (for Link in Object -> ...). If the source is not loaded, then you can still find link references 'LinkRef' (which actually refer to the echo part of a not yet loaded echoed Link) on an object. You can use it to load the source, therefore making DOORS load the 'Link' and then receive it from the object.
Maybe that clears things up, Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
So I see you do modify the target module's database files when you link to an object, even if its open Read. Now I wonder what happens if you create a link to target T while someone else is saving T.
Yes there is no such "inlink" nor "outlink" thing stored in the database, just "link", but the terms are rather useful when viewed from the context of an object, something that you always do when dealing with links.
|
|
Re: What is difference between Link and Linkref?
Mathias Mamsch - Fri Nov 04 06:35:42 EDT 2011 llandale - Thu Nov 03 18:36:33 EDT 2011
When would a link not be echoed? Is your use of "echo" the same as in the DXL manual under "versioned links" (something I've never yet dealt with).
So I see you do modify the target module's database files when you link to an object, even if its open Read. Now I wonder what happens if you create a link to target T while someone else is saving T.
Yes there is no such "inlink" nor "outlink" thing stored in the database, just "link", but the terms are rather useful when viewed from the context of an object, something that you always do when dealing with links.
The main property of a non-echoed link is that DOORS will not ensure that for each non-echoed link reference there is one non-echoed link and vice versa: For a non-echoed link there might not be a link reference. At that shows the basic problem of non-echoed link references (those little 'in-link' indicators that you have in baselines). They are pretty much useless. In most cases you will not even have a link for them somewhere. You cannot use them to get information about the link (like a suspicion, a creation date, etc.). And at least in DOORS 8.2 they are pretty elusive, they will simply vanish even from baselines sometimes. The non echoed links are of more use. They are not elusive and have the full information about the link. These can be handled from DXL perspective like normal links, with the exception that you do not have a link reference for them (and that you cannot modify them anymore, since should only be in baselines).
So the conclusions that I drew for myself were:
-
A DXL script that handles "outgoing" links should always use for Link in all obj->"..." since omitting the 'all' will not process links to baselines, even if they are echoed (for whatever reasons).
-
To explicitly skip non-echoed links, one should use the 'bool echo(Link)' function.
-
Scripts that process inlinks should only work with echoed links and also explicitly check. In Baseline Sets you can have echoed links that come from a baseline. One should not process non echoed in-link references, since they are not reliable. Note that for processing inlinks the 'all' must be put in parentheses: for Link in all (obj<-"...") due tue operator precedence.
-
Traceability scripts should either only work with echoed links (e.g. in baseline sets) and explicitly check for them or should only evaluate out-links by starting the evaluation at the buttom of the chain.
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|