Cyclomatic complexity

Cyclomatic complexity

[Jos De Laender]

This is a multi-part message in MIME format.

--------------69525AF5E24
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Although I'm not sure if it is relevant, I first of all want to
mention that I'm active in development using VHDL. This is a
programming language with ADA roots, used especially in hardware
development. For it being a hardware description language, not too
many software principles are usually applied on it.

I read some stuff about measuring complexity using 'Mc Cabe's 
cyclomatic complexity measurement' in software. 
Although it seems quite nice on the level of one module, I have 
difficulties to understand how the stuff glues when putting together 
'modules' or 'subprograms'.

Suppose that I have :

A main program 'A' , with complexity 2 and integration complexity 2
A subprogram 'B' , with complexity 2 and integration complexity 2
A subprogram 'C' , with complexity 3 and integration complexity 2
A subprogram 'D' , with complexity 2 and integration complexity 1

'A' calls 'B' at one place and calls 'C' at two places. 
'B' and 'C' both call 'D' at one place.

How should I calculate the total complexity of the whole program ?

Does the number of calls of one particular subprogram by one 
particular subprogram influence the result ? How ?

Does the fact that a subprogram is separately verified or not influence
the result (Subprogram in a package or not) ? How ?

I would appreciate very much any clarification or pointer to such
a clarification. Hereby I put my hope especially on the ADA - guys ;-)

Kind regards.

--------------69525AF5E24
Content-Type: text/plain; charset=us-ascii; name=".@Signature.Posting"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename=".@Signature.Posting"


=== Expressed opinions are not necessarily those of Alcatel ===


     \\\|///      ir. Jos De Laender
     ( 0 0 )      Alcatel - SSD (Switching Systems Division)
   oo0-(_)-0oo    ASIC design - VA21                
  _\   ' `   /_
  \ \ALCATEL/ /   F. Wellesplein 1, B-2018 Antwerp, Belgium
   \ \     / /                                
    \ \   / /     E-mail          : mailto:jdla@sh.bel.alcatel.be
     \ \ / /                                                                 
     o0 Y 0o      Alcatel Bell    : http://www.bel.alcatel.be
       \|/        Alcatel Telecom : http://www.alcatelecom.be
        *         Phone           : (32)(0) 3 240 74 61
                  Fax             : (32)(0) 3 240 99 47

--------------69525AF5E24--

Re: Cyclomatic complexity

[Michael F Brenner]

Cyclomatic complexity has more to do with the program flow graph than
subroutine calling. Cyclomatic complexity has nothing to do with which
parts of a system have been verified. Strengths of cyclomatic complexity
are: (a) it is accepted by the government, (b) it is easy to measure,
and (c) it gives the illusion that you are predicting maintenance cost
which is perceived to be related to cyclomatic complexity. Weaknesses
of cyclomatic complexity are: (a) it becomes less and less corellated
to maintenance cost as the program improves in quality by converting
to static CASE statements or GOTO-less programing, (b) as soon as 
you admit that this is your measure the programmers will make trivial
modifications to the code which increase maintenance cost but reduce
the cyclomatic complexity, and (c) it encourages a mind-set that 
thinks of complexity primarilly as the difficulty of understanding
small pieces of code rather than things that are actually related
to maintenance cost like (i) prior maintenance billing, (ii) number
of references to global variables, (iii) number of states (or
statelessness), (iv) complexity of the data flow graph (rather than
the program flow graph), (v) use of nonstandard file formats or
message formats, (vi) use of APIs when a standard file format would
couple systems more loosely, (vii) number of service requests closed
before completion, (viii) automation of the configuration management 
and testing processes, (ix) ability of the analysis tools to 
instantly display the data flow diagram and the program flow diagram
for any portion of the system, and (x) existence of an on-line
method of tracking the correlation of all metics used to actual costs
incurred.

Measuring what is easy to measure (like lines of code and cyclomatic
complexity) does not necessarily lead to lower life-cycle costs. Measuring
what is actually corelated to thoses costs and acting on those
measurements will lead to lower life-cycle costs. In most organization
reducing the number of levels of managers and the number of references
to global variables, while increasing the speed of the computers used
for debugging and testing will reduce software maintenance costs faster
than reducing the cyclomatic complexity of the code. 

Re: Cyclomatic complexity

[ltroeger]

I have used cyclomatic complexity in different ways and found it useful. 
In a study on Space Shuttle code, I found a direct correlation between
modules whose cyclomatic complexity exceeded the threshold of 10 and the
number and severity of errors discovered in those modules.  I am now
using the McCabe toolset (which has other metrics and tools to compensate
for the weaknesses in cyclomatic complexity itself) to focus independent
verification and validation efforts on modules that have high cyclomatic
and essential complexity measures in embedded flight software code.  I
have found, again, that modules whose metrics exceed those thresholds are
much more prone to error.  I should qualify this by saying that the code
is written in C and is structured - I don't know how useful this would be
on object-oriented code, and, indeed, McCabe and Assoc. have a new set of
metrics and tools for object-oriented code.  Also, integration issues
such as global data problems, issues with tasking, and re-entrancy are
not well addressed by the tool, and certainly not by the cyclomatic
complexity measure itself.

There is a complete discussion of all this in the NIST publication 500-235
"Structured Testing: A Testing Methodology Using the Cyclomatic Complexity
Metric".  It can be found on the McCabe website at:

http://www.mccabe.com/nist

The integration question is addressed in here as well.

Lea Anne Troeger
Program Area Technical Lead
Automated/Robotic Spacecraft IV&V
Intermetrics, Inc.
ltroeger@intermetrics.com

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet