pyreverse should include global functions in diagrams

[MaxG87]

Currently, pyreverse only considers classes in its UML diagrams. Right know I have a generated diagram open that shows inheritances and who is member of whom.

I would like to have pyreverse include module level functions in its UML diagrams too. I would like to see which function call each other and which classes are involved how.

Module level functions occur very frequently in normal Python code, so it is impossible to judge the dependency structure without seeing it.

[PCManticore]

Hi, thanks for creating an issue. Would you be interested in contributing a patch for this? pyreverse is a great tool but at this moment it's not a focus of the pylint team, so having this implemented by contributors would make it land a lot faster.

[MaxG87]

On 19-11-29 07:34:35, Claudiu Popa wrote:

Hi, thanks for creating an issue. Would you be interested in contributing a patch for this? pyreverse is a great tool but at this moment it's not a focus of the pylint team, so having this implemented by contributors would make it land a lot faster. I have no capacity for this at the moment. I am sorry.

[ELC]

Any guidance on how to get started on this?

[DudeNr33]

Hi @ELC first of all thank you for offering support, much appreciated!

For this specific issue we should start with a specification what we want to achieve. Currently I have the following questions on my mind that I think should be answered before starting with any implementations:

• We currently only generate class and package diagrams. From my understanding the original author wanted to include this in the class diagram. However, UML class diagrams (afaik) do not have any "standard" entity that represents a standalone function. So we first have to decide how to represent them, in a way that works for all output formats (DOT, PlantUML, MermaidJS)
• Should every module level function be a separate entity in the diagram, or should all functions of the same module be put into the same entity (e.g. you could think of the module being a 'class' in a class diagram, and the module level functions the class' methods)?
• How would this translate to the existing class diagrams? We currently only show associations between classes if one class has an attribute containing the instance of another class. However we do not show if one class just calls, let's say, a classmethod or staticmethod on another class. I feel like if we implement this feature for global functions, it should also work for classes and method calls
• Last but not least, for the information we want to see ("which function call each other and which classes are involved how"), is a static representation (class diagram) really the best solution, or would a dynamic representation (sequence diagram, activity diagram) be the better choice?