[Feature Request] Add auto-layout capability to Archi : integrate Eclipse ELK framework ?

[AlexisHFr]

Description

Hello,

Laying out a complex diagram with many box and connections rapidely becomes very time-consuming : moving manualy each box and having each conection with the best path .. and redoing this again at each and every change of layout.

That's where a solution like Eclipse ELK seems a perfect fit : it propose many layout alogrithms from Tree-based to Box etc.. and should nicely integrate with Archi, isnt'it ?

https://eclipse.dev/elk/

Have you ever consider integrating this framework within Archi ?

[Phillipus]

Hi, the Elk framework can't just be integrated into Archi out of the box. It would be better to get some algorithms and then apply these using a jArchi script. I think someone already wrote some scripts to do this. I'll look for them.

[AlexisHFr]

Hi Phil,
thanks for your prompt reply,

That's indeed my current approach : a jArchi script to generate some 'basic' views and laying it out (mainly catalog or hierarchical-embedded views : juste boxes and no connections, but even there it rapidly becomes complex when boxes are not all the same size and the ELK Box layout algorithm is exactly what I'm trying to code here..).
But I think having a powerful solution like ELK should be nice for more complex views where connections paths and multiples crosssings rapidly becomes a nightmare ;)

I see ELK has a javascript "transpile" package : ELK-JS, I'll give it a try 1st or maybe try to PoC an Eclipse plugin integration by myself to see how difficult it could be...

I will post back here if I have any success with it..

Regards,
Alexis

[Phillipus]

I see ELK has a javascript "transpile" package : ELK-JS, I'll give it a try 1st or maybe try to PoC an Eclipse plugin integration by myself to see how difficult it could be...

Thanks. But a word of warning regarding Eclipse frameworks that seem to promise "magical"solutions. They are usually under-documented and half-baked. Also, even though Archi uses the Eclipse RCP it doesn't mean that another Eclipse framework can easily just be "plugged in". I've tried these things before and they turn out to be too generic, or too heavyweight.

Another consideration is to be careful about adding more dependencies on a framework that might in the future turn out to be unsupported.

[AlexisHFr]

Hi Phil,

I've invested a couple of days on the Archi/ELK integration, here are my findings so far :

• ELK is indeed a complex framework, as their intent is to provide a ui-agnostic, multi-algorithm, with optionally user-constrained/round-trip multi-pass layout ...
• the conception/codebase has I think a really well-thought architecture : my understanding is that it's an application project of the Kiel University and some senior computer-scientists spend a lot of effort on it.. yet It's another layer of complexity on top of RCP+EMF/GEF
• it comes with a few dependencies : google Guice DI framework being one of them (as they need a DI solution for the non-Eclipse version of ELK)
• their documentation is quite correct to grasp the concepts and main entry-point, but I had to dig into their codebase to make it 'work'
• their is some concerns regarding ELK support towards Eclipse RCP, cf their discussions going on for a couple of years : Fade out Eclipse Support ?, from what I see in their discussion their priority is on the Plain-Java ELK (ELK 'Core') rather than Eclipse/RCP/GEF-GMF integration, I'm not sure if it's a real concern, but it cleary means the RCP/GEF integration needs to be outside ELK.

With all that said, I have a starting point of ELK integration into Archi I could share to let you consider it, it's only a proof-of-concept at this stage and I haven't reach a stage where I can layout complex diagram but I can now see the effort needed to go that road..

To see the potential of ELK, one can use their 'demonstrator' : ELK interactive demo, you can feed the graph examples on the left by one of their complex real-word (partially-annotated with layout constraint) graph-model, eg : CarTrackingAttackModelingAllAttacksInOneModel .

I think the best approach would be to go ahead with an external-plugin to Archi (like other org.archicontribs plugins.. ?), yet I'm not sure it's that easy considering I had to change the archi.target so I could need your help to figure this out.

I'm a 'retired' java developer (being now en Ent. Architect, aka ppt-arhcitect ;) ), and didn't code for almost a decade.. so I struggled a bit to catch the RCP/GEF/ELK complexity but in the end loved this 'retour au source', and might invest more of my spare time in this project.. but would like to have your (and maybe JB Sarrodie) feedback on this : do you think such an auto-layout feature could be a nice addition to Archi ?

[Phillipus]

Hi Alexis, thanks for taking this further. :-)

their documentation is quite correct to grasp the concepts and main entry-point, but I had to dig into their codebase to make it 'work'

This is standard procedure for Eclipse projects, I'm afraid. I'm currently doing the same for the EMF Compare framework for coArchi 2 ;-(

I think the best approach would be to go ahead with an external-plugin to Archi (like other org.archicontribs plugins.. ?), yet I'm not sure it's that easy considering.

If we do try any integration it is best to provide it as an optional plug-in, as you suggest in case it doesn't work out. Perhaps you can create a POC repo here in your account on GitHub for such a plug-in? That means we can continue the conversation there.

I had to change the archi.target so I could need your help to figure this out.

Yes, you'd need to change that for development work. And the dependencies also need to be added to the runtime configuration (or added to your copy of the archi.product file.

but would like to have your (and maybe JB Sarrodie) feedback on this : do you think such an auto-layout feature could be a nice addition to Archi ?

Well, it's worth a try to see what it's capable of. /cc @jbsarrodie

[AlexisHFr]

Hi Phil,

Just a quick update on my recent progress in ELK/Archi integration (PoC).
I've forked Archi repo in my github account : https://github.com/AlexisHFr/archi

and created 3 projects to host my 3 contribs plugins : https://github.com/AlexisHFr/archi-contribs

• org.archicontribs.layout: core ELK integration with Archi
• org.archicontribs.layout.debug : debug ELK UIs : it adds a 'Layout Graph' view to see a basic representation of the layout outcome, which helps debug ELK graph => Archi objects, coordinate systems and bendpoints mapping
• tests : work in progress

Here is a 1st demo of the layout 'out of the box' of a generated view from ArchiSurance model :
ELK + Archi integration demo

There's still a lot of work and debugging to be done, but the foundation is there ..

Next steps : complete and debug the integration, then make ELK 'aware' of Archimate's specific 'constraints' : for example the Layered ELK layout could match with Archimate classic 'Layered' viewpoint with business objects above applications above technology ..

At this stage there is almost no impact on Archi code, but it will be needed I think when I'll need to persist the layout options/parameters within each views to be able to reload them for an iterative view-modification / re-layout round trip.

Stay tuned.

[Phillipus]

Congratulations on getting ELK working in a plug-in, this Eclipse stuff is not easy! ;-)

I'd be interested to know what @jbsarrodie thinks about how to layout ArchiMate views. Is the layout of a View based on a personal style, an organisational style and what, if any are best practices?

At this stage there is almost no impact on Archi code, but it will be needed I think when I'll need to persist the layout options/parameters within each views to be able to reload them for an iterative view-modification / re-layout round trip.

It's important to maintain this as a separate Archi plug-in so that it remains optional (and experimental). Specific plug-in information shouldn't really be stored in the *.archimate file for several reasons - sharing the file with others who don't have the plug-in for example, for changes seen in revisions in coArchi, and so on. If possible this kind of data should be stored in another file, perhaps a preferences file.