5.2 McCABE METRICS

 < Day Day Up > 



5.2 McCABE METRICS

The first of the techniques I would like to discuss is the use of McCabe Metrics. McCabe measures are among the more established Software Metrics in use today and they do seem to be going through a revival after a somewhat troublesome time when numerous individuals criticized their effectiveness. I was also among the doubters until I had the good fortune, some years ago, to hear their originator, Tom McCabe, present a paper at a conference. This taught me two lessons. One, any Software Metric will be criticized, not least because so many people are looking for the silver bullet, the one metric to solve all our problems and, frankly, this will not be seen during our lifetime. Many of the criticisms of McCabe metrics stemmed from them being put to uses for which they were never intended. Two, if you want to learn about something then, if possible, go to the source.

That presentation coupled with the opportunity to talk to some individuals who were making use of McCabe metrics in the way that was intended induced me to try them. I can honestly report that the results I have had with their application convinces me that they are a very powerful tool.

So, what are McCabe metrics? There are two principle measures commonly known as McCabe Metrics, Cyclomatic Complexity and Essential Complexity, both founded upon graph theory. I am going to concentrate on describing Cyclomatic Complexity because Essential Complexity, as you will see, is very similar in its application.

Now this is going to get a bit, well, complex, but bear with me because the basic concepts are very simple to use, McCabe metrics are applied against "flowgraphs" which are simplified flowcharts, all "boxes" being represented as simple, unmarked nodes. Now I am tempted to leave it there but for a recent salutary experience when a young engineer told me that he had never been taught how to use flowcharts, "after all, they went out with the ark!" So for those young enough never to have had the pleasure of flowcharting, and anyone who has forgotten the basic principles let me try to explain what a flowgraph is in more technical terms.

If you look at Figure 5.1 you will see a fragment of code that contains an example of sequence, selection and iteration. By representing each statement as a simple bubble or node and each control flow between statements as a connecting line or edge we can present that code fragment as a flowgraph, simply a collection of nodes and edges. For the code fragment in Figure 5.1 an associated flowgraph is shown.

click to expand
Figure 5.1: McCabe Metrics Background Theory Example of Flowgraph (1)

Now a flowgraph can be constructed for any code fragment that can be seen to have a single entry and exit point. Generally speaking, McCabe metrics are applied to low level system components such as COBOL paragraphs, or sections, C functions etc.

Flowgraphs can also be derived from most psuedo-English design notations so that you do not have to wait for code before using these techniques. Even so, McCabe metrics do come into play relatively late in the development lifecycle but consider, how late is too late? Even if I was at the point of producing code, it is still cheaper for me to make changes rather than produce and deliver system components that are prone to defects, and maintenance problems. Equally important, by using McCabe metrics I can identify potential hot spots in my system and advise the test people that these should be even more rigorously tested than the rest of the system surely will be.

Having got the flowgraph, count the number of edges, e, and the number of nodes, n, then simply apply the formula below to calculate the McCabe Cyclomatic Complexity value, v:

v = e - n + 2

A simple example is provided in Figure 5.2 to illustrate the use of this formula.

click to expand
Figure 5.2: McCabe Metrics Background Theory Example of Flowgraph (2)

There are other ways to calculate the value v. Perhaps the most useful is, given code or a good pseudo-English approximation, to count the number of IF statements and add 1, remembering to treat compound conditions as multiple IFs. This basic algorithm can be used to produce a very simple automated tool that will calculate the value v once it has code to work on.

McCabe's Cyclomatic metric is a measure of how complex a specific realization of a design is. Basically, if my code or low-level design is seen as a black box that exists to do something, how complex have I made the innards of that black box?

Essential Complexity is a much more simple concept to explain in that it is a measure of "structuredness." If you look at a piece of code, or the low level pseudo-English that is one step away from code, you will find standard constructs within it. These are sequence, selection and iteration constructs. If you look at the flowgraph representation you will find that you can reduce it to the essential flowgraph by replacing these constructs by single nodes.

