Re: Tools

[schwarza@gdls.com (Art Schwarz)]

From James Rogers <jrogers@velveeta.apdev.cs.mci.com>
Newsgroups: comp.lang.ada
Subject: Re: Tools
Date: Tue Dec 17 12:06:30 EST 1996
Organization: MCI Telecommunications Colorado Springs, CO

Art Schwarz wrote: 
>  I'm interested in reading articles which describe what the complexity metric
>  for Ada is; what constructs are used and supported. the weight each has and
>  how the construct participates in control flow graph formation. I am also
>  interested in any freeware, shareware, commercialware which supports the return
>  of the complexity metric of a module along with the control-flow graph used to
>  form the complexity metric.

I assume this means that you will not be using any tagged types.  Run-time
dispatching makes Cyclomatic Complexity calculations very difficult.  There
is no static analysis which can tell which subprogram will be called via
dynamic dispatching.

-- 
Jim Rogers
*************************************************************
Team Ada


   Actually I don't know what I'm looking for. Putting a context on this,
   I'm including (below) a response to a posting in comp.lang.measurement.
   The issue is that one of the projects at General Dynamics Land Systems
   is being required to use the Cyclomatic Complexity Metric and the 
   Essential Complexity Metric (1, 2, 3) in an Ada project. My contention
   is that the referenced documentation does not provide any guidelines to:

   [1] Evaluating competing products, and

   [2] Constructing a product,

   because major issues within Ad 83 and Ada 95 are not addressed. I have
   identified (internally) the use of entry / tasking and exceptions as
   being two of those issues. You have identified yet another (thanks by
   the way). My basic problem is that in order to determine what we have
   to do, I have to determine what we have to do. Hence, I am looking for
   both products (freeware, shareware, commercialware) and literature. In
   order evaluate any product, I have to become familiar with the issues.
   And so, I am eager to hear opinions as well as to see articles. 

   As time is available, I will reformulate the Cyclomatic Complexity Metric
   to accomodate those issues not currently published or satisfied which I
   become aware of. (Don't count on this - they keep us underfed and
   overworked around here.)
  
   If anyone within the Ada or non-Ada community would like to share
   experiences or thoughts, I will provide a synopsis. Because of firewall
   restriction, I will probably have to direct mail the results to all
   interested parties. (Darn.) 

   [1] A Complexity Metric
       Tom McCabe
       IEEE Transactions on Software Engineering, Dec 1976

   [2] Structured Testing: A Testing Methodology Using the Cyclomatic
       Complexity Metric
       Thomas J. McCabe
       NBS 500-99

   [3] Structured Tesging: A Testing Methodology Using the Cyclomatic
       Complexity Metric
       Arthur H. Watson, Thomas J. McCabe
       NIST 500-235
       (http://www.mccabe.com)

======================================================================

From schwarza@gdls.com (Art Schwarz)
Newsgroups: comp.software-eng,comp.software.measurement
Subject: Re: Cyclomatic Complexity Metric
Date: Wed Dec 18 16:35:36 EST 1996
Organization: General Dynamics, Land Systems Div

> From John Sheckler <sheckler@software.org>
> Newsgroups: comp.software-eng,comp.software.measurement

> Cyclometric Complexity is language independent.  It is quite simple to 
> implement, all you do is count each program branch instruction (if, else, 
> case, switch, for, jump, branch on less than, etc.  A general and 

   This is not quite accurate in that some valid language constructs in, 
   e.g., C/C++ and Ada can not be appropriately mapped. I list as a 
   partial subset:

   [1] C/C++ throw and catch
   [2] Ada raise and exceptions.
   [3] Ada entry and tasking.

   In all these forms it is possible to generate a Directed Acyclic Graph
   (DAG) which is not strongly connected. As identified in McCabe's paper
   in the IEEE Transactions on Software Engineering, Dec. 1976, "A 
   Complexity Metric", the metric depends on the control flow graph being
   strongly connected. A book by Berge, "Graphs and Hypergraphs" is cited
   as being the reference.

   A direct implication of the reasoning behind the Cyclomatic Complexity
   Metric is that the original program be well-structured (see below). This
   property causes programs which use, e.g., continue (C), or break (C, Ada)
   which produce a control-flow graph which can be strongly connected, to
   represent complexity issues which are present but may not be relevant.



> somewhat serious complaint is that CASE (SWITCH) statements generate unfair 
> high complexity values, but then any numeric approach to evaluating programs 
> requires some judgment.

   McCabe identifies a further metric, which he calls the "essential complexity"
   which measures the well-structuredness of a program, that can be used to
   accomodate 'case' statements. The approach is to discard subgraphs which 
   are identified as being well-structured. The resultant Cyclomatic Complexity
   is an indication of how well-structured the original program was. For programs
   which are well-structured, the essential complexity metric == '1'. Counts larger
   than '1' indicate the degree, according to this metric, that a program is not
   well-structured. As above, issues exist in certain language constructs.

   Basically, the fundamental paper in '76 deals with popular languages which
   existed at that time. This was identified in NIST 500-99, "Structured 
   Testing: A Testing Methodoloy Using the Cyclomatic Complexity Metric" as
   being Fortran and Pascal with a little Cobol.


> The last I heard, is that there is a lot of software out there for generating 
> these kinds of metrics.  One source that I have had expereince with was 
> PC-Metics of SET Laboratories in Washington or Oregon out west somewhere. 
> Another prodcut called Logiscope is also well rated.  I took a course at JHU 
> that required me to write a source code metrics analysis tool, but I don't 
> consider my program a marketable commodity.  Of course McCabe is the one 
> credited for inventing the concept so I would look to his offerings first.

  
   Any software at all, or references to software, will and shall be well
   received.

   Thanks for the help. I hope that I haven't bored you with my concerns.

art schwarz
General Dynamics Land Systems
schwarza@gdls.com