Lecture 8: Objects/Classes Class Diagram

1
Lecture 8Objects/ClassesClass Diagram
MIS 210Information Systems I
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.

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.

4
Objects

• It is Something in the users 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.

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?)

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

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.

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

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.

10
Identity

• A child has identity from the moment of birth, or
  perhaps before.
• It doesnt 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 dont.

11
Encapsulation

• Encapsulation means an objects 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

12
Encapsulation

• Do you know how to drive a car?
• Do you know how everything works under the hood?
• The correct answer is. . .

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.

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

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.

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.

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.

18
Polymorphism

• Polymorphism the same message can elicit a
  different response depending on the receiver

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

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

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.

22
Classes or Instances?

• Many people use object to refer to a class.
• Strictly, as used in UML, an object is an
  Instance.

23
Responsibilities and Collaborations

• Responsibilities
• Knowing
• Doing
• Collaboration
• Objects working together to service a request

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

25
Class Components

• Name
• Attributes
• Services

Customer CustIdNum FirstName LastName etc... Acces
sAccount DebitAccount GetAccountBal etc...
What it knows about itself
What it can do
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

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
28
Subclasses
In our company, does a Customer have a name?

• Yes, of course!
• But Why?
• Because a Customer is a person, and
  people have names.
• Does a Customer have a Wage Rate?
• No, only Employee-type people have one of those!

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

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
32
Multiple Inheritance

• Subclass inherits from more than one superclass

Audio
Video
DVD Player
33
Repeated Inheritance

• Superclasses inherit from a higher level
  superclass

Electronic Equipment
Video
Audio
DVD Player
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

35
Generalization/Specialization
Customer
Name Address Phone
DiveCustomer
BoatCustomer
Certificate Certificate Date
Safety Course Completion Date
36
MultipleInheritance andGeneralization
Customer
Name Address Phone
DiveCustomer
BoatCustomer
Safety Course Completion Date
Certificate Certificate Date
DiveBoatCustomer
Certificate Certificate Date
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

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

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
40
Associations
Instructor
Employee No. Name Age Sex Salary
teaches
Course Offering
Student
Course No. Date Room No. Max Enrol
Student No. Name Age Sex
Enrolls In
41
Associations
Instructor
College
Employee No. Name Age Sex Salary
Name Address Phone Rating
Employs
teaches
teaches
Course Offering
Student
Course No. Date Room No. Max Enrol
Student No. Name Age Sex
Enrolls In
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 1M

Instructor
Course Offering
Employee No. Name Age Sex Salary
teaches
Course No. Date Room No. Max Enrol

43
Multiplicity

• And, since we wish many Customers to buy many
  Products, this one is a Many-to-Many association,
  or MM

Customer
A/c No. Name Address Phone No. Balance
Product
buys
Prod No. Description Unit Price Qty in Stock


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
45
Aggregation

• Part-whole relationship
• A whole is equal to the sum of its parts
• Classes are grouped to form an aggregate class

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 1M and MM associations

47
Aggregation versus Association

• Association refers to the relationship between
  dissimilar classes of objects

aggregation
Book
Page
Chapter
association
Customer
48
Aggregation versus Generalization
Car
Door
Wheels
Toyota
Ford
49
Example Class Diagram