Class Diagrams With The Vizzanalyzer Tool Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

There are two different tasks in explaining a software in detail. First, analyze the Software and assess the quality of that software. Then present those results to the software engineers.a tool, VizzAnalyzer is used for the detailed examination and illustration of software. Its illustration does not allow for a qualitative diagram representation. Therefore it is problematic task for others to understand it, and we need to explain the meaning of non-standard diagram elements.This problem can besolved by using a qualitative or standardized representation. UML is such a assemblage of instinctive diagrams with standardized elements.The VizzAnalyzer is a tool extended by this research allowing it to view software systems as UML Class diagrams. It reprocesses the existing plug-in architecture to attach the analysis tool with Yed,which is a graph visualization program. The plug-in is accountable for exchanging the data between the two applications.

A UML Class Diagram Model is defined to solve this conversion,the mapping function between this model,the Common Meta-Model used by the VizzAnalyzer and our Class Diagram Model. After that, we export this Class Diagram Model to a format that is suitable for yEd to display.

Now we have done the generation of Class Diagrams with the VizzAnalyzer tool .A better communication of the results  derived by varient examination with the software engineers is achieved.

The progress of different alternatives of research access in detecting out the answer for the problem mentioned is described by this study.


1. Introduction:


It is a complex task to develop a software. The process of developing a software typically includes out of a number of stages (among others, analysis, scheme, accomplishment and experiment).At present it is so difficult to develop a software that a single engineer cannot solve it. Therefore these complex tasks are being implemented by the cooperation of individuals in teams. As the actions which need to be carried out are significant and needs     the sharing of intricate knowledge, it requires that the software engineers should have a high amount of communication among the involved individuals in each of the phases.There are several formal and informal techniques developed to help the team members to interact effectively with each other and understand the requirements, design and implementation regarding the software.


In order to communicate the relevant information within a team and document the software a language known as UML is used. It is an assemblage of varient kinds of diagrams that are designed for modelling a software system.  The class diagrams are commonly used for this UML diagrams. The static structure of the software system, portray of its parts and their relation is represented by the class diagram.


It is hard to predict the existance of a software. As the necessities alter with time , the software has to be adapted to meet the new requirements and to accomodate to the changed environments. "Different studies confirm that  the cost for claiming the software represents between 50-90% of its total cost "(Foster, 1991).


Several researchers are been studying ways to assess and assure software quality to minimize the maintenance costs. "Among others is a Standard and Metric-Based Software Quality Model. With the help of static analysis and software quality metrics it helps to appraise the quality of the software "(Rudiger, 2007). " The VizzAnalyzer tool has the designed analysis implemented in it; thus it permits to analyze the software systems for design patterns and anti-patterns, to obtain cycles or the death code "(Welf and Thomas, 2005). It is necessary to communicate the results of these analyses with the software engineers possessing a specific software system in an adequate manner.

1.1 Aims and Objectives:


This  segment describes the objectives followed up by this study to solve the problem and the factors used for substantiating the goals:


·       Firstly the VizzAnalyzer is extended to visualize the contained data as an UML Class Diagram. The contained data  should contain the relevant information to generate the class diagram which is prerequisite. When the data is displayed as classes and relationship between them in a UML 2.0 conform way,then the goal is met.The fields and methods are included in the classes. The type and visibility information are included in the fields. The methods comprise parameters, return values and their type . The relations identified in the code and aggregate multiple relationships will be corresponded by the relationships.


·       The second goal is to produce a sketch of the output diagram, the entities and the relations shall be  held in the diagram on their own. When the classes are placed without overlapping, and the relations don't cross any class,then the objective is met.It is desired to have minimum crossing edged and bends.



·       The third goal is to allow the interaction of the user with the plug-in. The user should be able to decide the visibility needed to be displayed, and the relations that should be generated.

 2 Literature review:


VizzAnalyzer is developed for the analysis and visualization of programs and thus it is a reverse engineering framework. The VizzAnalyzer was originally developed for serving the purpose of  helping researchers in the investigation and innovation in the fields of software analysis and metrics.


Figure 1 shows the process of Software analysis and visualization. It  includes three main steps.They are:


Firstly, with the help of parsers the information is extracted from the source files which is then retrieved as the syntax tree and contains the exact information as in the sources files.


