DYNAMIC VIEW OF DEBUGGING STATE

An example operation may include one or more of tracking debugging actions performed to a software system via a runtime environment of the debugging actions, identifying one or more debugging attributes of an object of the software system based on the tracked debugging actions performed to the software system, generating a window which includes details of the one or more identified debugging attributes of the object, and displaying the window which includes the details of the one or more identified debugging attributes via a user interface of a debugging program.

BACKGROUND

Debugging is a process of testing a software system such as an application, program, service, etc., for quality and performance issues and fixing those issues for future releases. Anything that is not expected within a workflow of the software program may be considered a defect. In today's development environment, it is common for teams of people to collaborate on the development and testing of a software system. In this collaborative environment, it can be difficult to track or otherwise show each user a state of the debugging process for the software system given that other collaborators may have made changes that are not visible to that user. For example, multiple collaborators may spend significant time trying to debug the same problem within the software system. This can be a strong indicator that something is wrong in the underlying software system. However, the efforts of the collaborators are not be visible to each other within the debugging process. As a result, the debugging process can suffer from inefficiencies and other drawbacks as a result of this lack of visibility.

SUMMARY

One example embodiment provides an apparatus that may include a processor that is configured to one or more of track debugging actions performed to a software system via a runtime environment of the debugging actions, identify one or more debugging attributes of an object of the software system based on the tracked debugging actions performed to the software system, generate a window which includes details of the one or more identified debugging attributes of the object, and display the window which includes the details of the one or more identified debugging attributes via a user interface of a debugging program.

Another example embodiment provides a method that may include one or more of tracking debugging actions performed to a software system via a runtime environment of the debugging actions, identifying one or more debugging attributes of an object of the software system based on the tracked debugging actions performed to the software system, generating a window which includes details of the one or more identified debugging attributes of the object, and displaying the window which includes the details of the one or more identified debugging attributes via a user interface of a debugging program.

A further example embodiment provides a computer-readable medium comprising instructions, that when read by a processor, cause the processor to perform one or more of tracking debugging actions performed to a software system via a runtime environment of the debugging actions, identifying one or more debugging attributes of an object of the software system based on the tracked debugging actions performed to the software system, generating a window which includes details of the one or more identified debugging attributes of the object, and displaying the window which includes the details of the one or more identified debugging attributes via a user interface of a debugging program.

DETAILED DESCRIPTION

The example embodiments are directed to a host system which can be integrated within a debugging environment such as within a cloud computing platform, and which can provide a developer or other debugger with details about the software system (e.g., software application, service, program, etc.) being debugged. Large-scale software development often involves multiple users collaborating on the debugging of the software system over time. The purpose of the debugging is to fix errors and otherwise address defects within the software system. However, the steps taken by one developer are often not available to another developer that is also working on the same debugging process.

To address these drawbacks in the art of debugging, the example embodiments record modifications and other changes to the software system during the debugging process on a large-scale basis and provides details of the changes within a visual interface inside the debugging environment. When a developer is debugging the software system, the developer may test and check various parts of the program. To do this, the debugger may create new instances or copies of one or more objects, delete instances of one or more objects, modify one or more objects, perform method calls to one or more objects, and the like. These actions can be captured by the host system and recorded by the solution.

When a user (debugger) opens the debugging environment (e.g., a user interface of the debugging program, etc.) the host process may display a window with the different debugging details learned from the debugging which has occurred to the software system so far. As an example, the debugging details may include one or more of a rate of creation of one or more objects from the software system, a rate of method calls to methods within one or more objects of the software system, an age of one or more objects within the software systems, an estimated end of life of one or more objects within the software system, and the like. Accordingly, developers can be given a “head start” on identify where the most significant issues are located in the software system. The solution can provide each debugger with a global understanding of the changes that have occurred to the software system as a result of the debugging. Accordingly, developers can quickly identify sections of the software system that are having repeated issues and correct the problems.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

Community cloud: the cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by organizations or a third party and may exist on-premises or off-premises.

A cloud computing environment is service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

For example, again, depending upon the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, concurrently, or in a manner at least partially overlapping in time.

A computer program product embodiment (“CPP embodiment” or “CPP”) is a term used in the present disclosure to describe any set of one, or more, storage media (also called “mediums”) collectively included in a set of one, or more, storage devices that collectively include machine readable code corresponding to instructions and/or data for performing computer operations specified in a given CPP claim. A “storage device” is any tangible device that can retain and store instructions for use by a computer processor. Without limitation, the computer readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing.

