Scalable Vector Graphics to the Extreme

Documenting Software in the Extreme Programming methodology


Table of Contents

Introduction
Extreme approaches to software development
A picture is worth a thousand words
Requirements for tool support
The prototype tool
Technologies used in the tool
The Eclipse Framework
Abstract Syntax Tree (AST)
Scalable Vector Graphics
Combining the technologies
Forward transformation
Backwards transformation
Implementation Techniques
Research development
Conclusions
Acknowlegements
References

From the point of view of software developers, documenting software designs and decisions are highly time consuming tasks in a software development process, whether following a prescriptive process or an agile methodology. Hence agile methodologies, being consistent with their simplicity principle, aim to reduce time and effort when producing documents in order to keep themselves light. This often leads to documents, which contain models of the system other than code, being omitted completely. This difference is the source of some of the bitter debates between the agile and prescriptive followers. To address it one of the main questions of our research concerns how agile design and XP design could be performed if models were not that expensive to produce. Thus, we are challenging the idea that documentation must be highly expensive and difficult to keep in synchronisation with code during a development process.

Currently in the market there are tools for handling UML diagrams which also implement conversion of these diagrams to SVG representation, for example Omondo and Argo UML. Efforts to represent software design models in other formats based on Extensible Markup Language (XML), such as the Extensible Markup Language Metadata Interchange (XMI) promoted by the OMG, exist as well. These approaches are focused on using XML representation mainly for improving portability and model exchange. However, our research aims to explore the benefits of drawing diagrams directly in SVG representation in order to exploit the fact that information represented in SVG format is accessible, easily searched, zoomable, lightweight, structured, and suitable to be modified dynamically and interactively. Therefore, we aim to integrate SVG representation capabilities into the software development process instead of using it just as another graphic format representation.

The research is divided into two main stages: creation of a tool, and then its test and evolution. This paper describes mainly the first phase, creation of the tool that we call XPD (which is short for eXtreme Programming Design tool, and which would be pronounced "speed"). The second phase will require users testing the tool and providing feedback. During this stage empirical data will be collected from users' feedback in order to determine the features and properties that better suit the documentation process. In this phase changes produced from data analysis will lead the evolution of the tool, so as to incorporate or emphasize the features that users describe as more suitable or helpful.

At this stage the XPD tool is being developed to produce support for capturing static information (a portion of the UML class diagram specification) at the detailed design level of an XP software development process. At the same time the tool should also support the construction of the code for the software being developed and must keep the code in synchrony with the diagrams. Consequently, the tool must handle an abstract representation of the code as well as the SVG representation of the diagrams, and must maintain consistency between these two representations. The XPD tool is intended to operate within the Eclipse framework and so it is based on the processing of Abstract Syntax Trees (AST) and the Eclipse Java Model that is produced in real time from the code, alongside the diagrams that are structured and presented using Scalable Vector Graphics (SVG).

The rest of the paper therefore begins by discussing the extreme approaches to software development, and how these affect the requirements for the tool. It then goes on to describe the tool, and also to discuss the main design challenges. These are the implementation of parallel models that map between code structure and diagram representation, synchronization from code editing to diagram representation and from diagram editing to code representation, and the need to differentiate information that is better represented in diagrams from information better represented in code.

Since this tool is having to handle parallel models, the paper therefore describes the way in which we isolate pure code structure information from diagram representation, by devising a specific XML representation of the code to underpin the SVG representation. Therefore when information is represented in SVG the tool only deals with the inclusion of the graphic elements, which is supported by the use of Cascading Style Sheets (CSS) to simplify SVG DOM editing.

The paper also explains how this differentiation of information involves the division and restriction of editing functionalities. We explain the decision to restrict creation and modification of some graphic elements, such as relationships, from the code editor, so that relationships will only be coded after being drawn.

Finally, challenges arising from integration with and use of the Eclipse Framework are also discussed. Some design decisions that wrap interaction and functionality from Batik to cope with Eclipse out-of-the-box functionalities are presented. In particular, this will include issues relating to the management of focus within the Eclipse framework, such as the need to contain references to Eclipse resources in the SVG code.

Extreme programming (XP) is a software development method proposed originally by Kent Beck. XP is part of a set of software development processes, called Agile methods, that share a common set of values and principles defined by the Manifesto of Agile Software Development [AgileManifesto]. Basically, Agile methods are strongly adaptive, very people-oriented processes that use short time-boxed iterations and do not attach much weight to documents [ClarkeBaniassad05].