In the second step, a process for converting the information from the Base Model into a suitable format to perform later analysis is done, the Common Meta-Model  is described below.


Finally this information needs to be displayed once it is analyzed.For the visualization domain the information is converted again to a suitable Model .In the final step it is essential to convert this model to the specific format of the tool which is used for visualizing the information.


                      Figure 1: Software Analysis and Visualization Process (Welf and Thomas, 2005)



2.1 Common Meta-Model:


To represent the software properties necessary for calculating metrics the Common Meta Model (CMM) is intended . This model is based upon the Meta-Model theory. This theory is useful in defining an abstract representation of a software system at different levels of abstraction: The top layer is meta-model, and the most abstract information of software is represented by it, the Meta-Model is placed below this layer which is a middle representation between the source code and the Meta-meta model. The Model shown as the Base Model is the lowest layer.


2.2 GRAIL:


For managing graphs a graph library is developed, known as graph implementation. Different representations as well as different algorithms and filters that can be applied to the graphs are provided by it. For this context of research, it is used for reading and filtering the information that is described in the Common Meta Model.




2.3 UML Class diagram:


A program is a list of instructions that handles data affiliated with it .The program is seen as a collection of "objects" that collaborate together with the object oriented paradigm .All the objects are capable of taking messages, processing data, and sending messages to eachother. The abstract characteristics of the "objects", its characteristics (the data) and the things it can do (the behaviour) is defined by a class.

The software is represented by using diagrams. A graphical view of the types of objects in the system and the various kinds of static relationships that exist among them is achieved by the class diagrams.The classes are represented by rectangles in the diagram, which show the name of the class and optionally the name of the operations and ascribes.To divide the class name, attributes and operations ,compartments are used. To distinguish the different kind of relations,the relations are represented as lines with special arrows or symbols in the extremes.


In the class diagram, the class properties (the data) has two different notations , which can be shown as attributes or as associations.Within the class box itself, the attribute notation describes a property as a line of text . "Visibility name: type multiplicity = default_value {property-string}" is the full form of an attribute. A solid line between two classes is the association notation which is directed from the source class to the target class. The name property goes at the marked terminal of the association, together with its diversity.


Figure 2: Different representations of a class property (Gutwenger, Junger and Klein, 2003)


Within the class box, the notation for the operation describes it as a line of text, in the operations containment. "Visibility name: (parameters list) return type {property-string}" is the full form of an operation. In a similar way to attributes, "direction name: type = default_value" and separate by ",the parameters in the parameter list are noted.


 A part from associations, generalization, realizations and nested classes can be the relationship between the classes. Hierarchy between classes is represented by generalization; it is shown as an arrow with a white triangle arrow head. A class that implements an interface, shown as a generalization but with a dashed line,is represented by the realization. Between classes, nested classes is a relation. The notation for  a class defined inside another class is an arrow with a cross circle at the terminal of the outer class.


                                     Figure 3: Different UML relationships (Michael, 1996)

In the previous image the use of the relations is shown. In that example, from Controller and Embedded Agent (multi-inheritance) ,the SetTopController inherits and implements the interface URLStreamHandler, which is shown as an association of type Power Manager.


Many elements exist in a class diagram, but references are made to concepts that involves the behaviour of the system, like compositions or aggregations, otherwise it becomes difficult to translate into the source code, like n-ary associations.


2.4 yEd:


A graph editor which is programmed in Java is yEd ,which uses lightweight widgets. Drawings can be quickly and effectively shown and automatic layouts can be applied to a range of different diagrams by using it. The yed  has a freeware license. In order to visualize its own data VizzAnalyzer uses it.The visualization of UML Class nodes and UML relationship edges are allowed by the last versions of the program.


3 Research Approach:


The approaches to solve out the problem mentioned are described in this segment. The issue mentioned is split into two sub problems;

 Firstly,a Class diagram Model should be obtained from the data contained in Common Meta - Model.

 Secondly, the data in the Class Diagram Model  is extracted and displayed in a formal Class Diagram.




3.1 Mapping from the CMM to UML Class Diagram Model:


We can see Class diagram as a graph, where nodes are the classes which interfaces and edges the relationships among the classes. In this step ,a mapping is defined from the elements and relations of the information held by VizzAnalyzer in the Common Meta - Model into the knowledge required for the Class Diagram, which is a UML class diagram specific meta - model.