Some known types of storage devices that include these mediums include: diskette, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as punch cards or pits/lands formed in a major surface of a disc) or any suitable combination of the foregoing. A computer readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fiber optic cable, electrical signals communicated through a wire, and/or other transmission media. As will be understood by those of skill in the art, data is typically moved at some occasional points in time during normal operations of a storage device, such as during access, de-fragmentation or garbage collection, but this does not render the storage device as transitory because the data is not transitory while it is stored.

COMMUNICATION FABRIC111is the signal conduction paths that allow the various components of computer101to communicate with each other. Typically, this fabric comprises switches and electrically conductive paths, such as the switches and electrically conductive paths that make up busses, bridges, physical input/output ports, and the like. Other types of signal communication paths may be used, such as fiber optic communication paths and/or wireless communication paths.

Referring now toFIG.1B, an illustrative cloud environment150is depicted. As shown, cloud computing environment160includes one or more cloud computing nodes162with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone154A, desktop computer154B, laptop computer154C, and/or automobile computer system154N may communicate. Nodes162may communicate with one another. They may be grouped (not shown) physically or virtually in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment160to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices154A-N shown inFIG.1Bare intended to be illustrative only and that computing nodes162and cloud computing environment160can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Referring now toFIG.2A, a set of functional abstraction layers210provided by cloud computing environment160(FIG.1B) is shown. It should be understood in advance that the components, layers, and functions shown inFIG.2Aare intended to be illustrative only, and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided: Hardware and software layer60includes hardware and software components. Examples of hardware components include: mainframes61; RISC (Reduced Instruction Set Computer) architecture-based servers62; servers63; blade servers64; storage devices65; and networks and networking components66. In some embodiments, software components include network application server software67and database software68. Virtualization layer70provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers71; virtual storage72; virtual networks73, including virtual private networks; virtual applications and operating systems74; and virtual clients75. In one example, management layer80may provide the functions described below. Resource provisioning81provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing82provide cost tracking as resources are utilized within the cloud computing environment and billing or invoicing to consume these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal83provides access to the cloud computing environment for consumers and system administrators. Service level management84provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment85provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.

FIG.2Billustrates a process220of a host platform providing a dynamic view of a debugging state of a software system according to example embodiments. Referring toFIG.2B, when a debugger234starts (e.g., a debugging software program within a user interface/workspace where debugging actions and input can be entered), the debugger234may attach or otherwise couple to a software system232to perform debugging of the software system232. For example, the debugger234may receive an application identifier, network location, etc., of the software application and attached to the software system232based on this data. The debugger234may detect errors and other defects in the software system232and enable the errors and other defects to the corrected with changes and modifications to the underlying code of the software system232. As an example, the software system232may be an application, program, service, API, or the like, that is embodied within any of a number of different programming languages.

According to various embodiments, the debugger234may display an option to see debugging attributes associated with the software system232. As an example, when a developer222loads the debugger234and starts debugging the software system232via a user interface output by the debugger234, the debugger234may output a button within the user interface that allows the developer to select and see the debugging attributes. As another example, the debugging attributes may automatically be displayed within the debugging user interface by default without the user making a selection. If selected, the debugger234may notify the dynamic view generator236which generates a dynamic view of the debugging actions which have been performed to the software system232. For example, the debugging actions may include previously recorded/tracked debugging actions identified by the dynamic view generator236from the debugger234(e.g., a runtime environment of the debugger234, etc.) stored in a data store238accessible to the dynamic view generator236. For example, each debugging action performed by the developer222or any other developer (such as developer224) with respect to the software system232may be recorded within the data store238.

The debugger234may offer an application programming interface (API) or other interface which allows the dynamic view generator236to query the debugger234for attributes or the current debugging process such as identifying what objects are created, modified, deleted, copied, etc., as a result of the debugging actions performed in the runtime environment of the debugger234. This data may be recorded by the debugger234in a log or other storage structure, and transferred to the dynamic view generator236in response to a request from the dynamic view generator such as an API call or automatically delivered to the dynamic view generator236by default.

The dynamic view generator236may identify which objects have been created, which objects have been destroyed or deleted, method calls to methods within the objects, and the like. Based on this information, the dynamic view generator236may determine a rate of creation and a rate of destruction for one or more objects within the software system232(such as an object of code within a JAVA program, etc.) Also based on previous object's creation and destruction, the dynamic view generator236can forecast the current age of the debug object and how near it is to its destruction. Also method call rate can be shown which will indicate how frequently a method is called.

