SOFTWARE SYSTEM COMPLEXITY

• “Consisting of or comprehending various parts united

or connected together; formed by a combination of
different elements”
– (the definition of complexity from the Oxford English
Dictionary).

• Examples:
– retail banking,
– scheduled airline services
– component warehousing
– process control
 Complexity
“The more complex the system, the more open it is to total breakdown”
.

comparison of a software system and a non software system

A builder cant think about adding a new sub-basement to an existing

100-story building.

•Doing that would be very costly and would invite failure.

But, users of software systems rarely think twice about asking for
equivalent changes.
•They think that it is only a simple matter of programming.
 Complexity

• Our failure to master the complexity of software results

in projects that are
– late,
– over budget, and
– deficient in their stated requirements.
• This is called the software crisis,

• This crisis translates into

1. the waste of human resources—a most precious commodity
and
2. a considerable loss of opportunities.
 Organization of complex systems
• A personal computer has moderate complexity. Is composed of the
same major elements:
– a central processing unit (CPU),
– a monitor,
– a keyboard, and
– some sort of secondary storage device, usually either a CD or
DVD drive and
– hard disk drive.
 Organization of complex systems
• We may take any one of these parts and further decompose it

• For example,
– a CPU encompasses
• primary memory,
• an arithmetic/logic unit (ALU), and
• a bus to which peripheral devices are attached.

Each of these parts may in turn be further decomposed:

For example:
An ALU is composed of
– registers and random control logic,
• which themselves are constructed from even more primitive elements, such as
– NAND gates, inverters, and so on.

What do we observe here???

1. The hierarchic nature of a complex system.

• A personal computer functions properly only because of the

collaborative activity of each of its major parts.
• Together, these separate parts logically form a whole.

• A computer works only because

– we can decompose it into parts that we can study separately.
– Thus, we may study the operation of a monitor independently of
operation of the hard disk drive.

• Similarly, we may study the ALU without regard for the

primary memory subsystem.
2. Not only are complex systems hierarchic,

but the levels of this hierarchy represent different

levels of abstraction, each built upon the other,
and each understandable by itself.

– At each level of abstraction, we find a collection of

devices that collaborate to provide services to higher
layers.
– We choose a given level of abstraction to suit our
particular needs.
– For instance, if we were trying to track down a timing
problem in the primary memory, we might properly look
at the gate-level architecture of the computer

– This level of abstraction would be inappropriate if we

were trying to find the source of a problem in a
spreadsheet application.
• Defining Software Complexity
• Some of the software systems are not complex. These
are the largely forgettable applications that are
specified, constructed, maintained, and used by the
same person, usually the amateur programmer or the
professional developer.

• Such systems tend to have a very limited purpose and

a very short life span.

• They can be thrown away and replace them with

entirely new software rather than attempt to reuse
them, repair them, or extend their functionality.
• we are interested in the challenges of developing industrial-
strength software.

– the applications that exhibit a very rich set of behaviors.

• for example,

– applications that maintain the integrity of hundreds of thousands of

records of information while allowing concurrent updates and queries;

– systems for the command and control of real-world entities, such as the
routing of air or railway traffic.

Software systems such as these tend to have a long life span, and
over time, many users come to depend on their proper
functioning.
• The characteristic of industrial-strength software is that
– it is intensely difficult,
– the complexity of such systems exceeds the human intellectual capacity.

• This complexity is an essential property of all large software systems.

– Essential means that it may be mastered, but we can never make it go away.
 Why Software Is Inherently Complex

“The complexity of software is an essential property it

derives from four elements:

• The complexity of the problem domain.

• The difficulty of managing the development process.
• The flexibility possible through software.
• The problems of characterizing the behavior of discrete systems.
 The Complexity of the Problem Domain

• The problems solved in software often involve elements of

inescapable complexity, in which there are a myriad of competing,
perhaps even contradictory requirements.

• Example:
• Consider the requirements for the electronic system of a multiengine
aircraft, a cellular phone switching system, or an autonomous robot.

• The raw functionality of such systems is difficult enough to

comprehend
 The Complexity of the Problem Domain

• Now add all of the (often implicit) nonfunctional requirements

such as usability, performance, cost, survivability, and reliability.
This external complexity causes the arbitrary complexity.

• This external complexity usually springs from the “communication

gap” that exists between the users of a system and its developers:
Users generally find it very hard to give precise expression to their
needs in a form that developers can understand.

• In some cases, users may have only vague ideas of what they want
in a software system. This is not so much the fault of either the
users or the developers of a system; rather, it occurs because each
group generally lacks expertise in the domain of the other.
 The Complexity of the Problem Domain

• Users and developers have different perspectives on the nature of

the problem and make different assumptions regarding the nature of
the solution.

• Actually, even if users had perfect knowledge of their needs, we

currently have few instruments for precisely capturing these
requirements.
The Complexity of the Problem Domain
.
• The common way to express requirements is with large volumes of
text, occasionally accompanied by a few drawings.

– Such documents are difficult to comprehend,

– are open to varying interpretations, and
– too often contain elements that are designs rather than essential
requirements.

• A further complication is that the requirements of a software

system often change during its development.
The Difficulty of Managing the Development Process

• The fundamental task of the software development team is to

engineer the illusion of simplicity - to shield users from this vast and
arbitrary external complexity.

• use of a team of developers, however, no matter what its size, there

are always significant challenges associated with team development.

• Having more developers means more complex communication and

hence more difficult coordination, particularly if the team is
geographically dispersed, as is often the case.

• With a team of developers, the key management challenge is always

to maintain a unity and integrity of design.
The task of the software development team is to engineer the illusion of
simplicity.
The Flexibility Possible through Software

• Software offers the ultimate flexibility, so it is possible for a

developer to express almost any kind of abstraction.

• This flexibility forces the developer to craft all the primitive

building blocks on which these higher-level abstractions stand.
The Problems of Characterizing the Behavior of Discrete
Systems

• a large application has:

– hundreds or even thousands of variables
– more than one thread of control.
• The present state of the application constitutes:
The collection of these variables
Their current value
The current address
The calling stack of each process

• Because we execute our software on digital computers, we

have a system with discrete states.
• Discrete systems have

– a finite number of possible states;

– in large systems, there is a combinatorial explosion that
makes this number very large.
– an external event may corrupt the state of a system if its
designers didn’t take into account certain interactions
among events.
The Five Attributes of a Complex System

There are five attributes common to all complex systems.

1. Hierarchic Structure

• Many complex systems have a nearly decomposable, hierarchic

structure which is a major facilitating factor enabling us to
understand, describe, and even ‘see’ such systems and their
parts”

• The architecture of a complex system is a function of its

components as well as the hierarchic relationships among these
components.
The architecture of a complex system is a function of its components as well as the hierarchic
relationships among these components.
Relative Primitives

• The choice of the primitive components in a system

is arbitrary and is up to the discretion of the
observer of the system.

• What is primitive for one observer may be at a

much higher level of abstraction for another.
Separation of Concerns

– Hierarchic systems are nearly decomposable because

they can be divided into identifiable parts; nearly
decomposable means their parts are not completely
independent.

– It leads to another attribute common to all complex

systems:
– Intracomponent linkages: are generally stronger than
intercomponent linkages.
Common Patterns

• complex systems have common patterns.

• These patterns may involve the reuse of small
components.
Stable Intermediate Forms

• complex systems evolve over time.

• complex systems evolve from simple systems much more rapidly if

there are stable intermediate forms.

• A complex system designed from scratch never works and cannot

be patched up to make it work.

• As systems evolve, objects that were once considered complex

become the primitive objects on which more complex systems are
built.

• We can never craft these primitive objects correctly the first time:
We must use them in context first and then improve them over
time as we learn more about the real behavior of the system.
• The discovery of common abstractions facilitates our
understanding of complex systems.

– For example, with just a few minutes of orientation, an

