It's a simple list. PDQ is specified programmatically by creating a textual list of queueing resources (or nodes in PDQ parlance) using the CreateNode() procedure, a list of workloads (or streams in PDQ parlance) using either the CreateOpen() or CreateClosed() procedure, together with a list of which workloads use which resources via the SetDemand() procedure. It's a rather remarkable property of the way PDQ solves the queueing circuit, that only a scalar representation of intensities is required. Scalar means magnitudes only, no direction (like a vector) is needed. Simply put, the order in which things are calculated matters not.
Unlike event-based simulations, PDQ does not use a directed (acyclic) graph to solve the queueing model. Therefore, you do not need to specify directed arcs between nodes. In a simulator, you often need to tell it things like: If this condition holds, then send the token to resource-A, otherwise go to resource-B, and so on. In this case, a visual representation of the workflow can be very useful (although not all simulators provide a GUI). This difference is tied up with the fact that PDQ solves the queueing model assuming that it is already in steady-state i.e., how things look in the long run. Therefore, any instantaneous view is lost in the long-term averages. Logic like, if-then-else correspond to an instantaneous decision point which is swamped by the long-run view of PDQ.
Another reason for not creating a GUI has to do with the fact that even commercial analytic modeling tools e.g., BMC Perform-Predict and TeamQuest Model do not have a GUI showing the layout of the queueing nodes. Those tools auto-build the models based on taking an inventory of physical resources e.g., CPUs and disks, and assigning one queueing node per physical item. This is both a boon and a limitation of those tools. The results of the modeling calculations are usually displayed as plots using a GUI but the queueing circuit is never shown (because it would just be a list).