University of Science, VNU-HCM

Faculty of Information Technology

Review:
Object-Oriented Programming
Assoc. Prof. TRAN Minh Triet
Department of Software Engineering
 References

Object-Oriented Analysis and Design with Applications

by Grady Booch et.al., Addison-Wesley, 2007
(chapter 3)

Object-Oriented Analysis and Design

Understanding System Development with UML 2.0
By Mike O’Docherty, John Wiley & Sons, 2005
(chapter 2, chapter 7 – section 7.4)

Course “Mastering Object-Oriented Analysis and Design with UML 2.0”

by IBM Software Group

Course “Object-Oriented Analysis & Design with UML”

by Tran Hanh Nhi, Tran Minh Triet, and Nguyen Van Khiet
Faculty of Information Technology, University of Science, 2008
2
 Operation Visibility

❖ Visibility is used to enforce encapsulation

❖ May be public, protected, or private

Private
operations

Public Protected
operations operations

3
 How Is Visibility Noted?

❖ The following symbols are used to specify export control:

+ Public access
# Protected access
- Private access

Class1
- privateAttribute
+ publicAttribute
# protectedAttribute
- privateOperation ()
+ publicOPeration ()
# protecteOperation ()

4
 Scope

❖ Determines number of instances of the attribute/operation

 Instance: one instance for each class instance

 Classifier: one instance for all class instances

❖ Classifier scope is denoted by underlining the attribute/operation

name

Class1
- classifierScopeAttr
- instanceScopeAttr
+ classifierScopeOp ()
+ instanceScopeOp ()

5
 Example: Scope

Student

- name
- address
- studentID
- nextAvailID : int

+ addSchedule ([in] theSchedule : Schedule, [in] forSemester : Semester)

+ getSchedule ([in] forSemester : Semester) : Schedule
+ hasPrerequisites ([in] forCourseOffering : CourseOffering) : boolean
# passed ([in] theCourseOffering : CourseOffering) : boolean
+ getNextAvailID () : int

6
 Example: Define Operations

<<Interface>>
RegistrationController 0..* ICourseCatalogSystem
1
+ submitSchedule() + getCourseOfferings()
+ saveSchedule() + initialize()
+ getCourseOfferings() : CourseOfferingList
+ getCurrentSchedule ( [in] forStudent : Student, [in] forSemester : Semester) : Schedule
+ deleteCurrentSchedule()
+ new ( [in] forStudentID : String)
+ getStudent ( [in] anID : int) : Student

0..1

+ registrant 0..1

Student

+ getTuition() : double
+ addSchedule ( [in] aSchedule : Schedule)
+ getSchedule ( [in] forSemester : Semester) : Schedule
+ deleteSchedule ( [in] forSemester : Semester)
+ hasPrerequisites ( [in] forCourseOffering : CourseOffering) : boolean
# hasPassed ( [in] aCourseOffering : CourseOffering) : boolean
+ getNextAvailID() : int
+ getStudentID() : int
+ getName() : String
+ getAddress() : String

7
 More Notations…

Regular: a regular class

Italic: an abstract class/an interface
Underlined: an object (not a class)
Name

Regular: a regular attribute

Attribute(s)
Italic: N/A
Underlined: a static attribute
Operation(s)

Regular: a regular operation

Italic: a virtual/override operation
Underlined: a static operation

8
 Define Associations

❖ Purpose
 Refine remaining associations

❖ Things to look for :

 Association vs. Aggregation

 Aggregation vs. Composition

 Attribute vs. Association

 Navigability

 Association class design

 Multiplicity design

9
 What Is an Association?


The semantic relationship between two or more classifiers that
specifies connections among their instances
 A structural relationship, specifying that objects of one thing are
connected to objects of another

<<entity>> <<entity>> <<entity>>

Student Schedule Course

10
 What Is Aggregation?

❖ A special form of association that models a whole-part relationship

between an aggregate (the whole) and its parts

Whole/aggregate Part

<<entity>> <<entity>> <<entity>>

Student Schedule 0..* 0..2 CourseOffering
1 0..*

11
 Association or Aggregation?

❖ If two objects are tightly bound by a whole-part relationship

 The relationship is an aggregation.

Car Door

1 0..2,4
❖ If two objects are usually considered as independent, although they
are often linked
 The relationship is an association.

Car Door

1 0..2,4

When in doubt, use association.

12
 What Is Composition?

❖ A form of aggregation with strong ownership and coincident lifetimes

 The parts cannot survive the whole/aggregate

Whole Part

Whole Part

Composition

13
 Aggregation: Shared vs. Non-shared

❖ Shared Aggregation
Multiplicity > 1

Whole 1..* 0..* Part

❖ Non-shared Aggregation
Multiplicity = 1 Multiplicity = 1

Whole 1 0..* Part Whole 1 0..* Part

Composition
By definition, composition is non-shared aggregation.

14
 Aggregation or Composition?

❖ Consideration
 Lifetimes of Class1 and Class2

Class1 Class2

Aggregation

Class1 Class2

Composition

15
 Example: Composition

1
Student Schedule
0..*

1
RegisterForCoursesForm RegistrationController
1

16
 Attributes vs. Composition

❖ Use composition when

 Properties need independent identities

 Multiple classes have the same properties

 Properties have a complex structure and properties of their own

 Properties have complex behavior of their own

 Properties have relationships of their own

❖ Otherwise use attributes

17
 Example: Attributes vs. Composition

Attribute
Student
Schedule
- name
- address - semester : Semester
- nextAvailID : int
1 + submit ()
- StudentID : int
- dateofBirth : Date + //save ()
0..*
# any conflicts? ()
+ addSchedule () + //create with offerings ()
+ getSchedule () + new ()
+ delete Schedule () Composition of + passed ()
+ hasPrerequisites () separate class
# hasPassed ()

18
 Review: What Is Navigability?

❖ Indicates that it is possible to navigate from an associating class to

the target class using the association

<<Control>>
RegistrationController

Schedule CourseOffering

19
 Navigability: Which Directions Are Needed?

❖ Explore interaction diagrams

❖ Even when both directions seem required, one may work
 Navigability in one direction is infrequent

 Number of instances of one class is small

Schedule + primaryCourses CourseOffering

0..* 0..4

?
Schedule + primaryCourses CourseOffering Schedule + primaryCourses CourseOffering

0..* 0..4 0..* 0..4

20
 Example: Navigability Refinement

❖ Total number of Schedules

is small, or Schedule + primaryCourses CourseOffering
❖ Never need a list of the 0..* 0..4
Schedules on which the
CourseOffering appears

❖ Total number of
CourseOfferings is small, or
Schedule + primaryCourses CourseOffering
❖ Never need a list of
CourseOfferings on a 0..* 0..4

Schedule

❖ Total number of
CourseOfferings and Schedule + primaryCourses CourseOffering
Schedules are not small 0..* 0..4
❖ Must be able to navigate in
both directions
21
 Association Class

<<entity>>
❖ A class is “attached” to an ScheduleOfferingInfo
- status
association
+ // is selected ()
❖ Contains properties of a + // mark as selected ()
+ // mark as cancelled ()
relationship
❖ Has one instance per link
0..* + alternateCourses 0..2
Schedule CourseOffering
0..* + primaryCourses 0..4

<<entity>>
PrimaryScheduleOfferingInfo
- grade

+ // is enrolled in? ()
+ // mark as enrolled in ()
+ // mark as committed ()

22
 What Are Roles?

❖ The “face” that a class plays in the association

<<entity>> <<entity>> <<entity>>

CourseOffering Instructor Professor Department
Department Head

Role Name
<<entity>>
Course

Prerequisites

23
Example: Association Class Design

0..* + alternateCourses 0..2

Schedule CourseOffering
0..* + primaryCourses 0..4

PrimaryScheduleOfferingInfo
- grade
+ // is enrolled in? ()
+ // mark as enrolled in ()
+ // mark as committed ()

Design Decisions

0..* + alternateCourses 0..2

Schedule CourseOffering

1
1
- theCourseOffering 0..*
0..4
- primaryCourseOfferingInfo PrimaryScheduleOfferingInfo
- grade
+ // is enrolled in? ()
+ // mark as enrolled in ()
+ // mark as committed ()

24
 Multiplicity Design

❖ Multiplicity = 1, or Multiplicity = 0..1

 May be implemented directly as a simple value or pointer
 No further “design” is required

Professor 0..1 0..* CourseOffering

+ Instructor

❖ Multiplicity > 1
 Cannot use a simple value or pointer
 Further “design” may be required

Needs a
Professor 0..1 0..* CourseOffering
container for
+ Instructor
CourseOfferings

25
 Multiplicity Design Options

Professor 0..1 0..* CourseOffering

+ Instructor

Detail Container via Note

Explicit Modeling of a Container Class

Professor 0..1 0..* CourseOfferingList

List
+ Instructor

CourseOffering Professor 0..1 0..* CourseOffering

+ Instructor

26
 Multiplicity Design: Optionality

❖ If a link is optional, make sure to include an operation to test for the

existence of the link

Professor 0..1 CourseOffering

0..*
+ isTeaching () : boolean + hasProfessor () : boolean

27
 What Does Multiplicity Mean?

❖ Multiplicity answers two questions:

 Is the association mandatory or optional?

 What is the minimum and maximum number of instances that can be

linked to one instance?

<<entity>> <<entity>>
0..* 1
CourseOffering Course

0..*

Prerequisites 0..3

28
 Define Dependency

❖ What Is a Dependency?
 A relationship between two objects

Client Supplier

❖ Purpose
 Determine where structural relationships are NOT required

❖ Things to look for :

 What causes the supplier to be visible to the client

29
 Dependencies vs. Associations

❖ Associations are structural relationships

❖ Dependencies are non-structural relationships Supplier2
❖ In order for objects to “know each other”
they must be visible
 Local variable reference

 Parameter reference Dependency Client

 Global reference

 Field reference
Association

Supplier1

30
 Associations vs. Dependencies in Collaborations

❖ An instance of an association is a link

 All links become associations unless they have global, local, or

parameter visibility
 Relationships are context-dependent

❖ Dependencies are transient links with:

 A limited duration

 A context-independent relationship

 A summary relationship

A dependency is a secondary type of relationship in that it doesn't tell

you much about the relationship. For details you need to consult the
collaborations.

31
 Local Variable Visibility

❖ The op1() operation contains a local variable of type ClassB

ClassA

+ op1 ( )

ClassB

32
 Parameter Visibility

❖ The ClassB instance is passed to the ClassA instance

ClassA

+ op1 ( [in] aParam : ClassB )

ClassB

33
 Global Visibility

❖ The ClassUtility instance is visible because it is global

ClassA

+ op1 ( )

ClassB

+ utilityOp ( )

34
 Identifying Dependencies: Considerations

❖ Permanent relationships — Association (field visibility)

❖ Transient relationships — Dependency
 Multiple objects share the same instance
▪ Pass instance as a parameter (parameter visibility)
▪ Make instance a managed global (global visibility)
 Multiple objects don’t share the same instance (local visibility)
❖ How long does it take to create/destroy?
 Expensive? Use field, parameter, or global visibility
 Strive for the lightest relationships possible

35
 Example: Define Dependencies (before)

<<interface>>
RegistrationController ICourseCatalogSystem
0..* 1

+ // submit schedule () + courseCatalog + getCourseOfferings ( [in] forSemester : Semester) : CourseOfferingList

+ // save schedule ()
+ // create schedule with offerings ()
+ // get course offerings ()
0..1 Schedule
0..1
- semester : Semester
0..1
+ submit ()
+ currentSchedule + //save ()
# any conflicts? ()
+ //create with offerings()
0..*
0..* 0..*
0..1 + registrant 1
alternateCourses + primaryCourses
0..2 0..4
Student
CourseOffering
- name
- address
- StudentID : int - number : String = "100"
- startTime : Time
+ addSchedule ( [in] aSchedule : Schedule ) - endTime : Time
+ getSchedule ( [in] forSemester : Semester ) : Schedule - day : String
+ hasPrerequisites ( [in] forCourseOffering : CourseOffering ) : boolean
# passed ( [in] aCourseOffering : CourseOffering ) : boolean + addStudent ( [in] aStudentSchedule : Schedule)
+ removeStudent ( [in] aStudentSchedule : Schedule)
+ new ()
+ setData () 36
 Example: Define Dependencies (after)

<<interface>>
RegistrationController ICourseCatalogSystem

+ // submit schedule () + getCourseOfferings ( [in] forSemester : Semester) : CourseOfferingList

+ // save schedule ()
+ // create schedule with offerings ()
+ // get course offerings ()
Global visibility
0..1 Schedule
0..1
- semester : Semester
0..1
+ submit ()
+ currentSchedule + //save ()
Field visibility # any conflicts? () Field
+ //create with offerings()
0..*
visibility
0..* 0..*
0..1 + registrant 1
alternateCourses
0..2 0..4 + primaryCourses
Student
CourseOffering
- name
- address
- StudentID : int - number : String = "100"
- startTime : Time
+ addSchedule ( [in] aSchedule : Schedule ) - endTime : Time
+ getSchedule ( [in] forSemester : Semester ) : Schedule - day : String
+ hasPrerequisites ( [in] forCourseOffering : CourseOffering ) : boolean
# passed ( [in] aCourseOffering : CourseOffering ) : boolean + addStudent ( [in] aStudentSchedule : Schedule)
+ removeStudent ( [in] aStudentSchedule : Schedule)
+ new ()
+ setData ()
Parameter visibility 37