experienced pilot can step into a multiengine jet aircraft he
or she has never flown before and safely fly the vehicle.

– Having recognized the properties common to all such

aircraft, the pilot primarily needs to learn what properties
are unique to that particular aircraft
• Complex systems have more than one hierarchy;

– Part of
– Is a

– For example, an aircraft may be studied by decomposing

it into its propulsion system, flight-control system, and
so on.
– This decomposition represents a structural, or “part of”
hierarchy.
• The second hierarchy is an “is a” hierarchy.

– For example, a turbofan engine is a specific kind of jet

engine.
– Hence, a jet engine represents a generalization of the
properties common to every kind of jet engine;
– a turbofan engine is simply a specialized kind of jet engine,
with properties that distinguish it, for example, from ramjet
engines.

• It is essential to view a system from both perspectives,

– the “is a” hierarchy and
– the “part of” hierarchy
• Which class or object is chosen as primitive is relative
to the problem at hand.

• Looking inside any given level reveals yet another level

of complexity.

• Among the parts of the object structure, there are close

collaborations among objects at the same level of
abstraction.

Collectively, class and object structures of a system are

called its architecture.
• The Role of Decomposition

– “The technique of mastering complexity:

• divide and rule

• To design a complex software system:

– decompose it into smaller and smaller parts
– refine each of them independently.
 Algorithmic Decomposition

Each module in the system is a major step in the overall process.

 Object-Oriented Decomposition
Decomposing the system according to the key abstractions in the
problem domain rather than decomposing the problem into steps.
Both designs solve the same problem, but in
different ways.
• In object oriented decomposition, we view the world as
a set of autonomous agents that collaborate to perform
some higher-level behavior.

• Get Formatted Update: This does not exist as an

independent algorithm; rather, it is an operation
associated with the object File of Updates.

• Calling this operation creates another object, Update

to Card.

• In this manner, each object in our solution embodies its

own unique behavior, and each one models some
object in the real world.
• From this perspective, an object is simply a tangible
entity that exhibits some well-defined behavior.

• Objects do things, and we ask them to perform

what they do by sending them messages.

• Because this decomposition is based on objects and

not algorithms, this is an object-oriented
decomposition.
 Algorithmic versus Object-Oriented
Decomposition

Which is the right way to decompose a complex

system—

by algorithms or by objects?
 Algorithmic versus Object-Oriented
Decomposition

• Both views are important

• The algorithmic view highlights the ordering of events.
• The object-oriented view emphasizes the agents that either
cause action or are the subjects on which these operations
act.
• But, we cannot construct a complex system in both ways
simultaneously.
 Advantages of Object-oriented decomposition over
algorithmic decomposition.
• Object-oriented approach is better at helping us organize the
inherent complexity of software systems.

• Object-oriented decomposition yields smaller systems through

the reuse of common mechanisms.

• More resilient to change.

• Better able to evolve over time because their design is based on

stable intermediate forms.

• This decomposition reduces the risk of building complex software

systems because they are designed to evolve incrementally from
smaller systems in which we already have confidence.
 The Role of Abstraction

• A powerful technique for dealing with complexity is

abstraction, which means to ignore its inessential details,
dealing instead with the generalized, idealized model of the
object”

• Example:
When studying how photosynthesis works in a plant, we can
focus on the chemical reactions in certain cells in a leaf and
ignore all other parts, such as the roots and stems.
 The Role of Hierarchy

• The class and object hierarchies within a complex software

system.

• The object structure is important because it illustrates how

different objects collaborate with one another.

• The class structure is equally important because it highlights

common structure and behavior within a system.

• Example: Thus, rather than study each individual

photosynthesizing cell within a specific plant leaf, it is enough
to study one such cell because we expect that all others will
exhibit similar behavior.
 The Role of Hierarchy
• Each instance of a particular kind of object is distinct, but it
shares the same behavior as all other instances of that
same kind of object.

• By classifying objects into groups of related abstractions

(e.g., kinds of plant cells versus animal cells), we explicitly
distinguish the common and distinct properties of different
objects.