1. Lecture 8&9 11/2/16 Introduction to OO Concepts 1

2. Accessing an Object’s data The only way that a program can read or change the data carried by an object, or access the data in any way at all is by invoking one of the defined pieces of program code that the object carries within itself 2

3. This can be illustrated with a Taylor Donut Diagram Change Address Print Balance List all Update Balance Change Phone No Change Name Create Customer Delete Customer Name Joe Address Cork Phone No 555 Balance $1.49 Customer 3

4. Encapsulation As Coad and Yourdon put it, an object encapsulates both “the data, and the exclusive functions on that data” By “exclusive” we mean that no other code can access or manipulate this data 4

5. Hiding changes Nothing outside this class needs to be touched Advantages The complexity of the interface is hidden within the interface object All the interface processing is hidden, And can be changed to handle changes such as the communications medium.... Without upsetting the rest of the system 5

6. Encapsulation In the real world, we need… Consistency in the published interface Hide the details The complexity is enclosed within the product Leaving a small, easily-understood set of commands to operate it. 6

7. Encapsulation In the Data world… We hide both data and program code within the object Giving a level of encapsulation better than ever before Leading to Stability and Portability 7

8. Encapsulation There should be a “crisp” boundary between what is inside the object and what is outside it, Crossed only by the narrow published interface 8

9. An Object has “behaviour” In the real world there are things an object can do or have done to it This is called an object’s “behaviour” The “behaviours” around the outside are subroutines or functions They physically are pieces of compiled program code 9

10. Things an object may do These are called variously: Behaviours (esp. at the analysis modelling level) Responsibilities (esp. at the design level) Methods (esp. at the OO Programming level) Functions Operations Services The data in the centre is surrounded and protected by them 10

11. Real-World vs Data-World Objects Mostly, a Data-World Object is a Representation of a Real-World Object Since it carries only the data we need for the job at hand, and the behaviour (program code) for the job at hand this makes it an abstraction of the real-world object 11

12. ERD’s and Object Modelling serve four important functions: Allow us to understand the users’ business quickly and accurately Document the information needs of the users’ business Give the Analyst the tool to understand, document and ultimately control the data Give a template or pattern for database design And they are more effective, and give us better insights and understanding, than any of the earlier methods 12

13. Analysis Process: RDBMS vs OO Finding objects is similar to identifying entities “No one right model” is also true for both but OO includes methods in model 13

14. Object vs. Entity approach: Purchase Order 14

15. Purchase Order: Entity approach Table 1 Table 2 Table 3 15

16. Purchase Order: Object approach Purchase Order Attributes Methods Calculate total Qty, Item, Price Subject 1 16

17. Purchase Order: Object approach Purchase Order Attributes Methods Vendor Attributes Methods Item Attributes Methods Calculate total Qty, Item, Price Price Create PO Subject 1Subject 2 17

18. Purchase Order: Object approach Vendor Name :SSS Address :6103 State : OH Product : 9002a Price :$8.53 Add / delete ite,m Add / delete vendor Modify Item details Change Bank details Change Payment terms Create PO Collect Payment On PO Ship goods Against PO An object encapsulates both the data and the exclusive functions of that data 18

19. Purchase Order: Object approach Vendor Attributes Methods Add / delete item Modify Item Details Create PO Ship item … Name Address State Items … An object encapsulates both the data and the exclusive functions of that data 19

20. Jacobson’s Three Types of Objects (1) Entity Objects (2) Interface Objects (3) Control Objects 20

21. Entity Objects (1) Entity Objects: three kinds (a) Concrete objects (b) Conceptual objects (c) Event and State objects 21

22. Concrete Objects (a) Concrete Objects: Solid, tangible and physical Things you can grab hold of… These are easily understood by both analysts and users 22

23. Conceptual Objects (b) Conceptual Objects: Intangible, nonphysical More difficult for users to grasp But they are still things and objects Typically defined in terms of other object classes... 23

