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 ... 85
1
General Board / Re: Is EA v 14 ready for Enterprise use?
« on: Today at 08:54:33 pm »
Hej Steen,

I haven't evaluated the 14.1 beta that dropped earlier this week, but I noticed that it lists this feature:
  • Added option to automatically maintain the list of available users based on Windows Active Directory or OpenID groups
That, to me, is a huge step in the right direction for EA-in-the-Enterprise. Any enterprise solution has to be integratable into and manageable within the prevalent enterprise standards -- that's pretty much what the term means.

The fact that they use a proprietary licensing solution remains a problem, but if they make it possible to manage project access control using standard tools only, that's really encouraging.


/Uffe

2
Hi Nick,

eaDocx might be worth checking out, they might be able to do something along those lines.

/Uffe

3
Hej!

I want to centrally disable a lot of these and set one of them as the active one. (preferably not for a specific model but for all clients)

There's no way to do that within EA. Nizam's suggestion should work, but you need a way of managing the registry on the individual client machines. Just setting it up during installation won't prevent users from changing the set of MDG Technologies, so maybe create a launcher that sets up the registry and then starts EA.

Within EA, you can only specify MDG Technologies per project. But if you create your own base project and set the MDG Technologies you want in that, that should work.
A base project can be deployed as a resource that you tell users to use when starting a new project, or you can distribute it and overwrite the one (strictly speaking there are two, one .eap and one .feap) in the EA installation directory.

HTH,


/Uffe

4
Yeah, what I thought.

Thanks,

/U

5
Hello Ravi, and welcome to the forum.

Please note that while Sparx staff are pretty active on the forum, most of us are regular users. So this is not an official support channel (those are available in the Support menu up top), although I'd say for usage questions like this one it's probably the better option. There are more of us than there are of them. :)

Strictly speaking, element creation from toolbox is not drag-and-drop but select-and-place. You click the element type (and release the mouse button), move the pointer into the diagram and click again to place the element. Between the two clicks, the element type is highlighted in the toolbox and the pointer switches to the create-element shape (while in a diagram).

Creating a connector from the toolbox starts with the same select-and-place in that you select the connector type (which is highlighted), then click the source element, but you then drag to the target element.
If you omit the drag and just click one element while in connector creation mode, you get a connector whose source and target are the same element.
If you drag to an empty area of the diagram and release, you are presented with a menu of element types. Selecting one of these causes EA to create the connector and for its target a new element of the selected type.

If you drop the connector on the wrong element, you can move a connector end (either one) by selecting the connector, moving the pointer to the spot where the connector meets the element (the pointer changes to an up-right arrow), and then click-and-dragging to the correct element.

HTH,


/Uffe

6
Hi all,

Is there a way to access constraints in an Element shape script?
The manual only lists constraint properties for connector scripts, and there's nothing on the query page that seems to refer to constraints.

TIA,


/Uffe

7
Suggestions and Requests / Re: Silent install based on list of keys?
« on: August 06, 2018, 09:45:27 pm »
Hello,


I'm thinking no.

The actual license information checked by EA is stored in the file key.dat in the user's \AppData\Roaming\Sparx Systems\EA directory. (This is the case for floating licenses, and I assume for fixed licenses as well.)

However, the contents of this file is not the license key you've received, but something else which EA generates based on that key. So in order to do a silent install for 100 clients, you'd need to create and distribute 100 individual files.

In addition to being impractical, there's no support for generating these files in EA's license management client. You could enter your 100 license keys one by one into one EA installation and copy the resulting key.dat files out, but if key.dat incorporates some user or machine identity (and only Sparx knows whether it does), these files won't work on other machines / for other users.

So I don't think you can do this. New users will simply have to enter their keys manually. On the plus side, with fixed licenses they only have to do this once.


/Uffe

8
General Board / Re: Help - UML Types and shapescripts ...
« on: August 02, 2018, 06:36:55 pm »
t_object.BorderStyle is the most crucial one, and there's no attribute for it in Element. This probably means you have to write directly to the database. There's also a (slim) chance it can be set through some attribute in DiagramObject, but I think that's unlikely. Again, if you find a way to do it without invoking the dreaded Repository.Execute(), let us know.
I think I might pass - I'm trying really hard to avoid custom scripting and direct database manipulation as it is not sustainable (without building an operational support capability around the use of the tool within the organisation)
Well, arguably you've already crossed that threshold if you're doing shape scripts. But I hear what you're saying, and crossing a threshold is not the same as taking up residence.

/U

9
General Board / Re: Help - UML Types and shapescripts ...
« on: August 02, 2018, 12:47:30 am »
2) Is there a way with boundaries to set the "Boundary Style", from the default of "Solid - No Fill" to "Solid"?

Why, yes there is. Strap in.


It's all a bit complicated. By the looks of things, the functionality to deal with boundaries has been not so much designed from scratch as patched and added to in several phases.

The Shape and Style properties are actually split between t_object and t_diagramobjects. This kinda works because boundaries are diagram-only elements, meaning they're not shown in the project browser and there is a one-to-one relationship between the t_object row and the corresponding one in t_diagramobjects.

One-to-one, I said, and by that I mean almost: it is quite possible to copy/paste diagram-only elements between diagrams, resulting in two t_diagramobjects rows referencing the same t_object one. How exactly that affects the contents of the two tables is not something I've gone into.

So. Disregarding that special case, here's how a boundary's properties are stored.

Before we move on, I should say that I haven't found anything relevant in t_object.NType, t_object.PDATAn or t_xref. But it's always possible that I've missed something.