The dynamic view generator236may generate a window with the dynamic debugging state information displayed therein and output the window within a dashboard or other user interface where the debugging is performed within the debugger234. The more data the developer has, the easier it is for the developer to optimize the underlying code if these parameters are off the normal limit. A high value could also mean a programming error or a high rate especially in a I/O method could be a potential security risk. In some embodiments, the dynamic view generator236may determine the rate of creation and destruction of one or more objects based on a predetermined period of time (e.g. per second, per minute, per hour, etc.) which can provide a more comprehensive state of the debugging of the software system232. A few scenarios like “Stack Overflow”, “Out of Memory” and sluggish or freeze behaviors would be better understood and a solution would be reached much faster. As an example, a threshold in these values could also be logged in a debug log. Also an ability of debugger234to stop if threshold is breached would help the debugger234. Watching a trend line in a profile would not achieve this as there are multiple parameters to be watched and also it is preferred to be done along with debugging. Total method calls and objects created/destructed may not give the same detailed information required to understand the root problem.

FIG.3Aillustrates an example of a permissioned blockchain network300, which features a distributed, decentralized peer-to-peer architecture. The blockchain network may interact with the cloud computing environment160, allowing additional functionality such as peer-to-peer authentication for data written to a distributed ledger. In this example, a blockchain user302may initiate a transaction to the permissioned blockchain304. In this example, the transaction can be a deploy, invoke, or query, and may be issued through a client-side application leveraging an SDK, directly through an API, etc. Networks may provide access to a regulator306, such as an auditor. A blockchain network operator308manages member permissions, such as enrolling the regulator306as an “auditor” and the blockchain user302as a “client”. An auditor could be restricted only to querying the ledger, whereas a client could be authorized to deploy, invoke, and query certain types of chaincode.

A blockchain developer310can write chaincode and client-side applications. The blockchain developer310can deploy chaincode directly to the network through an interface. To include credentials from a traditional data source312in chaincode, the developer310could use an out-of-band connection to access the data. In this example, the blockchain user302connects to the permissioned blockchain304through a peer node314. Before proceeding with any transactions, the peer node314retrieves the user's enrollment and transaction certificates from a certificate authority316, which manages user roles and permissions. In some cases, blockchain users must possess these digital certificates in order to transact on the permissioned blockchain304. Meanwhile, a user attempting to utilize chaincode may be required to verify their credentials on the traditional data source312. To confirm the user's authorization, chaincode can use an out-of-band connection to this data through a traditional processing platform318.

FIG.3Billustrates another example of a permissioned blockchain network320, which features a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user322may submit a transaction to the permissioned blockchain324. In this example, the transaction can be a deploy, invoke, or query, and may be issued through a client-side application leveraging an SDK, directly through an API, etc. Networks may provide access to a regulator326, such as an auditor. A blockchain network operator328manages member permissions, such as enrolling the regulator326as an “auditor” and the blockchain user322as a “client”. An auditor could be restricted only to querying the ledger, whereas a client could be authorized to deploy, invoke, and query certain types of chaincode.

A blockchain developer330writes chaincode and client-side applications. The blockchain developer330can deploy chaincode directly to the network through an interface. To include credentials from a traditional data source332in chaincode, the developer330could use an out-of-band connection to access the data. In this example, the blockchain user322connects to the network through a peer node334. Before proceeding with any transactions, the peer node334retrieves the user's enrollment and transaction certificates from the certificate authority336. In some cases, blockchain users must possess these digital certificates in order to transact on the permissioned blockchain324. Meanwhile, a user attempting to utilize chaincode may be required to verify their credentials on the traditional data source332. To confirm the user's authorization, chaincode can use an out-of-band connection to this data through a traditional processing platform338.

In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast with permissioned blockchains, which require permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain a user may create a personal address and begin interacting with the network by submitting transactions and hence adding entries to the ledger. Additionally, all parties have the choice of running a node on the system and employing the mining protocols to help verify transactions.

