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 C1. 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 k3 and k5,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 Visualizationby Blaine A. Price, Ronald M. Baecker, and Ian S. Small

Confluent Drawings: Visualizing Nonplanar Diagrams in a Planar WayMatthew Dickerson, David Eppstein, Michael T. Goodrich, Jeremy Meng’

2004 Visualization ChallengeSuplee, Curt, Bradford, Monica, Science, 00368075, 9/24/2004, Vol. 305, Issue 5692

Visualizing Flow Diagrams in WebSphere Studio Using SHriMP ViewsDerek Rayside and Marin Litoiu, Margaret-Anne Storey, Casey Bestand Robert Lintern

Software visualization in the largeT. Ball and S. G. Eick - IEEE Computer, 29(4):33–43, 1996.

22

Thank You