Pttkhdtduml

Trương Đai hoc Bach Khoa Tp.
Hö̀ Chñ Minh

Khoa Cöng Nghï Thöng Tin
Mön hoc
PHÂN TÍCH & THIẾT KẾ

HƯỚNG ĐỐI TƯỢNG DÙNG UML
Bö mön Cöng nghï phền mï̀m Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Khoa CNTT
ĐH Bach Khoa Tp.HCM Slide 1
Nöi dung mön hoc

1. n lai 1 s ́ khai ni m cơ ban cua hương ₫ ́i tương, cac ng n ngư
hương ₫ ́i tương thương dung, cơ ch ́ dịch cac type/class sang ng n
ngư c ̉ ₫i ̉n (ng n ngư may).
2. n lai qui tr nh phat tri ̉n ph ̀n m ̀m hơp nh ́t.
3. n lai ng n ngư UML ₫ươc dung ₫ ̉ mi u ta cac artifacts cua qui
tr nh phat tri ̉n ph ̀n m ̀m hơp nh ́t.
4. Giơi thi u cac m ̃u thi ́t k ́ hương ₫ ́i tương ₫ươc dung ph ̉ bi ́n
trong cac ưng dung hi n hanh va cac ưng dung tương lai.
Khoa CNTT
1
Tai liïu tham khao chñnh
[1] The Unified Software Development Process, Ivar Jacabson,
Grady Booch, James Rumbaugh, Addison-Wesley, 1999.
[2] Software Engineering - A practitioner's approach, R.S.
Pressman, McGraw-Hill, 1997
[3] Design Patterns, Erich Gamma, Richard Helm, Ralph
Johnson, John Vlissides, Addison-Wesley, 1998.
[4] OMG Unified Modeling Language Specification, version 1.3,
Object Management Group (www.omg.org), 1999
[5] UML Toolkit, Hans-Erik Eriksson & Magnus Penker, 1998
[6] Object-Oriented Software Engineering, A Use-Case Driven
Approach, I. Jacobson, ACM Press/Addison-Wesley, 1992
[7] Object-Oriented Analysis and Design with Applications, G.
Booch, The Benjamin Cummings Publishing Company, 1994
Khoa CNTT
Trương Đai hoc Bach Khoa Tp. Hö̀ Chñ Minh

Chương 1
CAC KHAI NIÏM CƠ BAN CUA

MÖ HÒNH HƯƠNG ĐÖI TƯƠNG
Khoa CNTT Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương
2
Nöi dung
1.1 Tư lêp trònh co cếu truc ₫ḯn OOP
1.2 Đö́i tương, thuöc tñnh, tac vu.
1.3 Abstract type va class.
1.4 Tñnh bao ₫ong.
1.5 Tñnh thưa kḯ va cơ chḯ 'override'.
1.6 Tñnh bao göp.
1.7 Thöng ₫iïp, tñnh ₫a hònh va kiï̉m tra kiï̉u.
1.8 Tñnh tö̉ng quat hoa.
1.9 Tñnh vưng bï̀n.
Tư lêp trònh co cếu truc ₫ḯn OOP

1. May t nh s ́ la thi ́t bị co th ̉ thưc hi n 1 s ́ hưu han cac chưc năng
cơ ban (t p l nh), cơ ch ́ thưc hi n cac l nh la tư ₫ ng tư l nh ₫ ̀u
cho ₫ ́n l nh cu ́i cung. Danh sach cac l nh ₫ươc thưc hi n nay
₫ươc goi la chương tr nh.
2. b ́t ky c ng vi c ngoai ₫ơi nao cung co th ̉ ₫ươc chia thanh tr nh tư
nhi ̀u c ng vi c nho hơn. Tr nh tư cac c ng vi c nho nay ₫ươc goi
la giai thu t giai quy ́t c ng vi c ngoai ₫ơi. M ̃i c ng vi c nho hơn
cung co th ̉ ₫ươc chia nho nưa,... ⇒ c ng vi c ngoai ₫ơi la 1 tr nh
tư cac l nh may (chương tr nh).
3. v ́n ₫ ̀ m ́u ch ́t cua vi c dung may t nh giai quy ́t v ́n ₫ ̀ ngoai
₫ơi la l p tr nh. Cho ₫ ́n nay, l p tr nh la c ng vi c cua con ngươi
(vơi sư trơ giup ngay cang nhi ̀u cua may t nh).
4. cac l nh cua chương tr nh (code) phai tham khao hoăc xư ly (truy
xu ́t) th ng tin (dư li u).
3
5. Dư li u cua 1 chương tr nh co th ̉ r ́t nhi ̀u va ₫a dang. Đ ̉ truy
xu ́t ₫ung 1 dư li u ta c ̀n :
- t n nh n dang.
- ki ̉u dư li u mi u ta c ́u truc dư li u.
- t ̀m vưc truy xu ́t mi u ta giơi han khach hang truy xu ́t dư
li u.
6. Chương tr nh c ̉ ₫i ̉n = giai thu t + dư li u.
7. Chương tr nh con (function, subroutine,...) cho phep c ́u truc
chương tr nh, sư dung lai code...
8. Chương tr nh c ̉ ₫i ̉n co c ́u truc ph n c ́p như sau :

Chương tr nh = c ́u truc dư li u + giai thu t
module global data

(package)
local data
entry 'start' of module
local data
of function
4
Chương tr nh = t p cac ₫ ́i tương tương tac nhau
₫ ́i tương
(object)
local data
entry of object
local data
of operation
Tö̉ng quat vï̀ hương ₫ö́i tương

M h nh hương ₫ ́i tương giơi thi u 1 quan ₫i ̉m l p tr nh
(va ph n t ch/thi ́t k ́) khac hăn so vơi trương phai c ̉ ₫i ̉n
(co c ́u truc).
Băt ₫ ̀u nhen nhom vao nhưng năm cu ́i 60s va ₫ ́n ₫ ̀u
90s th trơ n n r ́t ph ̉ bi ́n trong c ng nghi p ph ̀n m ̀m.
Nhưng ng n ngư hương ₫ ́i tương ₫ ̀u ti n : Smalltalk,
Eiffel. Sau ₫o xu ́t hi n th m : Object Pascal, C++, Java,
C#,…
H nh thanh cac phương phap ph n t ch/thi ́t k ́ hương ₫ ́i
tương.
Va hi n nay ta co 1 qui tr nh phat tri ̉n ph ̀n m ̀m hơp nh ́t
dưa tr n ng n ngư UML.
5
Đö́i tương (Object)
~ M h nh ₫ ́i tương quan ni m chương tr nh bao g ̀m cac ₫ ́i
tương sinh s ́ng va tương tac vơi nhau.
~ Đ ́i tương bao g ̀m :
thu c t nh (dư li u) : mang 1 gia trị nh ́t ₫ịnh tai tưng thơi ₫i ̉m.
tac vu (operation) : thưc hi n 1 c ng vi c nao ₫o. Implementation
(class)
Interface
(abstract type)
Kiï̉u trưu tương (Abstract type)

~ Abstract type (type) ₫ịnh nghĩa interface sư dung ₫ ́i tương.
~ Interface la t p cac entry ma b n ngoai co th ̉ giao ti ́p vơi ₫ ́i
tương.
~ Dung signature ₫ ̉ ₫ịnh nghĩa m ̃i entry, Signature g ̀m :
t n method (operation)
danh sach ₫ ́i s ́ h nh thưc, m ̃i ₫ ́i s ́ ₫ươc ₫ăc ta bơi 3
thu c t nh : t n, type va chi ̀u chuy ̉n ₫ ng (IN, OUT,
INOUT).
₫ăc ta chưc năng cua method (thương la chu th ch).
~ Dung abstract type (chư kh ng phai class) ₫ ̉ ₫ăc ta ki ̉u cho
bi ́n, thu c t nh, tham s ́ h nh thưc.
~ User kh ng c ̀n quan t m ₫ ́n class (hi n thưc cu th ̉) cua ₫ ́i
tương.
6
Class (Implementation)
~ Class ₫ịnh nghĩa chi ti ́t hi n thưc ₫ ́i tương :

₫ịnh nghĩa cac thu c t nh dư li u : gia trị cua t ́t ca thu c
t nh xac ₫ịnh trang thai cua ₫ ́i tương.
ki ̉u cua thu c t nh co th ̉ la type c ̉ ₫i ̉n hay abstract type,
trong trương hơp sau thu c t nh chưa tham khao ₫ ́n ₫ ́i
tương khac.
coding cac method va cac internal function.
~ Định nghĩa cac method tao va xoa ₫ ́i tương.
~ Định nghĩa cac method constructor va destructor.
~ User kh ng c ̀n quan t n ₫ ́n class cua ₫ ́i tương.
Vñ du vï̀ class trong Java

class abstract HTMLObject {
protected static final int LEFT = 0;
protected static final int MIDDLE = 1;
protected static final int RIGHT = 2;
private int alignment = LEFT;
protected Vector objects = null;
HTMLObject( ){ // constructor
objects = new Vector (5);
}
public void setAlignment( int algnmt ) {
alignment = algnmt;
}
public int getAlignment( ) {
return alignment;
}
public abstract String toHTML( ); // abstract operation
}
7
Tñnh bao ₫ong (encapsulation)
z Bao ₫ong : che d ́u moi chi ti ́t hi n thưc cua ₫ ́i tương,

kh ng cho b n ngoai th ́y va truy xu ́t ⇒ t nh ₫ c l p cao
giưa cac ₫ ́i tương (hay t nh k ́t d nh - cohesion giưa cac
₫ ́i tương r ́t th ́p).
che d ́u cac thu c t nh dư li u : n ́u c ̀n cho phep truy
xu ́t 1 thu c t nh dư li u, ta tao 2 method get/set tương
ưng ₫ ̉ giam sat vi c truy xu ́t va che d ́u chi ti ́t hi n
thưc b n trong.
che d ́u chi ti ́t hi n thưc cac method.
che d ́u cac internal function va sư hi n thưc cua chung.
Tñnh thưa kḯ (inheritance)

~ T nh thưa k ́ cho phep giam nhe c ng sưc ₫ịnh nghĩa
type/class : ta co th ̉ ₫ịnh nghĩa cac type/class kh ng phai
tư ₫ ̀u ma băng cach k ́ thưa type/class co săn, ta chỉ ₫ịnh
nghĩa th m cac chi ti ́t mơi ma th i (thương kha t).
Đa thưa k ́ hay ₫ơn thưa k ́.
M ́i quan h  supertype/subtype va superclass/subclass.
co th ̉ override cac method cua class cha, k ́t qua
override chỉ co nghĩa trong ₫ ́i tương class con.
Đ ́i tương cua class con co th ̉ ₫ong vai tro cua ₫ ́i
tương cha nhưng ngươc lai thương kh ng ₫ung.
8
Vñ du vï̀ thưa kḯ va override - Java
class Geometry {
public Draw(Graphics g);
protected int xPos, yPos;
protected double xScale, yScale;
protected COLORREF color;
};
class Line extends Geometry {

int xPos2, yPos2;
// other attributes...
public Draw(Graphics g) {
// cac l nh ve ₫oan thăng
}
}
Tñnh bao göp (aggregation)

1 ₫ ́i tương co th ̉ chưa nhi ̀u ₫ ́i tương khac tao n n m ́i
quan h  bao g p 1 cach ₫  qui giưa cac ₫ ́i tương.
Co 2 goc nh n v ̀ t nh bao g p : ngư nghĩa va hi n thưc.
Goc nh n ngư nghĩa Goc nh n hi n

thưc
O1 O2 O2
O1
O3 O3
9
Vñ du vï̀ bao göp - C++
class Geometry { // abstract base class
public:
Geometry( );
~Geometry( );
virtual void Draw( Window *pWnd ) = 0; // abstract operation
protected:
int xPos, yPos;
double xScale, yScale;
COLORREF color;
};
class Group : public Geometry {

public:
Group( );
~Group( );
virtual void Draw( Window *pWnd ); // override
private:
Geometry **ppGeo; // pointer container
int geoCount;
};
Thöng ₫iïp (Message)

~ Th ng ₫i p la 1 phep goi tac vu ₫ ́n 1 ₫ ́i tương tư 1
tham khao.
~ Th ng ₫i p bao g ̀m 3 ph ̀n :
tham khao ₫ ́n ₫ ́i tương ₫ ch.
t n tac vu mu ́n goi.
danh sach tham s ́ thưc c ̀n truy ̀n theo (hay nh n v ̀ tư)
tac vu.
v du : aCircle.SetRadius (3); aCircle.Draw (pWnd);
~ Th ng ₫i p la phương ti n giao ti ́p (hay tương tac)
duy nh ́t giưa cac ₫ ́i tương.
10
Tñnh ₫a xa (Polymorphism)
~ Cung 1 l nh gơi th ng ₫i p ₫ ́n ₫ ́i tương th ng qua cung 1
tham khao nhưng ơ vị tr /thơi ₫i ̉m khac nhau co th ̉ g y ra
vi c thưc thi method khac nhau cua cac ₫ ́i tương khac
nhau.
T1 p1; // C1 va C2 la 2 class hi n thưc T1
...
p1 = New C1; // tao ₫ ́i tương C1, gan tham khao vao p1
p1.meth1(...);
...
p1 = New C2; // tao ₫ ́i tương C2, gan tham khao vao p1
p1.meth1(...);
L nh p1.meth1(...); ơ 2 vị tr khac nhau k ch hoat 2 method
khac nhau cua 2 class khac nhau.
Kiï̉m tra kiï̉u (type check)

~ Chăt va dung m ́i quan h  'conformity' (tương th ch t ̉ng
quat). Type A tương th ch vơi type B ⇔ A chưa moi method
cua B va ưng vơi tưng method cua B :
t ̀n tai 1 method cung t n trong A.
danh sach ₫ ́i s ́ cua 2 method tương ưng phai băng
nhau.
ki ̉u ₫ ́i s ́ OUT hay gia trị return cua method trong A
phai tương th ch vơi ki ̉u cua ₫ ́i s ́ tương ưng trong B.
ki ̉u ₫ ́i s ́ IN cua method trong B phai tương th ch vơi
ki ̉u cua ₫ ́i s ́ tương ưng trong A.
ki ̉u ₫ ́i s ́ INOUT cua method trong A phai trung vơi
ki ̉u cua ₫ ́i s ́ tương ưng trong B.
Ö quan h  so trung hay quan h  con/cha (sub/super) la trương
hơp ₫ăc bi t cua quan h  tương th ch t ̉ng quat.
11
Tñnh tö̉ng quat hoa (Generalization)
~ Co 2 ngư nghĩa khac nhau cua t nh t ̉ng quat hoa :
class t ̉ng quat hoa cho phep san sinh tư ₫ ng cac
class b nh thương, cac class b nh thương tư no chỉ co
th ̉ tao ra ₫ ́i tương. Thương dung ngư nghĩa nay trong
giai ₫oan l p tr nh.
ngươc vơi t nh thưa k ́ : supertype/superclass la
type/class t ̉ng quat hoa cua cac con cua no. Thương
dung ngư nghĩa nay trong giai ₫oan ph n t ch/thi ́t k ́
ph ̀n m ̀m.
Tñnh thương tru (persistence)

~ ₫ơi s ́ng cua 1 ₫ ́i tương ₫ c l p vơi ₫ơi s ́ng cua ph ̀n tư
tao ra no.
₫ ́i tương phai t ̀n tai khi con t nh ́t 1 tham khao ₫ ́n no
trong h  th ́ng.
₫ ́i tương phai bị xoa khi kh ng con tham khao nao ₫ ́n
no, v tai thơi ₫i ̉m nay ₫ ́i tương la rac. Vi c xac ₫ịnh
ch nh xac 1 ₫ ́i tương co phai la rac hay kh ng la 1 vi c
phưc tap code ưng dung kh ng ₫ươc phep lam, ₫ y la
c ng vi c cua h  th ́ng th ng qua module 'garbage
collection'.
vưng b ̀n kh ng phai la vĩnh hăng, mưc ₫  co th ̉ la 1
session cua may ao (JVM) hay l u dai (th ng qua ₫ĩa
cưng, CDROM).
12
Tö̉ng kḯt
~ M h nh hương ₫ ́i tương quan ni m th ́ giơi (hay chương tr nh)
bao g ̀m cac ₫ ́i tương s ́ng chung va tương tac vơi nhau.
~ Cac ₫ăc ₫i ̉m ch nh cua hương ₫ ́i tương :
Bao ₫ong : m ̃i ₫ ́i tương bao g ̀m dư li u va tac vu. Cac tac vu thi ́t
l p n n hanh vi cua ₫ ́i tương. Cac ₫ ́i tương ₫ươc ph n loai băng
class.
Cac ₫ ́i tương tương tac vơi nhau băng cach gơi th ng ₫i p.
giưa cac class/₫ ́i tương co th ̉ t ̀n tai quan h  bao g p, thưa k ́, t ̉ng
quat hoa.
T nh ₫a h nh : k ́t qua cua sư ki ̉m tra ki ̉u dưa vao m ́i quan h 
'conformity'.
T nh vưng b ̀n : ₫ ́i tương t ̀n tai khi con t nh ́t 1 tham khao ₫ ́n no.
Trương Đai hoc Bach Khoa Tp. Hö̀ Chñ Minh

Chương 2
THÑ DU VÏ NGÖN NGƯ OOP

) Visual C++
) Java
Khoa CNTT Chương 2: Th du v ̀ cac ng n ngư OOP
13
2.1 Ngön ngư Visual C++
1. Chỉ hö̃ trơ khai niïm class.
2. Cho phep Đa thưa kḯ.
3. Dung 'abstract class' ₫ï̉ ₫ịnh nghĩa interface.
4. Tềm vưc truy xuết cac thanh phền.
5. Đa hònh co chon loc nhơ 'virtual function'
6. Chỉ hö̃ trơ cac ₫ö́i tương tam.
7. Override method khi thưa kḯ.
8. Co thï̉ ₫ịnh nghĩa function overloaded.
Chỉ hö̃ trơ khai niïm class

1. Dung class ₫ ̉ ₫ịnh nghĩa ki ̉u cho cac bi ́n, thu c t nh
⇒ ₫ ́i tương co th ̉ chưa v t ly ₫ ́i tương khac hay chưa tham
khao ₫ ́n ₫ ́i tương khac.
2. Đa thưa k ́ trong ₫ịnh nghĩa class ⇒ 1 class co th ̉ chưa nhi ̀u
class con trung nhau ⇒ dung "virtual base class" ₫ ̉ t ́i ưu hoa
b  nhơ ₫ ́i tương.
14
Class trưu tương (Abstract class)
3. H ̃ trơ khai ni m "abstract class" ₫ ̉ ₫ịnh nghĩa class chỉ chưa
th ng tin interface nhưng kh ng cho phep dung class nay ₫ ̉
₫ịnh nghĩa ki ̉u cho bi ́n hay thu c t nh. 1 abstract class la 1
class chưa t nh ́t 1 "pure virtual funtion".
class Geometry { // abstract class
public:
Geometry( );
~Geometry( );
virtual void Draw( Window *pWnd ) = 0; // pure virtual function
protected:
int xPos, yPos;
COLORREF color;
};
Tềm vưc truy xuết thanh viïn

4. T ̀m vưc truy xu ́t th ng tin trong ₫ ́i tương :
private : th ng tin bị che d ́u hoan toan.
protected : chỉ che d ́u b n ngoai nhưng cho phep cac ₫ ́i
tương con, chau, chăt... truy xu ́t.
public : cho phep t ́t ca moi nơi truy xu ́t.
Friend class : la class ma m ̃i function cua no ₫ ̀u co th ̉ truy
xu ́t tư do m ̃i thanh ph ̀n cua class hi n tai.
Friend function : la function co th ̉ truy xu ́t tư do m ̃i thanh
ph ̀n cua class hi n tai.
Co th ̉ han ch ́ t ̀m vưc cua thanh vi n cua class cha khi thưa
k ́.
15
Hö̃ trơ tñnh ₫a hònh co chon loc
5. Định nghĩa 'virtual function' n ́u mu ́n ap dung t nh ₫a h nh
trong vi c gơi th ng bao y u c ̀u function nay thưc thi.
T ́t ca cac 'virtual function' ₫ươc quan ly trong 1 danh sach
"virtual function table".
₫ịa chỉ function 1
₫ịa chỉ function i
₫ịa chỉ function n
Cac ₫ö́i tương ₫ï̀u tam thơi

6. Cac ₫ ́i tương chỉ t ̀n tai tam thơi trong kh ng gian process.
Tham khao ₫ ́n ₫ ́i tương thưc ch ́t la pointer cuc b .
chương tr nh phai tư vi ́t code cho hoat ₫ ng save/restore ₫ ́i
tương n ́u mu ́n lưu giư/dung lai ₫ ́i tương.
VC++ h ̃ trơ hoat ₫ ng save/restore ₫ ́i tương nhơ kha năng
'Serialization'.
7. Co quy ̀n 'override' b ́t ky toan tư hay function nao cua class
cha.
8. Cho phep ₫ịnh nghĩa cac ham 'overloaded' : cung t n nhưng
'signature' khac nhau.
16
Skeleton ₫ịnh nghĩa class
class Geometry : Object { // == class Geometry : public Object {
public:
Geometry( );
~Geometry( );
virtual void Draw( Window *pWnd ); // virtual method
BOOL IsDisplayed(void);
....
protected:
COLORREF color;
....
private :
int xPos, yPos;
...
};
class Point : Geometry {};
class Line : Geometry { .... };
class Polygon : Geometry {....};
class Rectangle : Geometry {....};
....
Cếu truc 1 chương trònh Dialog based ₫ơn gian
InitInstance()
DoModal()
CProgramDlg
CProgramApp
17
Cếu truc 1 chương trònh SDI ₫ơn gian
InitInstance()
CMainFrame
CProgramView CProgramDoc
CSingleDocTemplate
CProgramApp
Cếu truc 1 chương trònh MDI ₫ơn gian
InitInstance()
CChildFrame
CProgramView CProgramDoc
CMultiDocTemplate
CProgramApp
18
2.2 Ngön ngư Java
1. Hö̃ trơ 'interface' (1 dang cua type) va class.
2. Hö̃ trơ Đơn thưa kḯ.
3. Dung 'abstract class' ₫ï̉ ₫ịnh nghĩa interface.
4. Tềm vưc truy xuết cac thanh phền.
5. Hö̃ trơ package
6. Đa hònh ₫ềy ₫u.
7. Chỉ hö̃ trơ ₫ö́i tương tam trong session JVM
8. Override function khi thưa kḯ.
9. Co thï̉ ₫ịnh nghĩa function overloaded.
Hö̃ trơ Class va Interface

1. Chu y ́u dung class ₫ ̉ ₫ịnh nghĩa ki ̉u cho cac bi ́n, thu c
t nh.
Co th ̉ dung interface ₫ ̉ ₫ịnh nghĩa ki ̉u cho cac bi ́n, thu c
t nh. Đ ́i tương chỉ co th ̉ chưa tham khao ₫ ́n ₫ ́i tương khac.
2. Phai goi ham tao ₫ ́i tương 1 cach tương minh, nhưng kh ng
₫ươc xoa ₫ ́i tương.
class C1 extends RootClass {...}
C1 o1; // o1 chưa tham khao ₫ ́n ₫ ́i tương C1
o1 = New C1;
3. Interface chỉ ₫ươc dung trong trương hơp ₫ăc bi t va kh ng
tương ₫ương vơi abstract type.
4. Đơn thưa k ́ trong ₫ịnh nghĩa class ⇒ m ́i quan h  thưa k ́
giưa cac class kha ₫ơn gian.
19
Hö̃ trơ abstract class
5. H ̃ trơ khai ni m "abstract class" ₫ ̉ ₫ịnh nghĩa class chưa
th ng tin interface va kh ng cho phep 'instanciate' ₫ ́i tương.
Ban chỉ co th ̉ dung class 'abstract class' ₫ ̉ ₫ăc ta ki ̉u cho
cac bi ́n hoăc ₫ịnh nghĩa cac class con.
class abstract Geometry { // abstract class
protected int xPos, yPos;
protected double xScale, yScale;
protected COLORREF color;
...
public abstract Draw(Graphics g); // abstract function
...
};
Abstract class co th ̉ chưa ₫ ̀y ₫u cac hi n thưc b n trong,
nhưng thương chỉ co chưa cac 'abstract function'.
Tềm vưc truy xuết cac thanh phền

6. T ̀m vưc truy xu ́t cac thanh ph ̀n trong ₫ ́i tương :
private : thanh ph ̀n bị che d ́u hoan toan.
protected : che d ́u b n ngoai nhưng cho phep cac ₫ ́i tương
con, chau, chăt... truy xu ́t.
public : cho phep t ́t ca moi nơi truy xu ́t.
friendly : cho phep moi ph ̀n tư trong package truy xu ́t. Đ y
la t ̀m vưc default va kh ng co tư khoa t ̀m vưc tương minh.
20
Hö̃ trơ package
7. Package la ₫ơn vị quan ly t ̀m vưc cua java, co th ̉ chưa nhi ̀u
class.
package graphics;
public class Circle extends Graphic implements Draggable {
...
}
T ́t ca moi ph ̀n tư ₫ươc ₫ịnh nghĩa trong 1 file source ₫ ̀u
thu c 1 package : t n ₫ươc qui ₫ịnh bơi phat bi ̉u package hay
la package default.
Nhi ̀u file source co th ̉ thu c cung 1package (dung cung t n
trong phat bi ̉u package).
Hö̃ trơ ₫ềy ₫u tñnh ₫a hònh

8. T ́t ca cac public function ₫ươc quan ly trong 1 danh sach
"public function table".

