Kiedyś więcej pisałem diagramów, ale teraz już nie muszę, bo zwykle jestem w stanie sobie wyobrazić jak to będzie wyglądać. Więc po co rysować (no chyba, że dla dokumentacji).
Chociaż nie zawsze wszystko ogarniam umysłem, to wtedy owszem, mogę coś narysować, albo np. opisać rozwiązanie w pliku tekstowym - taki dialog ze sobą-wewnętrzna burza myśli, i np. opisuję w takim pliku jakbym to rozwiązał (normalne zdania po polsku albo po angielsku) i piszę przykłady użycia modułów, itp. (tzn. piszę wtedy kawałki kodu, ale takie, które w żaden sposób się nie uruchomią, tylko spełniają rolę pseudokodu).
Czasem też prototypuję rozwiązanie, robię coś działającego, ale bardzo szybko i byle jak, po to, żeby jak najszybciej zobaczyć jakie konkretne problemy techniczne trzeba będzie rozwiązać (i w jaki sposób), jak to będzie mniej więcej wyglądać w praktyce itp. Bo jednak planować można sobie wiele rzeczy, a się okaże, że w praktyce problem jest zupełnie inny.
A potem albo refaktoruję kod na ładniejszy, albo piszę od nowa na czysto.
UML, Data Flow diagram
UML czy inne konkretne formalne techniki dobre są dla inspiracji, ale nie musisz się przejmować konkretnym sposobem zapisu. Dzisiaj i tak każdy pisze jak chce, a UML i tak wcale nie jest zbyt czytelny.