From: kalakota@ccwf.cc.utexas.edu
Newsgroups: comp.object,comp.software-eng,comp.lang.c++,comp.lang.objective-c
Subject: SUMMARY: complexity in O-O
Date: 9 Apr 92 05:34:59 GMT
Reply-To: kalakota@ccwf.cc.utexas.edu ()
Followup-To: comp.object
Organization: The University of Texas at Austin, Austin TX
Originator: kalakota@doc.cc.utexas.edu


               Complexity in Object-Oriented Environments
               ------------------------------------------

There has been very few replies to my query on complexity in O-O. I have 
been reading Dr. Horst Zuse's excellent book on "Software Complexity", in 
order to understand this area. The respondents wrote that the number of
lines of code actually increased in an O-O environment. This is contrary to
what I expected. I thought that the number of lines at the class or object
level would be more than say implementing the same functionality in a
procedural language, but the overall size of the application would actually
decrease due to reuse. Maybe someone would like to comment on this. 

---------------------------------------------------------------------------
What is Software Complexity?

Software Complexity is difficulty to maintain, change and understand programs.
It deals with the psychological complexity of programs.


What are best known complexity measures?

Some of the best known complexity measures are Measure of McCabe (Cyclomatic number), Lines of Code (LOC) and the Measures of Halstead (Length, Volume, Difficulty and Effort).


What are the several categories of complexity? [Ejiogu 85]

There are several categories of software complexity. Five of them are:

Structural Complexity: Has to do with the natural expression of the topological relationships of a system's components. Structural complexity is more than just the effects of the control paths. It is a global attribute.

Computational complexity: Concerns the relative difficulty in accomplishing
arithmetical/logical computations of an algorithm on data. This complexity 
is an attribute of the algorithm.

Logical complexity: Has to do with the relative difficulty of logical 
decisions or flows and branches within a system.

Conceptual complexity: Has to do with the psychological perception or the 
relative difficulty of undertaking or completing a system; it may also include
the diversity of human and material resources.

Textual complexity: has to do with the static analysis of program source 
texts. This condition influences reliability.

References:
[Ejiogu 85]  Ejiogu, Lem "A Simple Measure of Software Complexity", Computer
World, April 1984.
[Zuse 91] Zuse, Horst "Software Complexity, Measures and Methods", 1991.
----------------------------------------------------------------------------

Which does type of complexity does O-O affect most? As Ralph Johnson pointed
out, most of the complexity is inherent in the problem being solved, but O-O
can provide a way of managing complexity. Clarifications about this would be
appreciated as the more I read the more confused I get.              

send follow-ups to : comp.object or comp.software-eng.

-- Ravi

--------------------------------------------------------------------------
Ravi Kalakota                          kalakota@emx.utexas.edu
Center for Information Systems Management
University of Texas at Austin
--------------------------------------------------------------------------

From pogo.den.mmc.com!noren@cs.utexas.edu Wed Apr  1 10:17:27 1992
Date: Wed, 1 Apr 92 08:56:24 -0700
From: Chuck Noren <noren@pogo.den.mmc.com>

In article <69519@ut-emx.uucp> you write:

We find that OO does not reduce complexity, in fact our complexity
increases dramatically.  However, OO effectively manages complexity
via abstraction and encapsulation so that the design looks simple,
even through the components are complex and are built on top of other
"black-box" complex components.

-- 
Chuck Noren
noren@inlatlas.den.mmc.com     noren@pogo.den.mmc.com
Martin Marieta, Mail Stop XL8058, P.O. Box 179, Denver, CO 80201 
(303)977-1646

From: danny@taurus.bitnet
Comments: If you have trouble reaching this host as math.tau.ac.il
        Please use the old address: user@taurus.bitnet
Reply-To: <danny@math.tau.ac.il>
Date: Thu, 2 Apr 92 09:23:05+030
From: danny@taurus.bitnet
Status: R

