FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: INCREMENTAL CALL HIERARCHY GENERATION
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman
SERVICES LIMITED Point, Mumbai, Maharashtra 400021,
India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter relates, in general, to testing of applications, and particularly, but not exclusively to, generation of incremental call hierarchy of an application.
BACKGROUND
[0002] Present day software applications, also referred to as applications, have become very sophisticated and complicated to meet the growing organizational needs. Testing of the applications is therefore, necessary to ensure that the applications are bug-free before deploying the applications in the live environment of organizations. Similarly, monitoring of the applications is necessary after deploying the application in live environments to ensure that the applications are meeting the organizational needs. Various techniques are available for testing and monitoring the applications. One such technique is to trace the source code of the applications for identifying bugs in the source code. For this, the source code is traversed and representations of source code, such as call hierarchies, are generated. The call hierarchy helps in understanding the behavior of the source code during a runtime of the application and aids in testing and monitoring the application.
BRIEF DESCRIPTION OF DRAWINGS
[0003] The detailed description is described with reference to the accompanying figures.
In the figures, the left-most digit(s) of a reference number identifies the figure in which the
reference number first appears. The same numbers are used throughout the drawings to reference
like features and components.
[0004] Fig. 1a illustrates a network environment implementing a call hierarchy
generation system, in accordance with an embodiment of the present subject matter.
[0005] Fig. 1b illustrates a sample user interface provided by the call hierarchy
generation system, in accordance with an embodiment of the present subject matter.
[0006] Fig. 2 illustrates a method for generating an incremental forward call hierarchy of
an application, in accordance with an embodiment of the present subject matter.

[0007] Fig. 3 illustrates a method for generating an incremental backward call hierarchy of an application, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0008] A system and a method for generating an incremental call hierarchy of an application, the application having a plurality of modules, are described herein. The advent of the Internet and other computer networks, such as intranet used in organizations, has given rise to new sophisticated applications in various fields, such as e-commerce, education, supply chain management and customer relationship management. The organizations heavily rely on these sophisticated applications to meet business objectives. To ensure the applications perform as designed without any errors, application builders and organizations use various techniques for testing the applications.
[0009] Typically, the application builders test the application during a testing phase prior to deployment of the application in the organization, to identify any bugs and debug them. Similarly, the organizations monitor the application by collecting application runtime data regarding the individual modules that are invoked in the application. A module may be understood as a piece of code of the application that represents a function or a method performing some tasks in the application.
[0010] One of the techniques used for aiding the testing and monitoring is to create a call hierarchy. A call is a request by one module for services from other modules. Generally, the applications have a plurality of call hierarchies in which a module calls another module and the other module calls, yet another module. For creating a call hierarchy, typically, a source code of the application is traversed entirely and the call hierarchy from a first module to a last module is generated. However, such a process is complex and consumes extensive time and resource. Also, the process generates call hierarchies of all modules, including modules which are not being monitored. Further, the call hierarchies are not generated until all modules are traversed, thereby increasing the processing load, and accordingly, resulting in slow response time and delay in generation of the call hierarchies. Furthermore, in organizations, the source code of the application is generally, provided at a remote location and accessed over a network. Therefore, scripts are used for generating call hierarchies which necessitate manual execution, thereby increasing time to generate the call hierarchy. Also, generally the command line interface is used

for executing the scripts that make the generated call hierarchy difficult to interpret and maintain. Thus, the present technique of generating call hierarchy is complex and consumes time and resources thereby, substantially increasing effort to perform an impact analysis and troubleshoot issues in a timely manner.
[0011] According to an embodiment of the present subject matter, a system and a method for generating incremental call hierarchy of an application having a plurality of modules are described herein. The system described herein, is referred to as a call hierarchy generation system. For generating a call hierarchy, initially, the call hierarchy generation system may provide a source code of the application to a user through a user interface such as a program editor. The call hierarchy generation system may then, receive a selection of a module from the source code through the user interface. The selected module is associated with a root node of a call hierarchy. A root node is a top most node in the call hierarchy which indicates the beginning of the call hierarchy. The call hierarchy generation system may then retrieve a content model associated with the selected module from a database. The content model associated with the module is indicative of information about a call hierarchy of that module. As would be understood, the call hierarchy of the module represents flow of requests between the module and other modules in the application. In one implementation, content model for each of the plurality of modules is generated during a compilation of the application and is stored in the database. [0012] The call hierarchy generation system may then, parse the content model to build individual child nodes of the call hierarchy corresponding to each of the other modules in the content model and generate the call hierarchy for the selected module. In one implementation, the call hierarchy generation system may generate the call hierarchy by positioning the root node at top of the call hierarchy and the individual child nodes below the root node. Thereafter, the call hierarchy generation system may receive a selection of a child node from the generated call hierarchy through the user interface. The call hierarchy generation system may generate another call hierarchy for a module associated with the selected child node in a manner, as described above. Thus, the call hierarchy generation system may generate a call hierarchy for an individual module selected by a user and thus, does not have to generate the call hierarchy for all the modules in the source code.
[0013] According to the embodiment of the present subject matter, the call hierarchy generation system may generate a forward call hierarchy and a backward call hierarchy for the

