Va bene. Quindi, espandendo ulteriormente la risposta di @ Ister, in base ai commenti, ho concluso di fare quanto segue:
- Modella i miei moduli come classi statiche come suggerito da @esoterik.
- Scegli i diagrammi UML che sembrano pertinenti.
- Espandi i diagrammi con le mie convenzioni per renderli più descrittivi. come indicato da @DocBrown.
- Se in ogni caso, l'UML si è rivelato inespressivo, posso inventare la mia notazione. Come @esoterik e @KaspervandenBerg hanno suggerito esplicitamente.
Anche se questo sembra essere piuttosto raro, dato che non abbiamo regole rigide su come utilizzare i diagrammi UML, quindi possiamo utilizzarli intuitivamente per adattarli in base alle nostre esigenze.
There is no "law" which forbids you to replace the names of objects by the names of modules involved.
Il principale punto di confusione era che UML utilizzava effettivamente un approccio di progettazione orientato agli oggetti, mentre python non sempre si adattava a questo, specialmente quando si usano le funzioni standalone. Ma non dovrebbe essere un problema.
Also even if you don't follow OOP principles fully it's good to keep them mostly regardless if the language you use enable that or not. It's beneficiary in the long run (easier maintenance). And in every language, you can write OOP-like style.
Mentre mi dilungavo su come le persone usassero UML con Python, ho raggiunto il fatto che quasi nessuno progetta un software prima che sia sviluppato in python; almeno non con UML! Utilizzano invece i generatori UML quando il codice è pronto, che ha i suoi svantaggi.
Python objects can be extended at runtime, and objects of any type can be assigned to any instance variable. Figuring out what classes an object can contain pointers to (composition) would require a full understanding of the runtime behavior of the program.