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

Pages: 1 [2] 3 4 ... 85

This is in 13.5, but there's no mention of any relevant changes in the history for 14.

Let's I create a class with an attribute with an initial value.

Let's then say I create both an instance of that class, and another class which is a specialization of the first class.
I switch on presentation of inherited attributes for both the instance and the specialized class.

If I now override the attribute initializer in my specialized class, that overridden value is shown in the local attribute compartment of that class. Good.
But the same change is shown in the inherited attribute compartment. In other words, it now looks like the attribute in the general class has the same initial value as it does in the specialized class -- which it doesn't.

This isn't great, but semantically I suppose you could overlook it: there is only one initial value for any given attribute (since an instance cannot logically be initialized twice), so the presentation of the parent's initializer is more of a convenience. It'd be nice if it was right, but it's not crucial.

But now consider the same situation with an instance with a run state, which exhibits the same behaviour.

In my instance it now looks like the initial value is what I've put into the run state. This is definitely wrong. The initial value is a property of the classifier -- it cannot change with the run state, which is a property of the instance.

Or is there some obscure Jehova's Witness-style mangling of the UML standard that allows for this behaviour?


Bugs and Issues / Artifacts and attributes
« on: June 26, 2018, 08:51:41 pm »
Hi all,

I'm working in 13.5, but there's no mention of any changes to this behaviour in the release history for 14.

The properties dialog for an artifact does not include a "details" page, but the context menus in both the diagram and project browser allow me to open the attributes dialog, which allows me to create attributes in the normal way, with type, scope and initial value.

If I create an instance of this artifact, its type is reported as artifact (not object). In its diagram context menu, under "Features & Properties", there's an item "Override Attribute Initializers." When working with classes, this item does not appear for an instance but for a specialized class.

The same menu item for a class instance instead has the "Set Run State" item. This is what I would expect for an instance of an artifact as well. I can get that if I create an object and set its classifier to the artifact, but not by dropping the artifact onto a diagram -- that forces the creation of an artifact instance.

I should also point out that the "Override Attribute Initializers" item, when selected for an artifact instance, only yields an error message saying that the instance "has no attribute initializers to override." That makes sense if the attributes of artifacts are intended to work like the attributes of classes -- but why have the menu item there in the first place, only to have it flash an error message?

However, the weirdness doesn't end there. If I create another artifact (classifier) and draw a generalization from it to the previous one, the diagram context menu for the specialized artifact does not include the "Override Attribute initializers" item -- there's just the normal "Attributes" item.

If I switch on presentation of inherited attributes, the attributes from the general artifact are shown (with initial values) in both the specialized artifact and in the artifact instance.


1) Artifacts can have attributes.
2) Generalizations can be drawn between artifacts.
3) Attributes are inherited between artifacts connected by a generalization.
4) An artifact's local attributes can be given initial values.
5) Initial values of an artifact's inherited attributes cannot be overridden.
6) An artifact instance, which is itself an artifact, cannot have a run state.
7) An artifact instance, which is itself an object, can have a run state.

Is this by design?


Bugs and Issues / Re: Default connector line style
« on: June 21, 2018, 08:49:27 pm »
Kay, thanks guys.


Bugs and Issues / Default connector line style
« on: June 21, 2018, 05:07:33 pm »
Hi all,

Is there a way to set the default connector line style in a diagram?
Say I want all future connectors to use Tree Style - Vertical, or Orthogonal - Square. Can I set that somewhere?


Bugs and Issues / Re: SysML Activity Diagram Control Flow
« on: June 18, 2018, 05:10:09 pm »
EA has traditionally allowed this anyway, but while reworking functionality for version 14 we decided that it was time to prevent it by default.

Thank you Simon, that will spare me a lot of "There are no Activities on an Activity Diagram!" lectures in the future. :)


Hear hear.


Suggestions and Requests / Package Indicator for Here Be Locks
« on: June 15, 2018, 08:49:28 pm »
Hi all,

User locks are indicated with blue exclamation marks for "locked by me" and red ones for "locked by someone else."
It would be useful to be able to see at any package whether something in it, but not the package itself, is locked by me or (less importantly) by someone else -- all the way up to the root node.

Maybe a smaller exclamation mark, maybe an italic one, maybe a paler one, maybe something else, but having some kind of indication would help a lot.


Bugs and Issues / Re: Files on Sharepoint
« on: June 15, 2018, 05:31:12 pm »
Out of curiosity, and Alin, please don't read this as a workable alternative; what I said in my previous post holds and enterprise deployment means DBMS repositories, but:

An .eap file is basically an Access database with another extension.
When using it tries to create a temporary lock file, which sharepoint doesn't allow.

Does that apply to Firebird (.feap) as well? Or would it be possible to store a Firebird repository in SharePoint?


