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 - Paolo F Cantoni

Pages: 1 ... 3 4 [5] 6 7 ... 403
Bugs and Issues / v14 Beta: Workspaces vs My Workspaces
« on: March 19, 2018, 05:12:41 pm »
It is an axiom of natural language processing that an unqualified noun includes all the subtypes.

Consequently, having two tabs on the Start | View | Workspace | Select a Workspace page named, Workspaces and My Workspaces is incorrect.

The Workspaces tab lists only workspaces, the My Workspaces tab lists my Custom workspaces and (in this case) the BABOK technology workspace - which is NOT one of my and smells more like a system than a personal workspace.

Perhaps General Workspaces and My Workspaces (with Technology Workspaces in General)?


Thanks, Nizam,

Just the shot!

As we say here in OZ:  "just like a bought one!"

Thanks again,

[EDIT: my experimentation suggests you can only set ONE _subtypeProperty (seems logical); but is that actually so?]

As I've mentioned, we "hand roll" our MDG.  Don't ask...  However, before I go down a spurious track (and waste a PILE of effort), I'd like to confirm that I can theoretically do the following...

We have a number of components that are very similar.  At present, each has it's own metatype (to make it easy for the modeller to select the one they want to drag off the toolbox).  But, in fact, they are pretty much the same metatype but with a specific property set to an enumerated value.  The property can be a tagged value.  What I'd like to be able to do is have one metatype on the toolbox and as the modeller drags it off the toolbox, it asks which "subtype" it is (using the hidden menu) and sets the tagged value appropriately.  I realise I can do it with scripts and events, but I'm after a declarative solution if possible.  Our shape script (for the metatype) can then respond to the tagged value.


General Board / Re: EA refuses to show diagrams
« on: March 14, 2018, 10:49:17 am »
Do you have any more details on your environment. I'm guessing you are using an eap file for the repository and maybe its on a shared drive that is accessed over the network. If that guess is correct you may be suffering from a delay/lag over the network. If its a local Hard Disk maybe the disk has some errors and slowing down access.
Just some thoughts there you could investigate.

FYI - I've got a SQL repository which I transfer to eap for snapshots for time to time for testing jscripts etc. I use the file on a local SSD drive and is 880Mb in size so significantly bigger than yours and I don't have those issues with diagrams.

Hope that helps in some way.
Same here. Our .eap (snapshot) is also in the 700+ Mb range (after compacting) and no major problem with diagrams - although as mentioned in another topic - we have UPGRADED to Jetv4.  Jet 3.x had problems with large files.  If you haven't already, try compacting the file.


Thanks Geert,

apologises for getting you name wrong the first time... I've yet to make them appear in my document am assuming there is a flag that needs to be set somewhere to ensure they are included?

Hi Al, you should still be able to go back and fix it with the [Modify] button at top right.


Bugs and Issues / Re: Slow import of large codebase
« on: March 13, 2018, 12:02:19 pm »
100k classes sounds like a monster. Alas, rather than using a Mickeymouse (aka MS Access) database for a monster you should use a real RDBMS instead.

While I agree with qwerty I don't think it will help all too much with the performance though.
My best bet would be to use a local instance of MySQL for optimal performance.

And if you can't do that, upgrade your EA to use Jet4 (See [Ctrl+F9] General Page) or SQL Server Express.


The bug has been confirmed by Sparx.

While we're here in Label land, the whole Label processing via shape scripts is broken.  The print function will wrap regardless; after some arbitrary length, not (apparently) related to the size of the containing shape.  The printwrapped function will wrap but not (apparently) related to the size of the containing shape!  You can resize the label so it wraps correctly, but the next reload of the diagram restores the arbitrary behaviour.

The definition of printwrapped is:
"Prints the specified text string, wrapped over multiple lines if the text is wider than its containing shape."
Nowhere does it say that the wrap has to be within the boundaries of its containing shape.  So I guess it works as intended on planet Sparx.

So MUCH time gets wasted trying to get around these weird and wonderful functionalities!


Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.

