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 - ngong

Pages: [1] 2 3 ... 9
General Board / timeout on importing from DOORS
« on: December 11, 2018, 10:24:28 pm »
When using the DOORS plugin and importing a module, there are several steps shown while the import progresses. On Checking contents of DOORS module - the second step - I get the message Server busy together with a window telling some unreadable failure (the window is too small to read it and cannot be resized).

I click several times on Retry - in my case about 15 minutes - and it seems to work.

I assume EA DOORS plugin has a timeout waiting for a response from DOORS server. Do you know how to increase that timeout, so that EA DOORS plugin will wait a bit longer for response?

Ok, thank you KP for your help.
But again, the problem is, that I get two different Document/@ID when I export the very same profile package with 13.5 or 14.1 as a profile.xml.
Which means, I cannot maintain a profile with 14.1 that I initially created with 13.5.
If I do I will get a different Document/@ID with the very same profile package hindering to overload the profile in models where the 13.5 generated one is used.

adding some observations:
I can find the 13.5 profiles Document/@ID in the XMI export of the profile package, as you said. But I cannot find the 14.1 Document/@ID. Seems 14.1 hashing something on profile export, not just copying.
In my case exporting with 14.1 by diagram or by package not only leads to the same Document/@ID but also to exactly the same profile.xml.
But still, with 14.1 I cannot find where this Document/@ID is derived from or how it is calculated.

General Board / Re: two versions of EA on one workstation
« on: December 09, 2018, 02:00:30 am »
Thank you, qwerty
maybe I didn't search hard enough - so I had to find the solution myself.
What is important to me is, that EA as no problem working on one PC (one registry) with several installed versions even though the installer tries to hinder this (for what reason ever).

Thank you Geert, for the successful hint.

General Board / Re: Are spammers the main users of this forum?
« on: December 08, 2018, 11:00:03 pm »
Hi, Sunshine - I do not believe that the number of valuable users will stay constant if spamming increases, nor will new users be attracted to contribute. It will be a question of time to the break-even. I wonder if it is already reached.

Just want to highlight to someone who cares - and knows about spam filters - that something should be improved to keep the ease of use and attraction of our discussions, not loosing this valuable forum.

General Board / Are spammers the main users of this forum?
« on: December 08, 2018, 01:02:45 am »
I appreciate the contact to other EA users and professionals via this forum.
However, it becomes harder not to click on spams. There are about 10:1 spams per valuable entry.
Spams seems to disappear on a daily basis - but they reappear soon.

Is there no working spam filter that hinders spamming in this forum?

I am used (till EA13.5) to right-click on the datatype in the project browser or in a diagram, select Features/Attribute and got a dialog with all Attributes (its the same behavior for Operations) for change or for adding a new one.

I know that the dialog mechanisms have change (to the good) with EA14. However, when selecting Features/Attribute on a datatype or interface (not have checked with classes) nothing pops up - just silence.

How to get the Features dialog in EA14 (also had problems to find it in User Guide)

General Board / two versions of EA on one workstation
« on: December 07, 2018, 11:33:44 pm »
I came accross this problem as the IT department runs a daily job, that checks whether requested installations are already or still exist on user workstations.
I had to install EA14.1 new, every morning, as I was listed as to have EA13.0 installed.

Additionally because I do not fully trust the improvements of EA14.1 - because of painful experience - I like to have 13.5 installed on my workstation, too.
It turned out not to be as easy: I have to install one, rename the installation folder, and install the other. Otherwise the (in registry?) known installation will be automatically removed.

My question: It seems to work, but do I have to fear any serious problem by accessing the same model by different EA versions on the same workstation? (If not, why this automatic removal?)

It seems to be clear, accessing the same model (e.g. stored centrally in SQL Server) from different EA versions from different workstations shall be allowed - at least in some defined version ranges. That is why I believe that my "trick" does no harm.

General Board / Re: How to change Child Document for InteractionOccurence?
« on: December 07, 2018, 11:13:51 pm »
Thank you for committing, that there is no interactive way to do so.

