Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - kjourdan

Pages: 1 [2] 3 4 5
Feedback from Sparx:

Thank you for your enquiry.

As you have observed, unfortunately there is no built-in functionality in the MDG DOORS add-in to allow import of a specific baseline version at this time. We have noted this as a feature request for consideration in the future, but there are no current plans to implement this feature.

Suggestions and Requests / DOORS Add-In Improvements
« on: June 14, 2017, 09:02:21 pm »
1) Need the ability to import a specific baseline of a DOORS module.  These baselines are created a formal released versions of requirements. New requirements could be added or requirements could be modified/removed at the time that requirements are being imported but the EA model should only contain the specific (baselined) requirements that were planned.

2) Need the ability to define (load) profiles for DOORS import that can be applied automatically. Process of configuring the mapping each time is inconvenient and could be inconsistent.  After disconnecting from DOORS, the connection string should be retained (and potentially re-used when reconnecting).

3) Capture baseline version (and path) of the DOORS module being imported as a tagged value on the import package in EA.  This aids in traceability between EA and the requirements in DOORS.

It appears that importation of requirements from DOORS always imports the latest requirements.  The potential exists that requirements may change between when a baseline is created (and released) and when the requirements are imported into EA. This potential increased as the time between baselining of requirements and importing of requirements increases.

Is there a mechanism or planned mechanism that allows importing a specific baseline version of a DOORS module?

Hi All,

I have begun working with the DOORS Add-In and have some questions to the community on automation.  Is is possible to configure the import settings (eg. filter view and which attributes to import and how) via scripting and run the import?  I would like a consistent way of setting the filter and configuring the mappings using EA 12.1. Is there a way to extract the baseline of the DOORS module being imported and save this off in the model?


I have created a stereotype that includes 9 tagged values.  Using "Edit with Profile Helper" in EA 12, I created a tag group and moved 7 of the tagged values into that group. Looking at the tagged values from the Stereotype Properties tab, the group shows my 7 tagged values properly with 2 tagged values outside of the group; collapsing the tagged value group shows the 2 tagged values that are not in the group. No issues here.

When the stereotype is applied in my model, the tagged value group is not displayed properly.  The tagged value group only contains 5 of the tagged values.  Outside of the tagged value group, there are 4 tagged values now. 2 of the tagged values that should have been within a tagged value group have been moved outside of the tagged value group.

Thanks all for the help.  Curious if anyone knows how the CX and CY values are calculated. Is there a formula for CX assuming CY is 13?

It is indeed related to the Style. What is peculiar is that if you set the Style to a bad string (eg. CX=NaN: CY=NaN) then manually move the label, the Style is not corrected but the label is where it placed.

The problem is related to the Style attribute after creating the diagram object.  After creation of the diagram object, the Style is set to its default of "".  My port placement scripts were retrieving the Style attribute and setting the OX, OY and ROT to fixed values.  The CX and CY values were intended to be unaltered.  My logic for parsing the Style to extract CX and CY and did not take into account that Style may not be populated; Style is always populated when elements are manually added to the diagram. Since no CX or CY values exist in the Style, the parsing would result in NaN (not a number). The value written to Style would then have CX and CY as NaN.

I have scripts that I use to position component ports and corresponding labels on diagrams; one script places the labels inside the component boundary next to the port and one script places the labels outside the component boundary next to the port.

On diagrams that I create manually (drag component onto diagram, enable ports of interest, etc), these scripts properly move the ports and their labels as expected. I can move these ports and labels around, run the scripts and the ports and labels are moved back to their position. Nothing unusual here.

I created a script that creates a diagram, adds components and their ports to the diagram.  Running my port/label placement scripts results in the ports being moved to their expected positions on the component boundaries.  The labels however appear to at their default position (outside the component, slightly below the port and extending away from the component).  If I move the port manually, the label remains that the same positional offset from the port.  I can manually move the label on the diagram.  When I run my scripts, the port is moved back into position but the label does not move where I expect; the label remains at the same positional offset from the port after I had manually moved them.

