Abstract: Embodiments of the present invention provide a mechanism for certifying the compatibility of a software product by identifying the interfaces (API or ABI) used by that product. The source code or object code of a component is analyzed by a tool that traces which interfaces and data structures of an ABI/API are being utilized. For example, an ISV or IHV may be required to run the tool on their respective components in order to have that component certified with a particular version of an operating system and submit the results to a certification service. The certification service may collect this API/ABI information into an integrated database. The certification service may then use this database to analyze the impact of changes to an operating system at the binary interface level, proactively notify vendors prior to these changes, test compatibility and emulation libraries, and certify components are compatible with an operating system without the need of significant testing.

Abstract: A method, system, and computer-readable medium for maintaining a health of a software factory that creates custom software in a standardized manner is presented. In a preferred embodiment, the method includes the steps of: defining work packets to perform sub-functions of a custom software; tracking a transmission of the work packets to an assembly line in a software factory; monitoring any retrieval of software artifacts that are used to create the work packets; monitoring any on-going changes of work activities that are contained in the work packets; determining if execution of the work packets conforms to governance guidelines for the software factory; monitoring the software factory to ensure that the work packets comply with an architecture of the software factory; tracking quality metrics for an execution of the work packets in an assembly line in the software factory; and transmitting all tracked and monitored information described above to a dashboard.

Abstract: Methods, systems, and computer program products for aggregating service components in a data processing system according to predefined aggregation rules. The method includes providing a plurality of visual elements, each visual element representing a corresponding service component; selecting a new visual element for addition to an aggregation structure; determining a set of eligible visual elements of eligible service components among the instantiated service components; associating a visual cue with the eligible visual elements; and aggregating the new service component to a selected eligible service component in the aggregation structure. The new service component is compatible for aggregation with each eligible service component according to the aggregation rules. The aggregation structure includes an aggregation of instantiated visual elements of instantiated service components to define an aggregated service according to the aggregation of the instantiated service components.

Abstract: A system and method for dynamically associating an application with an extension service to generate an extended, dynamically linked version of the application. The application is configurable for deployment on an electronic device and for subsequent interaction with the extension service during execution through communication messages defined in a structured definition language. The system and method include a parser module configured for analyzing a set of service metadata descriptors to identify a communication interface associated with the extension service, such that the service metadata descriptors describe the communication interface including structure and type of parameters expected by the extension service for use in manipulation of the communication messages.

Abstract: An integrated system is provided for synchronizing source code development in an external program development application with source code development in an internal program development environment as a part of a separate Enterprise Management Application (EMA). The integrated system allows for source control operations to be executed in an external program development application and the source control operations to be synchronized with the source code control system contained in the EMA. The source code control system may enable multiple users in a collaborative development environment to modify source code elements on each user's local program development environment, and user modifications may be synchronized with the source control and updated in the source control system to reflect editing status of repository elements in the source control and the latest updated version of a source code element in the source control system repository.

Abstract: A mechanism for providing a source code control system that employs test case execution results to mandate that software code have a specific level of quality for check-in to a central repository. A request to check-in a modified copy of a source code file to a repository is received, wherein the modified copy comprises changes to the source code file located in the repository. The modified copy of the source code file is placed in a quality check pending state in the repository. Responsive to an occurrence of a specific event or expiration of a set time period, applicable regression test cases are executed against the changes in the modified copy. A determination is made as to whether the regression test cases are successful. If the regression test cases are successful, the changes in the modified copy are committed to the source code file located in the repository.

Abstract: A method and system is described for managing the development of software source code, and in addition, collecting useful metrics about the development process. A first source code is provided in a desired state. The desired state may be the requirement that the source code can be built or the desired state may be the requirement that the source code can be built and pass one or more tests. A second source code is then received. The second source may be a modified copy of the source code. It is then determined whether the second source code is in the desired state, and the first source code is updated using the second source code in response to the second source code being in the desired state. Metrics that may be collected include: the name of a task, time to complete the task, line of code involved, etc.