module based on a user input received through the user interface. In one example, the user input may be received in a form of a click on an icon provided on the user interface. [0014] In one implementation, a user input for generating a forward call hierarchy may be received by the call hierarchy generation system. As would be understood, the forward call hierarchy provides information about other modules being called by the module selected by the user during the run-time of the application. The other modules indicated herein, may be the modules called directly by the selected module, or called indirectly by the selected module. For example, a module ‘A’ selected for generation of forward call hierarchy, may have other modules ‘B’ and ‘D’ that are called by the module ‘A’ during run-time of the application may be referred as directly called modules. While, if the other module ‘B’ which is called by module ‘A’, in turns calls a module ‘C’, and the module ‘D’ which is called by module ‘A’, in turns calls a module ‘E’, then the modules ‘C’ and ‘E’ may be referred as indirectly called modules. Upon receiving the user input, the call hierarchy generation system may retrieve a content model associated with the module from the database. The content model contains information about other modules called by the module during a runtime of the application. Upon retrieving the content model associated with the module, the call hierarchy generation system may parse the content model to build individual child nodes of the forward call hierarchy. After building the individual child nodes, the call hierarchy generation system may generate the forward call hierarchy by positioning the root node at top of the call hierarchy and the individual child nodes below the root node. Further, the individual child nodes may be positioned in an order in which the other modules associated with the individual child nodes are called by the module associated with the root node.
[0015] Further, the call hierarchy generation system may generate another forward call hierarchy upon receiving a selection of one of the individual child nodes in the generated forward call hierarchy from the user. In one implementation, the user may select the individual child node from the generated forward call hierarchy and provide the user input of generating a forward call hierarchy for the selected individual child node through the user interface. Based on the received selection of individual child node, the call hierarchy generation system may then, generate a forward call hierarchy for the selected individual node in a manner as described above. Thus, the call hierarchy generation system generates a call hierarchy for each of the selected node.

[0016] In another implementation, a user input for generating a backward call hierarchy may be received by the call hierarchy generation system. As would be understood, the backward call hierarchy provides information about other modules calling the module selected by the user during run time of the application. For example, if module ‘A’ is selected for backward call hierarchy and modules ‘B’, ‘C’, and ‘D’ call the module ‘A’ during a run time of the application, then, the module ‘B’, ‘C’, and ‘D’ are referred to as other modules calling the selected module ‘A’. Upon receiving the user input, the call hierarchy generation system may retrieve a content model associated with the module from the database. The content model may contain information about other modules calling the selected module during the runtime of the application.
[0017] In one implementation, to build a content model for the backward call hierarchy generation, the call hierarchy generation system may search content models associated with other modules calling the module in the database based on a unique identification of the module. Upon searching, the call hierarchy generation system may generate a backward content model containing information about the other modules calling the module and associate the content model with the module. Upon generating the backward content model associated with the module, the call hierarchy generation system may parse the generated backward content model to build individual child nodes of the backward call hierarchy. After building the individual child nodes, the call hierarchy generation system may generate the backward call hierarchy by positioning the root node at top of the call hierarchy and the individual child nodes below the root node.
[0018] Further, the call hierarchy generation system may generate another backward call hierarchy upon receiving a selection of one of the individual child nodes in the generated backward call hierarchy from the user. In one implementation, the user may select the individual child node from the generated backward call hierarchy and provide the user input of generating a backward call hierarchy for the selected individual child node through the user interface. Based on the received selection of individual child node, the call hierarchy generation system may then, generate a backward call hierarchy for the selected individual node in a manner, as described above. Thus, the call hierarchy generation system provides a call hierarchy for each of the selected node.

