Virtual Views

[Thomas Rischbeck (ITMC.ch)]

Dear Phil and Jean-Baptiste,

After using many different enterprise modelling tools, we always like to come back to Archi  We really like it simplicity and so do our customers. However, we also experience one shortcoming, that we would like to address to make this great tool even better: let’s call it “virtual views” - I am adopting this name because I’ve seen some discussion around such a feature in the past (https://github.com/archimatetool/archi/issues/17).

Let me explain my understanding of "virtual views": currently, all views in Archi are manually layouted. Your drag-and-drop elements from the palate, positioning on the canvas and create relationships between those.  You can also drag and drop elements from the model tree - Which would appear in a basic flow Lay-out including relationships. I also found some JArchi scripts to do some kind of automatic Lay-out on existing views, but this is very limited (mmbmatrix, vertical/horizontal spacing, graph layout library, etc).

What we are really looking for is a generic ability to create virtual views that are automatically update based on model contents and filtering criteria. They should offer various layout styles, such as matrix, tree, risk-map, life-cycle roadmap, etc. driven by element properties.

I’ve gone quite a way to build generic layouts with a collection of JArchi scripts. My idea is to define a separate view, mark it as “virtual “and define a set of properties to drive its layout and the filtering of elements. An example is the risk map diagram shown below, which uses the properties “impact” and “probability” to position assessment elements on a grid. The “grid” is a generic reusable and stackable layout container.

This is great, however one shortcoming is of course that people could unintentionally modify the virtual views, since they are just standard Archi views and in no way protected against direct modification.

Another issue is the ease of access: I envisage having one master script that runs through all the virtual views and updates them accordingly. However, this is a manual process which may easily be forgotten which means that the virtual  views could be out of date.

Insofar, a native implementation in Archi or a plug-in might be a preferred way. However, my experience in creating Archi plug-ins is very limited and I wouldn’t really know where to start for something like that.

Before I invest much for the effort into the solution would be very much interested to align my thoughts with you regarding the virtual view feature. Maybe there is some potential for collaboration?

Cheers, Thomas

[Phil Beauvoir]

Hi Thomas,

thanks for your suggestion.

This sounds like an interesting idea but I think it wouldn't be an easy thing to implement. There's a lot going on - layout styles, layout algorithms, view types, special properties, read-only views and automatic synchronization. The latter would require fundamental changes - for every action in Archi that might affect one of these virtual views, several other commands would have to be invoked using other criteria. And there's undo/redo, how it might affect jArchi, coArchi, import/export, etc.

Off the top of my head I would rate this as "non-triivial and would take a lot of refactoring and time." :-) It would be slightly easier if automatic updating wasn't involved, but then you could do that in jArchi anyway.

Right now, we're working on stereotypes, icons and images, so I wouldn't be able to look at this now anyway, but please do continue the discussion anyway. :-)

Phil

[Thomas Rischbeck (ITMC.ch)]

Hi Phil

Thanks for your response and your thoughts on virtual views.

I agree: the automatic update of virtual views may be one of the trickiest issues - potentially with performance impact. In my naive implementation of virtual views these are updated through the central JArchi script - asynchronously. I could imagine, that the virtual view features (if implemented natively) could periodically check for changes in the model tree and only update the virtual views so often.

Anyway - you're working on another important (and wished-for) feature right now. Insofar I'll just continue to push on with the JScript solution. I guess this will help to gather some more experience and validate the concepts. I'll keep you posted on the progress. btw: GraalVM and its support for JavaScript classes is very helpful!

PS: Stereotypes, icons and images will be an excellent addition to lovely Archi!

Cheers, Thomas

[Phil Beauvoir]

Thanks Thomas, for your support and understanding.

I was talking about your proposal today with JB. We were discussing if this kind of view might be possible to generate from a "seed" of configuration/metadata information that recreates the view on demand or in response to events rather than maintaining state as with the regular views. Sort of like how the Visualiser creates a view, but with more parameters and information.

Let's not throw away the idea. As with all things Archi, we're limited by resources and person time but we can continue to brainstorm. Sometimes ideas lead onto other ideas... :-)

Phil

[Jean-Baptiste Sarrodie]

Hi,

Issue #17, that's an old one of mine ;-)

Most of this is still accurate and (even if don't have time to work on it atm) I'd really would like to have such feature in the future.

The basic idea was/is to have a kind of container (the virtual view) that stores the inputs to some view (image, table, matrix, graph...) and the name of the rendering engine to be called when the view is opened. Such view would not refresh automatically once opened in the UI, but the user could manually ask for a refresh of one or all opened views.

The trick would be to act as if the rendering is alway there, even if it is in fact only generated when used. This means that such virtual views should appear in HTML or Jasper reports and always be up to date.

In the meantime, one could use an archimate view to store the input parameters (objects and/or properties) and use a very generic jArchi script to "open" such view and in fact generate an image or HTML file opened in a new tab (embedded browser). This could even be used as part of jArchi based HTML exports (such as my single page HTML export).

Regards,

JB