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

2. 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.

3. 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

4. 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

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

9. 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

10. 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)

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

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

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

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

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

16. 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

17. 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

18. 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

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

20. 1st and Early 2nd Generation Languages n abstractions: formula n 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 n ALGOL 60, Lisp, FORTRAN II, PL/1 n parameter passing mechanisms n structured programming (blocks, nesting, scope)

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

25. Late 2nd - Early 3rd Generation

26. Data Flow Diagram

27. Structure Chart (call graph)

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

29. 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

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

31. Late 3rd Generation

32. 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

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

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

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

36. Object-based/Object-oriented Languages

37. New Design Paradigm n Set of Collaborating Objects

38. 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