Tools

Tools

[Art Schwarz]

 
 
 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.
 
 The object of this excercise is to provide a basis for developing a testing
 methodology using Structured Testing (NBS 500-99 & NIST 500-235). In order
 to use the methodology correctly, the control-flow graph used to calculate
 the Cyclomatic Complexity of a subject module is needed. Unfortunately, 
 NBS 500-99 addresses topics associated with Fortran and NIST 500-235 does
 not provide a theoretical or pragmatic basis for developing software.
 There are enough linguistic (semantic and syntactic) differences between 
 Fortran and Ada as to make the transition from NBS 500-99 to Ada complex.
 
 art schwarz
 schwarza@gdls.com

 The opinions I hold are seldom held by my company. 
 

Re: Tools

[James Rogers]

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

Re: Tools

[Robert Dewar]

Jim Rogers says

"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.
"


I don't think this can possibly be true. Dynamic dispatching is semantically
equiavlent to a series of calls protected by conditoinals, and it would seem
that any methodology which could not handle:


   if a then call-b
   elsif b then call-c
   ...


is too limited to be useful.

Re: Tools

[James S. Rogers]

Robert Dewar wrote:

> I don't think this can possibly be true. Dynamic dispatching is semantically
> equiavlent to a series of calls protected by conditoinals, and it would seem
> that any methodology which could not handle:
> 
>    if a then call-b
>    elsif b then call-c
>    ...
> 
> is too limited to be useful.

Yes, dynamic dispatching is sematically equivalent to a series of calls protected
by conditionals, or even a case statement.  A set of conditionals or a case
statement is easily evaluated on the fly.  The required information is directly
available for static analysis.

Tagged types differ. They require a static analysis tool to build and maintain
a dispatch table for all types, keeping in mind scope and visibility rules for
each calling point.  Given that the current package may be influenced by a 
child package which is unreferenced in the current package, this appears to be a 
task which would not be reliably executed by a tool which was less than a full
Ada compiler front end.

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

Re: Tools

[Robert A Duff]

In article <32B6D316.2F1C@velveeta.apdev.cs.mci.com>,
James Rogers  <jrogers@velveeta.apdev.cs.mci.com> wrote:
>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.

Nor is there any static analysis which can tell you which branch of a
case statement will be executed.

- Bob

Re: Tools

[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