Hi all - some help on this function?

llandale - Thu Feb 10 12:30:35 EST 2011
This is pretty clear in the DXL manual.

You should routinely use the optional Mandatory flag, the 2nd bool parameter first is "overrideable" and the 2nd "mandatory", both cannot be true.

"f" must be the folder housing the source module; I think this will work:
.... string NameSource = "/MyProject/MyFolder/MyModule"
.... Folder fldSource = folder(module(NameSource))

Create the link-module first. The "create" embedded here looks suspicious, doesn't have enough parameters and in any case is silly to tack on a 'create' in the middle of this function; why not also create the Source or Target formal modules?

Make sure you can create these LinkSetPairings using the GUI and understand what they are doing before attempting to manage the synonym LinkModuleDescriptors in DXL.

• Louie

TooDifficult - Thu Feb 10 18:24:26 EST 2011
{code}
string SourceName = "/New ResMed Project/1. IP Reqts/MRD"
string TargetName = "/New ResMed Project/1. IP Reqts/MANF"
Folder fldSource = folder("/New ResMed Project/1. IP Reqts")
string LinkName = "/New ResMed Project/Satisfies"

addLinkModuleDescriptor(fldSource,SourceName,TargetName,true,LinkName)
{/code}

Hi thanks for the replies' I've been trying this little snippet a while already and it keeps saying I have incorrect input parameters into addLinkModuleDescriptor. Can anyone spot what I've done wrong? I can't.

By the way, Louie, Folder fldSource = folder(module(SourceName)) doesn't work; it says wrong argument or something. The manual says the input is Item ItemRef_ ...

Any clues?

Thanks,

ToODiff

SystemAdmin - Thu Feb 10 19:02:14 EST 2011

The declaration syntax for the addLinkModuleDescriptor function is as follows.
 

string addLinkModuleDescriptor(Folder f,
                               string source,
                               string target,
                               bool overrideable,
                               [bool mandatory, ]
                               string linkmod,
                               string desc)

I don't see an argument for the string variable "desc" in your function declaration - this argument is the description text for the link module and is not an optional argument, as a minimum, you'll need to add an empty string to leave the link module description unchanged as per the following:

addLinkModuleDescriptor(fldSource,SourceName,TargetName,true,LinkName,"")

I don't understand why the Link Module description is an argument in this function in the first place.

BTW - you've been writing too much html\xml code - you don't need to put a slash in front of the ending code tag to close it off. Just put your DXL code snippet between two code tags.

Paul Miller
Melbourne, Australia

TooDifficult - Thu Feb 10 21:22:07 EST 2011
Ah I see.

Thanks Paul, I'll try it out now. So everything in the code that's [ ] is optional yeah?

Yeah, lol I just realized. the closing slash has almost become instinctive

TooDiff

SystemAdmin - Thu Feb 10 21:41:41 EST 2011

....So everything in the code that's [ ] is optional yeah?.. - yep, sure is, this is the usual convention for something that is optional within the syntax of a definition for most things, particularly code.

You should take heed of something important that Louie mentioned in his post, namely ...You should routinely use the optional Mandatory flag... . Don't enable the Overrideable option, it's a dog, set it to false and set Mandatory to true (for reasons outlined by me in this post), so your function should look like this.

addLinkModuleDescriptor(fldSource,SourceName,TargetName,false,true,LinkName,"")

Paul Miller
Melbourne, Australia

TooDifficult - Thu Feb 10 22:06:58 EST 2011

Hi Paul,

Yep, took note of it so my function does indeed look like that.

But is there a way to create a handle on a link module?

The code has no syntax or debug errors but it's not creating a new linkset pairing. A Link module descriptor is the thing you find inside a link module in the drop down list am I correct? I.e., linkset pairing.

My linkmodule name is /New ResMed Project/Satisfies

is this string enough as a parameter to the function? Or should there be some sort of fullName( linkmodulehandle ) definition that returns a full path? The above path is already full I think.
 

string SourceName = "/New ResMed Project/1. IP Reqts/MRD"
string TargetName = "/New ResMed Project/1. IP Reqts/MANF"
Folder fldSource = folder("/New ResMed Project/1. IP Reqts")
string LinkName = "/New ResMed Project/Satisfies"
 
addLinkModuleDescriptor(fldSource,SourceName,TargetName,false,true,LinkName,"")

