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 ... 24 25 [26] 27 28 ... 50
Bugs and Issues / Re: V13 State Machine Fork/Join Z-Order problem
« on: October 12, 2016, 07:33:49 pm »
Issue is confirmed by Sparx.
I personally hope that next build have it fixed.

Hi Simon,
Yes, I understand that.

Anyhow, I assume that you (Sparx) have some kind of possibilities to influence the UML spec.

I would be happy if you would try to get an “OR” in the spec.

I personally think it is a weak kind of specification, when it leads to  “What you see is either xxx or yyy.

Bugs and Issues / Re: V13 State Machine Fork/Join Z-Order problem
« on: October 11, 2016, 05:21:44 pm »
The issue is under review with reference number: 16104697

Bugs and Issues / Re: V13 State Machine Fork/Join Z-Order problem
« on: October 11, 2016, 03:13:07 am »
Yes, I created a "Registered Bug Report".

Bugs and Issues / V13 State Machine Fork/Join Z-Order problem
« on: October 11, 2016, 02:50:31 am »
I have a state machine created with V12.

Within that state machine I have a state ( top level state) containing concurrent sub states. Within the top level state I have Forks/Joins.

These Forks/Joins are visible in V12 but not visible in V13.

Moving the Z-order of the top level state to bottom makes the Forks/Joins visible in V13 as those are visible in V12.

However when closing and opening the diagram the  Fork/Joins are not visible again.

Ok, I had a look to the specification and indeed now EA conforms to UML 2.5.

However I think the old  EA implementation was better than now complying to the Spec..

Because former it was easy possible to call Activities e.g. twice and differentiate by name, still seeing that it is the same thing you are calling.
Now you have to do that somehow else.

Even more strange, according UML 2.5. for Call Operation Actions it is still possible to do what is mentioned above.

Yes, there is something wrong in V13.
When you have a “Call behavior” with no name the called activity name is shown as name rather than as call classifier. Once you add a name to your action that name is shown and the name of the called activities disappears.
I will initiate a bug report, because for me that is a V13 showstopper.

As already stated somewhere in the form, I have several use cases for using the decision table feature, but for me it is useless just because of the “very primitive” implementation.

As I remember it is even not possible to rearrange things, apart of deleting and adding anew.

I cannot imagine who gets value from that feature with the current implementation.

General Board / Re: Scope of specification manager
« on: October 10, 2016, 07:39:05 pm »
If that works for you, fine!

But keep in might that this is more to view/look on things rather than specifying things.

General Board / Re: Scope of specification manager
« on: October 08, 2016, 04:35:10 am »
AFAIK there is unfortunately no feature to do such things, expect doing an sql select.
However there is the RaQuest plugin providing such a feature (not sure if you can edit tags).

I do not really know the Archimate 2 implementation, but from what you describe it is pretty clear that Archimate 2 impementation “overwrites” the UML Object by the stereotype “ArchiMate_DataObject”, and one part of this “overwrite” is to overwrite the presentation features (how the object can looks like on a diagram) with a sharp script.

By removing the “ArchiMate_DataObject”  stereotype you convert your ArchiMate object to a UML object.
So either Archimate or the Sparx Archimate implementation does not satisfy your needs.

I do not say, that what you have done is bad, but your model is now not a pure Archimate model but a mixture between Archimate and UML.

What feature can be shown on a Diagram depend mainly on two things.

-The “basic” type of the element, and
-If the element is expanded by a stereotype

So to get help, you need to state what your concrete element is.

Expanding elements typically lead to additional features. And one of this feature could be, that how the elements look on a diagram is changes. This is done by a shape script.

In you case you are talking about Archimate Profil what for sure includes lots of expansions and might have shape scripts as well.

Hallo Paolo,
Yes, I use the features within Package Control.

I just have one root and two “EA-views” underneath, so what you have mentions is not a problem for my. If so, I would thing about to solve that problem with a script.

Another possibility I have in mind, is defining an “edit group” and assigning it to any user who is allowed to update some stuff, so I could just disable the update stuff in this group.
Both approaches I have not jet tested to be reliable, so there might be problems that these changes are only active when users reload the project or even restart EA, or maybe the script engine is ignored in those security features,….

Currently your “brute force” way, I could do as well. But the day will come when my IT will disallow me such “critical” things.

Another way I have in mind, is providing only Cloud Service access to the users. By doing so, I could lock out users by the Cloud Service (setting passwords, stop cloud server, …). Another advantage of that would be, that I would not need to give users write access to the DB. This would work fine I assume, if all EA features could be used over the cloud service.

Currently I lock the stuff as user (me), but honestly I have not jet investigated if this is reliable enough.

Here is the response from Sparx about my “One SQL select transaction” question.

“The data is read over time.”

So from my point of view, it is very recommended lock out the users with write access when doing long transfer, baseline, import/export stuff.

Pages: 1 ... 24 25 [26] 27 28 ... 50