Niedawno przeprowadziłem kilka schematów blokowych i zmagałem się z tym samym problemem, jak prezentować wywołania podprogramów, a może także wywołania metod i funkcji, jak można je teraz nazywać.
Uznałem konwencję, że oddzielam podprogram POŁĄCZENIA od podprogramu REFERENCJE. W przypadku pierwszego używam zwykłego prostokąta pokazującego wywołanie wraz z argumentami, używając zmiennych, które obowiązują w tym momencie podczas wykonywania programu.
Używam dwustronnego prostokąta „predefiniowanego procesu” po prostu jako odniesienie do innego schematu blokowego, który zawiera definicję tej funkcji lub podprogramu. Prostokąt podprogramu nie musi pokazywać argumentów podprogramu, ponieważ jest to część schematu definiującego podprogram, o którym mowa, ale pomocne może być dodanie go już w odwołaniu, aby ktokolwiek go czytał, mógł zobacz znaczenie rzeczywistych argumentów użytych w wywołaniu.
Zwiększa to liczbę prostokątów, ale czyni jaśniejszym, że te inne schematy blokowe istnieją, aby wyszukać definicję niektórych wywoływanych funkcji. Często, jeśli funkcja jest prosta, nie utworzę dla niej osobnego diagramu, ale po prostu udokumentuję go ustnie.
Używam również symbolu „dokumentu”, aby powiedzieć, że szczegóły powinny być wyszukiwane na liście kodów.
Celem schematu blokowego nie jest dla mnie tworzenie programu, ale ułatwienie innym zrozumienia programu. Myślę, że pomoc należy postrzegać z lotu ptaka i należy pamiętać o tym celu. Nie służą one do wizualnego opisu KAŻDEGO szczegółu programu, szczegóły są widoczne z kodu w razie potrzeby. Schemat blokowy to tylko jedno zdjęcie twojego programu z punktu widzenia wysokiego poziomu.
Utrzymanie wysokiego poziomu schematów blokowych oznacza również, że nie ma potrzeby aktualizowania ich w miarę modyfikowania kodu.
To są zdjęcia. Jak każda dobra historia, dokumentacja oprogramowania powinna również zawierać zdjęcia, które dają alternatywny punkt widzenia na kod.