Abstract: A method and a corresponding apparatus for inventorying software products on a plurality of computer are proposed. The inventorying system aims at populating a software catalogue without the manual intervention of an administrator. The present invention reduces the cost of producing and maintaining a comprehensive knowledge base (the catalogue) which contains definitions of software products and the related signature. Information about software products and their related signature is obtained through a process which gathers information from a potentially very large collection of computers. Any occurrence of a group of identical files across multiple computers is considered a reliable indicator that they belong to the installation footprint of a product.

Abstract: A data set may be represented as a hierarchical node set, comprising interrelated nodes that respectively include various data features (e.g., versions in a version-controlled software architecture.) Queries may be formulated regarding the inclusion of a particular feature in the nodes of the hierarchical data set (“does this node include this data feature?” and “what is the path of the data feature through the node set?”) Such queries may be evaluated by identifying a source node that includes the data feature, identifying candidate merge paths from the source node to the taget node, and determining whether the nodes of any candidate merge path include the data feature. The results may be presented to the user, e.g., as a visual layout of the portion of the hierarchical node set that includes the data feature or a timeline of nodes illustrating the path of the data feature over time.

Abstract: Systems and methods provide an operation of digital content assemblages such as video games with a digital processor so as to control platform dependent replacement of digital asset components. In a video game package operated on a first platform, the video game includes one or more first digital asset components such musical and/or graphical works. Platform association data is accessed to evaluate an association between the first digital asset component and the first platform. The platform association data is checked for a concurrence between the platform association data and platform data. A second digital asset component is substituted for the first digital asset component in accordance with the check of the platform association data to permit the operating of the digital content assemblage with the second digital asset component as a replacement for the first digital asset component.

Abstract: A method for deploying a software product comprising a plurality of components is provided. The method can include reading a topological description of the software product and its components, wherein the topological description defines characteristics and dependencies of the components. The method can further include reading characteristics of a plurality of publishers and matching each of the plurality of components to one of the plurality of publishers according to the characteristics and dependencies of the components and the characteristics of the plurality of publishers. A publisher may be a computer connected to a network. The method can further include distributing the plurality of components among the plurality of publishers responsive to the step of matching and validating each set of components distributed to each publisher.

Abstract: Certain exemplary embodiments can provide a system, which can comprise a block processor. The block processor can be adapted to automatically render a list of automatically described modifications to a first version of a block of a software program adapted to control a programmable logic controller (PLC). The first version can differ from an original version of the block.

Abstract: In some embodiments, an apparatus can comprise a memory unit including, two or more assemblies, wherein the two or more assemblies include a first assembly and a second assembly, wherein the second assembly is a later version of the first assembly, and wherein the first and second assemblies include, a stub module configured to detect an assembly initialization request indicating one of the first or second assemblies. The stub module can also be configured to retrieve a reference to a symbol table associated with the one of the first and second assemblies indicated in the assembly initialization request, to store data in the symbol table, and to provide the reference to a caller. The memory unit can also comprise an implementation module configured to perform operations associated with symbols in the symbol table and a processor configured to receive and execute one or more of the stub and implementation modules.

Abstract: A computer implemented method for automatically generating domain specific applications based on model driven changes of the source code base for existing applications. Abstracted declarative design change-models, separate from detailed implementation source coding, are used to define the possible set of changes for specific application domains. Generalized implementations of the design changes, mapped to the defined Change-Model abstracted representations but separate from the representations themselves, are implemented via Application-Templates consisting of existing source code plus mark-up. The application domain is thus defined by the change-model linked to allied application-templates. Meta generation facilities are implicitly provided as the code generator for a specific application domain is defined by the Change-Model plus related set of Application-Templates.

