Dewey
HD28
.M414
^0
f JAN 28
1^<^-
mS%m
Center for Information Systems Research
Massachusetts
Institute of
Alfred P. Sloan School of
Technology
Management
50 Memorial Drive
Cambridge, Massachusetts, 02139
617 253-1000
1982
TOWARDS AN AXIOMATIC APPROACH
TO
INFORMATION SYSTEMS DEVELOPMENT
John J. Donovan
Steven H. Kim
August 1981
CISR No. 77
Sloan WP No. 1260-81
To be presented at the Second International Conference on Information Systems
Cambridge
December 1981
(c)
1981 John J. Donovan and Steven H. Kim
Center for Information Systems Research
Sloan School of Management
Massachusetts Institute of Technology
M.I.T.
LIBRARIES
JAN 2 8
1982
RECEIVED
Page
10/02/81
Axiomatics
1
ABSTRACT
method)
This paper advocates an approach (called the axiomatic
to reduce
the
costs
of
constructing
system.
information
an
method to
Further, we contrast the applicability of the axiomatic
the
more
traditional
approach of enumerating alternatives (the
algorithmic method) in constructing an information system.
We delineate the steps involved
system,
theorems.
present
a
in
set of pilot axioms,
building
an
information
and offer some derivative
We then apply these axioms and theorems to each
(specification,
design,
implementation
information system life cycle, and confirm
phase
and maintenance) of the
a
number of
empirical
results other information system builders have observed.
0''/43€.X4
Axiomatics
10/02/81
1
Page 2
INTRODUCTION
.
Our discussion of PRODUCTIVITY pertains to
time
and
cost
involved
information system
(specification,
maintenance).
include
We
computer-based
system
information.
This
in
used
operational examples
such
the
as
the
in
building an
of
implementation
design,
and
term INFORMATION SYSTEM any
analyze
store,
to
includes
phases
four
all
in
reduction
the
spectrum
systems
accounting
payroll
present
and
of
from
decision
to
support systems for strategic planning.
The purpose of this paper is to present
whittling
for
construction
down
that
builder
system
a
must
systematic
method
and cost; this is to be
time
achieved by strategically reducing
a
number
the
when
evaluate
of
alternatives
constructing
an
information system.
We use the term INFORMATION SYSTEM CONSTRUCTION to
four
all
phases
of
system life cycle.
the
apply
to
Likewise the term
INFORMATION SYSTEM BUILDER refers to the person(s) in
charge
of
these four phases.
BACKGROUND ON AXIOMATICS
1.1
In some areas
that
always
certain
appear
such as manufacturing,
design
to
decisions
yield
(e.g.
superior
it
has
been
recognized
maintaining
modularity)
This
observation
designs.
10/02/81
Axiomatics
the
suggests
the process.
3
existence of basic natural principles which govern
If
these principles or axioms can be
crystallized
and
Page
information
for
systems,
tracked
down
we may establish
a
scientific approach to design.
AXIOMS
general
are
counter-examples.
truths
immune
violations
to
or
are to be taken as first principles and
They
are intrinsically unprovable.
THEOREMS may be defined as readily derivable
consequences
of
axioms, while COROLLARIES are readily deducible results of axioms
and theorems.
FUNCTIONAL REQUIREMENTS are the
specifications
include
the
transactions,
security,
completely
that
capacity
degree
of
of
minimum
define
the
database,
the
independent
of
Examples
tasks.
number
multiprogramming,
daily
of
level of read/write
and extent of backup to allow complete reconstruction.
In addition to functional requirements,
needed
set
to
specify
limits
on
constraints are
byproducts
or
often
effects.
side
CONSTRAINTS are specifications that define the boundaries
attributes
which
of these side effects are acceptable.
within
Examples
include upper limits on cooling requirements or mean time between
failures, or lower limits on the accuracy of numerical solutions.
White and Booth [21], for example, recommend the inclusion
of
these specifications for software design:
1.
Functional
specifications.
Definition
of
each
data
element and the control structure among various tasks.
2.
Performance constraints.
Specification of
each
subtask
Axiomatics
10/02/81
operate
to
within
its
Page
time
4
and space constraints and to
allow the overall task to do the same.
HEURISTICS are similar to
working
guidelines.
an axiom.
1.
But
a
axioms
in
that
they
offer
both
heuristic doesn't carry the weight of
Example heuristics might be:
accounts
"If your average
receivable
is
over
$1,000,
ignore those under $10."
"For clarity and readability,
keep subroutines
under
30
These are heuristics because they provide rules of thumb with
no
2.
executable source statements." [20]
claim to ALWAYS yielding the best result.
definition
are always valid.
those of Thermodynamics,
of
a
were
to
reveal
contrast, axioms by
such as the First Law:
system is constant."
be promoted to axioms
In
Perhaps the most famous axioms are
"The total energy
(The two sample heuristics
if industrial
above
may
or psychological case studies
that they always produce the most profitable or
readable results.)
1.2
FRAMEWORK FOR INFORMATION SYSTEMS DEVELOPMENT
The phases involved in constructing an information system
be
classified in
a
variety of ways [14],
the development phases as:
1.
Specification
In
may
this paper, we view
a.
functional requirements
b.
constraints
5
Architectural design
2.
a.
hardware
b.
software
Implementation
3.
a.
hardware selection
b.
code generation
c.
testing
Maintenance
4.
These phases are not intended to be
according
example,
Page
10/02/81
Axiomatics
one
to
partitioned.
strictly
For
method of software development, the
encoding and testing of modules should proceed side by side.
In
addition,
a
backtracking
necessitate
arising
development
to an earlier one.
program error detected in testing may require
coding or even the software design stage.
process
occurs
often
enough
to
at
In
a
the
might
illustration,
a
regression to the
In fact,
reverse
this
prompt investigation:
McClean and Urfrig [2] have shown that
errors
phase
one
in
cost
of
Boehm,
correcting
coding time is about twice that of changing it at the
design stage;
and finding it at
testing
time
costs
times that during design.
2.
ALGORITHMIC VERSUS AXIOMATIC APPROACH
about
10
Axiomatics
10/02/81
Page
6
ALGORITHMICS
2.1
The techniques for evaluating alternative
may
subdivided
be
into
basic
two
information
efficiently identify
the
approach
algorithmic
is
global
and
set of rules which
a
optimum.
contrast,
In
the
for considering
method
procedural
a
algorithmic
types,
The axiomatic method is based on
axiomatic.
systems
categories:
alternatives, and may be subdivided further into two
exhaustive and rapid search methods.
EXHAUSTIVE SEARCH
2.1.1
One algorithmic
approach
configurations
possible
— EXHAUSTIVE
SEARCH
choices.
and
— enumerates
all
drawback
The
with
exhaustive search with respect to information system construction
lies in the myriad technical choices and the explosive number
requirements
functional
demanded of new systems. To illustrate,
consider the recent design of an information system at
Associates
or
of
example
say
5
type
CPU,
programming
— that
Microwave
Burlington, Massachusetts: some design attributes
of
dimensions considered were the
size
of
language.
of
data
choice
of
representation,
Suppose
— in
this
operating
system,
and selection of
small
fancifully
there are only 10 such attributes to consider, with
choices
per
attribute.
million, design possibilities.
weekends to evaluate them all.
2.1 .2 RAPID SEARCH
The result is 5**10,
It would take
more
or over
than
a
9
few
.
10/02/81
Axiomatics
Page 7
Another algorithmic approach is RAPID SEARCH, in which
of guidelines constrain the domain of evaluation.
branch
which
bound,
and
seeks
to
a
set
One example is
discard entire branches of
inferior alternatives in the design tree.
Another example is stagewise optimization: as
is optimized,
attribute
each
the next attribute is evaluated cc nditionally under
the constraint that the preceding attribute chojces will prevail.
Consider again the
attributes
4
mentioned.
The
steps
for
stagewise optimization are:
Step
Identify all attributes and all choices within
1.
Optionally,
attribute.
each
these attributes might be ranked in
order of importance.
Step 2. Select the best choice of operating system.
Suppose
CI.
Step
3.
C2.
Say C2
CI
=
VM/370.
Select the size of CPU given that
=
=
CI
Call it
given
CI
and
C2
CI,
C2,
and
relational data model.
Step 5. Select the programming language given
Suppose C4
C3.
holds.
1024K.
Step 4. Select the data representation,
Say it's C3
Call it
=
PL/I.
Then the design with {CI C2 C3 04} will be the stagewise optimal.
,
Suppose there are
n
,
,
attributes, with m choices per
Then the stagewise algorithm requires
n
M
=
E
m.
attribute.
Axiomatics
10/02/81
evaluations.
Page
the exhaustive search method requires
In contrast,
n
N
=
es
5
,
The efficacy of the stagewise method for
evaluations.
with
m
n
•
a
problem
choices in each of 10 dimensions is
n
N
."-
e^s
N
^
1=1
SW
m.
'
"
m.
T.
1
10
c
b
-
^
2 *
10
5 * 10
i-1
In
the
class
well-specified
of
search
rapid
techniques
(e.g.
drawback
of
rapid
search
only
is
global
its
optimum.
lack
of
producing the global optimum: the union of optimized
does not necessarily yield
a
few
a
branch and bound) can lay claim
to solution algorithms that yield the
the
methods,
Usually
guarantee of
subproblems
global optimum unless the components
are mutually independent.
2.2
AXIOMATICS
The question now arises: Does there exist
principles
which
always
provides
subsets of design configurations?
attempt to specify those rules.
rules
a
set
of
general
for eliminating large
The AXIOMATIC APPROACH
is
an
10/02/81
Axiomatics
Page
9
PRESENTATION OF AXIOMS
3.
SOME DEFINITIONS
3.1
We may define
a
FEASIBLE
system
configuration
as
that
one
satisfies the functional requirements and constraints.
Then PRODUCTIVITY may be defined
[8],
with
time
in
Consider two feasible configurations A and
that
say
A
A are
For our purposes,
[9].
sense
B.
In this paper,
we
is more productive than B if both the time and cost
required to build
ways
Pareto-optimal
a
and monetary costs as attributes or dimensions.
The
less than that of
B.
INFORMATION may be defined in
information content involved in
might be characterized by the number of bits
fully describe the design.
variety
a
a
of
system design
needed to
encode
or
When communication between modules is
involved, information might be taken as defined by Shannon [171:
E
-
P.-log^
p.
1
where
p
is the probability of transmitting the ith message,
and
the summation occurs over all possible messages.
The concept of ENTROPY may be defined loosely as randomness or
disorder.
In the sense
of
information
theory
or
statistical
mechanics, entropy may be defined as the negative of information.
This relationship will be explored further in the future.
3.2
AXIOMS
Axiomatics
10/02/81
Page 10
We propose the following axioms as the set applicable
to
the
construction of information systems:
A1
:
Productivity
increases
information
when
content
is
minimized.
A2
:
increases
Entropy
over
time,
or
remains
best
at
constant.
A3:
Productivity
increases
when
independence
the
of
functional requirements is maintained.
calls
A1
for
Intuitively,
we
a
minimization
expect
information
of
the cost and complexity of
implementation to rise with
a
a
rise in the information
content.
particular
must
that
be used to define the system.
A2
refers to the viability of implemented systems.
that randomness or disorder in
time.
Eventually
must
system tends
functional
the
deteriorates to the point
system
a
where
a
implies
increase
to
modularity
completely
It
the
of
over
system
information
new
This concept is discussed further
be built afresh.
in connection with the theorems given below.
A3
calls
for
requirements
which
solution
satisfies
A
a
change
attribute
this
would
in
one
require
allows
for
functional
triggers
a
change
in
the collective optimization of the
entire set of interacting components.
independence
the
optimum is difficult to
global
independently.
attain when
others:
a
modular
In
contrast,
optimization
maintaining
in
which
10/02/81
Axiomatics
Page
optimization of each component may proceed independently
others.
independent
more
The
of
11
the
components, the better the
the
solution.
These axioms are adopted from those that have been applied
fields.
other
is
A2
thermodynamics;
A1
a
restatement
and A3 have been
of
Second
the
applied
by
Law
Bell
Suh,
to
of
and
Gossard [18] to manufacturing systems.
4.
APPLICATION OF THE AXIOMS
In this section we describe how the
number
theorems
of
pertaining
information system life cycle.
axioms
give
various
to
rise
phases
to
of
a
the
We also indicate how the theorems
might be proved.
4.1
PHASE
The
SPECIFICATION
1:
theorem
first
follows
from
A1
,
which
calls
for
a
minimization of information:
T1.1
Productivity increases when the number
of
functional
requirements are minimized.
Obviously
the
information
content
incorporated
in
a
system
specification can only increase with an increase in the number of
functional
requirements
and
constraints.
The
resulting
Axiomatics
10/02/81
complexity
assertion
n,2
This
cost.
.
PHASE 2: ARCHITECTURAL DESIGN
In the following theorems,
may
construction
increase
consistent also with the behavior of manufacturing
is
systems [22]
only
then
can
Page 12
either
apply
"component"
the terms "module" and
hardware or software in the architectural
to
design phase:
Productivity
T2.1
increased
with
increases
use
of
standardized or interchangeable modules.
T2.2
a
A
design should incorporate functional requirements in
single module if
these
requirements
can
be
kept
from
mutually interacting.
requirements,
If a design exhibits coupled functional
T2.3
these requirements should be segregated or decoupled.
The first theorem (T2.1) springs from
minimization of information.
description
or
specification
When
is
a
A1
requires
which
,
a
standard module is used, its
required
only
once.
If the
module is needed again, it may be specified simply by referencing
the original module.
T2.2 derives from
discrete
modules
A1
,
since
minimizes
a
reduction
as
A3
requires,
the
number
of
information that would otherwise be
needed to specify how all the original
However,
in
modules
would
interact.
the functional requirements must still
10/02/81
Axiomatics
be independent of each other;
result
interdependencies
the
if not,
overall information requirements.
increased
in
Page 13
may
This is
the idea behind theorem T2.3.
The use of T2.3 may be illustrated by an example from
writers'
the
personal experience.
one
of
The setting involved the Pan
Am reservation system which was experiencing
phenomenal
growth.
system retrieved data through linear search methods; but the
The
increasing size of the database led to
retrieval
in
which
time,
transactions
processed.
requirements
pertaining
in
In
the
to
corresponding
a
turn
reduced
this
case,
size
increase
the daily rate of
the
functional
the database and the
of
transaction processing rate had become coupled.
A
this
decoupling of these functional requirements
was
was
in
order;
by converting the method to hashing
accomplished
For low record densities in
a
hashed system,
the
accessing
[5].
rate
(hence the transaction processing rate) is largely independent of
the database size.
4.2.1
PARTITIONING OF FUNCTIONAL REQUIREMENTS
The complete independence of
ideal
As
a
to strive for,
practical matter,
requirements
functional
is
an
but may be difficult to attain in practice.
a
partial independence
among
subsets
of
functional requirements may be better than none.
We may invoke
T2.4
A1
and A2 to yield the following theorem:
Functional requirements should
be
partitioned
into
Axiomatics
10/02/81
Page 14
smaller groups with minimal interaction between groups.
Consider
According
applications
financial
a
theorem,
this
to
package,
example.
for
change in the credit check module
a
should not disturb the billing module.
optimally
To
partition
groups,
smaller
functional
important
is
it
between
relationships
the
to
requirements.
those
requirements
into
evaluate
first
These
the
functional
dependencies may then be represented by an undirected graph (See,
Andreu
example,
for
survey
brief
offers
a
and
[1]
method
better
Huff [?]).
Wong [23] presents
graph-decomposition
existing
of
for
finding
techniques
subgroups of independent
His technique is discussed
functional requirements.
a
and
in
greater
detail in the Attachment.
4.3
PHASE
IMPLEMENTATION
3:
From axiom
A1
we also propose another
theorem
applicable
to
Phase 3b (software design) of the information systems development
life cycle:
T3.1
The number of program statements should be minimized.
This is consistent
with
the
empirical
observation
increases disproportionately with program size [11]:
Effort
=
Constant
*
(Number of instructions)
'
that
cost
10/02/81
Axiotnatics
Another theorem due to
A1
Page 15
is
Productivity increases with the use of
T3.2
a
higher-level
language.
Taliaffero [19] reports that productivity is
statements
Fortran
per
year
productivity
by
whether
Nelson
Cobol.
or
factor
a
a
at
2,400
program is written in assembler,
also
[12]
of
constant
shows
an
increase
in
or more by using higher-level
3
languages.
Some other consequences of
T3.3
A
A1
are:
system should be decomposed
smaller
into
logical
units.
Separate subroutines
T3.4
should
be
designed
for
each
elementary task.
Here,
information is minimized because the interaction among
elements
of the system are localized within each
situation,
any
accomplished
as
interaction
between
modules
i
nodule.
and
the
In this
j
are
components in their entirety, without the need
for one to keep track of the function of each element within
the
other module.
One rule of thumb calls for
modules
a
partitioning of
functions
into
until each module includes no two elements that might be
useful in isolation.
Another
rule
claims
that
each
program
10/02/81
Axiomatics
module
should
be
enough
small
allowing comprehension at
Page 16
fit
to
one page,
on
thereby
single glance.
a
The drive toward modularity is not costless,
Camp
of course.
Jensen [4] report that modularity results in an extra 20-35%
and
overhead in memory and another 10-15X excess in run time
with
the
maintenance.
of software analysts,
increase
will
words,
overhead.
For
As
and cost by 50 to 100%.
example,
module
as
module
who believe that doubling the
complexity
the recommended average module size is
module
triple
with the concensus opinion
This may be compared
doubles.
size
costs
complexity and
In fact,
a
during development and
savings in productivity
major
over
but these costs are small in comparison
monolithic architecture;
if
to
3
the
5
times
a
the
size
result,
average
module overhead is 10
then the average module size should be
30
to
50
words,
including the overhead.
A1
and T3
T3.5
. 1
suggest this result:
The number of instructions coded is not
a
measure
of
productivity.
Intuitively,
instructions.
large-scale
But
A1
and T3
of instructions generated.
by total program size.
4.4
systems
PHASE 4: MAINTENANCE
. 1
require
will
call for
a
many
program
reduction in the number
Hence productivity cannot be measured
10/02/81
Axiomatics
Page 17
Axiom A2 suggests the following theorem:
The usability of
T4.1
a
decreases
system
over
time,
and
will eventually vanish.
Brooks [3] maintains that all information systems die eventually.
This is attributed to the inevitable patches or fixes to software
errors,
and the resulting decay in the
The need for fixes arise from
the sytem.
a)
conceptual
integrity
of
variety of factors.
a
Bugs.
Bugs in large systems
According
Brooks
to
Pikul and Wojcik
verminous
[15]
attacks.
fixing
[33,
introduce another with 20
As
remarkably
are
-
one
50 % probability.
offer
shown
the
bugs detected rises steeply at the outset
then
around
A
a
drops.
But
of
for
the rate of
any
program.
the attack rate eventually
it rises once again,
to oscillate
steady-state value within an attenuated envelope.
highly damped version of this
slow
model
following
in the diagram,
As debugging proceeds in earnest,
peaks,
creatures.
hardy
error will merely
decay
to
steady-state
model
value,
(steep
without
rise
the
and
minor
oscillations) is supported also by Ramamoorthy and Ho [16].
b)
Changes in user requirements.
In practice,
system,
they
as users become proficient with a particular
begin
to
demand
higher
performance.
They
change the original functional requirements by stretching an
existing
one
or
even
even
adding
new ones.
An airline
10/02/81
Axiomatics
Page 18
Rate of
Software
Errors
Detected
Cumulative number of program
ru-'is
reservation system, for example, may begin
simple
passenger
booking system.
is expanded to allow for kosher
fuel
distribution,
and
other
operation
meals,
addition of new code could easily mean
that
a
scheduling,
flight
functions.
as
the system
In due course
rate
The
the
bugs
of
are
proliferating faster than they are being eliminated,
c)
Changes due to hardware.
Technological advances may dictate the switch from,
an
IBM/370
to
a
/3033 for increased processing speed.
say,
Any
Page 19
10/02/81
Axiomatics
such transformation is rife with conversion problems.
5.
RELATIONSHIPS BETWEEN THEOREMS
The precedence relationships among the axioms and theorems may
be summarized as follows,
"derived from":
where arrows indicate the
relationship
Axiomatics
A
10/02/81
question which might arise is,
play
building
in
analysis in the
information
construction
Page 20
"What
role
systems?"
of
does
creativity
Creativity
information
precedes
systems;
it
is
important in the generation of alternative designs, without which
there can be no comparative evaluation.
methods are available for stimulating
A variety of
One of these is the trigger word method involving questions
[6].
what
about
[13]
creativity
"Magnify?",
The
design
the
is based on
a
The checklist method
such
as
"Rearrange?" or "Combine?"
morphological
attributes
is supposed to do.
series of questions on modification,
method
listing
involved,
[24]
requires
and
them,
determining
considering
all
the
the
resulting combinations.
Brainstorming refers to the animated generation of ideas by
heterogeneous group of participants,
new
a
The purpose is to produce
possible, however unorthodox they may be.
This paper, however,
se.
some of whom may be entirely
to the concepts under discussion.
as many ideas as
is not intended to address creativity per
The aim of axiomatics is to channel creativity by
set of guidelines.
designs,
but
a
providing
The objective lies not in the generation of
in the assignment of relative merit to alternative
configurations.
7.
CLOSURE
10/02/81
Axiomatics
Page 21
application
This paper has introduced the
of
axiomatic
the
approach to productivity in constructing information systems.
three
enumerated
have
pilot
proposed
axioms,
theorems, and indicated how the theorems spring from
upon
draw
and
empirical
results
from
the
We
number
a
of
axioms
the
construction
of
information systems.
We note that axiomatics is not
candidate
but
designs,
a
process of evaluating them.
to supplant algorithmics.
streamlining
in
the
methodology
a
generating
for
for use in the decision-making
tool
Further, axiomatics is not
intended
they will reinforce each other
Rather,
development process, as illustrated by the
use of the decomposition algorithms discussed in Section 4.2.1.
We hope that this paper
informations
systems
will
start
community,
so
a
that
dialogue
we
within
may collectively
generate the analytical and experimental results needed to
concept further.
this
only
a
pilot set,
the
carry
The axioms and theorems proposed here are
and may require changing,
deleting or adding to
in the light of experience.
In the future we would
compact
set,
to
like
refine
to
rephrase them in
a
in
systems
development.
axioms
into
a
more quantitative form from
which to prove the theorems, and to validate
studies
the
them
through
case
The successful development of
the axiomatic approach should open up new avenues for
increasing
productivity in the construction of information systems.
Axiomatics
10/02/81
Page 22
ACKNOWLEDGEMENTS
We gratefully acknowledge our debt to those who
before
us,
to Professor Nam P.
fields.
Recognition
field
colleagues
and
suggestions.
due
in
to
those
in
of thermodynamics who initially applied the axiomatic
method to the analysis of physical systems.
Lattin
is
Suh and his colleagues at the MIT
Laboratory for Manufacturing and Productivity, and
the
written
both in information systems and in the application of
the axiomatic method in other
particular
have
at
the
Mike
Sloan
School of Management
Treacy--for
their
also
We
—
thoughtful
thank
our
Tony Wong, Jim
comments
and
Page 23
10/02/81
Axiomatics
ATTACHMENT- DECOMPOSITION OF FUNCTIONAL REQUIREMENTS
BY THE HIGH-DENSITY CLUSTERING METHOD
A.I
GRAPHICAL REPRESENTATION OF FUNCTIONAL REQUIREMENTS
The first task in partitioning functional requirements
them
represent
of a graph,
nodes
as
between them as arc weights.
is
to
and the interdependencies
information
In building an
system,
some examples of functional requirements might be:
1.
The users will be guided by menus.
2.
A
report-writing facility will allow
users
to
develop
customized reports.
3.
the
to
Reports can be directed
line
printer
may
be
or
the
user's terminal.
Each
these
of
graphically
functional
as
requirements
functional
a
node
in
requirements,
interrelationship
we
between
design graph.
a
consider
can
the
nodes.
The
represented
For each pair of
degree
the
extent
of
this
of
association can be characterized as the weight on the link or arc
between the pair.
and
For convenience the weights are normalized between
If
two
functional
requirements
are
deemed
interdependency, the system builder might assign
0.3;
to
a
have
link weight of
an average degree of coupling may be represented by 0.5;
strong
relationship
deemed independent,
by 0.8.
1.
weak
a
a
If two functional requirements are
the link weight is 0.0,
is eliminated from the design graph.
and the
link
itself
10/02/81
Axiomatics
Returning
to
requirements
functional
therefore assigned
But
nodes).
two
example
our
above,
may
aids
must
a
be
the
the
first
considered
link weight of
a
,
since
requirements
of
and
between
the
this
way
report
the
directing
So the link weight is
be made available to the user.
value
and
no link
(i.e.
second
and
independent
first and third may be viewed to have an
average degree of interdependency
given
Page 24
the
0.5.
In
their
interdependencies
set
may
functional
of
be
represented
graphically.
DENSITY CONTOURS
A. 2
This section outlines the high-density clustering
functional decomposition proposed by Wong [233.
consisting
of nodes and unweighted arcs.
other
and
1
0-7
— O-
linked
to
In the figure below,
should belong in the same cluster,
a
for
graph
Intuitively, two nodes
belong to the same group or cluster if they are
and to many nodes in common.
method
Consider
while
nodes
i
each
nodes
k
and
j
->D
4should
be in separate cluster:
le
DKNSITY CONTOUR on the link
Axiomatics
10/02/81
between any two nodes
i
and
j
Page 25
is defined as:
No. of nodes connected tc both
i
and
j
(including
i
and
j
ij
U
"^J
No.
of nodes connected to either
i
or j or both (includii
and
i
,
If two nodes are unlinked,
their contour is defined to be zero.
The figure below illustrates the use of this definition.
example,
the contour between nodes
d*
For weighted arcs,
=
1
For
and 2 is 3/5.
2/8
the corresponding definition for
the
density
Axiomatics
10/02/81
Page 26
contour is
^ "ij ' '/^ tecC'ik ^
"it'
"ij
U-'iJ
where
W^-
•
weight on the link between nodes
=
nodes connected to both
i
and
(excluding
j
and j; C
i
set
r
and j).
i
Now we turn to the idea of grouping individual nodes.
DENSITY
CLUSTER
level
at
d*
on
graph
a
is
G,
by
links with density contour
—'d*.
in the preceding figure represent the density
HIGH
A
subgraph
a
that S is maximal among connected sets of nodes whose
connected
of
S
such
nodes
are
The nested loops
contours
for
the
given graph.
The family of high-density clusters on
form
a
at level d* expands
until
a
splitting
cluster joins with
smoothly.
This
level
is
a
c^
previously
graph may be shown to
gradual
reached,
disjoint
clusters, called BRANCHING CLUSTERS,
splitting
level is d*
=
2/8;
the cluster S
expansion
occurs
at which point the
cluster.
These
two
are useful in suggesting the
number of subgraphs in the original graph.
the
a
As the density level d* is decreased,
tree.
In the diagram above,
the two branching clusters are
{1,2,3,4,5} and {6,7,8,9,10}.
A. 3
IDENTIFYING
AND
PARTITIONING
THE
TREE
OF
HIGH-DENSITY
CLUSTERS
Consider
a
set of N nodes with density contours
d(i,j).
The
10/02/81
Axiomatics
Page 2?
algorithm to identify the tree of high-density clusters is:
STEP1. Let
i
and
j
be the pair of nodes with
Combine them to form
a
between that cluster and any node
d(l,k)
STEP2.
j.
Repeat STEP1
,
=
max [d(
treating
1
k
a
i, k) ,d( j,
k)]
as a node and ignoring
nodes
and
are
the
to
minimum
spanning
The drawback of this procedure is that the tree
of clusters does not explicitly yield
functional
i
single large cluster.
The foregoing procedure is equivalent
algorithm.
link.
by
The aggregation of nodes continues until all
absorbed into
tree
densest
cluster 1; define the density contour
requirements.
This
algorithm given by Lattin
[10],
the
optimal
grouping
of
last step may be effected by an
which
identifies
subgraphs of functional requirements from the tree.
the
optimal
Axiomatics
10/02/81
Page 28
REFERENCES
R.C.
Andreu,
A
systematic approach to the design and
[I]
structuring
of
complex software
systems.
Unpublished Ph.D.
thesis, Sloan School of Management, MIT, 1978.
Boehm, B.
McClean, R. and Urfrig, D.
[2]
Some experience with
automated aids to the design of large scale reliable software.
Proc. International Conference on Reliable Software, Los Angeles,
CA, April 1975, pp. 105-113.
,
Brooks,
F.P.,
Jr.
The Mythical
Man - Month
Essavs
[3]
Addison-Wesley, Reading, MA, 1975.
Software Engineering.
:
xm
[M]
Camp, J.W., and Jensen, E.P.
Cost
of modularity.
Proc.
Symposium on Computer Software Engineering, April 20-22, 1976,
Polytechnic Press, New York, 1976.
[5]
1972,
Donovan, J.J.
pp. 91-95.
[6]
Harrisburger,
Belmont, CA, I966.
Systems Programming
.
McGraw-Hill, New
Engineer smanship
.
Brooks/Cole
L.
York,
Publising,
Huff, S.L.
A
systematic methodology for designing the
[7]
architecture of complex software systems.
Technical Report No.
Naval
Systems
Electronic
Command, Washington, D.C., 1979.
12,
[8]
Keeney,
Objectives
.
and
R.L.
Raiffa,
John Wiley, New York,
H.
1976,
Decisions With
pp. 69-77.
Multiple
Kim,
S.H.
Manufacturing
axiomatics,
with
special
[9]
application to air compressor design.
Unpublished S.M. thesis.
Department of Mechanical Engineering, MIT, 1978.
Implementation and evaluation of a graph
[10] Lattin, J.M.
partitioning technique based on a high-density clustering model.
Technical Report #15, Center for
Information Systems Research,
MIT,
1981.
[II]
Nanus,
B.
and
Farr,
L.
Some cost contributors
to
large-scale programs, AFIPS Proc. SJCC, Spring 1964, pp. 239-248.
[12] Nelson, E.A.
Management
Computer Programming Costs.
^
TM-3225, pp. 66-67.
Handbook for the Estimation of
Systems Development Corp., Report
10/02/81
Axiomatics
[13] Osborn, A.F.
New York, 1963.
Applied Imagination.
Page 29
Charles Scribner's Sons,
and
L.L.
L.J.
Tripp,
A
Peters,
model
of
software
Proc.
3rd
International Conference on Software
engineering.
Engineering, Atlanta, GA, May 10-12, 1978, pp. 63-70.
.[14]
Wojcik,
R.T.
Software effectiveness:
[15] Pikul, R.A. and
a
growth
approach.
reliability
Proc.
Symposium on Computer
Software Engineering, April 20-22, 1976, Polytechnic Press,
New
York,
1976.
[16] Ramamoorthy, C.V. and Ho, B.F.
Testing large software with
automated software evaluation systems.
IEEE
Transactions on
No. 1, pp. 46-58.
Software Enginerring, SE-1
,
The
Mathematical Theory
[17] Shannon, C.E.
of Illinois Press, Urbana, IL, 1949.
Univ.
of
Communication,.'
[18] Suh, N.P., Bell, A.C., and Gossard, D.G.
On
an
approach to manufacturing and manufacturing systems.
the ASME 77-WA/PROD- 14, 1977.
W.M.
[19] Taliafero,
Software
potential.
,
1,
axiomatic
Trans,
Modularity,
the
key to system
3 (July 1971), pp. 245-57.
Weinberg,
G.M.
[20]
PL/I
McGraw-Hill, New York, 1970.
Progr amming;
A
Manual
of
of
growth
—
Style.
[21] White, J.R. and Booth, T.L.
Towards an engineering approach
to
software design.
Proc.
2nd
International Conference on
Software Engineering, Oct. 13-15, IEEE, 1976, pp. 214-222.
[22] Wilson, D.R., Bell, A.C., Suh, N.P., van Dyck, F.
and Tice,
Manufacturing axioms and their corollaries.
Proc.
North
American Metalworking Research Conference, May 13-16, 1979.
,
W.W.
A
graph decomposition technique based on a
[23] Wong, M.A.
high-density clustering model on graphs.
Technical Report #14,
Center for Information Systems Research, MIT, I98O.
F.
[24] Zwicky,
Discovery,
Invention,
Research
Morphological Approach.
MacMillan, New York, 1969.
through
the
vV
^C
5'B2
-uate uu
ENT
HD28.IVI414 no.l260' 81
Donovan, John /Towards an axiomatic ap
D'^BKS
743614
.001365.6.9.
_
3
TDflO
_
0D2 D42 751