[0019] The present subject matter thus, provides a method and a system for generating incremental call hierarchy of an application having a plurality of modules. Thus, the system dynamically generates call hierarchy for individual modules selected by a user which reduces the wait time that would be needed otherwise for generating call hierarchy of all modules. Therefore, an application builder and an Information Technology (IT) team of an organization may quickly respond to any defects observed in the functioning of the application, for example when a selected module is called. Also, the system uses content models previously generated during compilation of application for generating the call hierarchy. Therefore, the need to traverse the source code before call hierarchy generation is eliminated, thereby saving time and system resources such as memory and processor. Also, the processing load is reduced and accordingly response time for generation of the call hierarchies is further reduced. [0020] Further, writing of scripts and manual execution of scripts for generation of call hierarchies by the IT team is eliminated due to the availability of previously generated content models. Also, the use of command line interfaces for manual execution of scripts is eliminated. Thus, the IT team in organization may monitor the behavior of the source code and may identify reasons for error in the application in a short span of time due to the lesser time needed for generation of call hierarchies.
[0021] The manner in which the systems and methods for generating an incremental call hierarchy of an application is explained in detail, with respect to Figures 1a to 3. While aspects of the described system and methods for generating an incremental call hierarchy of an application may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following system(s). [0022] Fig. 1a illustrates a network environment 100 implementing a call hierarchy generation system 102 for generating an incremental call hierarchy for an application having a plurality of modules, in accordance with an embodiment of the present subject matter. The module may be understood as a piece of code of the application that represents a function or a method performing some tasks in the application. The call hierarchy generation system 102 is communicatively coupled to user devices 104-1, 104-2,..., 104-N, through a network 106. For the sake of clarity, the user devices 104-1, 104-2,,..., 104-N are collectively referred to as user devices 104 and individually referred to as user device 104. Examples of the user devices 104

include, but are not restricted to, desktop computers, laptops, smart phones, personal digital assistants (PDAs), tablets, and the like.
[0023] The user devices 104 are communicatively, coupled to the call hierarchy generation system 102 over the network 106 through one or more communication links, for example, via dial-up modem connections, cable links, and digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication through the network 106. The network 106 may be a wireless network, a wired network or a combination thereof. The network 106 may be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), cloud based network, and the internet. [0024] The call hierarchy generation system 102 may be implemented in a variety of computing devices, including, servers, workstations, computers, laptops, smart phones, personal digital assistants (PDAs), tablets, and the like. In an implementation, the call hierarchy generation system 102 may be accessed for generating an incremental call hierarchy for an application having a plurality of modules. In one implementation, the call hierarchy generation system 102 may be implemented as a web application which is hosted on a remote server, and may be accessed from the user device 104 through a user interface of the web application. In an example, the web application may be available as a plug-in to any present code viewer, such as Eclipse.
[0025] In one implementation, for generating a call hierarchy for an application, the user may select a module from amongst the plurality of modules of the application. The module may be understood as a piece of code of the application that represents a function or a method performing some tasks in the application. The user can be, for example, provided with a source code of the application, and allowed to select a module to provide a user input for generating an incremental call hierarchy for that module. Upon receiving a selection of the module, the call hierarchy generation system 102 may associate the module with a root node of a call hierarchy. The call hierarchy generation system 102 may then, retrieve a content model associated with the module from a database 108, storing a plurality of pre-created content models based on the selected module. As indicated previously, corresponding to each of the modules of an application, a content model is generated and stored into the database 108 by an application developer during a compilation of the application. The content model may contain information about call hierarchy of the module. As would be understood, the call hierarchy of the module

represents requests by the module in the application for service from other modules. Upon retrieving the content model, the call hierarchy generation system 102 may parse the content model to build individual child nodes of the call hierarchy corresponding to each of the other modules in the content model. The call hierarchy generation system 102 may then, generate the call hierarchy by positioning the root node at top of the call hierarchy and the individual child nodes below the root node. Thus, the call hierarchy generation system 102 generates the call hierarchy for each individual module selected by the user and not for all the modules in the source code.
[0026] Further, the call hierarchy generation system 102 includes processor(s) 110, interface(s) 112, and a memory 114 coupled to the processor(s) 110. The interface(s) 112 may include a variety of application programs and hardware interfaces, for example, a network interface allowing the call hierarchy generation system 102 to interact with the user devices 104 and the database 108. The interface(s) 112 may also, facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, and satellite networks. [0027] The processor(s) 110 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 110 is configured to fetch and execute computer-readable instructions and data stored in the memory 114. [0028] The memory 114 may include any non-transitory computer-readable medium known in the art, including volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[0029] In one implementation, the call hierarchy generation system 102 may include component(s) 116 and data 118. The component(s) 116, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The component(s) 116 may also, be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulate signals based on operational instructions.