₫ịa chỉ function i
₫ịa chỉ function n
21
Cac ₫ö́i tương ₫ï̀u 'tam thơi'
9. Cac ₫ ́i tương chỉ t ̀n tai tam thơi trong 1session chay JVM.
Ban co th ̉ tao ra cac ₫ ́i tương mơi ma kh ng c ̀n xoa no.
Đ ́i tương se t ̀n tai m t khi con tham khao ₫ ́n no. Module
Garbage Collection trong JVM se chịu trach nhi m phat hi n
₫ ́i tương 'rac' va xoa no ra khoi b  nhơ JVM.
10. Co quy ̀n 'override' b ́t ky function nao cua class cha.
11. Cho phep ₫ịnh nghĩa cac ham 'overloaded' : cung t n nhưng
'signature' khac nhau.
Thñ du vï̀ chương trònh Java

import java.net.*;
public class getnet {
public static void main(String args[]) {
try {
if(args.length!=1) {
System.out.println("Usage: java AddrLookupApp <HostName>");
return;
}
InetAddress host = InetAddress.getByName(args[0]);
String hostName = host.getHostName();
System.out.println ("Host name : "+hostName);
System.out.println ("IP address:"+host.getHostAddress());
}
catch (UnknownHostException e) {...}
}
}
22
Thñ du vï̀ chương trònh Java
GUIClock
<<chưa>> AlarmClock
12.34.25
wakeup()
Thñ du vï̀ cac class Java
public class AlarmClock {

private static final int MAX_CAPACITY = 10;
private static final int UNUSED = -1;
private static final int NOROOM = -1;
private Sleeper[] sleepers = new Sleeper[MAX_CAPACITY];
private long[] sleepFor = new long[MAX_CAPACITY];
public AlarmClock () {
for (int i = 0; i < MAX_CAPACITY; i++)
sleepFor[i] = UNUSED;
}
23
public synchronized boolean letMeSleepFor(Sleeper s, long time)

{
int index = findNextSlot();
if (index == NOROOM) {
return false;
} else {
sleepers[index] = s;
sleepFor[index] = time;
new AlarmThread(index).start();
return true;
}
}

private synchronized int findNextSlot() {
for (int i = 0; i < MAX_CAPACITY; i++) {
if (sleepFor[i] == UNUSED)
return i;
}
return NOROOM;
}
private synchronized void wakeUpSleeper(int sleeperIndex) {
sleepers[sleeperIndex].wakeUp();
sleepers[sleeperIndex] = null;
sleepFor[sleeperIndex] = UNUSED;
}
24
private class AlarmThread extends Thread {
int mySleeper;
AlarmThread(int sleeperIndex) {
super();
mySleeper = sleeperIndex;
}
public void run() {
try {
sleep(sleepFor[mySleeper]);
} catch (InterruptedException e) {}
wakeUpSleeper(mySleeper);
}
}
}

public interface Sleeper {
public void wakeUp();
public long ONE_SECOND = 1000;// in milliseconds
public long ONE_MINUTE = 60000; // in milliseconds
}
import java.applet.Applet;
import java.awt.Graphics;
import java.util.*;
import java.text.DateFormat;
public class GUIClock extends Applet implements Sleeper {
private AlarmClock clock;
public void init() {
clock = new AlarmClock();
}
25
public void start() {
clock.letMeSleepFor(this, 1000);
}
public void paint(Graphics g) {
Calendar cal = Calendar.getInstance();
Date date = cal.getTime();
DateFormat dateFormatter =
DateFormat.getTimeInstance();
g.drawString(dateFormatter.format(date), 5, 10);
}
public void wakeUp() {
repaint();
clock.letMeSleepFor(this, 1000);
}
} Bö mön Cöng nghï phền mï̀m Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Trương Đai Hoc Bach Khoa Tp. HCM

Khoa Cöng nghï Thöng tin
Chương 3
NGUYÏN TĂÆC DỊCH OOP

) Dịch abstract type
) Dịch class
Khoa CNTT Chương 3: Nguy n tăc dịch OOP
26
Tö̉ng quat vï̀ vến ₫ï̀ dịch OOP
• Chương tr nh la 1 t p cac ₫ ́i tương s ́ng va tương

tac l ̃n nhau.
• Cac ₫ ́i tương thu c 1 s ́ loai nh ́t ₫ịnh (n)
• M ̃i loai ₫ ́i tương ₫ươc mi u ta bơi 1 type + 1 class
• Chương tr nh la t p n ₫ịnh nghĩa type + class
• Dịch chương tr nh OOP la vong lăp dịch n type + n
class.
• Ta se mi u ta qui tr nh dịch 1 type va 1 class
Dịch 1 abstract type
• Abstract type chỉ chưa th ng tin trưu tương

(interface), kh ng mi u ta sư hi n thưc → K ́t qua
vi c dịch 1 type chỉ dưng lai c y ngư nghĩa cua type
tương ưng ₫ ̉ phuc vu vi c ki ̉m tra ki ̉u, chư kh ng
tao code ma may.
• Chỉ c ̀n 3 bươc : duy t tư vưng, ph n t ch cu phap,
ph n t ch ngư canh.
• N n dung c ng cu h ̃ trơ như LEX, YACC.
27
Dịch 1 class
• Dịch class la c ng vi c ch nh cua chương tr nh dịch

OOP.
• G ̀m 2 c ng vi c ch nh : dịch thu c t nh dư li u va
dịch cac method (hay cac internal function).
• C ̀n ₫ ̀y ₫u cac bươc : duy t tư vưng, ph n t ch cu
phap, ph n t ch ngư canh, tao ma.
• N n dung c ng cu h ̃ trơ như LEX, YACC.
Dịch thuöc tñnh dư liïu

typedef struct {
• class → c ́u truc record
// import cac field tư c ́u truc
class C1 : C0 { // ₫ươc sinh ra tư C0
double d;
int i ; // cac field tương ưng vơi C1
... int C1_d;
public : int C1_i;
int proc4(int i); ...
// cac field dư li u ₫i ̀u khi ̉n
void proc5 (double d); // tư tao bơi chương tr nh dịch
... void (*pvfaddr)() ;
}; } C1;
28
Dịch thuöc tñnh dư liïu (tt)
• m ̃i class → 1 record c ̉ ₫i ̉n.

• t n class → t n record.
• copy cac field dư li u cua c ́u truc sinh ra tư class cha.
• chuy ̉n tưng thu c t nh cua class thanh tưng field cua record,
'tuy t ₫ ́i hoa' t n cua thu c t nh ₫ ̉ tranh nhăp nhăng.
• th m cac field dư li u ₫i ̀u khi ̉n phuc vu cho run-time : th du
bang ₫ịa chỉ cac method cua ₫ ́i tương (pvftbl).
Dịch thuöc tñnh dư liïu (tt)
• c ́u truc record ₫ươc dịch ra ma may thanh 1 vung nhơ li n tuc
co ₫  dai băng ₫  dai cua record.
- field C1 o1; C1_o1 db dup (sizeof(C1))
• truy xu ́t 1 thu c t nh dư li u trơ thanh vi c truy xu ́t nhơ
dung cach ₫ịnh ₫ịa chỉ chỉ s ́ :
- o1.i = 5; mov bx, C1_o1
mov [bx+4], 5
29
Tao bang ₫ịa chỉ cac method
pvftbl
fname faddr
class C1 : C0 { 0 "proc1" C0_proc1
int i ;
1 "proc2" C1_proc2
double d;
... 2 "proc3" C0_proc3
public :
int proc4(int i, double k); 3 "proc4" C1_proc4
void proc5 (double d); 4 "proc5" C1_proc5
...
}; 5 .... ...
Tao bang ₫ịa chỉ cac method (tt)
• tao bang ₫ịa chỉ g ̀m C1METHCNT ph ̀n tư (C1METHCNT la

s ́ method cua class hi n hanh, k ̉ ca cac method thưa k ́.
• m ̃i ph ̀n tư ₫ươc nh n dang qua chỉ s ́ va g ̀m 2 th ng tin
ch nh : t n gơi nhơ cua method va ₫ịa chỉ cua method.
• copy bang ₫ịa chỉ cua class cha ₫a co.
• hi u chỉnh lai cac ₫ịa chỉ cua cac method bị override.
• th m vao cac method mơi ₫ịnh nghĩa trong class hi n hanh.
30
Dịch 1 method
int C1_proc1(C1* p, int i, double d) {
int C1::proc1(int i,double k) {
C2 o2; C2 *p2;
C2 o2;
// truy xu ́t thu c t nh
C2 *p2;
p->C1_i = i; p->C1_d = d;
C1::i = i;
// goi ham
d = k;
C1_proc5(p,d);
proc5(d);
C2_proc2(&o2, i,d);
o2.proc2(i,d);
// gơi th ng bao : ki ̉m tra, load,
p2 = New(C2); 1 // anh xa bang ₫ịa chỉ method
p2->proc2(i,d);
.... 2 for (i = 0; i <C1METHCNT; i ++)
if (strcmp ("proc2", p2->
};
pvftbl[i].fname)==0) break;
3 (*pvftbl[i].faddr)(p2,i,d);
};
Dịch 1 method (tt)

• t n method ₫ươc chuy ̉n tư dang 'tương ₫ ́i' sang 'tuy t ₫ ́i'
(n ́i k ́t t n class vao).
• th m tham s ́ ₫ ̀u ti n cho ham sinh ra : mi u ta tham khao
₫ ́n ₫ ́i tương ma ham se truy xu ́t cac thu c t nh dư li u.
• t n thu c t nh ₫ươc chuy ̉n tư dang 'tương ₫ ́i' sang 'tuy t ₫ ́i'
(n ́i k ́t t n class vao).
• goi ham internal → goi ham nhưng th m tham s ́ ₫ ̀u ti n.
• gơi th ng bao 3 bươc :
— ki ̉m tra, t m, load va anh xa bang ₫ịa chỉ cac method cua
₫ ́i tương.
— t m chỉ s ́ cua method c ̀n goi trong bang (i).
— goi gian ti ́p method th ng qua ₫ịa chỉ ph ̀n tư thư i trong
bang.
31
Tö́i ưu hoa code tao ra
• co 2 v ́n ₫ ̀ lơn trong qua tr nh dịch 1 class sang ng n ngư c ̉

₫i ̉n.
— bang ₫ịa chỉ method chi ́m nhi ̀u ch ̃.
— t ́n thơi gian ₫ ̉ phuc vu l nh gơi th ng bao : ki ̉m tra, load
va anh xa bang ₫ịa chỉ, t m chỉ s ́ method c ̀n goi va goi
gian ti ́p qua ₫ịa chỉ trong bang.
• 1 s ́ chương tr nh dịch t m cach t ́i ưu hoa cac v ́n ₫ ̀ nay.
• slide sau la cac t ́i ưu hoa cua chương tr nh dịch C++ va cai gia
phai tra.
Tö́i ưu hoa code tao ra (tt)

• trong C++, t ́t ca ₫ ́i tương ₫ ̀u tam thơi va găn chăt vao ưng
dung → bang ₫ịa chỉ cac method cua cac ₫ ́i tương lu n năm
săn trong kh ng gian cua ưng dung.
• m ̃i l ̀n tao ₫ ́i tương, bi ́n pvftbl trong ₫ ́i tương ₫ươc gan
ngay ₫ịa chỉ ₫ ̀u bang method → kh ng c ̀n lam bươc 1 cho
m ̃i l ̀n gơi th ng bao.
• C++ chỉ dung m ́i quan h  con/cha trong ki ̉m tra ki ̉u → c ng
vi c 2 ₫ươc lam tai thơi ₫i ̉m dịch thay v tai thơi ₫i ̉m gơi th ng
bao trong luc chay.
• c t t n gơi nhơ method kh ng c ̀n phai lưu trư trong bang ₫ịa
chỉ cac method.
• chỉ co cac virtual function mơi ₫ươc giai quy ́t theo cơ ch ́ ₫a
h nh, con cac function khac ₫ươc dịch ra lơi goi trưc ti ́p.
32
Tö́i ưu hoa code tao ra (tt)
• cai gia phai tra cua vi c t ́i ưu hoa trong C++ :
— ngươi l p tr nh phai tư quy ́t ₫ịnh method nao c ̀n xư ly
theo cơ ch ́ ₫a h nh, ham nao kh ng ? N ́u sư quy ́t ₫ịnh
nay sai th se g y l ̃i khi chay, ma la ngươi th kho long
quy ́t ₫ịnh ch nh xac.
— t nh ₫a h nh chỉ ₫ung giưa cac ₫ ́i tương co m ́i quan h 
con/cha, ơ ₫o thư tư cac ₫ịa chỉ method cua moi class con
trong bang ₫ịa chỉ lu n gi ́ng thư tư cac method tương ưng
cua class cha, tuy nhi n giưa 2 class b ́t ky th kh ng th ̉
₫am bao → ki ̉m tra ki ̉u trong C++ kh ng th ̉ n ng c ́p l n
băng cach dung m ́i quan h  "conformity".

Chương 4
QUI TRÒNH HƠP NHÊT & UML

) Qui trònh phat triï̉n phền mï̀m hơp nhết
) Tö̉ng quat vï̀ ngön ngư mö hònh UML
Khoa CNTT Chương 4: UML & Qui tr nh hơp nh ́t
33
What Is a Process?
• Defines Who is doing What, When to do it,

and How to reach a certain goal.
New or changed New or changed

Software Engineering
requirements Process system
Key concepts
When does
• Cycle product happen?
When does
• Phase, Iterations architecture happen?
• Process Workflows What does

happen?
— Activity, steps
• Artifacts What is
produced?
— models
— reports, documents
Who does
• Worker: Architect it?
34
Key concepts
time
Cycle 1 Cycle 2 Cycle 3 Cycle 4 Cycle i Cycle n
Phase
Inception Elaboration Construction Transition
Prelim ... Arch ... Dev Dev ... Trans ...

Iteration Iteration Iteration Iteration Iteration
Release Release Release Release Release Release Release Release
Lifecycle Phases
time
• Inception Define the scope of the project and

develop business case
• Elaboration Plan project, specify features, and
baseline the architecture
• Construction Build the product
• Transition Transition the product to its users
35
Major Milestones
time
Vision Baseline Initial Product

Architecture Capability Release
Phases and Iterations
Prelim ... Arch ... Dev Dev ... Trans ...

Iteration Iteration Iteration Iteration Iteration
Release Release Release Release Release Release Release Release
An iteration is a sequence of activities with an established plan and

evaluation criteria, resulting in an executable release
36
Iterations and Workflow
Phases
Core Workflows Inception Elaboration Construction Transition
Requirements
An iteration in the
elaboration phase
Analysis
Design
Implementation
Test
P r e lim in a ry ite r. ite r. ite r. ite r. ite r. ite r. ite r.

Ite ra tio n (s ) #1 #2 #n #n+1 #n +2 #m #m +1
Bö mön Cöng nghï phền mï̀m It e r a tioMön

n s Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Workflows and Models

UML diagrams provide
views into each model
Requirements Use Case

Model
Analysis Analysis
Model
Design Design Depl.

Model Model
Implementation Impl.
Model
Each workflow is
associated with one or
more models.
Test Test
Model
37
Use Case Model
Use Case
Use Case Diagrams
Model
Class Object
Diagrams Diagrams
Analysis Component
Model
Diagrams
Deployment
Design Diagrams
Model
Sequence
Diagrams
Depl.
Model Collaboration
Diagrams
Impl. Statechart
Model Diagrams
Activity
Test
Model Diagrams
Analysis & Design Model

Use Case
Use Case Diagrams
Model
Class Object
Diagrams Diagrams
Analysis Component
Model
Diagrams
Incl. subsystems
Deployment and packages
Design Diagrams
Model
Sequence
Diagrams
Depl.
Model Collaboration
Diagrams
Impl. Statechart
Model Diagrams
Activity
Test
Model Diagrams
38
Deployment and Implementation Model
Use Case
Use Case Diagrams
Model
Class Object
Diagrams Diagrams
Analysis Component
Model
Diagrams
Deployment
Design Diagrams
Model
Sequence
Diagrams Incl. active classes
Depl.
and components
Model Collaboration
Diagrams
Impl. Statechart
Model Diagrams
Activity
Test
Model Diagrams
Test Model
Use Case
Use Case Diagrams
Model
Class Object
Diagrams Diagrams
Analysis Component
Model
Diagrams
Deployment
Design Diagrams
Model
Sequence
Test model refers to Diagrams
Depl. all other models and
Model uses corresponding Collaboration
diagrams Diagrams
Impl. Statechart
Model Diagrams
Activity
Test
Model Diagrams
39
Overview of the Unified Process
• The Unified Process is

— Iterative and incremental
— Use case driven
— Architecture-centric
— Risk confronting
Use Case Driven
Req.ts Analysis Design Impl. Test
Use Cases bind these workflows together
40
Use Cases Drive Iterations
• Drive a number of development activities

— Creation and validation of the system’s
architecture
— Definition of test cases and procedures
— Planning of iterations
— Creation of user documentation
— Deployment of system
• Synchronize the content of different models
Architecture-Centric
• Models are vehicles for visualizing, specifying,

constructing, and documenting architecture
• The Unified Process prescribes the successive
refinement of an executable architecture
time
Architecture
41
Overview of the UML
• The UML is a language for
— visualizing
— specifying
— constructing
— documenting
the artifacts of a software-intensive system
• There are 4 key elements :
— Modeling elements
— Relationships
— Extensibility Mechanisms
— Diagrams
Modeling Elements
• Structural elements
— class, interface, collaboration, use case,
active class, component, node
• Behavioral elements
— interaction, state machine
• Grouping elements
— package, subsystem
• Other elements
— note
42
Relationships
• Dependency
• Association
• Generalization
• Realization
Extensibility Mechanisms
• Stereotype
• Tagged value
• Constraint
43
Models, Views, and Diagrams
A model is a complete
description of a system State
from a particular State
Diagrams
Class
Diagrams
perspective Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Sequence Diagrams
Diagrams
Diagrams
Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Models Component
Diagrams
Diagrams Diagrams
Scenario Component
Scenario
Diagrams
Component
Diagrams
Deployment
Statechart
Diagrams Diagrams
Diagrams Diagrams
Activity
Diagrams
Diagrams
• A diagram is a view into a model
— Presented from the aspect of a particular
stakeholder
— Provides a partial representation of the system
— Is semantically consistent with other views
• In the UML, there are nine standard diagrams

— Static views: use case, class, object, component,
deployment
— Dynamic views: sequence, collaboration,
statechart, activity
44
Use Case Diagram
• Captures system functionality as seen by users
Use Case Diagram

• Captures system functionality as seen by
users
• Built in early stages of development
• Purpose
— Specify the context of a system
— Capture the requirements of a system
— Validate a system’s architecture
— Drive implementation and generate test cases
• Developed by analysts and domain experts
45
Class Diagram
• Captures the
vocabulary of a
system
Class Diagram
• Captures the vocabulary of a system
• Built and refined throughout development
• Purpose
— Name and model concepts in the system
— Specify collaborations
— Specify logical database schemas
• Developed by analysts, designers, and
implementers
46
Object Diagram
• Captures instances and links
Object Diagram
• Shows instances and links
• Built during analysis and design
• Purpose
— Illustrate data/object structures
— Specify snapshots
• Developed by analysts, designers, and
implementers
47
Component Diagram
• Captures the physical structure of the
implementation
Component Diagram
• Captures the physical structure of the
implementation
• Built as part of architectural specification
• Purpose
— Organize source code
— Construct an executable release
— Specify a physical database
• Developed by architects and
programmers
48
Deployment Diagram
• Captures the
topology of a
system’s
hardware
Deployment Diagram
• Captures the topology of a system’s
hardware
• Built as part of architectural specification
• Purpose
— Specify the distribution of components
— Identify performance bottlenecks
• Developed by architects, networking
engineers, and system engineers
49
Sequence Diagram
• Captures
dynamic
behavior (time-
oriented)
• Purpose
— Model flow of
control
— Illustrate typical
scenarios
Collaboration Diagram
• Captures dynamic behavior
(message-oriented)
• Purpose
– Model flow of control
– Illustrate coordination of
object structure and control
50
Statechart Diagram
• Captures dynamic behavior (event-oriented)
• Purpose
— Model object lifecycle
— Model reactive objects (user interfaces, devices,
etc.)
Activity Diagram
• Captures dynamic
behavior (activity-
oriented)
• Purpose
— Model business
workflows
— Model operations
51
Architecture and the UML
Design View Implementation View
Classes, interfaces,
collaborations Components
Use cases
Use Case View
Process View Deployment View
Active classes Nodes

Organization Dynamics
Package, subsystem Interaction
State machine
Architecture and Models
Use Case Analysis Design Depl. Impl. Test

Model Model Model Model Model Model
Models
Views
Architecture embodies a collection of views of the models
52
Chương 5
NĂÆM BĂÆT YÏU CÊU HĐT

Cac artifacts cền tao ra
Cac workers tham gia
Qui trònh phên tñch
Khoa CNTT Chương 5: Năm băt y u c ̀u hương ₫ ́i tương
M u  c ₫ È c h c u  a h o a  t ₫ é  n g n ă  m b ă  t yãu c Ý ̀ u
Muc ₫ ch cua hoat ₫ ng năm băt y u c ̀u la x y dưng m h nh h 
th ́ng ma se ₫ươc x y dưng băng cach dung cac use-case. Cac ₫i ̉m
băt ₫ ̀u cho hoat ₫ ng nay kha ₫a dang :
tư m h nh nghi p vu (business model) cho cac ưng dung nghi p
vu.
tư m h nh lĩnh vưc (domain model) cho cac ưng dung nhung
(embeded).
tư ₫ăc ta y u c ̀u cua h  th ́ng nhưng ₫ươc tao bơi nhom khac
va/hoăc dung cac phương phap ₫ăc ta khac (th du như hương
c ́u truc).
tư 1 ₫i ̉m nao ₫o năm giưa cac ₫i ̉m xu ́t phat tr n.
53
C a  c artifa ct s c Ý ̀ n ta  o r a tr o n g n ă  m b ă  t yãu c Ý ̀ u
M h nh use-case :
actor : ngươi/h  th ́ng ngoai/thi ́t bị ngoai tương tac vơi h  th ́ng
use-case : cac chưc năng co nghĩa cua h  th ́ng cung c ́p cho
actor.
— flow of events
— cac y u c ̀u ₫ăc bi t cua use-case
₫ăc ta ki ́n truc (view of use-case model)
bang thu t ngư
cac prototype giao di n vơi user (user-interface prototype)
C a  c artifa ct s c Ý ̀ n ta  o r a tr o n g n ă  m b ă  t yãu c Ý ̀ u
1
Use-Case Model Use-Case System
* *
Use - Case
Actor
54
C a  c w o r k er s tr o n g n ă  m b ă  t yãu c Ý ̀ u
System Use-case User-Interface Architect

Analyst Specifier Designer
chịu trach nhi m v ̀ chịu trach nhi m v ̀ chịu trach nhi m v ̀
chịu trach nhi m v ̀
Use-Case Actor Glossary Use-Case User Interface Architecture

Model Prototype Description
Q u i trÉnh n ă  m b ă  t yãu c Ý ̀ u
Find Actors & Structure the

System Analyst Use-Case Model
Use-Cases
Prioritize
Architect Use-Cases
Use-Case
Detail a
Specifier Use-Case
Prototype
User-Interface
Designer User-Interface
55
T É m A ct o r s & U s e c a s e s
Muc ₫ ch nh n dang actor va use-case la ₫ ̉ :
Giơi han h  th ́ng vơi m i trương bao quanh no.
Phat hoa ai va cac g se tương tac vơi h  th ́ng va h  th ́ng cung
c ́p cac chưc năng g .
Năm băt va ₫ịnh nghĩa danh sach cac thu t ngư chung thi ́t y ́u
cho vi c tao cac ₫ăc ta v ̀ cac chưc năng cua h  th ́ng.
Hoat ₫ ng nay g ̀m 4 bươc :
T m cac actor cua h  th ́ng.
T m cac use cases cua h  th ́ng.
Mi u ta văn tăt v ̀ tưng use-case.
Mi u ta toan th ̉ m h nh use-case.
T É m A ct o r s
Vi c t m cac actor phu thu c vao ₫i ̉m xu ́t phat : n ́u xu ́t phat tư m
h nh nghi p vu hay m h nh lĩnh vưc th vi c t m actor r ́t ₫ơn gian. Con
n ́u xu ́t phat tư cac y ni m mơ h ̀ th hay tra lơi cac c u hoi sau :
Ai la ngươi sư dung chưc năng ch nh cua h  th ́ng ?
Ai c ̀n sư h ̃ trơ tư h  th ́ng ₫ ̉ thưc hi n c ng vi c thương nh t
cua ho ?
Ai phai thưc hi n c ng vi c bao dương, quan trị va giư cho h 
th ́ng hoat ₫ ng ?
H  th ́ng se ki ̉m soat thi ́t bị ph ̀n cưng nao ?
H  th ́ng ₫ang x y dưng c ̀n tương tac vơi nhưng h  th ́ng khac
kh ng ? H  th ́ng nao ?
Ai hoăc v t th ̉ nao quan t m ₫ ́n hay chịu anh hương bơi k ́t
qua ma h  th ́ng ph ̀n m ̀m tao ra ?
56
T É m U s e-C a s e s
Vi c t m cac use-case phu thu c vao ₫i ̉m xu ́t phat : n ́u xu ́t phat tư
m h nh nghi p vu hay m h nh lĩnh vưc th vi c t m use-case r ́t ₫ơn
gian. Con n ́u xu ́t phat tư cac y ni m mơ h ̀ th hay tra lơi cac c u hoi
sau :
Actor y u c ̀u chưc năng g cua h  th ́ng ?
Actor c ̀n phai ₫oc, tao, xoa, sưa ₫ ̉i hoăc lưu trư th ng tin nao
cua h  th ́ng ?
Actor c ̀n thi ́t phai ₫ươc canh bao v ̀ nhưng sư ki n trong h 
th ́ng, hay actor c ̀n phai bao hi u cho h  th ́ng v ̀ v ́n ₫ ̀ nao
₫o kh ng ?
H  th ́ng co th ̉ h ̃ trơ m t s ́ c ng vi c thương nh t cua actor
nao ₫o kh ng ?
M iã u ta v ăn tăt tưng U s e- C a s e s

