Controlling the name and order of the toolbox in a View Specification

[PeteC]

I've created a few View Specifications to restrict toolboxes to the most commonly needed tools, but they are not named or ordered in the filtered toolbox as they are in the original toolbox. Is it possible to control the order and/or names?

For example for the Activity diagram, I have included ActivityInitial. In the original toolbox it is called Initial, but with my View Specification selected as the Applied Metamodel, it is called ActivityInitial. I don't really want the names to change from the default toolbox (so it wouldn't matter if they simply acted like a pure filter on the toolbox or whether I need to specify precisely the names, but the default names look messy).

Also, including both ActivityInitial and ActivityFinal, in my View Specification, ActivityFinal appears before ActivityInitial while in the default toolbox Initial appears before Final. I've adjusted both the Z-order and the order that the elements appear in the Project Browser but they stay firmly in what appears to be alphabetic order. If I can't control them specifically, I would be happy if they simply stayed in the order they were in the default toolbox.

[Geert Bellekens]

I think you might want to look into creating your own toolboxes.

There you can define exactly the order and how the entries are called.

Geert

[PeteC]

I have created some of my own toolboxes and appreciate that doing that I have control over the naming and order (and hence I was rather expecting to be able to do so with View Specifications). But the beauty of the View Specification is that the toolbox can be restricted on user choice - I can create a simple one that offers the most used tools, but if a user wants to use the wider range of tools then they just choose the default or complete "Applied Metamodel" and that setting stays set every time the diagram is opened. I know that an expert could go and find the appropriate alternative toolbox, but If I create a cut-down toolbox then that will be the one that is offered by default every time the diagram is opened.

[PDC]

Apologies for resurrecting an old topic but I have this exact same problem (build 1628).
In my profile's toolboxes the Elements/Relationships are ordered in a particular way, but when the ViewSpecification Exposes those Elements/Relationships they are all just lumped into one toolbox in alphabetical order. The View Specification doesn't seem to be able to Expose the toolbox itself either, which is a shame.

It's not the most significant problem in the world (all the tools are available in the View, just in a funny order) but if there is a way to achieve this I would greatly appreciate knowing please

[Geert Bellekens]

I've never really felt the need for view specifications.
What make you want to use them?

Geert

[Eve]

If an MDG Technology contains exactly one toolbox definition, any view specifications will take the order and grouping of the items in that toolbox for any view specifications that are defined within the technology.

[PDC]

I've never really felt the need for view specifications.
What make you want to use them?

For me, it will make the MDG Technology more accessible to our engineers who are still becoming familiar with MBSE. I want to create views, tools etc that are maybe a little 'more' prescriptive than would be normal, so that it is more intuitive for people to build a model using terminology from our industry rather than having to immediately learn the entire SysML spec by heart. it's maybe not ideal, but my intention is that our engineers will gradually pick up the SysML side of it while also adding value to the model by doing work. So the View Specifications will allow me to give a user the tools they need for a particular task without distractions from things they don't understand.

In the long run, or if we had a team of seasoned MBSE engineers, I agree that the effort required to specify, produce and manage View Specifications may negate any benefit you would gain from them. It's useful for us in the transition period though.

If an MDG Technology contains exactly one toolbox definition, any view specifications will take the order and grouping of the items in that toolbox for any view specifications that are defined within the technology.

Thanks, this is useful to know (and I guess fairly obvious on reflection). My MGD Tech has several toolboxes though (rightly or wrongly) so I guess I'm stuck with the alphabetical groupings in the ViewSpec. Like I said, not the end of the world - the tools are all available in the right places, our engineers will just need to learn the alphabet

[Geert Bellekens]

For me, it will make the MDG Technology more accessible to our engineers who are still becoming familiar with MBSE. I want to create views, tools etc that are maybe a little 'more' prescriptive than would be normal, so that it is more intuitive for people to build a model using terminology from our industry rather than having to immediately learn the entire SysML spec by heart. it's maybe not ideal, but my intention is that our engineers will gradually pick up the SysML side of it while also adding value to the model by doing work. So the View Specifications will allow me to give a user the tools they need for a particular task without distractions from things they don't understand.

In the long run, or if we had a team of seasoned MBSE engineers, I agree that the effort required to specify, produce and manage View Specifications may negate any benefit you would gain from them. It's useful for us in the transition period though.

I understand that, but we have always defined toolboxes for that purpose. It seems like view specifications and toolboxes are two ways to reach the same goal.

Geert

[PDC]

I understand that, but we have always defined toolboxes for that purpose. It seems like view specifications and toolboxes are two ways to reach the same goal.

They're definitely similar, and I've read various threads on this forum that come to that conclusion.
The only difference from my persepective is that with the View Specification I can add custom diagram types to the 'New Diagram' dialogue, with a limited set of tools available when using that diagram (in the toolbox and in the quicklinker, using the stereotyped relationships and metaconstraints in my profile). Then we can tell our engineers 'We need a [diagramtype] diagram to communicate [some meaning]', rather than 'we need a BDD to communicated [some meaning]', and then all projects will deliver the same diagram with the same type of content to communicate that same meaning.

I agree we could achieve this with only the MDG profile and its toolboxes, but that would rely on the engineers knowing 'a little bit' more than they currently do about MBSE delivery.

In any case, I'm not planning to define many View Specifications, as there are limitations (e.g. the 'toolbox ordering' issue described here) and I would hope that the engineers don't need them as they become more familiar with MBSE and our internal engineering/delivery processes.



...also worth noting that this is the first time I've used View Specifications so if they turn out to be of limited value in practice then I'll probably abandon them and rely on the profile itself, as you suggested.

[Geert Bellekens]

Ok, thanks for your insights.

Good to know that I didn't miss a major benefit of View Specifications.
We indeed create diagram types to go along with the toolboxes.

And just like you with tell them: use diagram X in location Y to communicate Z

Geert

[PDC]

Good to know that I didn't miss a major benefit of View Specifications.
...
And just like you with tell them: use diagram X in location Y to communicate Z

No, you didn't miss anything, sounds like we're very much on the same page!

[Paolo F Cantoni]

Good to know that I didn't miss a major benefit of View Specifications.
...
And just like you with tell them: use diagram X in location Y to communicate Z

No, you didn't miss anything, sounds like we're very much on the same page!

Very Useful thread!

Let us know your experiences with the View Specifications.

Paolo