CS 7390 - Software Visualization

Questions for Presentation 3 - SV Specification

• As regards to viewing algorithm and animation as two separate problems: Wouldn't it be efficient to share relevant data structures/semantics across the two components of the resulting system ? If they are not shared, then it might result in replicating the same information twice, or having a "thicker" communication channel between the two components (possibly as a large number of arguments for a function call).

• How can systems such as Dance be improved so that it is more flexible and customizable for a more common use?
• How do you sychronize two "functions" and show the animations at the same time matching each iteration for comparison?

• In Chapter 12, dynamic displays are stated to have two types of information:  the entity and a delta.  This seems wasteful of space.  Why not have a data structure that contains one entry per entity containing the entity itself and a list/stack/queue of deltas required for animation which would provide some sort of history?  (Polka suffers from not being able to reset a visualization).
• In Chapter 13, it seems that the programmer must program independently of the visualization effort and that the animator must somehow divine which program states will be mapped to the graphical objects, possibly without proper queues from the programmer.  Does it not seem that, rather than having both development units isolated, that both the programmer and the animator must work together?

• The idea of separating software development and its animation as much as possible is only appropriate for system design purpose, right? With respect to implementation, I don't think one can create a nice and accurate animation without a thorough understanding about the software.
• Would like to hear more about the advantages and limitations of using DANCE and Lens system.

• Separation of visualization and programming activities seems to simplify the visualization process. However, when the code changes or when very different algorithms are being tested, does the visualization need to be altered? And if so, how is this to be done?
• Declarative programming sounds attractive, since it does a good job in decoupling the visualization and programming tasks, and its potential in visualizing the concurrent computations. Can it replace the idea of annotating interesting events in design visualization tools?

• Does the fact that "interesting events" are distinct semantic elements mean that this technique is not as useful for viewing continuous algorithms? Do algorithms change when they are "quantized"?
• Are visualization techniques more appropriate to certain classes of algorithms than others, or is this merely a side effect of the large amount of attention that has been paid to those classes of algorithms?

• How difficult is it to form all of the rules necessary for a declarative visualization? For the simple examples, this seems fine. But for some of the complex ones, I think I would have difficulty.
• Why haven't visual debuggers like Lens caught on? I think I would find such a thing very usful.

• The example of fixpoint has "old.node" What is the sematics of "old"? What is going on in this example?
• A two-level mapping is described. Please describe a simple example of this. (figure 7 is too general).

• Can we write an algortihm in terms of events only, and animate it?
• Can we combine the lessons from Dance and Lens to develop animations?

• Declarative is obviously good for general visualizations and fast prototyping. But can it be used efficiently for more specific or intensive visualizations?
• How does one decide what to visualize, or what the interesting events will be? And why does it seem like we are limited to focusing on the visualization of algorithms at this point?
• For the readings today, it seems like the main battle is with trading off ease of use and learnability with power and specificity. Is this worth it, and do we necessarily have to make these concessions?