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

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

Teaching Points: n Why OO Analysis and Design? n Why UML? n Three tools for coping with complexity n Abstract Data Types and Modularization n Information Hiding

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

Software Characteristics 2. Software doesn=t wear out –Failure rate for hardware follows a classic curve –Software is not subject to environmental maladies that cause wear out

Software Characteristics n 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

Managing Complexity in Software n 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)

Managing Complexity in Software n Difficulty in managing the Development Process –large problems lead to large development teams –more developers means complex communication

Managing Complexity in Software n Flexibility Possible Through Software –software houses capable of building any building block... so they do –no standard building codes

Managing Complexity in Software n Behaviour of Discrete Systems –continuous vs. Discrete system –(eg. Bouncing ball as a system)

How to Cope? n Three Tools –Decomposition –Hierarchy –Abstraction

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

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

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

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

Abstraction Examples n business organization chart n virtual machine n character based I/O n graphics objects

1st and Early 2nd Generation Languages n abstractions: formula n design paradigm: monolithic little support for separation of data

First Generation

Late 1st - Early 2nd Generation

Late 2nd and Early 3rd- Generation Programming Languages n ALGOL 60, Lisp, FORTRAN II, PL/1 n parameter passing mechanisms n structured programming (blocks, nesting, scope)

Late 2nd and Early 3rd- Generation Programming Languages n abstraction: procedures n design paradigm: procedural decomposition, structured design

Late 2nd - Early 3rd Generation

Data Flow Diagram

Structure Chart (call graph)

Must Reduce n complexity n vulnerability to change in design or requirement

Late 3rd Generation Languages n Pascal, Simula, C n separately compiled modules n often not strongly typed (but typed), unchecked calling semantics n can be used for information-hiding

Late 3rd Generation Languages n abstraction: modules n design paradigm: decide on information to be hidden; hide data in modules

Late 3rd Generation

Object-Based and Object- Oriented Programming Languages n Ada, Smalltalk, Object Pascal, C++ n abstract data types n strong typing (in some languages) n little global data

Object-Based and Object- Oriented Programming Languages n abstraction: abstract data type n design paradigm: define types, provide operations for types, exploit commonality

A New Modularization n based on abstract data types (classes) –encapsulation (data hiding) –abstraction (interface)

An Object n An instance of an abstract data type –State –Behaviour –Identity

Object-based/Object-oriented Languages

New Design Paradigm n Set of Collaborating Objects

Teaching Points: n Why OO Analysis and Design? n Why UML? n Three tools for coping with complexity n Abstract Data Types and Modularization n Information Hiding