Complexity

1
Lesson 1

• Complexity

2
Characteristics of Complex Software Systems

• Industrial-strength software systems have the
  following characteristics
• Non-trivial.
• Very rich set of behaviors
• Long life span.
• Relied upon by many users.
• Correct functioning is crucial errors may have
  disastrous effects.

3
Characteristics... (continued)

• Complexity of the system exceeds our intellectual
  capacity i.e. it is difficult for an individual
  developer to comprehend the entire system at once.

4
Characteristics... (continued)

• Complexity is an essential property of large
  software systems
• We need disciplined methods to deal with
  complexity
• Structured analysis and design.
• Object-oriented methodologies.

5
Why is Software Inherently Complex?

• Complexity of the problem domain
• There are a large number of functional
  requirements, each of which may be difficult to
  comprehend, and together form a complex system.
• Constraints such as usability, performance, cost,
  survivability and reliability creates more
  complexity.
• Functional requirements evolve over time.

6
Why (continued)

• Difficulties in managing software development
• Large systems require a large amount of code
  (sometimes millions of lines).
• The amount of work requires a team of developers.
• It is hard to coordinate a large team so that the
  systems design retains its unity and integrity.

7
Why (continued)

• The flexibility possible in software
• Code reuse is rather rare, especially compared to
  component reuse in industries such as
  construction and manufacturing.
• The developer usually builds all parts of the
  system, from primitive building blocks to
  high-level abstractions.
• Is labor-intensive, and leads to a lack of
  standardized components.

8
Why (continued)

• A collection of standardized components would
  lead to a collective mastery of complexity.
• Software is easy to change
• Often destroys the integrity of the design, or
  adds new complexity.
• Change may introduce new errors.
• Change must be managed and controlled.

9
Why (continued)

• Unpredictable behavior of discrete systems
• Unlike continuous systems, a small error (bug)
  might produce a wildly unpredictable effect.
• The number of discrete states in a software
  system is huge
• Exhaustive testing is usually impossible.
• Testing of subsystems leads to only acceptable
  levels of confidence in the correctness of the
  whole system.

10
Why (continued)

• Our failure to master complexity results in
  projects that are
• late
• over budget
• dont fulfill their requirements
• are difficult to evolve
• This is known as the software crisis.

11
Why (continued)

• We can learn from other disciplines where
  successful, complex systems are routinely built.

12
Attributes of a Complex System

• Complex systems usually have a hierarchical
  structure.
• Are composed of subsystems, which in turn are
  composed of lower-level subsystems, and so on to
  elementary component parts.
• Allows us to decompose and understand complex
  systems.
• System functionality is due to the function of
  individual components, plus the relationships
  between components.

13
Attributes (continued)

• The depth of the hierarchy is arbitrary, and
  depends on the discretion of the observer.
• Components considered primitive for one observer
  may be a high-level abstraction for another.
• Intracomponent linkages are stronger than
  intercomponent linkages.
• Components are highly cohesive and loosely
  coupled.

14
Attributes (continued)

• Hierarchical systems are usually composed of only
  a few different kinds of subsystems in various
  combinations.
• Common patterns are used, and small components
  tend to be reused in different subsystems. E.g.
  cells in biological systems.

15
Attributes (continued)

• Complex systems evolve from simple systems that
  work.
• A complex system cannot be built from scratch
  it must be built up from tested, simpler systems.

16
The Canonical Form of a Complex System

• Systems generally consist of at least two
  hierarchies
• Part of hierarchy
• Objects work together to form a system or
  subsystem.
• E.g. a carburetor, pistons, valves, etc. are all
  part of an engine. An engine, chassis,
  transmission, etc. are all part of an
  automobile.
• Often called the object structure.

17
Canonical Form (continued)

• Is a hierarchy
• Objects are specializations of more general kinds
  of objects.
• E.g. a human is a kind of mammal, which is a
  kind of animal.
• Often called the class structure.
• The class structure, object structure, plus the 5
  attributes of complex systems together make up
  the canonical form.

18
(c) 1994 Booch
19
Canonical Form (continued)

• Successful complex systems have well-engineered
  class and object structures.
• The class and object structures together form an
  object-oriented architecture.

20
Decomposition

• The division of a system into smaller parts, each
  of which is then refined independently ( divide
  and rule).
• An important tool for mastering complexity.
• Algorithmic decomposition
• Breaks the problem down into a series of steps.
• Highlights the ordering of events (i.e. focuses
  on process).

21
(c) 1994 Booch
22
Decomposition (continued)

• Object-oriented decomposition
• Views a system as a set of autonomous agents
  (objects) that collaborate to perform some higher
  level behavior.
• Objects do things (exhibit well-defined
  behavior).
• Objects do these things when asked by sending
  them a message.

23
Decomposition (continued)

• Objects collaborate by passing messages back and
  forth.
• Can be agents that cause an action (send a
  message)
• Can be subjects that are acted upon (receive a
  message).

24
(c) 1994 Booch
25
Decomposition (continued)

• Object-oriented decomposition is preferred
• It results in smaller systems because common
  mechanisms are reused.
• Object-oriented systems are easier to change
  because their design is based upon stable,
  intermediate forms.
• The risk of developing complex systems is
  reduced, because they are based on smaller,
  tested systems.

26
Decomposition (continued)

• An object-oriented decomposition usually maps
  very cleanly to the problem domain.
• Can act as a framework for other kinds of
  decomposition.

27
Abstraction

• The process of ignoring unimportant details in
  order to focus on a general, idealized model of a
  complex entity.
• Allows us to simplify and comprehend complexity.
• An object-oriented view of the world provides a
  powerful framework for abstraction objects are
  small, self-contained units of abstraction.

28
Hierarchy

• Allows us to organize our abstractions so we can
  simplify and comprehend complex systems.
• Class and object hierarchies are explicitly
  discovered and constructed in object-oriented
  analysis and design.

29
Features of Software Design Methods

• Categories of analysis and design methods
• Top-down structured design
• Data-driven design
• Object-oriented design
• Design Method a disciplined approach used to
  invent a solution to a problem.
• Provides a path from requirements to
  implementation.

30
Features (continued)

• Purpose is to create a clean and simple internal
  structure or architecture for a system.
• Models
• Are the product of design.
• Are representations of a system to be built.
• Allows us to describe specific aspects of a
  system in explicit detail

31
Features (continued)

• Allows us to test and improve the system before
  building it.
• Several kinds of models are used to provide
  different views of the system.
• Elements of software design methods
• Notation means for expressing a model (graphics
  and/or text).
• Process ordered set of activities for building
  system models.

32
Features (continued)

• Tools software for building models, which check
  for errors and inconsistencies.
• Object-oriented development models
• An object-oriented decomposition can be expressed
  with four models
• Logical model
• Physical model
• Static model
• Dynamic model

33
(c) 1994 Booch
34
This presentation is based on the following book
Object Oriented Analysis and Design by G.Booch
and partially compiled by Leonard Manzara.