[0030] Further, the component(s) 116 may be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit may comprise a computer, a processor, such as the processor(s) 110, a state machine, a logic array or any other suitable devices capable of processing instructions. The processing unit may be a general-purpose processor which executes instructions to cause the general-purpose processor to perform the required tasks or, the processing unit may be dedicated to perform the required functions. [0031] In another aspect of the present subject matter, the component(s) 116 may be machine-readable instructions (software) which, when executed by a processor/processing unit, perform any of the described functionalities. The machine-readable instructions may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium or non-transitory medium. In one implementation, the machine-readable instructions may also, be downloaded to the storage medium via a network connection. [0032] In one implementation, the component(s) 116 further, include a selection listener 120, an expansion listener 122, a content model (CM) retriever 124, a CM parser 126, a call hierarchy (CH) viewer 128, and other component(s) 130. The other component(s) 130 may include programs or coded instructions that supplement applications and functions of the call hierarchy generation system 102. The data 118 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the other component(s) 130. The data 118 includes node data 132, CM data 134, CH data 136, and other data 138. The other data 138 includes data generated as a result of the execution of one or more modules in the other component(s) 130.
[0033] As described previously, the call hierarchy generation system 102 may be accessed for generating an incremental call hierarchy for an application having a plurality of modules. The module may be understood as a piece of code of the application that represents a function or a method performing some tasks in the application. In an implementation, the source code of the application indicated herein, may be written in a fourth generation language (4GL). For the purpose of generating the incremental call hierarchy, the selection listener 120 of the call hierarchy generation system 102 may receive text selected by the user from a source code of the application. In an example, the source code of the application may be stored in the database 108 and accessed by the user through a user interface of the call hierarchy generation system 102. In

the example, the user may select the text in a program editor provided through the user interface for the generation of call hierarchy.
[0034] Upon receiving the selected text, the selection listener 120 may determine a module associated with the selected text from amongst the plurality of modules of the application present in the source code. In one implementation, the user may provide a name of module to the selection listener 120, either manually or using a copy action. Additionally, the selection listener 120 may retrieve corresponding full qualified file name of the module from the source code of the application. Upon determination of the module, the selection listener 120 may associate the module with a root node of the call hierarchy. In an example, the selection listener 120 stores the details of the module as the node data 132.
[0035] Further, a user input may be received by the call hierarchy generation system 102 for generating the call hierarchy of the module. In one implementation, the user input may be received for generating a forward call hierarchy of the module. In one example, the user input may be received in a form of a click on an icon provided on the user interface for generating the forward call hierarchy. In other implementation, the user input may be received for generating a backward call hierarchy of the module. In one example, the user input may be received in a form of a click on an icon provided on the user interface, for generating the backward call hierarchy. As would be understood, a forward call hierarchy of a module represents information about other modules called by that module, and a backward call hierarchy of a module represents information about other modules calling that module. [0036] Upon receiving the user input of generating the call hierarchy, the CM retriever 124 may retrieve a content model associated with the selected module from the database 108. For this purpose, the CM retriever 124 may establish a secure shell (SSH) channel between the call hierarchy generation system 102 and the database 108 for secure transmission of the content model. The content model may contain information about the other modules calling or being called by the module. The content model may also, contain information about line numbers in the source code of the application where the other modules are called by the module or are calling the module in the source code. The information may be represented in the content model in an order of the other modules are being called by or are calling the module in the source code. In one implementation, the content model is generated for each of the plurality of modules during a compilation of the application and is stored in the database 108. The content model may