When you cannot do this because the basic rules of sequencing, selection and iteration have been broken the degree of structuredness is reduced.

Figures 5.3 and 5.4 show the reduction for a flowgraph that is well structured and for one that contains illegal constructs.

click to expand
Figure 5.3: McCabe MetricsBackground Theory Example of Reduced Flowgraph (1)

click to expand
Figure 5.4: McCabe Metrics Background Theory — Example of Reduced Flowgraph (2)

Calculating Essential Complexity is simply a case of applying the same formula to that used for Cyclomatic Complexity but with counts taken from the reduced flowgraph, thus:

vr = er - nr + 2

where vr is Essential Complexity and er and nr are the edge and node counts from the reduced flowgraph.

But, of course, all we have so far are some numbers. What do they mean and how do we use them?

Let me start to answer that question by putting forward some very concrete guidelines and I will then discuss a slightly less pedantic approach.

The rules are quite straightforward. If you are working on a new development or an enhancement project that is adding functionality then, for any single low level component, the value for v, Cyclomatic Complexity, should not exceed 10 and the value for vr, Essential Complexity, should not exceed 2.

One project I know of in the United States that applied these rules did achieve zero defects for at least twelve months after delivery. Think about that. The system was being used as well!

Now let us talk about the reality. Most of us do not have the pleasure of working on new developments, and any additional functionality that we get to add to systems as part of an enhancement project tends to be swamped by straight changes to existing stuff. Also, if we are managing a system we may feel it to be slightly over the top to suddenly insist that everyone start bringing things in line with the ten/two rule (i.e,. that Cyclomatic Complexity, should not exceed 10 and the value for vr, Essential Complexity, should not exceed 2).

In a maintenance environment a good guideline is to do a McCabe analysis before you do a change and to then do another one after you have designed the changes. If the values for v and vr are the same or a little bit better than you found them, then implement the change. If they are worse, then go back and do it over — because otherwise you are storing up trouble for the future.

If you are in the situation of developing new systems or adding low-level components then, in all honesty, you could do a lot worse than to apply the ten/two rule. In a maintenance environment this may be a bit much for your people if they have not come across these ideas before. In this situation you could do an analysis of the system you are responsible for, either by analyzing the whole system through a tool that uses code as its source or by sampling components from the system. You may be surprised, or even shocked, to find components with Cyclomatic values of five hundred plus, yes I know the guideline was ten but that is not a mistype, I really do mean 500+! I regularly see components with values like this. I have even been told about one component with a value of 2,800! Believe it and weep.

Now we do have to take a deep breath here for two reasons, one being the fact that there are modules around like that, and we wonder why we have problems in this industry! Second, what you must realize is that there is one very easy way to bump up the Cyclomatic Complexity value of a component without destroying its reliability or maintainability. How? Use a CASE statement or its equivalent that implements a multiple "if" construct. Which is where I have a fundamental difference with some individuals in our industry. CASE statements are fine and have a role to play in designs and coding, however, there is a limit that, when reached, makes a CASE-heavy component as unmaintainable as a module that does the same thing through multiple IFs.

It may upset the fundamentalist structured programmer but if I am presented with a design that goes over a Cyclomatic value of 50, and the excuse given is that a CASE statement has been used, somebody had better find cover very quickly! Complex CASE statements are difficult to understand. I make this statement as an ex-maintenance programmer who regularly had to attempt to decipher CASE statements that went to twenty or thirty lines and that were not easy to comprehend.

Enough of the problems, what can be done about them?

If you wish to introduce the use of McCabe metrics you could use a sampling exercise like that I have outlined to set short-term targets. For example, looking at our current system the average McCabe values are 25 and 5 for Cyclomatic and Essential Complexity respectively. From now on, the rule will be that no design solution gets through a review (and if you are sensible you will say it does not even go for review), unless it makes the McCabe values better than they were before, or, if new functionality, has values of 20 and 4. Given the environment you have these targets are reasonable and you can always reassess the situation in six months time and make the targets tighter.