Abstract: A computer-implemented method executed by a server processor for generating a software product comprises generating modules, each module being described by module metadata, and for each generated module, adding dependencies on other modules to the module metadata, creating a nest, the nest comprising data describing a development environment of a client processor for the module, and adding the nest to the module metadata, and further comprising storing the module metadata with a database connected to the server processor, providing a created nest to the client processor for being loaded into the development environment of the client processor, and building the module and publishing the built module to a publication repository connected to the server processor. Furthermore, there is provided a system for generating a software product and being adapted for performing the computer-implemented method.

Abstract: A build process management system can acquire data pertaining to a software build process that is currently being executed by an automated software build system. The software build process can include executable process steps, metadata, and/or environmental parameter values. An executable process step can utilize a build artifact, representing an electronic document that supports the software build process. The acquired data can then be synthesized into an immutable baseline build process and associated baseline artifact library. The baseline artifact library can store copies of the build artifacts. The immutable baseline build process can include baseline objects that represent data values and dependencies indicated in the software build process. In response to a user-specified command, an operation can be performed upon the baseline build process and associated baseline artifact library.

Abstract: A build process management system can acquire data pertaining to a software build process that is currently being executed by an automated software build system. The software build process can include executable process steps, metadata, and/or environmental parameter values. An executable process step can utilize a build artifact, representing an electronic document that supports the software build process. The acquired data can then be synthesized into an immutable baseline build process and associated baseline artifact library. The baseline artifact library can store copies of the build artifacts. The immutable baseline build process can include baseline objects that represent data values and dependencies indicated in the software build process. In response to a user-specified command, an operation can be performed upon the baseline build process and associated baseline artifact library.

Abstract: A requirement for a versioned resource is fulfilled, particularly in light of compatibility constraints of the requirement. Versions of the versioned resource are associated with compatibility information, such as a feature version and a service version, for example. In fulfilling the requirement, compatibility logic may be applied to identify versions that are compatible with the requirement, and selection logic may be applied to select a preferred version from the compatible versions.

Abstract: Disclosed are a VoIP server apparatus and a method for maintaining VoIP server software in the server apparatus which transmits/receives a packet to/from an IP terminal via network to provide VoIP service. The method includes: assigning a virtual IP address to the server apparatus; associating a first IP address used by first VoIP server software with the virtual IP address; activating second VoIP server software while the first VoIP server software receives a packet addressed to the virtual IP address and provides VoIP service; changing the association of the virtual IP address with the first IP address to association of the virtual IP address with a second IP address used by the second VoIP server software; receiving a packet addressed to the virtual IP address by the second VoIP server software; and changing VoIP service by the first VoIP server software to VoIP service by the second VoIP server software.

Abstract: A method for building and verifying and validating a software system that is used for regulated industry software related activities, such as FDA trials, field trials, biomedical data gathering, and similar efforts includes building the application into a virtual appliance using, for example, Vmware. The application and the supporting software are encapsulated in a single virtual file to create a virtual appliance that is independent of hardware and dependent only on virtual appliance support.

Abstract: Embodiments of the present invention address deficiencies of the art in respect to defect classification for software development and provide a method, system and computer program product for automated defect classification in a software development tool. In an embodiment of the invention, a defect classification method can be provided. The method can include computing differences between versions of a line of source code, lexically analyzing the computed differences to produce a lexical construct, mapping the lexical construct to a classification, and assigning the defect classification to the line of source code.

Abstract: Software is provisioned by providing a repository that contains a software trove. A local changeset is generated that represents differences between a version of the software trove on the repository and a corresponding version of the software trove on a local system.

Abstract: Software is provisioned by providing a repository that contains software files available for provisioning. At least one tag is associated with respective ones of at least a subset of the software files, the tags describing the at least a subset of the software files. A tag handler is used to process at least one detected change affecting at least one of the software files having a tag associated therewith.