In more detail, XP is an extremely disciplined method focused on coding for small-to-medium-sized teams and it is based on four main core values: Communication, Simplicity, Feedback and Courage. XP’s core values act as cohesive agents supporting the process and articulating the 12 fundamental XP practices: the planning game, small releases, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, a 40-hour week, on-site customers and coding standards [Beck00].

XP achieves design of the software in quite a different way when compared with other software processes, simply because of the fact that the main deliverable artifact is code and not other kinds of documents such as diagrams or pseudo code. A detailed description of the design phase in XP is out of the scope of this paper, and so the discussion here is mainly focused on the design aspects that relate to the use and elaboration of diagrams in the XP method. In XP the use of diagrams as a form of representing and documenting design decisions is more a matter of time constraints than communication and storage constraints. As explained by Beck in [Beck00], there is nothing wrong with designing software using explicit pictures instead of purely mental or textual models, thus anyone can design with pictures all they want. At the same time, as soon as a question is raised that can be answered with code, the XP approach insists that the designer must turn to code for the answer. Consequently, as soon as the answer is understood the diagram can be discarded. Beck’s main objection to elaborating and storing pictures thus relates to the time and effort required to try keeping multiple forms of the same information synchronized.

Some current modelling tools allow successful production of diagrams from code or vice versa, however they face different difficulties for keeping code and diagrams in synchronization. Our development investigates an approach that will provide better synchronization between code and diagrams along the whole development process. We focus on the production of artifacts at detailed design level, with Java code and class diagrams as our initial target. Therefore, our requirements include graphic creation of class diagrams associated with a project; editing of class diagrams; storage and removal of class diagrams; Java code editing; automated updates between code and diagrams, and vice versa; easy integration with other tools supporting XP development (which is why we are using the Eclipse framework); and simultaneous displays of the current state of both code and diagrams.

When creating class diagrams the tool should allow the creation and positioning of UML boxes into a package diagram. The package diagram will include the classes and relationships selected by the user to be displayed. Relationships should be added graphically and the related code will be generated. Stereotypes should be added graphically.

When coding, developers are expected to code parts that do not modify the diagrams such as method bodies, comments, and javadoc comments. Code that modifies the diagram structure, such as when a new method is defined, should be created automatically in synchronization when the visual editing of the diagram is performed.

Users should be allowed to manipulate the diagram output through actions such as filtering the information to be displayed, for example hiding methods or variables in the diagram; zooming parts of the diagram; adding, removing or hiding whole classes; adding, removing, editing or hiding relationships between classes.

At this stage, the requirements for this tool explicitly exclude providing any functionality for either producing diagrams from whole source code obtained from elsewhere, or for producing code from diagram files produced with other tools. This is because the focus is to provide code and diagram synchronization at the time they are being created, rather than allowing code and diagrams to be separated. Moreover in the market there are various tools that perform, with high quality results, code production from static diagrams and vice versa. The final diagram, when saved should be stored in a compact format, easy to edit and display. Transport is not a priority requirement because of the temporary nature of models in XP. However it may be desirable that data is obtained from those diagrams in order to link to other diagrams or further software analysis.

Eclipse was launched by IBM and seven other companies in November of 2001 as an open source project. The Eclipse Platform is primarily an integration platform for tools and other kinds of client applications [ClaybergRubel06][DAnjouEtAl05]. This is possible because its architecture and the set of Java frameworks provided by Eclipse allow developers to contribute to the user interface and to package and deploy new functions, via the plug-in mechanism. A plug-in introduces new capability using a contribution mechanism called extension point [DAnjouEtAl05]. Moreover Eclipse is also a Java development environment. In particular, Eclipse includes the Java Development Tooling (JDT), which is basically a set of plug-ins that allow users to write, compile, test, debug, and edit programs written in the Java programming language. The JDT is structured into three major components:

  • JDT Core- the infrastructure for compiling and manipulating Java code.

  • JDT UI - the user interface extension that provides the IDE that developers see.

  • JDT Debug- program launching and debug support specific to the Java programming language.

In this paper, discussion is mainly concentrated on the JDT Core (org.eclipse.jdt.core) component which defines the core Java elements and API. The JDT Core packages include:

  • org.eclipse.jdt.core - defines the classes that describe the Java model.

  • org.eclipse.jdt.core.compiler - defines an API for the compiler infrastructure.

  • org.eclipse.jdt.core.dom - supports Abstract Syntax Trees (AST) that can be used for modeling the structure of a compilation unit down to the statement level.

  • org.eclipse.jdt.core.eval - supports the evaluation of code snippets in a scrapbook or inside the debugger.

  • org.eclipse.jdt.core.jdom - supports a Java Document Object Model (DOM) that can be used for walking the AST structure of a Java compilation unit.

  • org.eclipse.jdt.core.search - supports searching the workspace's Java model for Java elements that match a particular description.

  • org.eclipse.jdt.core.util - provides utility classes for manipulating the files of compiled code and associated Java model elements.

