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 4 5
16
General Board / Primitive Types in Tags
« on: September 18, 2017, 06:05:09 pm »
Sometimes I cannot add any value to a tag of an element of a certain stereotype. I got no clue, why.

The chosen primitive type for the regarding attribute in the profile that defines that stereotype may be the cause for my problem.

How do I define the set of primitive types to choose from in creating the profile? Selecting a certain Product Name in the Code Engineering Datatypes? If so is that binding for the whole model or just one element? What would be the best to choose for creating attributes for stereotypes that should become a string value?

Any advice or link to read would be welcome.

Kind Regards

Rolf

p.s. even if I change the datatype back to int, I am not able to enter any value. Maybe there is different reason why I cannot enter a tag-value than the profile datatype.

17
General Board / Best way to share a package
« on: September 10, 2017, 11:17:29 pm »
Assume 2 or more models sharing a set of basic data types in a certain package.
It has been xmi exported by the front-most project and imported by others at starttime.
All projects refer to the same GUID when they refer to a certain datatype.

Now assume the front-most model extends that basic types package, corrects some flaws and improves some of the types.
What would be the best strategy to get those changes to the other model as well?

18
Bugs and Issues / Re: Problem to check-in to PTC
« on: May 25, 2017, 09:06:06 pm »
thank you, qwerty - a colleague of mine is fluent in scripting EA, will ask him.

@Oliver, PTC Source Integrity has an unresolved issue:

https://www.ptcusercommunity.com/thread/40277
and PTC refuses to change that in a timely manner.

I know of two tools that have problems with that one: EA and VectorCAST.
In general all tools using the XML specification to the extend having lines longer than 16k characters without a new-line.
With source files PTC reads lines, not characters, and cannot accept lines longer than 16k.

EA exports xml files as configurable items for version control. Sometimes they come with lines longer than 16k. I have seen ~150k, but that model is far from ready. I expect even longer lines.
One work-around would be to check-in the xml files as binaries into PTC. This has a bad influence on size and performance of the PTC database for very big files. Exporting an EA package could grow too big.

The other solution that I am taking is, to break long lines by inserting newline characters at places where not only XML but also EA accepts them. A good place is at sub-strings "},{" after the comma. I am inserting as few as possible.

In one post above I am detailing the steps to be taken manually when checking such packages into PTC.
Now I am going to automate this in order to hide this inconvenience from users in other teams.

Best Regards

Rolf

19
Bugs and Issues / Re: Problem to check-in to PTC
« on: May 23, 2017, 11:15:47 pm »
super qwerty,

that is similar to what I did in Java You did it in python, not a regex, and if the "," is not in the next 384 chars, the line gets too long. To achieve searching backwards, you got to introduce some  buffer handling. Add also a good response for any failure that may happen and also looking for non-printable characters, you will get to ~100 lines, what is ~200 in Java. Think to deliver your tool to some other team members abroad.

However, the question remains: If I open in EA the Package Control dialog and choose check-in, how to pipeline the xml through your tool prior to hand it over to PTC? Avoiding the failure message that comes with check-in or put.

Kind Regards


Rolf

20
Bugs and Issues / Re: Problem to check-in to PTC
« on: May 23, 2017, 04:44:43 pm »
Hi qwerty,
looking forward to your regex, finding long lines and inserting a newline at the nearest comma just less than 16536, say POS, and nearest but less than 16536+POS, say POS1 and nearest 16536+POS+POS1...

But the Java code is not the real question. The real question would be: How to automate the procedure to break the attribute string and check the package in.

As it looks for me, EA+PTC seems not to be a very good combination.

Kind Regards

Rolf