Abstract: It may be advantageous to facilitate communication between two types of source code. For example, a wrapper may be generated to translate between managed source code and native source code. Current techniques may translate a single type of native source code into a managed binary wrapper. However, as provided herein, a managed source code wrapper may be generated based upon a variety of native source code formats. A native binary descriptor describing a set of native code may be received. A provider may be selected based upon the format of the set of native code. The provider may be executed upon the native binary descriptor to produce a common native binary description. A managed source code wrapper may be generated based upon the common native binary description. Because the managed source code wrapper may be in a textual source code format, a developer may easily maintain and/or customize the wrapper.

Abstract: A method and apparatuses for allowing additional tail call optimizations. The compiler generates both optimized and non-optimized code for tail call candidates. At a later time when there is more information (e.g. regarding program bounds), a decision and a modification to the executable code is made, implementing one of the two earlier codes.

Abstract: A method is provided for executing guest computations in a virtual machine of a virtualization system and forcing execution of registered code into an execution context of the guest. The forcing is performed from the virtualization system based on an execution trigger monitored without reliance on functionality of the guest software.

Abstract: Tools are provided for locating changes in source code. More particularly, tools are provided for use with an integrated development environment having a source code management system for locating related changes in source code. Changed elements of target source code are located in a source code repository by acquiring a search term and by locating one or more references to changed elements of target source code containing the search term, wherein the located references are provided in order of the most recently changed located source code reference.

Abstract: A system is provided comprising a computer and application that creates a development zone in response to a first message. The zone comprises a recording of state-based references to files and folders of a master production build in read-only and read-write copies of the build. The system receives another message containing a request to commit changes to the build. The changes comprise updating the build with changes to the read-write clone. The system compares the read-only snapshot with the current build to determine changes committed after the zone creation. The system compares changes to the read-write clone and changes committed to the build after zone creation. The system identifies files and folders changed in the read-write clone and commits the changes made to the read-write clone to a staging build and the master production build.

Abstract: In and for software projects, arrangements for permitting a user to understand how the spatial locality of a function call may have changed with respect to any changes in a function definition. This permits an analysis of different workflows which use the same function, wherein the definition of the function may have changed. To the extent that there might be corresponding changes in the workflows which use such a function, the user will readily develop an idea of why some workflows changed and some did not. The invention method and apparatus determine and display deltas (changes) between different versions of a file where the function call occurs.

Abstract: A method, system, and computer program product for efficiently providing software product updates in a client's computer system. A Software Product Update (SPU) utility initiates the software update process by downloading a response file. The response file comprises scripted code and encoded data for an update of application system files. The SPU utility processes the response file with the aid of a script processing engine (SPE), which is saved, along with installation files, on the client's computer system during an initial software product installation. The SPU utility sets the installation properties within the installation file set to values which allow the SPE to access and run the scripted code. The embedded binary data is decoded with the aid of the running scripted code. The SPU utility completes the update of application system files and the installation properties file, with the aid of the decoded embedded data.

Abstract: A method and system is described for managing the development of software source code, and in addition, collecting useful metrics about the development process. A first source code is provided in a desired state. The desired state may be the requirement that the source code can be built or the desired state may be the requirement that the source code can be built and pass one or more tests. A second source code is then received. The second source may be a modified copy of the source code. It is then determined whether the second source code is in the desired state, and the first source code is updated using the second source code in response to the second source code being in the desired state. Metrics that may be collected include: the name of a task, time to complete the task, line of code involved, etc.

Abstract: The disclosure provides a solution for associating deployed executables with source code. In the solution, source code of a development environment can be mapped to a deployed executable of a runtime environment. The mapping can ensure that a version of source code from which the deployed executable was produced is always known. The mapping can occur within digitally encoded data stored in a non-transient storage medium. The development environment and the runtime environment can be two distinct and separate computing environments that are isolated from each other.

