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 2 [3] 4 5 ... 403
31
Sorry Paolo I don't think you can be successful in this one

Did you mean to address Mats, not Paolo?
I hope so because Richard seems to be saying the same as me (AFAICT).  Although I agree with Glassboy that messages are flows of data between entities.

I kept going round and round in circles (especially with my business users) until I realised that it was the attributes and not the entities that were "Master Data".  After that, we were even able to resolve the "that's MY data" problem.

I personally think that the concept of "Source of Truth" is misleading(1).  The implication is that there is one source of absolute truth.  Neither of which is correct.

Paolo
(1) And if you try to find a consistent definition on the interweb, you're unlucky.

32
Hi Mats,

If I understand you correctly, there are a couple of problems with what you are attempting to do.  The first is conceptual.  I hope you agree that the real Master data is the attribute or property, not the object or entity.  "Objects' are "Master Data Objects" because they include one or more Master Data Items (attributes/properties/features).  If you don't agree, good luck  ;).

Each Master Data Item has a lifetime.  Different sources can create/modify the value of the item at different points during its lifetime.  Indeed, at the same point, multiple sources may change the value.

Normally, information flows document flows between objects/entities not between the attributes.  There are ways around it, but you will need to decide what you are tracking.

Normally, you need to track which systems/business processes access the item and in what manner (CRUD).  This suggests that an ArchiMate "Accesses" relationship may be more appropriate.

We have implemented a "source of Truth" relationship which is (effectively) derived from the accesses and indicates that the supplier can be considered a SoT for the related attribute.

HTH,
Paolo

33
Hear hear. This post should really be pinned.

Well, not this one. That one. You know what I mean.


/Uffe
+1 (for pinning THAT post)

And no, we didn't know what you meant, we only saw what you wrote...  ;)

Happy Friday everybody!  ;D

Paolo

34
Bugs and Issues / Re: Custom Script fragments not working in 13.5.1352
« on: March 29, 2018, 10:53:23 am »
This is in fact an old bug which I first reported back in May 2013. Slight difference in that back then 'custom script' fragments never worked when invoked through the API, and this time around they do work once per session.
It was fixed and worked in 11.1, but somewhere along the line it reared its zombie head again. Well, it's Easter after all.

The issue number was 13055290.

/U
Don't forget that (in at least English speaking countries) this year Easter Sunday is ALSO "April Fool's Day".  ;D

Paolo

35
General Board / Re: When is an instance not an Object?
« on: March 29, 2018, 10:49:06 am »
Wow, you... actually sat down and did that.
That is laudable, or possibly certifiable. I get them confused. Either way, you deserve a long weekend.

On artifacts, I remember this discussion was up at some point and someone from Sparx said that there's a bug, which will be fixed, in how EA handles instantiation of artifacts, and that's why instances of artifacts appear to be both classifiers and instances.

I had a trawl through my mailbox but I couldn't find it. Possibly it's in a thread here on the forum.

/Uffe
Remember, Uffe, the only certifiably sane people are those who have been certifiably insane in the first place...   :D

Paolo

36
Bugs and Issues / Re: What's the deal with the «enum» stereotype?
« on: March 29, 2018, 10:41:22 am »
is it set on a per-instance, per-repository or per-user basis?

Paolo
Most of the settings are per user since being stored in the registry.

q.
I'll try to confirm that since it's quite annoying.

Paolo

37
I think you need to clarify "correct".  Viable might be a better term.  It can be argued that if one can't "see" the original conceptual model in the physical model, then there has been semantic impedance introduced.
One wonders what schools of art you favour :-)
Conceptual Art, of course!  :D

Paolo

38
General Board / Re: EA14 beta: new eapx repository
« on: March 28, 2018, 05:45:54 pm »
In our case, we can guarantee all our .EAP files are Jet4 since we can't open Jet3.5 files with our MS Access versions.  So, we convert all Jet3.5 files (of any consequence) to Jet4 and go from there.
Ditto with the addition that any new eap files created are now jet4
We achieve this by replacing EABase.eap in C:\Program Files (x86)\Sparx Systems\EA\ with jet4 template
I forgot we did that also...  We did it specifically for our snapshots via Project Transfer.  In fact, we create two snapshots, one with the unadorned Jet4 EABase.eap from Sparx and one with our "adjusted" Jet4 schema.
We change the EABase "on the fly" - as required.

Paolo