Effectively, I suggest that McCabe metrics be used as control gates. The actual values you use for those gates are less important than the fact that you are asking engineers to think about the results of their actions.

But do such approaches work? Are McCabe metrics worth anything? I have already mentioned the experience of one organization that got zero defects when it piloted these techniques. I can also tell you that Hewlett Packard has published data that shows a 0.9 correlation between Cyclomatic Complexity and defect reports across a large number of applications. That is pretty impressive no matter what reservations you have about correlation statistics.

The best example I have come across to support the use of McCabe metrics is somewhat back-to-front. A while ago I was asked to pilot Complexity metrics in an organization as part of a quality improvement program. I was given a particular application and team to work with and initial discussions indicated that McCabe metrics would be the best approach. I asked what the current quality levels were in terms of defects only to be told that this application did not have defects, at least so few that it was almost zero. Needless to say I asked for proof and this was not available. Being something of a cynic I suggested that we put in a defect reporting mechanism on the current project, a fairly straightforward five thousand line enhancement job.

This was done and I returned expecting to find a good few defect reports awaiting me from the link tests and from the user acceptance or system tests. There were three defect reports. Two of these were due to data and could not be blamed on the programming team. This meant I had a system that appeared to be exhibiting a reliability level better than 0.001 defects per thousand lines of code changed. Bear in mind that the best norms we have to work with suggest 4 defects per thousand lines for US and European software.

Why was this? Well the team was not large, consisting of three individuals. Those individuals were quality staff to their toenails. As the team leader said, those three defects should not have got through, and she meant it! They had a very close and good relationship with their user. Obviously it all helped but the thing that really battened it down was that most of their system components conformed to the ten/two rule. They were applying McCabe concepts automatically and they were getting the results.

Incidentally, this team had one individual who manually analyzed all the components associated with that 5K project and it took him three days. I would not recommend that McCabe analysis is regularly carried out by hand but it shows that it can be done.

Of course everything is not perfect, even with these metrics. There can be problems with recursion, that is when sections of code call themselves, and with fall-through, where one component passes control down to another and so on so that there is no single entry/exit point. However, most managers steer clear of recursion, wisely I believe, and fall-through is fortunately quite rare so I tend to ignore these concerns.

More important are the people worries that sometime arise. Some managers are very concerned about the use of such metrics because they see that use adding to development time. In my mind the results speak clearly in favor of their use but it should be remembered that a McCabe analysis, when done as part and parcel of the day-to-day work, adds about five or ten minutes to a component change that typically takes a minimum of an engineering day when you allow for familiarization, re-documentation and all the rest of what makes up IT.

McCabe metrics do also seem to open some other interesting doors.

There are a number of tools around that support McCabe metrics. These are easily found through the web. Some of these tools also enable the automatic production of unit test cases. This can offer a significant saving on testing effort.

Even more interesting are some of the reports that came out of the United States some time ago. It seems that some people have been using McCabe metrics and the automatic generation of test cases to identify redundant code within systems. By redundant code we simply mean modules that do the same job as other modules in the same system. For example, you may need a sort routine and so may I. Assuming you write yours for release 1 is it very likely that I will check things out before writing my own for release 2 or 3? The answer seems to be, 'no, I will write my own.' For further information about this experimental technique see McCabe (1) .

Based on the work done so far, it seems that we could expect systems to exhibit about a 30% level of redundancy. That is an awful lot of code to be there when it does not need to be!

To summarize, McCabe metrics are a well established, well proven foundation for techniques to manage complexity and, hence, reliability and maintainability. Like them or not, many people have found that they work.



 < Day Day Up > 



Software Metrics. Best Practices for Successful It Management
Software Metrics: Best Practices for Successful IT Management
ISBN: 1931332266
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Paul Goodman

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net