M ̃i use-case sau khi t m ₫ươc, n n ₫ươc ₫ăt t n, ₫ươc mi u ta băng vai
c u t ̉ng k ́t cac hoat ₫ ng r ̀i sau ₫o ₫ăc ta tưng bươc h  th ̀ng c ̀n g
₫ ̉ tương tac vơi actor.
Dung lươc ₫ ̀ va cac flow of events ₫ ̉ mi u ta m h nh use-case t ̉ng
th ̉, ₫ăc bi t la cac m ́i quan h  giưa cac use-case va vơi actor.
Quan h  giưa cac actors : t ̉ng quat hoa (generalization).
Quan h  giưa actor va use-case : li n k ́t (association).
Quan h  giưa cac use-cases :
t ̉ng quat hoa.
include
extend
57
Cac né́i quan hã giưa cac actor va use-cases
Use-Case Z
Actor A Actor B Use-Case X
Use-Case Y
<<extend>> Use-Case D
Use-Case A Use-Case B
<<include>>
Use-Case C
Cac né́i quan hã giưa cac use-cases va use-cases

<<include>>
User Maint enance POS Login

Store Manager
<<extend>>
<<extend>>
<<exten...
Edit User Information

Add New User
Remove User
58
Cac né́i quan hã giưa cac actor va actor
Quan h  giưa cac actors : t ̉ng Cus tom ers
quat hoa (generalization).
Th du Customer la actor t ̉ng
quat hoa cua cac actor Online C us tom er
Customer, Telephone Customer,
Retail Store Customer.
Lưu y actor t ̉ng quat hoa
thương kh ng co th t, no la
ph ̀n tư trưu tương. R etail S tor e O nline
Cu s tom er Cus tom er
Telephone
C us tom er
Lươc ₫é̀ use-case Sales:From Order to Delivery
Order Goods & Services
Ini tiator
Confirm Order Initiator
Initiator
Initiator
Buyer Initiator Seller
Invoice Buyer
Send Reminders
Pay Invoice <<extend>>

Accou nti ng System
Perform Transaction Pay Overdraft Fee
59
Lươc ₫é̀ trang thai cua use-case Pay Invoice
Browsing
schedule reject
Invoice
Scheduled
pay on due date
Invoice Paid Invoice

Cancelled
Miãu ta té̉ng thã̉ mé hÉnh Use-Cases

X y dưng cac lươc ₫ ̀ use-case va cac ₫ăc ta giai th ch m h nh use-
case, nh ́t la cach thưc ma cac use-case quan h  vơi nhau hay vơi cac
actor :
lươc ₫ ̀ mi u ta cac use-case phuc vu cho 1 actor hay 1
use-case nghi p vu.
₫ ̉ ₫am bao t nh nh ́t quan khi mi u ta nhi ̀u use-case ₫ ̀ng
thơi, n n x y dưng 1 bang thu  ngư chung (glossary).
m h nh use-case co th ̉ ₫ươc t ̉ chưc dang c y thư b c
nhơ cac package use-case.
x y dưng ₫ăc ta "survey" cho m h nh use-case t ̉ng th ̉ va
nhơ khach hang va ngươi dung ki ̉m tra, ₫anh gia lai.
60
Săp thư tư ưu tiãn cac use-case
cac use-case t m ₫ươc kh ng phai thi ́t y ́u như nhau, do ₫o
ki ́n truc sư c ̀n săp x ́p thư tư ưu ti n chung ₫ ̉ xac ₫ịnh
use-case nao n n ₫ươc phat tri ̉n trươc, use-case nao ₫ươc
phat tri ̉n sau.
k ́t qua cua hoat ₫ ng nay la x y dưng ₫ươc goc nh n ki ́n
truc cua m h nh use-case, no ₫ươc dung ₫ ̉ hoach ₫ịnh
cac bươc lăp cung vơi cac y ́u t ́ khac như nghi p vu, kinh
t ́...
Chi tiã́t hoa Use-Case

Muc ₫ ch la ₫ăc ta "flow of events" cho tưng use-case :
c ́u truc ₫ăc ta use-case.
₫ăc ta use-case bao g ̀m nhưng g .
h nh thưc hoa ₫ăc ta use-case.
C ́u truc ₫ăc ta use-case :
g ̀m 1 lu ̀ng c ng vi c cơ ban va cac lu ̀ng phu.
Cac lu ̀ng phu co th ̉ xay ra v cac ly do :
Actor co th ̉ chon thưc hi n 1 trong nhi ̀u nhanh.
N ́u hơn 1 actor dung use-case, cac hoat ₫ ng cua ho co
th ̉ anh hương l ̃n nhau.
H  th ́ng co th ̉ phat hi n l ̃i nh p tư actor.
1 s ́ tai nguy n kh ng hoat ₫ ng t ́t lam cho use-case
kh ng hoan t ́t c ng vi c ₫ung cua no.
61
Đăc ta use-case gé̀m nhưng gÉ ?
n n ₫ịnh nghĩa trang thai băt ₫ ̀u.
khi nao va cach nao use-case băt ₫ ̀u.
thư tư cac hoat ₫ ng ₫ươc thưc hi n.
khi nao va cach nao use-case k ́t thuc.
n n ₫ịnh nghĩa trang thai k ́t thuc.
kh ng cho phep nhi ̀u 'path' thưc thi.
Co th ̉ mi u ta lu ̀ng thi hanh phu trong ₫ăc ta lu ̀ng cơ
ban.
Đăc ta lu ̀ng phu ₫ươc rut tr ch tư lu ̀ng cơ ban.
Tương tac giưa h  th ́ng va actor va chung trao ₫ ̉i nhưng
g.
Vi c dung cac ₫ ́i tương, gia trị, tai nguy n trong h  th ́ng.
Phai mi u ta ro rang h  th ́ng lam g va actor lam g .
HÉnh thưc hoa use-case (Formalizing)

Khi sư tương tac giưa actor va use-case g ̀m nhi ̀u trang thai
phưc tap ta n n dung ky thu t m h nh trưc quan ₫ ̉ di ̃n ta use-
case v no giup nha ph n t ch hi ̉u ro hơn v ̀ use-case :
lươc ₫ ̀ trang thai UML co th ̉ ₫ươc dung ₫ ̉ mi u ta trang
thai cua use-case va sư chuy ̉n giưa cac trang thai.
lươc ₫ ̀ hoat ₫ ng co th ̉ ₫ươc dung ₫ ̉ mi u ta sư chuy ̉n
trang thai chi ti ́t hơn dươi dang cac hoat ₫ ng.
lươc ₫ ̀ tương tac co th ̉ ₫ươc dung ₫ ̉ mi u ta cac tương
tac giưa ₫ ́i tương use-case va ₫ ́i tương actor.
Kh ng n n lam dung cac lươc ₫ ̀ v ₫ y la ng n ngư cua nha phat
tri ̉n, cac khach hang va ngươi dung kho long hi ̉u n ̉i.
62
CÝ́u truc lai mé hÉnh Use-Case
M h nh use-case ₫ươc c ́u truc lai ₫ ̉ :
rut tr ch cac use-case t ̀ng quat va dung chung bơi cac use-
case ₫ăc bi t hơn.
rut tr ch cac use-case nhi m y va phu th m ₫ ̉ nơi r ng use-
case khac.
Trươc khi hoat ₫ ng nay xay ra :
nha ph n t ch ₫a nh n di n tương ₫ ́i ₫ ̀y ₫u cac actor va
use-case, mi u ta chung trong cac lươc ₫ ̀ ₫ ̉ c ́u thanh m
h nh use-case t ̉ng th ̉.
ngươi ₫ăc ta use-case ₫a phat tri ̉n ₫ăc ta chi ti ́t cho m ̃i
use-case.
CÝ́u truc lai mé hÉnh Use-Case

Cac c ng vi c cu th ̉ :
Nh n dang cac use-case t ̉ng quat ₫ươc dung chung.
Nh n dang cac use-case co quan h  "extend".
Nh n dang cac use-case co quan h  "include".
M t s ́ ₫i ̀u lưu y :
C ́u truc cac use-case va m ́i quan h  giưa chung n n phan
anh cac chưc năng thưc t ́.
M ̃i use-case c ̀n ₫ươc xư ly như 1 artifact ri ng bi t, do ₫o
kh ng n n chon use-case qua lơn hay qua nho.
Tranh chia nho use-case.
63
Chương 6
PHÊN TÑCH HƯƠNG ĐÖI TƯƠNG

Qui trònh phên tñch
Khoa CNTT Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương
Muc ₫Èch cua phÝn tÈch yãu cÝ̀u

Muc ₫ ch cua hoat ₫ ng ph n t ch y u c ̀u la x y dưng m h nh ph n
t ch vơi cac ₫ăc ₫i ̉m sau :
dung ng n ngư cua nha phat tri ̉n ₫ ̉ mi u ta m h nh.
th ̉ hi n goc nh n tư b n trong cua h  th ́ng.
₫ươc c ́u truc tư cac class ph n t ch va cac package ph n t ch.
₫ươc dung chu y ́u bơi nha phat tri ̉n ₫ ̉ hi ̉u cach thưc tao h nh
dang h  th ́ng.
loai trư moi chi ti ́t dư thưa, kh ng nh ́t quan.
phat hoa cac hi n thưc cho cac chưc năng b n trong h  th ́ng.
₫ịnh nghĩa cac d ̃n xu ́t use-case, m ̃i d ̃n xu ́t use-case c ́p
ph n t ch mi u ta sư ph n t ch 1 use-case.
64
Cac artifacts cÝ̀n tao ra trong phÝn tÈch yãu cÝ̀u
M h nh ph n t ch = h  th ́ng ph n t ch :
cac class ph n t ch
— boundary class
— entity class.
— control class
cac d ̃n xu ́t use-case c ́p ph n t ch :
— cac lươc ₫ ̀ class ph n t ch
— cac lươc ₫ ̀ tương tac (c ng tac,...).
— 'flow of events' ơ c ́p ph n t ch
— cac y u c ̀u ₫ăc bi t cua use-case
cac package ph n t ch
₫ăc ta ki ́n truc (view of analysis model)
Cac artifacts cÝ̀n tao ra trong phÝn tÈch yãu cÝ̀u
*
1
*
Analysis Analysis Analysis Package
Model System
* * *
*
Analysis Class Use-Case Realization -
Analysis
65
Cac workers trong phÝn tÈch yãu cÝ̀u
Use-Case Component
Architect
Engineer Engineer
Analysis Architecture Use-Case Analysis Analysis

Model Description Realization - class package
Analysis
Qui trÉnh phÝn tÈch yãu cÝ̀u
Architect Architectural
Analysis
Use-Case Analyze a
Engineer Use-Case
Analyze a Analyze a
Component
Engineer Class Package
66
PhÝn tÈch kiã́n truc : nhÝn dang cac package phÝn tÈch
Muc ₫ ch cua ph n t ch ki ́n truc la phat hoa m h nh ph n t ch va ki ́n
truc h  th ́ng băng cach nh n dang cac package ph n t ch, cac class
ph n t ch d ̃ th ́y va cac y u c ̀u ₫ăc bi t chung cho h  th ́ng.
Cac package ph n t ch giup t ̉ chưc h  th ́ng thanh nhưng ₫ơn vị nho
d ̃ quan ly. M ̃i package chưa 1 s ́ use-case vơi t nh ch ́t sau :
cac use-case h ̃ trơ cho cung 1 qui tr nh nghi p vu.
cac use-case h ̃ trơ cho cung 1 actor.
cac use-case co quan h  l ̃n nhau : t ̉ng quat hoa, include va
extend.
Theo thơi gian, khi vi c ph n t ch ti ́n tri ̉n, sư tinh ch ́ c ́u truc cac
package se ti ́n tri ̉n theo.
3 loai class phÝn tÈch

Co 3 loai (stereotype) class ph n t ch :
class bi n (boundary class) m h nh sư tương tac giưa actor va h 
th ́ng
class thưc th ̉ (entity class) m h nh th ng tin c ̀n cho h  th ́ng,
loai th ng tin co t nh b ̀n vưng, t ̀n tai l u dai.
class ₫i ̀u khi ̉n (control class) m h nh vi c xư ly, c ng tac, giao
tac trong use-case.
Boundary class Entity class Control class
67
PhÝn tÈch kiã́n truc : nhÝn dang cac class thưc thã̉ dã̃ thÝ́y
Tư cac class lĩnh vưc hay cac class nghi p vu trong bươc năm băt y u
c ̀u, ₫ ̀ nghị 1 s ́ class thưc th ̉ quan trong nh ́t (tư 10-20).
Cac class ph n t ch con lai se ₫ươc nh n dang trong hoat ₫ ng ph n
t ch use-case.
Cac y u c ̀u ₫ăc bi t cung ₫ươc nh n dang ₫ ̉ ₫ươc xư ly trong cac
bươc sau, chung g ̀m :
t nh b ̀n vưng.
sư ph n tan & ₫ ̀ng thơi.
cac t nh ch ́t an toan dư li u.
₫ ̀ khang vơi l ̃i.
quan ly giao tac.
T nh ch ́t cua m ̃i y u c ̀u ₫ăc bi t se ₫ươc c n nhăc sau trong tưng
class va tưng d ̃n xu ́t use-case.
PhÝn tÈch use-case

Ph n t ch use-case la ₫ ̉ :
nh n dang cac class ph n t ch co ₫ ́i tương cua chung tham
gia vao vi c thưc hi n 'flow of events' cua use-case.
ph n ph ́i hanh vi cua use-case băng cach cho cac ₫ ́i
tương ph n t ch tương tac nhau.
năm băt 1 s ́ y u c ̀u ₫ăc bi t cho d ̃n xu ́t use-case.
68
PhÝn tÈch use-case : nhÝn dang cac class phÝn tÈch
Trong bươc nay ta nh n dang cac class ₫i ̀u khi ̉n, bi n, thưc th ̉ c ̀n
thi ́t ₫ ̉ hi n thưc use-case va phat hoa t n, trach nhi m, thu c t nh va
cac m ́i quan h  giưa chung. Dung cac hương d ̃n sau :
nh n dang cac class thưc th ̉ băng cach chu y cac th ng tin trong
₫ăc ta use-case va trong m h nh lĩnh vưc.
nh n dang class bi n cơ sơ cho m ̃i class thưc th ̉ vưa t m ₫ươc.
nh n dang class bi n trung t m cho m ̃i actor la con ngươi.
nh n dang class bi n trung t m cho m ̃i actor la h  th ́ng ngoai
hay thi ́t bị I/O.
nh n dang class ₫i ̀u khi ̉n co trach nhi m xư ly trong d ̃n xu ́t
use-case.
T p hơp cac class ph n t ch tham gia vao d ̃n xu ́t use-case thanh 1
(hay nhi ̀u) lươc ₫ ̀ class.
ThÈ du vã̀ lươc ₫é̀ class phÝn tÈch cho use-case Pay Invoice
Order Configmation
Order Handler
Invoice
Buyer Payment Request UI

(f rom Use-Case Model)
Payment Scheduler
Payment Request
69
PhÝn tÈch use-case : miãu ta sư tương tac giưa cac ₫é́i tương phÝn tÈch
C ̀n chu y cac ₫i ̉m sau trong lươc ₫ ̀ c ng tac :
p. tư actor gơi 1 th ng bao ₫ ́n class bi n ₫ ̉ k ch hoat use-case.
m ̃i class ph n t ch n n co t nh ́t 1 ₫ ́i tương tham gia vao lươc
₫ ̀ c ng tac.
chưa v i k ́t hơp tac vu cu th ̉ cho th ng bao.
cac m ́i n ́i trong lươc ₫ ̀ c ng tac thương la 'instance' cua m ́i
quan h  k ́t hơp giưa cac class tương ưng.
chưa t p trung vao thư tư thơi gian cac th ng bao.
Lươc ₫ ̀ c ng tac n n xư ly t ́t ca m ́i quan h  cua use-case
₫ươc hi n thưc.
c ̀n b ̉ sung ₫ăc ta dang văn ban vao lươc ₫ ̀ c ng tac, ₫ăc ta
nay n n ₫ươc ₫ ̉ vao 'flow of events c ́p ph n t ch".
Lươc ₫é̀ céng tac

C ̀n chu y cac ₫i ̉m sau trong lươc ₫ ̀ c ng tac :
cac th ng ₫i p ₫ươc ₫anh s ́ theo ki ̉u ph n c ́p.
— 3.4.2 xay ra sau 3.4.1 va ca 2 ₫ươc l ̀ng trong 3.4
— 3.4.3a va 3.4.3b xay ra ₫ ̀ng thơi va ₫ươc l ̀ng trong 3.4
cu phap t ̉ng quat cua 1 th ng ₫i p :
precedessor guard-condition sequence-expression return-value :=
message-name argument-list
Vñ du :
— 2/ 1.3.1: p := find(specs)
— 1.1, 4.2/ 3.2 *[i:=1..6]: invert(x, color)
70
Cac thanh ph ̀n cua lươc ₫ ̀ c ng tac :
5: Get
: Order Confirmation
4: Get
: Order Handler
3: Check Invoice 2: Browse

: Invoice
6: Schedule InVoice for payment 9: setStatus(scheduled)
1: Browse Invoice
: Payment Request UI 7: Schedule payment
: Buyer
8: New
: Payment Scheduler : Payment Request
PhÝn tÈch class

Muc ₫ ch cua vi c ph n t ch class la :
nh n dang va duy tr cac nghĩa vu, trach nhi m cua class ph n
t ch dưa vao vai tro cua no trong d ̃n xu ́t use-case.
nh n dang va duy tr cac thu c t nh va cac m ́i quan h  cua class
ph n t ch.
năm băt cac y u c ̀u ₫ăc bi t li n quan ₫ ́n vi c hi n thưc class
ph n t ch.
71
PhÝn tÈch class : nhÝn dang cac nghĩa vu
t ̉ hơp cac vai tro ma class ₫ong trong cac d ̃n xu ́t use-case
khac nhau se cho ta 1 s ́ nghĩa vu cua class.
nghi n cưu cac lươc ₫ ̀ class va lươc ₫ ̀ tương tac trong cac d ̃n
xu ́t use-case co class tham gia.
₫ i khi c ̀n nghi n cưu 'flow of events c ́p ph n t ch' cua d ̃n xu ́t
use-case ₫ ̉ t m th m cac nghĩa vu cac class.
PhÝn tÈch class : nhÝn dang cac thuéc tÈnh

M ̃i nghĩa vu thương c ̀n 1 s ́ thu c t nh. Dung cac hương d ̃n sau :
t n thu c t nh n n la danh tư.
ki ̉u thu c t nh ơ c ́p ph n t ch n n ơ c ́p y ni m, chưa c ̀n ki ̉u
cu th ̉, n n dung lai ki ̉u ₫a co khi ₫ăc ta ki ̉u cho thu c t nh mơi.
n ́u class ph n t ch qua phưc tap, n n tach 1 s ́ thu c t nh phưc
tap ra thanh class ri ng.
thu c t nh cua class thưc th ̉ thương d ̃ th ́y.
thu c t nh cua class bi n giao ti ́p vơi ngươi thương mi u ta th ng
tin ₫ươc xư ly bơi user như cac field text,...
thu c t nh cua class bi n giao ti ́p vơi h  th ́ng ngoai thương
mi u ta cac t nh ch ́t cua giao ti ́p.
thu c t nh cua class ₫i ̀u khi ̉n t khi co.
₫ i khi kh ng c ̀n cac thu c t nh h nh thưc.
72
PhÝn tÈch class : nhÝn dang mé́i quan hã giưa cac class
Cac ₫ ́i tương tương tac nhau th ng qua cac lươc ₫ ̀ c ng tac. Cac m ́i
li n k ́t nay thương la 'instance' cua m ́i quan h  k ́t hơp giưa cac
class. Cac m ́i li n k ́t nay cung co th ̉ am chỉ nhu c ̀u v ̀ sư g p
nhi ̀u ₫ ́i tương. M ́i quan h  g p n n ₫ươc dung khi cac ₫ ́i tương
mi u ta :
cac khai ni m chưa v t ly khai ni m khac (xe chưa tai x ́ va
khach)
cac khai ni m ₫ươc x y dưng tư cac khai ni m khac (xe g ̀m cac
banh xe va ₫ ng cơ).
cac khai ni m tao thanh t p hơp y ni m nhi ̀u ₫ ́i tương (gia ₫ nh
g ̀m cha, me va con).
Đ ̉ rut tr ch cac hanh vi chung cua nhi ̀u class ph n t ch, ta co th ̉ dung
class t ̉ng quat hoa, nhưng chỉ n n ơ c ́p y ni m.
PhÝn tÈch package

Muc ₫ ch cua ph n t ch package la :
₫am bao tưng package ph n t ch ₫ c l p vơi cac package khac
nhi ̀u như co th ̉ co.
₫am bao package ph n t ch hoan thanh muc ₫ ch cua no la hi n
thưc 1 s ́ class lĩnh vưc hoăc 1 s ́ use-case.
mi u ta cac phu thu c sao cho co th ̉ ươc lương anh hương cua
cac thay ₫ ̉i trong tương lai.
Dung cac hương d ̃n sau :
₫am bao package chưa cac class ₫ung, c ́ găng cho t nh k ́t d nh
cao băng cach g p cac class co m ́i quan h  chưc năng.
han ch ́ t ́i ₫a sư phu thu c giưa cac package, ph n ph ́i lai cac
class qua phu thu c vao package khac.
73
Chương 7
THIÏT KÏ HƯƠNG ĐÖI TƯƠNG

Qui trònh thiḯt kḯ
Khoa CNTT Chương 7: Thi ́t k ́ hương ₫ ́i tương
Muc ₫Èch cua thiã́t kã́

Muc ₫ ch cua c ng vi c thi ́t k ́ la :
₫at tơi sư hi ̉u bi ́t s u săc cac v ̀n ₫ ̀ v ̀ cac rang bu c va cac
y u c ̀u kh ng chưc năng co li n quan ₫ ́n ng n ngư l p tr nh, sư
dung lai linh ki n, HĐH, c ng ngh  ph n tan, ₫ ̀ng thơi, database,
giao di n, quan ly giao tac.
tao ra ₫ ̀u vao cho hoat ₫ ng hi n thưc băng cach năm băt cac
h  th ́ng con, cac interface va cac class.
chia c ng vi c hi n thưc ra nhi ̀u ph ̀n d ̃ quan ly va xư ly bơi
cac ₫ i khac nhau (co th ̉ ₫ ̀ng thơi).
năm băt cac interface ch nh giưa cac h  th ́ng con.
co th ̉ hi ̉n thị trưc quan va xem xet bang thi ́t k ́ dung cac ky
hi u chung.
tao ra mưc trưu tương cua sư hi n thưc h  th ́ng.
74
Cac artifacts cÝ̀n tao ra trong thiã́t kã́
M h nh thi ́t k ́ = h  th ́ng thi ́t k ́ :
cac h  th ́ng con
cac class thi ́t k ́.
cac interface cua h  th ́ng con va class.
cac d ̃n xu ́t use-case c ́p thi ́t k ́ :
— cac lươc ₫ ̀ class
— cac lươc ₫ ̀ tương tac (tr nh tư, trang thai,...).
— 'flow of events' ơ c ́p thi ́t k ́.
— cac y u c ̀u c ́p hi n thưc.
₫ăc ta ki ́n truc (view of design model)
M h nh b ́ tr :
₫ăc ta ki ́n truc (view of deployment model)
*
1 *
Design Desgin Design
Model System Subsystem
*
* * * * *
Interface
Use-Case Realization -
Desgin Class
Design
75
Đăc ₫iã̉m cua class thiã́t kã́
Class thi ́t k ́ la sư trưu tương trưc ti ́p cua class hi n thưc :
dung ng n ngư l p tr nh ₫ ̉ mi u ta class thi ́t k ́.
thương xac ₫ịnh t ̀m vưc cua cac thanh ph ̀n.
cac m ́i quan h  co y nghĩa trưc ti ́p tơi hi n thưc : t ̉ng quat hoa
→ thưa k ́, quan h  g p, k ́t hơp thanh thu c t nh tương ưng.
method trong thi ́t k ́ → method trong hi n thưc.
co th ̉ delay vi c xư ly 1 s ́ y u c ̀u tơi luc hi n thưc.
class thi ́t k ́ thương co stereotype tương ưng vơi ng n ngư l p
tr nh : <<form>>, <<class module>>, <<user control>>...
class thi ́t k ́ hi n thưc (hay cung c ́p) 1 interface.
co th ̀ co 1 s ́ class active, nhưng n n t ̀n tai trong m h nh
process thay v trong m h nh thi ́t k ́.
Cac wokers trong hoat ₫éng thiã́t kã́
Architect Use-Case Component

Engineer Engineer
Desgin Deployment Architecture Use-Case Design Design Interface

Model Model Description Realization - class Subsystem
Desgin
76
Qui trÉnh thiã́t kã́
Design
Use-Case Design a
Engineer Use-Case
Design a Design a
Component
Engineer Class Subsystem
Thiã́t kã́ kiã́n truc : muc ₫Èch