General Board / How to change Child Document for InteractionOccurence?
« on: December 06, 2018, 03:37:50 am »
In my model linked Child Diagram are wrongly bound to almost all InteractionOccurrence elements. Clicking on the InteractionOccurrence in the hosting InteractionOverview diagram brings me to the wrong diagram.
I do not know how that could ever happen, no one has changed it. Somehow the database has mixed up the links to Child Diagrams.

However, I would like to link the InteractionOccurence to the correct diagram. Usually I do so by right-clicking and selection New Child Diagram. That menu item is offered for other elements but for an InteractionOccurrence. I am also not able to find the Child Diagram link information in any of the properties, nor can I find a menu item in all the ribbons, nor can I find any description of InteractionOccurrence elements in the User Guide.

How can I change the Child Diagram that an InteractionOccurrence element is linked to?

p.s. I create InteractionOccurrence elements of InteractionOverview diagrams by dragging a SequenceDiagram to the InteractionOverview diagram, selecting Interaction Occurrence. I also place Requirement elements in the InteractionOverview to trace the intercations to their requirements. As there are links from an InteractionOccurrence to a lot of requirements, I am looking for a better way to have the correct Child Diagram than deleting the InteractionOccurrence an drag the SequenceDiagram newly to the InteractionOccurrence diagram.

Let me repeat in other words:
I have a model that uses a profile for stereotypes.
I maintain that profile in a separate model, there I have a package with a diagram holding my stereotypes.
I am used to the following:
After maintanance I export the profile as a profile.xml.
In the using model, I import the profile. EA informs me that a profile of this name exists, and get asked whether I want to overload it.

But now it is different: I am not asked. The maintained profile is just imported by the same name. I get two profiles with the same name and allmost identical stereotypes. Problem is, even though the stereotypes have the same name, they seem to be different, as changes I did to the newer one get not synced to elements using that stereotype name, but from the older profile.

The reason I found lies in the Document/@ID, an element/attribut found in the exported profile.xml. If I change it manually in the newly exported profile.xml to hold the same value as the former exported one, EA overloads it on import as desired.

How can I tell EA what Document/@ID value to use at export to profile.xml?

General Board / Re: Transfer from SQL Server not possible
« on: November 29, 2018, 06:28:51 am »
Experimenting with checking Jet 4.0 and using the new extension .eapx instead of .eap, now it works.
The minimum .eapx file is - as you said Simon - roughly 2.4 MB.

Thank you Simon.
When I am exporting the diagram as a profile I can import it and it works.
However, it does not overload the profile that I have used so far, because it generates a different value for the Documentation/@id attribute.

Not overloading is a problem, because I can not apply changes to existing stereotyped elements. The newly imported profile has obviously no relation to the stereotyped elements that were stereotype with a profile with a different Documentation/@id.

Is there a solution, so that the changed an imported profile stereotypes can be synced with existing ones by name - regardless what Documentation/@id value, or how to change the Documentation/@id to the desired value on profile export?

General Board / Re: Require Lock and Edit, locking the history
« on: November 28, 2018, 06:51:21 am »
Thank you qwerty - I will switch auditing on. My aim is not to look at them interactively, but create reports on them for release documentation. I see that I can Save Logs for a certain time period. The chatty, the better. Parsing and transferring the log in a form that can be filtered in different ways for different reports  - that's what I will try.

General Board / Require Lock and Edit, locking the history
« on: November 28, 2018, 05:34:43 am »
I read the  topic,41273.0.html and was happy to see that others like Require Lock and Edit as I do. My reason was also mentioned: think before you change. And I do not have problems that colleagues make changes where they should not.

But I am missing one thing for several reasons (one reason is to fulfill ISO26262 change management rules).
I'd like to be able to be responsive to the question: "What has changed when by whom (for what reason)?". If this information would be stored somewhere, I could do a report, selective, as required for specific situations.

Has anyone an idea, how to log the history of locking?

Pages: [1] 2 3 ... 9