Classes, attributes and methods are the elements of the UML class diagram specific meta-model. We can later represent this information as rectangular squares that contain information about the names and the varieties of these elements. Inheritance, Realization, Association and Nested classes are the relations between these classes.

 3.2 Visualization (Of the Class Diagram):


After the collection of data for a class diagram, we can be display it as next step. The factors for selection of  the different alternatives  in particular are:


·       The tool should be free

·       Automatic generation and design of the class diagram should be permitted by the tool

·       The tool should be fit to import a general format or have well defined its own file format, so that the data can be exported readily

·       Integration of a new version of VizzAnalyzer into the eclipse framework should be done. If this tool can be integrated,  it will be desirable that the plug - in to also to be integrated into this framework

·       The UML 2.0 confirm shall be the UML class diagrams

·       Fast implementation and good results should be allowed by this solution.


3.3 UML Layout:

In the last few years UML layout has become a point of special interest. For satisfying the needs of providing a good layout for UML class diagrams, different studies work on extending the traditional graph or tree layout algorithms. Two main approaches for this research are:

the hierarchical approach

and the directed orthogonal approach.


3.3.1 Hierarchical Approach:


On the Sugiyama algorithm, the hierarchical approach is based . This algorithm is based upon the common divide and conquers technique, using which acyclic directed graphs can be drawn. For drawing other kinds of graphs, different variants have been developed.


According to the main idea of the Sugiyama algorithm, the nodes are divided into layers, in such a way that nodes of a layer do not have outgoing edges to layers in level L or lower and after that, the algorithm reorders the nodes in each layer, trying to reduce the number of crossing edges with the previous or antecedent layer.


An UML adapted version of the Sugiyama algorithm is proposed by Jochen Seeman .There are mainly two steps in this UML layout algorithm. First, the layout of a sub graph of the class diagram is calculated, formed only for the classes, and the inheritance and implements relations, using the original Sugiyama algorithm.In the second step the rest of the classes and relations is to incrementally added to minimize the size and crossing edges.


 When the number of inheritance is high, hierarchical approach works fine. But the results are poor for diagrams with a low number of inheritance or high number of associations 


3.3.2 Directed Orthogonal Approach:


This access is based on a variety of the orthogonal layout. It is essential to find a planar portrayal of the graph. Firstly, the graph has to be planar, otherwise more complete sub graph is to be calculated. The rest of the edges are not permanently saved. A planar representation is then calculated for the graph, and the edges removed  are added trying to minimize the cross size. To place the edges horizontal or vertical in the draw,  an orthogonal process is realized, and finally the result is optimization in size of bends.


The orthogonal layout is used by the directed orthogonal approach but  when calculating the planar representation, it applies new constraints ,no nesting of one class hierarchy within another and uniform direction within each class hierarchy.  And at the end, the implementation and the extension edges at the target are merged by the layout.

It is shown by various test implementations realizing this algorithm that it offers better layouts than the hierarchical approach in almost all the cases.


3.4 The VizzAnalyzer Framework:


This background on the VizzAnalyzer architecture is discussed in this section. Parts of the architecture that are reused for the Visualization plug-in are explained in it. Finally, it explains the storage and manipulation of the  internal data of the software system under consideration.


3.4.1 Architecture:


The VizzAnalyzer Framework is a structural system. It includes the framework core, converters, and different wrappers connecting the plug-ins. The framework-core is a controller, responsible for communicating information between the different components. The converters are connected to the core and are the reusable components, The main functionalities are provided by them. One of these components is GRAIL. The connection of arbitrary reverse engineering components with the framework is allowed by the wrappers. e.g., Recoder or yEd.


The wrappers allow extending the framework. They allow for three different points: retrieval, analysis and visualization.


                                   Figure 4: VizzAnalyzer Framework (Thomas, Rudiger and Welf, 2005)


Technically ,the variation points are  realized as directories containing the plug-in classes. These plug-ins widen from predefined classes provided by the framework. When the framework starts, the directories are read and   the plug-ins are loaded. If the framework recognizes the plug-in, then a new menu entry is created in the framework and is mapped to run the plug-in.



