Method and system for analyzing interaction among software artifacts

A system and method to analyze interactions among software artifacts within enterprise applications. The system includes an artifact analyzer module an artifact code parsing module and an artifact token processing module. The artifact analyzer module generates artifact tokens associated with trigger points in which processing control passes between a first software object and a second software object in the enterprise application and an interaction token repository for storing artifact tokens. The artifact tokens describe identity of the first software object, ownership of the first software object containing the trigger point, a location within first software object of the trigger point, and identity of the second software object. These artifact tokens are stored within an interaction token repository for later use.

FIELD OF THE INVENTION

Embodiments of the present invention relates generally to the technical field of software development and, in one exemplary embodiment, to methods and systems to analyze interactions among software artifacts.

BACKGROUND

A large enterprise application comprises of a number of interacting software artifacts which tend to have a high degree of cohesion. This interaction could be at different layers depending on the technical implementation architecture. Two cases of typical architectures which are used currently include client server and multi-tier architecture.

In a client-server architecture, the interaction can be at either the client layer or at the server layer. The server is typically a relational database system holding persistent data and the client will typically be a graphical user interface (GUI) interface implemented in Visual Basic/VC++/Java™. In case of the multi-tier technical architecture, the interactions could be at the following layers: presentation layer, services layer, methods layer, and database layer.

This leads to a large number of side effects when certain software artifacts have been modified. These need to be studied for the impact of changes. For example, if a control is added to a user interface it will lead to a change in the interface of a service. This will trigger changes in one or more methods having to change their interface signature. If these methods and services were reused in other places, the changes to the interfaces can lead to inconsistency. If such a study of impact is needed, information about the interactions of the software artifacts comprising of the enterprise application is generally needed. It is extremely unlikely that the software systems are developed with such an interaction mechanism being available as part of the development. This makes it difficult to completely study the impact of changes and be dependant on unstructured information for making such decisions.

SUMMARY

The below described embodiments of the present invention are directed to methods and systems to analyze interactions among software artifacts. According to one embodiment, there is provided a system for analyzing interactions among software artifacts within enterprise applications. The system includes an artifact analyzer module for generating artifact tokens associated with trigger points in which processing control passes between a first software object and a second software object in the enterprise application and an interaction token repository for storing artifact tokens. The artifact analyzer module includes an artifact code parsing module and an artifact token processing module. The artifact tokens describe identity of the first software object, ownership of the first software object containing the trigger point, a location within first software object of the trigger point, and identity of the second software object.

In another embodiment, there is provided a method for analyzing interactions among software artifacts within enterprise applications. The method assigns an ownership function for every software object within the enterprise application, parses software code for software objects in the enterprise application, extracts artifact tokens associated with trigger points in which processing control passes between a first software object and a second software object in the enterprise application, and analyzes interaction between the first and second software object using the artifact tokens. The artifact tokens describe identity of the first software object, ownership of the first software object containing the trigger point, a location within first software object of the trigger point, and identity of the second software object.

In yet another embodiment, there is provided a machine-readable medium storing a set on instructions that, when executed by a machine, cause of the machine to perform a method for analyzing interactions among software artifacts within enterprise applications. The method receives the software from a software development system for processing and analysis of artifact token data, assigns an ownership function for every software object within the enterprise application, parses software code for software objects in the enterprise application, extracts artifact tokens associated with trigger points in which processing control passes between a first software object and a second software object in the enterprise application, stores artifact tokens within an interaction artifact repository, and analyzes interaction between the first and second software object using the artifact tokens. The artifact tokens describe identity of the first software object, ownership of the first software object containing the trigger point, a location within first software object of the trigger point, and identity of the second software object.

DETAILED DESCRIPTION

A method and system to analyze interactions among software artifacts are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.

FIG. 1is a network diagram depicting a system having a client-server architecture in accordance with one exemplary embodiment of the present invention. Enterprise business applications are divided into an enterprise server application121that executes on a large server processing system102and an enterprise client application131that executes on one or more client processing systems103. The enterprise server application121and the enterprise client application131communicate with each other over a network102, such as a local area network or the Internet.

