UML is not a graphical programming language. Transforming C++ in UML will do no magic in this regard.
Recommendation
- The first thing that you need to do, is to reconsider your problem and find out what is worth to show visually and what
you expect from the visualization.
- At the same time, if you have a lot of static global variables, your source code encapsulated some internals at the level of the compilation unit. So even if you have no objects and classes, you have somehow a component and could see your source file as component.
- Now, if you manage to do this, one step further could be to consider the component as an instance of a class. This could allow you to start introducing some OO design into a bunch of free standing jungle of functions.
- Alternatively, you could consider every freestanding function as a stateless class. But this might lead to an overkill and bring us back to the question if visual programming is really a good idea for your problem.
How UML can help?
If you want to show the flow of control, that starting with some objects gets some behaviors and generates a flow of objects, you may consider using an activity diagram. Functions would be actions:
- but you might just end up with a kind of more elaborate flowchart diagram : you might express with more work things that could be easier expressed in code;
- on the other side, viewing a very complex flow may allow to better understand how the parts relate together, and even identify parallelisation opportunities.
If you want to show the structure of your module, and the exposed API, you may consider:
- a component diagram could help you to abstract the interface and purpose of your different modules or submodules (e.g. compilation units);
- a composite structure may focus on the inner structure of your modules: the parts may represent named objects (variables). But nothing is foreseen for functions, so you’d need to handle them as a parts as well. I’m not sure that it’s the best thing in your case
- a class diagram could be used to show how the static globals relate to a group of related functions, especially if these are
embedded in their own namespace.
Personally, from what I understand of the partial information on your case, I’d opt for the last approach: even if you would have no class in your implementation, at a conceptual level they seem to be there. And this could then help to develop a more object oriented design, breaking down larger modules in smaller "classes", focusing on their public interface, and making them interchangeable.
<< ... >>thing) on the class itself, e.g.<< static >>or<< globals >>to modify the meaning of the element (just explain it in some accompanying text). Stereotypes are there to allow you to extend UML.- - - - ->, as that doesn't imply that the dependent end holds a reference, just that the names of the global functions and/or the global variable are mentioned somehow.