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 ... 124
Hi Paolo,

Can a user update the external item or just view it?  The documentation on the website would suggest only viewing is possile.

According to the API documentation, the SBPI has only very limited create/update functionality so you couldn't make any meaningful changes to an external repository this way.
That assumes, of course, that the PCS actually uses the SBPI and not some unholy hidden API.


Vertex Type + Profile Stereotype = Profile Metatype.  Can't get simpler than that!  If you're going to put the metatype on the Type column in the Project Search, it's a straight mapping, no?

Well, it's pretty clear that EA doesn't use an internal metamodel. Or at least if it is, it's not the UML metamodel.
In fairness, UML itself has been changing a fair bit over the years and the MOF didn't even exist when EA was first designed cobbled together.

Also, as to this (problematic) idea that all MDG Technologies shall be available but only loaded when required.

Yeah. It's all sorts of weird. Again, it's pretty clear EA isn't so much engineered as hacked.
All these variations on the theme of which technologies are used and which not is a prime example of what I was on about the other day where the same functionality is implemented multiple times that don't work together (and quite possibly not even each on their own either).

Unfortunately, while it's fun to do a deep dive every once in a while and try to work out how stuff actually works doesn't work, it's an exercise in futility because there is no way of telling how long the results will be valid. Which, also on a topic I was recently on, makes it less rewarding for the community to actually pitch in and help make the whole EA experience better.


Oh man you guys, you're right. Except it's even worse. The Object_Type returned in a query changes with... Hell, I don't know. Barometric pressure?

But try this.
  • Create a new project.
  • Create a Data Modeling diagram, and create a table in it.
  • Exit EA.
  • Start EA again and open the project.
  • Without opening the package with the table in it, run select * from t_object
    Note that you get Object_Type = 'Class'.
  • Open the diagram, or reload the package containing it. Rerun the query.
    Ta-daa! You now get Object_Type = 'Table'.
Reloading the project resets the reported Object_Type to 'Class'. Yay - consistency!

I think, and this is the purest speculation, that MDG technologies only get loaded when needed. So EA only loads the technology containing the EAUML profile once you expand a package, or open a diagram, containing a table. And the smarts that translate, or shall we say obfuscate, the Object_Type are part of the technology.
So while the technology isnt loaded, tables are reported as 'Class'. Once the technology is loaded, they instead become 'Table'.

Buuut at the end of the day, the point is that CSV exports must include the Profile Metatype (or possibly the Fully Qualified Stereotype is sufficient) or elements with profile-defined metatypes won't import right.

Too bad much of what you wrote is absent from the Sparx Documentation, especially the Profile 'influence'.
Yeah, that kinda sucks. It looks like they gave up on supplying user documentation years ago and just started copy-pasting the marketing blurbs into the manual. But that's why there's a forum. :)


Bugs and Issues / Re: EA Viewer crashes after connecting to SQL Server
« on: January 08, 2021, 02:53:37 am »

Don't take this as official, but it appears that the viewer is being quietly phased out. Its latest version is 14.1, which is now almost two years old, not to mention one major and two minor versions behind the full client. In the interim there have been non-backwards-compatible changes to the project database schema as well as to login procedures when connecting to a security-enabled project, so I would not expect the viewer to work.

The last time an issue was raised relating to it on this forum the response from Sparx was first to suggest all users use a fully licensed client instead of the viewer, and then:
In case you haven't noticed, PCS, WebEA, and Prolaborate are being pushed by us as a preferred reader method over EA lite. It will have a different UI, but a much simpler one. It also doesn't require any install for on the client machines. Of course it's still not free.
(EA Lite is the older name for the EA Viewer.)

So best advice, don't waste time trying to get the viewer to work. Bite the bullet and pony up for another license.



Hey guys,

I did a bit of a dive on this. Find something to hold on to, and make sure you've got some paracetamol to hand.

Object_Type = "Table" is definitely wrong.
Well... For a given value of "definitely", perhaps. But this. Is. EA!!! (cue Gerard Butler)

It is, in fact, the Class/«table» elements that are wrong. The correct representation is Table/«table».

You can test this very easily (this is on 1557).
If you create a table in a Data Modeling diagram, the element gets Object_Type "Table" and stereotype «table».
If you import a schema from a DBMS, again you get Table/«table» (and View/«view»).
Whether this is something that's been changed recently I can't say. I did a quick check of the histories and there's nothing that indicates that it has, but it is possible.

Now, as I understand it the t_object.Object_Type is the same as EA.Element.Type, or am I missing something?
You are. The profile-defined metatype.

Element.Type is sort of the UML base type. The API documentation lists the valid contents, and you'll note Table isn't in there but Class is.
t_object.Object_Type, on the other hand, holds the metatype if there is one and the base type only if there isn't. In this case, the metatype is Table, as you can see in the corresponding Element.Metatype attribute.