39
I don't know if it CAN be automated but I would STRONGLY recommend against it.  Creating a physical data model from a logical data model or class diagram is not straightforward, and there are so many factors such as level of denormalization, target RDBMS implementation specifics, data modeler style etc.  A perfectly correct physical data model can be totally different from its perfectly correct logical data model.  Anyone else has a better idea?
I think you need to clarify "correct".  Viable might be a better term.  It can be argued that if one can't "see" the original conceptual model in the physical model, then there has been semantic impedance introduced.

Further, if the modeller is consistent, then it is possible to encode the rules they use into an automaton.  If the conceptual model is well-formed (actually models the reality it is scope for) then applying the modeller's rules should produce a viable physical model with reduced semantic impedance.

In my experience encoding such rules provide s a level of Concistency, konsistency, consistensy! TMUffe - after Paolo that allows both the conceptual and physical models to be improved.

But (as they say) "Don't try this at home, folks".  If you don't have the knowledge or experience.

Paolo

40
Bugs and Issues / Re: What's the deal with the «enum» stereotype?
« on: March 28, 2018, 11:07:03 am »
The «enum» stereotype on an enumeration literal is added to Java enumerations. It was added when Java added support for enumerations, which included normal attributes as well. A stereotype was used on the literals to distinguish them from the attributes.

Set the language of your enumeration to <none> and the stereotype shouldn't show up again.
We tried setting our standard language to other than Java  (and we thought we had reset the repository - using Update Package Status...) but EA still creates some things with the Java Language Property. Is there more than one place to set this and is it set on a per-instance, per-repository or per-user basis?

Paolo

41
Bugs and Issues / Re: What's the deal with the «enum» stereotype?
« on: March 27, 2018, 05:46:54 pm »
For a while now I've noticed something strange.
On some models, when I add a value to an enumeration, this new value automatically gets the stereotype «enum»

On other models the stereotype is not there.

Does anyone know where this stereotype is coming from, and why I have this on some models an not on others?

Geert
I can't help with your questions Geert, but I can confirm that «enum» is a very special thing and behaves differently from other stereotypes.

Paolo

42
General Board / Re: BUG in 1410
« on: March 27, 2018, 05:36:54 pm »
the color picker is not working on high res screens
Curious, I was able to reproduce some odd behavior when switching between displays with different DPI scaling settings. Does that apply in your scenario?
Coincidentally one of our users just got a Surface Book 2? with Windows 10.  Weird things are happening with EA 13.5 as he moves between the Surface screen to one of the 2 other attached screens.

Paolo

43
Bugs and Issues / Re: Imported requirements not recognizing MDG tags
« on: March 27, 2018, 10:46:56 am »
Do you have the base type and your stereotype defined in the csv import/export?
+1
Paolo

44
General Board / Re: EA14 beta: new eapx repository
« on: March 26, 2018, 02:47:38 pm »
does that mean we can just rename one of our (Jet4) .eap files to .eapx
I decided against offering that suggestion in my previous reply. I've seen enough instances where people thought they had a JET 4 repository but actually didn't.

If EA can't open the file when JET 4 is disabled, but can when it is enabled, it is probably1 a JET 4 model, and shouldn't add to the confusion if you renamed it. Alternatively, if you can set the name of something to a sequence of characters from different languages/characters sets, close the model and re-open it and they are still there you should also be safe. Here's sample text that I just verified that is round-tripped:
Quote
يَحظى чудна ĉiu größeren ψημένηמאוכזב वाले つねならむ 입술끼리 џвакацитрусกว่าบรรดา 視野無限廣 中国智造

1 It wouldn't actually surprise me if there are some circumstances where a particular database corruption would cause a Jet 3.5 model to fail to open in Jet 3.5 code, but Jet 4 code ignores or handles the error.
Thanks for the warning!

In our case, we can guarantee all our .EAP files are Jet4 since we can't open Jet3.5 files with our MS Access versions.  So, we convert all Jet3.5 files (of any consequence) to Jet4 and go from there.

Paolo

45
General Board / Re: EA14 beta: new eapx repository
« on: March 26, 2018, 12:22:22 pm »
eapx is a Jet 4 database, so it supports Unicode. Jet 4 isn't a new thing for EA, but there's often confusion around it.
So, Simon, does that mean we can just rename one of our (Jet4) .eap files to .eapx and it will work "out of the box" with 14?

If so, we might leave our shortcut files as .eap and our real repositories as .eapx.  Not that it matters so much since we prefix ALL our shortcut files with "@".

Paolo

Pages: 1 2 [3] 4 5 ... 403