Newsgroups: comp.software.testing,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!gatech!agis!simtel!harbinger.cc.monash.edu.au!news.cs.su.oz.au!tmx!news.tmx.com.au!news
From: Philip Haynes <philip@oose.com.au>
Subject: Re: Metrics in Smalltalk / OO Languages
Message-ID: <D97u19.3ov@online.tmx.com.au>
Nntp-Posting-Host: 203.5.19.179
Sender: news@online.tmx.com.au (System Administrator)
Organization: The Message eXchange Pty Ltd
Date: Sat, 27 May 1995 02:39:09 GMT
References:  <3psahv$gln@isoit109.bbn.hp.com>
Lines: 79
Xref: glinda.oz.cs.cmu.edu comp.software.testing:4575 comp.lang.smalltalk:24031

> 1.) Has anybody experience with Space Profiling.
>     I want to collect information about the amount of memory allocated
>     by a class and its instances. This mechanism should work recursive.
>     That means it should register the whole amount of memory allocated
>     by an instance including all structures / instance variables.
Visual Age has a memory profiler, testing out data structures here would
be a useful start. 

> 2.) I want to calculate a kind of defect density for smalltalk code.
>     I'm not sure what could be the denominator for this number.
>     Shall I report errors per class, errors per statement, ...?
I have been some size analysis work in Smalltalk and it appears
that from this work that both effort and defects should be tracked
at the class level. 

> 3.) Branch coverage is another interesting topic.
>     How can I look for branch coverage when testing smalltalk code?
The size of a Smalltalk method, as measured by number of message
sends is approximately modelled by an exponential distribution. 
That is, most Smalltalk methods are very small. (As compared to procedural 
code. ) Consequently, the first instance we  have been using a
modified smalltalk profiler, to ensure all methods are
executed by our unit test suites. This is proving to be reasonably
effective.
We have, however, be tinkering with the idea of going further, but
have not sufficient justification to write the coverage tool.


> 4.) Can I make an issue about complexity of smalltalk code?
>     How could this be calculated?
I have been looking at complexity of Smalltalk at both the inter &
intra class level. Given the small size of methods, I believe 
method complexity is essentially irrelavent. 

At the interclass level I have identified that with increased class
coupling comes a non-linear increase in class size. Although in
a previous paper I said it was linear. That is, class coupling is a 
contributor to complexity. 

I am now looking at ways in which calling patterns in a Smalltalk 
hierachy can be modelled as the basis for understanding 
inter class complexity issues. The current approach is using 
ternary diagrams. I have coauthored a paper on this which is 
available from http://www.sd.monash.edu.au/~timm/ if you are 
interested.

It terms of intra class complexity, the idea I have been playing
with is to look at a class interms of a reliability model. By looking 
at the dependencies of different components of a class
it should be possible to calculate a figure for the probability
that the class will work. For example, say only one method writes to
an attribute, the chances that the attribute will always contain
the correct value are greater than the case where many methods 
write to that attribute. Conversely, if many methods read from a 
given attribute it is much more important that this attribute 
always contain a valid value.

However, I am only now begining to collect defect & effort data so
I have not been in the position where I can experimentally test out 
this idea. If you have such data, then I would be most interested
in sharing it.


Regards
PhilHaynes

-----------------------------------------------------------
        Philip Haynes              | 
        philip@oose.com.au         | "You cant control what you 
 ,-_|\  Object Oriented Pty Ltd    |  cant measure. If you think 
/     \ P.O. Box 528,              | the cost of measurment is high, 
\_,-._/ North Sydney               | consider the cost of being  
     v  NSW, Australia, 2059       | out of control."
        +61-2-957-1092 (ph)        | 	- Tom Demarco





