A list of desirable properties for software metrics appear in “Object-Oriented Metrics Measures of Complexity”, by Brian Henderson-Sellers, Prentice Hall Inc., 1996, chapter 8, the contents of which are herein incorporated by reference. These properties include the following:    1. It is objective and computable in a precise manner.    2. It is consistent, repeatable, and reliable.    3. It provides a useful feedback to allow the user to improve the design.    4. It is amenable to statistical analysis and capable of prediction.    5. It is easy to understand and easy to apply.
But neither the metrics of software complexity nor their collection approach have made significant progress. They have no theoretical bases, are design/implementation dependent, and/or cannot be automatically collected.
The internal process complexity of a software system increases with the number of processes, exceptions, and handlers within it.
Computer Aided Software Engineering (CASE) tools construct diagrams of uses cases to represent the internal process complexity of a software system. Use-cases are described in “Object Oriented Development Process and Metrics”, D. Champeaux, Prentice Hall Inc., 1996, chapter 3 (“Champeaux”), the contents of which are herein incorporated by reference. “Use cases embody a simple idea: describe the behavior of a system through examples . . . The notation of a use-case can be generalized from a prototypical interaction sequence to a tree-like format, that covers all possible branches of choices by the use/context and/or by the intended system logic.” Champeaux, page 86. A use-case is a piece of functionality in the system that gives a user a result of value. See e.g. Champeaux.
One of the most common documents for software developed with use-case is the scenario diagram. A software system is composed of subsystems; a scenario diagram either describes the interactions between systems and subsystems or the interactions between the internal objects/classes in the subsystems.
FIG. 1 illustrates the system structure and intra-subsystem message interaction diagram where                Si is a subsystem i;        EIj is an external interaction from/to the external business world;        IIk is the internal invocation between the two subsystems.        
FIG. 2 shows the internal object/class interactions for a subsystem Si where                EIj and IIk are the same as in FIG. 1, and        Mi is an object/class method call.        
Correct, complete, and well-maintained scenario diagrams directly represent system complexity. They represent complications of the system internal logical process, of interfaces between subsystems, and of the interfaces between subsystems and external systems.
Object/class interaction diagrams should present all branches of use-cases. But diagrams generated by current CASE tools do not clearly identify conditional branches. In particular, diagrams generated by current CASE tools fail to show the branches for exception cases and do not clearly present the whole picture of the use-case set or the whole project.
Further, existing CASE tools cannot print all possible state transition paths for a State Transition Diagram and cannot establish the dynamic relations among the states of different levels. Accordingly, there exists a need for a software complexity metric that represents exceptions in addition to normal process scenarios.
USPTO Backgrounds
USPTO Backgrounds