Patent application number | Description | Published |
20080306617 | CORE OBJECT-ORIENTED TYPE SYSTEM FOR SEMI-STRUCTURED DATA - A type system employing structural subtyping is disclosed herein. A core type system supports several structural types, such as stream, choice, intersection and sequence. Also part of the core type system is a new invariant type, which denotes values whose dynamic type is the same as its static type, and type restrictions for limiting a range of a base type. Furthermore, a streamlined structural version of delegates, called structural delegates and a validation method thereof are introduce into the type system. To further facilitate type safety, strict statically checked interface casts are introduced. | 12-11-2008 |
20080307264 | PARAMETERIZED TEST DRIVEN DEVELOPMENT - In one embodiment a computer system automatically generates unit tests. The computer system accesses a parameterized unit test that provides a base outline from which one or more unit tests are automatically generated, generates input parameter values for a unit of software code, automatically generates a unit test configured to assess the functionality of the unit of software code, and receives test results from a software testing program and provides feedback to a user. In other embodiments, a computer system automatically maintains a unit test database. The computer system receives a unit test at a unit test database, assigns a test identity to the received unit test, determines that the test identity assigned to the received unit test is unique when compared to other unit tests, determines that the received unit test has different functionality coverage characteristics, and adds the received unit test to the unit test database. | 12-11-2008 |
20080313602 | BOUNDED PROGRAM FAILURE ANALYSIS AND CORRECTION - In one embodiment, a computer system determines that a previously run test scenario configured to test a software program has failed to produce an expected result due to one or more semantic errors, generates error trace code configured to monitor the called component, processes the test scenario using the error trace code, and analyzes error trace information to determine the point at which the semantic error occurs in the called component. In an alternative embodiment, a computer system detects a semantic error in a software component of a software program, constructs an error condition that may include source code representing a minimum condition under which the error occurs, generates an object invariant based on the error condition that represents an opposite condition to that represented by the error condition, and automatically generates source code change recommendations using the object invariant that prevent the semantic error from reoccurring in subsequent test scenarios. | 12-18-2008 |
20080313609 | CORE OBJECT-ORIENTED TYPE SYSTEM FOR SEMI-STRUCTURED DATA - A type system employing structural subtyping is disclosed herein. A core type system supports several structural types, such as stream, choice, intersection and sequence. Also part of the core type system is a new invariant type, which denotes values whose dynamic type is the same as its static type, and type restrictions for limiting a range of a base type. Furthermore, a streamlined structural version of delegates, called structural delegates and a validation method thereof are introduce into the type system. To further facilitate type safety, strict statically checked interface casts are introduced. | 12-18-2008 |
20090043560 | FEATURE ORIENTED PROTOCOL MODELING - Modeling protocols. A method includes accessing a number of model programs. Each model program includes computer-executable instructions. The computer-executable instructions describe the behavior of at least one of another program, system, or component. Model programs may be disjointed in that they have independent meaning or dependent in that they include at least one of a state variable, action, or precondition that is dependent on another model program to impart meaning to the model program. An output model program is composed by unification including substituting state variables into another of the model programs without executing the model programs. Traces are generated from the output model program. Each of the traces includes a path of labels. The labels describe actions of the output model program from an initial state to an accepting state where a run is allowed to stop. The traces are output to a user. | 02-12-2009 |
20090164973 | CONTRACT PROGRAMMING FOR CODE ERROR REDUCTION - In one embodiment, a computer system provides an application programming interface (API) for augmenting an application API. A computer system receives software code written in a second programming language indicating a user's intention to augment an application API with contracts from a contract API written in a first programming language. The software code includes a reference to the contract API. The contracts include assertions indicating appropriate use of the application API. The computer system accesses portions of the contract API according to the reference in the software code and compiles the received software code and the referenced portions of the contract API into an intermediate language (IL) version of the software code. The IL version is in an intermediate language common to both the first programming language and the second programming language. The IL version includes the assertions indicating appropriate use of the application API. | 06-25-2009 |
20100011194 | STATE AS A FIRST-CLASS CITIZEN OF AN IMPERATIVE LANGUAGE - A state component saves a present state of a program or model. This state component can be invoked by the program or model itself, thereby making state a first-class citizen. As the state of the program evolves from the saved state, the saved state remains for reflection and recall, for example, for testing, verification, transaction processing, etc. Using a state reference token, the saved state of the program or model can be accessed by the program or model. For example, the program or model by utilizing a state component, can return itself to the saved state. After returning to the saved state, a second execution path can be introduced without requiring re-execution of the actions leading to the saved state. In another example, the state space of an executing model is saved in order to generate inputs required to exercise a program or model. | 01-14-2010 |
20100082802 | Stabilization of distributed systems - One or more embodiments, described herein, are directed towards a technology for analyzing a distributed system in order to determine one or more inconsistencies placing the distributed system in an unstable state. Once the one or more inconsistencies are determined, one or more operations reconciling the inconsistencies are defined in order to stabilize the distributed system. | 04-01-2010 |
20100269110 | EXECUTING TASKS THROUGH MULTIPLE PROCESSORS CONSISTENTLY WITH DYNAMIC ASSIGNMENTS - A developer can declare one or more tasks as being replicable. A library manages all tasks that are accessed by an application, including replicable tasks, and further establishes a task manager during requested task execution. During execution, the library generates a plurality of worker threads, and each of the worker threads is assigned to be processed on one of a plurality of different central processing units. When one or more worker threads have finished processing assigned tasks, and other threads are still busy processing other tasks, the one or more idle worker thread scan copy over and process replicable tasks assigned to the other, busier worker thread(s) to help with processing. The system can also synchronize processing of the replicable task by the plurality of different worker threads and different processors to ensure no processing discrepancies. | 10-21-2010 |
20110083124 | Software Verification Using Two-State Invariants - Software verification using two-state invariants is described. In an embodiment a verifier represents an annotated program to be verified as a plurality of atomic transitions between global program states, each state comprising a plurality of objects. For example, the verifier accesses the annotations which specify a two-state invariant for each object. A two-state invariant is a predicate that relates a global program state before a state transition to the state after that state transition. In an example some of the two-state invariants are cross-object in that they refer to other objects. For example, a verification system checks that only the two-state invariants of the objects which changed in each transition are preserved; this modularity enables the verifier to work for large code bases and concurrent software. In an example the modularity is possible since the two-state invariants meet an admissibility requirement which is independent of the functionality of the program. | 04-07-2011 |
20110265067 | Automatic Parallelization in a Tracing Just-in-Time Compiler System - A tracing just-in-time (TJIT) compiler system is described for performing parallelization of code in a runtime phase in the execution of code. Upon detecting a hot loop during the execution of the code, the compiler system extracts trace information from sequentially recorded traces. In a first phase, the compiler system uses the trace information to identify at least one group of operation components that can be operated on in a parallel manner. In a second phase, the compiler system provides instructions which allocate the group of operation components to plural processing resources. A native code generator module carries out those instructions by recompiling native code that directs the operation of a native system to perform parallel processing. The compiler system terminates a group if it encounters program data in a loop iteration that is not consistent with previously encountered predicated information (upon which it records a new trace in a sequential manner). | 10-27-2011 |
20110302550 | Providing Diverse Solutions Using Design Space Exploration - A design space exploration (DSE) system automatically discovers viable solutions within a design space. The DSE system operates by creating or receiving a design specification that is described using a design language. The design specification contains a collection of constraints that an acceptable architecture is expected to satisfy. The DSE system then symbolically executes the design specification to provide a logical formula. The DSE system then interacts with a theorem prover module to identify one or more solutions to the formula. Finally, the DSE system converts the solutions into a user-interpretable form (e.g., expressed in the format of the modeling language) for viewing by a user. Each solution pertains to an architecture that satisfies the collection of constraints. The DSE system ensures that the solutions are diverse by disfavoring any solution that is deemed similar to any solution that has been previously encountered. | 12-08-2011 |