Article Summary of
The Structural Complexity of Software:
An Experimental Test
By Darcy, Kemerer, Slaughter and Tomayko
In IEEE Transactions of Software Engineering
November, 2005 issue
Software Complexity
• There are problem complexity and solution complexity
– We are interested in solution complexity when we speak about
software complexity in “Design”
– For software solution there are:
• Algorithmic complexity (detailed design)
• Structural complexity (high level design / architecture)
– We are interested more in Structural Complexity when we
discuss the construction and maintenance of software
components because structural complexity deals with
organization of program/design elements (component, form,
rationale) --- which touches upon people’s decision making.
– Algorithmic Complexity is more interesting for execution of
code --- that is the reduction of number of steps to solve the
problem directly affects computational time, which is more
machine oriented than human oriented (even though it does
also affect human)
Interest in Structural Complexity
• Some main reasons of studying structural complexity is
to more clearly outline:
– What constitute (help define/measure) better or worse structure
– Ways to aid in creating structurally optimal solutions (less
complexity) to influence other attributes such as maintainability,
testability, re-usability, etc.
In software, we already know the concepts of cohesion and coupling
affect structural complexity ---- from past studies, we want:
- high cohesion and
- low coupling
Using Wood’s Task Complexity Model
to Aid in Studying Structural complexity
• Has 3 essential concepts:
– Products : things created by acts and behaviors
– Acts: pattern of behavior that has a purpose or direction
– Information cue ; information about attributes of stimuli that affect
the decision making needed to perform the tasks
• Also has 3 sources of task complexity associated with the
above concepts:
– Component complexity : # of distinct acts and the # of distinct
information cues needed in the performance of the acts to produce
the product.
– Coordinative complexity: relationships between task inputs and
task outputs such as the form, strength, and sequence of the
relationships.
– Dynamic complexity: changes in the state of the world that has an
effect on the relationship between tasks and products
People ---- Making Trade-offs
• Draw from Cognition studies on how people make
trade-offs between dimensions of complexity
– People have primary storage called short term memory (STM)
where all the needed information must be available for people
to think.
– People will access information from secondary storage called
long term memory (LTM) to help the thinking process. The
problem is that accessing LTM takes a lot more time and
effort.
This suggests that we should work with small chunks of information
and that thinking that requires the usage of LTM will take longer or more effort.
Drawing Analogy to Wood’s Task Complexity
and Cognitive Science’s STM and LTM
• Wood’s Complexity :
– Component Complexity – related to the acts and the information
cues need for each of the acts
• This is similar to software cohesion
– Coordinative Complexity – related to the precedence, form and
strength of relationships between the input to a task and the
product
• This is similar to software coupling
• Short Term and Long Term Memory:
– In comprehension and thinking, all the information must be brought
into STM and when there is too much some of that information is
moved to LTM.
• This is similar to looking at Cohesion of a component (STM) and
Coupling (LTM) among components, because coupling requires one to
look at more than one thing and thus require more memory --- (LTM).
These Task - Cognitive Science Studies also suggest that “complexities” are
not independent of each other.
Authors’ Research Hypotheses
• Hypothesis 1: For the more highly cohesive
programs, maintenance effort is lower
• Hypothesis 2: For the more highly coupled
programs, maintenance effort is higher
• Hypothesis 3: For the more highly coupled
programs, higher levels of cohesion reduce
maintenance effort.
Why would people think of Hypothesis 3? This 3rd Hypothesis
seems like something added after the experimental results were
known. (---- I am being a bit cynical here -----)
Experimental Test of Hypotheses
• Used 17 professional software engineers
• Performed “perfective” maintenance task on two
types of problems:
– Regression analysis enhancement written in procedural style
with C language
– Database functionality enhancement written in OO style with
C++ language
• There were 4 code variations set up for the
enhancement task:
–
–
–
–
High coupling – High cohesion
High coupling – Low cohesion
Low coupling – High cohesion
Low coupling – Low cohesion
• Measured the “time” required to complete the
maintenance task.
Somewhat Surprising Experimental Results
1.
2.
3.
4.
Covariate factors such as previous experience with
language and length of work experience had NO
significant correlation to task time.
Hypothesis 1 : more cohesive programs should
take less maintenance effort - - - could not be
accepted
Hypothesis 2: more coupled programs should take
more maintenance effort - - - could not be accepted
Hypothesis 3: For more highly coupled programs,
higher levels of cohesion reduce maintenance
effort - - - could be accepted
The two attributes, coupling and cohesion, together shows a relationship where
coupling is the main and cohesion is the moderator of that relationship in
bringing down the maintenance effort.
Hypothesis 3 Results Says?
• In case of high coupling we need to bring in a
lot of related information and use LTM
because coupling brings in chunks
(programs) of information that need to be
processed.
– Within the situation of high coupling, when the
chunk (program) is itself very cohesive, then
maintenance effort is actually less compared to
when the chunk is less cohesive.
Now Look carefully at Figure 6 of the Article
high
1.
2.
3.
4.
Observations:
With low cpl, effort is higher as we get more cohesive --- not ok
With high cpl, effort is lower as we get more cohesive --- ok
With high cohesion, effort goes up with low cpl ---- not ok
With low cohesion, effort goes up with high cpl ---- ok
effort
(low cpl; high coh)
(high cpl; low coh)
with high coupling,
high cohesion is
better
(high cpl; high coh)
(low cpl; low coh)
high
coupling
The experimental results did NOT come out with high cohesion is always better (e.g. low
coupling with low cohesion required less effort than low coupling with high cohesion!)