In article <69519@ut-emx.uucp> you write:
>
>Going one step further, I would like to introduce a variable into the
>implication:
>
>   Good Design     ===>  Reduces Complexity  ===>  Better Maintainability.
     Well, I would not say that "Complexity" is the  correct
variable to insert into the implication. A better one, IMHO,
is something close to "Readability".

     What I mean to say is, that  complex  programs  can  be
easy  to  maintain,  provided  that the complexity is stated
well, the code is easy to  penetrate  into,  the  model  and
functionality are clearly displayed etc.

     In this respect, O-O-D&P help a lot. My experience with
C++  shows  that  complex  models  are  readily designed and
implemented, still yielding relatively clear  and  maintain-
able code.

>
>Most literature says that O-O is less complex since the code size
>is reduced. This was true in the functional paradigm where complexity was
>proportional to code size? Does this hold in the O-O paradigm?
>Inheritance is an excellent structuring method to reduce complexity but only
>if used well.
     My experience is, as it  turns  out,  contrary  to  the
literature,  in  the  sense  that O-O code is usually bigger
than functional code. One of the prices we  pay  for  parti-
tioning  into  classes  and using inheritance extensively is
enlarged code.

     Still, this does not affect complexity, or  readability
for  that  matter.  On  the  contrary, large code made up of
small pieces designed to handle one  aspect  of  one  object
each  is fine.  Heck, we've got good editors and other tools
to help us find our way thru the code -- size in  itself  is
meaningless.

>
>One last query: If you measure the complexity of a system designed using
>O-O-O versus the same system designed using functional decomposition
>(Good old COBOL) What will be the difference in complexity?
>(assume same metric for both)
     I don't know about metrics, but my intuition says, that
if designed well, the same complexity shoulkd be achieved in
both ways (it  is  rather  inherent  to  the  problem  being
solved),  but  O-O code would be clearer and thus more main-
tainable.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Danny Khen      danny@math.tau.ac.il    |       Phone:  +972-3-720783
                danny@taurus.bitnet     |       Fax:  ** for future use **
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

From noren@pogo.den.mmc.com Thu Apr  2 16:59:35 1992
> 

I don't have a good definition of complexity.  All I can say is that
our lines of code have increased, mostly because we have a more
comprehensive system than the one we implemented before.  Our data
model before consisted of a variety of relational tables with simple
primative data types.  Now our data model resides in an OODBMS and is
very complex.  Its part-of hierarchy are trees within trees, but all of
this is encapsulated away into "black-box" classes.  They take care of
their own memory management, notification of other objects upon update,
they can send themselves from one UNIX process to another via IPC.
Because of their layering, we hide thier implementation thru C++
enforcement mechanisms and give them the feel of primative objects.

I'm afraid this is not a very good answer.  I'd like to spend more time
on this but I'm in an integration crunch right now -- where I'm the
critical person holding up the rest of the project.




From: igor!ctbu!rmartin@uunet.UU.NET (Bob Martin)

In comp.lang.c++ you write:



One of the interesting things about OOD is the number of metrics that
can be generated.  OOD is full of relationships between classes.
These relationships can be counted and turned into a per-class metric.
For example, we can count all the inheritance, using and containing
relationships that one class has with others, and call this metric the
"coupling" of the class.  We can also count all the classes that
inherit from, use or contain our class, and call that number the
"usablilty" of the class.  Clearly and design technique would want to
minimize coupling and maximize usability.

If we draw boundaries around cohesive groups of classes (Booch calls
such groupings "Class Categories"), then we can count the number of
classes within the category which are used outside the category.  This
number is the "coupling" of the category.  We want to minimize
coupling.  The cohesion of a class category is the count of
relationships between classes within that category.  If this number is
high, then the category is highly cohesive.  We want to maximize
cohesion relative to coupling.  Finally comes the metric that I call
"health".  It pertains to a category.  The health of a category is the
ration of cohesion to coupling.  We want to maximize "health" by
keeping cohesion high and coupling low.  Such a category can be
inferred to have a high functionality, and a low dependence on the
rest of the design.