Bugs and Issues / Re: Files on Sharepoint
« on: June 15, 2018, 05:27:27 pm »
Hello Alin,

SharePoint is the way to go until we get to deploy EA as an Enterprise solution. The long term plan is to go Pro Cloud on premise, but before I get there I have to demonstrate it works...

Unless you're proposing to use external version control and individual project files for each team member (in which case SharePoint wouldn't make much sense anyway), .EAP files are not part of an enterprise deployment. If you don't understand what I mean by "external version control", then that just adds weight to my argument.

Set up a database instead. SQL Server is probably the best choice since you're on a Microsoft platform.

It also seems you're confused about EA's so-called cloud solution. Pro Cloud / WebEA is not a separate type of model repository, it's a different way to access an already existing repository.

In other words, Pro Cloud is not an alternative to an .EAP file. There has to be either an .EAP file or a database behind it. Nothing is stored "in the cloud": models are always located in a repository, and that's either a file or a database.

Go with a database. It is better in all respects than an .EAP file.


Suggestions and Requests / Re: Package Indicator for Baselines
« on: June 14, 2018, 09:58:31 pm »

Bugs and Issues / Re: Project browser auto-side-scroll
« on: June 14, 2018, 08:58:53 pm »
For reference, Ctrl + arrow keys can be used to scroll the project browser, whether or not there is a scroll bar visible.

Be aware though that EA also interprets Ctrl + up/down arrows as "move the selected element up/down within its package".

But I haven't noted any side effects with the Ctrl + left/right arrows, and those are the important ones. (PgUp/PgDn can be used to scroll the project browser vertically anyway.)


Bugs and Issues / Re: Project browser auto-side-scroll
« on: June 14, 2018, 06:59:44 pm »
Thanks guys. I can report the following on 1352.

Some visual styles have a horizontal scrollbar, and others don't.

I tried creating a list of those styles, but it turns out the style-switching function is buggy as all hell and the results are not reliable. In general, more recent styles do not have h-scrollbars, while older ones do -- but changing back and forth might cause it to disappear even in a style that had it a moment ago, and I've also seen double v-scrollbars appear. Funny stuff!

It also turns out that switching to a style does not cause the same behaviour as starting EA with that style set from last time.
So if you start with the Office XP style there's no auto-scroll, but if you've switched to it from another style that has auto-scroll it's there.

That works in reverse too. Start up in Office XP and switch to Studio 2013 -- no h-scrollbar, no auto-scroll.

So one of the bugs appears to be that the auto-scroll behaviour is not (re)set when changing visual styles. It's only set during startup.

Which means this is actually a have-the-cake-and-eat-it-too kind of bug that allows you to select auto-scroll separately from the visual style.

Since I find the auto-scroll so incredibly annoying, I think it should be selectable in the Visual Style dialog.
Failing that, that particular bug should not be fixed but be allowed to remain as a workaround.


Bugs and Issues / Project browser auto-side-scroll
« on: June 14, 2018, 01:16:20 am »
Hey all,

13.5 on Windows 10, the auto-side-scrolling project browser is driving me up the freakin post. For a project with more depth and/or longer names than some trivial Mickey-Mouse example it's worse than useless.

Not sure if this is EA's fault or some Windows bullsh*t but it doesn't really matter. Point is, is there a way to switch it off?
Only remedy I've found is to widen the window till it covers half the screen. Meaning I can't see the diagrams.


General Board / Re: different sets of Default Types
« on: June 13, 2018, 07:17:10 pm »
Hej Rolf,

I think I was wrong before, or maybe I was still looking at version 11. In 13.5 it's a bit better, though not quite there.

If you create an activity parameter, you must open the properties dialog for the parameter in order to access its Language property.
If you set it, the Type dropdown will contain the appropriate set of types -- but only if you open the dialog with the Language already set. If you change the Language and click Apply, the dropdown still contains the types from the old language.

For action pins, however, it still doesn't work. The Language property is not honoured.

But those are bugs. Using the Language property is the proper way to customize the set of available types, so provided the bugs are fixed you should be able to do what you want.

I've also checked, and the Language property is set correctly for activity parameters and action pins if you change the language with "Code Engineering -- Reset Options for This Package". That might help speed things up as far as activity parameters are concerned.

Operation parameters also obey the Language property (of the interface, there's no separate property for operations or their parameters).



General Board / Re: unchecked "Show Namespace" as default?
« on: June 13, 2018, 06:58:51 pm »

It appears that's not one of the properties you can set when defining your own diagram type, and I'm not aware of a tool option or project setting to do it either.

So looks like "no".



There's no property you can check to find a package's (or element's) depth, so the simple way is to write a subroutine in whatever language you're using that calculates it.


Pages: 1 [2] 3 4 ... 85