FIG.3Cillustrates a process350of a transaction being processed by a permissionless blockchain352, including a plurality of nodes354. A sender356desires to send payment or some other form of value (e.g., a deed, medical records, a contract, a good, a service, or any other asset that can be encapsulated in a digital record) to a recipient358via the permissionless blockchain352. In one embodiment, each of the sender device356and the recipient device358may have digital wallets (associated with the blockchain352) that provide user interface controls and a display of transaction parameters. In response, the transaction is broadcast throughout the blockchain352to the nodes354. Depending on the blockchain's352network parameters, the nodes verify360the transaction based on rules (which may be pre-defined or dynamically allocated) established by the permissionless blockchain352creators. For example, this may include verifying the identities of the parties involved, etc. The transaction may be verified immediately or it may be placed in a queue with other transactions, and the nodes354determine if the transactions are valid based on a set of network rules.

In structure362, valid transactions are formed into a block and sealed with a lock (hash). This process may be performed by mining nodes among the nodes354. Mining nodes may utilize additional software specifically for mining and creating blocks for the permissionless blockchain352. Each block may be identified by a hash (e.g., 256-bit number, etc.) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to a hash of a previous block's header in the chain, and a group of valid transactions. The reference to the previous block's hash is associated with the creation of the secure independent chain of blocks.

Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain352may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header. Although not shown in the example ofFIG.3C, another process for validating a block is proof-of-stake. Unlike the proof-of-work, where the algorithm rewards miners who solve mathematical problems, with the proof of stake, a creator of a new block is chosen in a deterministic way, depending on its wealth, also defined as “stake.” Then, a similar proof is performed by the selected/chosen node.

With mining364, nodes try to solve the block by making incremental changes to one variable until the solution satisfies a network-wide target. This creates the PoW, thereby ensuring correct answers. In other words, a potential solution must prove that computing resources were drained in solving the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins, etc.) for correctly mining a block.

Here, the PoW process, alongside the chaining of blocks, makes modifications of the blockchain extremely difficult, as an attacker must modify all subsequent blocks in order for the modifications of one block to be accepted. Furthermore, as new blocks are mined, the difficulty of modifying a block increases, and the number of subsequent blocks increases. With distribution366, the successfully validated block is distributed through the permissionless blockchain352, and all nodes354add the block to a majority chain which is the permissionless blockchain's352auditable ledger. Furthermore, the value in the transaction submitted by the sender356is deposited or otherwise transferred to the digital wallet of the recipient device358.

FIGS.3D and3Eillustrate additional examples of use cases for cloud computing that may be incorporated and used herein.FIG.3Dillustrates an example370of a cloud computing environment160, which stores machine learning (artificial intelligence) data. Machine learning relies on vast quantities of historical data (or training data) to build predictive models for accurate prediction on new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to unearth non-intuitive patterns.

In the example ofFIG.3D, a host platform376, builds and deploys a machine learning model for predictive monitoring of assets378. Here, the host platform366may be a cloud platform, an industrial server, a web server, a personal computer, a user device, and the like. Assets378can be any type of asset (e.g., machine or equipment, etc.) such as an aircraft, locomotive, turbine, medical machinery and equipment, oil and gas equipment, boats, ships, vehicles, and the like. As another example, assets378may be non-tangible assets such as stocks, currency, digital coins, insurance, or the like.

The cloud computing environment160can be used to significantly improve both a training process372of the machine learning model and a predictive process374based on a trained machine learning model. For example, in372, rather than requiring a data scientist/engineer or another user to collect the data, historical data may be stored by the assets378themselves (or through an intermediary, not shown) on the cloud computing environment160. This can significantly reduce the collection time needed by the host platform376when performing predictive model training. For example, data can be directly and reliably transferred straight from its place of origin to the cloud computing environment160. By using the cloud computing environment160to ensure the security and ownership of the collected data, smart contracts may directly send the data from the assets to the individuals that use the data for building a machine learning model. This allows for sharing of data among the assets378.

Furthermore, training of the machine learning model on the collected data may take rounds of refinement and testing by the host platform376. Each round may be based on additional data or data that was not previously considered to help expand the knowledge of the machine learning model. In372, the different training and testing steps (and the associated data) may be stored on the cloud computing environment160by the host platform376. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored in the cloud computing environment160to provide verifiable proof of how the model was trained and what data was used to train the model. For example, the machine learning model may be stored on a blockchain to provide verifiable proof Furthermore, when the host platform376has achieved a trained model, the resulting model may be stored on the cloud computing environment160.