TooDifficult - Thu Feb 10 22:06:58 EST 2011

Hi Paul,

Yep, took note of it so my function does indeed look like that.

But is there a way to create a handle on a link module?

The code has no syntax or debug errors but it's not creating a new linkset pairing. A Link module descriptor is the thing you find inside a link module in the drop down list am I correct? I.e., linkset pairing.

My linkmodule name is /New ResMed Project/Satisfies

is this string enough as a parameter to the function? Or should there be some sort of fullName( linkmodulehandle ) definition that returns a full path? The above path is already full I think.
 

string SourceName = "/New ResMed Project/1. IP Reqts/MRD"
string TargetName = "/New ResMed Project/1. IP Reqts/MANF"
Folder fldSource = folder("/New ResMed Project/1. IP Reqts")
string LinkName = "/New ResMed Project/Satisfies"
 
addLinkModuleDescriptor(fldSource,SourceName,TargetName,false,true,LinkName,"")

llandale - Fri Feb 11 15:56:15 EST 2011
You can open a Link Module the same was as a Formal Module, either with "read" to get a "Module" handle, or "ModName_" ref with module(Name).

Because of that, I've started putting extra checks in my scripts:
.... Module g_mOriginal = current
.... if (null g_mOriginal or type(g_mOriginal) != "Formal") ack error and halt.

However, opening a link module doesn't do much good; each "Object" corresponds to a link set and the attributes are boring, just telling you the name of source and target modules.

When you addLinkModuleDescriptor, you can verify with the GUI by looking at the properties sheet of the open Source module.

Perhaps check modules:
if (!module(SourceName) or
!module(TargetName) or
!module(LinkName)) ack error and return

May be a little better if you CALCULATE the folder housing the source module:
Folder fldSource = getParentFolder(module(SourceName))

I wonder if you are confusing a "LinkSet Pairing" as seen in the module properties, with an actual "LinkSet" as seen inside a Link Module. You can indeed define an LSP in an existing link module that has that linkset, but if that linkset doesn't exist the LSP is just fine, then linkset will get created when you actually attempt to create a link.

• Louie

TooDifficult - Sun Feb 13 20:47:35 EST 2011
Thanks all for the replies!

Paul: Yeah I get it now. I think I forgot what an LMD was prior to this. So you can do two things with this: set the default LinkMod that the two modules Source and Target can take linking rules from.

You can also define what module links to what.

So even though there's the option of adding many many LMDs to one source module, does it mean you have to create a different LMD for a different type of link? Let's say module A links to B via the Satisfies link module, and this would maintain that every link described in this module is an 'A satisfies B' link.

By convention, would I create another LMD if I wanted to describe a pairing with 'A verifies C'? This would ensure that the source A and target C will look to the Verifies link module for their linker descriptions and also maintain that every link in this module is an 'A verifies B' link.

Or would I store both of them in the same LMD? To me this doesn't make sense anyway because I would be mixing the verifies together with satisfies and assuming both of them have the same linking structures in each link module.

Louie: I think I did confuse the linkset with the linkset pairing.

I also did see the getParentFolder function in the manual and thought of using it. I think I will implement it.

Since it's a template I'm making, I would indeed want to create an LSP beforehand, so that every 'wrong' link from an arbitrary user would be rejected.

I'll give the coding a shot and see what I get up to.

TooDiff

TooDifficult - Sun Feb 13 23:24:16 EST 2011
Yeah I forgot to put something in:

OK, you have to create an LMD between two modules. A and B.

Once you have created an LMD that 'describes' what target module to aim at and with what link module, it will record it as ONE of the entries in the linkset pairings. Being one of the entries, it does seem you can create more.

Now, on a separate level, you create a link module that has as ONE of the entries, the specific direction(s) that A can link to B. Being one of the entries, again, it looks like you can create more of the same type of entries.

Problem 1: When you do create more Linkset pairings or LMDs inside the Module Properties, this is like saying for a given source A and target B, I am setting down different link modules that I want you to base your new links on. Is that logical? So first I mark it with an LMD saying A Satisfies B - using the 'satisfies' link module. Then I mark it again using the 'verifies' module, with A Verifies B. Does this make sense? It's like you're overwriting it. So am I correct in thinking the main use of LMDs' extra entries is to control what link modules govern links between a given source A and an arbitrary target B (chosen by user?)