Now I say that Element.Type is a "sort of" base type, and unfortunately that's because this is pretty sloppily defined. Again, if you refer to the API documentation you'll see that it's not just UML base types in there (Activity, Class, Component...) but also some of EA's core extensions such as GUIElement, Issue and Requirement.

EA's representation of a database table, however, is not a separate element type in the core extensions, but a profile-defined metatype.

There are essentially four categories of element type in EA:
  • Types defined in the UML standard;
  • Types defined as their own element types in EA (Requirement);
  • Types defined with their own metatypes in Sparx-supplied profiles (Table), which get special treatment in the GUI and various functions (more below);
  • Types defined with their own metatypes in third-party profiles, which don't get special treatment.
I don't think that EA actually differentiates between categories 1 and 2. They're just what we might call built-in types, and what's listed under the Type attribute in the Element API documentation is the sum total.
Telling categories 1/2 and 3 apart can be very difficult, and again, I don't know of any documentation that clarifies it other than that list.

The in-project representation gets a little tricky because there is no "Metatype" column in t_object. There's .Object_Type and .Stereotype, and that's it. (I'm choosing to ignore .NType, as far as I've been able to ascertain it doesn't enter into this.)

t_object.Object_Type will hold the (cat 3/4) metatype if one is defined, and only if the element has no profile-defined metatype will .Object_Type hold the (cat 1/2) base element type. (Whether a stereotype has a profile-defined metatype is a choice made by the profile designer.)
In both cases, t_object.Stereotype will hold the stereotype's simple name. The fully-qualified stereotype is stored in t_xref.

When going through the API, EA does it differently because there are separate Element attributes for .Type, .Metatype, .Stereotype and .FQStereotype.

So a correctly created database table element should appear as follows:
  • Database
    • t_object.Object_Type = 'Table'
    • t_object.Stereotype  = 'table'
    • t_xref.Description   = '@STEREO;Name=table;FQName=EAUML::table;@ENDSTEREO;'
  • API
    • Element.Type         = 'Class'
    • Element.Metatype     = 'Table'
    • Element.Stereotype   = 'table'
    • Element.FQStereotype = 'EAUML::table'
As I was writing this, Qwerty responded.
EA's query results are mingled and not a direct representation of the table contents. Esp. object type is changed towards the metatype defined for the element.
Normally I defer to Q on the details of the database, but are you actually sure about this? I would have assumed that EA stores the metatype as I describe above, not that it fudges the query results.

In either case, the CSV import/export also differentiates between the base element type and the metatype, and I suspect this is what's causing the problem. In a CSV specification, the metatype is referred to as "Profile Metatype" and it must be included for a CSV import to work when dealing with metatyped elements.

A proper export of a package containing a correctly defined database table should look something like
    GUID;Type;Profile Metatype;Stereotype;Fully Qualified Stereotype;Name
    {E91B88AA-AB9F-40ae-B970-34D6CA0E9C8B};Class;EAUML::Table;table;EAUML::table;Tabellen Ellen

(I've included the simple stereotype name for completeness. It should be omitted in production.)

As you can see, the CSV import/export also includes the profile name in the metatype name. The API does not, and it isn't stored that way in t_object.


So when I do an csv export these two table both report CLass for Element.Type.?
What is happening here?
You are exporting only the base type, not the metatype.
This should be obvious when you import the data into another project, but unfortunately EA obscures this error by being "helpful".

If your CSV data contains Type and Stereotype, but not Profile Metatype, then on import EA won't know that you want to create Table/«table» elements. It will find only Class/«table» elements in there, and will create exactly that.
(I am assuming that you are working with simple stereotypes too. I believe fully-qualified stereotypes might also have worked, but I haven't tested this.)

But here's where it gets murky. In a fresh project created from scratch (that is, from the default base project) EA includes a bunch of in-project stereotypes which do not belong to any profiles at all. Crucially, there is a non-profile «table» stereotype in amongst them.

So it is quite possible to create a Class in a regular class diagram, then set its stereotype to the profile-less «table».
You can also set the stereotype of a Class to «table» from the EAUML profile. Of course you can -- the EAUML::table stereotype applies to Class, after all.

If you set a class stereotype to EAUML::table, EA changes its t_object.Object_Type from 'Class' to 'Table'.
If you set a class stereotype to the profile-less «table», EA sets its t_object.Object_Type to 'Class'. So EA does a lot of footwork when you change stereotypes, and importantly, you can change a properly-defined Table/«table» element to an ill-defined Class/«table» this way.

This "helpfulness" isn't limited to the ill-defined profile-less «table» stereotype. EA also treats a Class/«table» as if it were a proper Table/«table»: it shows it as a database table in diagrams, and when prompted to open the properties dialog it opens the table-specific dialog instead of the generic class one, allowing you to edit columns instead of attributes, etc. But the project browser does show the difference between a Table/«table» and a Class/«table» in that only a Table/«table» has the table-style icon.

Finally, you mention that
I've checked types, Stereotypes, FQStereotypes, Profile Types, PackageID, ...
This omits both metatypes and GUIDs. I've talked (at length) about metatypes but if you've somehow managed to get duplicate GUIDs in t_object your project is seriously broken, although I would expect the integrity check to pick up on that.

Going forward, your CSV specifications should always include metatypes and only ever use fully-qualified stereotypes, and all new projects should immediately be cleared of all "helpful" stereotypes and tagged value types. It is worth setting up your own base project for this.

I hope this helps. I really do. :)


Uml Process / Re: Describe questionnaire algorithm in UML
« on: January 04, 2021, 10:29:49 pm »
Hi Mo,

I hope that I have not confused (I feel I might have done so) between modeling the questionnaire at the abstract level (the type of question and types of answers, multiple-choice vs free text) and modeling it at the object/instance level where I state the specific Questions and Answers in each section.

Unfortunately, I think you have. Don't feel bad -- we all started out making models like this. :)
So here are some thoughts, in no particular order or structure.

A fundamental problem is that in UML, only the syntax and semantics are standardized. No applications are. That is to say, you can't say  "I've done a data model" and expect people to be able to read it. You're still going to have to explain what choices you've made in your modelling methodology, or put another way, what you've modelled, how, and why. (This is sort of what Qwerty is saying too.)

I can think of several different things you might be trying to model here:
  • A conceptual model of what a medical questionnaire is, regardless of whether it's done on paper, by interview or electronically;
  • A data model of the data obtained from a medical questionnaire, with a view to storing it in a database or similar;
  • An activity model of the flow of activity someone follows when filling out a medical questionnaire;
  • A software model of a system for carrying out medical questionnaires.
These are very different things, and it's essentially impossible to know how best to represent anything without knowing what the purpose of the model is.

Your use of enumerations is incorrect.
Enumerations are data types. They should have values only, and are not good representations of questions. They should also be named in the singular. A good enumeration in this context could be "Yes/No Response" with values "Yes" and "No".

I see you've drawn a generalization from Health Assessment to Health Profile. This doesn't make sense; a health assessment is not a type of health profile.

I have a hunch you're more interested in the responses than the questions. If that is the case, focus on the responses. Make each response an attribute in some class, eg "Currently experiencing anxiety, panic attacks or phobias : Boolean".

Don't worry about units of measure if your model is more conceptual than representational. It's a rabbit hole you don't want to dive into unless you really really have to.

I like your «quantity» stereotype and the Duration datatype. But units of measure are not attributes of a quantity: a Duration does not contain one number of years, one number of months and one number of weeks. In general, if you're working with quantities you're in conceptual space and if you're working with units of measure you're in representational space. Don't mix the two. Leave Duration as a primitive (attribute-less datatype).

The «use» connectors to Duration are inappropriate. The «use» relationship denotes usage of functionality, as in one class calling a method in another. If your attribute is typed Duration, that alone expresses the relationship you're trying to show.

So yeah. Room for improvement. :)




There is the cloud server integration. I haven't tried it myself, but it's supposed to allow you to make use of elements from one project in another without importing any models.



Bugs and Issues / Re: User created multiple times
« on: December 30, 2020, 08:03:19 pm »
Hi again,

I'm wondering about the project transfer.

When you do a project transfer EA creates a new .eap file based on the EABase.eap file in the program files folder, and I thought it was exactly this one that should have been updated.

Are you sure about this?
You do need a project, not just an empty database, to transfer into, but why should it first copy EABase to the target project and then copy the source project? Remember, the target is already a project (ie has all the EA tables) and will be clobbered with the data from the source. Copying the base project first is redundant.

Presumably also the transfer process doesn't copy the schema from the source to the target but simply clears all the tables in the target and then copies the data from the source.

If this is all correct, what you need to do is update the schema in both the source and the target before you transfer.
It's only if you've created the target project with 1557 that you don't need to update it before the transfer.


Bugs and Issues / Re: User created multiple times
« on: December 29, 2020, 01:51:20 am »
Hi again,

Not presuming to speak for Sparx or anything, but surely the schema change only applies to new projects?

I'd be surprised if they'd implemented an auto-update in the client. For one thing, the account that runs the client might not have permission to make those changes in the database (in a file project yes, but not in a DBMS).

So you'll have to make that change yourself if you need it.

In summary, 1555 changed what gets stored in t_secuser.UserLogin when importing users from AD. Notably, the newer format (UPN) requires longer strings, but the column length was left at 32. (This was too short before as well, but usually worked due to sheer luck.)
1556 added a fix so that when storing accounts in t_secuser, the actual length of .UserLogin is used in case you've increased the length of the column yourself.
1557 updated the schema so that projects created from then on would have the column extended to 255 characters.

But if you're working with a project created with any version of the client prior to 1557, you need to extend that column yourself.
Sparx have not published any scripts to help you do that, you simply have to know a) that you need to do it in the first place, and b) how to do it in your chosen DBMS.