also, contain unique identification of each of the plurality of modules generated during the compilation of the application. In an example, the content model is generated using a XML format. In the example, a list of modules present in the source code may be generated during the compilation of the application. The list of modules may then, be formatted in XML format for further processing.
[0037] Further, the source code may be compiled each time the source code is updated to generate updated content models. The previously generated content models are replaced by new content models when the source is updated. The updation of the content models does not change the unique identification of each of the plurality of modules generated previously. Example 1 below, illustrates a XML based-content model generated during compilation of application written in 4GL for translating the source code, from 4GL to target language, such as C++ and Java. In the Example 1, XML content model is created for module ‘AccountMgmt_Account_getBalance’ which is given a unique id of 129029. The module ‘AccountMgmt_Account_getBalance’ requests services of three modules namely ‘AccountMgmt_Account_getAccountHolder’, ‘RoleMgmt_Role_getRoleForHolder’, and ‘UserMgmt_User_getUserDetails’
Example 1

[0038] Furthermore, hash maps may be generated when the content models are retrieved, to accomplish faster search of the content models, to verify recursive function calls. A hash map is a data structure used to implement an associative array for mapping keys with data values to enables easy and fast search of data values. The hash map uses a hash function to compute a

unique index that maps the data values with associated keys. In an implementation, a blank hash map is created at the beginning of call hierarchy generation. The information about the module is captured in a hash map object along with other modules calling the module. The information is then, queried during a call hierarchy generation of other modules calling the module to verify, if there is any recursive function call. In an event, the information is indicative of the recursive function call, the call hierarchy generation is stopped and the retrieved content models are further processed for providing to a user.
[0039] After retrieving the content model associated with the module, the CM parser 126 may parse the content model to build individual child nodes of the call hierarchy in an array structure. As indicated previously, the individual child nodes represent the other modules being called by, or are calling the module in the content model. It would be understood that the array structure is used for preserving the order in which the other modules are being called by, or are calling the module in the source code. Any suitable data structure may be used for preserving the order. In one implementation, a SAX XML parser parses XML based-content model to build individual child nodes. The array structure including the individual child nodes may be stored as the CM data 134.
[0040] After building the individual child nodes, the CH viewer 128 may generate the call hierarchy by positioning the root node at top of the call hierarchy and the individual child nodes below the root node. Further, the individual child nodes may be positioned in the order preserved by the array structure. Thus, the call hierarchy only provides information about the selected module and does not provide information of all the modules present in the source code. Further, the root node and each of the individual child nodes may be provided with an icon indicating whether the node is a fourth generation languages (4GL) such as Q++ module, a third generation language, such as C++ and Java module, and a database query language, such as SQL module. Furthermore, the CH viewer 128 may provide information, such as line number and file name of the individual child nodes in the call hierarchy. Also, the CH viewer 128 may provide a icon along side an individual node indicating whether the node is an overridden module. [0041] As described previously, in one implementation, the CM retriever 124 may retrieve a content model associated with the module from the database 108, upon receiving a user input of generating a forward call hierarchy for the module based on the unique identification of the module. The content model may contain information about other modules called by the

module during a runtime of the application. The content model retrieved from the database 108 may be stored as the CM data 134. Upon retrieving the content model, the CM parser 126 may parse the content model to build individual child nodes of the call hierarchy in an array structure. Upon building the individual child nodes, the CH viewer 128 may generate the forward call hierarchy by positioning the root node at top of the call hierarchy and the individual child nodes below the root node. The individual child nodes may be positioned in the order of calling the other module by the module, as preserved by the array structure. In one implementation, the generated forward call hierarchy may be provided to the user through a user interface. [0042] In another implementation, the CM retriever 124 may search content models associated with other modules calling the module from the database 108 upon receiving a user input of generating a backward call hierarchy for the module. The content models for each of the other modules may contain information about other modules calling the module during the runtime of the application. The CM retriever 124 may search the content models associated with the other modules calling the module based on a unique identification of the module generated during a compilation of the application. In one implementation, the CM retriever 124 may search content models associated with other modules in the database 108 based on the unique identification of the module.
[0043] Upon searching the content models of other modules, the CM retriever 124 may generate a backward content model based on the searched content models of other modules and associate the generated content model with the module. The generated backward content model may contain information about all the other modules calling the module in an order of calling the module in the source code. The generated content model may be stored as the CM data 134 and also may be stored in the database 108 for future reference. Upon generating backward content model, the CM parser 126 may parse the generated backward content model to build individual child nodes of the backward call hierarchy in an array structure. Upon building the individual child nodes, the CH viewer 128 may generate the backward call hierarchy by positioning the root node at top of the backward call hierarchy and the individual child nodes below the root node. The individual child nodes may be positioned in the order of the other modules calling the module in the source code, as preserved by the array structure. In one implementation, the generated backward call hierarchy may be provided to the user through a user interface.