21
Bugs and Issues / Re: Problem to check-in to PTC
« on: May 23, 2017, 03:05:14 am »
Has not been that easy, qwerty:

  • The long line can grow very long: currently I am at 150k and the model is less than 20% through.
  • [The long lines in the XMI file are values of just two Tagged values $ea_attclassified and $ea_oprsclassified, that is: breaking the lines has to be done on String level, not XML.

They look like
UML:TaggedValue tag="$ea_attsclassified" value="{B4A1C8DF-1D75-4226-A88B-258C986E2C37},{6E172079-E70F-408F-9630-915719CD029D},{B9C03329-21FF-4120-A27D-F27A7A6A0399}, ... (>150k characters, maybe grows to 1M)

I could have used tokenize function of xslt and substitue every },{ by },\n{.
However, it seems to me likely that I would see heap overflow, if the xslt processing copies attribute values for some reason.
And also it sounds sane to me to put the changes to the EA-XMI file to a minimum, leaving the lines just below 16k.

My solution was a transformation utility (~200 lines POJO Java) that does just that, while paying heed to buffer sizes. I was lucky that the inserted newlines did not harm the EA-import of the XMI file or violate some checksum or the like.
My procedure is as follows:
  • try to check-in the package
  • accept the failure
  • insert as few as possible newlines
  • check in using PTC
  • synchronize version control state in EA

Do you think, I could find a better solution? This one would be hard to sell to my users.

Kind Regards


Rolf

p.s. BTW, I was told by the PTC maintenance that there is an unwritten rule, that a printable String in Java should not contain more than 16k consecutive characters without a newline. I did not know that one. However, if there is some truth in it, it might be an argument for Sparx not to have such long attribute values in their XMI. Even though the better solution would be, that I can define to PTC how to distinguish a character from a binary file.

22
Bugs and Issues / Re: Problem to check-in to PTC
« on: May 21, 2017, 04:43:27 am »
Thank you KP,

i understand: if the current class is int or uint8_t or the like, which is heavily used throughout the model, it es very likely, that $ea_attsclassified gets very long.
If it exceeds 16k, I got trouble using the version control with PTC/Integrity-Source.

Is there any chance to get line breaks in the value of $ea_attsclassified?

23
Bugs and Issues / Alias does not show
« on: May 19, 2017, 03:03:01 am »
What I did:
Placing several InteractionOccurence elements on an InteractionOverview diagram and give some InteractionOccurence an Alias text. Now switch on in the diagrams properties "Use Alias if Available".

What I expected:
to see the Alias text on the diagram instead of the names of InteractionOccurence elements.

What I got:
I still see the names of InteractionOccurence elements.

Doing the same on the same diagram e.g. with Requirement elements works as expected.

24
Bugs and Issues / Re: Problem to check-in to PTC
« on: May 11, 2017, 11:28:42 pm »
I intensified my analysis and found out, that the characterset idea was not the solution. It was a lengthy line that did not go away when formatting the XMI file using Eclipse formatter. For some reason, EA writes the UML:TaggedValue tag="$ea_attsclassified" and the UML:TaggedValue tag="$ea_oprsclassified". For one UML:Class in the XMI holds line 21222 and line 21223 each with 16695 characters.

I substituted that class by a new one and got rid of the problem.
What are these tags for?

25
Bugs and Issues / Re: Problem to check-in to PTC
« on: May 10, 2017, 09:11:29 pm »
Thank you, qwerty.

the failure screenshot can be looked at here: http://picpaste.de/2017-05-10-NoCheckIn-aNLWHHyE.PNG

Yes, the failure seems to be identified: PTC is justifying the new package xml as binary and refuses to check it in, over a text file. (Strange!)

As my current user account at PTC is not strong enough to view the link you, qwerty, supplied (I love open source) I found this link:
https://www.ptcusercommunity.com/thread/40277

They propose - as a workaround - to format the XML. However, it was formatted and I formatted it newly using Eclipse XML plugin. Nothing solved the issue.
Could it be a characterset issue?

26
Bugs and Issues / Problem to check-in to PTC
« on: May 10, 2017, 06:37:13 pm »
For some weeks now, I am using "Package Control" together with PTC, prior to roll it out in the team. Once you get used to it, it seems to be quite productive.
However, today I tried to check-in a package and got the message MKS125628: Could not compute text delta ... (see attached).
I repaired the data base, compacted it. But nothing helped.

Any suggestion?

(how to attach a screenshot?)
The whole failure message from PTC is: MKS125628: Could not compute text delta. Likely cause is that you are attempting to check in binary data into a text archive.
I am using EA13 producing into an .eap file, PTC/Integrity 10.7.0.7925 with APIU 4.15.7925.

27
Automation Interface, Add-Ins and Tools / How to find a role by name?
« on: November 18, 2016, 10:06:26 pm »
Sometimes I remember just a name. Trying to find it with Simple or Extended find does not reveal it. What helps is, looking through all diagrams and eventually I catch it, e.g. a name of a Role of an Aggregation.
Is there an easier way to locate that name?

28
Automation Interface, Add-Ins and Tools / Re: xmi:id how to?
« on: November 18, 2016, 09:54:47 pm »
Thank you very much for this superb answer, Simon.
The XMI snippet about a Tag export from SysML to XMI looks very promising.
I will investigate it. Do you think I can repeat that in plain UML?
I must say, I have not understood it fully, yet. Could not identify the Tag-name and Tag-value.
One fear of mine: Is XMI spec silent about this? Does it have to be covered by vendor-extension?

29
Automation Interface, Add-Ins and Tools / Re: xmi:id how to?
« on: November 18, 2016, 12:32:30 am »
Hi, Simon

everyone in the UML world knows that XMI like UML is an OMG standard. That is not the point.

XMI uses an xmi:id attribute as a surrogates for each UML element, uniquely. From the XMI standard afaik tool vendors like Sparx may choose their algorithm to find a unique code given to xmi:id in order to uniquely identify a UML element.

XMI is ment to be vendor independent.

I am not sure whether Tags are properly reflected in the XMI exported by EA. I tried to find that in the XMI 2.4.1 spec but without success in the time I could spend for it. Tags are exported by EA solely in the vendor specific part of the XMI albeit they are part of the UML specification. I would expect Tags in the UML part of the EA XMI export, not the vendor specific part - but I am not sure about this, yet.

On import of XMI, in general the EA tool excepts any value for xmi:id attribute, as long as it is unique per UML element. This is imported for XMI interchange.

For this general rule EA import has at least one exception: Tags - in the vendor specific part of the XMI, that is not standardized for exchange. xmi:id attributs in this part - at least for tags - have to follow the Sparx way of unique key generation.

My question is: why violating the requirements for xmi:id attributes in the vendor specific part? And if there is a good reason: am I able to reflect that key generation in my process tools?

Now these questions are rhetorical as I have accepted not to get a sufficient answer - there are proprietary algorithms in the vendor specific part of XMI export.

30
Automation Interface, Add-Ins and Tools / Re: xmi:id how to?
« on: November 15, 2016, 08:43:35 pm »
Yes, thank you qwerty and Simon,

seems my knowledge comes close to what is known.

About the idea not using the API but XMI: I have a dream: XMI holds what is in the model - and - in an openly specified way. My lifecycle tools would work regardless what modelling tool to use. We are getting closer.
And I agree: xmi:id should be a surrogate, unique but without further information.

I did what you said: getting information about the xmi:id from experience exporting packages.

I was wondering whether there is some documentation about it. I could not find any.

Rolf



Pages: 1 [2] 3 4 5