Lecture 8: Objects/Classes Class Diagram - PowerPoint PPT Presentation

lecture 8 objects classes class diagram n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Lecture 8: Objects/Classes Class Diagram PowerPoint Presentation
Download Presentation
Lecture 8: Objects/Classes Class Diagram

play fullscreen
1 / 49
Lecture 8: Objects/Classes Class Diagram
138 Views
Download Presentation
luther
Download Presentation

Lecture 8: Objects/Classes Class Diagram

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. MIS 210Information Systems I Lecture 8:Objects/ClassesClass Diagram Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  2. The Entity Relationship Diagram • The ERD was the first systems analysis tool to focus on data and how it is Linked and Organized. • It was from this that objects then evolved. • An Entity is a thing the users need to know (i.e, record) something about. • An Entity Type is a group or class of entities that are all the same kind of thing. • An Occurrence of an Entity Type is a specific individual thing of the kind the Entity Type describes. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  3. The Entity Relationship Diagram • Attributes are the things we need to know about an Entity. • An Association is the interaction of one or more Entities and is represented by a verb. • These interactions among the Entities (i.e., these associations) show us the paths we need to follow through the database to access the data. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  4. Objects • It is “Something in the user’s world that has a separate and distinct existence, and is of interest in that they need to keep data about it.” • Some private data and a set of operations that can access that data • These operations exclusively access the data it carries - no other code can touch it. • Contains both data (what it knows) and behavior (what it can do) • An Object is an entity with behavior. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  5. THINGS (Objects), etc. • Things… • Car, Train, Elephant, Sale, Invoice, Division, Account, etc. • Physical or Conceptual • Attributes… • Make, Model, Year, • Color, Weight, • Serial Number, License Number • Relationships… • e.g., to a Person object, i.e., the Owner. • Behaviors… • Create • Change Color • Change Owner • Destroy Itself (Suicide?) Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  6. Object • Since an object carries only • The data we need for the job at hand, and • The behavior (program code) for the job at hand • This makes it an abstraction of the real-world object. • Attributes: what an object knows (about itself) • Methods: what an object can do • Identity: each instance is unique, even if very similar Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  7. Attributes: • Each object instance carries a set of attribute values • These represent the data items that a user might need to know about the object at any time • Data types and sizes are defined for the class apply to every instance. • The domain of an attribute is its set of all permissible values. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  8. Methods and Messages • A method is what an object can do; a specific implementation of an operation by a particular object • how it does an operation • An operation (behavior) is an action that an object performs or is subject to • something the object can perform (walk; run) • A message is an operation that one object performs upon another • An operation (behavior) is initiated by sending a messages Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  9. Identity • Defined: The condition or fact that something is itself and not something else. • Two red apples. . . • Each is itself, even though identical to the other. • Identity is inherent in an object. • An object has identity just because it is that object. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  10. Identity • A child has identity from the moment of birth, or perhaps before. • It doesn’t get a name until after its birth. • So an identifier does not confer identity • But simply documents or recognizes identity that already existed. • So do identifiers such as customer numbers, social security numbers, etc. • Remember, only objects have identity, attribute values don’t. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  11. Encapsulation • Encapsulation means an object’s data (attributes) is hidden within, and protected by, a shell of procedures (methods) • Also known as information hiding • Methods allow for hiding of information by concealing the way in which an object satisfies a request • When we send a message, we do not know how or where it will be satisfied • The interface is public; the internals are private • Leading to stability and portability Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  12. Encapsulation • Do you know how to drive a car? • Do you know how everything works under the hood? • The correct answer is. . . Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  13. Encapsulation • What does matter is consistency in the interface. • Every car made these days has the standard pedal layout. • Now we have standard user interfaces (or close) for all kinds of products: Touch phones, keyboards, cars, motorcycles, microwave ovens, thermostats, TV remote controls. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  14. Encapsulation • What all of these do, is HIDE THE DETAILS • The complexity is enclosed within the product • Leaving a small, easily-understood set of commands to operate it. • We hide both data and program code within the object • Giving a level of encapsulation better than ever before, • Leading to stability and portability Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  15. Encapsulation • Stability is improved since once a class is built, it will survive the years with very few changes. • It can be reused in new projects with few changes • Portability is enhanced because only the narrow published interface needs to be learned by the new developers, i.e., the reusers. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  16. Encapsulation • All the attributes and their values should be hidden within the object and accessible only via the methods. • There is a boundary between what is inside the object and what is outside it • Crossed only by the interface. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  17. Encapsulation • Since we have encapsulated all the data and behavior of our system within the classes, we reduce the “ripple effect” of change. • Even though the reduction may be small for each class, remember. . . • The number of possible interactions goes up exponentially with the number of objects. • In a large system this makes a huge difference in maintenance. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  18. Polymorphism • Polymorphism: the same message can elicit a different response depending on the receiver Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  19. Classes 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.) Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  20. Classes • A class is a set of objects that share a common structure (attributes) and a common behavior (methods) • We group objects together on the basis of: • Shared Attributes • Shared behavior • Class of: • All Employees • All Products • All Transactions • An individual object is then a INSTANCE Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  21. Classes Classes perform such things as: • Creating Instances • Holding the program code • Holding the attribute definitions • Data type and size, etc. • Point of contact for associations. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  22. Classes or Instances? Many people use “object” to refer to a class. Strictly, as used in UML, an “object” is an Instance. Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  23. Responsibilities and Collaborations • Responsibilities • Knowing • Doing • Collaboration • Objects working together to service a request Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  24. Class Symbol • Name • should be unambiguous • should be a noun • Attributes (what the class/object knows about itself) attribute name : data type = default value {property string} • Methods method name (parameter-list) : return-type where parameter-list and return-type are specified as attributes Visibility: + public - private # protected Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  25. Class Components • Name • Attributes • Services Customer CustIdNum FirstName LastName etc... AccessAccount DebitAccount GetAccountBal etc... What it knows about itself What it can do Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  26. Class Diagrams • Finding the classes is the core activity of OOSD. • The class diagram describes the classes in the system and the static relationships among them • Similar to ERD -- with methods added • Will be directly implemented in an OOPL • Most important model Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  27. 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” Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  28. Subclasses In our company, does a Customer have a name? • Yes, of course! • But Why? • Because a Customer is a person, and peoplehave names. • Does a Customer have a Wage Rate? • No, only Employee-type people have one of those! Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  29. Overlapping Sets of Attributes Customer Attributes • Balance Owing • Amount Overdue 30 days • Amount Overdue 60 days • Amount Overdue 90 days • Credit Rating • Date of Last Payment Name Name Address Address Phone Phone Date of Birth Date of Birth Sex Sex Person Attributes SIN Marital Status Number of Dependants Date Hired Wage Rate Employee Attributes Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  30. Inheritance • A (top-down) relationship among classes wherein one class shares the structure or behavior defined in one (single inheritance) or more (multiple inheritance) other classes. • Based on a hierarchical (IS-A) relationship • Inheritance is in the “eye of the beholder” Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  31. Single Inheritance • Subclasses inherit from no more than one superclass Student ssn, name Undergrad Graduate Grad advisor Year (F,So,J, S) Compute gpa Compute gpa Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  32. Multiple Inheritance • Subclass inherits from more than one superclass Audio Video DVD Player Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  33. Repeated Inheritance • Superclasses inherit from a higher level superclass Electronic Equipment Audio Video DVD Player Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  34. Generalization • The convention for defining subclasses • Think substitution - anywhere you have the class you can freely use the sub class • For Example, Wherever You Use Customer you can use “Corporate Customer” Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  35. Generalization/Specialization Customer Name Address Phone DiveCustomer BoatCustomer Certificate Certificate Date Safety Course Completion Date Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  36. MultipleInheritance andGeneralization Customer Name Address Phone DiveCustomer BoatCustomer Safety Course Completion Date Certificate Certificate Date Dive&BoatCustomer Certificate Certificate Date Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  37. Navigation • Defines the direction of an association • Line Options • Uni-Directional - “Order Comes From Customer” • Bi-Directional - Two Roles are Inverses of Each Other • No Arrows - Assumed “Unknown” or “Bi-Directional” Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  38. Role • A Label for that direction of the association • Each Association has a Role for Each Direction of the Association • When no Role is Identified, the Role Takes the Name of the Target Class Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  39. Associations • Draw a line joining two class boxes to show a relationship exists • Write the verb above the line. • Add a solid arrowhead so that it makes a sentence when you read it in the direction of the arrow: • “Student enrolls in course Course Offering Student *Student No. Name Age Sex *Course No. *Date Room No. Max Enrol Enrolls In Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  40. Associations Instructor *Employee No. Name Age Sex Salary teaches Course Offering Student *Student No. Name Age Sex *Course No. *Date Room No. Max Enrol Enrolls In Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  41. Associations Instructor College *Employee No. Name Age Sex Salary *Name Address Phone Rating Employs teaches teaches Course Offering Student *Student No. Name Age Sex *Course No. *Date Room No. Max Enrol Enrolls In Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  42. Multiplicity • We diagram this by adding a star (asterisk) below the relationship line whenever it should show “many.” • Read this one as :“Instructor teaches many courses” • This is a “One-to-Many” Association, or 1:M Instructor Course Offering *Employee No. Name Age Sex Salary teaches *Course No. *Date Room No. Max Enrol * Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  43. Multiplicity • And, since we wish many Customers to buy many Products, this one is a Many-to-Many association, or M:M Customer *A/c No. Name Address Phone No. Balance Product buys *Prod No. Description Unit Price Qty in Stock * * Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  44. Multiplicity • How many objects may participate in a given relationship • One Customer can make “one to many” Orders • Multiplicity Notation • * = one to many • 1 = one • 0 = zero • 0..* = zero to many • 1..* = one to many • 2,4 = two or four • 2..4 = two to four Multiplicity Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  45. Aggregation • Part-whole relationship • A whole is equal to the sum of its parts • Classes are grouped to form an aggregate class Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  46. Aggregation • Aggregation is a relationship between two classes where the instances of one class are in some way components, members or contents of the instances of the other class. • These are relationships that appear on the class diagram along with all the subclass hierarchies and the regular 1:M and M:M associations Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  47. Aggregation versus Association Association: refers to the relationship between dissimilar classes of objects aggregation Book Chapter Page association Customer Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  48. Aggregation versus Generalization Car Wheels Door Ford Toyota Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  49. Example Class Diagram Sylnovie Merchant, Ph.D. MIS 210 Fall 2004