1. The Object Model Nazim H. Madhavji UWO 1(c) N.H. Madhavji, 14 August, 2014

2. Key sources of material Chapter 2, OO Analysis and Design with Applications, 3 rd Ed., Grady Booch, et al., Addison Wesley, 2011. Personal thoughts. 2(c) N.H. Madhavji, 14 August, 2014

3. Key topics covered The Evolution of the Object Model Foundations of the Object Model Elements of the Object Model (c) N.H. Madhavji, 14 August, 20143

4. The Evolution of the Object Model Please read the text book for complementary details; here we shall cover: Algorithmic/Structured languages vs. OO languages 4(c) N.H. Madhavji, 14 August, 2014

5. Algorithmic/Structured languages vs. OO languages Algorithmic languages were so called because “algorithms” (actions, instructions, etc.) were the primary basis underlying the design and code of programs in these languages. OO languages have “objects” and “classes” of objects as the primary basis. 5(c) N.H. Madhavji, 14 August, 2014

6. Algorithmic/Structured languages Programs in algorithmic (a.k.a “structured”) languages (such as Algol 60, Pascal, etc.) were basically tree-structured. Relatively small(er) programs (“programming-in-the-small”). Independent development of parts of the same program manually managed. PROGRAM X (I/O parameters); BEGIN END. 6(c) N.H. Madhavji, 14 August, 2014

7. Modular languages More sophisticated (a.k.a “modular”) languages (such as Modula, Modula-2, Ada, C) facilitated development of a large “system” as a set of “modules”. This suited “programming-in-the-large” – for development by teams. Say, programmer 1 develops module M1, and programmer 2 develops module M2, etc. Modules could be developed independently and concurrently. – Separately compiled – Loaded (integrated) to form a whole system 7(c) N.H. Madhavji, 14 August, 2014

8. Modular languages A module had two parts: interface part and implementation part. The implementation part was hidden from the users of a given module; they could only read/use the interface part. The modules M1 and M2, etc., interacted with each other through their interfaces. A module interface had “exports” and “imports”. Exported items from module M1 need to be declared in the interface part of M1. – Data structures exported showed their internal structure in the interface part. – Procedures/functions exported showed the parameters so that the user of module M1 can make proper calls. 8(c) N.H. Madhavji, 14 August, 2014

9. Modular languages Items imported in module M1 (from module M2, etc.) need to be specified in the interface part of module M1 and must be exported from the exporting module’s interface (M2, etc.). Each module was essentially like a tree- structured Pascal program. 9(c) N.H. Madhavji, 14 August, 2014

10. Interface and Implementation Modules INTERFACE MODULE M1. EXPORT A, B, X; FROM M2 IMPORT P, Q; (*P and Q need to be made visible through the interface of Module M2 *) <visible declarations: A: int; B: real; PROCEDURE X (....); END M1. IMPLEMENTATION MODULE M1. ; Procedure X (....); BEGIN.... END; (*hidden from the user*) BEGIN.... END M1. 10(c) N.H. Madhavji, 14 August, 2014

11. Modular languages and scaling up While modular languages enabled programmers to do independent development (of large-scale systems) and collaborate through module interaction, the increasing domain complexity was still a challenge. – Modules could not be nested so scaling up to very large- scale development was a problem. – Fundamentally, viewing a real-world problem in an algorithmic way was getting more and more difficult as system complexity increased. – There was a need to represent the application domain more directly in the system design in order to handle system complexity. 11(c) N.H. Madhavji, 14 August, 2014

12. From Modular to OO languages Object-oriented languages (e.g., Java, C++) turned this around (to the extent it has been able to) by structuring systems based on classes (as representation of real-world things) and objects as instances of classes. See OO history (Chapter 2) – Algorithms are encapsulated in classes as “operations” (a.k.a methods) on the objects. – Objects in different classes interact with each other through calls (messages) from methods in one class to methods in other classes. – Specialisation (reuse) of a parent class is done through inheritance; this did not exist in modular/structured languages. 12(c) N.H. Madhavji, 14 August, 2014

13. From Modular to OO languages The OO paradigm builds upon the structured paradigm, does not abandon it. – The basic elements of structured languages are all there: declarations, procedures and functions, calls, execution statements, assignment, etc. – However, be warned that different OO language designers have tended to call the same thing differently in different OO languages (Smalltalk, C++, Eiffel, Object Pascal, CLU, Java, etc.). – As programmers in OO languages, you need to know the different terminology used by different OO languages. (For an overview of various OO languages see Appendix A of the book by Booch et al, 3 rd. Ed.). (c) N.H. Madhavji, 14 August, 201413

14. Small to moderate-sized OO programs (c) N.H. Madhavji, 14 August, 201414

15. Large-sized OO systems (c) N.H. Madhavji, 14 August, 201415 Note encapsulation of Small objects (classes) into large objects (packages). Enables scaling up to designing and developing large Systems.

16. Foundations of the Object Model For a historical exposé on the various influencing and concurrent factors in the development of OO languages and paradigm, see Section 2.2 (Foundations of the Object Model), pg. 37-40 in Booch et al., 3 rd ed. We will focus on the meanings of: OO Programming (OOP), OO Design (OOD) and OO Analysis (OOA) (c) N.H. Madhavji, 14 August, 201416

17. OOP -- Object-oriented programming OOP is a way of writing programs organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships. – Object-oriented programming uses objects, not algorithms, as its fundamental logical building blocks (”part of’ hierarchy ). – Each object is an instance of some class. – Classes may be related to one another via inheritance relationships (the “is a” hierarchy). A language that supports the above three elements is an OO language. (c) N.H. Madhavji, 14 August, 201417

18. OOD -- Object-oriented design While OOP emphasises proper and effective use of particular OO *language* mechanisms, OOD emphasises proper and effective *structuring* of a complex system. In this course (cs3307) we are concerned with this latter, design issue. OOD is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design. (c) N.H. Madhavji, 14 August, 201418

19. OOD -- Object-oriented design The difference between OOD and structured design is that OOD uses class and object abstractions to logically structure systems; whereas, structured design uses algorithmic abstractions. (c) N.H. Madhavji, 14 August, 201419

20. OOA -- Object-oriented analysis OOA is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain. Helps identify what should be part of the system and what should not be included, and what interactions system should have with things outside the system. This is also called “boundary analysis”. (c) N.H. Madhavji, 14 August, 201420

21. OO Programming (OOP), OO Design (OOD) and OO Analysis (OOA) (c) N.H. Madhavji, 14 August, 201421 Requirements Engineering Software Design Programming OOAOOD OOP These three notions are all important and complementary in software/systems engineering. OOA produces models used to start OOD the models of which can then be used to implement a system using OOP.

22. Elements of the Object Model There are four fundamental elements of this model: – Abstraction – Encapsulation – Modularity – Hierarchy Without any of these four elements, it is unthinkable to be able to build large OO systems. (c) N.H. Madhavji, 14 August, 201422

23. Elements of the Object Model Three relatively minor elements of this model are: – Typing – Concurrency – Persistence These elements are useful but not essential in all the systems at the design level. (c) N.H. Madhavji, 14 August, 201423

24. Abstraction An abstraction focuses on the outside view of an object and so serves to separate an object’s essential behavior from its implementation. (c) N.H. Madhavji, 14 August, 201424

25. Encapsulation Abstraction and encapsulation are complementary: – Abstraction focuses on the observable behavior of an object – Encapsulation focuses on the implementation that gives rise to this behavior (c) N.H. Madhavji, 14 August, 201425

26. Encapsulation The abstraction of an object should precede the decisions about its implementation. Once an implementation is selected, it should be treated as a secret of the abstraction and hidden from most clients. (c) N.H. Madhavji, 14 August, 201426

27. Encapsulation Encapsulation is achieved through information hiding (not just data hiding): – hides all the secrets of an object that do not necessary for the clients to know: structure of an object is hidden, Implementation of its methods. No part of a complex system should depend on the internal details of any other part”. (c) N.H. Madhavji, 14 August, 201427

28. Modularity Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. – High cohesion within a module. – Low coupling across modules. Modularity and encapsulation go hand in hand. (c) N.H. Madhavji, 14 August, 201428

29. Hierarchy Abstraction, encapsulation and modularity are all useful for dealing with complexity; yet they are not adequate. In complex systems, we end up making a set of abstractions, e.g.: – Person  (Male doctor | Female doctor) – Male doctor  Male & (GP |specialist) (c) N.H. Madhavji, 14 August, 201429

30. Hierarchy A set of abstractions often forms a hierarchy Identifying these hierarchies in our design can help deal with problem complexity. Hierarchy is thus a ranking or ordering of abstractions. (c) N.H. Madhavji, 14 August, 201430

31. Hierarchy Two important hierarchies to note: – class structure (the “is a” hierarchy) – object structure (the “part of’ hierarchy). Single inheritance and Multiple inheritance – “is a” relationship among classes in the hierarchy (c) N.H. Madhavji, 14 August, 201431

32. Typing – Type is a precise characterization of structural or behavioral properties which a collection of entities all share. E.g.: the Integer type (1,2,3....) – Typing is used to enforce constraints on operations. Objects of different types may not be interchanged, or interchanged in very restricted ways. – E.g.: operations on variables of mixed types in an expression – NHM: Data types are important (of course) but they tend to be at the programming (a.o.t. Design) level. (c) N.H. Madhavji, 14 August, 201432

33. Concurrency An automated system may have to handle many different events simultaneously. Other problems may involve computation that exceeds the capacity of any single processor. May need to: – distribute the solution across a set of computers. – Or do multitasking (time-sharing) on a signle computer. May need to model this at design time. (c) N.H. Madhavji, 14 August, 201433

34. Persistence An object takes up space and time during its life. Persistence encompasses the following: – Transient results in expression evaluation – Local variables in procedure activations – Global variables that outlive a procedure’s life – Data that exists between executions of a program – Data that exists between various versions of a program – Data that outlives the program Important to think of these issues in system design. (c) N.H. Madhavji, 14 August, 201434

35. Summary OOA, OOD and OOP address the issues of programming-in-the-large. There are several different programming paradigms: procedure-oriented, object-oriented, logic-oriented, rule-oriented, and constraint- oriented. Key OO system design properties: – Abstraction; Encapsulation; Modularity; Hierarchy Other properties include: Typing, Concurrency and Persistence. (c) N.H. Madhavji, 14 August, 201435