Site News  |   Monitor Keywords  |   Monitor Archive  |   Organizer  |   Account Info  |

Design rule system for verifying and enforcing design rules in software

Design rule system for verifying and enforcing design rules in software description/claims

In large software development projects, software designers write a design specification that they or other software developers may refer to when writing source code for the software that implements the designs. These design specifications sometimes contain design decisions, such as interactions between various objects. An object is a basic building block in object-oriented programming. The design decisions can be expressed as design rules that impose constraints on the structure or behavior of the software. The design rules are sometimes expressed informally, such as in source code comments, design documents, and so forth.

The software can change over time, such as when fixing bugs, adding features, and so forth. During these changes, the software may fail to comply with the design decisions because the software developers or designers may no longer refer to the original design specification. Moreover, the software designers may fail to update the design specifications as the software changes. These failures may lead to various defects in the software, such as incompatibility with other software, interaction problems between objects, and so forth. These defects may not be found until late in the software testing process or until the product has been shipped to customers. Defects detected at that point may be difficult or expensive to resolve.

Various techniques have been employed to express design rules formally and keep them updated. Some conventional design rules treat states associated with objects independently. As examples, these design rules may ensure that locks are acquired and then released in strict alternation; files are opened before reading and closed before exiting; memory is allocated before use and released before software termination; and so forth. Various tools exist to statically check source code for conformance with these practices. However, they conventionally do not enforce the rules at runtime (e.g., when the software executes) and relate to single objects (e.g., locks, file handles, memory, etc.). Other conventional design rules enable the expression of design rules involving multiple objects, but are unable to enforce the design rules automatically.

A software design rule system is provided. The software design rule system can employ a rule language that enables software developers to model valid interactions between multiple, inter-related objects; provide a rule verifier component that determines whether design rules achieve their intended purpose; and provide a rule enforcer component that determines whether the software complies with the specified rules. Software designers can provide design specifications using the rule language that the software design rule system employs. The rule language can specify a program that identifies “auxiliary states” associated with objects in the software that is being developed, transitions between the auxiliary states, and object invariants.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

FIG. 1 is a block diagram illustrating components associated with the software design rule system in various embodiments.

FIG. 2 is a block diagram illustrating components associated with the software design rule system and interactions between them in various embodiments.

FIG. 3 is a block diagram illustrating state transitions for an object in accordance with a protocol.

FIG. 4 is a block diagram illustrating two protocols.

FIG. 5 is a flow diagram illustrating a bind_rules routine invoked by the software design rule system in some embodiments.

FIG. 6 is a flow diagram illustrating an emit_logic routine invoked by the software design rule system in some embodiments.

FIG. 7 is a flow diagram illustrating a generate_verify_rules routine invoked by the software design rule system in some embodiments.

FIG. 8 is a flow diagram illustrating a generate_action_predicate routine invoked by the software design rule system in some embodiments.

FIG. 9 is a flow diagram illustrating a generate_constraints routine invoked by the software design rule system in some embodiments.

FIG. 10 is a flow diagram illustrating an enforce_rules routine invoked by the software design rule system in some embodiments.

FIG. 11 is a flow diagram illustrating an generate_aspect routine invoked by the software design rule system in some embodiments.

FIG. 12 is a combination flow and block diagram illustrating use of aspects in some embodiments.

• Provisional Patent
• Utility Patent

• What Is a Patent?
• What Is a Trademark or Servicemark?
• What Is a Copyright?
• Patent Laws