It isn't, and you can't. The model introduced in v14 is strictly hierarchical, meaning you can't set one part of a project up to be visible to team A only, and another to team B only. If team A should not be able to read team B's area you can achieve that by giving team B higher privileges, but that means they will also be able to ream team A's area.

So that fell over right out of the gate, I'm sorry to say.

Now that you remind me I think I came to the same conclusion (on reading the proposal).  I'll need to do more checking.  I'm sure the V14 security model is useful for someone.  Perhaps they could raise their hand?


Interesting proposal, Uffe.

However, notwithstanding EA's UI, the ONLY thing EA knows about the attached diagram is that it is attached to the Parent object.  We use that fact to hijack the linkage for our Neighborhood diagrams.  Consequently, how can you tell it's a composite structure diagram?  In my MDG, the usual markers may not apply...


PS: Our Neighborhood diagrams bump into the same problem.  But that's because we haven't written the code to place the parent object on the diagram.  Like Sparx bug fixes, it will come sometime before the end of the universe...   ;)

Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.

I still wouldn't use the same repository in that instance.  I've seen several instances of personal grievances claims made against an employer when staff felt they were not being consulted about restructuring.  If you keep the "pie in the sky" "what if" process modelling in a separate database to the "production" repository it is completely clear that the models are not in any official or approved.
Understand your point, but we use status and other codes and Sandboxes for that (blue sky stuff).  I'm not sure having separate repositories changes the semantics (nor would hold up in court).  It does, however, better ensure that if you can't get to it, you can't get to it.


As far as 1..1 (1) relationships, they need to be confirmed but aren't, prima facie, wrong.  Incorrect 1..1 associations are a common newbie, mistake, but we are usually cured of that pretty quickly.

I try to tell my wife that, but will she listen?
My bad I think I meant 1:1 relationships...  ;)  1..1 is the directional multiplicity.  No wonder your wife is confused...   :-[  [1..1:1..1] => [1:1]

Bugs and Issues / Even the first setting isn't in the right place!
« on: March 12, 2018, 12:13:35 pm »
We've noticed that the label isn't even placed correctly on change of value (like while we were debugging).  It needs a diagram reload to get it to the correct (specified) location.

EAUI+ guys!

It isn't rocket science!  Most frustrating for our users!


In almost all cases I've seen the single repository setup was to be preferred.

The case where it is not is if your organisation is going to perform a significant process re-engineering which might result in job losses.  In this case, it is best to clone your process models into a new repository with access only given to those staff working on the re-engineering.  This also allows the what-if models to be flushed away when the modelling is over.

Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.



I am curious what would total participation look like in Crow's Feet (I.E.) notation?  Or what would a SQL DDL code for total participation look like?

If it's 1:1 as suggested in previous post, it's certainly possible to do with EA but 1:1 is usually a sign of a problem in the data model... probably semantic mistakes or treating an attribute as if it was an entity, or using 2 entities where 1 would be enough.  I'm curious to know... thanks!
In our modelling environment, we've gone for crow's feet notation for ALL our Association related (or based) relationships.  We believe it best renders the relationship between the instances of the classifiers.  We even developed a mechanism for highlighting unconventional relationships (in Sharia law countries, a man may have 0..4 wives).

As far as 1:1  relationships, they need to be confirmed but aren't, prima facie, wrong.  Incorrect 1:1 associations are a common newbie, mistake, but we are usually cured of that pretty quickly.


[Edit: corrected 1..1 to 1:1

I prefer diagram-only elements or non-browser elements.

Since object is, in fact, an element type, I always avoid using that word to describe anything else.

Element also has another meaning in UML. Almost anything in UML is an Element (except for diagram, tagged values, and maybe a few other things), but they are not all stored in t_object.

So I prefer the more neutral Item as a term.

You may have noticed (apart from my deviation previously) that I've started using item also.  Item defines an identifiable member of a set; which describes the situation exactly.  It is a natural language definition, irrespective of any modelling language.


Pages: 1 ... 3 4 [5] 6 7 ... 403