1 / 16

Visualization

Visualization. Program v isuali z ation. Debugging programs without the aid of support tools can be extremely difficult. See “My Hairest Bug War Stories”, Marc Eisenstadt, Communications of the ACM, Vol 40, No 4, April 1997, pp 30-37.

plaw
Download Presentation

Visualization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Visualization

  2. Program visualization • Debugging programs without the aid of support tools can be extremely difficult. See “My Hairest Bug War Stories”, Marc Eisenstadt, Communications of the ACM, Vol 40, No 4, April 1997, pp 30-37. • This article makes it clear that the potential sources for bugs in software is enormous and that tracking them down is both costly and time consuming • Clearly it is preferable that we do not put bugs in our code, but we are all human... • Software visualization, or program visualization, can assist programmers to better debug, maintain and understand the behaviour of their programs and thereby track down bugs through the use of graphically presented information. • Program visualisation is a technique to manage complexity. CS351 - Software Engineering (AY2004)

  3. Program visualization • The paper “Aspects and Taxonomy of Program Visualisation”, M.J. Oudshoorn, H. Widjaja, and S.K. Ellershaw, in Software Visualisation, P. Eades and K. Zhang (Eds), World Scientific, 1996, pp 3-26, provides an overview of the current state of the art with respect to program visualization. • We aim to use pictures to convey meaning clearly and succinctly. • Humans perceive pictorial representations more quickly than textual ones. • Aim is to help programmers synchronise their mental model of the executing program with reality. • Knowledge of code decays as the software ages and the original programmers and design team move on. CS351 - Software Engineering (AY2004)

  4. Principle of immediacy • Minimise the separation between cause and effect. This can occur in at least three dimensions: temporal, space and semantics. (“Debugging and the Experience of Immediacy”, D. Ungar, H. Lieberman and C. Fry, Communications of the ACM, Vol 40, No 4, April 1997, pp 38–43). • Temporal immediacy • In debugging it is important to reason backwards from effects to causes. Temporal immediacy helps track down faults. • Spatial immediacy • Physical distance between causally related events is minimised. Events widely separated by space on the screen require users to conscientiously link them, forcing them to shift attention and putting additional strain on their short-term memory. CS351 - Software Engineering (AY2004)

  5. Principle of immediacy • Semantic immediacy • The conceptual distance (eg., number of mouse clicks) to get between semantically related pieces of information is minimised. • These issues of immediacy are also relevant in program visualization. CS351 - Software Engineering (AY2004)

  6. Program visualization model Run-time control Static model Dynamic model Programmer’s control Program visualisation Programmer’s mental model Correspondence searching Executing program model CS351 - Software Engineering (AY2004)

  7. Basic properties • Three basic properties of software can be visualized: • Software structure. • Run-time behaviour. • The code itself. CS351 - Software Engineering (AY2004)

  8. Ideals • The ideals of a visualization system are: • From the system’s perspective: • Scalability. • Extensibility. • Portability. • From the user’s perspective: • Minimal disturbances to the user’s program. • Little or no programmer intervention. • Handle real-world problems. • Present the “right” things to the user. CS351 - Software Engineering (AY2004)

  9. The “right” things • Provide multiple views of multiple facets of the program. • Give information to the user rather than rationalise it. Let the user discover things about the program. • Appear aesthetically pleasing, but not use graphics as mere decorations. • Organise information appropriately - hierarchical views, for example. • Provide the user with appropriate control over the views to navigate quickly. CS351 - Software Engineering (AY2004)

  10. Mechanisms • Instrumentation and data collection are the first steps. • Instrumentation is often done through the insertion of probe statements into the user code. This can cause perturbations in the behaviour and timings of the user code – this is inevitable, but should be minimised. • Visualizations may be provided to the user on-the-fly or via a post-mortem analysis. Post-mortem analysis allows the collected data to be manipulated before it is displayed to the user (eg., reordering, clustering, …) CS351 - Software Engineering (AY2004)

  11. Displays • May be related to the static structure of the code. Helps the user relate dynamic behaviour to the static code. • Graph-based • Generally used for simulating, and representing program activities. • Statistics-based • Typically used for showing performance data. • Source-code related • The source code structure is presented through flowcharts and Nasi-Schneiderman diagrams. CS351 - Software Engineering (AY2004)

  12. Distributed Parallel Taxonomy Visualisation Software Hardware Architecture Uniprocessor Multiprocessor Operating Systems Programming Language Application CS351 - Software Engineering (AY2004)

  13. Sample view CS351 - Software Engineering (AY2004)

  14. Software visualization for debugging • “Software Visualisation for Debugging”, R. Baecker, C. DiGiano and A. Marcus, Communications of the ACM, Vol 40, No 4, April 1997, pp 44–54. • In addition to graphical representation of program behaviour, animation can be used to demonstrate algorithm behaviour. This typically requires the programmer to manually animate the algorithm! • Auralisation may be another technique which can be employed to help improve program understanding??? CS351 - Software Engineering (AY2004)

  15. Software visualisation for software engineering • “Software Visualisation in the Large”, T. Ball, S.G. Eick, IEEE Computer, April 1996, pp 33–43. • There is a need to visualize more than just code and behaviour in order to understand large and complex software systems. • There is no reason why program visualization techniques cannot be applied to other aspects of the software engineering process: • When each line was last modified. • Which programmer wrote which sections of code. • Where bugs and bug fixes are located. • Complexity analysis (eg., conditional nesting complexity). CS351 - Software Engineering (AY2004)

  16. Software visualization for software engineering • Code profiling. • Execution hot spots. • Dynamic program slicing (ie., determine the code that impacts on a statement or procedure call within a particular program execution). CS351 - Software Engineering (AY2004)

More Related