During the operation of the enterprise business application, a number of business functions interact with each other to provide value to an organization. These functions may be part of the enterprise server application121or part of the enterprise client application131. Understanding the interactions between these business functions assists application developers in the creation, debugging, and operation of the enterprise business applications. These interactions between business functions include both interactions between business functions that are completely within either the enterprise server application121or the enterprise client application131and interactions that are between business functions on both the enterprise server application121and the enterprise client application131. These interactions between business functions are implemented as interaction of software artifacts implementing these functions.

An artifact analyzer module111may be used to extract interactions of software artifacts at different levels. This artifact analyzer module111provides a comprehensive repository112of the interaction found at all levels of the enterprise server application121and the enterprise client application131. This repository112may be used for analyzing the changes to existing functionality within various applications as well as the impact of such changes on existing software of two architectures which are a client-server and multi-tier architecture.

In a client-server architecture, the server application121may be a relational database application holding persistent data and the client application131correspondingly may be a graphical user interface (GUI) implemented in Visual Basic/VC++/Java™.

When the artifact analyzer module processes enterprise applications, every object of the system may be assigned an owner function. The granularity of the owner function may be at any level. Depending on the granularity of the owner function, the artifact analyzer module111may determine all artifact interactions present at this level. For example, the artifact analyzer111may be set to assign ownership to a set of objects to a purchasing function within the server application121. Alternatively, the artifact analyzer module111may assign ownership to the same set of objects to more granular function like purchase requesting, purchase ordering, goods receipt and so on. Depending on this granularity, the artifact analyzer module111may extract interaction at the specified granularity.

Parsers have been written to parse the elements of the code of both the client layer code and the server side code. The parser extracts the different tokens of the software and stores in a relational database model in the interaction repository112. These tokens are collected for every user action. These tokens are analyzed to collect trigger points that lead to a transfer of control to different objects. This analysis uses the grammar associated with that particular programming language. All such Interaction points along with the destination object that services the transfer of control is stored in a relational model. The combination of object ownership along with the transfer trigger points is now used to arrive at the interaction model. This interaction model is now arranged in a way that we can navigate through the different functions that are cooperating to provide the required response for every user action.

FIG. 2is a network diagram depicting a system having a multi-layered application within a client-server architecture in accordance with one exemplary embodiment of the present invention. In a multi-tier architecture, there is an additional complexity that needs to be taken care of. The transfer of control happens at different layers. There is a need to keep track of the layer at which this transfer occurs for each user interaction. This information is stored in a relational model and is used for further analysis. The analysis is similar to a client server methodology ofFIG. 1but it generates the interactions at different layers explicitly.

In this alternate embodiment, artifact analyzer module111parse code for modules executing on both server102and client103to identify artifacts. In the multi-layer architecture of these applications, applications on server102are divided into corresponding layers: a server services layer222, a server methods layer223and a server database layer224. These various layers of the server application typically interact with corresponding layers on the client103that include: a client presentation layer231, a client services layer232, a client methods layer233and a client database layer234. Software modules within each of these layers on both the client103and the server102interact with corresponding modules on the other computing platform as well as other layers within the same platform. Artifact analyzer module111parses the code associated with software modules within these layers to identify artifacts passing between layers and between processing systems in a manner similar to the processing ofFIG. 1. These artifacts are maintained within a artifact repository112for later use.

In the embodiment shown inFIG. 3, a hardware and operating environment is provided that is applicable to any of the servers and/or remote clients shown in the other Figures.

As shown inFIG. 3, one embodiment of the hardware and operating environment includes a general purpose computing device in the form of a computer20(e.g., a personal computer, workstation, or server), including one or more processing units21, a system memory22, and a system bus23that operatively couples various system components including the system memory22to the processing unit21. There may be only one or there may be more than one processing unit21, such that the processor of computer20comprises a single central-processing unit (CPU), or a plurality of processing units, commonly referred to as a multiprocessor or parallel-processor environment. In various embodiments, computer20is a conventional computer, a distributed computer, or any other type of computer.

The system bus23can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory can also be referred to as simply the memory, and, in some embodiments, includes read-only memory (ROM)24and random-access memory (RAM)25. A basic input/output system (BIOS) program26, containing the basic routines that help to transfer information between elements within the computer20, such as during start-up, may be stored in ROM24. The computer20further includes a hard disk drive27for reading from and writing to a hard disk, not shown, a magnetic disk drive28for reading from or writing to a removable magnetic disk29, and an optical disk drive30for reading from or writing to a removable optical disk31such as a CD ROM or other optical media.