After the model has been trained, it may be deployed to a live environment where it can make predictions/decisions based on executing the final trained machine learning model. For example, in374, the machine learning model may be used for condition-based maintenance (CBM) for an asset such as an aircraft, a wind turbine, a healthcare machine, and the like. In this example, data fed back from asset378may be input into the machine learning model and used to make event predictions such as failure events, error codes, and the like. Determinations made by executing the machine learning model at the host platform376may be stored on the cloud computing environment160to provide auditable/verifiable proof As one non-limiting example, the machine learning model may predict a future breakdown/failure to a part of the asset378and create an alert or a notification to replace the part. The data behind this decision may be stored by the host platform376and/or on the cloud computing environment160. In one embodiment, the features and/or the actions described and/or depicted herein can occur on or with respect to the cloud computing environment160.

FIG.3Eillustrates an example380of a quantum-secure cloud computing environment382, which implements quantum key distribution (QKD) to protect against a quantum computing attack. In this example, cloud computing users can verify each other's identities using QKD. This sends information using quantum particles such as photons, which cannot be copied by an eavesdropper without destroying them. In this way, a sender and a receiver through the cloud computing environment can be sure of each other's identity.

In the example ofFIG.3E, four users are present384,386,388, and390. Each pair of users may share a secret key392(i.e., a QKD) between themselves. Since there are four nodes in this example, six pairs of nodes exist, and therefore six different secret keys392are used, including QKDAB, QKDAC, QKDAD, QKDBC, QKDBD, and QKDCD. Each pair can create a QKD by sending information using quantum particles such as photons, which cannot be copied by an eavesdropper without destroying them. In this way, a pair of users can be sure of each other's identity.

The operation of the cloud computing environment382is based on two procedures (i) creation of transactions and (ii) construction of blocks that aggregate the new transactions. New transactions may be created similar to a traditional network, such as a blockchain network. Each transaction may contain information about a sender, a receiver, a time of creation, an amount (or value) to be transferred, a list of reference transactions that justifies the sender has funds for the operation, and the like. This transaction record is then sent to all other nodes, where it is entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 384-390) authenticate the transaction by providing their shared secret key392(QKD). This quantum signature can be attached to every transaction, making it exceedingly difficult to be tampered with. Each node checks its entries with respect to a local copy of the cloud computing environment382to verify that each transaction has sufficient funds.

FIGS.4A-4Billustrate a process of tracking a debugging state of a software system and outputting a dynamic view of the debugging state within the debugging environment according to example embodiments. For example,FIG.4Aillustrates a process400of transferring debugging data from a runtime environment of a debugger412to a dynamic view generator426system described according to various embodiments. Referring toFIGS.4A and4B, a runtime environment410of the debugger412is shown. Here, the debugger412is hosted by a host platform such as a cloud platform, a web server, a database, a distributed system, or the like, which is not shown in the drawing for brevity. Developers may request to debug a software system414via the debugger412to detect and fix defects associated with the software system414. The debugging actions that are performed by the developers (or other users that are testing the software system414via the debugger412) may be captured by the runtime environment410such as a service or program associated with an application programming interface API416of the debugger412. The debugging actions may include object creation, object destruction, method calls to one or more objects, and the like. The debugging actions may be tracked and recorded within a data store418of the debugger412.

According to various embodiments, the recorded debugging actions can be transferred to a dynamic view generator system420for analyzing the debugging actions and generating useful insight which can be output via a display window within the debugging environment and visible to all of the developers and testers thereby providing a global understanding of the actions that have been performed to the software system414in an accumulated/aggregated manner that combines actions from one or more users within a debugging environment and generates and displays insights based on such combination of actions. As an example, the debugging environment may be a collaborative environment where multiple users share in access and debugging of the software system414. As another example, the debugging environment may only include one user. In either scenario, the dynamic view generator420may display dynamic debugging attributes accumulated from user actions.

For example, the dynamic view generator420may include a query service421that can query the API416of the debugger412to retrieve the tracked debugging actions recorded in the data store418. An object create tracker422may count the number of times each object within the software system414is newly instantiated/created as a result of the debugging actions. An object destruct tracker423can count the number of times an instance of each object within the software system414is destroyed. In addition, the dynamic view generator420may include an object end predictor424configured to predict a current age of an object and an end of life of the object within the software system414based on the debugging actions. Furthermore, the dynamic view generator420may include a method call tracker425that counts the number of calls to each method within an object of the software system414.

