Organize Package

[rothnic]

I'm creating a script to import some requirements and create connections between them. As part of that I want to be able to manage the structure of the packages and update it when something changes.

I have tried setting Element.PackageID equal to the Package.PackageID that I want the requirement moved to, but nothing changes after updating and refreshing the package.

Is moving elements between packages supported by the scripting interface?

[rothnic]

Right after messing with this forever then posting this, I figured it out.

I needed to Update both the package and the element. Then Refresh the top level package I'm working on.

[rothnic]

A similar issue that I have that I cannot get to work after messing with update and refresh of the element, elements, and package is for the parentID.

I create a bunch of elements, then try to organize them. I do this by setting the parentID for one element equal to the elementID for the element I want it embedded up underneath. I am trying to do this for activities, for a decomposition of system level functions.

After doing this and refreshing/updating, the structure doesn't change. Am I doing this correctly with parentID and elementID?

[qwerty]

Element nesting is not supported in all combinations. Try to do it manually first. Eventually read the GetLastError() result.

q.

[rothnic]

Element nesting is not supported in all combinations. Try to do it manually first. Eventually read the GetLastError() result.

q.

I am able to nest the Activities in the content tree manually. Then I was able to read the parentID and it was equal to the parent element's elementID. I'll try checking for the error. Thanks.

[qwerty]

You might also post code snippets if you're still stuck.

q.

[rothnic]

You might also post code snippets if you're still stuck.

q.

Will do tomorrow if I can't get it to work. Didn't have time to play with it anymore. This is on a classified computer so i'll have to copy some over manually.

We have some high level system functions that we have stored in DOORS. I have an export of that and am using the CSV import library via jscript. We have numbering id's for the functions I put into a tagged value, like 1, 1.1, 1.2, 2, 2.2, etc that I'm using to derive the structure. So I import/update all of the functions, then run an organize function. The organize function derives the parent for each element by finding the last '.' in the ID string, then grabbing the substring from 0 to that index. I have confirmed that I am importing, setting the tags, parsing the tagged values correctly, then searching for and finding the parent activity correctly.

The next step once I have the current element and the parent is pretty simple, and I'll try to remember the gist of it:

Code: [Select]

currentElement.ParentID = parentElement.ElementID;
// Have gone overboard here since I'm not super confident on what absolutely needs to be updated/refreshed, so some of this might be redundant
parentElement.Update();
currentElement.Update();
parentElement.Elements.Refresh();
thePackage.Elements.Refresh();

 I think it would be useful to import these as Activities to use for functional analysis. We have a mapping between them and our build requirements, which are mapped to system requirements, which are mapped to system of system requirements, which are mapped to system of system functions.

The class I took used magicdraw, and the professor encouraged a more object oriented organization. So if you were starting from scratch, a high level activity(system function) would be created, then an activity diagram underneath it. You would define the subordinate activities within that scope, then instantiate their use within that scope within the activity diagram as actions. I could use packages instead, but to me what I described seems intuitive. If you could suggest a different approach that works better with EA, I'm open for suggestions.

[qwerty]

Regarding your code:

Code: [Select]

currentElement.ParentID = parentElement.ElementID;
currentElement.Update();
is sufficient. This already reflects the changes also in the browser.

Code: [Select]

parentElement.Elements.Refresh();is only eventually needed if you iterate them later. Everything else is not needed.

I have also noticed that this works if the child is in a different package than the parent! So EA adjusts the packageId as well.

Now for you approach (something complete different?): I'd go from requirements to use cases linking them via either <<satisfy>> of a realize relation. Activities appear inside the use cases describing the single scenarios to reach the goal of the use case (returned value for the primary actor). Inside the the activities you'll find actions representing the single steps.

q.

[rothnic]

Regarding your code:

Code: [Select]

currentElement.ParentID = parentElement.ElementID;
currentElement.Update();
is sufficient. This already reflects the changes also in the browser.

Code: [Select]

parentElement.Elements.Refresh();is only eventually needed if you iterate them later. Everything else is not needed.

I have also noticed that this works if the child is in a different package than the parent! So EA adjusts the packageId as well.

Now for you approach (something complete different?): I'd go from requirements to use cases linking them via either <<satisfy>> of a realize relation. Activities appear inside the use cases describing the single scenarios to reach the goal of the use case (returned value for the primary actor). Inside the the activities you'll find actions representing the single steps.