This set of classes implements the Java specific behaviour for resources and further decomposes Java resources into model elements. The structure of a java program is represented as an in-memory object that has an hierarchical structure, which is derived from the project’s class path. Some of the in-memory elements and their related class path elements are illustrated in the "top level java model elements" figure.


Top level elements from the in-memory representation of a program can be decomposed into child elements. In fact, a Java element is a handle to some underlying model object. The "low level java model elements" figure illustrates some of the underlying elements of a java compilation unit.


The Eclipse Software Development Kit (SDK) provides the JDT set of tools. These allow users to exploit the Eclipse Framework infrastructure through tools that modify or extend Eclipse functionality. JDT relies on plug-in extensions to integrate new functionalities. The JDT allows interaction with its models of the Java elements, for example packages, classes, methods, fields and so on, that are defined in the Java language specification [DAnjouEtAl05]. Moreover interaction with the Eclipse-specific workspace artifacts is also possible.

The JDT architecture is divided into the model and the user interface domains. Here the non-visual representation of the Java elements forms the model, and the set of views, actions, and Java-aware editors working together form the user interface [DAnjouEtAl05]. The JDT provides a Java source code editor with enhancements to enable content assistance, syntax highlighting, annotations, and source code formatting. In addition it provides different levels of source code analysis, for example the AST framework.

The AST framework is a tool capable of representing code as a tree of nodes, where each element that is part of the Java language in the source code is represented by a node, and source pointers related to each node can be used to extract the related source strings. Hence, an AST tree is an in-memory structured-document representation of the source code, and it can be navigated, created and edited through the functions provided by the AST framework.

Scalable Vector Graphics (SVG), as described in [Kolesnikov07], is an open standard for creating and manipulating two dimensional vector graphics and vector/raster graphics images in Extensible Markup Language (XML). The fact that SVG representation is based on XML allows its use for graphics file exchange, transfer, and display on different kinds of devices. The SVG modular language is text-based, and so is accessible and easily searched, and to some extent is human readable. Information stored in SVG format also has other advantages compared with other forms, such as being zoomable, searchable, lightweight and structured. SVG documents can be interactive and dynamic because SVG graphics can be scripted to respond to user interface events. SVG provides the built-in text interactivity, the linking mechanism, user-triggered events, and animations events as its four basic types of interactivity [Kolesnikov07].

One of the main reasons why the Eclipse Framework was selected to develop the proposed tool is because its plug-in mechanism allows easy integration between different applications. Also, its code editing and analysis functionalities, such as those provided by the Java Development Tool Kit, simplify various development tasks on this project. Moreover, because Eclipse is a Java based application it should be easy to integrate a widely used SVG displayer API, the Batik API from Apache.

The proposed tool is being developed following the Model-Control-View design pattern. Here, code is our main source model and the SVG display and the Java editor are our views. In order to feed both views with changes in the source model it is necessary to transform the code to an intermediate representation. This process can be understood as two different transformation paths: from code to graphic model, and from graphic model to code, which can be referred to as forwards and backwards transformation respectively. In this paper, the meaning of forward and backward transformation is applied contrary to the usual software development convention in order to emphasize the fact that in Extreme Programming code is the main product of the software development process. Therefore, the forward transformation is essentially the conversion of Java source code to SVG (XML) representation. We analyze the JavaModel and AST trees in order to produce an XML "neutral" representation of the general class structure, where "neutral" means that it is not an SVG file, and individual elements that are easily represented in a direct SVG format.


From the neutral XML document a second transformation is produced through XSLT in order to obtain the SVG document that is then displayed and the individual SVG elements added to it. In the backward transformation, during visual editing a Document Object Model (DOM) representing the SVG Diagrams is being edited. Then the DOM document is transformed to comply with the XML "neutral" intermediate representation. At this level the XML document will be fed to a code template that will finally be pasted to the source code. The the XPD tool's simplified class diagram shown above illustrates the static structure of the prototype tool implementation. The classes shaded in yellow represent the components implementing the Viewer functionality, while those under the green shadow perform the Controller functionality and those without highlight are the elements implementing the model adaptors functionality.