Abstract: A method of testing software can include maintaining a cache within at least one of a plurality of farm machines of a testing farm. Each cache can include at least one version of test ingredients. The method can also include receiving, within at least one selected farm machine, a request to perform a test involving a test version of the test ingredients and comparing the test version of the test ingredients with versions of the test ingredients stored within the cache of the selected farm machine. The method can also include selectively updating a version of the test ingredients stored within the cache of the selected farm machine according to the comparison.

Abstract: A method for analyzing the performance of a video game uses a diagnostic tool that is associated with application code of the video game. The diagnostic tool is activated when the video game is in operation, and real-time performance data is captured and displayed. A warning is generated when a performance metric violates a pre-set condition. The warning may be displayed on a display screen that is used to provide information for rectifying the violation.

Abstract: A version control system includes a mechanism for a learning roadmap based on information available from a source repository. More particularly, the mechanism generates an easily understandable timeline of a project and a directory of developers based on information available in the version control system that contains the source content of a project. The timeline for the project may be tied to the directory of developers. Under each date in the timeline, a list of developers and their roles and commits may be listed.

Abstract: A method for creating applications optimized for use on multiple mobile devices, the method including using a computer to generate a single version of an application including at least one of content and functionality, providing the single version of the application via a computer network to a mobile device adaptation server and employing the mobile device adaptation server to automatically modify the single version of the application so as to create multiple versions corresponding to the single version, each of the multiple versions being optimized for at least one different mobile device platform.

Abstract: The mock tool can be configured to create a mock execution environment for building software packages. The mock execution environment is isolated from resources of the computing system supporting the mock execution environment and other mock execution environments. Further, the mock execution environment can be created to simulate disabling on any features of the operating system supporting the mock execution environment that could cause problems in the building the software packages.

Abstract: Topics in source code can be identified using Latent Dirichlet Allocation (LDA) by receiving source code, identifying domain specific keywords from the source code, generating a keyword matrix, processing the keyword matrix and the source code using LDA, and outputting a list of topics. The list of topics is output as collections of domain specific keywords. Probabilities of domain specific keywords belonging to their respective topics can also be output. The keyword matrix comprises weighted sums of occurrences of domain specific keywords in the source code.

Abstract: A method for using an appropriate level of code to be executed in a runtime environment. Code in a non-Java format is translated into a Java source file. During the translation process, metadata is generated from a configuration file where the metadata includes version information of the resources (e.g., JSTL) being used by the code written in the non-Java format. A determination is made as to whether to recompile the non-Java code based on software components, referred herein as “listener components,” determining whether the versions of the resources being used by the non-Java code performs acceptably well in the runtime environment. If a listener component determines that a version of a resource being used is not acceptable, then the non-Java code is recompiled with a newer version of the resource. In this manner, an appropriate level of code is executed by the runtime environment.

Abstract: In accordance with embodiments, there are provided mechanisms and methods for determining whether a developed application associated with an on-demand database service will operate properly with at least one other application. These mechanisms and methods for providing such determination can enable embodiments to ensure that new versions of developed applications will operate in the same application environment of a previous version. The ability of embodiments to make such determination may lead to an improved application migration development/runtime framework, etc.

Abstract: A method and apparatus for a guided procedure development and testing for computer code. An embodiment of a method includes receiving a component for a software program, and storing the component in an inactive state. A new version of the software program is built, the new version being limited to the component stored in the inactive state and one or more components of the software program that are in an active state, with the new version being built in the inactive state. If the building of the new version is successful, then the new version of the software program is tested. If the testing of the new version is successful, then the component is moved into the active state.

Abstract: A content management system (CMS) for computer software provides automatic notification and correlation of changes in a design document with corresponding code, and provides automatic notification and correlation of changes in the code with one or more corresponding design documents. Traceability rules are defined that correlate which portions of the code correspond to which portions of the design document. A traceability update policy governs whether interested parties are notified of a change to either the design document or the corresponding code, and whether the change to one causes an automatic update to the other. The result is a content management system that helps keep the code and corresponding design documents consistent with each other so the system has accurate and consistent information at all times.