q.

Thanks, yeah there is  how I would do it from the start, then how I make sense of what already exists that was generated using DOORS only by our prime contractor. They at times went beyond what is needed for Use Cases and these system functions.

What I've seen done is have a refine relationship between a use case and an activity.

[qwerty]

What I've seen done is have a refine relationship between a use case and an activity.

That's more or less a matter of taste how to relate requirements and use cases. Important is the relation itself.

q.

[rothnic]

What I've seen done is have a refine relationship between a use case and an activity.

That's more or less a matter of taste how to relate requirements and use cases. Important is the relation itself.

q.

Sorry, that sounded argumentative because I didn't expand further on the thought. I just mean that because our use cases are so complicated and not in the model currently, these activities were going to be that refining side of that relationship. There isn't an existing clean mapping between use cases and these functions currently. But, that is something I'm looking at doing in the future.

[qwerty]

So you mean you have refinements with requirements? Personally I'd avoid that. There should be only the atomic requirements be left. Anything resembling a refinement should go into use cases. The reason is that requirements are meant to be tested. And if you have refinements then what's the point in testing them? When you're thinking about refinement of requirements, then why not doing the step towards use cases. Here's where refinement will come in. Finally this is a way of expressing conditions.

q.

[rothnic]

So you mean you have refinements with requirements? Personally I'd avoid that. There should be only the atomic requirements be left. Anything resembling a refinement should go into use cases. The reason is that requirements are meant to be tested. And if you have refinements then what's the point in testing them? When you're thinking about refinement of requirements, then why not doing the step towards use cases. Here's where refinement will come in. Finally this is a way of expressing conditions.

q.

A refinement of use cases with activities. So if you had a use case of Provide Mission Data, with an associated actor. You could, if needed, refine the use case with an activity called "Provide Mission Data", which would expand on the system and actor behavior.

The things that I'm importing are more system functions/behavior instead of functional requirements.

The only time I've used refinement was for the use case to activity relationship. There is a valid use if you wanted to maintain some interim state of a requirement with any associated analysis/rationale in relation to a more refined requirement, but I haven't really found use for it.

Thanks for the help. I found my issue in that I made a mistake and had theElem.ParentID == theParent.ElementID. After fixing that, I was able to get it to work.

[qwerty]

Glad to hear it's working.

Regarding use cases: refinement is actually not the right word. It took me some time to understand that use cases are not "refined" but "synthesized". This makes a big difference. The "refinement" comes from programming where you break down something into smaller parts. You refine it. The use case synthesis in contrast is something where you try to build the puzzle from small images. You have somehow the whole picture, or in other words the goal. Then you try to find out how to achieve that goal by putting together the pieces. These form a couple of scenarios which can also be viewed as activities. Inside activities you have a lot of single steps or actions. While synthesizing you try to conform to the requirements. So you link use cases and requirement. In the end all your (functional) requirements must link at least one single use case.

q.

[rothnic]

Glad to hear it's working.

Regarding use cases: refinement is actually not the right word. It took me some time to understand that use cases are not "refined" but "synthesized". This makes a big difference. The "refinement" comes from programming where you break down something into smaller parts. You refine it. The use case synthesis in contrast is something where you try to build the puzzle from small images. You have somehow the whole picture, or in other words the goal. Then you try to find out how to achieve that goal by putting together the pieces. These form a couple of scenarios which can also be viewed as activities. Inside activities you have a lot of single steps or actions. While synthesizing you try to conform to the requirements. So you link use cases and requirement. In the end all your (functional) requirements must link at least one single use case.

q.

From Practical Guide to SysML, a similar thing I'm doing is stated in this reference to the relationship between use case and activity:

"The activity diagram in Figure4.7 shows the actions required of the Driver and the Vehicle to Control Power. The activity partitions(or swimlanes)represent the Driver and the Vehicle.The actions in the activity partitions specify functional requirements that the Driver and Vehicle must perform.

They reference a use case diagram for Vehicle with a use case of Control Power involving Driver. They use an activity of the same name as the use case.

Are you saying that this relationship between the use case and activity with the same name would literally be synthesize, or just describing more about what the refinement relationship really means?