I want to generate python code based on UML/SysML. The coding is mainly imperative - calling functions that deliver results, switch states and some main part.
How can I create some simple main program, that contains my logic (again primitive: some input gathering function, some processing function, some output writer function)?
In Enterprise Architect I see no way without classes, objects etc. In this near-to-hardware/functional safety area there is no need for OOP stuff, inheritance, polymorphism. But it seems all the activity diagrams, sequence diagrams etc. are unusable. Has anybody proposals how you can bridge this gap with a model based approach?
1. How to model in UML an inherently imperative / procedural design?
If you have a processing flow such as:
you can very comfortably design it using activity diagrams. They have everything what you need to describe a complex processing, decompose it it smaller step, and regardless if it is composed of sequential or parallel parts.
Activity diagrams even allow you to document the flow of input/output data thanks to the object flow (but you would use data structures rather than encapsulated objects.
Very probably, you would also be interested in data structures, even if you're not in the OOP world. In a procedural way, you generally define some data structures, and have some functions that aim to manage the data structures. Although, it's not always as clear-cut and encapsulated as in OOP since you can easily have a function working on several data structures at once.
But you could benefit from modeling the data-structures as if they were classes, in light class diagrams, eventually without any operation, and even if it' not as central as in OOP.
Now if you have some functions/procedures which are very dedicated to a data structure, nothing prevents you from indicating them in the UML class diagram as an operation, even if it's not OOP. At least it'll show that some unctions/procedures are dedicated to some data structures. This is routinely done in database modelling, where pure data tables are shown as if they were a class, and database triggers, related to such tables are shown as operation, event if triggers are not OOP at all.
2. Generating code
You might not find something that works out of the box, for your language. I'm not sure that your need is of economic interest for the UML tool-makers who target primarily OOP.
However, it's not more difficult to generate a C struct, a Pascal or an ADA record than a C++ or a Java class. And if the tool makers don't offer it, you could imagine at least some systematics.
The activity diagram code generation should be more straight-forward, since its concept are more OO agnostic than other UML concepts.
Lastly, state diagrams should also be an interesting tool for you. Many code generators out there work on state machines. YACC, Lex, Bison, & co are in fact tools that construct giant state machines out of a language grammar, generate automatically state transition tables, and from there, generate code that nobody could produce manually. Again, this is not something reserved for the OO world.
Conclusion
UML can be a useful tool for modelling your design, even if you're not in OOP and if your design is more procedural. It's just that you will find less automation for moving to the implementation. (But I have the impression that code generation and roundtrip engineering is not so frequent in OOP either).