The hard disk drive27, magnetic disk drive28, and optical disk drive30couple with a hard disk drive interface32, a magnetic disk drive interface33, and an optical disk drive interface34, respectively. The drives and their associated computer-readable media provide non volatile storage of computer-readable instructions, data structures, program modules and other data for the computer20. It should be appreciated by those skilled in the art that any type of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROM(s), redundant arrays of independent disks (e.g., RAID storage devices) and the like, can be used in the exemplary operating environment.

A plurality of program modules can be stored on the hard disk, magnetic disk29, optical disk31, ROM24, or RAM25, including an operating system35, one or more application programs36, other program modules37, and program data38. A plug in containing a security transmission engine for the present invention can be resident on any one or number of these computer-readable media.

A user may enter commands and information into computer20through input devices such as a keyboard40and pointing device42. Other input devices (not shown) can include a microphone, joystick, game pad, satellite dish, scanner, or the like. These other input devices are often connected to the processing unit21through a serial port interface46that is coupled to the system bus23, but can be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB). A monitor47or other type of display device can also be connected to the system bus23via an interface, such as a video adapter48. The monitor40can display a graphical user interface for the user. In addition to the monitor40, computers typically include other peripheral output devices (not shown), such as speakers and printers.

The computer20may operate in a networked environment using logical connections to one or more remote computers or servers, such as remote computer49. These logical connections are achieved by a communication device coupled to or a part of the computer20; the invention is not limited to a particular type of communications device. The remote computer49can be another computer, a server, a router, a network PC, a client, a peer device or other common network node, and typically includes many or all of the elements described above I/O relative to the computer20, although only a memory storage device50has been illustrated. The logical connections depicted inFIG. 3include a local area network (LAN)51and/or a wide area network (WAN)52. Such networking environments are commonplace in office networks, enterprise-wide computer networks, intranets and the internet, which are all types of networks.

When used in a LAN-networking environment, the computer20is connected to the LAN51through a network interface or adapter53, which is one type of communications device. In some embodiments, when used in a WAN-networking environment, the computer20typically includes a modem54(another type of communications device) or any other type of communications device, e.g., a wireless transceiver, for establishing communications over the wide-area network52, such as the internet. The modem54, which may be internal or external, is connected to the system bus23via the serial port interface46. In a networked environment, program modules depicted relative to the computer20can be stored in the remote memory storage device50of remote computer, or server49. It is appreciated that the network connections shown are exemplary and other means of, and communications devices for, establishing a communications link between the computers may be used including hybrid fiber-coax connections, T1-T3 lines, DSL's, OC-3 and/or OC-12, TCP/IP, microwave, wireless application protocol, and any other electronic media through any suitable switches, routers, outlets and power lines, as the same are known and understood by one of ordinary skill in the art.

In the foregoing detailed description of embodiments of the invention, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description of embodiments of the invention, with each claim standing on its own as a separate embodiment. It is understood that the above description is intended to be illustrative, and not restrictive. It is intended to cover all alternatives, modifications and equivalents as may be included within the spirit and scope of the invention as defined in the appended claims. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein,” respectively. Moreover, the terms “first,” “second,” and “third,” etc., are used merely as labels, and are not intended to impose numerical requirements on their objects.

FIG. 4is a block diagram of a software artifact analyzer module in accordance with an example embodiment of the present invention. Artifact analyzer module111contains a set of processing modules to perform its functions. These modules include an analyzer control module411, an artifact code parsing module412, a user interface module413, a database interface module414, and an artifact token processing module415. The analyzer control module411controls the overall operation of the artifact analyzer module111to initiate operations to analyze software, interact with users and store and maintain artifact token data.

The artifact code parsing module412parses software module to identify artifact tokens within these modules that may be of interest in analyzing the operation of these modules. The artifact code parsing module412receives the code from a software development system402that typically stores the code, in source code form, in a software module database403. In the embodiment ofFIG. 4, the software development system402is illustrated as an external processing system. However, one skilled in the art will recognize that the artifact analyzer module111itself may be hosted within a larger software development system that may access source code developed and maintained therein without deviating from the scope of the present invention as recited within the attached claims.