FIG.4Billustrates a process430of generating and outputting a window or other visualization within a user interface430associated with the debugging process performed by the developers and other testers via the debugger412. In this example, the attributes detected by the components of the dynamic view generator420may be output within the user interface430of the debugger412. For example, the attributes may be displayed within an existing window, workspace, banner, etc. of the debugger412. As another example, the attributes may be displayed within a pop-up window or other graphical means. Here, a dynamic viewer426component builds the user interface using a template and inserts attributes such as object rate of creation, object rate of destruction, object age, estimated object end of life, method call rate, and the like, within the user interface430of the debugger412.

An example of the types of debugging attributes that can be output via the user interface430are shown inFIGS.4C-4E. For example,FIG.4Cillustrates a visualization of a graph440with a rate of creation for a plurality of different objects (classes) within the software system414being tested by the debugger412. As another example,FIG.4Dillustrates a visualization of a graph450with a rate of method calls for a number of methods within a particular object (class) or objects of the software system414. The graphs may include charts such as bar charts, line charts, time-series data, and the like. Also, the visualizations may be embedded or otherwise integrated into the user interface430of the debugger412. For example, a template or other predefined structure may be used to format the visualization, and the visualization may be embedded within a predefined location of the user interface430which is denoted by the application template or the like.

FIG.4Eillustrates an example of a visualization460of object age information which includes both a current age and an estimated end of life for each of a plurality of objects included within the software system414. The visualization460may identify each object as well. The dynamic view generator420may include machine learning algorithms, artificial intelligence, and the like, which can be used to analyze the history of a software system and predict the likely end of life.

FIG.5illustrates a method of providing a dynamic view of a debugging state of a software system according to example embodiments. For example, the method may be performed by a container engine hosted on a cloud platform or other host system such as a web server, a database, a distributed network of systems, and the like. Referring toFIG.5, in510, the method may include tracking debugging actions performed to a software system via a runtime environment of the debugging actions. For example, the tracking may include recording debugging actions performed by a plurality of users of the software system and identifying the one or more attributes of the object of the software system based on the recorded debugging actions of the plurality of users.

In520, the method may include identifying one or more debugging attributes of an object of the software system based on the tracked debugging actions performed to the software system. In530, the method may include generating a window which includes details of the one or more identified debugging attributes of the object. In540, the method may include displaying the window which includes the details of the one or more identified debugging attributes via a user interface of a debugging program.

In some embodiments, the identifying may include identifying a rate of creation of the object over a predetermined period of time based on the tracked debugging actions performed to the software system and the displaying comprises displaying the identified rate of creation of the object via the window. In some embodiments, the identifying may include identifying a rate of destruction of the object over a predetermined period of time based on the tracked debugging actions performed to the software system and displaying the identified rate of destruction of the object via the window.

In some embodiments, the identifying may include identifying a rate of invocation of a method of the object over a predetermined period of time based on the tracked debugging actions performed to the software system and the displaying comprises displaying the identified rate of the method calls to the method of the object via the window. In some embodiments, the method may further include predicting an estimated end of life of the object and the displaying comprises displaying the predicted estimate of the end of life of the object via the window.

In some embodiments, the identifying may include identifying a value of a debugging attribute of each respective object from among a plurality of objects of the software system over a predetermined period of time based on the tracked debugging actions and the displaying comprises displaying the value of the debugging attribute of each respective object from among the plurality of objects via the window. In some embodiments, the method may further include determining an age of the object based on the tracked debugging actions and the displaying comprises displaying the determined age of the object via the window.

FIG.6illustrates an example system600that supports one or more of the example embodiments described and/or depicted herein. The system600comprises a computer system/server602, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computer system/server602include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

As shown inFIG.6, computer system/server602in cloud computing node600is shown in the form of a general-purpose computing device. The components of computer system/server602may include, but are not limited to, one or more processors or processing units604, a system memory606, and a bus that couples various system components, including system memory606to processor604.

Program/utility616, having a set (at least one) of program modules618, may be stored in memory606by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof may include an implementation of a networking environment. Program modules618generally carry out the functions and/or methodologies of various application embodiments as described herein.

Computer system/server602may also communicate with one or more external devices620such as a keyboard, a pointing device, a display622, etc.; one or more devices that enable a user to interact with computer system/server602; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server602to communicate with one or more other computing devices. Such communication can occur via I/O interfaces624. Still yet, computer system/server602can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter626. As depicted, network adapter626communicates with the other components of computer system/server602via a bus. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server602. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archival storage systems, etc.

One having ordinary skill in the art will readily understand that the above may be practiced with steps in a different order and/or with hardware elements in configurations that are different from those which are disclosed. Therefore, although the application has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent.