software Complexity

1
software Complexity

• The AMUSE project

By Bart-Floris Visscher
2
What will I talk about

• Overview of the field
• Views on complexity
• Amuse project
• Results
• Preliminary conclusions

3
Complexity Crisis

• What's the most important problem in computer
  science? Languages, tools, programmers? Well,
  according to a growing number of researchers and
  computer users, it's software complexity. "We've
  known about this problem for 40 years," says
  Alfred Spector, vice-president at IBM Research.
  "This is probably the number one problem...It
  can't go on."

The Rising Costs of Software Complexity Dr.
Dobb's Journal April 2001
4
Possible source

• "Fifteen years of Moore's law is really amazing.
  People don't understand exponentials very well."
  But developers are essentially working in the
  same ways, with the same tools, to create
  applications that must be vastly more powerful.

5
A complexity measure ofWindows family
6
Possible correlation between complexity measure
and ??

• Execution / Response Speed
• Usefulness
• Program Quality
• Debugging
• Correctness
• Reliability
• Robustness
• Mental effort to understand functionality
• Reuse
• Maintenance
• Adaptability
• Flexibility

7
Some measures of complexity

• Algorithm complexity (Space/Time/Work)
• Lines Of Code (MLOC, KLOC)
• Halstead software Science Metrics
• Counting number of total and unique operators and
  operands in the program
• Mental programming effort
• Henry and Kafuras measure
• Fan-in/out of subroutines
• McCabe cyclomatic complexity measure
• Control flow (Jumps, branches, loops)
• Structure metrics (Inter module complexity)
• Tree Impurity (Ince and Hekmatpour)
• Distance between the code graph and a pure tree

8
Why measure complexity?

• In Gradys book, Practical Software Metrics for
  Project Managements and Process Improvement, he
  states
• 75 of software developers admit that they do
  some maintenance.
• It costs 2 to 3 times as much to maintain
  software than it did to develop it initially
• Cheaper in total to make programs flexible to fit
  future requirements than rigged to fit current
  design requirements.
• How to design for the future?

9
General idea of how to deal with complexity
Divide and conquer Abstraction
10
Goals and complexity
Simple bricks used to build walls Complex bricks
used to predict where it will brake Bricks are
neither simple nor complex. Complexity depends on
the goal!!! GQM paradigm by Victor Basilli
11
AMUSE

• Architectural modelling to understand system
  evolution
• Architectonic view, layers of change
• (People, Furniture, Electricity/Water/Heat,
  layout of the room, layout of the floor, layout
  of the building, location of the building)
• 1 Year EPSRC funded feasibility study to show if
  there is a relationship between the layers in the
  environment and the structural layers in the
  program

12
Project split into three stages

• Layers of change in the environment
• Done by collaborators in University of North
  London
• Quantitative analysis using grounded theory of
  the environment by interviewing managers,
  programmers, look at company structure, financial
  situation etc.
• Layers of change in the software structure
• Done here by Prof. Tom Addis, Jan Addis and
  Bart-Floris Visscher
• See if they match
• Done in collaboration
• See how they match (Full study)

13
Structures in Software

• Most of the software structures have no formal
  reason!!!
• Structure is informal, depending on the goals
  your trying to optimise (Speed / Robustness /
  Maintenance/etc.)
• Syntax / Coding conventions / Comment
• Subroutines / Functions / Methods
• Data structures / Data types
• Classes / Inheritance
• Modules / Packages
• Etc. etc. etc.
• Simplify all to include only the formal semantics
  (behaviour)

14
Behavioural Dependency

• Definition A is behaviourally dependent on B if
  and only if B has the possibility of influencing
  and thereby effectively determining the behaviour
  of A
• In order to understand A, you will need to
  understand B.
• Indicator used A calls B (also memory)

A is dependant of B B is enabler of A
15
Example of Behavioural Dependencies
subroutine subA Global memA, memB memB
memA 2 Call subB end sub
memB subA subA memA subA subA subA subB
16
Translations into Behavioural dependency lists
Fortran Parser
Functional Dependency Lists
5 Commercial Applications (4 Fortran, 1 C)
C Parser
17
Bottom up / Top - Down

• Enabler distribution appear to have Wittworth
  distribution
• Distribution associated with random processes
• Decomposition of functions appears to be random
  process
• Dependent distribution appear to have Zipfs
  distribution
• Distribution associated with structured processes
• Usage of function appears to have structure

18
Starting Design Principle
General System Architecture Model

• Designing a program
• Single Entry point
• Into Operators / BI / LIB
• Programmers Job
• Fit Entry point concept with Low level concepts
  by Extending en Decomposing
• Overcome Tension
• Program split into levels

Main
Tension
Operators
Library
19
GSAM, Calls between Levels
20
Testing for GSAM

• All functions sorted
• High / Low sort
• Levels at top were decomposing
• Levels at bottom were mediating
• Levels in between were both decomposing/mediating
• No significant differences between levels
• No significant relation to levels of change

21
Recursive Design principle Homoarchy of keystone
groups

• Program consists of many other programs
• Single Entry points
• BI/LIB/Functions at higher programs
• Keystone function
• Entry point of program
• Concept of the program
• Informal semantics
• Keystone group
• Function within program
• Function can call outside
• Context tree
• For each function list all keystone groups it is
  part of from largest to smallest

22
Heterarchy v.s. Homoarchy

• Generate random graphs with same number of
  functions (363) and chance of connection
  P0.033999
• 1 None empty Keystone group found in 6 runs.

23
Hierarchy v.s. Homoarchy

• Function Role
• Decomposing, called only once
• Mediating, called more than once

24
Keystone groups in analysed projects

• Strong relationship
• NKG .15 F 13
• Why? Is this related to a limit in applying a
  divide and conquer strategy??

25
Keystone group size measures of analysed projects

• Average keystone group size 2-2.5
• Independent of previous keystone group size
• ????? Why ??????

26
Connection Entropy Measure

• Keystone functions increase the connection
  entropy in keystone group than just functions.
• More connections between keystone groups than
  between functions within keystone groups
• This contradicts the traditional view of
  clustering

27
DRUSLIP analysis

• Single analysis that incorporates
• Keystone functions / Groups
• Context of each function
• Determine the function role (Decomposing /
  Mediating)
• Sort levels in software
• 7 Possible relationships between each two
  functions
• Inaccessible Function is in a different branch
  of the context tree
• Unused Can potentially be called but is not
• Recursive Function call is at the same or
  higher level
• Decomposing Function is called only once
• Sub call to a keystone function that is at a
  lower context
• Local Call to a keystone function with the same
  context
• suPer Call a keystone function with a higher
  context

28
Example of DRUSLIP graph
Inaccessible Unused Unused Higher Decomposing Recu
rsive Sub Local super
29
Organisation in Calland DRUSLIP graphs
30
DRUSLIP graphs
Inaccessible Unused Unused Higher Decomposing Recu
rsive Sub Local super

• Fortran (similar pro.)
• Same BI/LIB
• Double main structure
• Initialisation structure

31
More DRUSLIP graphs
Inaccessible Unused Unused Higher Decomposing Recu
rsive Sub Local super

• C program for windows
• Many BI/LIB
• Single main structure
• Windows handling structure
• Initialisation structure

32
Additional possible measures

• As you go down the branches of the context tree,
  more functions become accessible, less functions
  have access to it.
• Only a few highly structured concepts
  representing the main concept of the program
• Several less structured concepts for
• Initialisation
• Event handling (User / System / Error )
• Does the context tree relate to levels of change?
• Higher concepts in the context tree appear to be
  more rigid than concepts in its sub contexts.
  Detailed comparison need to be made.

33
Preliminary Conclusions

• Behavioural dependencies are capable of
  representing any language (incl. OO)
• Program structure is better represented in a
  Homoarchy than as a Heterarchy or Hierarchy
• Reduction into sub concepts is linear to the
  number of functions related to the concept
• Functions related to each form sparsely connected
  structures and not clusters
• The Keystone Homoarchy may form a basis on how to
  evaluate the designers capabilities in handling
  complexity

34
The End

• Any questions??