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

Pages: [1] 2 3 ... 55
Bugs and Issues / Re: SABOEAB
« on: October 17, 2019, 08:36:00 pm »
I had build 1512 stop working several times see here:,43327.0.html
For whatever reason this problem stopped after a few days working with build 1512, but then I had other dialogues which I could not close. It is sporadic so I cannot reproduce
Unfortunately, Sparx QA seems to miss the goals they should have. Several changes might have a positive intention but a bad result (like the senseless and even inconsistent element drag/drop hopping introduced in build 1512).
Years ago I just updated to a new version and I was happy. Now each time I first have to look if the new version does not too much destroy my diagrams, due to changes in rendering, before I search for all the other surprises.
In my dreams Sparx pays the users each time, the users find a bug and they pay more if the bug is not fixed in time X, to get QA alive. ;)

General Board / Re: SysML Block Operation and Action Allocation
« on: October 15, 2019, 10:21:15 pm »
Well, if you use things like operations, receptions, or classifier Behaviour the coupling between structure and behaviour is strong/fixed.
If you use allocation the coupling is weaker and you can have many different behaviour of the same structure.
Example: You can have processor like a intel core and you can allocate linux or windows on it. The processor is not fix coupled to windows only.

General Board / Re: Silent install and configuration of client
« on: October 11, 2019, 12:50:56 am »
I am sure it did. However once you have done and you install a new build on the same machine you are not asked anymore. You have to consider as well that the key expires somehow.

To by honest I do not see any reason and purpose wy this key is needed.

General Board / Re: Silent install and configuration of client
« on: October 10, 2019, 11:41:44 pm »
Yes it is bad  :'( :'( :'( :'( :'(

Go to the docked properties window and select the tab “Trigger”.

Go to the docked properties window and select the tab “Condition”.

Bugs and Issues / Activity Parameter Direction and Action Pin Kind
« on: October 10, 2019, 11:36:50 pm »
Any idea why an activity parameter can have a direction inout/return but an action pin can only have input or output?

General Board / Re: Prevent accidental deletes of elements
« on: October 08, 2019, 01:43:05 am »
You could apply locks.

Hi Geert,
you are right, Sparx seem to think somehow in this direction!

However, even if so, with my diagram drag/drop procedure the action is still on many diagrams, owned by different activities. So the implementation is a bug anyway.

From my interpretation of the standard, I would say:
1) An action should be owned only by one activity
2) No action should have a kind of flow to other activity nodes not owned by its own owner
3) An action can have dependency links to actions not owned by its owner
4) !!!And!!! An action can be shown on an activity diagram or any other kind of diagram not owned by its owner

The last one I derive from this part of the standard:
„NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not
preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral
elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the
various kinds of diagram types are not strictly enforced.“
Or see here:

I have the feeling that Sparx tries to be more UML compliant, what is in principle not a bad thing, but they overshoot somehow.
With the new Sparx implementation it is really hard and might get impossible in future to visualize cross-cutting relationships, and this would be very bad.

No, what I mean has nothing to do with pools/lanes/swim lanes!

When you add an element from the toolbox to a diagram, it gets typically located under the parent of the diagram. This is a solution which fits to most cases I have.

If you add an element to any diagram from the project browser in the very most cases it remains on its project browser location. This is a solution which fits to most cases I have as well.

Before current version(s!), when you dragged and drop an element from on diagram to another and selecting “Create Link on this Diagram”, the element typically remained on its original location. What was good!

Now in current version(s!) when you dragged and drop an element from on diagram to another and selecting “Create Link on this Diagram” several types of elements are relocated to the parent of the dropped diagram.

I have several scenarios where this is bad.

Exapmle: In activity diagrams I frequently use a send signal action in one activity diagram and several accept event actions in other diagram.
To get a glue where a signal comes from what is “accepted “, I connect the send/accept actions with trace links and to visualize that link, I drag and drop the send action to the activity diagram having the accept event action.
Before V14 I put the send signal action outside of the activity diagram boarder frame, to clearly mark that it is a kind of visual reference and does not belong the activity. Unfortunately since V14 it is not allowed to have thing outside of the diagram frame anymore.

Anyhow, now when I drag e.g. an action from the project browser to an activity diagram it remains on its browser location and if I do a “Create Link on this Diagram” it jump.
For some (not all) other element types I saw the same. Why on earth, an element what is in !!!addition!!! shown on the second diagram has to move its location anyway? And why only when I fetch the element from a diagram rather than from the project browser?

This behaviour is quiet illogical and annoying.

I realized that now, when you drag and drop an element from one diagram to another, the element is relocated under the assumptions that the element should have the same place as if it was created on the diagram.
However, if you want to show the element on several diagrams by creating the drag and drop link, this new (at least for me bad feature) causes the element to jump around within the repository each time you put it to an additional diagram.

Bugs and Issues / Re: Build 1512 seem to have serious bugs
« on: September 30, 2019, 09:00:46 pm »
Here is some additional feedback.
2) I have not seen that any more so far. However I am quite sure that it was not a scrolling thing, because I missed the head and not the tail.

1) I see very frequently. It is not really related to signal assignment to triggers. It is about the “Unsaved Property Changes” dialog which appears most times (but not always!?) when you changed a property after you select something else. When you do some of this property changes it takes not to long time and neither “Yes” not “No” nor “X” closes that dialog. After pressing several time on those controls, the dialog is closed,  but EA does not carry out any command after that.
A bug report I will send today.

Bugs and Issues / Build 1512 seem to have serious bugs
« on: September 26, 2019, 01:26:48 am »
Just working 5 minutes with build 1512 I had two strange issues.

1)   After assigned a signal to my second trigger a signal, I got the message box that the trigger has changes. However both OK and Cancel opend the message box again. After clicking around several times the message box was gone closed but EA as well (just frozen). With my first trigger I did not have that problem?!
2)   One of my diagram tabs do not show the name of the diagram but only the last two letters of the name.

Just finding those things in this shore time let me fear that the 1512 buld might have much more surprises or;
 I am the world best tester. ;)

General Board / Re: Can I exclude ports from report generation?
« on: September 06, 2019, 11:24:31 pm »
Assuming that you are talking about elements and not diagrams, you should be able do that with template selectors e.g. by caling a template for ports doing nothing.

In general this example diagram looks a bit strange to me, because the IDB seem to have blocks rather than parts.

Ignoring that fact, SysML allow connecting parts without ports. Not using ports to connect part1 with part 2 means part1 is connected somehow to part2 but I do not tell you how or I do not know how.

If the two parts are connect with ports having classifiers, it means part1 is connected with part1 port and the details are defined in the part1 port classifier to part2 with the part2 port and the details are defined in the part2 port classifier.

If they had added the counterpart ports to the CAN_Bus as well, it would make clear that there is a one to one relationship between ports.

Without those ports, you are allowed to implement that one to one relationship, or you are allowed to implement a one to one relationship ports within a super port, or you are allowed to implement a super port which can handle all ports connected to CAN_Bus in common.

In other words, yes there is a semantical difference.

Pages: [1] 2 3 ... 55