SSD3: Object-Oriented Programming and
Design
Object-Oriented Programme 1
Unit 1. Class Design
1.1 Java Application
1.2 Designing Classes
Object-Oriented Programme 2
1.2 Designing Classes
Contents
1.2.1 UML Class Diagrams
1.2.2 Relationships Between Classes
1.2.3 Common Class Structures
1.2.4 UML with Eclipse
1.2.5 Modeling Classes
1.2.6 Modeling the Library System
Assessments
Practical Quiz 3
Practical Quiz 4
Multiple-Choice Quiz 2
Exercise 2
Object-Oriented Programme 3
1.2.1 UML Class Diagrams
Introduction
Class Notation
Object-Oriented Programme 4
Introduction
The Unified Modeling Language (UML) is a graphical
language for
modeling the static and dynamical aspects of a system.
unifies the best engineering practices for modeling
systems
defines different graphical diagrams that provide multiple
perspectives of a system under development
UML is a unification of the methodologies developed by
Grady Booch, James Rumbaugh, and Ivar Jacobsen.
The Object Management Group (OMG), a not-for-profit
organization that promotes the use of object-oriented
technology, has responsibility for the further development of
the UML standard.
Object-Oriented Programme 5
UML Diagrams
Use case diagram ( 用例图 )
Class diagram ( 类图 )
Object diagrams ( 对象图 )
Behavior diagrams:
Statechart diagram ( 状态图 )
Activity diagram ( 活动图 )
Interaction diagrams:
Sequence diagram ( 顺序图 )
Collaboration diagram ( 协作图 )
Implementation diagrams:
Component diagram ( 组件图 )
Deployment diagram ( 部署图 )
Object-Oriented Programme 6
Class Notation 类的表示符号
A class
represented
by a rectangle with three
compartments.
The first compartment contains the name of the class;
the second compartment describes the attributes of the
class;
third compartment describes the methods of the class.
Object-Oriented Programme 7
Sample
From left to right
Representation of class Employee
Abbreviated representation of class Employee
Shortest form of class Employee
Essential representation of class Employee
Object-Oriented Programme 8
1.2.2 Relationships Between Classes
Associations
One-way and Two-way Associations
Multiplicity
Aggregation
Specialization/Generalization
Object-Oriented Programme 9
Associations 关联
An association represents the relationship between
two or more classes.
A binary association is a relationship between two
classes.
An object of a class requires an object of another
class to do its work.
In UML, a binary association is represented by a
solid line that connects the two classes. E.g.,
In a classroom, a professor instructs students.
In a bank system, clients hold bank accounts.
Object-Oriented Programme 10
One-Way and Two-Way Associations
An association can be a one-way or two-way relationship.
A one-way association indicates
the direction in which one can navigate from an object of one
class to an object of another class.
A two-way association indicates
bi-directional navigation between objects of two classes.
difference
one-way association : the first class has a reference to an
object of the second class, but the second class does not
have a reference to an object of the first class.
two-way association : each class contains a reference to
an object of the other class.
Object-Oriented Programme 11
UML samples
UML indicates a one-way association with an arrow
at the end of the association line.
The attribute in the first class that contains a
reference to an object of the second class is also
written at the end of the line.
One-way association between classes Car and
Engine indicates that an engine is part of a car
Object-Oriented Programme 12
samples
the relationship between the classes Country,
Government, and Capital
the class Country has a reference to an object of
class Government
the class Country a reference to an object of
class Capital
Object-Oriented Programme 13
A class can contain more than one association
with another class
Two associations between classes Flight and Pilot,
one association with the attribute pilot and another
with the attribute coPilot.
Object-Oriented Programme 14
Multiplicity 多重性
Multiplicity
indicates the number of instances of a class that
may be associated with a single instance of
another class. E.g.,
one car has four tires and one engine
one client holds one or more bank accounts.
The multiplicity can be specified with
a single integer
a range n..m, where n is the lower limit and m is the upper limit.
“ * “ used to denote no upper limit.
The following are the most common multiplicities:
0..1 Zero or one instance
0..* or * Zero or more instances
1 Exactly one instance
1..* One or more instances
Object-Oriented Programme 15
One-to-one Association
Ina one-to-one association, exactly one instance of
each class is related with exactly one instance of
the other class.
Object-Oriented Programme 16
One-to-many Association
In a one-to-many association between classes A
and B, one instance of class A may be related with
many instances of class B, but one instance of
class B is related with exactly one instance of class
A.
Object-Oriented Programme 17
Many-to-many Association
In a many-to-many association between classes A
and B,
one instance of class A may be related with
many instances of class B
one instance of class B may be related with
many instances of class A.
Object-Oriented Programme 18
Aggregation 聚集
Each instance of class A is composed by instances
of class B.
An instance of class B is part of an instance of
class A.
The instance of class A is called the aggregate( 聚
合体 )
The instance of class B is called the component( 部
件 ).
Object-Oriented Programme 19
Aggregation in UML
Object-Oriented Programme 20
Specialization/Generalization 具象 / 抽象 ( 继承 /
泛化 )
Specialization/Generalization represents the is-a
relationship. E.g.,
a whale is-a mammal
a client is-a person.
Specialization/generalization allows class A to be
defined as specialization of another class B.
Class A is called the specialization class 特殊化类
Whale, client
class B the generalization class. 一般化类
Mammal, person
Object-Oriented Programme 21
Specialization/Generalization
Specialization/generalization
represented in UML by adding a triangle next to
the generalization class:
Object-Oriented Programme 22
specialization/generalization relationship
Ifthere is a specialization/generalization
relationship between classes A and B ,so
if A is-a B, then all instances of class A are also
instances of class B.
教材 书 , java 程序设计 / 英语 / 大学物理 书
An important consequence of this relationship is
class A inherits all the features of class B.
All the attributes and methods of class B are also
attributes and methods of class A.
Object-Oriented Programme 23
specialization/generalization relationship
The following class diagram represents the
relationships Client is-a Person and Employee is-a
Person:
Object-Oriented Programme 24
Sample note
They are specialization/generalization relationships
the attributes of class Person are also attributes
of classes Client and Employee.
Each instance of class Client contains the attributes
name, age, address, and accounts;
Each instance of class Employee contains the
attributes name, age, address, salary, and
departments.
Object-Oriented Programme 25
Example of a system of multimedia files
includesimages, audio, and text files.
The classes are defined as follows:
Object-Oriented Programme 26
1.2.3 Common Class Structures
Introduction
Collections
Self-ContainingClasses
Relationship Loops
Object-Oriented Programme 27
Introduction
Although the definition of classes and their
relationships depends on the particular application,
some class structures are common to many
designs.
These class structures, which can be thought of as
basic building blocks, can be composed to design
complex systems.
Like the the building a skyscraper
Object-Oriented Programme 28
Collections
A collectionmodels a
one-to-many relationship.
Collections store many instances of one class.
Object-Oriented Programme 29
sample
The diagram
uses a collection to represent the relationship
"one client holds one or more bank accounts"
defines methods to handle the collection of
BankAccount instances.
Each BankAccount instance in the collection has an
index indicating its location in the collection.
Object-Oriented Programme 30
Self-Containing Classes 自包含
A class can have an association with itself.
the class contains attributes with references to
objects of the same class.
Object-Oriented Programme 31
sample
Class Person in a genealogical tree ( 家族系谱树 )
system.
The relationships "each person has one mother"
and "each person has one father" are indicated with
the attributes mother and father.
The attributes mother and father are references to
objects of class Person.
Object-Oriented Programme 32
Another example,
The relationship "each employee has one boss."
The diagram indicates that the boss of an
employee is another employee.
Object-Oriented Programme 33
Relationship Loops 关系循环
Self-containment can be found in relationships that
include two or more classes.
Object-Oriented Programme 34
example
A file system.
A file system has folders, and folders contain
files or more folders, or both.
We can define a class Folder, which contains a
collection of FolderItem objects:
Object-Oriented Programme 35
1.2.4 UML with Eclipse
Introduction
Create Project
Create Folder
Create New Class Diagram
Create Class BankAccount
Create Class Person
Create Class Client
Create Specialization/Generalization Relationship
Create Association Relationship
Export Image
Object-Oriented Programme 36
1.2.5 Modeling Classes
Process of Modeling Classes
Identifying Classes
Identifying Relationships
Identifying Attributes
Identifying Methods
Modeling Using UML
Object-Oriented Programme 37
Process of Modeling Classes
Object-oriented design is
the process of building an object model for a
system to be developed.
An object model specifies
the classes
attributes
Methods
relationships with other classes.
How to building an object model from a system
specification?
Object-Oriented Programme 38
The steps to create an object model
Identify classes of objects from the system
specification.
Identify relationships between classes.
Identify attributes of each class.
Identify methods of each class.
Model system using UML.
Object-Oriented Programme 39
Identifying Classes
identify classes is to analyze the textual description
in the system specification.
In textual analysis, the nouns and the noun phrases
often indicate objects and their classes.
Singular nouns ( “book,” “library catalog,” and
“client“ ) and plural nouns ( ”users,” “books,” and
“accounts” ) indicate classes. 单数与复数
Proper nouns ( “the ACME Bank” ) and nouns of
direct reference ( “the person that owned the
account” ) indicate objects. 专有名词与指代
Object-Oriented Programme 40
The steps for identifying the classes - 1
List all the nouns in the specification.
Prune the list: 对列表进行裁剪
Convert plural nouns to their singular form. In an object
model, class names are singular.
Eliminate nouns that represent objects. Replace them
with generic nouns.
use "client" instead of "John Smith."
Eliminate nouns that are class attributes.
Ifcannot identify the attributes of the noun, it is possible a class
attribute.
Group the synonyms and then choose the best name for the
class from the group.
"user" and "client" are synonyms. In a bank system, the
best name is "client" because the system may have two
types of users: the clients and the bank's employees.
Object-Oriented Programme 41
The steps for identifying the classes - 2
Select the classes that are relevant to the system.
Look for more relevant classes. Search the
application domain for:
Physical things. "person," "book," and "computer."
Roles played by persons or organizations."employer" and "supplier."
Objects that represents an occurrence or event. "system crash,"
"flight," and "mouse click."
Objects that represent a relationship between other objects in the
model. "purchase" (related to "buyer," "seller," and "merchandise")
and "marriage" (related to "man" and "woman").
People who carry out some function. "student" and "clerk."
Places. "library," "classroom," and "bank."
Collections of objects, people, resources, or facilities. "catalog" and
"group."
Concepts or ideas that are intangible. 抽象名词 For example,
“money” and “bank account.”
Object-Oriented Programme 42
The steps for Identifying Relationships - 1
Create an n x n table where n is the number
of classes.
Label the rows and columns with the class
names.
Object-Oriented Programme 43
The steps for Identifying Relationships - 2
identify the specialization/generalization relationships
for each cell in the row A and column B, ask the following
questions:
Is an instance of class A an instance of class B?
Is an instance of class B an instance of class A?
Analyze the answer
If the answer to both questions is yes, then
the class names might be synonyms.
If the answer to the first question is yes, then
class A is a specialization of class B.
Mark the cell in the row A and column B with an S.
If the answer to the second question is yes, then
class A is a generalization of class B.
Mark the cell in the row A and column B with a G.
Object-Oriented Programme 44
The steps for Identifying Relationships - 3
Identify the association relationships,
evaluate each cell in the row A and column B:
If there is no association between class A and class
B, mark the cell with an X.
If there are one or more associations between class
A and class B, then insert the association attributes.
“study," “buy," "ownedAccounts," and "clients."
Object-Oriented Programme 45
The table told us …..
Shows the relationships "a client is a person that
has one or more accounts."
Indicates that class Client is a specialization of
class Person
Class Client has an association relationship with
class Account.
Object-Oriented Programme 46
Identifying Attributes
Look for adjectives and possessive phrases 所有格
"the X of Y" and "Y's X" in the system
specification.
"number of the account" and "client's name.“
Use knowledge of the application domain to define
the set of attributes needed for the system being
developed. 问题领域的经验,可从专业人员那里获
取
Object-Oriented Programme 47
Identifying Methods
To identify behaviors, look for verbs.
"theclient deposits money into the account“ indicates that
class Account should define a method deposit.
Use knowledge of the application domain to define
the set of methods needed for the system being
developed.
Object-Oriented Programme 48
Identifying Methods
除了以上的,还要利用开发者的经验
一般的应用系统都有的方法 ( 或系统行为 )
Create and initialize new instances.
Set and get values of attributes.
Load to and save from persistent storage.
Destroy instances.
Perform calculations using an object's values.
Output or display a result.
Ifthere are any collections held by the object,
include the methods needed to add, remove, and
access elements of these collections.
Object-Oriented Programme 49
Modeling Using UML
Use class notation to represent classes Include
attributes and methods.
Use link notation to describe association and
specialization/generalization relationships between
classes.
For associations, specify the multiplicity and the
name of the attribute associated with the
relationship.
Object-Oriented Programme 50
1.2.6 Modeling the Library System
Specification of the Library System
Identifying Classes
Identifying Relationships
Identifying Attributes
Identifying Methods
Modeling Using UML
Object-Oriented Programme 51
Specification of the Library System 规格说明
The library system tracks the items checked out by
borrowers.
The system contains a catalog of the items owned
by the library. There are two kinds of catalog items:
books and recordings. All catalog items are
identified by a unique code. (If the library owns
several copies of the same book or recording, each
copy has a unique code.) The information for each
item includes title, year, and availability. An item is
available if it is not checked out.
Object-Oriented Programme 52
Specification of the Library System
Inaddition:
The information for a book includes the author and
number of pages.
The information for a recording includes the
performer and format (CD or tape).
The system contains a database of the borrowers.
Each borrower has a unique identification code in
addition to a name. The system maintains a list, for
each borrower, of the catalog items checked out.
Object-Oriented Programme 53
Specification of the Library System
Inthe library system, the user should be able to:
Display the catalog by listing the code, title, and
availability of each item.
Display a catalog item.
Display the borrowers by listing the identification
code and name of each borrower.
Display the catalog items checked out by a
borrower.
Check out a catalog item by adding the item to
borrower's list of borrowed items.
Check in a catalog item by removing the item
from borrower's list of borrowed items.
Object-Oriented Programme 54
Identifying Classes
First, we list the nouns in the system specification:
library system book CD
items recording tape
borrowers copy database
system information borrower
catalog item identification code
library title name
kinds year list
catalog items availability user
books author (borrower) code
audio items number of pages list of borrowed items
(item) code performer
copies format 55
Object-Oriented Programme
Identifying Classes
Then, we prune the list by eliminating the following nouns:
(item) code, title, year, availability These nouns are attributes of a catalog item.
author, number of pages These nouns are attributes of a book.
performer, format These nouns are attributes of an audio item.
CD, tape These nouns are values for the attribute format.
name, identification code, (borrower)
These nouns are attributes of a borrower.
code
This noun is an element outside the library
user
system.
information This noun is a generic term for the class attributes.
kinds This noun is not relevant to the system.
Object-Oriented Programme 56
Identifying Classes
Next, we group the synonyms and then choose the best name
for the class from each group:
CatalogItem
items, catalog items, copies, copy, item
LibrarySystem
library system, system, library
Borrower
borrowers, borrower
Book
books, book
Recording
recordings, recording
BorrowedItems
list, list of borrowed items
Object-Oriented Programme 57
Finally, we have ……
classes that are relevant to the system
LibrarySystem
Catalog
CatalogItem
Book
Recording
Borrower
BorrowedItems
BorrowerDatabase
Object-Oriented Programme 58
Identifying Relationships
tableidentifies the association and
specialization/generalization relationships:
Object-Oriented Programme 59
Identifying Attributes
The following is the list of attributes for each class:
Class Attributes
LibrarySystem catalog, borrowerDB
Catalog items
CatalogItem code, title, year, available
Book author, numberOfPages
Recording performer, format
Borrower name, id, borrowedItems
BorrowedItems items
BorrowerDatabase borrowers
Object-Oriented Programme 60
Identifying Methods
The following is the list of methods for each class:
Class Methods
LibrarySyste displayCatalog() , displayCatalogItem(),
m displayBorrowerDatabase(),
displayBorrower(),checkIn(),checkOut()
Catalog addItem(item:CatalogItem)
getItem(index:int):CatalogItem
getNumberOfItems():Int
getItem(code:String):CatalogItem
CatalogItem getCode():String
getTitle():String
getYear():int
isAvailable():boolean
Object-Oriented Programme 61
setAvailable(value:boolean)
Identifying Methods
The following is the list of methods for each class:
Class Methods
Book getAuthor():String
getNumberOfPages():int
Recording getPerformer():String
getFormat():String
Borrower getId():String
getName():String
getBorrowedItems():BorrowedItems
Object-Oriented Programme 62
Identifying Methods
The following is the list of methods for each class:
Class Methods
BorrowedItems addItem(item:CatalogItem)
removeItem(item:CatalogItem)
getItem(index:int):CatalogItem
getItem(code:String):CatalogItem
getNumberOfItems():int
BorrowerDatab addBorrower(borrower:Borrower)
ase getBorrower(index:int):Borrower
getNumberOfBorrowers():int
getBorrower(id:String):Borrower
Object-Oriented Programme 63
Modeling Using UML
Thefollowing is a class diagram for the library
system:
Object-Oriented Programme 64