It is sometimes useful to divide the coupling and cohesion numbers by
the number of classes in the category.  This gives us normalized
cohesion and coupling which can be compared with the normalized
cohesion and coupling of other classes.

---------------------------------

Code size and source line count are abysmal methods for measuring
complexity.  They are far too dependent on the vagaries of the
implementation method and development environment.

--------------------------------

The problem with comparing the complexity of applications generated
with OOD aginst the complexity of applications generated with SD, is
that they have very little common ground.  You can't use object code
size, in part because of the incredible differences between compilers.
You can't use source line count because there is no good way to
measure the semantic content of the source lines.

One interesting measures would be the ratio of source lines to
functions/methods.  Another might be to measure the ratio of the
number of data structures (structs, classes, etc) to the number of
functions.

I would expect that one would find that an OO application would have
fewer lines per function (for whatever that's worth), and more
functions per data structure. (for whatever that's worth).
You would also probably find more data structures in an OO
application.

Another interesting metric would be the number of "visible" functions.
This is clearly associated with complexity, since greater visibility
yeilds more options resulting in higher complexity.  In a C++
application the visible functions are those methods which are declared
in the public area of the class, plus the normal global function.  In
a traditional application it would simply be the count of global
function.  In both cases, functions visibile only to file scope should
not be counted.

I would expect that this 'visibility' metric would indicate that C++
applications are less complex than traditional applications.

-- 
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |

From rajar@herky.cs.uiowa.edu Sat Apr  4 02:09:19 1992
Posted-Date:  Sat, 4 Apr 92 02:02:46 -0600
Received-Date:  Sat, 4 Apr 92 02:06:49 -0600
Received: from herky.cs.uiowa.edu by emx.utexas.edu (5.61/1.9)
	id AA21022; Sat, 4 Apr 92 02:06:49 -0600
Received: by herky.cs.uiowa.edu (AIX 3.1/UCB 5.61/4.03)
          id AA31782; Sat, 4 Apr 92 02:02:46 -0600
Date: Sat, 4 Apr 92 02:02:46 -0600
From: rajar@herky.cs.uiowa.edu (Chandrashekar Rajaraman)
Message-Id: <9204040802.AA31782@herky.cs.uiowa.edu>
To: kalakota@emx.utexas.edu
Status: RO

>	How does one measure complexity in a O-O environment? I have seen measures
>	like Object Counts and Method counts in addition to the "old" metrics like
>	function points, Halstead and McCabe. Are these valid? If so, which one is the
>	best and in what kind of system? If not, Why not? How do you guys in the 
>	"industry"  measure complexity in O-O lifecycle? Enlighten us acedemicians.

Object Counts and Method Counts have limited use since they
are not granular enough for a wide range of software sizes. The
parallel that I can find - the number of procedures in a Fortran 
module. What about the complexity of each procedure / method ?
You will find that the state of the art in OO s/w complexity
measurement is quite backward.
Chidamber and Kemmerer in  "Towards a Metrics Suite for
OO Design" propose Weighted Methods per Class (WMC), but they
do not state how the weights are to be computed, and in so doing
(or should I say not doing) they have left an area ripe for
a little research - computing complexity at the method level.

As regards the validity of fp and Halstead, I have no idea, however,
you will find that the inapplicability of McCabe to OO will be difficult
to prove my empirical study simply because a lot of "OO" code (used
in these studies) is still COBOL(functional decomposition) in spirit !!

So, just as McCabe's is "pretty good" for non-OO, it will continue
to be so for OO, until more programmers *really* understand OO.

Chandra

P.S.I would greatly appreciate it if you would send me
*useful* replies to the above posting, before you get
a summary ready !

Newsgroups: comp.object