The user interface module413provides a mechanism for a user to interact with the artifact analyzer module111to provide commands to initiate artifact token generation, to view and analyze generated artifact tokens, and to manipulate artifact data as part of any software development and analysis activity. In the embodiment ofFIG. 4, user401interacts with the analyzer module111through a direct connection to the user interface module413. One skilled in the art will recognize that any communication mechanism including network connections, remote connections, and direct connections between user401and the module111may be used without deviating from the scope of the present invention.

The database interface module414provides an interface between the artifact analyzer module111and the artifact interaction repository112. The repository112is a database of all found artifact tokens used to define interactions between software modules within applications. These software modules include modules within server application121, client application131, as well as within the various layers within the server221-224and the various layers within the client231-234. The database interface module414provides processing functions to store, search and retrieve tokens from the repository112during the operation of the artifact analyzer module111.

The artifact token processing module415performs the functions associated with processing parsed code received from the artifact parsing module412to identify and characterize tokens found in parsing the code. This token processing module415defines the parameters identifying the token including the module generating the token, the module receiving the token and any data parameters used as part of the token. The token generated within the artifact token processing module415are stored within the artifact repository112through the database interface module414. The artifact token processing module415may retrieve tokens from the repository as needed to assist in defining any new tokens as well as to identify any inconsistencies between found tokens.

The artifact token processing module415may contain an interaction processing module421to process tokens that are generated when processing passes from one processing module within either the client103or the server102to a second processing module. Similarly, the artifact token processing module415may contain an multi-layer token processing module422to process tokens that are generated when processing passes from one layer within either the client103or the server102to a second layer. All tokens found and processed within these modules are ultimately stored for later use in the repository112. For example, while parsing a database object, say a stored procedure belonging to one function f1 calls another stored procedure belonging to a different function f2, this call is triggered as an interaction point between these two functions f1 and f2.

FIG. 5is a diagram of a token entry from an interaction token repository according to an exemplary embodiment of the present invention. As noted above, a token500is used to define trigger points that occur when processing passes from one processing object to another. These tokens500contain data fields that define the state and nature of the processing transfer between these objects. The token fields may include a token ID511, a token name512, an object ID513, an object name514, an owner515, trigger point ID516, a trigger point location517, destination object518, and trigger point parameters519. The token ID511and the token name512are used to define the particular token contained within token500when it is stored in repository112. The token ID511provides a unique identifier for the token as compared to the token name512which is typically a human-readable identifier for the token.

The object ID513and an object name514provide a unique identifier and a human-readable name for the processing object in which a trigger point for possible transfer of control to a different object occurs. The owner field515identifies any owner for the object in which the trigger point occurs that may be used in defining the granularity of the modules being analyzed. The trigger point ID516and the trigger point location517provide a unique identify for the location of the trigger point within the object identified by object ID513. The destination object518identifies the software object to which processing may pass if conditions of the trigger point indicate that processing is to flow between software objects.

Finally, trigger point parameters519contain one or more parameters to define any data, state conditions, and other processing information needed to characterize the trigger point, the data passing between software objects and similar information needed to analyze the code. All of this information is stored within token500which is maintained within the repository112for use as needed.

FIG. 6is a flow diagram of a software development of an artifact analyzer module operation according to an exemplary embodiment of the present invention. The processing within the artifact analyzer module111begins601and ownership of every software object within an application is determined and assigned within operation611. The ownership characteristic is used to define the granularity of any analysis being performed within a large enterprise application.

Once ownership of the software objects is determined, software module code may be parsed within operation612to extract tokens. In order to extract these tokens, trigger points between software objects are identified in the parsed code. Parameter data and related information related to the trigger point is collected to define the trigger point. The token500is stored within interaction repository112for storage and later use within operation613.

With the tokens stored within the repository, tokens500may be retrieved from the repository112in operation614and compared within each other in operation615to identify whether the interactions between these modules contain any errors or inconsistencies in the data and related interaction. Tokens typically define when processing control leaves an object to pass to another object. These tokens may be checked to see that objects receiving the control, receives parameters needed to continue processing. When the analysis is performed after one of the objects associated with the token have been modified, the token may be checked to verify that the needed data and related state information is present and in a proper form given any modifications made to the objects.

Any data from these analyzed tokens and trigger points may be stored within the repository112in operation616for use in any future analysis. The processing may continue with test operation617determining if additional tokens are to be processed. If so, processing returns to operation614and repeats the analysis operations. Otherwise the processing ends602.