Forward transformation is the general term we use to refer to the set of processes involved in the automatic generation of graphic UML class diagram elements from the code that is being written. The forward transformation involves the tasks of drawing the initial box that represent the class and performing the required transformations that allow the inclusion of new elements to the class, for example fields, methods, stereotypes and relationships, every time that the class code is edited or modified. The former sub-process or task is performed after the JavaElementsChanged listener is notified that a new java class has being created.There are many different kind of operations that can trigger change notifications: for example: creating a resource, modifying a resource, modifying a project’s classpath, modifying a classpath variable value, changing the resource attachment of a .jar file and reconciling a working copy with its buffer.

The Java Model element implements the ISourceReference interface which allows the accessing of its related source code. Changes in the elements can be detected by implementing a JavaIElementChangedListener, as shown in the following code snippet.

                    private IElementChangedListener javaElementChangedListener;
                    …
                    JavaCore.addElementChangedListener(javaElementChangedListener);
                    … 
                    

There are two kinds of events that are supported by JavaCore:

  • POST CHANGE: Listeners of this event kind will get notified during the corresponding POST_CHANGE resource change notification.

  • POST_RECONCILE: Listeners of this event kind will get notified at the end of a reconcile operation on a working copy.

At the moment, the developed tool only listens to post change events in order to keep the diagram up to date in real time with the code changes. In the listener implementation the IJavaElementDelta, which is a delta tree rooted at the JavaModel level (see the "top level java model elements" figure ) , contains the changed element and the flags describing the kind of change occurred, hence clients must then navigate this delta using getAffectedChildred to find out what projects have changed. The following code snippet exemplifies the process.

               
               IElementChangedListener listener= newIElementChangedListener(){
                public void elementChanged(ElementChangedEvent event) {
                IJavaElementDelta delta=event.getDelta(); 
                IJavaElementDelta[] affectedChildren;
                if (delta != null) { 
                affectedChildren=delta.getAffectedChildren();
                … 
                } 
                … 
                } 
                
                

Because the Eclipse framework provides a set of wizards that helps developers to create new elements, every time a user wants to create a new java class in the project the Eclipse out-of-the-box functionality invokes the corresponding wizard, which collects from the user the minimum information required for creating the class, this is illustrated in the "Eclipse class creation wizard" figure. Then the wizard creates a compilation unit and calls a java editor which shows the new code, see the "Eclipse's java editor" figure.


Once the compilation unit is available, the XPD tool scans the code and represents it in XML format. The following snippet exemplifies the process of acquiring the related code from the compilation unit elements.

                   
                
                ICompilationUnit javaUnit=sourceUnit; 
                javaTypes=javaUnit.getTypes();
                sourceCode=javaTypes[0].getSource();
                 …
                sourceCode=javaTypes[0].getFields()[i].getSource();
                 …
                sourceCode=javaTypes[0].getMethods()[i].getSource();
                 …
                
                    
                

The code above illustrates the way the code of each java element is scanned and divided in tokens, where each token represents a specific element of the class, method or variable being tokenized.


The produced XML is then transformed through an XSL transformation which produces the SVG representation of the compilation unit which it contains, as may be seen in the "Eclipse class creation wizard" figure. This illustrates some of the features that can be included in the class, such as modifiers and methods like the constructor.

Finally, the SVG class representation is added to the main SVG class diagram document selecting the node that marks the beginning of the class in the SVG file, the <g id=[className]> node (see "the package's SVG tree structure"), and importing it to the main SVG document. The following code illustrates the process.

               
               Node duplicate=SVGDocument.importNode(element, true);
               SVGDocument.getDocumentElement().appendChild(duplicate); 
                
                

The last part of the forward transformation process relates to the automatic graphic editing of the diagram every time a new element (i.e. a method, a field, a modifier, etc) is added or edited in the current class code. In this case, the process is also triggered by the JavaElementChangedListener object.

In contrast with the box drawing process described previously, the inclusion of individual elements to the class does not involve an XML partial representation. In other words, individual elements that are added inforwards the code are directly represented as SVG elements and included in the main diagram document; it is possible by analyzing and traversing the delta object obtained by the JavaElementChangedListener, as can be seen from the implementation of the "JavaElementChangedListener" shown above.

The backwards transformation reuses most of the software functionality developed for the forwards transformation in order to keep the integrity of the application and consistency with the Eclipse framework functionality.

Thus, when the user adds a new box representing a class in the project's diagram, the request will be redirected from the SVG view to the java class creation wizard, and then (as explained previously in the forwards transformation section), the tool will create the class box from the template and the information collected through the wizard. However, in this case the XPD tool will also create a working copy from the compilation unit.

The working copy is the main receptor of the changed produced by the inclusion of new elements into the class-box. These changes will be managed through a wizard or context menu so after collection of the required data, the element will be drawn and the working copy reconciled with the compilation unit and the java editor will be updated as a consequence of the integration between the Eclipse framework components, keeping the diagram and code in synchrony. In other words, the wizard will collect the input from the user, it will select and format the information filling the gaps in the template strings that define the elements and will be added to the working copy later on. The elements get drawn because each of them triggers an event that is caught by the "JavaElementChangedListener" object every time the working copy is reconciled with the actual class unit.

As has been explained, we mainly exploit the functionally provided by the Eclipse JDT and the Batik APIs. Although the advantages of both are inherited, this approach to tool development has also implied compromising with the out-of-the-box functionalities of both APIs.

In the first place, as explained before, the way to contribute to the Eclipse Framework is through the extension points which allows developers to contribute functionality in the form of views, editors, menus, buttons, wizzards ,etc [DAnjouEtAl05]. In our case, we are required to add functionality as either a view or an editor extension point. It was decided to use a view extension point to cointain the SVG display implementation in order to simplify validation and optimizing the editing process.This has implied that users are restricted to display just one class diagram at one time because only one instance of the view can exist in the workbench page [Eclipse FAQ] [DAnjouEtAl05]but it gives us the advantage that, unlike to the editor's behaviours that can be closed whether they are dirty (with changes not being saved) or not, whenever the view or the tool is closed the contents of the view are saved . In the current development stage, this limitation to just one view was considered one that can be accepted in order to test the main tool functionality first.

Basic code editing and documentation involves to identifying the java editor in use, the related compilation unit and the right SVG document, meaning that access to the different resources in the workspace is required by the XPD tool to maintain coherence and synchronization between the code and diagram. The workspace is the Eclipse's logical container of the resources that can be accessed, it exists in the file system as a directory [DAnjouEtAl05].

Eclipse creates its own file system structure (Resource Model), which is the logical representation of the contents accesible in the workspace, whose changes are tracked by the Resource plug-in [DAnjouEtAl05]. The workspace API defines a hierarchy of classes and interfaces that represent the core of such model. Hence to simplify validation and access to the resources in the proposed tool each SVG class representation maintains a reference to its hierarchical position inside the project as a text string. The string is stored in the first child element of the group representing the class, see figure "the package's SVG tree structure". This string is parsed when validation is required by the tool in order to identify the location and related resources to each class. A similar treatment is used for low level elements (methods and fields) to keep a coherent representation, but information is stored as part of the element's id.

An advantage of using the Java Model representation is that many refactoring actions implemented by the Eclipse JDT trigger events that can be managed just by adapting the current tool implementation. Fro example, it is the case that refactoring actions usually can be identified by the fact that they trigger add and delete actions in pairs. Then the listener does not respond to the action as they are generated, but rather the affected element or elements are tagged at the first instance identifying them as addedElement, deletedElement or modifiedElement, so decisions can be made after the implied elements are all known.This is not really relevant for fields and methods refactoring because in most of the cases the delete and add action can be performed straight away with no secondary effects. But for class renaming it is crucial to recognize these actions and to execute them in the proper sequence maintaining the graphic information, such as position and relationships, from the original class and copy it to the new substituting class.

In the case of relationships between classes, these have just been represented by solid lines every time an object creates an instance of an object, but work is still being done in order to characterize the relationship according to the code changes. Because the java model is a lightweight representation of the top level code structure, but not giving detail at the method inner code level, AST analysis will be performed to detect whether any message is sent between objects, so that the relationship can be decorated according to the code changes.

Because the Batik UI components are implemented as Swing component with their own threads to manage the drawing and scripting functionalities, in the development of the prototype tool it has been decided to implement all the functionality and animation required (i.e. dragging objects) using java language. So the whole access to the SVG elements, attributes and related events are managed by the Eclipse framework and our tool. However, we expect that further tool refinement will lead us to identify the actions better implemented as pure scripting functions.

It has been observed that during editing of the inline SVG DOM document in Batik the order of children is not always as expected therefore any reference to order has being avoided for editing or searching for elements in the document.

The dynamic nature of the graphic elements required for the desired diagram representation (i.e. each box representing a class has its own different height) has restricted the use of the SVG elements that allows reusing graphic elements along a SVG document. Hence the use of <symbol>,<defs> and <use> elements has been limited to the representation of elements such as head arrows and other connectors in the final document. These elements are included as part of the template SVG document generated every time a new package class diagram is created.

The use of Cascading Style Sheets (CSS) has reduced the complexity and processing time involved in the generation, editing and updating of the SVG document, by reducing the numbers of calls that would usually be required to create or edit individual attributes. But, as in the case of matching Eclipse Resources names and SVG elements id, use of CSS ties the display of the diagrams to the XPD tool.

As described above, the initial focus of this research has been on trying to link effectively class diagrams and code. This was partly because our survey of intended users indicated that they consider class diagrams to be the most important ones, and partly because the key relationships between those diagrams and code structures are fairly well understood. For instance, the common strategies for storing associations can be each represented easily within UML class diagrams. Thus, in evaluating the prototype tool a key issue will be whether users find it more natural to apply these strategies by editing the diagrams rather than by editing the code directly. If this stage of the research is successful, then the user survey indicated that the next diagrams to be considered should be sequence diagrams, which provide a more abstract representation than the code structure of how different use cases (or parts of them) are to be implemented. Here, though, there is a larger semantic gap between these diagrams and the code representation, particular where iterations over data structures are required and so integrating the two effectively is likely to prove more challenging. Hence, a number of cycles of prototyping and feedback maybe required to arrive at acceptable solutions.

Extreme programming as an Agile methodology is people oriented and rooted on the Communication, Simplicity, Feedback, and Courage core values. It also has principles and practices that guide practitioners through the processes of implementing and executing the methodology [Beck00][Martin02]. Through our research, we have found that many of the documents and literature that explain the elements mentioned above make reference to a self-paced learning process during implementation and execution of the methodology. So we challenge the idea that documentation processes must be highly expensive and difficult to keep in synchronisation with code during an XP development process, because it is our belief that a people-oriented methodology based on communication and constant learning should not overlook the fact that those actors involved in the process learn and communicate in different ways, and therefore may require in a different extend more detailed representations or multiple representations of the project.

Hence, our approach is aiming to produce a tool that will not just save time and resources for practitioners, but that will also encourage them to communicate more effectively. Thus, the most important aspect of the tool is the effects which its availability should have on the XP development process. While code is the end product of such a process, its intermediate stages involve the developer in creating much higher-level abstractions, which are most appropriately captured in modeling notations such as UML. Our thesis is that if a tool such as this can allow the abstract models and the concrete code to be developed together and easily maintained in synchronisation, then it should be easier for users to think about features of the system being developed at the most appropriate level of abstraction, rather than always having to work at the lowest level of detail. This we claim, will not only improve the quality and efficiency of the development process, but also help to reduce the gap between agile and prescriptive methods.

Currently, our research is not at the stage of producing data from the users, nevertheless the current tool has shown that the approach is potentially able to capture changes in code during editing and refactoring phases, without heavy processing requirements. Moreover, the fact that the developed SVG representation can resemble the file system structure as well as the OO code structure with no further changes is an advantage over other format representations. However this tight relationship it still needs a mechanism to serialize and recover from the diagram and source code the state and object structure of the tool at the moment a diagram is saved.

In the mean time, SVG representation can be easily integrated to other well known documenting artifacts such as html javadocs opening the door to production of new or enriched document artifacts that reuse and integrate multiple representations on a single document. In fact, our current SVG representation already provides an abstract representation of the code from which general metrics (such as the number of field and methods) can be easily obtained with no need of fully re-parsing the code. Moreover, SVG capabilities can help to simplify code comprehension by filtering the information being displayed on the diagram and facilitating its storage and display in different formats and media definitions. For example, users can easily instruct the SVG display to not show all private elements of a class or project and save it in a pdf document or to change the font type and size of all methods that have private access.

We expect that our research will produce a good insight for the construction of further tools that will not just facilitate software design but helps to apply good design practices and techniques during the whole software development process. It is also expected that the proposed guidelines will help to improve other methodologies. Moreover, in the agile area we expect that the proposed data representation can be a gateway for the introduction, or a more extensive use, of other technologies such as audio and animation as documentation artifacts. It is also important to highlight the fact that accessibility can be highly improved under this documenting approach.

The first author wishes to acknowledge financial support for this research from the Mexican Government through a CONACYT scholarship and the support from the ESIME Zacatenco of the National Polytechnic Institute of Mexico.