24. Event and State Objects (c) Event and State Objects: Also very abstract in nature When an Event occurs, some object will change its State When a business event occurs, it is documented, and that is a fact we must record, i.e., it is Data 24

25. Interface Objects (2) Interface Objects: Most software systems need to exchange data with other systems. Other information systems A real-world system controlled by our software Monitoring systems Communications Interfaces Graphical User Interfaces (GUIs) 25

26. Control Objects (3) Control Objects: A method that uses data, and calls other methods, from many different objects and classes These methods don’t easily fit or don’t logically belong in any of our entity classes or interface classes 26

27. So we create a class just to have somewhere to put this method This we call a Control Class Control Objects (cont.) 27

28. Control Objects (cont.) Sometimes this control class will have just this one method Nothing else, no attributes, no nothing Other times it will need a few attributes for intermediate results, etc. And perhaps a few other methods 28

29. Traditional vs. OO methodology Traditional or Structured approach based on the idea that a system/software can be thought of as a collection of modules or subsystems (a collection of programs) and sets of isolated data Traditional Systems Development Methodology focuses on what the (whole) system is doing OO approach Objects make up the services offered by the system “Design by contract” 29

30. Data-driven vs. OO methodology Data models capture data requirements of the business Processes work on the data Functional components typically access the same set of data Objects make up the services offered by the system Objects are abstract entities encapsulating data AND associated behaviour Data is “protected” within individual chunks Objects communicate interfaces and messages to access behaviour “Design by contract” interfaces and behaviour offered eg: departments in an organisation 30

31. Objects are Grouped in Classes The role of a class is to define the attributes and methods (the state and behaviour) of its instances The class car, for example, defines the property color Each individual car (object) will have a value for this property, such as "maroon," "yellow" or "white" 31

32. Employee Class John object Jane object Mark object Instances 32

33. Classes and Classification A class is a group of objects with: similar properties (attributes), common behavior (operations), common associations to other objects, and common semantics (i.e., meaning.) 33

34. Objects are Grouped in Classes A class is a blueprint for an object When you “instantiate” an object, you use class as a basis for the object to be built A bicycle is an object The blueprint is the class In a relational database the definition of the table (fields, description and data types) is a class the rows of the table (data) are objects 34

35. A Class is an Object Template or an Object Factory 35

36. Subclasses Some instances of a class may be grouped together on the basis of features not shared by the rest of the class Attributes Behavior Associations Key verb is: “ISAKINDA” 36

37. Class Hierarchy An object-oriented system organizes classes into subclass- superclass hierarchies At the top of the hierarchy are the most general classes and at the bottom are the most specific 37

38. Class Hierarchy A subclass inherits all of the properties and methods defined in its superclass 38

39. Subclasses - Example In our company, does a Customer have a name? Yes But Why? Because a Customer is a (isakinda) person, and people have names Does a Customer have a Wage Rate? No, only Employee-type people have one of those 39

40. Balance Amount Overdue 30 days Amount Overdue 60 days Amount Overdue 90 days Credit Rating Date of Last Payment Balance Amount Overdue 30 days Amount Overdue 60 days Amount Overdue 90 days Credit Rating Date of Last Payment Name Address Phone Date of Birth Sex Name Address Phone Date of Birth Sex PPS Marital Status Number of Dependants Date Hired Wage Rate PPS Marital Status Number of Dependants Date Hired Wage Rate Overlapping Sets of Attributes Customer Attributes Customer Attributes Person Attributes Person Attributes Employee Attributes Employee Attributes 40

41. Venn diagram of ATTRIBUTES CUSTOMER ATTRIBUTES EMPLOYEE ATTRIBUTES PEOPLE ATTRIBUTES 41

42. Venn diagram of INSTANCES PEOPLE CUSTOMERS EMPLOYEES 42

43. Sample Use Case description - full 43