For associating the visualization plug-in, the yEd graph editor, we need the extention of the existing yEd plug-in to utilize the proper wrapper converting the data provided as Common Meta-Model to the UML Class Diagram specific meta-model.

3.4.2 GRAIL and the Common Meta-Model:

 VizzAnalyzer uses a graph known as Grail to represent the internal data. In this portrayal of an annotated graph instantiated from GRAIL, each entity (nodes, edges and the graph itself) has a set of properties affiliated to it. Objects are used to represent these properties.


Each node (or edge)  of the Property Type represents an entity (or relation) of the Common Meta-Model. Easy retrieval of the information stored in the properties is allowed by Grail.


For navigation of the graph thoroughly or a subset of it using views the Grail offers functions. In these view, type of the objects (node or edges) that are interested can be mentioned; filtered, depending on the values of its properties. In these views, edge propagations can also be specified. This means, this relationship can be propagated to the parent node, until they are attached to a non-filtered node, if children of the current node are strained but have relationship to other nodes.


3.4.3 The Visualization plug-in:


From the Plug-in abstract class given by the core ,the plug-ins is Java compiled classes extend  and implements the PlugInInterface. An Action List property is defined by the Plug-in class. In order to call the execution of the plug-in ,this Action is used by the VizzAnalyzer. Therefore ,while initializing ,the plug-in needs to add the code which the Action is going to execute.


When the VizzAnalyzer framework starts, the predefined directories, retrieval, analysis and visualization looking for the wrappers are searched by it. Those wrappers are created and instantiated with a call to the initPlugIn () method ,once the predefined directories, retrieval, analysis and visualization looking for the wrappers  are found.


The application waits for the user to interact while running. The GUI calls the correct plug-in for execute the Action when an interaction occurs.


Via the setGraph () and getGraph () methods from the Project Manager ,the information exchange between the wrappers and the framework is controlled.  All program information is inwardly controlled as GRAIL's graphs.

3.5 Transformation process:


In the transformation process ,the data is mapped and exported from the Common Meta-Model to our Class Diagram Meta-Model. Therefore the graph representing the data needs to be traversed and retrieve the information required in the diagram.


This transformation is takes two steps:

Firstly ,over a view of  the graph which contains only the nodes relevant for the UML Class Diagram Meta-Model ,iteration is done. Then filter all the other nodes. Thus the classes participating in the diagram and the class properties and relations, e.g., associations or attributes will be known.


Secondly, for each class that has to be displayed in the diagram, all the available information needed in a class diagram are taken into consideration. Different views of the Common Meta-Mode are used by this research approach to archive this task.

 3.6 Visualization process:

For displaying the UML Class Diagram, the yEd is used. The yEd  is already used by the VizzAnalyzer as one of its visualization plug-ins. Therefore, the existing plug-in are reused and adapted our needs.


3.6.1 VizzAnalyzer yEd plug-in:


 From the Plug-in  ,the plug-in which is a Java class ,extends and  implements the PlugInInterface. The code needed for the framework for adding the plug-in to a menu entry in the user interface are contained in the Plug-in. The initPlugin and toString methods that are needed to be implemented are defined by PlugInInterface. When loading the plug-in , the initPlugIn will be called by the framework  To display the plug-in name onto the menu in the GUI , the toString is used. 

3.6.2 GML File Format:


A standard graph file format designed for easy exchange of data graphs between applications is GML File Format. It is very extensible and for each program it allows to write its own data.  Pairs of a key and a value are required to make a file. The values can be integers, floating point numbers, strings, records and lists, and the key is a string literal where the former  two must be enclosed in square brackets.


There are some standard keys like graph, node and edge, and anybody is free to add its keys to add specific information which is the key idea behind GML .


3.6.3 yEd Extension of GML Format:


Two records are defined by yEd for the storage of  information needed to display the diagrams and they are Graphics and Label Graphics. We can apply both to nodes or edges, but they have different properties.


3.6.4 Export the File:


The main necessity for the plug - in is memory consumption. Thus the Class Diagram Model is exported during its conversion. As mentioned in the transformation section, first the entire graph should be traversed to decide which class nodes should be involved in the class diagram file.


All the information needed is retrieved for each of these classes. As mentioned earlier, a box with 3 containments for the name, attributes and methods is used to represent a class in UML. As there are non proper representations available in free versions of yEd, the UML class representation is simulated by drawing the node as rectangle and writing the label using HTML. For separating the containments simulating the class node, this allows writing horizontal lines.

