Path: utzoo!mnetor!uunet!littlei!ogcvax!pase From: pase@ogcvax.UUCP (Douglas M. Pase) Newsgroups: comp.software-eng Subject: Re: program complexity metrics Message-ID: <1518@ogcvax.UUCP> Date: 24 Dec 87 19:26:04 GMT References: <561@ndsuvax.UUCP> <3850002@wdl1.UUCP> <242@pedsga.UUCP> <2252@dasys1.UUCP> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 24 In article UH2@PSUVM.BITNET (Lee Sailer) writes: >The thru a module doesn't impress me at all. A very simple >module constructed from a sequence of big CASE or SWITCH statements will have >many paths, but is easy to understand. >How 'bout a measure based on the *hierarchy* of Data Flow Diagrams? As I see it there are two problems. The first is the complexity of the paths through a module. A number of metrics have been proposed elsewhere and mentioned in this forum (cycle count, independent path count, etc.). The second problem is the complexity of the conditions each path places on the data that passes through, a la Floyd/Hoare program verification. for example, simple arithmetic expressions replace old conditions with new. An example might be: x > 5 --> 'x := x + 1' --> x > 6. Other types of expressions may replace old conditions with new, or add new restrictions. 'if' expressions are bad news, 'while' and recursive expressions can be worse. But, not all 'if', 'while', or recursive expressions are equally bad, and it's not just the relative location of each in a program. Lest anyone think I'm saying something profound, all I have said is that if one wishes to measure the complexity of a program, one must consider the program itself (or equiv. its tranformations of the data it modifies) and not just the flow of data through it. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu.csnet