Abstract: A computing system includes a logic subsystem and memory storing instructions executable by the logic subsystem. The instructions are executable by the logic subsystem to store, in the memory, a plurality of software models that each describe aspects of a network connected device or a software service, the plurality of software models comprising a first version of a selected software model. The logic subsystem is configured to receive a second version of the selected software model and validate the second version of the selected software model via validation logic by applying one or more versioning rules to the second version of the selected software model. Based on the application of the one or more versioning rules, the logic subsystem is configured to execute a versioning action on the selected software model.

Abstract: A computer system is provided that includes one or more processors configured to store a plurality of software interfaces that define explicit interaction contracts between network connected devices and software services. The one or more processors are configured to execute a plurality of software services. Each software service defines one or more software interfaces operated on by that software service. The one or more processors are configured to receive, from a network connected device, a list of one or more software interfaces implemented by the network connected device, select one or more software services based on a match between the one or more software interfaces implemented by the network connected device and the one or more software interfaces operated on by the plurality of software services, and process data received from the network connected device using the selected software services.

Abstract: A computing system includes a logic subsystem and memory storing instructions executable by the logic subsystem. The instructions are executable by the logic subsystem to store, in the memory, a plurality of software models that each describe aspects of a network connected device or a software service, the plurality of software models comprising a first version of a selected software model. The logic subsystem is configured to receive a second version of the selected software model and validate the second version of the selected software model via validation logic by applying one or more versioning rules to the second version of the selected software model. Based on the application of the one or more versioning rules, the logic subsystem is configured to execute a versioning action on the selected software model.

Abstract: A computer system is provided that includes one or more processors configured to store a plurality of software interfaces that define explicit interaction contracts between network connected devices and software services. The one or more processors are configured to execute a plurality of software services. Each software service defines one or more software interfaces operated on by that software service. The one or more processors are configured to receive, from a network connected device, a list of one or more software interfaces implemented by the network connected device, select one or more software services based on a match between the one or more software interfaces implemented by the network connected device and the one or more software interfaces operated on by the plurality of software services, and process data received from the network connected device using the selected software services.

Abstract: Tools and techniques assist developers with the detection of memory leaks by using correlation of data type memory usage trends. In particular, investigations of memory leaks can be prioritized without always resorting to the use of bulky and performance-degrading memory dumps, by using these tools and techniques to identify leaky correlated data types. Data about a program's memory usage is processed to identify memory usage trends over time for respective data types, and the trends are searched for significant correlations. Correlated trends (and hence their corresponding data types) are grouped. Memory usage analysis information is displayed for grouped data types, such as the names of the most rapidly leaking data types, the names of correlated data types, leak rates, and leak amounts in terms of memory size and/or data object counts. Memory usage data may also be correlated with processing load requests to indicate which requests have associated memory leaks.

Abstract: Tools and techniques assist developers with the detection of memory leaks by using correlation of data type memory usage trends. In particular, investigations of memory leaks can be prioritized without always resorting to the use of bulky and performance-degrading memory dumps, by using these tools and techniques to identify leaky correlated data types. Data about a program's memory usage is processed to identify memory usage trends over time for respective data types, and the trends are searched for significant correlations. Correlated trends (and hence their corresponding data types) are grouped. Memory usage analysis information is displayed for grouped data types, such as the names of the most rapidly leaking data types, the names of correlated data types, leak rates, and leak amounts in terms of memory size and/or data object counts. Memory usage data may also be correlated with processing load requests to indicate which requests have associated memory leaks.

Abstract: The formulation of an architectural diagram of a software program having multiple components. A static model identifying at least some of the components and a relationship between the components is accessed by perhaps performing a static code analysis of the code of the software program. A dynamic analysis is also performed by executing the software program, and observing the execution to derive dynamic behaviors of the software program. These dynamic behaviors may perhaps be information that is not readily available based on a static code analysis of the computer program alone, such as parameter values exchanged, paths of execution, and additional components invoked. The architectural diagram is then formulated using the static model and the dynamic behaviors to generate a more complete representation of the computer program.

Abstract: The formulation of an architectural diagram of a software program having multiple components. A static model identifying at least some of the components and a relationship between the components is accessed by perhaps performing a static code analysis of the code of the software program. A dynamic analysis is also performed by executing the software program, and observing the execution to derive dynamic behaviors of the software program. These dynamic behaviors may perhaps be information that is not readily available based on a static code analysis of the computer program alone, such as parameter values exchanged, paths of execution, and additional components invoked. The architectural diagram is then formulated using the static model and the dynamic behaviors to generate a more complete representation of the computer program.

Abstract: A debugger casuality feature is provided. Debugger casuality is the ability of a cooperating debugger to associate an ordered set of casuality related threads, possibly originating from different processes, as a logical thread of execution. In an illustrative implementation, systems and methods are provided allowing for the execution and management of debugger casuality within a computing environment. In the contemplated implementation casuality hooks are provided for integration with calls found in software operating in a computing environment. The hooks help attach a cooperating debugger to be able to step through a call executing in the computing environment. The casuality hooks provide the ability to step between logically related physical threads executing in a given computing environment. The physical threads ranging from single process, multi-threaded applications to multi-machine, multi-process systems.

Abstract: A debugger causality feature is provided. Debugger causality is the ability of a cooperating debugger to associate an ordered set of causally related physical threads, possibly originating from different processes, as a logical thread of execution. In an illustrative implementation, systems and methods are provided allowing for the execution and management of debugger causality within a computing environment. In the contemplated implementation causality hooks are provided for integration with calls found in software operating in a computing environment. The hooks help attach a cooperating debugger to be able to step through a the call executing in the computing environment. The causality hooks provide the ability to step between logically related physical threads executing in a given computing environment. The physical threads ranging from single process, multi-threaded applications to multi-machine, multi-process systems.