[0044] Further, after a call hierarchy is generated, the expansion listener 122 may receive a selection of one of the individual child nodes from the generated call hierarchy for generating a new call hierarchy for the selected individual child node. The expansion listener 122 may then, identify a module corresponding to the selected individual child node and associate the module with a root node of the new call hierarchy. Additionally, the expansion listener 122 may also, receive a user input of generating a forward call hierarchy or a backward call hierarchy of the module. The expansion listener 122 may then, notify the CM retriever 124 to retrieve a content model associated with the module from the database 108. The CM retriever 124 may then, retrieve the content model associated with the module corresponding to the selected individual child node. The CM parser 126 may then, parse the retrieved content model and build individual child nodes for the new call hierarchy in a manner, as described previously. The CM parser 126 may build the individual child nodes based on the received user input of generating the new call hierarchy as described previously. After building the individual child nodes, the CH viewer 128 may generate the call hierarchy by positioning the individual child nodes below the root node. In one implementation, the generated call hierarchy may be provided to the user through the user interface. Thus, the expansion listener 122 incrementally generates call hierarchy of each individual module in the source code upon selection of the individual module instead of generating a call hierarchy of entire source code.
[0045] Further, after a call hierarchy is generated, the selection listener 120 may receive a user input from the user for opening the source code. In one example, the user may doubleclick on an individual child node in the call hierarchy. Upon receiving the user input, the selection listener 120 may then, identify a module corresponding to the selected individual child node and open the source code in a program editor, which is provided on the user interface of the call hierarchy generation system 102. In another implementation, one of the other component(s) 130 may be used for performing the above function of the selection listener 120. [0046] Further, after a call hierarchy is generated, the CH viewer 128 may receive a user input of generating a call hierarchy report based on the call hierarchy. In one implementation, the user input may include a selection of one of the individual child nodes in the call hierarchy. Upon receiving the user input of generating the call hierarchy report, the CH viewer 128 may associate the selected node as a root node and generate a report by recursively traversing all the individual child nodes positioned below the selected node in the call hierarchy. The call

hierarchy report may also, contain information about the selected node and all the individual child nodes, such as file name and line number of the each of the modules associated with the nodes in the source code. The call hierarchy report may also contain appropriate indentation for each of the nodes based on an order of calling in the source code. [0047] Fig. 1b illustrates an exemplary user interface 140 provided by the call hierarchy generation system 102, according to an embodiment of the present subject matter. As shown in the Fig. 1b, in one implementation, the user interface 140 includes at least three sections, namely, a workspace section 142, a CH section 144, and a CH table section 146. The workspace section 142 provides information about a module, for which a call hierarchy is generated. The information includes name of the module and type of call hierarchy (forward or backward) generated. The CH section 144 provides the call hierarchy of the module. In one example, the CH section 144 provides a call hierarchy of a module 148 and a call hierarchy of another module 150 associated with an individual child node of the call hierarchy of module 148. The CH section 144 also, provides an icon 152 against each of the modules in the call hierarchy identifying the type of language. The CH table section 146 provides information about file name and line number of a module selected from the call hierarchy in the source code. Further, the user interface 140 also includes two icons 154 and 156 for receiving a selection of generating a forward call hierarchy and a backward call hierarchy respectively. In one implementation, the icons 154 and 156 may be replaced with buttons. [0048] It is to be understood that the user interface shown above with specific sections, features, and representation of the call hierarchy is only for the purpose of explanation. The user interface may have additional sections and features with any possible arrangement. Further, the representation of the call hierarchy can also be different without deviating from the scope of the present subject matter.
[0049] Figs. 2 and 3 illustrate method 200 and 300 for generating an incremental forward call hierarchy and an incremental backward call hierarchy, respectively, of an application having a plurality of modules, in accordance with an implementation of the present subject matter. The methods 200 and 300 may be described in the general context of computer executable instructions. Generally, computer executable instructions may include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The methods 200 and 300 may also, be

practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices. The method described herein, may be implemented by computer-executable instructions in one or more computer-readable media (for example, computer storage media or other tangible media). Further, the methods described herein, may be implemented in a plurality of programming languages. [0050] The order in which the methods 200 and 300 are described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the methods, or alternative methods. Additionally, individual blocks may be deleted from the methods 200 and 300 without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods may be implemented in any suitable hardware, software, firmware, or combination thereof. [0051] Referring to Fig.2, a process for generating an incremental forward call hierarchy of an application having a plurality of modules begins at block 202. At block 202, a text selected by a user from a source code of the application is received. For example, the selection listener 120 may receive a selection of a text in the source code from the user. [0052] At block 204, a module from amongst the plurality of modules corresponding to the selected text is determined. Further, the module is associated with a root node of the forward call hierarchy. For example, the selection listener 120 may determine a module corresponding to the node data 132 and associate the module with a root node of the forward call hierarchy. [0053] At block 206, a content model associated with the module is retrieved from a database. The content model includes information about other modules called by the module during a runtime of the application. In one implementation, content models for each of the modules in the application is generated during a compilation of the application and stored in the database. For example, the CM retriever 124 may retrieve a content model associated with the module from the database 108.
[0054] At block 208, the content model is parsed to build individual child nodes of the forward call hierarchy for each of the other modules in the content model. In one implementation, the individual child nodes are stored in an array structure such that an order in which the other modules are called by the module in the source code is preserved. For example,

the CM parser 126 may parse the content model associated with the module to generate individual child nodes of the forward call hierarchy in an array structure preserving an order in which the other modules are called by the module in the source code. [0055] At block 210, the forward call hierarchy is generated with the root node and the individual child nodes. In one implementation, the root node is positioned at top of the forward call hierarchy and the individual child nodes are positioned below the root node in the call hierarchy based on the order preserved in the array structure. The generated forwarded call hierarchy is then provided to the user. For example, the CH viewer 128 may generate the forward call hierarchy having the root node and the individual child nodes such that the root node is positioned at top of the forward call hierarchy and the individual child nodes are positioned in the forward call hierarchy below the root node according to the order of the other modules. [0056] Referring to Fig 3, a process for generating an incremental backward call hierarchy of an application having a plurality of modules begins at block 302. At block 302, module selected by a user from a source code of the application using a program editor is received. Upon receiving the selection of the module, the module is associated with a root node of the backward call hierarchy. For example, the selection listener 120 may receive a selection of a module from the user and may associate the module with a root node of the backward call hierarchy.
[0057] At block 304, a content model associated with the module is retrieved from a database. The content model includes information about other modules calling the module during a runtime of the application. In one implementation, content models associated with the other modules calling the module are searched. Based on the searching, the content model associated with the module is generated such that the content model includes all other modules calling the module in an order of calling in the source code. For example, the CM retriever 124 may retrieve the content models associated with the other modules calling the module from the database 108 and generate a backward content model associated with the module such that the generated content model includes information about other modules calling the module. [0058] At block 306, the generated content model is parsed to build individual child nodes of the backward call hierarchy for each of the other modules in the content model. In one implementation, the individual child nodes are stored in an array structure such that an order in which the other modules are calling the module in the source code is preserved. The For

example, the CM parser 126 may parse the content model associated with the module to generate individual child nodes of the forward call hierarchy in an array structure preserving an order in which the other modules are calling the module in the source code. [0059] At block 308, the backward call hierarchy is generated with the root node and the individual child nodes. In one implementation, the root node is positioned at top of the backward call hierarchy and the individual child nodes are positioned below the root node in the backward call hierarchy based on the order preserved in the array structure. The generated backward call hierarchy is then provided to the user. For example, the CH viewer 128 may generate the backward call hierarchy having the root node and the individual child nodes such that the root node is positioned at top of the forward call hierarchy and the individual child nodes are positioned in the backward call hierarchy below the root node according to the order of the other modules.
[0060] Although embodiments for generating incremental call hierarchy of an application having a plurality of modules have been described in language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary embodiments for incremental call hierarchy generation.