If I hide the ports for a given component on that diagram (select component, right-click, Structural Elements, None) and then show the ports (select component, right-click, Structural Elements, All), the ports and labels go to the positions that would occur if I manually dragged the component onto the diagram.  When I run my scripts, these ports and labels get moved into proper position; the labels for ports on other components continue to remain in their default positions.

Is there an attribute for these diagram objects that needs to be set to allow the labels to be moved?

Thanks Geert. 

I have prototyped a similar "work-around" using SQLQuery but don't like the fact that the APIs provided don't support very large models and don't provide feedback that the Collection can not hold the number or elements returned. I would like to see the old Collection class and APIs superceded or at least updated to provide user feedback regarding error; new APIs / classes should be created to support large complex models. 

If the Count field is going to be declared as a short, return count as -1 to indicate the number of results is too great and can not be contained in a container; otherwise, why use a short to begin with?  Returning -1 would at least allow the automation to detect the condition and operate in a predictable manner (generate an error if count if <0 to indicate the tools must be updated to use SQLQuery or new APIs/Container classes).

With the ever increasing sizes of models and information stored in these models (associations), the likelihood of having more than 32767 elements returned by a query (using GetElementSet) is almost certain.  Upon reaching this point, the automation tools used would need heavy re-work to address this limitation.  Mechanisms would need to be put in place to detect this condition and alert the users that the automation tools will not function.

To avoid this (and maintain backward compatibility), can new classes and APIs be defined that do not limit the count values to shorts (eg. GetElementSetExtended that returns and an EA.CollectionExt class which contains Count as an unsigned int). Changes to the automation tools would be done through search and replace in the majority of cases. Detection of this overflow condition could be done by comparing the count values returned in the two different collection classes. 

Bugs and Issues / DAO.QueryDef[3219] Invalid operation
« on: March 15, 2017, 03:20:23 am »
I have seen the DAO.QueryDef[3219] error being generated in EA 12.1 when the number elements returned by GetElementSet is "too big".  This same issue has been reported by others on the forum.  The specific size where this occurs is not clear. 9443 elements fails;  8119 elements passed.

This error does not get generated with a DBMS repository.  It appear to occur with a stand-alone JET 3.5 database.  I have been informed by a counter-part the EA 13 appears to not generate this error.  I have also observed that setting the "Use JET 4.0..." option results in the error no longer appearing even though the database itself is still a JET 3.5 database.

The issue is caused by the size limitation on a collection and with Collection.Count being a Short.  94002 is what is returned by the SQL scratchpad; truncation of 94002 (0x16F32) to a short yields 28466 (0x6F32).  In my case, my query is greater than 32767 so the count is no longer valid (either reported as negative value or a bogus positive value).

Sorry for the delay in responding.  In the picture shown by q below, when I click on "a" in the tagged values window, the sub-pane shows the notes that were populated in my MDG.  I like this.

If there were notes captured in the MDG for that attribute "a", the sub-pane just shows the name of the tagged value.  I am OK with this since there were no notes in the MDG.

For the parent class, the sub-pane always re-iterates the profile::stereotype (name). In the MDG, I have notes captured for these stereotypes that I would like to be shown in the sub-pane.  The behaviour applied to the tagged values within a stereotype should be extended to the stereotype itself.

I have created an MDG with numerous stereotypes.  These stereotypes have various attributes.  Notes have been populated for the attributes and the stereotypes.  When I create elements of these stereotypes, the notes from the attributes in the MDG show up in the TaggedValues window when I have selected a specific tagged value.

The notes for the stereotype itself do not show up.  The split pane is in the TaggedValues window is empty. If I click on the element type in the TaggedValue window, the split pane shows the same information; Class (XYZ) is shown in the pane for an XYZ class.  When clicking on tagged values, the notes that were defined in the MDG show up in the split pane.

I would like a way to display the notes associated with the stereotype in the MDG to be displayed.  These note provide references regarding where the stereotype is defined, how it is used, etc...

Pages: 1 [2] 3 4 5