Displaying IDL Instances

Debug&ring a complex system can be aided by displaying the internal data structure ~ manipulated by the system. Vle ex~unine one generic Unix tool and four EDL.epeci~c too/s, ffocuss/ng on their functionality and ability to h~ndle large data structures Er~cefufly. One o~en cited advantage of using [DE in the implementation of complex systems is that it can aid in debugging [Lamb 1983]. The soRware system is partitioned into • collection of IDL processes, each of which may be debugged individually. Each process is tested be examining the output(s) produced from given input(s). It is no longer necessary to debug the system//near/y, where a process is debugged only after the processes producing the data structures needed by the one process are debugged. Instead, debugging can proceed concurrently, since input test cases for each IDL process can be generated by hand. This paper examines one aspect of the debugzing task, that of viewing instances of IDL structures. The problems encountered involve functionality and scale. The obvious solutions are difficult to use of instances of medium size, ~nd are impractical on large instances, which unfortunately are common. We will examine a range of approaches. Two examples will be used. Example A, from [Warren et aL 1986], is quite short, containing three nodes and 18 a~tribute-value pairs. Example B is somewhat larger, containing 103 nodes and 309 attributes. 1 The ASCII External Representation Instances of IDL structures can be written to external storage in a variety of formats. Every hnplementation is required to support the ASCII Ez~er=~i Rep,~e,~ta~ioa La.gu~ge, in which an arbitrarily graph-structured instance may be encoded as a linear char~ter sequence in a restricted character set. This representation allows users to create IDL instances via a conventional text editor, and supports viewing via conventional text outputing commands. Example A in this representation is shown below.-- file billing/customers.in