Rationale for <<view specification>> (V14 MDG addition)

[qwerty]

Is that just a "toolbox+"? To me it seems that you now can dynamically assign multiple toolboxes to a diagram. But is there more about it? (Thank god the designer of that and me won't accidentally cross paths.)

q.

[Eve]

It's an idea that's expressed in languages like ArchiMate and UAF. A "view" is an abstract concept of a restricted set of the model in order to convey one aspect of that model. Although the language may offer some example view types, the intention in those languages is that they should be customizable by model authors, not just tool authors. That factor contributed to the implementation in EA where you take an existing diagram type then explicitly expose the modeling types that you want to use.

It does result in a toolbox, and a quicklinker, but it also allows you to explicitly hide any elements that don't belong in that view.

Incidentally, it allows an answer to the age old question of preventing new connectors from showing up in old diagrams. If you are using views properly they will be automatically hidden.

PS. That last comment could be interpreted as a threat of violence. It's not really appropriate in any professional setting.

[Paolo F Cantoni]

[SNIP]
Incidentally, it allows an answer to the age-old question of preventing new connectors from showing up in old diagrams. If you are using views properly they will be automatically hidden.
[SNIP]

Hi Eve,

Can you elucidate on that?  I can see how new arcs of suppressed types would be inhibited, but how do new arcs of included types get supressed?

TIA,
Paolo

[Eve]

The key is "if you are using views correctly".

If you are using different views for different relationship types then you won't be in the situation where a connector shown in that view is added on a different diagram.

You could even create an "overview" stereotype for connectors and create a view that only shows those connectors. (Although that would probably interfere with your rule of only one stereotype on each thing)

[Paolo F Cantoni]

The key is "if you are using views correctly".

If you are using different views for different relationship types then you won't be in the situation where a connector shown in that view is added on a different diagram.

You could even create an "overview" stereotype for connectors and create a view that only shows those connectors. (Although that would probably interfere with your rule of only one stereotype on each thing)

Bit ignorant today, I still don't quite see how that works.  I guess I'd have to see a worked example.

As to my rule of single stereotype, I'll need to investigate the new MDG process more.  Certainly, I can cling to the notion of there is only ONE metatype per vertex (and thus one primary stereotype), but I can consider "Claytons" stereotypes (the stereotypes you have when you don't have a stereotype  ) as mechanisms for achieving certain ends.  As I said, I've started a new assignment so I'm still coming "up to speed" on that.

Paolo

[qwerty]

So if I get it right this is a replacement for the toolbox concept. Which (the usual EA approach) means we have two completely different ways to achieve the same thing (with a view on the old toolbox concept). And also as usual the old way will not be deprecated. Uhm well, thanks for the confirmation.

q.

P.S.: Die Gedanken sind frei.

[qwerty]

PS. That last comment could be interpreted as a threat of violence. It's not really appropriate in any professional setting.

It's you interpreting it that way which tells a lot. I haven't expressed any violence.

q.

[KP]

So if I get it right this is a replacement for the toolbox concept.

Wrong, it's an extension not a replacement, and you can either use it or not. It's simply a mechanism for creating subsets, or supersets, of toolboxes for specific kinds of diagram. Have a look at the toolboxes for ArchiMate 3 Business Layer diagram views, as an example, and see how they line up with the Viewpoints chapter in the ArchiMate 3 specification.

[qwerty]

My point was that you can do the same with the view what you could with toolboxes (plus more). So the toolboxes should be deprecated and not live on as zombies (my POV). I know that does not conform with Sparx' view. And it's only a little sigh today. Not an OMG (and more) like it was in the past. That's just how it is. Do how you please.

q.

[Eve]

My point was that you can do the same with the view what you could with toolboxes (plus more).

Which is incorrect. A view specification intentionally does not deal with how the exposed types are presented in the toolbox. It only covers what can be used.

You still need the toolbox to specify multiple pages, ordering within pages, hidden menus, patterns etc.

It's the same for the way the metamodel specifies what is allowed rather than the quicklinker specifying all of the options that you have (in explicit and sometimes gory detail)

[qwerty]

Hmm. Using the view will at least do a similar thing like the toolboxes. I add exposed elements to a view which then will appear in the very toolbox for the diagram. I haven't thought about the ordering and the other bits so far. But it's obvious that you have a large overlap of functionality.

Rather than having now two ways of doing the same thing (namely showing a subset of elements in a toolbox of a page) I would have expected one (extended or new) way to cover both. A toolbox has ever been a view in that it limits/presents a set of relevant elements/relations for a diagram in a user defined order. The new view does the same without being able to give an order, but adding some other functionality. That's where my frustration came from. Again, that's how it is. At least it's in the same consistently inconsistent way EA is designed.

q.

[adepreter]