E.g., I say Satisfies is to be used between A and B but in another entrY I say that Verifies is to be used between B and C. This seems to make more sense?

Problem 2: Within the link module what you are doing is defining link directions - as well as actual links if you wish. So we create a module linkset saying A ---> B in that specific direction. If this link module has a whole lot of other linksets saying B--->C, D---->E, is it actually sensible to place them here? The link module is called satisfies and the arrow directions between each module linkset show this behaviour as well.

Do you bunch everything into one link module or create different link modules for different pairings of modules (this latter choice will result in so so so many link modules)

Thanks,

TooDiff

TooDifficult - Sun Feb 13 23:28:47 EST 2011

SystemAdmin - Mon Feb 14 04:29:35 EST 2011
...the main use of LMDs' extra entries is to control what link modules govern links between a given source A and an arbitrary target B...

I think you're starting to see the light - but just in case - here's a once only offer for you and others - I have attached a PDF extract of some DOORS training material that I created some time ago on the topic of linking and linkset pair rules - I have permission to publish this extract from a company that I have done some contracting work for (company logo removed to avoid gratuitous advertising). See if this helps your understanding of LMD's as a feature of DOORS - once you fully understand the concept, then applying the DXL may be easier.

TooDifficult - Mon Feb 14 17:01:07 EST 2011
Wow thanks for this it helps so much.

I guess it's more ideal to have a bunch of different link modules that each govern linking between just 2 modules.

Now I just have to try and translate that into code. So a linkset (the drop down in the link module) is the one that specifies linking direction right?

Thanks,

TooDiiff

TooDifficult - Mon Feb 14 17:01:07 EST 2011
Wow thanks for this it helps so much.

I guess it's more ideal to have a bunch of different link modules that each govern linking between just 2 modules.

Now I just have to try and translate that into code. So a linkset (the drop down in the link module) is the one that specifies linking direction right?

Thanks,

TooDiiff

Mathias Mamsch - Tue Feb 15 03:53:49 EST 2011
One comment from me: The link pairing restriction thing seems to be redundant on the first glance. A linkset defines source, target (and therefore direction) and obviously the link module. The same is true for link pairing restrictions. So the question is: why would you need both? The answer is: A link pairing restriction defines, to which modules you are allowed to link at the moment. A linkset is merely a like a container for the links. Using the combination of link restrictions and link module access you could implement a process like this: 1. links between module A and B are allowed. 2. Keep the links between A and B but now only allow links from A to C. You could also also disallow changing any links from A to B by using a separate link module and revoke access to it on the second process step. In the second step, the linkset for A->B still exists but you are not allowed to use it to create links anymore.

So you see, link modules define where links are and who has access to them, link pairing restrictions define, which links can be created. Unfortunately most of the time we do not want to change the link module or restrictions but just have a static link setup. So in this static case, would Telelogic not have created this unfortunate "Default Link Module" setting there would probably be no need for link pairing restrictions (provided, that the module knew the linksets that exist for it).

Regards, Mathias

TooDifficult - Tue Feb 15 19:48:51 EST 2011
I sort of see where you're coming from.

Are you referring to how the linkset pairs under Linkset in the Module Properties seems to have the same function as a linkset direction restriction? Because the function for a Link Module Descriptor takes the input source and target, which sort of indicates that there is some kind of direction restriction. Otherwise it would just take 2 arbitrary module inputs and let the linksets determine linkage direction. In fact at all levels of linking (LMD, linkset pair, linkset) the functions take source and target. Which of these functions actually use the source and target for what they are, rather than just accepting two modules that the user defines and calling them source and target?

TooDiff

TooDifficult - Tue Feb 15 19:58:19 EST 2011

void Create_LinkMod()
{
        //Create link modules here      
 
                Satisfies = create("/New ResMed Project/Satisfies","Links that satisfy -",manyToMany,true)
                close(Satisfies,false)
 
                Verifies = create("/New ResMed Project/Verifies","Links that verify - ",manyToMany,true)
                close(Verifies,false)
 
                Validates = create("/New ResMed Project/Validates","Links that validate -",manyToMany,true)
                close(Validates,false)
 
                //Module References = create("References","Links that reference -",manyToMany,true)
                //close(References,false)
                //Module Testable = create("Testable","Links tested by -",manyToMany,true)
                //close(Testable,false)
}
 