Muc ₫ ch cua thi ́t k ́ ki ́n truc la phat hoa m h nh thi ́t
k ́ va m h nh b ́ tr cung ki ́n truc cua chung băng
cach nh n dang cac v ́n ₫ ̀ sau :
Cac nut t nh toan va cac c ́u h nh mang cua chung.
Cac h  th ́ng con va interface cua chung.
Cac class thi ́t k ́ co y nghĩa ki ́n truc như cac class
chu ₫ ng.
Cac cơ ch ́ thi ́t k ́ t ̉ng quat xư ly cac y u c ̀u chung
như t nh b ̀n vưng, hi u qua,... (₫ươc năm băt trong cac
class ph n t ch va cac d ̃n xu ́t use-case ơ c ́p ph n
t ch.
77
Thiã́t kã́ kiã́n truc : nhÝn dang nut va cÝ́u hÉnh mang
C ́u h nh mang v t ly se anh hương ₫ ́n ki ́n truc ph ̀n m ̀m, g ̀m cac
kh a canh :
cac nut nao li n quan, kha năng v ̀ b  nhơ va c ng su ́t t nh cua
nut.
ki ̉u n ́i k ́t va ki ̉u giao thưc nao giưa cac nut.
cac t nh ch ́t v ̀ sư n ́i k ́t va giao thưc như băng th ng, ₫  săn
sang, ch ́t lương...
c ̀n kha năng t nh dư thưa, ch ́ ₫  ₫ ̀ khang l ̃i, di cư process,
sao lưu dư li u,...
Thiã́t kã́ kiã́n truc : nhÝn dang hã thé́ng con va interface cua chung
Chia c ng vi c thi ́t k ́ tư ₫ ̀u hay khi m h nh thi ́t k ́ phat tri ̉n thanh
phưc tap c ̀n ₫ươc chia nho. M t s ́ h  th ́ng con ₫ươc dung lai tư cac
project khac :
nh n dang cac h  th ́ng con c ́p ưng dung
nh n dang cac h  th ́ng con c ́p giưa va c ́p h  th ́ng
₫ịnh nghĩa sư phu thu c giưa cac h  th ́ng con.
nh n dang giao ti ́p cua cac h  th ́ng con.
78
Thiã́t kã́ kiã́n truc : nhÝn dang cac class thiã́t kã́ quan trong vã̀ kiã́n truc
C ̀n nh n dang cac class thi ́t k ́ quan trong v ̀ măt ki ́n truc ₫ ̉ lam
ti ̀n ₫ ̀ cho hoat ₫ ng thi ́t k ́, cac class khac se ₫ươc nh n dang trong
vi c thi ́t k ́ use-case.
nh n dang cac class thi ́t k ́ tư cac class ph n t ch tương ưng
nh n dang cac class chu ₫ ng khi chu y y u c ̀u ₫ ̀ng thơi tr n h 
th ́ng :
— cac y u c ̀u v ̀ hi u qua, ₫  săn sang, throughput cua h 
th ́ng
— sư ph n tan cua h  th ́ng tr n cac nut.
— cac y u c ̀u khac như khơi ₫ ng, k ́t thuc, tranh deadlock,
tranh bao hoa, c ́u h nh lai cac nut, kha năng n ́i k ́t.
Thiã́t kã́ kiã́n truc : nhÝn dang cac cơ chã́ thiã́t kã́ té̉ng quat
Tư cac y u c ̀u chung va ₫ăc bi t ₫a ₫ươc nh n dang trong ph ̀n ph n
t ch (trong cac class ph n t ch va cac d ̃n xu ́t use-case c ́p ph n t ch),
quy ́t ₫ịnh cach xư ly chung dưa tr n c ng ngh  hi n thưc va thi ́t k ́
săn co. K ́t qua la 1 t p cac cơ ch ́ thi ́t k ́ t ̉ng quat. Cac y u c ̀u c ̀n
xư ly thương li n quan ₫ ́n :
t nh b ̀n vưng.
sư ph n tan & ₫ ̀ng thơi.
cac t nh ch ́t an toan dư li u.
₫ ̀ khang vơi l ̃i.
quan ly giao tac.
79
Thiã́t kã́ Use-Case
Muc ₫ ch cua thi ́t k ́ use-case la :

Nh n dang cac class thi ́t k ́ va cac h  th ́ng con co
object c ̀n cho vi c thưc hi n 'flow of events-design'
cua use-case.
ph n tan hanh vi cua use-case băng cach cho cac
object thi ́t k ́ va h  th ́ng con tương tac nhau.
₫ịnh nghĩa y u c ̀u tr n cac tac vu cua class thi ́t k ́,
h  th ́ng con va interface cua chung.
năm băt cac y u c ̀u c ́p hi n thưc cho use-case.
Thiã́t kã́ Use-Case : nhÝn dang cac class thiã́t kã́

Nh n dang cac class thi ́t k ́ như sau :
nghi n cưu cac class ph n t ch tham gia trong d ̃n xu ́t use-
case c ́p ph n t ch tương ưng, nh n dang cac class thi ́t k ́
n ́i vơi cac class ph n t ch nay.
nghi n cưu cac y u c ̀u ₫ăc bi t trong d ̃n xu ́t use-case
c ́p ph n t ch tương ưng, nh n dang cac class thi ́t k ́ hi n
thưc cac y u c ̀u ₫ăc bi t nay.
gan nghĩa vu cho cac class thi ́t k ́ t m ₫ươc.
n ́u con thi ́u 1 vai class c ̀n cho vi c thi ́t k ́ use-case ₫ăc
bi t, ky sư use-case n n li n h  vơi ki ́n truc sư va ky sư linh
ki n ₫ ̉ ban bac.
x y dưng lươc ₫ ̀ class chưa cac class thi ́t k ́ t m ₫ươc.
80
Thiã́t kã́ Use-Case : miãu ta cac tương tac giưa cac object thiã́t kã́
Dung lươc ₫ ̀ tr nh tư :
lươc ₫ ̀ tr nh tư chưa cac ph ̀n tư actor, ₫ ́i tương thi ́t k ́ va
cac t.bao giưa chung.
n ́u use-case co nhi ̀u lu ̀ng ₫i ̀u khi ̉n khac nhau, n n tao
lươc ₫ ̀ tr nh tư cho tưng lu ̀ng.
n n chuy ̉n lươc ₫ ̀ c ng tac ơ c ́p ph n t ch thanh lươc ₫ ̀
tr nh tư ban ₫ ̀u, tư ₫o phat tri ̉n th m chi ti ́t.
dung 'flow of events', duy t qua cac bươc trong no ₫ ̉ quy ́t
₫ịnh cac tương tac nao c ̀n thi ́t giưa cac ₫ ́i tương thi ́t k ́
va ph ̀n tư actor.
Thiã́t kã́ Use-Case : miãu ta cac tương tac giưa cac object thiã́t kã́
N n chu y cac ghi nh n sau trong vi c x y dưng lươc ₫ ̀ tr nh tư :
n n t p trung vao tr nh tư trong lươc ₫ ̀.
actor gơi th ng bao ₫ ́n 1 ₫ ́i tương thi ́t k ́ ₫ ̉ y u c ̀u thưc
hi n use-case.
m ̃i class thi ́t k ́ n n co t nh ́t 1 ₫ ́i tương tham gia vao
lươc ₫ ̀ tr nh tư.
cac message ₫ươc gơi giưa cac ₫ương ₫ơi s ́ng ₫ ́i tương,
co th ̉ co t n tam va se trơ thanh t n tac vu tương ưng.
dung label va flow of events c ́p thi ́t k ́ ₫ ̉ b ̉ sung lươc ₫ ̀
tr nh tư.
lươc ₫ ̀ tr nh tư n n xư ly t ́t ca m ́i quan h  cua use-case
c ̀n hi n thưc.
81
Cac thanh ph ̀n cua lươc ₫ ̀ c ng tac : (th du lươc ₫ ̀ c ng
tac cho use-case Login cua h  th ́ng ₫ăng ky m n hoc h  t n
chỉ th ng qua Web.
1: login(uname,pswd)
: People
1.2 [succ = true]: welcome

: LoginForm
1.1: succ := Verify(uname,pswd)

: Database
Lươc ₫é̀ trÉnh tư

Cac thanh ph ̀n cua lươc ₫ ̀ tr nh tư : (th du lươc ₫ ̀ tr nh tư
cho use-case Login cua h  th ́ng ₫ăng ky m n hoc h  t n chỉ
th ng qua Web.
: LoginForm : Database
: People
1: submit(uname, psswd) 1.1: verify(uname, psswd)
1.2: welcome
82
Lươc ₫é̀ trang thai
Cac thanh ph ̀n cua lươc ₫ ̀ trang thai : (th du lươc ₫ ̀ trang
thai cho use-case Send/Read e-mail).
hightlight
Composed focus
compose command
entry/ assign ID
exit/ fill date Read
on char/ handle character re-fwd cmd / quote / append subject
entry/ convert to rich text
save command read command / recover( id )
send command[ recipents != null ] / parse unhightlight
Sending sending done Stored logout

do/ send( repc ) entry/ save into folder
Lươc ₫é̀ hoat ₫éng

LoginForm Database
Cac thanh ph ̀n cua
lươc ₫ ̀ hoat ₫ ng : Show input for username
(th du lươc ₫ ̀ hoat and password
₫ ng cho use-case

Verify
Login cua h  th ́ng
₫ăng ky m n hoc h 
t n chỉ th ng qua [ psswd invalid ] [ psswd valid ]
Web.
Reject Welcome
83
Thiã́t kã́ class
Muc ₫ ch cua vi c thi ́t k ́ class la tao ra class thi ́t k ́ hoan
thanh vai tro cua no trong d ̃n xu ́t use-case va cac y u c ̀u phu.
Bao g ̀m vi c duy tr class thi ́t k ́ va cac kh a canh sau cua no :
cac tac vu cua class.
cac thu c t nh cua class.
cac m ́i quan h  ma class tham gia.
cac method cua class (hi n thưc tac vu tương ưng).
cac trang thai cua ₫ ́i tương.
cac phu thu c tơi b ́t ky cơ ch ́ thi ́t k ́ t ̉ng quat nao.
cac y u c ̀u co li n quan ₫ ́n hi n thưc cua class.
sư hi n thưc ₫ung cua b ́t ky interface ma class phai cung
c ́p.
Thiã́t kã́ class : Phat hoa class thiã́t kã́

Bươc ₫ ̀u ta phat hoa cac class thi ́t k ́ tư cac interface va class ph n
t ch : 1 interface co 1 class thi ́t k ́, con class ph n t ch th :
thi ́t k ́ class bi n phu thu c vao c ng ngh  tao interface : form,
activeX control... Đ ̉ y dung cac prototype giao di n vơi user trong
bươc trươc.
thi ́t k ́ class thưc th ̉ thương phu thu c vao c ng ngh  database.
Vi c anh xa tư m h nh hương ₫ ́i tương sang m h nh dư li u
quan h  co th ̉ c ̀n worker, m h nh va c ng vi c ri ng.
c ̀n t p trung thi ́t k ́ class ₫i ̀u khi ̉n, chu y cac nhu c ̀u sau :
— v ̀n ₫ ̀ ph n tan : c ̀n nhi ̀u class thi ́t k ́ tr n cac nut khac nhau
₫ ̉ hi n thưc 1 class ₫i ̀u khi ̉n.
— v ́n ₫ ̀ hi u qua : n n dung 1 class thi ́t k ́ cho 1 class ₫i ̀u khi ̉n
— v ́n ₫ ̀ giao tac: class thi ́t k ́ c ̀n t ch hơp c ng ngh  quan ly
giao tac.
84
Thiã́t kã́ class : NhÝn dang cac tac vu
Nh n dang cac tac vu ma class thi ́t k ́ c ̀n cung c ́p va t ̀m vưc
cua chung (dung cu phap ng n ngư l p tr nh). Cac ₫ ̀u vao cua
bươc nay la :
cac trach nhi m cua b ́t ky class ph n t ch ma d ̃n tơi class
thi ́t k ́.1 trach nhi m tương ưng 1 hay nhi ̀u tac vu, nhưng
ơ ₫ y mơi phat hoa th ng s ́ h nh thưc cac tham s ́.
cac y u c ̀u ₫ăc bi t cua b ́t ky class ph n t ch ma d ̃n tơi
class thi ́t k ́.
cac interface ma class thi ́t k ́ phai cung c ́p.
d ̃n xu ́t use-case c ́p thi ́t k ́ ma class tham gia.
Thiã́t kã́ class : NhÝn dang cac thuéc tÈnh

Tac vu thương ₫oi hoi thu c t nh, c ̀n dưa vao cac hương d ̃n sau
:
chu y thu c t nh cua b ́t ky class ph n t ch ma d ̃n tơi class
thi ́t k ́.1 thu c t nh nay am chỉ 1 hay nhi ̀u thu c t nh cua
class thi ́t k ́.
han ch ́ dung ki ̉u cua ng n ngư l p tr nh cho thu c t nh.
c ́ găng dung ki ̉u ₫a co.
n ́u class thi ́t k ́ qua phưc tap, 1 vai thu c t nh cua no co
th ̉ tach ra thanh cac class ri ng.
n ́u co qua nhi ̀u thu c t nh hay thu c t nh qua phưc tap,
n n dung lươc ₫ ̀ class ri ng ₫ ̉ mi u ta thu c t nh.
85
Thiã́t kã́ class : NhÝn dang cac mé́i quan hã kã́t hơp & gép
C ̀n theo cac hương d ̃n sau :
chu y cac m ́i quan h  k ́t hơp & g p cua b ́t ky class ph n
t ch ma d ̃n tơi class thi ́t k ́.
tinh ch ́ s ́ ph ̀n tư tham gia, t n vai tro, t nh ch ́t cua vai
tro, class k ́t hơp, k ́t hơp n-ary.
tinh ch ́ hương cua m ́i quan h  k ́t hơp tư lươc ₫ ̀ tương
tac.
Nh n dang m ́i quan h  t ̉ng quat hoa dung cu phap ng n ngư
l p tr nh, n ́u ng n ngư l p tr nh kh ng h ̃ trơ, dung m ́i quan h 
k ́t hơp, g p ₫ ̉ thay th ́.
Thiã́t kã́ class : NhÝn dang cac mé́i quan hã kã́t hơp & gép
Method ₫ăc ta cach tac vu ₫ươc hi n thưc. Mi u ta cac method
dung ng n ngư tư nhi n hay ng n ngư pseudocode. N ́u cung ky
sư linh ki n thưc hi n 2 kh u thi ́t k ́ va hi n thưc, ng ta thương
t khi ₫ăc ta method trong giai ₫oan thi ́t k ́.
M t vai ₫ ́i tương thi ́t k ́ ₫ươc ₫i ̀u khi ̉n bơi trang thai : trang
thai xac ₫ịnh hanh vi cua no khi nh n 1 th ng bao tư ngoai →
mi u ta trang thai dung lươc ₫ ̀ trang thai.
Xư ly cac y u c ̀u ₫ăc bi t chưa ₫ươc chu y ơ cac bươc trươc.
86
Thiã́t kã́ hã thé́ng con (Subsystem)
Muc ₫ ch cua vi c thi ́t k ́ h  th ́ng con la :
₫am bao h  th ́ng con la ₫ c l p vơi nhau nhi ̀u như co th ̉
co.
₫am bao h  th ́ng con la ₫ c l p vơi interface cua no nhi ̀u
như co th ̉ co.
₫am bao h  th ́ng con cung c ́p ₫ươc interfcae ₫ung.
₫am bao h  th ́ng con hoan thanh muc ₫ ch, tao hi n thưc
₫ung cho cac tac vu.
Thiã́t kã́ hã thé́ng con (Subsystem)

G ̀m cac c ng vi c sau :
duy tr sư phu thu c giưa cac h  th ́ng con (n n th ng qua
interface), t ́i thi ̉u hoa sư phu thu c băng cach b ́ tr lai
cac class qua phu thu c vao h  th ́ng con khac.
duy tr interface cua cac h  th ́ng con.
duy tr n i dung cua cac h  th ́ng con.
87
Chương 8
HIÏN THƯC HƯƠNG ĐÖI TƯƠNG

Qui trònh hiïn thưc
Khoa CNTT Chương 8: Hi n thưc hương ₫ ́i tương
Muc ₫Èch cua giai ₫oan hiãn thưc

Muc ₫ ch cua hi n thưc la :
k ́ hoach cac bươc t ch hơp h  th ́ng c ̀n thi ́t cho m ̃i bươc
lăp theo cơ ch ́ tăng d ̀n (h  th ́ng ₫ươc hi n thưc như
chu ̃i cac bươc nho va d ̃ quan ly).
ph n tan h  th ́ng băng cach anh xa cac thanh ph ̀n kha thi
tr n cac nut trong m h nh b ́ tr (dưa chu y ́u vao cac class
chu ₫ ng).
hi n thưc cac class va h  th ́ng con thi ́t k ́.
ki ̉m tra ₫ơn vị tr n cac thanh ph ̀n, t ch hơp chung vao 1
hay nhi ̀u file kha thi trươc khi gơi ₫i ki ̉m tra t ch hơp va
ki ̉m tra h  th ́ng.
88
Cac artifacts cÝ̀n tao ra trong hiãn thưc
M h nh hi n thưc = h  th ́ng hi n thưc :
cac h  th ́ng con hi n thưc
cac component (executable, file, library, table, document,...)
cac interface cua h  th ́ng con va component.
k ́ hoach t ch hơp cac "build"
₫ăc ta ki ́n truc (view of Implementation model)
Stub, hã thé́ng con

Stub la 1 thanh ph ̀n ma ph ̀n hi n thưc chỉ ơ mưc ₫  "template"
₫ ̉ phat tri ̉n hoăc ki ̉m tra thanh ph ̀n khac phu thu c va stub.
Stub co th ̉ t ́i thi ̉u s ́ thanh ph ̀n mơi c ̀n hi n thưc cho m ̃i
version cua h  th ́ng. co ph ̀n hi n thưc, nhơ ₫o lam ₫ơn gian
vi c t ch hơp va ki ̉m tra t ch hơp.
H  th ́ng con do cơ ch ́ packaging trong m i trương hi n thưc tao
ra :
package trong java.
project trong VB.
thư muc cac file trong C++,...
89
Build
Ph ̀n m ̀m ₫ươc hi n thưc theo tưng bươc nho d ̃ quan ly, m ̃i
bươc ta x y dưng 1 build. Build la 1 version kha thi cua h  th ́ng.
Lơi ch cua cach ti ́p c n nay la :
version kha thi co th ̉ tao ra kha sơm thay v phai chơ ₫ơi
l u, vi c ki ̉m tra t ch hơp nhơ ₫o ₫ươc băt ₫ ̀u sơm ₫ ̉ co
th ̉ demo cho cac thanh vi n n i b  hay cac ngươi li n
quan.
d ̃ dang phat hi n ₫i ̉m y ́u va l ̃i v m ̃i l ̀n chỉ co 1 ph ̀n
mơi r ́t nho ₫ươc th m vao.
ki ̉m tra t ch hơp thương nhanh hơn la ki ̉m tra toan b  h 
th ́ng.
Kã́ hoach xÝy dưng build tÈch hơp

K ́ hoach x y dưng build t ch hơp mi u ta tr nh tư cac build c ̀n
thi ́t cho m ̃i bươc lăp, ưng vơi m ̃i build no mi u ta :
chưc năng ky vong ₫ươc hi n thưc trong build, ₫ y la danh
sach cac use-case va/hoăc cac kịch ban cua chung. Danh
sach nay cung chỉ ra cac y u c ̀u phu kem theo.
Cac ph ̀n nao cua m h nh hi n thưc bị tac ₫ ng trong build,
₫ y la danh sach cac h  th ́ng con va cac thanh ph ̀n ₫ươc
₫oi hoi ₫ ̉ hi n thưc chưc năng ky vong cua build.
90
*
1 *
Implementation Implementation Implementation
Model System Subsystem
* * *
*
Interface
Component
Cac workers trong hoat ₫éng hiãn thưc
Architect System Component

Integrator Engineer
Imple. Deployment Architecture Integration Component Imple. Interface

Model Model Description Build Plan Subsystem
91
Qui trÉnh hiãn thưc
Implementation
System Integrate
Integrator System
Implement
Component a Class Perform
Engineer Implement Unit Test
a Subsystem
Hiãn thưc kiã́n truc

Muc ₫ ch cua hi n thưc ki ́n truc la phat hoa m h nh hi n thưc
va ki ́n truc cua no băng cach :
nh n dang cac thanh ph ̀n co y nghĩa ki ́n truc như cac
thanh ph ̀n kha thi (exe).
anh xa cac thanh ph ̀n tơi cac nut trong c ́u h nh mang li n
quan : 1 class chu ₫ ng ₫ươc hi n thưc trong 1 thanh ph ̀n
kha thi va trơ thanh 1 process chay ơ 1 nut cu th ̉.
92
TÈch hơp hã thé́ng
Muc ₫ ch cua t ch hơp h  th ́ng la :
tao 1 k ́ hoach t ch hơp cac build mi u ta build nao trong
tưng bươc lăp va cac y u c ̀u trong m ̃i build.
t ch hơp m ̃i build trươc khi ki ̉m tra t ch hơp.
M t vai ti u chu ̉n cho 1 build k ́ ti ́p la :
build n n th m 1 s ́ chưc năng vao build trươc băng cach
hi n thưc hoan chỉnh use-case.
build kh ng n n bao g ̀m qua nhi ̀u thanh ph ̀n mơi hay
₫ươc tinh ch ́.
build n n dưa tr n build trươc theo cơ ch ́ nơi r ng tư dươi
l n.
TÈch hơp hã thé́ng (tt)

Ưng vơi m ̃i use-case c ̀n hi n thưc, lam cac vi c sau :
chu y d ̃n xu ́t use-case ơ c ́p thi ́t k ́ (d ̃n ngươc v ̀ use-
case).
nh n dang cac h  th ́ng con va class thi ́t k ́ trong d ̃n
xu ́t use-case c ́p thi ́t k ́.
nh n dang cac h  th ́ng con hi n thưc va cac thanh ph ̀n
d ̃n ngươc v ̀ h  th ́ng con va class thi ́t k ́.
chu y anh hương cua vi c hi n thưc cac y u c ̀u l n cac h 
th ́ng con va cac thanh ph ̀n nay, ₫anh gia anh hương ₫ ̉
quy ́t ₫ịnh n n hi n thưc use-case trong build nay hay delay
cho build sau.
93
TÈch hơp 1 build
N ́u build ₫ươc k ́ hoach c ̉n th n th vi c t ch hơp no r ́t ₫ơn
gian :
chon version ₫ung cua cac h  th ́ng hi n thưc va cac thanh
ph ̀n r ̀i dịch, li n k ́t chung ₫ ̉ tao ra build.
chu y m ́i phu thu c dang bottom-up khi dịch cac thanh
ph ̀n va h  th ́ng con.
build vưa ₫ươc tao ra se ₫ươc ki ̉m tra t ch hơp va h  th ́ng
n ́u no pass ₫ươc ki ̉m tra t ch hơp va la build cu ́i cua 1
bươc lăp.
Hiãn thưc hã thé́ng con

Muc ₫ ch cua hi n thưc h  th ́ng con la ₫am bao no hoan thanh
vai tro cua no trong m ̃i build :
m ̃i class trong h  th ́ng con thi ́t k ́ c ̀n cho build hi n tai
n n ₫ươc hi n thưc bơi thanh ph ̀n trong h  th ́ng con hi n
thưc tương ưng (va ₫  qui).
m ̃i interface cua h  th ́ng con thi ́t k ́ c ̀n cho build hi n
tai cung n n ₫ươc cung c ́p bơi h  th ́ng con hi n thưc
tương ưng (va ₫  qui)..
94
Hiãn thưc class
Muc ₫ ch cua hi n thưc class la hi n thưc tưng class thi ́t k ́
thanh file thanh ph n tương ưng, g ̀m cac c ng vi c sau :
Phat hoa 1 file thanh ph ̀n chưa source code cua class. 1
file co th ̉ chưa nhi ̀u class, nhưng theo qui ₫ịnh cua ng n
ngư l p tr nh va nguy n ly ph n chia module, co th ̉ 1 file
chỉ chưa 1 class (VC++, java).
tao source code tư class thi ́t k ́ va cac m ́i quan h  ma
class tham gia.
hi n thưc cac tac vu cua class thi ́t k ́ dươi dang cac
method.
₫am bao thanh ph ̀n cung c ́p cung interface như class thi ́t
k ́.
Kha năng tai sư dung

Kha năng tai sư dung phu thu c vao cac y ́u t ́ sau :
Giư cho m ̃i method co ₫  c ́ k ́t cao : n n thưc hi n 1 chưc
năng ro rang.
giư cho m ̃i method ₫u nho : n ́u chi ́m nhi ̀u trang th tach
ra nhi ̀u method.
giư cho cac method th ́ng nh ́t : n n dung cung danh sach
tham s ́ cho cac method co y nghĩa sư dung gi ́ng nhau.
tach bi t method chi ́n lươc va phương thưc thưc thi.
mơ r ng method cang nhi ̀u cang t ́t : khai quat hoa ki ̉u
tham s ́, s ́ tham s ́,...
tranh dung dư li u toan cuc.
95
Kha năng mơ réng
Kha năng mơ r ng phu thu c vao cac y ́u t ́ sau :
bao ₫ong lơp con : ngay ca lơp bao ngoai cung kh ng th ́y
b n trong.
che d ́u c ́u truc dư li u : kh ng xu ́t ra b n ngoai.
tranh ₫a li n k ́t giư nhi ̀u ₫ ́i tương : tham khao cho phep
thưc hi n chưc năng tr n ₫ ́i tương tương ưng, tranh dung
no ₫ ̉ ti ́p tuc truy xu ́t gian ti ́p ₫ ́n cac ₫ ́i tương khac.
tranh dung l nh switch tr n ki ̉u ₫ ́i tương : ban th n ₫ ́i
tương tư hi ̉u m nh la ai.
ph n bi t tac vu public va private.
LÝp trÉnh ưng dung lơn

La x y dưng 1 ph ̀n m ̀m phưc tap c ̀n nhi ̀u nhom tham gia
₫ ̀ng thơi, giao ti ́p giưa cac thanh vi n la r ́t quan trong :
Kh ng băt ₫ ̀u l p tr nh n ́u chưa hi ̉u ro.
giư cho cac method d ̃ hi ̉u : ₫  k ́t ₫ịnh cao va nho.
tao cho method d ̃ ₫oc : t n bi ́n va ki ̉u co y nghĩa ro rang.
sư dung cung t n cho cac giai ₫oan khac nhau : ph n t ch,
thi ́t k ́, hi n thưc...
lưa chon t n ky lương : th ̉ hi n ₫ung vai tro, nghĩa vu.
sư dung cac hương d ̃n va qui tăc l p tr nh : style...
l p tai li u cho cac class va cac method : muc ₫ ch, chưc
năng...
xu ́t ban ₫ăc ta hương d ̃n cach sư dung class.
96
Thưc hiãn kiã̉m tra ₫ơn vị (Unit test)
Muc ₫ ch la ki ̉m tra chưc năng cua tưng ₫ơn vị ₫ươc hi n thưc 1
cach ri ng le. Co 2 loai ki ̉m tra tưng ₫ơn vị :
ki ̉m tra ₫ăc ta (black-box testing) : ki ̉m tra hanh vi cua ₫ơn
vị như ₫ươc th ́y tư ngoai.
ki ̉m tra c ́u truc (white-box testing) : ki ̉m tra sư hi n thưc
b n trong ₫ơn vị.
Cung con 1 s ́ loai ki ̉m tra ₫ơn vị khac như : ki ̉m tra t nh hi u
qua, ki ̉m tra vi c dung b  nhơ, ki ̉m tra tai, ki ̉m tra kha năng.
Vi c ki ̉m tra t ch hơp va ki ̉m tra h  th ́ng se ₫ươc thưc hi n
trong giai ₫oan ki ̉m tra.
Kiã̉m tra ₫ăc ta

Muc ₫ ch ki ̉m tra ₫ăc ta (black-box testing) la ki ̉m tra hanh vi
cua ₫ơn vị như ₫ươc th ́y tư ngoai :
ki ̉m tra xem component cho k ́t qua g ưng vơi tưng dư li u
nh p va trang thai nao ₫o.
S ́ lương t ̉ hơp b  ba {gia trị dư li u nh p, trang thai băt
₫ ̀u, gia trị k ́t qua} thương r ́t lơn n n vi c ki ̉m tra t ́t ca
t ̉ hơp nay la kh ng kha thi.
ta xac ₫ịnh cac lơp tương ₫ương cua "test case" va chỉ ki ̉m
tra tr n cac lơp tương ₫ương nay. Lơp tương ₫ương la t ́t ca
cac "test case" lam ₫ơn vị cho h ̀u như cung hi u ưng.
97
Kiã̉m tra cÝ́u truc
Muc ₫ ch cua ki ̉m tra c ́u truc (white-box testing) la ki ̉m tra sư
hi n thưc b n trong ₫ơn vị :
₫am bao moi hang l nh ₫ ̀u ₫ươc ki ̉m tra ( t nh ́t la chay 1
l ̀n).
ki ̉m tra moi path c ̀n quan t m : cac path chay thương
nh ́t, cac path d ̃ g y sai, cac path t ₫ươc bi ́t v ̀ giai thu t
nh ́t, cac path co rui ro cao.

Chương 9
KIÏM THƯ
Qui trònh kiï̉m thư
Khoa CNTT Chương 9: Ki ̉m thư
98
Cac artifacts cÝ̀n tao ra trong kiã̉m thư
M h nh ki ̉m thư = h  th ́ng ki ̉m thư :
Test case : 1 trương hơp ki ̉n thư { input, status, output}
Test procedure : cach thưc thưc hi n test case
Test component : tư ₫ ng hoa 1 hay nhi ̀u thu tuc ki ̉n thư
Plan Test : chi ́n lươc, tai nguy n, lịch
Defect : l ̃i
Evaluate Test : phu cac testcase, cac code, trang thai l ̃i
Khoa CNTT Chương 9 : Ki ̉m thư
Cac artifacts trong kiã̉m thư

1
Test Model Test System
* * *
Test Case Test Test

Procedure Component
99
Cac workers trong kiã̉m thư
Test Component Integration System

Engineer Engineer Tester Tester
chịu trach nhi m v ̀ chịu trach nhi m v ̀
chịu trach nhi m v ̀
Test Model Test Plan Test case Test Test Test

Test
defect
Procedure Evaluation Component
Qui trÉnh kiã̉m thư
Plan test Evaluate test

Test Engineer Design test
Perform Integration
Integration tester Test
System Perform
Tester System Test
Component Implement
Engineer Test
100
Kã́ hoach viãc kiã̉m thư
Muc ₫ ch la k ́ hoach hoa cac n ̉ lưc ki ̉m thư cho 1 bươc lăp
băng cach :
mi u ta chi ́n lươc ki ̉m thư : thưc hi n ki ̉u ki ̉m thư nao,
thưc hi n như th ́ nao, khi nao thư va ₫anh gia k ́t qua ki ̉m
thư như th ́ nao.
ươc lương cac y u c ̀u cua n ̉ lưc ki ̉m thư, như cac tai
nguy n v ̀ h  th ́ng hay tai nguy n v ̀ ngươi.
lăp lịch cho n ̉ lưc ki ̉m thư.
Ky sư ki ̉m thư dung chu y ́u m h nh use-case va cac y u c ̀u
phu, cung co th ̉ dung th m m h nh thi ́t k ́.
Thiã́t kã́ cac test case

Muc ₫ ch la :
nh n dang va ₫ăc ta cac test case cho m ̃i build.
nh n dang va c ́u truc cac thu tuc ki ̉m thư ₫ ̉ xac ₫ịnh
cach thưc hi n cac test case.
Cu th ̉ :
thi ́t k ́ cac test case t ch hơp.
thi ́t k ́ cac test case h  th ́ng.
thi ́t k ́ cac test case "regression".
nh n dang va c ́u truc cac thu tuc ki ̉m thư.
101
Thiã́t kã́ cac test case tÈch hơp
Thi ́t k ́ cac test case t ch hơp :
test case t ch hơp ₫ ̉ ki ̉m tra cac thanh ph ̀n ₫ươc hi n
thưc trong build tương tac vơi nhau, thương dưa vao d ̃n
xu ́t use-case ơ c ́p thi ́t k ́, chu y ́u la cac lươc ₫ ̀ tương
tac va tr nh tư.
₫ ̉ giam nhe n ̉ lưc thi ́t k ́ test case, ky sư ki ̉m thư c ́
găng t m ra cac test case co ph ̀n giao t ́i thi ̉u, m ̃i test
case tương ưng vơi 1 path hay 1 kịch ban ri ng trong d ̃n
xu ́t use-case.
sau khi ki ̉m thư, ky sư ki ̉m thư se so sanh cac tương tac
thưc sư giưa cac ₫ ́i tương vơi sơ ₫ ̀ tương tac trong thi ́t k ́,
n ́u gi ́ng th Ok, n ́u khac th co l ̃i.
Thiã́t kã́ cac test case hã thé́ng

Cac test case h  th ́ng ₫ươc dung ₫ ̉ ki ̉m tra xem cac chưc
năng h  th ́ng co hoat ₫ ng t ́t ơ mưc t ̉ng th ̉ ? M ̃i test case
ki ̉m thư cac t ̉ hơp use-case hoat ₫ ng dươi nhưng ₫i ̀u ki n
khac nhau như c ́u h nh ph ̀n cưng, mưc tai, s ́ actor, k ch thươc
database.
Khi phat tri ̉n cac test case h  th ́ng n n ₫ ̉ y ₫  ưu ti n cua cac
t ̉ hơp test case ma :
₫ươc ₫oi hoi ₫ ̉ hoat ₫ ng song song.
co th ̉ ₫ươc thưc hi n song song.
co anh hương vơi nhau n ́u ₫ươc thưc hi n song song.
li n quan tơi nhi ̀u process.
thương dung tai nguy n h  th ́ng theo 1 cach phưc tap va
kh ng th ̉ ti n ₫oan.
102
Thiã́t kã́ cac thu tuc kiã̉m thư
dưa vao tưng test case va ₫ ̀ nghị thu tuc ki ̉m thư cho tưng
test case.
c ́ găng dung lai cac thu tuc ki ̉m thư ₫a co nhi ̀u như co
th ̉ (co th ̉ co thay ₫ ̉i nho).
1 thu tuc ki ̉m thư co th ̉ tac ₫ ng tr n nhi ̀u test case va 1
test case co th ̉ co nhi ̀u thu tuc ki ̉m thư.
Thưc hiãn kiã̉m thư

Muc ₫ich la tư ₫ ng hoa cac thu tuc ki ̉m thư băng cach tao cac
thanh ph ̀n ki ̉m thư (n ́u co th ̉). Dưa vao cac thu tuc ki ̉m thư
ta tao cac thanh ph ̀n ki ̉m thư theo 2 c ng ngh  :
dung tool tư ₫ ng ki ̉m thư.
vi ́t tương minh thanh ph ̀n ki ̉m thư.
Cac thanh ph ̀n ki ̉m thư thương nh n r ́t nhi ̀u dư li u nh p vao
tao ra nhi ̀u dư li u xu ́t, do ₫o c ̀n thi ́t phai hi ̉n thị trưc quan
₫ươc cac dư li u nay ₫ ̉ d ̃ theo doi (dung bang t nh hay
database).
103
Thưc hiãn kiã̉m thư tÈch hơp
Thưc hi n cac test case cua m ̃i build va ghi nh n k ́t qua. Qui
tr nh thưc hi n :
thưc hi n băng tay tu ̀n tư cac test case hay băng cac thanh
ph ̀n ki ̉m l ̃i tư ₫ ng.
So sanh k ́t qua co ₫ươc vơi k ́t qua ky vong.
th ng bao cac l ̃i tơi ky sư linh ki n li n quan.
th ng bao cac l ̃i tơi ky sư thi ́t k ́ test case ₫ ̉ ₫anh gia k ́t
qua ki ̉m thư t ̉ng th ̉.
Thưc hiãn kiã̉m thư hã thé́ng

muc ₫ ch ki ̉m thư h  th ́ng la thưc hi n cac test case ₫ươc
₫oi hoi cho m ̃i bươc lăp va năm băt cac k ́t qua ki ̉m thư.
ki ̉m thư h  th ́ng co th ̉ băt ₫ ̀u khi ki ̉m thư t ch hơp cho
th ́y h  th ́ng ₫a thoa man cac muc ti u ch ́t kương t ch
hơp ( khoang 95%).
qui tr nh ki ̉m thư h  th ́ng tương tư như ki ̉m thư t ch hơp.
Cac c ng vi c ki ̉m tra h  th ́ng :
Ki ̉m tra t nh phuc h ̀i sau l ̃i (Recovery testing)
Ki ̉m tra t nh bao m t (Security testing).
Ki ̉m tra trong m i trương căng thăng (Stress Testing).
Ki ̉m tra trong hi u su ́t (Performance testing).
104
Đanh gia viãc kiã̉m thư
Ky sư ki ̉m thư quan t m 2 thươc ₫o ch nh :
mưc ₫  hoan thanh ki ̉m thư.
₫  tin c y : xu hương l ̃i phat hi n so vơi xư hương test case
thanh c ng.
Dưa tr n xu hương l ̃i, ky sư ki ̉m thư co th ̉ ₫ ̀ nghị cac c ng vi c sau
:
thưc hi n th m ki ̉m l ̃i ₫ ̉ xac ₫ịnh th m l ̃i.
nơi long ti u chu ̉n ki ̉m l ̃i n ́u muc ti u ch ́t lương qua cao so
vơi bươc lăp hi n hanh.
Tach cac b  ph n co ve ₫at ₫  tin c y, con cac b  ph n chưa ₫at
phai ₫ươc xem xet va ki ̉m thư lai.
Cu ́i cung l p tai li u v ̀ mưc ₫  hoan thanh ki ̉m thư, ₫  tin c y, cac
c ng vi c ₫ ̀ nghị (ta goi la ₫ăc ta ₫anh gia ki ̉m thư).
Tổng quát về hoạt ₫ộng debug ứng dụng

Sau khi viết code cho ứng dụng xong, ta sẽ thử chạy nó ₫ể xác ₫ịnh
xem nó giải quyết ₫úng yêu cầu không. Thường ứng dụng chứa nhiều
lỗi sai thuộc 1 trong 3 loại sau :
1. các lỗi về từ vựng (tên các phần tử, từ danh riêng,..) và cú pháp của
các phần tử cấu thành ứng dụng. VC++ sẽ phát hiện các lỗi này
triệt ₫ể và hiển thị thông báo lỗi cho ta xem xét và sửa chữa.
Thường sau khi ₫ược VC++ thông báo về các lỗi này, ta dễ dàng
sửa chúng.
Ví dụ :
ItemRec item; // sẽ báo sai nếu kiểu ItemRec chưa ₫ược ₫ịnh nghĩa
// error C2146: syntax error : missing ';' before identifier 'item'
int a
double b; // thiếu dấu ; ở trước double
// error C2144: syntax error : missing ';' before type 'double‘
If (delta >= 0) // sai từ vựng vì If phải viết thường
//error C2065: 'If' : undeclared identifier
105
2. các lỗi run-time (giải thuật, tràn bộ nhớ,...). VC++ không thể phát hiện các
lỗi này vì chúng thuộc phạm trù ngữ nghĩa. Ứng dụng sẽ chạy theo giải
thuật ₫ược miêu tả, ta phải tự ₫ánh giá tính ₫úng/sai về giải thuật, nhưng
việc tìm lỗi giải thuật thường rất khó. Để giúp ₫ở người lập trình dễ dàng
tìm ra các lỗi giải thuật, VC++ cung cấp công cụ cho phép họ kiểm soát
₫ược qui trình chạy ứng dụng và truy xuất các biến dữ liệu của chương
trình, cộng cụ này ₫ược gọi là 'Debug'.
Ví dụ :
double a[50];
double b;
…
b = 3.1416;
a[50] = 9.0; // cũng sẽ làm b = 9.0 vì vùng nhớ của biến b cũng
// chính là vùng nhớ của phần tử a[50]

3. các lỗi do truy xuất tài nguyên ₫ồng thời với các ứng dụng khác (môn HĐH
sẽ trình bày cụ thể lỗi này và cách giải quyết). Thí dụ 2 ứng dụng truy xuất
tài khoản A ₫ồng thời :
1. hiển thị giao diện & chờ 1. hiển thị giao diện & chờ
người dùng ra lệnh người dùng ra lệnh
2. Người dùng ra lệnh nạp 2. Người dùng ra lệnh rút tiền
vào tài khoản A số tiền từ tài khoản A 500USD →
700USD → xử lý : xử lý :
Tài khoản
21a Đọc tài khoản A vào 21b Đọc tài khoản A vào
bộ nhớ,
A
bộ nhớ,
22a Tăng giá trị tài 22b Giảm giá trị tài
khoản trong bộ nhớ khoản trong bộ nhớ
lên 700USD. ₫i 500USD.
23a Ghi lại giá trị mới. 23b Ghi lại giá trị mới.
3. Quay về bước 1 3. Quay về bước 1
Nếu tài khoản A là 1000USD và HĐH ₫iều khiển chạy 2 process P1 và P2 theo
thứ tự 21a→22a→21b→22b→23b→23a thì kết quả tài khoản A sẽ là 1700USD
(giá trị ₫úng là 1200USD).
106
Tổng quát về tiện ích debug tích hợp trong VC++
Trong quá trình debug, ứng dụng sẽ ở 1 trong 2 chế ₫ộ sau :
Pause : chế ₫ộ của ứng dụng trước khi chạy hay khi dừng lại theo 1 ₫iều kiện
dừng nào ₫ó của người debug. VC++ sẽ ghi nhớ lệnh sắp thi hành trước khi
dừng (lệnh ₫ầu tiên của ứng dụng nếu nó chưa bắt ₫ầu chạy). Do tính lịch sử,
ta dùng thuật ngữ PC - program counter ₫ể nói về lệnh này. Ở chế ₫ộ này,
người debug có thể xem trạng thái của ứng dụng : giá trị của các biến dữ liệu
₫ể biết ứng dụng chạy ₫úng hay sai theo yêu cầu, lịch sử gọi hàm trong call
strack, thêm/bớt các ₫iều kiện dừng,… ₫iều khiển việc thi hành tiếp theo của
ứng dụng, lúc này ứng dụng sẽ chuyển sang chế ₫ộ Running.
Running : chế ₫ộ mà ứng dụng ₫ang chạy các lệnh của nó ₫ến khi nó gặp 1
₫iều kiện dừng ₫ã thiết lập trước, lúc này ứng dụng sẽ chuyển về chế ₫ộ
Pause.
Trong quá trình debug, ứng dụng ở chế ₫ộ Pause chủ yếu thời gian và người
debug tương tác với ứng dụng chủ yếu ở chế ₫ộ này. Mỗi khi ứng dụng ₫ược chạy
tiếp, nó chuyển qua chế ₫ộ Running, nhưng sẽ nhanh chóng chạy ₫ến lệnh dừng
và chuyển về chế ₫ộ Pause (trừ phi bị 'blocked' chờ I/O hay bị 'loop' trong các vòng
lặp vô tận).
Cửa sổ Debug
Cửa sổ Registers
Cửa sổ Memory
Cửa sổ CallStack
Cửa sổ Variable Cửa sổ Watch
Khoa CNTT
107
Các thao tác ₫ể xem và hiệu chỉnh biến dữ liệu
Để xem nội dung của 1 biến dữ liệu, người debug có thể :
dời chuột ₫ến tên biến trong cửa sổ code, 1 cửa sổ nhỏ chứa giá trị của biến
₫ó sẽ ₫ược hiển thị ₫ể người debug xem xét.
Xem nội dung của biến trong cửa sổ “Variable”.
nhập biểu thức (thường là biến dữ liệu) vào vùng Name của cửa sổ Watch ₫ể
xem nội dung của nó.
Để hiệu chỉnh giá trị của 1 biến nào ₫ó (do ₫ã bị sai, nhưng muốn sửa lại cho ₫úng
hầu có thể kiểm thử các lệnh còn lại), người debug có thể dời cursor về cell chứa
giá trị hiện hành của biến ₫ó (trong cửa sổ Variable hay trong cửa sổ Watch rồi
hiệu chỉnh lại giá trị mới).
Các thao tác ₫ể xem vị trí thi hành hiện tại

Để hiển thị cửa sổ chứa danh sách các hàm ₫ang thực hiện dỡ dang (các hàm
lồng nhau theo thứ tự), người debug có thể :
chọn menu View.Debug Windows.Call Stack.
ấn phải chuột trên gáy cửa sổ bất kỳ rồi chọn mục “Call Stack”.
Để xem vị trí PC hiện hành (lệnh sắp thực hiện kế tiếp), người debug có thể :
chọn menu Debug.Show Next Statement (thường khi ứng dụng dừng lại, nó
sẽ hiển thị lệnh chạy kế tiếp - lệnh bị dừng với màu tô ₫ặc biệt và có dấu mũi
tên ở lề trái của lệnh).
108
Các lệnh thiết lập ₫iều kiện dừng
Để xem/hiệu chỉnh các ₫iểm dừng (breakpoint), ta chọn menu Edit.Breakpoints ₫ể
hiển thị cửa sổ Breakpoints, từ ₫ó thực hiện chức năng mong muốn :
Xem danh sách các ₫iểm dừng hiện hành, có thể xóa hết chúng bằng cách
chọn button “Remove All”, có thể xóa từng ₫iểm dừng bằng cách chọn nó rồi
ấn button “Remove”.
Muốn thiết lập ₫iểm dừng mới, chọn tab “Location”, nhập vị trí lệnh cần dừng
và ₫iều kiện dừng mong muốn (mặc ₫ịnh là luôn luôn dừng ở vị trí qui ₫ịnh).
Muốn thiết lập ₫iểm dừng mới dựa trên 1 biến nào ₫ó bị thay ₫ổi giá trị, chọn
tab “Data”, nhập biểu thức cần tính toán (biến cần quan tâm).
Muốn thiết lập ₫iểm dừng mới dựa trên thông báo (message) của Windows,
chọn tab “Message”, chọn hàm xử lý, chọn thông báo cần dừng.
Ta có thể (và nên) thiết lập nhiều ₫iểm dừng ₫ồng thời ₫ể 'rào chắn' nhiều luồng
thi hành khác nhau của chương trình.
Các lệnh ₫iều khiển chạy tiếp ứng dụng

Để chạy tiếp ứng dụng từ vị trí PC hiện hành, người debug có thể :
o chọn menu Debug.Go ₫ể bắt ₫ầu chạy ứng dụng, ứng dụng chỉ dừng lại khi
gặp ₫iều kiện dừng nào ₫ó ₫ã ₫ược thiết lập.
o chọn menu Debug.Go ₫ể chạy tiếp từ vị trí PC hiện hành, ứng dụng chỉ dừng
lại khi gặp ₫iều kiện dừng nào ₫ó ₫ã ₫ược thiết lập.
o chọn menu Debug.Step Over ₫ể chạy tiếp 1 lệnh rồi dừng lại (Pause), nếu
lệnh thi hành là lệnh gọi thủ tục thì toàn bộ thủ tục sẽ ₫ược chạy. Đây là lệnh
cho phép thực hiện từng lệnh theo mức vĩ mô.
o chọn menu Debug.Step Into ₫ể chạy tiếp 1 lệnh rồi dừng lại (Pause), nếu
lệnh thi hành là lệnh gọi thủ tục thì ứng dụng sẽ dừng lại ở lệnh ₫ầu tiên của
thủ tục. Đây là lệnh cho phép thực hiện từng lệnh theo mức vi mô.
o chọn menu Debug.Step Out ₫ể chạy tiếp các lệnh còn lại của thủ tục hiện
hành rồi quay về và dừng lại sau lệnh gọi thủ tục này (Pause).
o chọn menu Debug.Run to Cursor ₫ể chạy tiếp ứng dụng từ vị trí PC hiện hành
₫ến lệnh chứa cursor hiện hành rồi dừng lại (Pause).
109
Các lệnh ₫iều khiển khác
Ngoài ra khi ứng dụng ở trạng thái 'Pause', người debug có thể thực hiện
các lệnh sau :
chọn menu Debug.Stop Debugging ₫ể kết thúc việc chạy ứng dụng.
chọn menu Debug.Restart ₫ể kết thúc việc chạy ứng dụng rồi bắt ₫ầu chạy lại
từ ₫ầu.
Khi ứng dụng ở trạng thái ‘Running', người debug có thể thực hiện các lệnh sau :
chọn menu Debug.Break ₫ể dừng ₫ột ngột việc chạy ứng dụng, lệnh ₫ang
thực hiện sẽ ₫ược ₫ánh dấu ₫ể ta dễ theo dõi. Chức năng này giúp ta biết ứng
dụng ₫ang bị 'loop' ở ₫oạn lệnh nào. Nếu ứng dụng ₫ang bị 'block' chờ biến
cố I/O, sẽ không có lệnh nào ₫ược dánh dấu cả.
Trường Đại Học Bách Khoa Tp. HCM

Khoa Công nghệ Thông tin
Chương 10
CÁC MẪU CẤU TRÚC

Mẫu Adapter
Mẫu Composite
Mẫu Proxy
Mẫu Decorator
Mẫu Flyweigth
Mẫu Facade
Khoa CNTT Chương 10 : Các mẫu cấu trúc
110
Giới thiệu
Thiết kế phần mềm là một vấn ₫ề rất khó khăn, nhất là khi phần mềm
lớn, mối quan hệ giữa các phần tử nhiều → bản thiết kế thường không
hiệu quả hoặc có lỗi.
Các lỗi thiết kế thường phải trả giá cao do ảnh hưởng ₫ến nhiều giai
₫oạn sau (viết code, kiểm tra…).
Phương pháp lập trình hướng ₫ối tượng cung cấp cơ chế ₫ể có thể xây
dựng ₫ược phần mềm dễ nâng cấp, thay ₫ổi (VD: ₫ặc tính thừa kế, ₫a
hình…). Tuy nhiên việc xây dựng những phần mềm HĐT như thế phụ
thuộc nhiều vào khả năng người thiết kế.
Mục tiêu của thiết kế: không chỉ thiết kế những phần mềm ₫úng mà còn
có thể hạn chế hoặc hỗ trợ tái thiết kế trong tương lai.
Giới thiệu (tt)

Có nhiều nguyên nhân dẫn ₫ến tái thiết kế :
Phụ thuộc vào phần cứng, hệ ₫iều hành (OS) hay phần mềm khác: các
phần mềm xác ₫ịnh quá chặt chẽ các thông số phần cứng hay phần mềm
liên quan sẽ phải thay ₫ổi khi các thông số này thay ₫ổi.
Phụ thuộc vào giải thuật: khi hệ thống có nhiều giải pháp, nhiều mức ₫ộ xử
lý cho cùng một vấn ₫ề, việc ràng buộc chặt chẽ hệ thống với giải pháp cụ
thể sẽ dẫn ₫ến khó bổ sung, thay ₫ổi hệ thống.
Không tổng quát hóa khi lập trình, nhất là lập trình hướng ₫ối tượng. VD:
ràng buộc thông số hình thức với ₫ối tượng lớp con thay vì có thể là ₫ối
tượng lớp cha.
Các component liên quan nhau quá chặt chẽ: mối quan hệ giữa các
component nhiều dẫn ₫ến hiện tượng thay ₫ổi dây chuyền khi phải thay ₫ổi
một component nào ₫ó. VD: lạm dụng thừa kế trong lập trình hướng ₫ối
tượng, các component gọi lẫn nhau nhiều…
111
Giới thiệu (tt)
Một biện pháp ₫ược ₫ề xuất ₫ể có những bản thiết kế tốt: sử dụng lại
những mẫu thiết kế của những chuyên gia ₫ã qua kiểm nghiệm thực tế.
Mẫu thiết kế (Design pattern) thường có ₫ặc ₫iểm:
Là những thiết kế ₫ã ₫ược sử dụng và ₫ược ₫ánh giá tốt.
Giúp giải quyết những vấn ₫ề thiết kế thường gặp.
Chú trọng việc giúp cho bản thiết kế có tính uyển chuyển, dễ nâng cấp,
thay ₫ổi.
Vai trò của design pattern

Cung cấp phương pháp giải quyết những vấn ₫ề thực tế thường gặp ₫ã
₫ược ₫ánh giá, kiểm nghiệm.
Là biện pháp tái sử dụng tri thức các chuyên gia phần mềm.
Hình thành kho tri thức, ngữ vựng trong giao tiếp giữa những người làm
phần mềm.
Giúp người tìm hiểu nắm vững hơn ₫ặc ₫iểm ngôn ngữ lập trình, nhất là
lập trình hướng ₫ối tượng.
→ tăng ₫ộ tin cậy, tiết kiệm nguồn lực…
112
Phân loại software patterns
Có nhiều loại Software patterns: analysis patterns, design patterns,
organization patterns, process patterns… Bài giảng này chỉ tập trung
vào Object Oriented Design Patterns (từ ₫ây về sau gọi là Design
Patterns hay mẫu thiết kế).
Design patterns có ba nhóm chính
Structural — Cung cấp cơ chế xử lý những lớp không thể thay ₫ổi (lớp thư
viện của third party…), ràng buộc muộn (lower coupling) và cung cấp các
cơ chế khác ₫ể thừa kế.
Creational — Khắc phục các vấn ₫ề khởi tạo ₫ối tượng, hạn chế sự phụ
thuộc platform.
Behavioral — Che dấu hiện thực của ₫ối tượng, che dấu giải thuật, hỗ trợ
việc thay ₫ổi cấu hình ₫ối tượng một cách linh ₫ộng.
Phân loại Object Oriented Design Patterns

Mỗi nhóm Design Pattern có các pattern về lớp (class patterns) và
pattern về ₫ối tượng (object patterns).
Class patterns dựa trên mối quan hệ thừa kế giữa các lớp, mối quan hệ
này là tĩnh (xác ₫ịnh tại thời ₫iểm dịch), do ₫ó class patterns thích hợp
cho hệ thống không cần thay ₫ổi ₫ộng trong thời gian chạy.
Object patterns dựa trên mối quan hệ giữa các ₫ối tượng, do ₫ó có thể
thay ₫ổi ở thời ₫iểm chạy.
113
Khả năng ứng dụng design patterns
Tìm kiếm ₫ối tượng: việc phân chia hệ thống thành một tập hợp các ₫ối
tượng hoạt ₫ộng hiệu quả là công việc khó khăn. Design pattern giúp
₫ưa ra những ₫ối tượng thường gặp trong những trường hợp thiết kế
tương tự ₫ã gặp trước ₫ây.
Xác ₫ịnh số lượng và kích thước ₫ối tượng: trong trường hợp hệ thống
cần ràng buộc số lượng xác ₫ịnh ₫ối tượng ₫ang hoạt ₫ộng hay người
thiết kế băn khoăn về việc nên tập trung một số chức năng nào ₫ó vào
trong 1 ₫ối tượng hay tách ra thành nhiều ₫ối tượng.
Xác ₫ịnh interface và hiện thực (implementation) của ₫ối tượng. Hướng
chương trình ₫ến ₫ặc ₫iểm: program to an interface, not an
implementation.
Giúp thiết kế theo hướng tái sử dụng và linh ₫ộng bằng cách sử dụng
mối quan hệ giữa các ₫ối tượng (bao gộp, thừa kế…) một cách phù hợp
và thiết kế theo hướng tiên ₫oán trước các thay ₫ổi trong tương lai.
Cấu trúc design pattern sẽ trình bày

Tên
Mục tiêu và nhu cầu áp dụng
Ví dụ sử dụng
Lược ₫ồ class miêu tả mẫu : chứa các phần tử (lớp, ₫ối tượng) trong
pattern và mối quan hệ giữa chúng.
Các ngữ cảnh nên áp dụng pattern.
114
Structural Patterns
Các mẫu cấu trúc (Structural Patterns) tập trung giải quyết vấn ₫ề kết
hợp các lớp và/hoặc ₫ối tượng thành một kiến trúc lớn hơn.
Các mẫu cấu trúc lớp (structural class patterns) sử dụng thừa kế ₫ể kết
hợp các lớp hay các interface. Tương tự quá trình ₫a thừa kế: một lớp
thừa kế từ nhiều lớp cha sẽ mang ₫ặc ₫iểm của tất cả các lớp cha gộp
lại.
Các mẫu cấu trúc ₫ối tượng (structural object patterns) tập trung vào
việc kết hợp các ₫ối tượng ₫ể thực hiện những chức năng nào ₫ó.
Trong các slide tiếp theo, chúng ta sẽ tìm hiểu các mẫu: Adapter,
Composite, Proxy, Decorator, Facade, Flyweight.
Adapter
Mục tiêu : chuyển ₫ổi interface của một class thành một interface khác
theo yêu cầu sử dụng của Client.
Nhu cầu áp dụng : có những trường hợp chúng ta sử dụng một class
nhưng không muốn tuân theo interface của chính class ₫ó mà lại muốn
chuyển sang một interface khác. Mẫu Adapter giúp chúng ta giải quyết
vấn ₫ề này.
Ví dụ : chương trình drawing editor xử lý các ₫ối tượng ₫ồ họa Line,
Polygon, Text... thông qua interface sử dụng Shape (₫ược ₫ịnh nghĩa
như class root nếu ngôn ngữ lập trình không hỗ trợ Interface). Hiện thực
class Line, Polygon từ ₫ầu khá dễ vì ₫ơn giản nhưng hiện thực class
Text thì phức tạp hơn → nên dùng lại class sẵn có nào ₫ó (thí dụ
TextView cung cấp chức năng quản lý Text) nhưng không thể hay không
muốn thay ₫ổi class TextView → ₫ịnh nghĩa class Adapter tên là
TextShape thừa kế class Shape của ứng dụng.
115
Thí dụ về mẫu Adapter dùng object
Sơ ₫ồ cấu trúc của mẫu Adapter dùng class
Mẫu Adapter dùng class xây

dựng lớp Adapter bằng cách
thừa kế cả interface cần
chuyển và interface ₫ích.
116
Sơ ₫ồ cấu trúc của mẫu Adapter dùng object
Mẫu Object
Adapter xây dựng
lớp Adapter bằng
cách thừa kế
interface ₫ích và
bao gộp ₫ối tượng
của interface cần
chuyển.
Các phần tử tham gia

Target (Shape) : ₫ịnh nghĩa interface cho Client sử dụng.
Client (DrawingEditor) : sử dụng các ₫ối tượng thông qua interface
Target.
Adaptee (TextView) : ₫ịnh nghĩa interface ₫ã có sẵn cần “chuyển” sang
interface Target.
Adapter (TextShape) : “chuyển” interface Adaptee sang interface Target.
117
Các ngữ cảnh nên dùng mẫu Adapter
muốn dùng một lớp ₫ã có sẵn nhưng interface của nó không tương thích
với interface ₫ang sử dụng trong khi chúng ta chỉ muốn dùng interface
₫ang sử dụng.
muốn tạo ra các lớp có thể giao tiếp với các lớp khác nhưng chưa biết
trước interface của những lớp ₫ó.
(₫ối với mẫu object adapter) muốn sử dụng nhiều lớp con ₫ã có sẵn
nhưng sẽ không hiệu quả nếu phải chuyển interface (bằng mẫu Adapter)
của từng lớp con. Object Adapter sẽ chuyển interface của chỉ lớp cha.
Composite
Mục tiêu : tạo quan hệ thứ bậc bao gộp giữa các ₫ối tượng. Client có thể
xem ₫ối tượng bao gộp và ₫ối tượng bị bao gộp như nhau → khả năng
tổng quát hóa trong code của client → dễ phát triển, nâng cấp, bảo trì.
Nhu cầu áp dụng : Có những trường hợp hệ thống muốn xem xét các ₫ối
tượng ₫ơn cũng như các ₫ối tượng phức (₫ối tượng chứa nhiều ₫ối tượng
₫ơn). Trong trường hợp này, hệ thống vừa phải ₫ảm bảo ₫ược tính bao
gộp lẫn tính không phân biệt giữa các phần tử. Mẫu Composite cung cấp
giải pháp cho yêu cầu này.
Ví dụ : chương trình drawing editor vừa có các ₫ối tượng ₫ơn như ký tự,
₫iểm ảnh vừa có các ₫ối tượng phức như từ (gồm nhiều ký tự), hàng
(gồm nhiều từ), nhóm các phần tử nhỏ hơn…Dưới góc ₫ộ người sử dụng,
họ thường tác ₫ộng như nhau lên một từ và một ký tự...
118
Thí dụ về mẫu Composite
Graphic
Draw()
Add(Graphic)
Remove(Graphic)
GetChild(int)
graphics
Line Text Rectangle Picture
for all g in graphics
Draw() Draw() Draw() Draw() g.Draw()
Add(Graphic)
Remove(Graphic) add g to list of graphics
GetChild(int)
Sơ ₫ồ cấu trúc của mẫu Composite
119
Component
Khai báo interface và hiện thực một số tác vụ chung cho các ₫ối tượng của
những lớp thừa kế (gọi chung là các component)
Khai báo interface cho việc truy xuất và quản lý ₫ối tượng của các
component.
Có thể khai báo hay hiện thực các phương thức ₫ể truy xuất ₫ến ₫ối tượng
cha của những component.
Leaf : Định nghĩa tác vụ cho cho những component cơ bản.
Composite : Định nghĩa tác vụ cho những component bao gộp những
component khác.
Client : Sử dụng các component thông qua interface Component
Các ngữ cảnh nên dùng mẫu Composite

chương trình muốn thể hiện quan hệ bao gộp - bị bao gộp.
chương trình muốn ₫ối xử các phần tử bao gộp và bị bao gộp như nhau.
Ví dụ: compiler (chương trình con hay module có thể bao gộp các
chương trình con hay module khác…); chương trình giao diện GUI
(window là ₫ối tượng phức, button là ₫ối tượng ₫ơn); chương trình text
editor…
120
Proxy
Mục tiêu : Cung cấp ₫ối tượng ₫ại diện cho một ₫ối tượng khác ₫ể hỗ trợ
hoặc kiểm soát quá trình truy xuất ₫ối tượng ₫ó. Đối tượng thay thế gọi
là Proxy.
Nhu cầu áp dụng :
Những ₫ối tượng lớn khi khởi tạo sẽ tốn nhiều tài nguyên, do ₫ó nên trì hoãn
thời ₫iểm khởi tạo thực sự các ₫ối tượng này. Trong thời gian trì hoãn, proxy
₫óng vai trò thay thế ₫ối tượng.
Chương trình muốn truy xuất một ₫ối tượng ở không gian ₫ịa chỉ khác.
Proxy thay thế ₫ối tượng ở máy remote.
Đối tượng cần ₫ược bảo mật khỏi tương tác trực tiếp với client. Client chỉ tác
₫ộng ₫ược lên Proxy, Proxy chuyển yêu cầu Client xuống ₫ối tượng thực
hiện yêu cầu.
Chương trình muốn bổ sung một số thao tác kiểm soát lên một ₫ối tượng.
Proxy ₫óng vai trò ₫ối tượng kiểm soát.
Phân loại Proxy

Remote proxy : cung cấp ₫ối tượng ₫ại diện (local) cho một ₫ối tượng
phân bố (nonlocal) khác (ví dụ RMI, JINI).
Virtual proxy : cung cấp ₫ối tượng ₫ại diện cho ₫ối tượng lớn khi khởi tạo
tốn nhiều tài nguyên. Mục ₫ích ₫ể trì hoãn thời ₫iểm tạo ₫ối tượng lớn.
(Ví dụ ₫ối tượng hình ảnh trong một chương trình xử lý ₫ồng thời nhiều
hình ảnh).
Protection proxy : cung cấp ₫ối tượng ₫ại diện cho một ₫ối tượng khác
cần ₫ược bảo mật từ bên ngoài. Ví dụ các KernelProxies cung cấp truy
xuất ₫ến Kernel của hệ ₫iều hành.
Smart proxy : cung cấp ₫ối tượng ₫ại diện ₫ể bổ sung một số thao tác
khi có truy xuất ₫ến ₫ối tượng thực. Ví dụ proxy kiểm tra số tham khảo
₫ến ₫ối tượng, proxy thực hiện việc load persistent object trong lần tham
khảo ₫ầu tiên…
121
Thí dụ về mẫu Proxy
DocumentEditor Graphic
Draw()
GetExtent()
Store()
Load()
Image ImageProxy if (image==0)

image = LoadImage(filename);
Draw() image Draw() else image->Draw();
GetExtent() GetExtent()
Store() Store()
if (image==0)
Load() Load()
return extent;
imageImp filename else return image->GetExtent();
extent extent
Sơ ₫ồ cấu trúc của mẫu Proxy

Client Subject
Request()
...
RealSubject Proxy
// prolog code
Request() realSubject Request() realSubject->Request();
... ... // epilog code
... ...
122
Proxy
giữ liên hệ ₫ến ₫ối tượng RealSubject.
có thể thay thế ₫ối tượng RealSubject.
kiểm soát quá trình truy xuất ₫ến ₫ối tượng RealSubject, có thể tạo hoặc
delete ₫ối tượng này.
Thực hiện một số hoạt ₫ộng khác tùy loại Proxy:
+ remote proxy: encode và gửi thông tin ₫ến ₫ối tượng RealSubject ở
không gian ₫ịa chỉ khác.
+ virtual proxy: chứa các thông tin về ₫ối tượng realSubject ₫ể có thể khởi
tạo lại nó sau này.
+ protection proxy: kiểm tra ₫ối tượng ₫ang thực hiện truy xuất có quyền
không…
+ smart proxy: thực hiện các thao tác bổ sung khi có truy xuất ₫ến ₫ối
tượng thực.

Subject :
Định nghĩa interface chung cho 2 lớp ₫ối tượng RealSubject và Proxy, do ₫ó
₫ối tượng Proxy có thể thay thế vị trí ₫ối tượng RealSubject.
RealSubject:
Lớp thể hiện ₫ối tượng thực sự Client cần truy xuất.
Quá trình giao tiếp ở thời ₫iểm run-time có thể mô tả bằng sơ ₫ồ:
123
Các ngữ cảnh nên dùng mẫu Proxy
Các chương trình phân bố
Các hệ thống chương trình cần phối hợp hoạt ₫ộng của nhiều ₫ối tượng.
Các hệ thống middleware.
Hệ thống cần chia tải ₫ể phục vụ ₫ược nhanh.
DBMS, OS
…
Mẫu Decorator
Mục tiêu : thêm ₫ộng trách nhiệm cho ₫ối tượng.
muốn thêm trách nhiệm cho 1 số ₫ối tượng chứ không phải cho toàn bộ các
₫ối tượng của class tương ứng.
Ví dụ :
Toolkit GUI cho phép user thêm border và scrollbar vào bất kỳ phần tử GUI
nào như TextView...
aBorderDecorator
aScrollDecorator
component aTextView
component
component
124
Decorator
VisualComponent
Draw()
component
TextView Decorator
Draw() Draw() component->Draw();
ScrollDecorator BorderDecorator
Draw() Draw() Decorator::Draw();
ScrollTo() DrawBorder() DrawBorder();
scrollPosition borderWidth
Sơ ₫ồ cấu trúc của mẫu Decorator

Component
Operation()
component
ConcreteComponent Decorator
Operation() Operation() component->Operation();
ConcreteDecoratorA ConcreteDecoratorB
Operation() Operation() Decorator::Operation();
AddedBehavior() AddedBehavior();
addedState addedState
125
Component (VisualComponent)
₫ịnh nghĩa interface cho các ₫ối tượng mà ta cần thêm trách nhiệm cho
chúng 1 cách ₫ộng.
ConcreteComponent (TextView)
₫ịnh nghĩa ₫ối tượng mà ta cần thêm trách nhiệm cho chúng 1 cách ₫ộng.
Decorator
chứa tham khảo ₫ến ₫ối tượng Component và ₫ịnh nghĩa interface tương
thích với interface của Component.
ConcreteDecorator (BorderDecorator, ScrollDecorator)
thêm trách nhiệm cho thành phần gốc.
Các ngữ cảnh nên dùng mẫu Decorator

muốn thêm ₫ộng trách nhiệm cho 1 vài ₫ối tượng mà không ảnh hưởng
₫ến các ₫ối tượng cùng loại.
tích lũy thêm các trách nhiệm của ₫ối tượng.
khi không thể nới rộng ₫ối tượng bằng cách thừa kế (sợ bùng nổ hệ
thống class con-cha).
126
Facade
Mục tiêu : cung cấp interface hợp nhất cho tập các interface của 1 hệ
thống con. Facade ₫ịnh nghĩa 1 interface cấp cao hơn các interface có
sẵn ₫ể làm cho hệ thống con dễ sử dụng hơn.
tối thiểu hóa tính "coupling" giữa các hệ thống con ₫ể tối thiểu hóa giao tiếp
giữa các hệ thống con.
Ví dụ :
hệ thống con biên dịch có nhiều class phục vụ các bước biên dịch rời ràc
như Scanner, Parser, ProgramNode, BytecodeStream,
ProgramNodeBuilder. Để dịch source code, ta có thể viết 1 ứng dụng gọi
dịch vụ của từng class ₫ể duyệt token, parser, xây dựng cây cú pháp, tạo
code ₫ối tượng... Tuy nhiên làm như trên sẽ rất khó và dễ gây ra lỗi. Cách
khắc phục là ₫ịnh nghĩa 1 class mới với giao tiếp hợp nhất tên là Compiler,
nó cung cấp 1 hàm Compile (file), ứng dụng nào cần dịch source code chỉ
cần gởi thông ₫iệp Compile ₫ến ₫ối tượng Compiler.
Thí dụ về cấu trúc Facade

Compiler
Compile()
Sc a n n Toke
Stream er n
Pa rs e r Sy mb
ol
BytecodeStream Pro g r a m N o d e Pro g r a m N
B u ff e r ode
CodeGenerator
State mentN
ode
E x p r e ssio n N
ode
S t a c k M a c hi n e C o d e G e R ISCCodeGene V a ri a bl e N o
nerator rator de
127
Sơ ₫ồ cấu trúc của mẫu Facade
Facade

Facade (Compiler)
biết class nào liên quan ₫ến request xác ₫ịnh.
nhờ các ₫ối tượng liên quan thực hiêện request.
subsystem classes (Scanner, Parser,..)
hiện thực các chức năng của hệ thống con.
xử lý công việc ₫ược nhờ từ ₫ối tượng Facade.
không cần biết Facade, không có tham khảo ₫ến Facade.
128
Các ngữ cảnh nên dùng mẫu Facade
muốn cung cấp 1 giao tiếp ₫ơn giản cho 1 hệ thống con phức tạp.
muốn tạo thêm lớp ngăn cách hệ thống con với client.
Mẫu Flyweight
Mục tiêu : dùng phương tiện dùng chung ₫ể quản lý hiệu quả 1 số lớn
₫ối tượng nhỏ.
thiết kế hướng ₫ối tượng thường có nhiều ₫iểm lợi, nhưng hiện thực ấu trĩ
bản thiết kế có thể trả giá ₫ắt về sự không hiệu quả.
thí dụ chương trình xử lý văn bản có thể dùng khái niệm ₫ối tượng ₫ể miêu
tả bất kỳ phần tử cơ bản nào : ký tự, công thức, hình, .... Tuy nhiên ký tự là
₫ối tượng rất nhỏ và xuất hiện rất nhiều lần trong văn bản, nếu mỗi lần xuất
hiện 1 ký tự, ta tạo riêng 1 ₫ối tượng mới cho ký tự ₫ó thì rất không hiệu
quả. Mẫu Flyweight rất thích hợp ₫ể giải quyết vấn ₫ề dùng chung ký tự.
Flyweight là ₫ối tượng dùng chung dựa vào khái niệm cơ bản là trạng thái
trong và trạng thái ngoài. Trạng thái trong ₫ược chứa trong flyweight, ₫ộc
lập với ngữ cảnh sử dụng (code ký tự,...). Trạng thái ngoài phụ thuộc và
thay ₫ổi theo ngữ cảnh, nó không thể ₫ược chứa trong flyweight, ngữ cảnh
cần truyền cho flyweight trạng thái ngoài khi nhờ flyweight 1 công việc nào
₫ó.
129
Thí dụ về mẫu Flyweight
Glyph
Draw(Context)
Intersects(Point,Context)
Row Character Column

children Draw(Context) Draw(Context) Draw(Context) children
Intersects(Point,Contex Intersects(Point,Context Intersects(Point,Contex
t) ) t)
char c
Sơ ₫ồ cấu trúc của mẫu Flyweight

FlyweightFactory Flyweight
GetFlyweight(key) Operation(extrinsicState)
if (flyweight(key) exists
return existing flyweight
else {
create new flyweight;
add it to pool of flyweights;
return the new flyweight;
}
ConcreteFlyweight UnsharedConcreteFlyweight
Operation(extrinsicState Operation(extrinsicState)
)
intrinsicState allState
Client
130
Flyweight (Glyph)
₫ịnh nghĩa interface cho ₫ối tượng nhận yêu cầu và hoạt ₫ộng theo trạng
thái ngoài.
ConcreteFlyweight (Character)
hiện thực interface Flyweight thành các ₫ối tượng dùng chung.
UnsharedConcreteFlyweight (Character)
hiện thực interface Flyweight thành các ₫ối tượng không dùng chung.
FlyweightFactory
tạo và quản lý các ₫ối tượng Flyweight.
Client
chứa tham khảo ₫ến flyweight và nhờ khi cần
Các ngữ cảnh nên dùng mẫu Flyweight

Khi các ₫iều kiện sau ₫ồng thời thỏa mãn :
ứng dụng dùng 1 số lớn ₫ối tượng.
giá bộ nhớ cao vì phải chứa số lượng lớn ₫ối tượng.
phần lớn trạng thái ₫ối tượng có thể ₫ể bên ngoài.
nhiều nhóm ₫ối tượng có thể ₫ược thay thế bằng 1 số nhỏ ₫ối tượng khi
các trạng thái ngoài của chúng bị loại bỏ.
ứng dụng không phụ thuộc vào tên nhận dạng ₫ối tượng.
131
Chương 11
CÁC MẪU CREATIONAL

Mẫu Abstract Factory
Mẫu Factory Method
Mẫu Prototype
Mẫu Singleton
Mẫu Builder
Khoa CNTT Chương 11 : Các mẫu Creational
Creational Patterns
Creational design patterns giúp xây dựng hệ thống linh ₫ộng về mặt khởi
tạo, quản lý và sử dụng ₫ối tượng. Chúng có thể cho phép hệ thống chủ
₫ộng trong việc xác ₫ịnh ₫ối tượng nào ₫ược tạo, ai tạo ra ₫ối tượng ₫ó,
cách thức và thời ₫iểm khởi tạo ₫ối tượng ₫ó.
Đặc ₫iểm nổi bật trong creational patterns là chương trình cần sử dụng
₫ối tượng không trực tiếp sinh ra ₫ối tượng mà nhờ các phần tử trung
gian ₫ể tăng ₫ộ linh ₫ộng.
Class creational patterns sử dụng ₫ặc ₫iểm thừa kế ₫ể thay ₫ổi class sẽ
₫ược sử dụng ₫ể sinh ra ₫ối tượng, Object creational patterns truyền quá
trình khởi tạo ₫ối tượng cho một ₫ối tượng khác.
132
Ví dụ về quá trình khởi tạo ₫ối tượng
Xây dựng một mê lộ (maze) cho các trò chơi có sử dụng mê lộ.
Một mê lộ ₫ược ₫ịnh nghĩa bằng một tập hợp các phòng (room), mỗi
phòng biết các ₫ối tượng kế cận nó ở 4 hướng: bắc, nam, ₫ông, tây. Đối
tượng kế cận có thể là một phòng khác, một bức tường (wall) hay một
cánh cửa (door) sang phòng khác.
Các hướng có thể ₫ược hiện thực bởi các hằng số hay kiểu enum trong
C++:
enum Direction {North , South , East , West }
Lược ₫ồ lớp của hệ thống như sau:

MapSite
Enter()
sides Room Wall Door
Enter() Enter()
Maze SetSide() Enter()
rooms GetSide()
AddRoom()
RoomNo() isOpen
roomNumber
133
MapSite là lớp cha trừu tượng của tất cả các phần tử trong mê lộ.
MapSite chỉ có một phương thức Enter ₫ể chỉ thao tác ₫i vào một phần
tử (room, door, wall). Tùy ₫ặc ₫iểm của mình, các phần tử sẽ phải
override phương thức này.
Lớp Room có thể ₫ược hiện thực trong C++ như sau :
class Room : public MapSite {
public:
Room (int roomNo);
MapSite* GetSide (Direction) const;
void SetSide(Direction, MapSite*);
virtual void Enter();
private:
MapSite m_sides[4];
int m_roomNumber;
};

Class Wall có thể ₫ược hiện thực trong C++ như sau :
class Wall : public MapSite {
public:
Wall ();
};
Class Door có thể hiện thực trong C++ như sau :
class Door : public MapSite {
public:
Door (Room* = 0, Room*=0);
Room* OtherSideFrom (Room*);
private:
Room* m_room1, m_room2;
bool m_isOpen;
};
134
Lớp Maze có thể hiện thực trong C++ như sau :
class Maze {
public:
Maze();
void AddRoom(Room*);
Room* RoomNo(int) const;
private:
//…
};
Lớp MazeGame tích hợp những lớp ₫ã giới thiệu ₫ể tạo thành một game
có sử dụng mê lộ. Lớp này phải tạo ra một mê lộ (Maze), method
CreateMaze tạo một mê lộ ₫ơn giản gồm 2 phòng có thể ₫ược ₫ịnh
nghĩa trong C++ như sau :

Maze* MazeGame::CreateMaze() {
Maze* aMaze=new Maze;
Room* r1=new Room(1);
Room* r2=new Room(2);
Door* theDoor = new Door(r1,r2);
aMaze->AddRoom(r1)
aMaze->AddRoom(r2)
r1->setSide(North, new Wall); …
r2->setSide(North, new Wall); …
return aMaze;
}
Phương thức CreateMaze bị ràng buộc cứng (Hard code), ₫iều này dẫn ₫ến hai nhược
₫iểm :
- Không thể sinh ra một maze có cấu trúc khác (VD: các phần tử ở các hướng của
các room thay ₫ổi).
- Rất khó tái sử dụng phương thức này ₫ể tạo ra một maze có ₫ặc ₫iểm khác (VD:
maze trong ₫ó các phòng có thể có bom hoặc quà tặng, cửa giữa các phòng chỉ có
thể mở bằng câu thần chú…) vì CreateMaze ₫ã ràng buộc cứng các tên lớp.
135
Giải pháp khắc phục
Truyền cho phương thức CreateMaze một ₫ối tượng có khả năng sinh ra room, wall,
door theo ₫ặc thù của ứng dụng. Khi ₫ó nếu muốn thay ₫ổi maze thì chỉ cần truyền
một ₫ối tượng khác. Đây là hướng tiếp cận của mẫu Abstract Factory.
Code trong CreateMaze gọi các phương thức thông thường (hoặc virtual) ₫ể khởi
tạo ₫ối tượng thay vì gọi constructor của lớp tương ứng. Khi ₫ó nếu muốn thay ₫ổi
lớp sẽ tạo ₫ối tượng thì chỉ cần tạo một subclass thừa kế MazeGame, trong ₫ó
override các phương thức khởi tạo ₫ối tượng ở trên. Đây là hướng tiếp cận của mẫu
Factory Method.
CreateMaze ₫ược truyền các ₫ối tượng room, door, wall có khả năng sinh ra ₫ối
tượng tương tự chúng (clone). Khi ₫ó nếu muốn thay ₫ổi ₫ối tượng trong
CreateMaze, ta chỉ cần truyền vào các ₫ối tượng khác. Các ₫ối tượng truyền cho
CreateMaze gọi là Prototype và hướng tiếp cận này là của mẫu Prototype.
CreateMaze ₫ược truyền 1 ₫ối tượng mà có thể tạo mêlộ mới dùng các tác vụ thêm
phòng, cửa và tường vào mêlộ mà nó xây dựng rồi ta dùng thừa kế ₫ể thay ₫ổi các
phần của mêlộ hay cách thức xây dựng mêlộ. Đây là hướng tiếp cận của mẫu
Builder.
Trong các slide sau chúng ta sẽ tìm hiểu các mẫu phần mềm này.
Abstract Factory
Mục tiêu : cung cấp interface cho việc khởi tạo ₫ối tượng mà không cần
xác ₫ịnh trước lớp cụ thể (concrete) tương ứng.
Nhu cầu áp dụng : có những trường hợp khi xây dựng chương trình
chúng ta chưa biết chính xác hay chưa muốn ràng buộc lớp nào sẽ ₫ược
sử dụng ₫ể sinh ra ₫ối tượng, chẳng hạn:
chương trình có khả năng chạy trên nhiều platform. Mỗi platform có một họ
các lớp giao diện, việc sử dụng cụ thể họ lớp giao diện nào chỉ biết khi
chương trình chạy.
framework cần khởi tạo ₫ối tượng nhưng chưa biết trước lớp cụ thể sẽ sử
dụng.
Những chương trình như vậy thường có một số yêu cầu ₫ối với người thiết kế:
code chương trình phải có khả năng tương tác tổng quát lên các ₫ối tượng
sẽ ₫ược sinh ra.
dễ chuyển ₫ổi giữa các họ ₫ối tượng.
dễ bổ sung các họ ₫ối tượng mới.
136
Giải pháp ₫ề nghị:
Cung cấp interface cho các ₫ối tượng dự ₫ịnh sẽ ₫ược khởi tạo khi hệ thống
chạy, gọi là AbstractProduct.
Cung cấp interface ₫ể khởi tạo các ₫ối tượng kiểu AbstractProduct, gọi là
AbstractFactory.
Để khởi tạo một ₫ối tượng cụ thể, cần xây dựng 2 lớp concrete: một lớp hiện
thực interface AbstractFactory ₫ể khởi tạo ₫ối tượng từ lớp hiện thực
AbstractProduct.
Hướng tiếp cận trên là của mẫu Abstract Factory.
Thí dụ về mẫu AbstractFactory

WidgetFactory Client
CreateScrollbar() Window
CreateWindow()
PMWindow MotifWindow
MotifWidgetFactory PMWidgetFactory
CreateScrollbar() CreateScrollbar() Scrollbar

CreateWindow() CreateWindow()
PMScrollbar MotifScrollbar
137
Sơ ₫ồ cấu trúc của mẫu AbstractFactory
AbstractFactory Client
CreateProductA() AbstractProductA
CreateProductB()
ProductA2 ProductA1
ConcreteFactory1 ConcreteFactory2
CreateProductA() CreateProductA() AbstractProductB

CreateProductB() CreateProductB()
ProductB2 ProductB1

AbstractFactory : ₫ịnh nghĩa interface cho việc khởi tạo ₫ối
tượng. Thường là lớp Abstract.
ConcreteFactory : hiện thực các method trong interface
AbstractFactory ₫ể tạo ra các ₫ối tượng cụ thể. Hệ thống có nhiều
ConcreteFactory, mỗi ConcreteFactory sinh ra một nhóm ₫ối
tượng, các nhóm ₫ối tượng do các ConcreteFactory sinh ra tương
₫ồng nhau về vai trò.
AbstractProduct : lớp Abstract, ₫ịnh nghĩa interface cho một kiểu
lớp (kiểu lớp button, kiểu lớp Scrollbar…)
ConcreteProduct : lớp hiện thực ₫ối tượng ₫ược sinh ra từ lớp
ConcreteFactory tương ứng, thừa kế lớp Abstract Product.
138
Client : chương trình cần tạo các ₫ối tượng. Client chỉ sử dụng các
interface AbstractFactory và AbstractProduct.
Quá trình tương tác giữa các phần tử :
Tại thời ₫iểm compile, Client nắm giữ pointer ₫ến phần tử của lớp
AbstractFactory (giả sử là _factory).
Tại thời ₫iểm run-time, Client biết cần sử dụng họ ₫ối tượng
ConcreteProduct nào sẽ khởi tạo ₫ối tượng ConcreteFactory tương
ứng và gán vào _factory. Client thông qua interface AbstractFactory
₫ể yêu cầu ₫ối tượng ConcreteFactory sinh ra các ₫ối tượng mong
muốn.
Client dựa vào interface của các ₫ối tượng ConcreteProduct ₫ược
khai báo trong AbstractProduct ₫ể sử dụng các ₫ối tượng này.
Các ngữ cảnh nên dùng mẫu Abstract Factory

hệ thống muốn xác ₫ịnh quá trình khởi tạo và sử dụng ₫ối tượng tại thời
₫iểm chạy chương trình.
hệ thống muốn tương tác với một họ trong một tập hợp họ ₫ối tượng và
việc chọn họ ₫ối tượng ₫ược xác ₫ịnh tại thời ₫iểm run-time.
hệ thống muốn ràng buộc tính sử dụng ₫ồng thời các phần tử trong một
họ ₫ối tượng.
139
Ví dụ áp dụng
Lớp MazeFactory (tương ứng phần tử Abstract Factory) cung cấp
phương thức mặc ₫ịnh ₫ể khởi tạo các ₫ối tượng maze, wall, room, door.
Các lớp con thừa kế có thể override các phương thức này ₫ể sinh ra các
maze, wall, room, door khác.
MazeFactory không sử dụng Constructor mà cung cấp các method
Make ₫ể tạo ra các ₫ối tượng.
MazeFactory có thể ₫ược hiện thực trong C++ như sau:
class MazeFactory {
public: MazeFactory();
virtual Maze* MakeMaze() const { return new Maze;}
virtual Wall* MakeWall() const { return new Wall;}
virtual Room* MakeRoom(int n) const {
return new Room(n); }
virtual Door* MakeDoor(Room* r1, Room* r2) const {
return new Door(r1, r2);
}
Ví dụ áp dụng
Lớp MazeGame ₫óng vai trò là Client sử dụng mẫu Abstract Factory.
Phương thức CreateMaze ₫ược truyền một ₫ối tượng kiểu MazeFactory,
CreateMaze sử dụng ₫ối tượng này ₫ể sinh ra các ₫ối tượng cần thiết.
CreateMaze có thể ₫ược hiện thực trong C++ như sau:
Maze* MazeGame::CreateMaze (MazeFactory& factory) {
Maze* aMaze = factory.MakeMaze();
Room* r1 = factory.MakeRoom (1);
Room* r2 = factory.MakeRoom (2);
Door* aDoor = factory.MakeDoor(r1, r2);
aMaze->AddRoom(r1);
aMaze->AddRoom(r2);
r1->SetSide(North, factory.MakeWall());
…
return aMaze;
}
140
Ví dụ áp dụng
Để thay ₫ổi ₫ối tượng tạo ra, ta chỉ việc truyền một ₫ối tượng factory
khác, miễn là ₫ối tượng này thuộc kiểu MazeFactory.
VD ₫ể tạo một maze mà trong room có thể có bom, ta ₫ịnh nghĩa lớp
RoomWithABomb thừa kế lớp Room và lớp BombedMazeFactory thừa
kế lớp MazeFactory trong ₫ó override phương thức MakeRoom như sau:
Room* BombedMazeFactory::MakeRoom(int n) const {
return new RoomWithABomb(n);
}
Trong chương trình Game chỉ cần thực hiện ₫oạn code:
MazeGame game;
BombedMazeFactory factory;
game.CreateMaze(factory);
Ví dụ áp dụng
Khi áp dụng mẫu Abstract Factory, chương trình có một số ₫ặc ₫iểm :
có thể thích ứng với nhiều kiểu maze khác nhau.
việc thêm một kiểu maze chỉ là thêm một họ các lớp, không ảnh hưởng ₫ến
code chương trình ₫ã có.
chương trình nhất quán trong việc sử dụng một họ các phần tử của cùng
một kiểu maze, không xảy ra trường hợp 2 phần tử của 2 họ khác nhau
cùng tồn tại trong code của client.
việc bổ sung một loại phần tử vào maze sẽ gặp khó khăn vì phải bổ sung
vào lớp MazeFactory, do ₫ó sẽ ảnh hưởng ₫ến hầu như tất cả các lớp khác.
141
Factory Method
Mục tiêu : ₫ịnh nghĩa interface ₫ể sinh ra ₫ối tượng nhưng ₫ể cho lớp
con quyết ₫ịnh lớp nào ₫ược dùng ₫ể sinh ra ₫ối tượng. Factory Method
cho phép một lớp chuyển quá trình khởi tạo ₫ối tượng cho lớp con.
Tương tự nhu cầu áp dụng ở mẫu Abstract Factory: cần phải cung
cấp giải pháp tạo ₫ối tượng nhưng chưa biết ₫ược lớp cụ thể dùng ₫ể
sinh ra ₫ối tượng.
Hướng giải quyết theo mẫu Factory Method: thay vì tạo lớp Abstract
Factory ₫ể tạo các ₫ối tượng như trong mẫu Abstract Factory,
Factory Method tạo một phương thức ảo, các lớp con sẽ override
phương thức này ₫ể khởi tạo ₫ối tượng.
Sơ ₫ồ thí dụ
docs
Document Application
Open() CreateDocument() Document* doc=CreateDocument();

Close() NewDocument() docs.Add(doc);
Save() OpenDocument() doc->Open();
Revert()
MyDocument MyApplication
CreateDocument() return new MyDocument;
142
Sơ ₫ồ cấu trúc của mẫu Factory method
docs
Product Creator
FactoryMethod() ...
AnOperation() Product = FactoryMethod();
...
ConcreteProduct ConcreteCreator
FactoryMethod() return new ConcreteProduct;

Product : ₫ịnh nghĩa interface cho các ₫ối tượng sản phẩm.
ConcreteProduct : lớp thể hiện ₫ối tượng sản phẩm cần tạo. Hiện
thực interface Product.
Creator : ₫ịnh nghĩa factory method, sản phẩm trả về là ₫ối tượng
kiểu Product.
ConcreteCreator : thừa kế lớp Creator, override factory method
₫ể trả về ₫ối tượng ConcreteProduct.
143
Các ngữ cảnh nên dùng mẫu Factory Method
một lớp không biết trước lớp của ₫ối tượng mà nó cần khởi tạo.
một lớp muốn lớp con của mình thay ₫ổi hay xác ₫ịnh lớp của ₫ối tượng
cần khởi tạo.
một lớp muốn chuyển quá trình hiện thực một nhiệm vụ nào ₫ó cho một
trong các lớp con nhưng cho phép ứng dụng xác ₫ịnh lớp con cụ thể.
Ví dụ áp dụng
Lớp MazeGame ₫óng vai trò là Creator, cung cấp các factory method ₫ể
tạo các ₫ối tượng:
class MazeGame {
public: Maze* CreateMaze();
// factory methods:
virtual Maze* MakeMaze() const { return new Maze; }
virtual Room* MakeRoom(int n) const { return new Room(n); }
virtual Wall* MakeWall() const { return new Wall; }
virtual Door* MakeDoor(Room* r1, Room* r2) const { return
new Door(r1, r2); }
};
144
Ví dụ áp dụng
Method CreateMaze có thể ₫ược ₫ịnh nghĩa lại như sau:
Maze* MazeGame::CreateMaze () {
Maze* aMaze = MakeMaze();
Room* r1 = MakeRoom(1); Room* r2 = MakeRoom(2);
Door* theDoor = MakeDoor(r1, r2);
aMaze->AddRoom(r1);
aMaze->AddRoom(r2);
r1->SetSide(North, MakeWall());
//…….
r2->SetSide(North, MakeWall());
//…….
return aMaze;
}
Ví dụ áp dụng
Các maze game khác muốn thay ₫ổi phần tử trong game thì:
Định nghĩa các lớp thừa kế từ các lớp thể hiện các phần tử tương ứng
VD: RoomWithABomb thừa kế Room.
Định nghĩa lớp thừa kế lớp MazeGame, trong lớp này override factory
method tạo ra ₫ối tượng muốn thay ₫ổi.
VD:
class BombedMazeGame : public MazeGame {
public: BombedMazeGame();
virtual Wall* MakeWall() const { return new BombedWall; }
virtual Room* MakeRoom(int n) const
{ return new RoomWithABomb(n); }
};
145
Prototype
Mục tiêu : giúp khởi tạo ₫ối tượng bằng cách copy một ₫ối tượng khác
(prototype) ₫ang tồn tại.
Muốn tạo ₫ối tượng nhưng không biết hoặc không muốn sử dụng lớp
Concrete. Ví dụ Editor Framework cho phép ứng dụng bổ sung các
control vào toolbox nhưng chưa biết lớp cụ thể sẽ sinh ra Control.
Giải pháp ₫ề nghị :
+ Framework cung cấp interface ₫ể copy một ₫ối tượng, interface
này sẽ ₫ược các lớp concrete cần sinh ra ₫ối tượng implement.
+ Ứng dụng phát triển từ Framework hay component tạo ra ₫ối
tượng mong muốn, sau ₫ó mỗi lần tạo thêm một ₫ối tượng bằng
cách gọi hàm copy ₫ối tượng này.
Đây chính là phương pháp của mẫu Prototype.
Ví dụ về mẫu Prototype
Tool MusicsalNote
Manipulate()
Draw(Position)
Clone()
prototype
RotateTool GraphicTool
Staff MusicalNote
Manipulate() Manipulate()
Draw(Position)
Clone()
WholeNote HalfNote
p = protoype->Clone(); Draw(Position) Draw(Position)

while (user drag mouse) { Clone() Clone()
p->Draw(new position);
}
insert p onto drawing return copy of self; return copy of self;
146
Sơ ₫ồ cấu trúc của mẫu Prototype
prototype
Client Prototype
Operation() Clone()
ConcretePrototype1 ConcretePrototype2
p = protoype->Clone();
Clone() Clone()
return copy of self; return copy of shelf;

Prototype: cung cấp interface ₫ể copy chính nó (clone)
ConcretePrototype: hiện thực interface ₫ược cung cấp bởi
Prototype ₫ể copy chính nó.
Client: tạo mới ₫ối tượng bằng cách yêu cầu một ₫ối tượng ₫ã có
(prototype) copy chính nó.
147
Một số vấn ₫ề hiện thực
Class có thể cung cấp phương thức ₫ể set giá trị cho ₫ối tượng sau
khi ₫ược tạo ra bằng cách copy từ prototype.
Nếu số lượng prototype trong ứng dụng không cố ₫ịnh, nên quản
lý chúng bằng một ₫ối tượng prototype manager. Đối tượng này
chứa các tham khảo ₫ến các prototype và các key tương ứng ₫ể
truy xuất chúng.
Việc hiện thực phương thức clone phụ thuộc nhiều vào ngôn ngữ
lập trình. Có thể copy hoàn toàn (deep copy) hay share biến
(shallow copy).
Java, SmallTalk, Eiffel cung cấp phương thức clone(). C++ có
phương thức copy.
Tất cả những phương thức trên ₫ều mặc ₫ịnh thực hiện shallow
copy.
Khi hiện thực deep copy, ₫ể ý vấn ₫ề tham khảo vòng.
Các ngữ cảnh nên dùng mẫu Prototype

Mẫu Prototype thường ₫ược sử dụng khi hệ thống cần ₫ộc lập với các
₫ối tượng mà nó sinh ra và
khi lớp cần dùng ₫ể sinh ₫ối tượng ₫ược xác ₫ịnh tại thời ₫iểm
chương trình chạy (dynamic loading), hoặc
tránh trường hợp xây dựng số lượng các phần tử khởi tạo ₫ối tượng
ngang bằng với số lượng kiểu ₫ối tượng bổ sung dự ₫ịnh tạo ra, hoặc
khi các ₫ối tượng của cùng một class có ít ₫iểm khác biệt.
148
Ví dụ áp dụng
Chương trình này phát triển từ ví dụ áp dụng mẫu Abstract Factory.
Định nghĩa lớp MazePrototypeFactory thừa kế lớp MazeFactory, ₫ối
tượng lớp này ₫ược cung cấp các prototype ₫ể tạo ra các ₫ối tượng cùng
loại. MazePrototypeFactory có thể ₫ược hiện thực trong C++ như sau:
class MazePrototypeFactory : public MazeFactory{
public:
MazePrototypeFactory(Maze*, Wall*, Room*, Door*);
virtual Maze* MakeMaze() const;
...// Các method khởi tạo các phần tử của maze
private:
Maze* _mazePrototype;
Room* _roomPrototype;
Wall* _wallPrototype;
Door* _doorPrototype;
}
Ví dụ áp dụng
Constructor của lớp MazePrototypeFactory chỉ khởi tạo các prototype
với các ₫ối tượng tương ứng ₫ược cung cấp từ ứng dụng:
MazePrototypeFactory::MazePrototypeFactory (
Maze* m, Wall* w, Room* r, Door* d ) {
_mazePrototype = m;
_wallPrototype = w;
_roomPrototype = r;
_doorPrototype = d;
}
149
Ví dụ áp dụng
Các lớp Door, Wall, Room ₫ều phải hiện thực phương thức clone thừa kế
từ lớp MapSite và các phương thức set giá trị nếu cần:
class Door : public MapSite {
public: Door();
Door(const Door&);
virtual void Initialize(Room*, Room*);
virtual Door* Clone() const;
private: Room* _room1; Room* _room2;
};
Door::Door (const Door& other)
{ _room1 = other._room1; _room2 = other._room2; }
void Door::Initialize (Room* r1, Room* r2)
{ _room1 = r1; _room2 = r2; }
Door* Door::Clone () const { return new Door(*this); }
Ví dụ áp dụng
Các phương thức khởi tạo wall, room, door ₫ều clone prototype có sẵn
và set các giá trị nếu cần:
Wall* MazePrototypeFactory::MakeWall () const {
return _wallPrototype->Clone();
}
Door* MazePrototypeFactory::MakeDoor (Room* r1, Room *r2) const {
Door* door = _doorPrototype->Clone();
door->Initialize(r1, r2);
return door;
}
150
Ví dụ áp dụng
Để thay ₫ổi maze cần tạo, ta chỉ cần cung cấp các factory cho
constructor của MazePrototypeFactory :
MazeGame game;
MazePrototypeFactory bombedMazeFactory( new Maze, new
BombedWall, new RoomWithABomb, new Door );
Maze* maze = game.CreateMaze(bombedMazeFactory);
Khi bổ sung phần tử sản phẩm mới (VD: roomWithABomb), không cần
phải cung cấp lớp Factory (BombedMazeFactory) ₫ể sinh ra các sản
phẩm này mà chỉ cần cung cấp prototype của sản phẩm ₫ó.
Mẫu Builder
Mục tiêu : tách việc xây dựng ₫ối tượng phức tạp khỏi việc miêu tả nó
sao cho cùng 1 qui trình xây dựng có thể tạo ra nhiều sự miêu tả khác
nhau.
Trình ₫ọc file RTF cần ₫ổi file RTF sang 1 số dạng khác chưa biết
trước như text thô, Tex,... hay sang 1 ₫iều khiển soạn thảo text.
Giải pháp ₫ề nghị :
+ ₫ịnh nghĩa class TextConverter chứa các tác vụ chuyển ₫ổi token
cơ bản.
+ Mỗi ₫ịnh dạng cần chuyển tới sẽ ₫ược ₫ảm trách bởi 1 subclass
của class TextConverter.
Đây chính là phương pháp của mẫu Builder.
151
Ví dụ về mẫu Builder
builder
RTFReader TextConverter
ParseRTF() ConvertCharacter()
builders ConvertFont()
ConvertParagraph()
while (t=getnexttoken()) {
switch (t.type) {
ASCIIConverter TeXConverter TextWidgetConverter
case CHAR :
builder->ConvertCharacter(t.Char);
break; ConvertCharacter() ConvertCharacter() ConvertCharacter()
case FONT : GetASCIIText() ConvertFont() ConvertFont()
builder->ConvertFont(t.Font); ConvertParagraph() ConvertParagraph()
break; GetTeXText() GetTextWidget()
case PARA :
builder->ConvertParagraph();
}
}
ASCIIText TeXText TextWidget
Sơ ₫ồ cấu trúc của mẫu Builder

Director builder Builder
Construct() BuildPart()
builders
forall objects in structure {

builder->BuildPart();
ConcreteBuilder1 ConcreteBuilder2 ConcreteBuilder3
}
BuildPart() BuildPart() BuildPart()

GetResult() GetResult() GetResult()
Product1 Product2 Product3
152
Director (RTFReader) : xây dựng ₫ối tượng dùng interface Builder.
Builder (TextConverter) : cung cấp interface ₫ể xây dựng các phần của
₫ối tượng Product.
ConcreteBuilder (ASCIIConverter, TeXConverter) :
xây dựng và lắp ghép các phần của Product bằng cách hiện thực
interface của class Builder.
₫ịnh nghĩa và ghi giữ ₫ối tượng mà nó tạo ra.
cung cấp interface ₫ể nhận ₫ối tượng.
Product (ASCIIText, TeXText) :
miêu tả ₫ối tượng phức tạp cần xây dựng.
bao gồm các class ₫ịnh nghĩa các thành phần bao gồm interface
phục vụ việc lắp ghép các thành phần thành kết quả cuối cùng.
Các ngữ cảnh nên dùng mẫu Builder

Mẫu Builder thường ₫ược sử dụng khi :
giải thuật tạo ₫ối tượng phức tạp nên ₫ộc lập với các phần cấu thành
₫ối tượng và cách lắp ghép chúng.
qui trình xây dựng phải cho phép xây dựng nhiều biến thể khác nhau
của ₫ối tượng
153
Ví dụ áp dụng
Ta xây dựng interface của builder bằng class MazeBuilder sau :
class MazeBuilder {
protected:
MazeBuilder();
public:
// methods:
virtual void BuildMaze() { };
virtual void BuildRoom (int n) { };
virtual void BuildDoor (int roomFrom, int RoomTo) { } ;
virtual Maze* GetMaze() { return 0; };
};
Ví dụ áp dụng
Ta hiệu chỉnh hàm CreateMaze() của class MazeGame thành :
Maze* Mazegame::CreateMaze (MazeBuilder& builder) {
builder.BuildMaze();
builder.BuildRoom(1);
builder.BuildRoom(2);
builder.BuildDoor(1,2);
return builder.GetMaze();
}
Ta có thể ₫ịnh nghĩa các subclass của class MazeBuilder ₫ể tạo ra các
Maze khác nhau và tạo ₫ối tượng của subclass này rồi truyền nó như là
tham số của hàm CreateMaze() ₫ể tạo các Maze khác nhau.
154
Singleton
Mục tiêu : ₫ảm bảo mỗi class chỉ có 1 instance và cung cấp 1 ₫iểm truy
xuất toàn cục ₫ến ₫ối tượng.
chỉ 1 "printer spooler" ₫ể quản lý các máy in.
chỉ 1 trình quản lý cho các file của hệ thống file.
chỉ 1 trình quản lý windows cho các cửa sổ trên màn desktop...
Sơ ₫ồ cấu trúc của mẫu Singleton
Singleton
static Instance() return uniqueInstance ;

SingletonOperation()
GetSingletonData()
static uniqueInstance
singletonData
155
Singleton :
₫ịnh nghĩa tác vụ Instance giúp client truy xuất instance duy nhất của class.
Instance() là tác vụ chung của class (hàm static trong C++).
chịu trách nhiệm về việc tạo instance duy nhất cho class.
Cộng tác giữa các ₫ối tượng : các clients truy xuất instance của class
Singleton thông qua việc gọi tác vụ Instance() của class.

Chương 12
CÁC MẪU BEHAVIORAL

Mẫu Chain of Responsibility
Mẫu Template Method
Mẫu Strategy
Mẫu Command
Mẫu State
Mẫu Observer
156
Behavioral Patterns
Tập trung vào giải thuật và sự phân bố công việc giữa các object
Class patterns sử dụng thừa kế ₫ể chuyển giao thao tác giữa các class.
Object patterns sử dụng tính ₫a hình và bao gộp ₫ể truyền thao tác từ
₫ối tượng này sang ₫ối tượng khác.
Các slide sau sẽ giới thiệu các pattern Chain of Responsibility, Template
Method (class pattern), Strategy (object pattern) và Command (object
Pattern),..
Mẫu Chain of Responsibility

Mục tiêu : Tránh việc gắn kết cứng giữa phần tử gởi request với phần tử
nhận và xử lý request bằng cách cho phép hơn 1 ₫ối tượng có cơ hội xử
lý request. Liên kết các ₫ối tượng nềhận request thành dây chuyền rồi
"pass" request xuyên qua từng ₫ối tượng xử lý ₫ến khi gặp ₫ối tượng xử
lý cụ thể.
Nhu cầu áp dụng : Trong ứng dụng có trợ giúp theo ngữ cảnh thì user có
thể thu ₫ược thông tin trợ giúp của 1 phần tử giao diện nào ₫ó bằng cách
chỉ cần click vào nó. Ta nên tổ chức thông tin trợ giúp theo tính tổng
quát từ phần tử ₫ặc biệt nhất (nhỏ nhất) ₫ến tổng quát nhất (lớn nhất),
mỗi thông tin trợ giúp ₫ược xử lý bởi ₫ối tượng giao diện tương ứng phụ
thuộc vào ngữ cảnh.
157
Thí dụ về mẫu Chain of Responsibility
Thí dụ khi ấn phải chuột vào button OK thì trình trợ giúp của OKButton
sẽ chạy, nó sẽ hoặc hiển thị Help hoặc chuyển ₫iều khiển cho trình trợ
giúp của Dialog, trình trợ giúp của Dialog có thể chuyển ₫iều khiển ₫ến
Application...
aSavingDialog
handler
anApplication
aPrintButton
handler
handler
aPrintDialog
handler
anOKButton
handler
Thí dụ về mẫu Chain of Responsibility
handler
HelpHandler
HandleHelp() handler->HandleHelp();
Application Widget
Dialog Button
if (can handle)
ShowHelp();
HandleHelp() else
ShowHelp() Handler::HandleHelp();
158
Lược ₫ồ cấu trúc của mẫu Chain of Responsibility
successor
Client Handler
HandleRequest()
ConcreteHandler1 ConcreteHandler2
HandleRequest() HandleRequest()
aClient
aConcreteHandler
aHandler aConcreteHandler
successor
successor

Handler (HelpHandler) :
₫ịnh nghĩa interface của tác vụ xử lý request.
(optional) hiện thực mối liên kết ₫ến ₫ối tượng ₫i sau (successor).
ConcreteHandler (PrintButton, PrintDialog) :
xử lý request mà nó có trách nhiệm xử lý.
có thể truy xuất ₫ối tượng ₫i sau.
nếu có thể xử lý ₫ược request, nó sẽ xử lý, nếu không forward request cho
₫ối tượng ₫i sau giải quyết.
Client :
khởi ₫ộng request và gởi tới 1 ConcreteHandler ₫ầu tiên trong dây chuyền.
159
Các ngữ cảnh nên dùng mẫu Chain of Responsibility
Thường áp dụng mẫu Chain of Responsibility trong các trường hợp sau:
hơn 1 ₫ối tượng có thể xử lý request nhưng ₫ối tượng nào sẽ xử lý thì chưa
biết trước. Đối tượng xử lý sẽ ₫ược xác ₫ịnh ₫ộng.
bạn muốn gởi request ₫ến 1 ₫ối tượng xử lý nào ₫ó nhưng không xác ₫ịnh
rõ ràng.
muốn xác ₫ịnh tập các ₫ối tượng xử lý 1 request nào ₫ó 1 cách ₫ộng.
Template Method
Mục tiêu : ₫ịnh nghĩa bộ khung giải thuật trong một tác vụ nhưng cho
phép các class con hiện thực một số phần của tác vụ ₫ó.
Nhu cầu áp dụng : trong trường hợp Windows cho phép người lập trình
Hook vào hệ thống, Windows ₫ã ₫ể sẵn những entry mà người lập trình
có thể chèn thêm phần xử lý của mình. Người lập trình không thể thay
thế trình tự quá trình xử lý của Windows. Phương pháp lập trình hướng
₫ối tượng có thể cung cấp hướng giải quyết những vấn ₫ề này như sau:
Một lớp ₫ịnh nghĩa quá trình xử lý bao gồm nhiều tác vụ nhỏ hơn, các tác vụ
nhỏ hơn có thể cho lớp con override chính là các ₫iểm hook.
Các lớp con thừa kế hook vào quá trình xử lý của lớp cha bằng cách
override các ₫iểm hook.
Hướng tiếp cận như trên là của mẫu Template Method.
160
Ví dụ về mẫu Template Method
docs
Document Application
Save() AddDocument()
Open() OpenDocument()
Close() DoCreateDocument()
DoRead() CanOpenDocument()
AboutToOpenDocument()
document
MyDocument
MyApplication
DoRead()
DoCreateDocument() return new MyDocument;
CanOpenDocument()
AboutToOpenDocument()
Sơ ₫ồ cấu trúc mẫu Template Method
AbstractClass
TemplateMethod() ...
PrimitiveOperation1() PrimitiveOperation1();
PrimitiveOperation2() ...
PrimitiveOperation2();
...
ConcreteClass
PrimitiveOperation1()
PrimitiveOperation2()
161
AbstractClass (Application) :
₫ịnh nghĩa các primitive operation cho lớp con override ₫ể hiện thực một
phần của hoạt ₫ộng. Các phương thức này là ₫iểm mà lớp con có thể hook
vào code của lớp cha.
hiện thực template method, là method ₫ịnh nghĩa bộ khung của hoạt ₫ộng.
Template method kết hợp các primitive operation ₫ể thực hiện trọn vẹn hoạt
₫ộng.
ConcreteClass (MyApplication) : hiện thực các primitive operation ₫ể
can thiệp một phần vào quá trình thực hiện hoạt ₫ộng ở lớp cha.
Các ngữ cảnh nên dùng mẫu Template Method

Thường sử dụng Template method khi cần:
hiện thực một phần cố ₫ịnh của hoạt ₫ộng và cho phép lớp con hiện thực
phần có thể thay ₫ổi.
tập trung các hành vi giống nhau ở các lớp ₫ể tránh trùng lắp.
kiểm soát quá trình override của lớp con: chỉ cho phép override những ₫iểm
hook qui ₫ịnh sẵn.
162
Mẫu Strategy
Mục tiêu : Cung cấp một họ giải thuật và cho phép Client chọn lựa linh
₫ộng một giải thuật cụ thể khi sử dụng.
Nhu cầu áp dụng : Một số chương trình có nhiều giải thuật khác nhau
cho cùng một vấn ₫ề. Nhu cầu phát sinh: quản lý các giải thuật ₫ó một
cách ₫ơn giản và cho phép client chọn một trong những giải thuật ₫ó ₫ể
sử dụng một cách linh ₫ộng.
Ví dụ về nhu cầu ứng dụng Strategy

Chương trình chơi game có thể có nhiều giải thuật tùy vào mức ₫ộ khó
của cuộc chơi. Khi người chơi chọn mức ₫ộ khó dễ chính là thao tác
chọn giải thuật. Do ₫ó ₫ối tượng giải thuật phải tách biệt với code
chương trình. Một hướng giải quyết ₫ược ₫ề nghị như sau:
Định nghĩa 1 interface chung cho các lớp thể hiện các giải thuật.
Định nghĩa các lớp concrete hiện thực interface trên, mỗi lớp concrete thể
hiện một giải thuật.
Chương trình sử dụng ₫ối tượng kiểu interface và cho phép client thay thế
bằng ₫ối tượng thể hiện giải thuật cụ thể khi chạy.
→ hướng giải quyết vấn ₫ề của mẫu Strategy.
163
Ví dụ về mẫu Strategy
compositor
Composition Compositor
Traverse() Compose()
Repair()
compositor->Compose();
SimpleCompositor TeXCompositor ArrayCompositor

Compose() Compose() Compose()
Lược ₫ồ cấu trúc của mẫu Strategy

strategy
Context Strategy
ContextInterface() AlgorithmInterface()
ConcreteStrategyA ConcreteStrategyB ConcreteStrategyC

AlgorithmInterface() AlgorithmInterface() AlgorithmInterface()
164
Strategy (Compositor) : ₫ịnh nghĩa interface cho tất cả các lớp thể hiện
giải thuật. Có thể nhận pointer ₫ến ₫ối tượng Context trong quá trình
khởi tạo ₫ối tượng ₫ể truy xuất dữ liệu trong Context.
ConcreteStrategy (SimpleCompositor, TeXCompositor..) : hiện thực
interface Strategy, thể hiện một giải thuật cụ thể.
Context (Composition) :
tại thời ₫iểm dịch: chỉ sử dụng ₫ối tượng kiểu Strategy khi xác ₫ịnh giải thuật
cho vấn ₫ề cần xử lý.
tại thời ₫iểm run-time: ₫ược cung cấp một ₫ối tượng giải thuật cụ thể thay
thế cho ₫ối tượng Strategy.
có thể cung cấp entry cho phép ₫ối tuợng kiểu Strategy truy xuất dữ liệu.
Các ngữ cảnh nên dùng mẫu Strategy

Thường áp dụng mẫu Strategy trong các trường hợp sau:
Một lớp có nhiều hành vi loại loại trừ lẫn nhau và quá trình chuyển từ hành
vi này sang hành vi khác cần ₫ược thực hiện dễ dàng. Khi ₫ó mỗi hành vi sẽ
₫ược thể hiện trong 1 lớp Concrete Strategy và lớp có nhiều hành vi là lớp
Strategy.
Giải thuật cần ₫ược che dấu cả về dữ liệu và cấu trúc ₫ối với chương trình
Client.
Một số chương trình có thể áp dụng Strategy :
Compiler, OS: quá trình tối ưu hóa
Game: Quá trình chọn giải thuật
Các giao diện tổng quát (common dialog trong VB…)
165
Mẫu Command
Mục tiêu : ₫óng gói request vào trong một Object, nhờ ₫ó có thể thông
số hóa chương trình nhận request và thực hiện các thao tác trên
request: sắp xếp, log, undo…
Nhu cầu áp dụng : Đôi khi chúng ta cần gửi request ₫ến ₫ối tượng nhưng
không biết ₫ược hành ₫ộng sẽ ₫ược thực thi cũng như những ₫ối tượng
bị tác ₫ộng bởi request ₫ó. Ví dụ user interface toolkit cần xây dựng
trước việc truyền request ₫ến menu và button nhưng chỉ có ứng dụng cụ
thể mới xác ₫ịnh ₫ược hành ₫ộng khi click vào chúng. Vấn ₫ề này có thể
₫ược giải quyết như sau:
Ví dụ về nhu cầu ứng dụng mẫu Command

Xây dựng lớp trừu tượng Command, trong ₫ó có phương thức trừu tượng
Execute().
Menu hay button giữ liên kết ₫ến ₫ối tượng kiểu Command
Request ₫ược ₫óng gói trong các ₫ối tượng thừa kế Command. Các ₫ối
tượng này override phương thức Execute() ₫ể xác ₫ịnh hành ₫ộng khi thực
thi request.
Khi ứng dụng cần gửi request ₫ến cho menu hay button chỉ cần gửi ₫ối
tượng có ₫óng gói request ₫ó ₫i. Menu hay button sẽ gọi phương thức
Execute() trên ₫ối tượng ₫ó.
166
Ví dụ về mẫu Command
command
Application Menu MenuItem Command
Add(MenuItem) Clicked() Execute()
Add(Document)
Document
command->Execute();
Open()
Close()
Cut()
Copy()
Paste()
Thí dụ ₫ối tượng PasteCommand hỗ trợ hoạt ₫ộng dán text từ clipboard
vào 1 tài liệu. Phần tử nhận của PasteCommand là ₫ối tượng Document
mà PasteCommand ₫ược cung cấp trong lúc "instantiation". tác vụ
Execute gọi chức năng Paste trên Document nhận ₫ược.
Command
Execute()
Document
Open()
document
Close() PasteCommand
Cut()
Copy() document->Paste();
Execute()
Paste()
167
Tác vụ Execute của OpenCommand thì khác : nó hiển thị cửa sổ yêu
cầu user nhập tên document rồi tạo ₫ối tượng Document tương ứng,
"add" document vào ứng dụng nhận rồi mở document.
Command
Execute()
Application application
OpenCommand
Add(Document)
Execute() name = AskUser();
AskUser() doc = new Document(name);
application-.Add(doc);
doc->Open();
Đôi khi 1 option Menu cần thực thi 1 chuỗi các lệnh, chúng ta có thể
₫ịnh nghĩa class MacroCommand ₫ể cho phép thi hành 1 số lệnh chưa
biết trước.
Command
Execute()
commands
MacroCommand
Execute() forall c in commands

c->Execute();
168
Lược ₫ồ class của mẫu Command
Client
Command
Invoker
Execute()
Receiver
receiver
Action() ConcreteCommand
Execute() receiver->Action();
state

Command : Khai báo các phương thức ảo (Execute()…) ₫ể gọi thực thi
hay quản lý request.
ConcreteCommand (PasteCommand, OpenCommand):
Xác ₫ịnh ₫ối tượng nhận tương tác (₫ối tượng lớp Receiver).
Override phương thức Execute trong lớp Command ₫ể ₫áp ứng request.
Client (Application) : khởi tạo ₫ối tượng ConcreteCommand và truyền
₫ối tượng nhận tương tác cho nó.
Invoker (MenuItem): gửi request ₫ến ₫ối tượng Command.
Receiver (Document, Application) :
Đối tượng nhận tương tác trong ConcreteCommand.
Biết cách thực hiện những hành ₫ộng ₫ể ₫áp ứng request.
169
Quá trình cộng tác giữa các phẩn tử
Các ngữ cảnh nên dùng mẫu Command

Thông số hóa ₫ối tượng bằng hành vi mà ₫ối tượng ₫ó thực thi. Nghĩa là
một entry của ₫ối tượng có thể thực thi nhiều hành vi khác nhau tùy
thuộc vào thông số (là ₫ối tượng khác) truyền cho nó.
Quản lý, lưu trữ và thực thi request tại những thời ₫iểm khác nhau. Vì
trong mẫu Command, request ₫ược lưu trữ trong các ₫ối tượng nên việc
lưu trữ và quản lý request chỉ là việc lưu trữ và quản lý các ₫ối tượng.
Hỗ trợ undo, redo các thao tác. Phương thức Execute() có thể lưu trạng
thái cũ của ₫ối tượng Receiver ₫ể phục hồi lại khi có yêu cầu.
Hỗ trợ việc log lại các thay ₫ổi trên ₫ối tượng Receiver ₫ể có thể thực
hiện trở lại trong trường hợp ứng dụng chưa lưu ₫ối tượng Receiver ₫ã
thay ₫ổi mà hệ thống lại bị hỏng. (Ví dụ MS Word có chức năng
recovery).
Các hệ thống hỗ trợ transaction. Trường hợp này có thể kết hợp mẫu
Template Method.
170
Mẫu State
Mục tiêu : cho phép 1 ₫ối tượng thay ₫ổi hành vi khi trạng thái bên trong
của nó thay ₫ổi. Ta có cảm giác như class của ₫ối tượng bị thay ₫ổi.
Nhu cầu áp dụng : trong class TCPConnection miêu tả 1 mối nối mạng,
₫ối tượng TCPConnection có thể ở 1 trong nhiều trạng thái : Established,
Listening, Closed. Khi ₫ối tượng TCPConnection nhận request, nó sẽ
₫áp ứng khác nhau tùy vào trạng thái hiện hành.
→ hướng giải quyết vấn ₫ề của mẫu State.
Ví dụ về mẫu State
TCPConnection state
TCPState
Open() Open()
Close() Close()
Acknowledge() Acknowledge()
state->Open();
TCPEstablished TCPListen TCPClosed

Open() Open() Open()
Close() Close() Close()
Acknowledge() Acknowledge() Acknowledge()
171
Lược ₫ồ cấu trúc của mẫu State
Context state
State
Request() Handle()
... ...
state->Handle();
ConcreteStateA ConcreteStateB ConcreteStateC

Handle() Handle() Handle()
... ... ...

Context (TCPConnection) :
₫ịnh nghĩa interface cần dùng cho client.
duy trì 1 tham khảo ₫ến ₫ối tượng của 1 class con ConcreteState mà ₫ịnh
nghĩa trạng thái hiện hành.
State (TCPState) :
₫ịnh nghĩa interface nhằm bao ₫óng hành vi kết hợp với trạng thái cụ thể.
duy trì 1 tham khảo ₫ến ₫ối tượng của 1 class con ConcreteState mà ₫ịnh
nghĩa trạng thái hiện hành.
ConcreteState (TCPEstablished, TCPListen, TCPClose) :
₫ịnh nghĩa hành vi cụ thể kết hợp với trạng thái của mình.
172
Các ngữ cảnh nên dùng mẫu State
Thường áp dụng mẫu State trong các trường hợp sau:
hành vi của ₫ối tượng phụ thuộc vào trạng thái của nó và phải thay ₫ổi run-
time khi trạng thái thay ₫ổi.
các tác vụ có những lệnh ₫iều kiện số học lớn phụ thuộc vào trạng thái ₫ối
tượng.
Mẫu Observer
Mục tiêu : ₫ịnh nghĩa sự phụ thuộc 1-n giữa các ối tượng sao cho khi 1
₫ối tượng thay ₫ổi trạng thái thì các ₫ội tượng phụ thuộc ₫ược cảnh báo
hầu hiệu chỉnh tự ₫ộng (₫ể ₫ảm bảo tính nhất quán).
Nhu cầu áp dụng : trong ứng dụng quản lý bảng tính, mỗi bảng tính là 1
database nhưng nó ₫ược trình bày dưới nhiều dạng khác nhau như
spreadsheet, barchart, piechart,... Mỗi khi nội dung database thay ₫ổi ta
muốn cập nhật ₫ồng thời nhiều dạng biểu diễn nó.
→ hướng giải quyết vấn ₫ề của mẫu Observer.
173
Ví dụ về mẫu Observer
Spreadsheet BarChart PieChart
thay ₫ổi, notification
Database request, modification
Lược ₫ồ cấu trúc của mẫu Observer
Subject observers
Observer
Attach(Observer) Update()
Detach(Observer)
Notify() forall o in observers
o->Update();
ConcreteSubject ConcreteObserver
GetState() return subjectState(); Update() observerState =

SetState() subject->GetState();
observerState
subjectState
174
Subject :
biết observer của nó. Có thể có nhiều observer quan sát 1 subject.
cung cấp interface ₫ể Attach va Detach các observer vào mình.
Observer :
₫ịnh nghĩa interface hiệu chỉnh cho các ₫ối tượng mà sẽ ₫ược cảnh báo ₫ể
hiệu chỉnh subject của mình.
ConcreteSubject :
lưu trạng thái lưu ý tới các ₫ối tượng ConcreteObserver.
gởi cảnh báo tới các observer khi trạng thái của nó thay ₫ổi.
Concretebserver :
duy trì tham khảo tới ₫ối tượng ConcreteSubject.
lưu trạng thái mà cần phải luôn nhất quán với subject của mình.
hiện thực interface hiệu chỉnh ₫ể giữ trạng thái luôn nhất quán với subject
của mình.
Các ngữ cảnh nên dùng mẫu Observer

Thường áp dụng mẫu State trong các trường hợp sau:
khi 1 sự trừu tượng có 2 khía cạnh phụ thuộc lẫn nhau. Bao ₫óng các khía
cạnh này trong những ₫ối tượng ₫ộc lập giúp ta thay ₫ổi và dùng lại chúng
₫ộc lập.
khi việc thay ₫ổi ₫ối tượng này ₫òi hỏi phải thay ₫ổi các ₫ối tượng khác
nhưng bạn không biết trước có bao nhiêu ₫ối tượng cần thay ₫ổi.
khi ₫ối tượng cần có khả năng cảnh báo các ₫ối tượng khác nhưng không
muốn chúng ghép nối chặt với nhau.
175

Pttkhdtduml

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pttkhdtduml

Uploaded by

Copyright:

Available Formats

Trương Đai hoc Bach Khoa Tp.

Hö̀ Chñ Minh

PHÂN TÍCH & THIẾT KẾ

Nöi dung mön hoc

Trương Đai hoc Bach Khoa Tp. Hö̀ Chñ Minh

CAC KHAI NIÏM CƠ BAN CUA

Tư lêp trònh co cếu truc ₫ḯn OOP

Tư lêp trònh co cếu truc ₫ḯn OOP

module global data

Tö̉ng quat vï̀ hương ₫ö́i tương

Kiï̉u trưu tương (Abstract type)

~ Class ₫ịnh nghĩa chi ti ́t hi n thưc ₫ ́i tương :

Vñ du vï̀ class trong Java

z Bao ₫ong : che d ́u moi chi ti ́t hi n thưc cua ₫ ́i tương,

Tñnh thưa kḯ (inheritance)

class Line extends Geometry {

Tñnh bao göp (aggregation)

Goc nh n ngư nghĩa Goc nh n hi n

class Group : public Geometry {

Thöng ₫iïp (Message)

Kiï̉m tra kiï̉u (type check)

Tñnh thương tru (persistence)

Trương Đai hoc Bach Khoa Tp. Hö̀ Chñ Minh

THÑ DU VÏ NGÖN NGƯ OOP

Chỉ hö̃ trơ khai niïm class

Tềm vưc truy xuết thanh viïn

Cac ₫ö́i tương ₫ï̀u tam thơi

Cếu truc 1 chương trònh Dialog based ₫ơn gian

Cếu truc 1 chương trònh MDI ₫ơn gian

Hö̃ trơ Class va Interface

Tềm vưc truy xuết cac thanh phền

Hö̃ trơ ₫ềy ₫u tñnh ₫a hònh

₫ịa chỉ function 1

Thñ du vï̀ chương trònh Java

Thñ du vï̀ cac class Java

public class AlarmClock {

public synchronized boolean letMeSleepFor(Sleeper s, long time)

Thñ du vï̀ cac class Java

Thñ du vï̀ cac class Java

Trương Đai Hoc Bach Khoa Tp. HCM

NGUYÏN TĂÆC DỊCH OOP

• Chương tr nh la 1 t p cac ₫ ́i tương s ́ng va tương

Dịch 1 abstract type

• Abstract type chỉ chưa th ng tin trưu tương

• Dịch class la c ng vi c ch nh cua chương tr nh dịch

Dịch thuöc tñnh dư liïu

• m ̃i class → 1 record c ̉ ₫i ̉n.

Dịch thuöc tñnh dư liïu (tt)

Tao bang ₫ịa chỉ cac method (tt)

• tao bang ₫ịa chỉ g ̀m C1METHCNT ph ̀n tư (C1METHCNT la

Dịch 1 method (tt)

• co 2 v ́n ₫ ̀ lơn trong qua tr nh dịch 1 class sang ng n ngư c ̉

Tö́i ưu hoa code tao ra (tt)

Trương Đai Hoc Bach Khoa Tp. HCM

QUI TRÒNH HƠP NHÊT & UML

• Defines Who is doing What, When to do it,

New or changed New or changed

• Process Workflows What does

Cycle 1 Cycle 2 Cycle 3 Cycle 4 Cycle i Cycle n

Prelim ... Arch ... Dev Dev ... Trans ...

Release Release Release Release Release Release Release Release

• Inception Define the scope of the project and

Inception Elaboration Construction Transition