Visualisation of Software Engineering Diagrams Part – 2 Rajat Anantharam Department of Gaming and Media Technology

2 Topics Discussed 1.Terminologies 2.Existing protoypes 3.Functionalities 4.Evolution of SV

3 Terminologies Program Visualization: The use of various techniques to enhance the human understanding of computer programs Visual Programming: The use of “visual” techniques to specify the program in the first place Algorithm Visualization: Visualization of a high level description of a piece of software Code\Data Visualization: Visualization of the actual implemented code Software Visualization: All of the above (together) !!!

4 The Twelve Systems Sorting out Sorting BALSA Zeus Tango ANIM Pascal Genie UWPI SEE TPM PAVANE LOGO-Media Centerline ObjectCenter – formerly Saber C++)

5 Agenda Taxonomy Detail Discussing the existing problems with software visualization Using graph drawing as a possible solution to the problems Future of Software Visualization

6 Taxonomy Detail The derivations of SV taxonomy yielded six distinct categories. They are represented in the form of a tree Though described in a single tree, each taxonomy can have sub-levels leading to n-ary tree Taxonomies building a Software Visualization System Scope, Content, Form, Method, Intersection, Effectiveness

7 Taxonomy Representation

8 In a Jiffy !! 1.Scope: What is the range of programs that the SV may take as an input for visualization? 2.Scalability: To what degree does the system scale up to handle large examples? 3.Form: What are the characteristics of the output of the system? 4.Method: How is visualization specified? 5.Interaction: How does the user of the SV system interact and control with it? 6.Effectiveness: How well does the system communicate information to the user?

9 Existing Problems with Software Visualization Very rarely the Visualization Diagrams are hand-crafted. Multiple crossings across inheritence \ class diagrams Affecting Readability Conflicts graph drawing aesthetics

10 An Approach to Solving Input: Non planar graph – multiple crossings Desired Output: A graph with minimal edge crossings. Approach : Confluent Drawing Approach to Visualizing non-planar graphs in a planar way Concern : NP- Hard Work Around : A possible solution based upon heuristics

11 The Idea of Confluent Drawings We merge edges into “tracks” so as to turn edge crossings into overlapping paths

12 Informally A curve is called locally-monotone if it contains no sharp turns and no self intersections. It contains no points with left and right tangent that form an angle less than or equal to 90 degrees. Example: A single train track Confluent drawings are a way of drawing non-planar graphs in a planar way by merging edges together into tracks which are the union of locally monotone curves.

13 Formally There is a one-to-one mapping between the vertices in G and A, so that, for each vertex v 2 V (G), there is a corresponding vertex v′ 2 A, which has a unique point placement in the plane. There is an edge (vi, vj ) in E(G) if and only if there is a locally-monotone curve e′ connecting v′, i and v′, j in A. A is planar. That is, while locally-monotone curves in A can share overlapping portions, no two can cross. Assumptions: Does not allow confluent graphs to contain self loops or parallel edges. Does not allow the drawing to make sharp turns or doube-back.

14 Drawing a Confluent Graph

15 Heuristics Existing Methods: Brute-Force method of merging individual edges to come up with a confluent drawing. Heuristic: Input – An undirected sparse graph G Output – Confluent drawing of G if succeed – fail otherwise 1.If G is planar 1.Draw G 2.Else if G contains a large number of clique\bi-clique subgraph C 1.Create a new vertex v 2.Obtain a new graph G’ by removing edges of v and connecting each vertex of C to v 3.HEURISTICDRAWUNDIRECTED(G’) 1.Replace v by a small “traffic signal” to get a confluent drawing of G 4.Else fail.

16 Application of the Heuristics Confluent drawings of k 3 and k 5,5

17 Scope for Research? The largest impediment to the use of SV by professional programmers is the issue of scope. Most are applicable to small scale prototypes – scaling is clearly a visible issue Form of software visualization still remains a big question. There are no specific standards set for this form of communication. Interaction \ Navigation \ Usability – all are more or less “subjective” concerns Non make out of the research lab – Effectiveness is a major issue.

18 Future of Software Visualization If we make progress with issues concerning taxonomies, there are obvious benefits for the fields of software engineering and computer science instruction. The potential goes beyond this to the entire domain of interactive systems, to the users as well as the programmers of interactive systems.

19 Future of Software Visualization Increasingly, the learning and use of complex systems is being facilitated by augmenting conventional textual and still graphic presentations with animation (Baecker & Small, 1990; Baecker, Small, & Mander, 1991), video, and speech and non-speech audio (Mountford & Gaver, 1990).

20 Future of Software Visualization Software visualization can therefore be applied to the development of self-revealing technology that can aid in demystifying and explaining system behaviour to users across the novice to expert continuum.

21 References A Principled Taxonomy of Software Visualization by Blaine A. Price, Ronald M. Baecker, and Ian S. Small Confluent Drawings: Visualizing Nonplanar Diagrams in a Planar Way Matthew Dickerson, David Eppstein, Michael T. Goodrich, Jeremy Meng’ 2004 Visualization Challenge Suplee, Curt, Bradford, Monica, Science, , 9/24/2004, Vol. 305, Issue 5692 Visualizing Flow Diagrams in WebSphere Studio Using SHriMP Views Derek Rayside and Marin Litoiu, Margaret-Anne Storey, Casey Best and Robert Lintern Software visualization in the large T. Ball and S. G. Eick - IEEE Computer, 29(4):33–43, 1996.

22 Thank You