I/ We claim:
1. A method for generating an incremental forward call hierarchy of an application having a
plurality of modules, the method implemented by a processor (110), the method comprising:
determining, by the processor (110), a module from amongst the plurality of modules corresponding to a selected text, wherein the module is associated with a root node of a call hierarchy;
retrieving, by the processor (110), a content model associated with the module, from a database, based on the determination, wherein the content model is indicative of at least one other module called by the module during a runtime of the application;
generating, by the processor (110), the forward call hierarchy having the root node and at least one individual child node based on the content model, wherein the root node is positioned at top of the call hierarchy and the at least one individual child node is positioned in the call hierarchy below the root node and in an order in which the at least one other module associated with the at least one individual child node is called by the module associated with the root node; and
providing, by the processor (110), the generated forward call hierarchy for the selected module to a user.
2. The method as claimed in claim 1, wherein the method further comprises:
receiving, by the processor (110), a selection of the at least one individual child node in the forward call hierarchy; and
generating, by the processor (110), another forward call hierarchy based on the selected individual child node, wherein the selected individual child node is associated with a root node of the call hierarchy.
3. The method as claimed in claim 1, wherein the method further comprising receiving, by the processor (110), the selected text by the user from a source code of the application.
4. The method as claimed in claim 1, wherein the method further comprising parsing, by the processor (110), the retrieved content model to build at least one individual child node of the call hierarchy.

5. The method as claimed in claim 1, wherein the content model associated with the module is generated during a compilation of the source code.
6. A method for generating an incremental backward call hierarchy of an application having a plurality of modules, the method implemented by a processor (110), the method comprising:
receiving, by the processor (110), a selection of a module from amongst the plurality of modules from a source code of the application using a program editor, wherein the module is associated with a root node of call hierarchy;
retrieving, by the processor (110), a backward content model associated with the module from a database, based on the determination, wherein the backward content model is indicative of at least one other module calling the module during a runtime of the application;
generating, by the processor (110), the backward call hierarchy having the root node and at least one individual child node based on the backward content model, wherein the root node is positioned at top of the call hierarchy and the at least one individual child node is positioned in the call hierarchy below the root node; and
providing, by the processor (110), the generated backward call hierarchy for the selected module to a user.
7. The method as claimed in claim 6, wherein the method further comprising parsing, by the processor (110), the retrieved content model to build at least one individual child node of the call hierarchy.
8. The method as claimed in claim 6, wherein the retrieving further comprises:
searching, by the processor (110), at least one content model associated with at least one other module calling the module; and
generating, by the processor (110), the backward content model associated with the module based on the searching of the at least one content model, wherein the generated backward content model provides information about the at least one other module calling the module and wherein the generated backward content model is stored in the database.
9. The method as claimed in claim 6, wherein the method further comprising:

receiving, by the processor (110), a selection of the at least one individual child node in the backward call hierarchy; and
generating, by the processor (110), another backward call hierarchy based on the selected individual child node, wherein the selected individual child node is associated with a root node of the call hierarchy.
10. The method as claimed in claim 8, wherein the at least one content model associated with at least one other module is generated during a compilation of the source code.
11. A call hierarchy generation system (102) for generating an incremental call hierarchy of an application having a plurality of modules, the call hierarchy generation system (102) comprising:
a processor (110);
a selection listener (120) coupled to the processor (110) to receive a selection of a module from amongst the plurality of modules from a source code of the application, wherein the module is associated with a root node of the call hierarchy;
a content model retriever (124) coupled to the processor (110) to retrieve a content model associated with the module from a database based on the selection; and
a call hierarchy viewer (128) coupled to the processor (110) to:
generate the call hierarchy having the root node and the at least one individual child node based on the content model, wherein the root node is positioned at top of the call hierarchy and the at least one individual child node is positioned in the call hierarchy below the root node; and
provide the call hierarchy of the selected module to a user.
12. The call hierarchy generation system (102) as claimed in claim 11, wherein the content model is indicative of at least one other module called by the module during a runtime of the application.
13. The call hierarchy generation system (102) as claimed in claim 11, wherein the content model is indicative of at least one other module calling the module during a runtime of the application.

14. The call hierarchy generation system (102) as claimed claim 11, wherein the call hierarchy generation system (102) further comprising a content model parser (126) coupled to the processor (110) to parse the retrieved content model to build at least one individual child node of the call hierarchy.
15. A non-transitory computer readable medium having a set of computer readable instructions that, when executed, cause a computing system to:
receive a selection of module from amongst the plurality of modules from a source code of the application, wherein the module is associated with a root node of call hierarchy;
retrieve a content model associated with the module from a database;
generate the call hierarchy having the root node and the at least one individual child node based on the content model, wherein the root node is positioned at top of the call hierarchy and the at least one individual child node is positioned in the call hierarchy below the root node; and
provide the call hierarchy for the selected module to a user.