After the retrieval of all the information of a class; it is represented as HTML, and stored into the file instead of holding it in the memory.In the memory, only the relationships between the classes need to be temporally, because in the GML file, the nodes need to be written before the edges.


After writing all the classes into the file, write the relationship (the edges) with the appropriate style and arrow. Only the label position on the associations is modified, for displaying it in the target and not at the centre of the edge.


4 Discussions:


Class Diagrams are much broadened nowadays for the visualization part, and there are lots of tools considered for generating a visualization of UML. For the manual generation of the diagrams, most of these tools are taken into account and automatic layout is allowed by few of them, but unfortunately none of them are free.

Additional algorithms are required  for manipulating the graph necessary for the layout algorithms which makes its implementation difficult. The required time is out of the scope for this research.


This study is to visualize the information held in VizzAnalyzer as a UML class diagram. A complex tool is not required for handling the diagrams .Since a graph can be used to see a class diagram, a tool can be used for visualizing and arranging the graphs, if it allows special sketching of nodes and edges.


yEd is used as one of the main visualizing tools in the current VizzAnalyzer. This tool permits the insertion of some UML drawings and Directed Orthogonal Layout is also offered. By using the horizontal rule it can simulate a class node and hence make the normal nodes look like UML class nodes.


5 Conclusions and Future Work:


5.1 Conclusions:


The main objective of this research was to provide VizzAnalyzer with visualization plug-in for displaying the software system analyzed in the VizzAnalyzer as UML Class Diagram. Three goals are defined to solve this problem, that the plug-in has to meet to solve the problem:


·      The first one is to widen the VizzAnalyzer to visualize the contained data as an UML Class Diagram. The necessary condition for this goal is that relevant information should be associated with the contained data to generate the class diagram. When the data is displayed as classes and relationship between them in a UML 2.0 confirm way, then the goal is met. The fields and methods are in the classes. Type and visibility information is present in the fields. Parameters, return value and the type of theirs are present in the methods. The relations identified in the code and aggregate multiple relationships are corresponded by the relationships .A UML Class Diagram Meta-Model is defined to meet this criterion and a mapping from the Common Meta-Model to it. Common Meta-Model and the UML Class diagrams is also discussed by this study .In addition, it also analyses the conversion between the models and the provided details on the implementation.


·      The second goal is the procreation of a design for the output diagram. The entities and relations are automatically placed in the diagram. When the classes are placed without overlapping, and the relations don't cross any class then the goal is met. It is desired that there is  minimization of crossing edges and bend. Several UML tools are discussed for meeting this goal. For displaying and designing the UML class diagrams a generic graph program yEd is used .This goal is met by the combined approaches of using a UML confirm representation and powerful layout algorithms from a 3rd party tool.


·      The third goal is to permit the interaction of the user with the plug-in. The user should be able to decide the visibility needed to be displayed, and the relations that should be generated. The combined use of the plug-in configuration and the VizzAnalyzer tool meets this goal. The user can select the information which he wants to display by using the plug-in configuration . The visibility level for the objects (methods and attributes) to be displayed as well as the type of relationships to be represented in the diagram can be chosen by the user. The necessary options for operating the internal data, allowing the users to filter the information the way they want it to be displayed is also provided by the VizzAnalyzer tool

5.2 Future Work:


The due result is obtained by the accomplishment of the UML plug-in and it has solved the problem. But some work is still left. Since the present definition of the Common Meta - Model does not allow some properties that are  needed in the Class Diagram, the Abstract and Static information on the properties are missing. There should not be any problem for adding it to the plug-in, taking this into account while writing the plug-in and when these properties will be available.


Future research can be made in affiliations' relationships. We don't have many fields in the Common Meta-Model. It is possible to extract this information from the application code, but it is mostly dependent on the programming language used and additional study can be made to extract this information.

 We can make another future research in the layout algorithms. yEd provide us with   suitable layout that helps in solving our problem, but these layouts are inclusive and not specific. Some of the traditional  restraints considered in [GJK03] are not carried out, e.g. avoiding the nesting of one class hierarchy within another, and displaying the related class by inheritance together.