[vprcic]

Sequence diagrams seem like the go--to format for displaying data flow in a microservice-type environment, but even though there is a plethora of implementations in various languages and technologies that generate diagrams of this kind, they all lack certain functionalities, number one being the support for threads. Some solutions do provide the "par" fragment, but this is inadequate when message ordering corresponds to cronological ordering. Numbering messages may help, but I find it easier to grasp what is going on visually with multiple activations per lifeline (the best implementation of this I've found to date is the Quick Sequence Diagram Editor [http://sdedit.sourceforge.net/], but that project doesn't seem to be active or maintained).

I've recently tried to find a suitable solution for this on StackOverflow, but I've been rejected under the "Opinionated question" remark (::sigh::), so I could just as well do it here.

Is there a (Java based) sequence diagram generating tool/library that has the following functionalities:

. supports multiple threads and thread referencing in messages (multiple activations per lifeline)

. supports delayed messages (message trasmission and message reception can occur at different times, i.e. sending a message does not imply immediate reception on the other side)

. no custom language/pseudocode as input, but builder-style approach (I use Java to generate a text description of the diagram and then pass it to the library for parsing - I could just call the methods the parser calls and remove the unneccesary middle man)

. highly customizable visual style (PlantUML, the most flexible I've found in this regard, is notoriously bad at styling, mostly due to a lack of a coherent styling paradigm)

If not, how many people would be interested in such a thing? I may start it as an open source project myself...

[imiric]

I'm not familiar with those features, and agree that PlantUML generated diagrams have a distinctive look, but why not contribute to PlantUML instead of starting yet another project of this type? It's written in Java, so it meets that requirement.

[vprcic]

This was my intention as well so I tried familiarizing myself with PlantUML code (made a small contribution as a result), but in the end, I came to the conclusion that the overhead of getting to know its ins and outs would be greater than to get a new project to a usable state from scratch. PlantUML is, unfortunately, burdened with years of development choices that make it tough to modify in a way to conform to what I need. Most of these functionalities were (I'm 100% sure for the multiple threads and customization of the visuals), at some point, mentioned in various forum discussions as "possibly under development" by the developer, just to be followed with years of silence on the topic. And if they aren't able to deliver those, I'm not going to be, for sure.