MANAGING COMPLEXITY

1
MANAGING COMPLEXITY

• Lecture OO01
• Introduction to Object-oriented Analysis and
  Design
• Abstract Data Types

2
References

• Ambler, S., The Object Primer, Cambridge Univ.
  Press, 2001, Chapter 1 2.
• Booch, G., Object-oriented Analysis and Design,
  Benjamin Cumings, 1994, Chapter 1.

3
Teaching Points

• Why OO Analysis and Design?
• Why UML?
• Three tools for coping with complexity
• Abstract Data Types and Modularization
• Information Hiding

4
Software Characteristics

• 1. Software is developed or engineered, it is
  not manufactured in the classical sense.
• Software is not manufactured
• Different use of people

5
Software Characteristics

• 2. Software doesnt wear out
• Failure rate for hardware follows a classic
  bathtub curve
• Software is not subject to environmental maladies
  that cause wear out

6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
Software Characteristics

• 3. Most software is custom-built, rather than
  being assembled from existing components.
• Presently few applications with catalogues of
  software components
• software usually comes off-the-shelf only as a
  complete unit
• no standard building codes

10
Managing Complexity in Software

• The complexity of the problem domain
• large number of competing, even contradictory
  requirements
• users and developers have problems in mutual
  understanding
• requirements change (often as a result of
  software development)

11
Managing Complexity in Software

• Difficulty in managing the Development Process
• large problems lead to large development teams
• more developers means complex communication

12
Managing Complexity in Software

• Flexibility Possible Through Software
• software houses capable of building any building
  block ... so they do
• no standard building codes

13
Managing Complexity in Software

• Behaviour of Discrete Systems
• continuous vs. Discrete system
• (eg. Bouncing ball as a system)

14
How to Cope?

• Three Tools
• Decomposition
• Hierarchy
• Abstraction

15
Decomposition

• breaks the problem into understandable components
• allows elements of an organization to work on
  small chunks of the system

16
Decomposition

• can limit flexibility by producing well defined
  (possibly reusable) building blocks
• opens the possibility for separation of issues
  allowing isolation of the state space
• Coupling vs. Cohesion

17
Hierarchy

• allows understanding of relationships between
  small numbers of components
• different kinds of hierarchies allow insight into
  different aspects of the complex system

18
Abstraction

• probably the most important of the three tools
• the overlooking of unimportant detail
• concentration upon the essential features of an
  idea

19
Abstraction Examples

• business organization chart
• virtual machine
• character based I/O
• graphics objects

20
1st and Early 2nd Generation Languages

• abstractions formula
• design paradigm monolithic little support for
  separation of data

21
First Generation
22
Late 1st - Early 2nd Generation
23
Late 2nd and Early 3rd-Generation Programming
Languages

• ALGOL 60, Lisp, FORTRAN II, PL/1
• parameter passing mechanisms
• structured programming (blocks, nesting, scope)

24
Late 2nd and Early 3rd-Generation Programming
Languages

• abstraction procedures
• design paradigm procedural decomposition,
  structured design

25
Late 2nd - Early 3rd Generation
26
Data Flow Diagram
27
Structure Chart (call graph)
28
Must Reduce

• complexity
• vulnerability to change in design or requirement

29
Late 3rd Generation Languages

• Pascal, Simula, C
• separately compiled modules
• often not strongly typed (but typed), unchecked
  calling semantics
• can be used for information-hiding

30
Late 3rd Generation Languages

• abstraction modules
• design paradigm decide on information to be
  hidden hide data in modules

31
Late 3rd Generation
32
Object-Based and Object-Oriented Programming
Languages

• Ada, Smalltalk, Object Pascal, C
• abstract data types
• strong typing (in some languages)
• little global data

33
Object-Based and Object-Oriented Programming
Languages

• abstraction abstract data type
• design paradigm define types, provide operations
  for types, exploit commonality

34
A New Modularization

• based on abstract data types (classes)
• encapsulation (data hiding)
• abstraction (interface)

35
An Object

• An instance of an abstract data type
• State
• Behaviour
• Identity

36
Object-based/Object-oriented Languages
37
New Design Paradigm

• Set of Collaborating Objects

38
Teaching Points

• Why OO Analysis and Design?
• Why UML?
• Three tools for coping with complexity
• Abstract Data Types and Modularization
• Information Hiding