There are three columns of interest: t_object.BorderStyle, t_object.StyleEx and t_diagramobjects.ObjectStyle. Their use is not quite consistent, as I alluded to above. In addition, t_object.Backcolor holds the background colour.

Boundaries with Shape Rectangle only use t_object.BorderStyle. This is likely because way back when boundaries were first implemented, there were no other possible shapes (and therefore no Shape attribute as such). Thus only the Style property is represented.

Shape Rectangle
Style (t_object.BorderStyles):
    0  =  Solid
    1  =  Dotted
    2  =  Dashed
    3  =  Solid - No Fill


For boundaries with other shapes, t_diagramobjects.ObjectStyle comes into play to hold the Shape property. The Style is still in t_object.BorderStyle, but now with a different set of values.

t_diagramobjects.ObjectStyle is a string containing a set of properties expressed as key=value pairs, each terminated by a semicolon. The order of these pairs does not appear to be significant. (There is always the "instance GUID", or DUID, which appears as 'DUID=xxxxxxxx;', where xxxxxxxx is an eight-digit hex number, but it appears in different positions in the list for different rows.)

Shape Rounded Rectangle, Ellipse and User Defined
Style (t_object.BorderStyles):
    4  =  Solid
    5  =  Dotted
    6  =  Dashed
    7  =  Solid - No Fill

Shape (t_diagramobjects.ObjectStyle):
    "shape=rounded;"    =  Rounded Rectangle
    "shape=ellipse;"    =  Ellipse
    "shape=freestyle;"  =  User Defined


User-defined shapes adds the last little wrinkle. They have a t_diagramobjects.ObjectStyle property 'LBL' which controls the label (and whose value is a sub-list of key=value pairs, separated by colons). I won't go into any details for this here, just note that it is created automatically for user-defined shape boundaries which means you may have to create it too if you plan to create user-defined boundaries through the API (but probably not).

User-defined shapes also get a key=value property 'Path' in t_object.StyleEx. This also contains a sub-list, a '@'-separated one of ':'-separated X/Y-coordinates. You probably do have to populate this in order to create a user-defined boundary through the API. For a rectangle, this will be something like Path=20:-398@143:-398@143:-498@20:-498;

I haven't been able to change the number of co-ordinates through the GUI, but it seems to me like it should be possible to create any polygonal shape by setting this property through the API. if you try it, please let us know how you did.


Finally, the background colour. This isn't quite consistent either, but at least it's stored in just one place: t_object.Backcolor holds a signed integer whose value is either -1 for the default colour, or an eight-bit RGB value. When accessing the data from an Intel machine, the order of bytes from most to least significant is Blue, Green, Red.

Note that the background color is handled differently for different shapes and styles. For user-defined shapes, the background colour is only used for the Solid style. For all predefined shapes, the background is only not used for the Solid - No Fill style.

The default colour also varies. For predefined shapes with style Solid (three in total), one colour is used, but all other combinations of shape and style use another one (although strictly speaking, Solid - No Fill shapes never use the fill colour). In my tests, these were pale yellow and white, respectively, but it may be controlled by the theme.


Since I haven't written any code to test this stuff, I'm not sure how to set all these properties through the API.

t_object.StyleEx is simple enough, that's just the Element.StyleEx attribute. But you only need this for user-defined shapes.

t_diagramobjects.ObjectStyle is probably DiagramObject.Style -- there's no "Style" column in t_diagramobjects and the API documentation says that this attribute is a "semi-colon delimited string" so they probably match -- although you may note that the DUID, which is stored in t_diagramobjects.ObjectStyle, has its own attribute DiagramObject.InstanceGUID.

t_object.BorderStyle is the most crucial one, and there's no attribute for it in Element. This probably means you have to write directly to the database. There's also a (slim) chance it can be set through some attribute in DiagramObject, but I think that's unlikely. Again, if you find a way to do it without invoking the dreaded Repository.Execute(), let us know.

Update -->
I forgot the background colour. That at least is straightforward: either set the DiagramObject.BackgroundColor attribute, or call the Element.SetAppearance() method.
<--

HTH,


/Uffe

10
General Board / Re: How to distribute My Queries?
« on: June 27, 2018, 08:46:48 pm »
Hi Rolf,

Searches are stored locally in the file system as you've found. What you can do is create an MDG Technology, which in turn can be either deployed to a file share or imported into a project.

The MDG Technology generation process is pretty straightforward -- just click through the wizard. It's a good idea to spend a little time thinking about the name and ID, and deployment, but the generation itself is a matter of seconds.

HTH,


/Uffe

11
General Board / Re: Advice - to nest or to compose ?
« on: June 27, 2018, 06:42:30 pm »
Hello Matthew,


It does also depend on what you want to show in your diagrams.

If it's just the structural relationship itself, then I'd go with a composition connector. It's the simplest way, and you can easily see the relationship from the property dialog of either component, and follow it with the Traceability window.

But if you nest them in the project browser then the nesting component becomes part of the nested component's namespace. If that's something you want to show.

Another option is to create a separate component for the nested component, and in the nesting component create a property / part with the other component as its classifier. This way only the property / part gets nested, and the two components are independent of one another.
In development terms, this approach is suitable for something like a statically linked library, which has properties of its own (assigned to the classifier) and is used in several executables.


/Uffe

12
Hello,


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?


/Uffe

13
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.

So.

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?


/Uffe

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

/U

15
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?

/Uffe

Pages: [1] 2 3 ... 85