void Create_LinksetPairings()
{
                //Links using Satisfies LM to link
                addLinkModuleDescriptor(f2,FG_SYS,REG,false,true,"/New ResMed Project/Satisfies","")
                addLinkModuleDescriptor(f2,FG_SYS,MRD,false,true,"/New ResMed Project/Satisfies","")
                addLinkModuleDescriptor(f2,FG_SYS,CRD,false,true,"/New ResMed Project/Satisfies","")
                addLinkModuleDescriptor(f2,FG_SYS,SRVC,false,true,"/New ResMed Project/Satisfies","")
}
 
void Create_Linkset()
{
                //Linksets to define direction
                *create(Satisfies,FG_SYS,REG)*
}
 
Create_LinkMod()
Create_LinksetPairings()
Create_Linkset()

The above code gives me an error saying that the emboldened "create(Satisfies,FG_SYS,REG)" "is not a link module"

Doesn't make sense because I've clearly defined it to be a link module!

TooDiff

SystemAdmin - Tue Feb 15 22:19:38 EST 2011

In function Create_LinkMod(), you are closing the link modules after they have been created. That's OK and good practice, but once you have closed a module, as far as I know, the handle to the module is also lost, so for example, the Module variable "Satisfies" is = null after the close. Louie and Mathias might have a more accurate way of describing this.

Have a go at implementing the following in function create_linkset()
 

void Create_Linkset()
{
Satisfies = edit("/New ResMed Project/Satisfies",false) //Open Link module "Satisfies" in edit mode, a handle to this module is passed to the Module variable "Satisfies"
 
create(Satisfies,FG_SYS,REG) //Add a new linkset
 
save Satisfies //Save the link module to save the new linkset
 
close(Satisfies,false) //Close the opened link module
}

Paul Miller
Melbourne, Australia

SystemAdmin - Tue Feb 15 22:19:38 EST 2011

In function Create_LinkMod(), you are closing the link modules after they have been created. That's OK and good practice, but once you have closed a module, as far as I know, the handle to the module is also lost, so for example, the Module variable "Satisfies" is = null after the close. Louie and Mathias might have a more accurate way of describing this.

Have a go at implementing the following in function create_linkset()
 

void Create_Linkset()
{
Satisfies = edit("/New ResMed Project/Satisfies",false) //Open Link module "Satisfies" in edit mode, a handle to this module is passed to the Module variable "Satisfies"
 
create(Satisfies,FG_SYS,REG) //Add a new linkset
 
save Satisfies //Save the link module to save the new linkset
 
close(Satisfies,false) //Close the opened link module
}

Paul Miller
Melbourne, Australia

llandale - Wed Feb 16 13:20:47 EST 2011

Sadly the 'Module' handle is not set to null when the module is closed, it just points to de-allocated memory that still looks like a 'Module'. Using a closed 'Module' handle often works, sort of, but eventually will lead to exception violations. YOU must insure you don't use a Handle after the module is closed.

Most of the time there is no issue, since scripts tend to look like this:

for all items
{  if its not a module continue
   Module mod = open
   deal with mod
   close(mod)
}

However, for scripts that don't look like the above, such as following links or opening a module but returning power back to the Dialog box, you must keep track. Its tricky. First off create a close function:

bool  CloseMod(Module &mod)
{  if (null mod) return(true)
   noError()
   close(mod, false)  // no save
   string ErrMess = lastError()
   if (!null ErrMess) //
   return (false)
 
   mod = null
   return(true)
}

That will null out your Module handle. That doesn't cover all the situations, however.

Perhaps add some sort of "if (isOpen(module(fullName(mod)))", but not sure where I'm going with that.

• Louie

TooDifficult - Wed Feb 16 18:53:25 EST 2011
Hi,

OK, I'll try using that close function.

By the way, up to the point where I create a linkset (after rearranging the close to occur after the linksets have been added), I can see the pairings inside the link module but not the grid. Is this an issue? Do grids only exist after you create a link?

So top I see Source/target and bottom I see source/target (didn't check which was which), but they are only words have no grid in between them.

Thanks,

TooDiff

TooDifficult - Wed Feb 16 18:55:14 EST 2011
Here's a JPEG of what it looks like; it doesn't look very good.