Automation Interface, Add-Ins and Tools / Re: Export attributes to CSV
« on: December 28, 2020, 09:02:24 am »
Hi Mo,

Unfortunately yes. You can't export attributes or operations to CSV, nor indeed connectors.


Uml Process / Re: Attribute/tag value with more than one values
« on: December 27, 2020, 01:27:26 am »
Another option is to work with "loose" tagged values.
Manually you can add as many tagged values of the same type as you want.
Make sure the option "show duplicate tags" is on though, or EA will only show one of them.
Also, if you need too access the tagged value contents in scripts and/or document generation, it gets tricky. The same goes for RefGUIDLists (although the single RefGUID is simpler to deal with).

Basically what we are all saying here is you're going out on a limb of EA functionality and should consider your metamodel and how to implement it.

But I should also add for completeness that the RefGUIDList I mentioned is the same thing as a one-to-many tagged value connector in the profile. So that's what you were trying to do I think, but you didn't use the correct connector.


Uml Process / Re: Attribute/tag value with more than one values
« on: December 26, 2020, 03:34:34 am »

You can use a RefGUIDList to assign as the values of a tag a number of elements of certain types and stereotypes.
It's a bit clunky and requires you to create elements for the things you want to use as tagged values, but it works.


Bugs and Issues / Re: User created multiple times
« on: December 26, 2020, 12:32:38 am »