Abstract: Various technologies and techniques are disclosed for providing an object model for transactional memory. The object model for transactional memory allows transactional semantics to be separated from program flow. Memory transaction objects created using the object model can live beyond the instantiating execution scope, which allows additional details about the memory transaction to be provided and controlled. Transactional memory can be supported even from languages that do not directly expose transactional memory constructs. This is made possible by defining the object model in one or more base class libraries and allowing the language that does not support transactional memory directly to use transactional memory through the object model.

Abstract: A method of recording changes to a markup language file which employs application-defined tags. The changes are recorded in a delta file which is also a markup language file providing validation of the recorded changes against substantially the same markup language structure as that of the markup language file being changed. Where the original markup language file is an XML file with a DTD, a DTD can be created for the delta file which substantially follows the DTD of the original markup language file. Strict compliance of the data recorded in the delta file with the delta DTD provides validation of the changes with respect to the original XML file.

Abstract: A source code file management system includes a first receiving module, a generating module, a retrieving module, a determining module, a transmitting module, a second receiving module, a storing module and a message module. The first receiving module receives a source code file from a developer client associated with a developer. The generating module generates an intermediate file based on the source code file. The retrieving module retrieves a developer profile associated with the developer. The determining module determines examiners according to the developer profile. The transmitting module transmits the intermediate file to examiner clients associated with the examiners. The second receiving module receives examining results from the examiner clients. The storing module stores the source code file in a source code storage when each examining result is accepted.

Abstract: A method, apparatus and computer program product for providing recovery data for program code. A first version of an object code module is received. A second version of the object code module is received, the second version being a subsequent version to the first version. A unique identifier is inserted in the second version, wherein the unique identifier indicates a location of recovery data. First difference data representing a difference between the second version and the first version is calculated. The first difference data is stored as the recovery data. The first difference data is stored within the second version of the object code module at the location. The unique identifier indicates a location of the recovery data.

Abstract: Systems, methods and apparatus are provided through which an evolutionary system is managed and viewed as a software product line. In some embodiments, the core architecture is a relatively unchanging part of the system, and each version of the system is viewed as a product from the product line. Each software product is generated from the core architecture with some agent-based additions. The result may be a multi-agent system software product line.

Abstract: Techniques for efficiently isolating software regressions are provided. A system test tool determines that a particular regression is present in a particular build of a software system, but not in a baseline build. Using historical data, the tool determines, for each of a plurality of intermediate builds between these two builds, a likelihood that that intermediate build introduced the particular regression. A particular intermediate build can be identified as a build to be tested. Here, the particular intermediate build comprises a plurality of layered putbacks, each of which putbacks comprises one or more code changes in the software system. The tool determines, for each putback, a likelihood that that putback introduced the particular regression. A particular putback in the plurality of putbacks may be selected as a putback to be tested. In some embodiments, the particular putback is the putback that has the greatest likelihood of introducing the particular regression.

Abstract: Techniques are described for merging device schemas to manage different versions of network devices in the same device family. In one example, a computing device includes an interface to receive a first schema to be used for managing a first version of a device in a device family and a second, different schema to be used for managing a second version of the device, a computer-readable medium encoded with instructions for a schema merger module, and a processor to execute the schema merger module to merge the first schema and the second schema to produce a resulting merged schema to be used for managing both the first version of the device and the second version of the device, wherein the resulting merged schema expresses differences between the first schema and the second schema and includes a single instance of each common portion between the first schema and the second schema.

Abstract: Runtime execution of one or more tasks defined in a workflow process language. The method may include obtaining a description of the task from a process ontology (PO). The PO may define a hierarchical taxonomy of executable tasks, where each task refers to at least one frame of a hierarchical frame taxonomy of the PO. The method may further include identifying at least one parameter as described in the frame description to which the task refers, resolving the value of the at least one parameter, and executing the most specific applicable version of the task contained in the task taxonomy of the process ontology.