New Model Visualisations

[git-afsantos]

Develop new views for the extracted models, allowing better user interaction and better analysis of the system from different zoom levels. For instance, view only the node graph, without specifying topics or services.

[asmodehn]

Hi, I just arrived here after browsing around, looking for ways to generate architecture diagrams from an existing implementation, so I was wondering if you did consider relying on already existing software architecture tools, mostly for the visualization aspect, but maybe also for the "how to describe a software architecture" aspect (somewhat still a research area).

For example, one I am thinking of currently is the C4-model (it has this "zoom-level" concept embedded). https://structurizr.com/ already has a DSL, and a set of existing tools to generate various visualizations, depending on your audience, and there are probably others out there...

[git-afsantos]

Thanks for the tip! Adapting the current concept of a ROS computation graph to the four levels of the C4 model is not trivial, and might require some additional work to populate the lower levels of abstraction, but it is a good starting point.

I will definitely look into Structurizr. I already have JSON/YAML models, so it might just be a matter of converting between formats.

[asmodehn]

The way I see it, one of the main "anchor point" is :

Level 2: Container diagram Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data.

This matches the running concept of an executable, ie a 'process template' (a running instance can easily be inferred by the brain from that process template IMHO), so that is a 'node' in the ROS context... but we must be careful about things like nodelets : aggregating multiple things (components) into one node...

The component level is not trivial, as in it will depend on the language used, the patterns the developer used (class, nodelet functor, etc.). Maybe it is best to not do much in that space ? or simply rely on existing tooling for a language (I m thinking of python packages&modules that can be tested and documented automatically with doctest & unittest). There is also probably a way to support "ROS practices" here though, even if just for a specific programming language... maybe this could be a ros package ?

The system context level is also not trivial, but mainly because of "people's perspective". I see this more as tying it into "System Design" practices like DDD, etc. so maybe something that is more tied to documentation structure ? I'm thinking sphinx docs for python packages, maybe ROS documentation could be at that level as well ?

Anyway I should try HAROS on a running system to get a clearer idea, but I am anyway interested in following that up. Let me know if you figure out something in that space...

Disclaimer: I am the main developer of https://github.com/pyros-dev (although currently on hold, I'm hoping to get back into it sometime soon...) and I am interested in the broad "software architecture for cybernetics systems" topic, while keeping a foot into various programming language de-facto workflows (f.i. system programming C++ and application programming Python are two different domains, with different set of practices, that are often very mixed up when developing with ROS).

[git-afsantos]

Hmm, I see. In the context of pyros and broadening the use of ROS in generic application environments, these conventional tiered architecture models would likely be more helpful.

I should try HAROS on a running system

Note that, at the moment, it works only for ROS, not ROS2.

Level 2: Container diagram

I agree that this is the most straightforward starting point for a model transformation. The levels above and below might get fuzzy and somewhat dependent on user preference.

we must be careful about things like nodelets

The current version of HAROS displays nodelets as if they were independent nodes - which, in concept they are. The fact that nodelets inhabit a single node is treated as implementation details. But I can see that this might not always be desirable. A good solution would be some kind of toggle, so that the user can select whether to nest nodelets under a single node (i.e., nodelets are components), or to unfold them (i.e., nodelets are containers).

The component level is not trivial, as in it will depend on the language used

Most likely, yes. Otherwise, the best we can do is to define common abstractions - e.g., there are classes both in C++ and Python, C++ namespaces can correspond to Python modules or packages. However, if not done right, it is likely that some users will not like the end result.