Just a few marginal notes from me. I'm only starting to use these constraints. While the old csv format was just no way to go (trying to hammer a multi-dimensional structure into a flat format) the new approach also has its drawbacks. It's getting crowded quite fast. So it's hard to read what may be related and what not. I'm currently thinking of externalizing this into some data structure (be it JSON or whatever) in order to make it maintainable and then make some sort of bulk import. So although the new approach looks much better it's still far from being "sliced bread". My own slices still do not look that delicious too right now :-/
q.
Ah, yes. Reading your post, I realise we're in a
uniquely fortunate position with
our Sparx setup. As you know, we make extensive use of our diagrammer Add-In which creates "Neighborhood" diagrams. Consequently, we can get a simplified view of all the relevant relationships and related items to the stereotype or metatype etc.
We can therefore create and manage VERY complex metamodels. For example,
(NOTE: This is a simplified version of the Neighborhood diagram for the purposes of this discussion)
You can see the central stereotype PBIRprt (Power BI Report) and what other components it extends or inherits from. This is manageable on a per-item basis. One REALLY NICE feature of this diagram is the ability to simply create similar stereotypes. We just select a (central) item that has the required characteristics and copy it using [Ctrl+Shift+V]. A quick rename and any customisations required for the new stereotype and we have a consistent, new item! The new item then gets its own Neighborhood diagram.
Works a treat! (as it has for over a decade!).
All we need is for the inheritance to work properly over multiple levels of inheritance and (I believe) we'll be sweet!
As I said, we're very fortunate to have solved another enterprise-level modelling problem.
Paolo