Did this all start from adequate requirements? And from whom?

It seems (just a guess) to start from an assumption that it is a good idea to start mixing different languages that were not designed to work together, that have different semantics, different metamodels, different terminologies etc....

For people to effectively communicate and collaborate across several disciplines, they should better speak one language, and use one tool and one repository.
Teams can use one language that does everything they need or two that are exactly complementary if they need more.
Complementary OK. But there should not be any redundancy.

Also the term "metamodel view" sounds like a mix of concepts that does no make sense to me.
What my users need is the ability to create views based on a single language metamodel.
And to be able to create views, I, the framework author, need to be able to define Viewpoints, as defined e.g. in ISO 42010: http://www.iso-architecture.org/42010/cm/
Hopefully, that is what diagram pages are about.

--- My users' requirements and my derived requirements ----

As a professional focusing on framework, language and tool authoring, these are some of the things my customers need.
Most things I could resolve myself. But there are areas where I would like to go further, and I can't due to EA limitations, as explained below.
And these limitations persist maybe because the EA development team seems to be focusing on requirements of obscure origin leading to these unusable language mixtures.

So here are mys users requirements and my derived framework author requirements:
- Modelling elements and connectors (MDG UML profile)
- Language Metamodel covering the entire language (as in Labnaf)
- Easy-to read yet formal language metamodel expressed using the end user modeling language itself (as in Labnaf)
- Pre-conditional (preventing from) and post-conditional model validation (validate after the fact) (as in Labnaf)
- Dynamic model validation based on the language metamodel that is expressed using the end user language (as in Labnaf)
- Quicklinks generated from the language metamodel (as in Labnaf)
- Viewpoints (MDG Diagram pages)
- Toolboxes (MDG Toolbox pages)
- Filters on the available items on the toolbox (------------ HOW?)
- Filters (that can be set on and off by the end user or he administrator) on the type of connectors an elements that can appear on a specific type of diagram (------------ HOW?)

- Ability to load/import and activate an MDG any time programmatically at runtime, when EA is already running (------------ HOW?)
- Ability to programmatically (re)load quick links in memory for an active MDG (------------ HOW?)
- And finally get rid of this EA bug that removes the "From"part of quick links for each diagram page that does not have the same name as the MDG

[Eve]

Alain, there appears to be two mostly unrelated issues here.

• You're getting unexpected results in your quicklinker
• You can't get the results you want using view specifications, diagram profiles and toolbox profiles

I'm guessing that your quicklinker has been specified using the table rather than extrapolated based on a metamodel. That's only because the images that I've seen show a menu that doesn't match what the metamodel would build. The fact that your from items don't show up when the diagram type changes does suggest that either the diagram filter is different or different elements are involved and filter to toolbox is doing its thing. Unfortunately, anything suggestions from Sparx at this point are pure guesses. We don't have the information available about what you're doing.

Looking at your listed requirements, omitting implementation details incorrectly expressed as requirements, they sound a lot like we have built.

So here are mys users requirements and my derived framework author requirements:
- Language Metamodel covering the entire language
- Easy-to read yet formal language metamodel
- Pre-conditional (preventing from) and post-conditional model validation (validate after the fact)
- Dynamic model validation based on the language metamodel
- Quicklinks generated from the language metamodel

All covered using the metamodel constraints available from v14. I've intentionally left out the parts that in my option correspond to your interpretation of your user requirements.

- Easy-to read yet formal language metamodel expressed using the end user modeling language itself (as in Labnaf)

In general, you can't expect a language to be able to express its own metamodel. This may be valid for your metamodel. As tool authors, we have to reject this requirement as self-contradictory.

- Filters on the available items on the toolbox (------------ HOW?)
- Filters (that can be set on and off by the end user or he administrator) on the type of connectors an elements that can appear on a specific type of diagram (------------ HOW?)

Filtering the toolbox is exactly what the view specifications being discussed in this thread are for. The exact views that will be used would depend on the requirements for a specific model, and it's intentionally separate from the definition of the toolbox itself because the technology author can't know in advance every view required for their technology.

- Ability to load/import and activate an MDG any time programmatically at runtime, when EA is already running (------------ HOW?)
- Ability to programmatically (re)load quick links in memory for an active MDG (------------ HOW?)

A full technology can be loaded explicitly at any point. The only time that's difficult is when the technology is coming from an add-in. There's no way to re-trigger the broadcast to load technologies.

Additionally, a UML profile (which includes a metamodel, quicklinker and views) can be specified in the model and imported explicitly into the model in one command. (In 15 that's Specialize > Technologies > Publish-Tech > Import Package as UML Profile) It's a quick easy way to test changes in the metamodel and how they impact the use. Can be used easily for technology authors and model managers that want to apply views to an existing technology.