Can you explain why the change is a good thing?
Is that because UPN can stay the same even if you change domain?
No, the UPN is linked to a domain. Different domain, different UPN.
But UPNs are more readable, and can be longer. They seem to be the preferred option when authenticating in Windows, although it is hard to tell for sure.

In my case, since I have the groups in EA linked to AD groups, I could simply release all user locks, and then delete all users.
They will be automatically recreated (with their UPN) the next time they open the model.
I'm just not sure if I should. After all, its working now as well.
I wouldn't. If you want to get rid of the message, I'd modify t_secusers. You never know what might be tied to the user GUID somewhere deep down in the schema.


Bugs and Issues / Re: User created multiple times
« on: December 25, 2020, 07:21:24 pm »
Hello again,

The behavior changed when we upgraded from 15.1 to 15.2.
We didn't change anything else except that, and suddenly we see this new behavior with the email addresses.

It was in 15.2.1555. And they're User Principal Names, not e-mail addresses.
  • Active Directory integration improved:
    • Importing Active Directory users now uses 'User Principal Name'
    • Auto login will now attempt to match both 'User Principal Name' and legacy NetBIOS\SAMUsername formats
    • New option added. 'Allow non-domain users (insecure)'. This is off by default when enabling security but existing models it will be on

So pretty much as I outlined. But since you're presumably logging into a pre-existing project, it's got DLLNs stored and so you get that message.

However, this also makes clear that EA does in fact choose whether to retrieve DLLNs or UPNs when importing users, and it has changed from DLLN to UPN. This is a good thing, but was clearly not executed with due care and consideration, which is why they had to rush the 1557 fix.

It would have been even better if they'd included an option to re-import users so they'd retain the old GUIDs but change t_secuser.UserLogin from DLLN to UPN. You can automate it, but if you want to do it right (which, you know, we're talking about security and accessibility here, so probably just as well to make the effort) it's a fair amount of work so some support would have been nice.


Bugs and Issues / Re: User created multiple times
« on: December 25, 2020, 02:38:42 am »
The other option is that they reverse the change and go back to the old Domain\userName
I don't see how that's an option. EA can't decide what the domain controller returns.
It's EA that chooses to either use the Domain\userName or the "emailaddress" style username.
I don't think so.

If EA doesn't have your email address registered, but still the old Domain\userName, then you will be logged in anyway.
This is then mentioned in the system output like this:
Login: Windows user 'Geert Bellekens (Geert.b[email protected])' is not a member of the model.
Login: Logged in as Windows user 'Geert Bellekens (DOMAIN\Geert.bellekens)'.

That would appear to be EA checking if the account in the Windows session is stored in t_secuser. If not, and if it is a UPN, it constructs a DLLN from the simple account name and tries that. This may have security implications, and once again it would be interesting to know exactly what the algorithm is here. (Keeping your authentication algorithm obscure is a frustration for IT staff and a godsend to hackers.)

But what I meant was that EA doesn't decide what the domain controller returns when you import the user in the first place. In this case, it appears that what's been imported is a DLLN, but the Windows session returns a UPN.


Pages: [1] 2 3 ... 124