1

Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 1
Trương Đai hoc Bach 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
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 2
1. Ón lai 1 số khai niêm cơ ban cua hương ₫ối tương, cac ngôn ngư
hương ₫ối tương thương dung, cơ chế dịch cac type/class sang ngôn
ngư cổ ₫iển (ngôn ngư may).
2. Ón lai qui trình phat triển phần mềm hơp nhất.
3. Ón lai ngôn ngư UML ₫ươc dung ₫ể miêu ta cac artifacts cua qui
trình phat triển phần mềm hơp nhất.
4. Giơi thiêu cac mẫu thiết kế hương ₫ối tương ₫ươc dung phổ biến
trong cac ưng dung hiên hanh va cac ưng dung tương lai.
Nöi dung mön hoc
2
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 3
Tai liïu tham khao 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
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 4
Trương Đai hoc Bach Khoa Tp. Hö̀ Chñ Minh
Khoa Cöng Nghï Thöng Tin
Chương 1
CAC KHAI NIÏM CƠ BAN CUA
MÖ HÒNH HƯƠNG ĐÖI TƯƠNG
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
3
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 5
Nöi dung
1.1 Tư lêp trònh co cếu truc ₫ḯn OOP
1.2 Đö́i tương, thuöc tñnh, tac vu.
1.3 Abstract type va class.
1.4 Tñnh bao ₫ong.
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 quat hoa.
1.9 Tñnh vưng bï̀n.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 6
1. May tính số la thiết bị co thể thưc hiên 1 số hưu han cac chưc năng
cơ ban (tâp lênh), cơ chế thưc hiên cac lênh la tư ₫ông tư lênh ₫ầu
cho ₫ến lênh cuối cung. Danh sach cac lênh ₫ươc thưc hiên nay
₫ươc goi la chương trình.
2. bất ky công viêc ngoai ₫ơi nao cung co thể ₫ươc chia thanh trình tư
nhiều công viêc nho hơn. Trình tư cac công viêc nho nay ₫ươc goi
la giai thuât giai quyết công viêc ngoai ₫ơi. Mỗi công viêc nho hơn
cung co thể ₫ươc chia nho nưa,... ⇒ công viêc ngoai ₫ơi la 1 trình
tư cac lênh may (chương trình).
3. vấn ₫ề mấu chốt cua viêc dung may tính giai quyết vấn ₫ề ngoai
₫ơi la lâp trình. Cho ₫ến nay, lâp trình la công viêc cua con ngươi
(vơi sư trơ giup ngay cang nhiều cua may tính).
4. cac lênh cua chương trình (code) phai tham khao hoăc xư ly (truy
xuất) thông tin (dư liêu).
Tư lêp trònh co cếu truc ₫ḯn OOP
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
4
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 7
Tư lêp trònh co cếu truc ₫ḯn OOP
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
5. Dư liêu cua 1 chương trình co thể rất nhiều va ₫a dang. Để truy
xuất ₫ung 1 dư liêu ta cần :
- tên nhân dang.
- kiểu dư liêu miêu ta cấu truc dư liêu.
- tầm vưc truy xuất miêu ta giơi han khach hang truy xuất dư
liêu.
6. Chương trình cổ ₫iển = giai thuât + dư liêu.
7. Chương trình con (function, subroutine,...) cho phep cấu truc
chương trình, sư dung lai code...
8. Chương trình cổ ₫iển co cấu truc phân cấp như sau :
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 8
Chương trình = cấu truc dư liêu + giai thuât
entry 'start'
global data module
(package)
local data
of module
local data
of function
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Tư lêp trònh co cếu truc ₫ḯn OOP
5
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 9
Chương trình = tâp cac ₫ối tương tương tac nhau
entry
₫ối tương
(object)
local data
of object
local data
of operation
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Tư lêp trònh co cếu truc ₫ḯn OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 10
Tö̉ng quat 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ế) khac hăn so vơi trương phai cổ ₫iển
(co cấu truc).
ƒ Băt ₫ầu nhen nhom vao 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 thanh cac phương phap phân tích/thiết kế hương ₫ối
tương.
ƒ Va hiên nay ta co 1 qui trình phat triển phần mềm hơp nhất
dưa trên ngôn ngư UML.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
6
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 11
Đö́i tương (Object)
~ Mô hình ₫ối tương quan niêm chương trình bao gồm cac ₫ối
tương sinh sống va tương tac vơi nhau.
~ Đối tương bao gồm :
ƒ thuôc tính (dư liêu) : mang 1 gia trị nhất ₫ịnh tai tưng thơi ₫iểm.
ƒ tac vu (operation) : thưc hiên 1 công viêc nao ₫o.
Interface
(abstract type)
Implementation
(class)
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 12
Kiï̉u trưu tương (Abstract type)
~ Abstract type (type) ₫ịnh nghĩa interface sư dung ₫ối tương.
~ Interface la tâp cac entry ma bên ngoai co thể giao tiếp vơi ₫ối
tương.
~ Dung signature ₫ể ₫ịnh nghĩa mỗi entry, Signature gồm :
ƒ tên method (operation)
ƒ danh sach ₫ố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 cua method (thương la chu thích).
~ Dung abstract type (chư không phai 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ể) cua ₫ối
tương.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
7
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 13
Class (Implementation)
~ Class ₫ịnh nghĩa chi tiết hiên thưc ₫ối tương :
ƒ ₫ịnh nghĩa cac thuôc tính dư liêu : gia trị cua tất ca thuôc
tính xac ₫ịnh trang thai cua ₫ối tương.
ƒ kiểu cua 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 khao ₫ến ₫ối
tương khac.
ƒ coding cac method va cac internal function.
~ Định nghĩa cac method tao va xoa ₫ối tương.
~ Định nghĩa cac method constructor va destructor.
~ User không cần quan tân ₫ến class cua ₫ối tương.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 14
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
}
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
8
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 15
Tñnh bao ₫ong (encapsulation)
z Bao ₫ong : che dấu moi chi tiết hiên thưc cua ₫ối tương,
không cho bên ngoai thấy va truy xuất ⇒tính ₫ôc lâp cao
giưa cac ₫ối tương (hay tính kết dính - cohesion giưa cac
₫ối tương rất thấp).
ƒ che dấu cac thuôc tính dư liêu : nếu cần cho phep truy
xuất 1 thuôc tính dư liêu, ta tao 2 method get/set tương
ưng ₫ể giam sat 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 cac method.
ƒ che dấu cac internal function va sư hiên thưc cua chung.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 16
Tñnh thưa kḯ (inheritance)
~ Tính thưa kế cho phep giam nhe công sưc ₫ịnh nghĩa
type/class : ta co thể ₫ịnh nghĩa cac type/class không phai
tư ₫ầu ma băng cach kế thưa type/class co săn, ta chỉ ₫ịnh
nghĩa thêm cac 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 cac method cua class cha, kết qua
override chỉ co nghĩa trong ₫ối tương class con.
ƒ Đối tương cua class con co thể ₫ong vai tro cua ₫ối
tương cha nhưng ngươc lai thương không ₫ung.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
9
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 17
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
}
}
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 18
Tñnh bao göp (aggregation)
ƒ 1 ₫ối tương co thể chưa nhiều ₫ối tương khac tao nên mối
quan hê bao gôp 1 cach ₫ê qui giưa cac ₫ối tương.
ƒ Co 2 goc nhìn về tính bao gôp : ngư nghĩa va hiên thưc.
O
1
O
2
O
3
Goc nhìn ngư nghĩa
Goc nhìn hiên
thưc
O
1
O
2
O
3
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
10
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 19
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;
};
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 20
Thöng ₫iïp (Message)
~ Thông ₫iêp la 1 phep goi tac vu ₫ến 1 ₫ối tương tư 1
tham khao.
~ Thông ₫iêp bao gồm 3 phần :
ƒ tham khao ₫ến ₫ối tương ₫ích.
ƒ tên tac vu muốn goi.
ƒ danh sach tham số thưc cần truyền theo (hay nhân về tư)
tac vu.
ƒ ví du : aCircle.SetRadius (3); aCircle.Draw (pWnd);
~ Thông ₫iêp la phương tiên giao tiếp (hay tương tac)
duy nhất giưa cac ₫ối tương.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
11
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 21
Tñnh ₫a xa (Polymorphism)
~ Cung 1 lênh gơi thông ₫iêp ₫ến ₫ối tương thông qua cung 1
tham khao nhưng ơ vị trí/thơi ₫iểm khac nhau co thể gây ra
viêc thưc thi method khac nhau cua cac ₫ối tương khac
nhau.
T1 p1; // C1 va C2 la 2 class hiên thưc T1
...
p1 = New C1; // tao ₫ối tương C1, gan tham khao vao p1
p1.meth1(...);
...
p1 = New C2; // tao ₫ối tương C2, gan tham khao vao p1
p1.meth1(...);
Lênh p1.meth1(...); ơ 2 vị trí khac nhau kích hoat 2 method
khac nhau cua 2 class khac nhau.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 22
Kiï̉m tra kiï̉u (type check)
~ Chăt va dung mối quan hê 'conformity' (tương thích tổng
quat). Type A tương thích vơi type B ⇔A chưa moi method
cua B va ưng vơi tưng method cua B :
ƒ tồn tai 1 method cung tên trong A.
ƒ danh sach ₫ối số cua 2 method tương ưng phai băng
nhau.
ƒ kiểu ₫ối số OUT hay gia trị return cua method trong A
phai tương thích vơi kiểu cua ₫ối số tương ưng trong B.
ƒ kiểu ₫ối số IN cua method trong B phai tương thích vơi
kiểu cua ₫ối số tương ưng trong A.
ƒ kiểu ₫ối số INOUT cua method trong A phai trung vơi
kiểu cua ₫ối số tương ưng trong B.
Ö quan hê so trung hay quan hê con/cha (sub/super) la trương
hơp ₫ăc biêt cua quan hê tương thích tổng quat.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
12
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 23
Tñnh tö̉ng quat hoa (Generalization)
~ Co 2 ngư nghĩa khac nhau cua tính tổng quat hoa :
ƒ class tổng quat hoa cho phep san sinh tư ₫ông cac
class bình thương, cac class bình thương tư no chỉ co
thể tao ra ₫ối tương. Thương dung ngư nghĩa nay trong
giai ₫oan lâp trình.
ƒ ngươc vơi tính thưa kế : supertype/superclass la
type/class tổng quat hoa cua cac con cua no. Thương
dung ngư nghĩa nay trong giai ₫oan phân tích/thiết kế
phần mềm.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 24
Tñnh thương tru (persistence)
~ ₫ơi sống cua 1 ₫ối tương ₫ôc lâp vơi ₫ơi sống cua phần tư
tao ra no.
ƒ ₫ối tương phai tồn tai khi con ít nhất 1 tham khao ₫ến no
trong hê thống.
ƒ ₫ối tương phai bị xoa khi không con tham khao nao ₫ến
no, vì tai thơi ₫iểm nay ₫ối tương la rac. Viêc xac ₫ịnh
chính xac 1 ₫ối tương co phai la rac hay không la 1 viêc
phưc tap code ưng dung không ₫ươc phep lam, ₫ây la
công viêc cua hê thống thông qua module 'garbage
collection'.
ƒ vưng bền không phai la vĩnh hăng, mưc ₫ô co thể la 1
session cua may ao (JVM) hay lêu dai (thông qua ₫ĩa
cưng, CDROM).
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
13
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 25
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 cac ₫ối tương sống chung va tương tac vơi nhau.
~ Cac ₫ăc ₫iểm chính cua hương ₫ối tương :
ƒ Bao ₫ong : mỗi ₫ối tương bao gồm dư liêu va tac vu. Cac tac vu thiết
lâp nên hanh vi cua ₫ối tương. Cac ₫ối tương ₫ươc phân loai băng
class.
ƒ Cac ₫ối tương tương tac vơi nhau băng cach gơi thông ₫iêp.
ƒ giưa cac class/₫ối tương co thể tồn tai quan hê bao gôp, thưa kế, tổng
quat hoa.
ƒ Tính ₫a hình : kết qua cua sư kiểm tra kiểu dưa vao mối quan hê
'conformity'.
ƒ Tính vưng bền : ₫ối tương tồn tai khi con ít nhất 1 tham khao ₫ến no.
Chương 1: Cac khai niêm cơ ban cua mô hình hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 26
Chương 2
THÑ DU VÏ NGÖN NGƯ OOP
) Visual C++
) Java
Chương 2: Thí du về cac ngôn ngư OOP
Trương Đai hoc Bach Khoa Tp. Hö̀ Chñ Minh
Khoa Cöng Nghï Thöng Tin
14
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 27
2.1 Ngön ngư Visual C++
1. Chỉ hö̃ trơ khai niïm class.
2. Cho phep Đa thưa kḯ.
3. Dung 'abstract class' ₫ï̉ ₫ịnh nghĩa interface.
4. Tềm vưc truy xuết cac thanh phền.
5. Đa hònh co chon loc nhơ 'virtual function'
6. Chỉ hö̃ trơ cac ₫ö́i tương tam.
7. Override method khi thưa kḯ.
8. Co thï̉ ₫ịnh nghĩa function overloaded.
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 28
Chỉ hö̃ trơ khai niïm class
1. Dung class ₫ể ₫ịnh nghĩa kiểu cho cac biến, thuôc tính
⇒₫ối tương co thể chưa vât ly ₫ối tương khac hay chưa tham
khao ₫ến ₫ối tương khac.
2. Đa thưa kế trong ₫ịnh nghĩa class ⇒1 class co thể chưa nhiều
class con trung nhau ⇒dung "virtual base class" ₫ể tối ưu hoa
bô nhơ ₫ối tương.
Chương 2: Thí du về cac ngôn ngư OOP
15
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 29
Class trưu tương (Abstract class)
3. Hỗ trơ khai niêm "abstract class" ₫ể ₫ịnh nghĩa class chỉ chưa
thông tin interface nhưng không cho phep dung class nay ₫ể
₫ị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;
double xScale, yScale;
COLORREF color;
};
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 30
Tềm vưc truy xuết thanh 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 hoan toan.
protected : chỉ che dấu bên ngoai nhưng cho phep cac ₫ối
tương con, chau, chăt... truy xuất.
public : cho phep tất ca moi nơi truy xuất.
Friend class : la class ma mỗi function cua no ₫ều co thể truy
xuất tư do mỗi thanh phần cua class hiên tai.
Friend function : la function co thể truy xuất tư do mỗi thanh
phần cua class hiên tai.
Co thể han chế tầm vưc cua thanh viên cua class cha khi thưa
kế.
Chương 2: Thí du về cac ngôn ngư OOP
16
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 31
Hö̃ trơ tñnh ₫a hònh co chon loc
5. Định nghĩa 'virtual function' nếu muốn ap dung tính ₫a hình
trong viêc gơi thông bao yêu cầu function nay thưc thi.
Tất ca cac 'virtual function' ₫ươc quan ly trong 1 danh sach
"virtual function table".
₫ịa chỉ function 1
₫ịa chỉ function 2
₫ịa chỉ function 3
₫ịa chỉ function i
₫ịa chỉ function n
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 32
Cac ₫ö́i tương ₫ï̀u tam thơi
6. Cac ₫ối tương chỉ tồn tai tam thơi trong không gian process.
Tham khao ₫ến ₫ối tương thưc chất la pointer cuc bô.
chương trình phai tư viết code cho hoat ₫ông save/restore ₫ối
tương nếu muốn lưu giư/dung lai ₫ối tương.
VC++ hỗ trơ hoat ₫ông save/restore ₫ối tương nhơ kha năng
'Serialization'.
7. Co quyền 'override' bất ky toan tư hay function nao cua class
cha.
8. Cho phep ₫ịnh nghĩa cac ham 'overloaded' : cung tên nhưng
'signature' khac nhau.
Chương 2: Thí du về cac ngôn ngư OOP
17
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 33
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;
double xScale, yScale;
...
};
class Point : Geometry {};
class Line : Geometry { .... };
class Polygon : Geometry {....};
class Rectangle : Geometry {....};
....
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 34
Cếu truc 1 chương trònh Dialog based ₫ơn gian
InitInstance()
DoModal()
CProgramApp
CProgramDlg
Chương 2: Thí du về cac ngôn ngư OOP
18
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 35
Cếu truc 1 chương trònh SDI ₫ơn gian
InitInstance()
CProgramApp
CSingleDocTemplate
CMainFrame
CProgramView
CProgramDoc
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 36
Cếu truc 1 chương trònh MDI ₫ơn gian
InitInstance()
CProgramApp
CMultiDocTemplate
CChildFrame
CProgramView
CProgramDoc
Chương 2: Thí du về cac ngôn ngư OOP
19
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 37
2.2 Ngön ngư Java
1. Hö̃ trơ 'interface' (1 dang cua type) va class.
2. Hö̃ trơ Đơn thưa kḯ.
3. Dung 'abstract class' ₫ï̉ ₫ịnh nghĩa interface.
4. Tềm vưc truy xuết cac thanh phền.
5. Hö̃ trơ package
6. Đa hònh ₫ềy ₫u.
7. Chỉ hö̃ trơ ₫ö́i tương tam trong session JVM
8. Override function khi thưa kḯ.
9. Co thï̉ ₫ịnh nghĩa function overloaded.
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 38
1. Chu yếu dung class ₫ể ₫ịnh nghĩa kiểu cho cac biến, thuôc
tính.
Co thể dung interface ₫ể ₫ịnh nghĩa kiểu cho cac biến, thuôc
tính. Đối tương chỉ co thể chưa tham khao ₫ến ₫ối tương khac.
2. Phai goi ham tao ₫ối tương 1 cach tương minh, nhưng không
₫ươc xoa ₫ối tương.
class C1 extends RootClass {...}
C1 o1; // o1 chưa tham khao ₫ến ₫ối tương C1
o1 = New C1;
3. Interface chỉ ₫ươc dung 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 cac class kha ₫ơn gian.
Hö̃ trơ Class va Interface
Chương 2: Thí du về cac ngôn ngư OOP
20
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 39
Hö̃ trơ abstract class
5. Hỗ trơ khai niêm "abstract class" ₫ể ₫ịnh nghĩa class chưa
thông tin interface va không cho phep 'instanciate' ₫ối tương.
Ban chỉ co thể dung class 'abstract class' ₫ể ₫ăc ta kiểu cho
cac biến hoăc ₫ịnh nghĩa cac 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 cac hiên thưc bên trong,
nhưng thương chỉ co chưa cac 'abstract function'.
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 40
Tềm vưc truy xuết cac thanh phền
6. Tầm vưc truy xuất cac thanh phần trong ₫ối tương :
private : thanh phần bị che dấu hoan toan.
protected : che dấu bên ngoai nhưng cho phep cac ₫ối tương
con, chau, chăt... truy xuất.
public : cho phep tất ca moi nơi truy xuất.
friendly : cho phep moi phần tư trong package truy xuất. Đây
la tầm vưc default va không co tư khoa tầm vưc tương minh.
Chương 2: Thí du về cac ngôn ngư OOP
21
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 41
7. Package la ₫ơn vị quan ly tầm vưc cua java, co thể chưa nhiều
class.
package graphics;
public class Circle extends Graphic implements Draggable {
. . .
}
Tất ca moi phần tư ₫ươc ₫ịnh nghĩa trong 1 file source ₫ều
thuôc 1 package : tên ₫ươc qui ₫ịnh bơi phat biểu package hay
la package default.
Nhiều file source co thể thuôc cung 1package (dung cung tên
trong phat biểu package).
Hö̃ trơ package
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 42
Hö̃ trơ ₫ềy ₫u tñnh ₫a hònh
8. Tất ca cac public function ₫ươc quan ly trong 1 danh sach
"public function table".
₫ịa chỉ function 1
₫ịa chỉ function 2
₫ịa chỉ function 3
₫ịa chỉ function i
₫ịa chỉ function n
Chương 2: Thí du về cac ngôn ngư OOP
22
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 43
Cac ₫ö́i tương ₫ï̀u 'tam thơi'
9. Cac ₫ối tương chỉ tồn tai tam thơi trong 1session chay JVM.
Ban co thể tao ra cac ₫ối tương mơi ma không cần xoa no.
Đối tương se tồn tai môt khi con tham khao ₫ến no. Module
Garbage Collection trong JVM se chịu trach nhiêm phat hiên
₫ối tương 'rac' va xoa no ra khoi bô nhơ JVM.
10. Co quyền 'override' bất ky function nao cua class cha.
11. Cho phep ₫ịnh nghĩa cac ham 'overloaded' : cung tên nhưng
'signature' khac nhau.
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 44
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) {...}
}
}
Chương 2: Thí du về cac ngôn ngư OOP
23
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 45
Thñ du vï̀ chương trònh Java
Chương 2: Thí du về cac ngôn ngư OOP
12.34.25
AlarmClock
GUIClock
wakeup()
<<chưa>>
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 46
Thñ du vï̀ cac 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;
}
Chương 2: Thí du về cac ngôn ngư OOP
24
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 47
Thñ du vï̀ cac class Java
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;
}
}
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 48
Thñ du vï̀ cac class Java
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;
}
Chương 2: Thí du về cac ngôn ngư OOP
25
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 49
Thñ du vï̀ cac class Java
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);
}
}
}
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 50
Thñ du vï̀ cac class Java
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();
}
Chương 2: Thí du về cac ngôn ngư OOP
26
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 51
Thñ du vï̀ cac class Java
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);
}
}
Chương 2: Thí du về cac ngôn ngư OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 52
Trương Đai Hoc Bach 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
Chương 3: Nguyên tăc dịch OOP
27
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 53
• Chương trình la 1 tâp cac ₫ối tương sống va tương
tac lẫn nhau.
• Cac ₫ối tương thuôc 1 số loai nhất ₫ịnh (n)
• Mỗi loai ₫ố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 vong lăp dịch n type + n
class.
• Ta se miêu ta qui trình dịch 1 type va 1 class
Tö̉ng quat vï̀ vến ₫ï̀ dịch OOP
Chương 3: Nguyên tăc dịch OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 54
• 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 lai cây ngư nghĩa cua type
tương ưng ₫ể phuc vu viêc kiểm tra kiểu, chư không
tao code ma may.
• Chỉ cần 3 bươc : duyêt tư vưng, phân tích cu phap,
phân tích ngư canh.
• Nên dung công cu hỗ trơ như LEX, YACC.
Dịch 1 abstract type
Chương 3: Nguyên tăc dịch OOP
28
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 55
Chương 3: Nguyên tăc dịch OOP
• Dịch class la công viêc chính cua 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 cac method (hay cac internal function).
• Cần ₫ầy ₫u cac bươc : duyêt tư vưng, phân tích cu
phap, phân tích ngư canh, tao ma.
• Nên dung công cu hỗ trơ như LEX, YACC.
Dịch 1 class
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 56
Chương 3: Nguyên tăc dịch OOP
• class →cấu truc record
class C1 : C0 {
double d;
int i ;
...
public :
int proc4(int i);
void proc5 (double d);
...
};
Dịch thuöc tñnh dư liïu
typedef struct {
// import cac field tư cấu truc
// ₫ươc sinh ra tư C0
// cac field tương ưng vơi C1
int C1_d;
int C1_i;
...
// cac field dư liêu ₫iều khiển
// tư tao bơi chương trình dịch
void (*pvfaddr)() ;
} C1;
29
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 57
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 cac field dư liêu cua cấu truc sinh ra tư class cha.
• chuyển tưng thuôc tính cua class thanh tưng field cua record,
'tuyêt ₫ối hoa' tên cua thuôc tính ₫ể tranh nhăp nhăng.
• thêm cac field dư liêu ₫iều khiển phuc vu cho run-time : thí du
bang ₫ịa chỉ cac method cua ₫ối tương (pvftbl).
Chương 3: Nguyên tăc dịch OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 58
Dịch thuöc tñnh dư liïu (tt)
• cấu truc record ₫ươc dịch ra ma may thanh 1 vung nhơ liên tuc
co ₫ô dai băng ₫ô dai cua record.
- field C1 o1; C1_o1 db dup (sizeof(C1))
• truy xuất 1 thuôc tính dư liêu trơ thanh viêc truy xuất ô nhơ
dung cach ₫ịnh ₫ịa chỉ chỉ số :
- o1.i = 5; mov bx, C1_o1
mov [bx+4], 5
Chương 3: Nguyên tăc dịch OOP
30
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 59
class C1 : C0 {
int i ;
double d;
...
public :
int proc4(int i, double k);
void proc5 (double d);
...
};
Tao bang ₫ịa chỉ cac method
0 "proc1" C0_proc1
1 "proc2" C1_proc2
2 "proc3" C0_proc3
3 "proc4" C1_proc4
4 "proc5" C1_proc5
5 .... ...
fname faddr
pvftbl
Chương 3: Nguyên tăc dịch OOP
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 60
Tao bang ₫ịa chỉ cac method (tt)
• tao bang ₫ịa chỉ gồm C1METHCNT phần tư (C1METHCNT la
số method cua class hiên hanh, kể ca cac method thưa kế.
• mỗi phần tư ₫ươc nhân dang qua chỉ số va gồm 2 thông tin
chính : tên gơi nhơ cua method va ₫ịa chỉ cua method.
• copy bang ₫ịa chỉ cua class cha ₫a co.
• hiêu chỉnh lai cac ₫ịa chỉ cua cac method bị override.
• thêm vao cac method mơi ₫ịnh nghĩa trong class hiên hanh.
Chương 3: Nguyên tăc dịch OOP
31
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 61
Chương 3: Nguyên tăc dịch OOP
int C1::proc1(int i,double k) {
C2 o2;
C2 *p2;
C1::i = i;
d = k;
proc5(d);
o2.proc2(i,d);
p2 = New(C2);
p2->proc2(i,d);
....
};
Dịch 1 method
int C1_proc1(C1* p, int i, double d) {
C2 o2; C2 *p2;
// truy xuất thuôc tính
p->C1_i = i; p->C1_d = d;
// goi ham
C1_proc5(p,d);
C2_proc2(&o2, i,d);
// gơi thông bao : kiểm tra, load,
// anh xa bang ₫ịa chỉ method
for (i = 0; i <C1METHCNT; i ++)
if (strcmp ("proc2", p2->
pvftbl[i].fname)==0) break;
(*pvftbl[i].faddr)(p2,i,d);
};
1
2
3
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 62
Chương 3: Nguyên tăc dịch OOP
Dịch 1 method (tt)
• tên method ₫ươc chuyển tư dang 'tương ₫ối' sang 'tuyêt ₫ối'
(nối kết tên class vao).
• thêm tham số ₫ầu tiên cho ham sinh ra : miêu ta tham khao
₫ến ₫ối tương ma ham se truy xuất cac thuôc tính dư liêu.
• tên thuôc tính ₫ươc chuyển tư dang 'tương ₫ối' sang 'tuyêt ₫ối'
(nối kết tên class vao).
• goi ham internal →goi ham nhưng thêm tham số ₫ầu tiên.
• gơi thông bao 3 bươc :
— kiểm tra, tìm, load va anh xa bang ₫ịa chỉ cac method cua
₫ối tương.
— tìm chỉ số cua method cần goi trong bang (i).
— goi gian tiếp method thông qua ₫ịa chỉ phần tư thư i trong
bang.
32
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 63
Chương 3: Nguyên tăc dịch OOP
Tö́i ưu hoa code tao ra
• co 2 vấn ₫ề lơn trong qua trình dịch 1 class sang ngôn ngư cổ
₫iển.
— bang ₫ịa chỉ method chiếm nhiều chỗ.
— tốn thơi gian ₫ể phuc vu lênh gơi thông bao : kiểm tra, load
va anh xa bang ₫ịa chỉ, tìm chỉ số method cần goi va goi
gian tiếp qua ₫ịa chỉ trong bang.
• 1 số chương trình dịch tìm cach tối ưu hoa cac vấn ₫ề nay.
• slide sau la cac tối ưu hoa cua chương trình dịch C++ va cai gia
phai tra.
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 64
Chương 3: Nguyên tăc dịch OOP
Tö́i ưu hoa code tao ra (tt)
• trong C++, tất ca ₫ối tương ₫ều tam thơi va găn chăt vao ưng
dung →bang ₫ịa chỉ cac method cua cac ₫ối tương luôn năm
săn trong không gian cua ưng dung.
• mỗi lần tao ₫ối tương, biến pvftbl trong ₫ối tương ₫ươc gan
ngay ₫ịa chỉ ₫ầu bang method →không cần lam bươc 1 cho
mỗi lần gơi thông bao.
• C++ chỉ dung mối quan hê con/cha trong kiểm tra kiểu →công
viêc 2 ₫ươc lam tai thơi ₫iểm dịch thay vì tai thơi ₫iểm gơi thông
bao trong luc chay.
• côt tên gơi nhơ method không cần phai lưu trư trong bang ₫ịa
chỉ cac method.
• chỉ co cac virtual function mơi ₫ươc giai quyết theo cơ chế ₫a
hình, con cac function khac ₫ươc dịch ra lơi goi trưc tiếp.
33
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 65
Chương 3: Nguyên tăc dịch OOP
Tö́i ưu hoa code tao ra (tt)
• cai gia phai tra cua viêc tối ưu hoa trong C++ :
— ngươi lâp trình phai tư quyết ₫ịnh method nao cần xư ly
theo cơ chế ₫a hình, ham nao không ? Nếu sư quyết ₫ịnh
nay sai thì se gây lỗi khi chay, ma la ngươi thì kho long
quyết ₫ịnh chính xac.
— tính ₫a hình chỉ ₫ung giưa cac ₫ối tương co mối quan hê
con/cha, ơ ₫o thư tư cac ₫ịa chỉ method cua moi class con
trong bang ₫ịa chỉ luôn giống thư tư cac method tương ưng
cua class cha, tuy nhiên giưa 2 class bất ky thì không thể
₫am bao →kiểm tra kiểu trong C++ không thể nâng cấp lên
băng cach dung mối quan hê "conformity".
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 66
Trương Đai Hoc Bach Khoa Tp. HCM
Khoa Cöng nghï Thöng tin
Chương 4
QUI TRÒNH HƠP NHÊT & UML
) Qui trònh phat triï̉n phền mï̀m hơp nhết
) Tö̉ng quat vï̀ ngön ngư mö hònh UML
Chương 4: UML & Qui trình hơp nhất
34
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 67
New or changed
requirements
New or changed
system
Software Engineering
Process
What Is a Process?
• Defines Who is doing What, When to do it,
and How to reach a certain goal.
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 68
Key concepts
• Cycle
• Phase, Iterations
• Process Workflows
— Activity, steps
• Artifacts
— models
— reports, documents
• Worker: Architect
What does What does
happen? happen?
What is What is
produced? produced?
Who does Who does
it? it?
When does When does
architecture happen? architecture happen?
Chương 4: UML & Qui trình hơp nhất
When does When does
product happen? product happen?
35
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 69
Key concepts
Chương 4: UML & Qui trình hơp nhất
Cycle 1 Cycle 2 Cycle 3 Cycle 4 Cycle i Cycle n
time
Phase
Arch
Iteration
... Dev
Iteration
Dev
Iteration
... Trans
Iteration
...
Release Release Release Release Release Release Release Release
Prelim
Iteration
...
Inception Elaboration Construction Transition
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 70
Lifecycle Phases
time
Inception Elaboration Construction Transition
• 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
Chương 4: UML & Qui trình hơp nhất
36
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 71
Major Milestones
time
Vision Baseline
Architecture
Initial
Capability
Product
Release
Inception Elaboration Construction Transition
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 72
Phases and Iterations
An iteration is a sequence of activities with an established plan and
evaluation criteria, resulting in an executable release
Arch
Iteration
... Dev
Iteration
Dev
Iteration
... Trans
Iteration
...
Release Release Release Release Release Release Release Release
Prelim
Iteration
...
Inception Elaboration Construction Transition
Chương 4: UML & Qui trình hơp nhất
37
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 73
Iterations and Workflow
Pr elimi nary
Iteration(s)
iter.
#1
iter.
#2
iter.
#n
iter.
#n+1
ite r.
#n +2
it er.
#m
iter.
#m +1
Inception Elaboration Construction Transition
I t e r a t i o n s
Phases
Core Workflows
An iteration in the
elaboration phase
Requirements
Design
Implementation
Test
Analysis
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 74
Workflows and Models
Requirements
Design
Implementation
Test
Analysis
Use Case
Model
Design
Model
Depl.
Model
Impl.
Model
Analysis
Model
Test
Model
UML diagrams provide
views into each model
Each workflow is
associated with one or
more models.
Chương 4: UML & Qui trình hơp nhất
38
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 75
Use Case Model
Use Case
Diagrams
Collaboration
Diagrams
Component
Diagrams
Deployment
Diagrams
Object
Diagrams
Statechart
Diagrams
Sequence
Diagrams
Class
Diagrams
Activity
Diagrams
Use Case
Model
Design
Model
Depl.
Model
Impl.
Model
Analysis
Model
Test
Model
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 76
Analysis & Design Model
Use Case
Diagrams
Collaboration
Diagrams
Component
Diagrams
Deployment
Diagrams
Object
Diagrams
Statechart
Diagrams
Sequence
Diagrams
Class
Diagrams
Activity
Diagrams
Use Case
Model
Design
Model
Depl.
Model
Impl.
Model
Analysis
Model
Test
Model
Incl. subsystems
and packages
Chương 4: UML & Qui trình hơp nhất
39
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 77
Deployment and Implementation Model
Use Case
Diagrams
Collaboration
Diagrams
Component
Diagrams
Deployment
Diagrams
Object
Diagrams
Statechart
Diagrams
Sequence
Diagrams
Class
Diagrams
Activity
Diagrams
Use Case
Model
Design
Model
Depl.
Model
Impl.
Model
Analysis
Model
Test
Model
Incl. active classes
and components
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 78
Test Model
Use Case
Diagrams
Collaboration
Diagrams
Component
Diagrams
Deployment
Diagrams
Object
Diagrams
Statechart
Diagrams
Sequence
Diagrams
Class
Diagrams
Activity
Diagrams
Use Case
Model
Design
Model
Depl.
Model
Impl.
Model
Analysis
Model
Test
Model
Test model refers to
all other models and
uses corresponding
diagrams
Chương 4: UML & Qui trình hơp nhất
40
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 79
Overview of the Unified Process
• The Unified Process is
— Iterative and incremental
— Use case driven
— Architecture-centric
— Risk confronting
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 80
Use Case Driven
Req.ts Impl. Test
Use Cases bind these workflows together
Analysis Design
Chương 4: UML & Qui trình hơp nhất
41
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 81
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
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 82
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
Inception Elaboration Construction Transition
Chương 4: UML & Qui trình hơp nhất
42
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 83
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
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 84
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
Chương 4: UML & Qui trình hơp nhất
43
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 85
Relationships
• Dependency
• Association
• Generalization
• Realization
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 86
Extensibility Mechanisms
• Stereotype
• Tagged value
• Constraint
Chương 4: UML & Qui trình hơp nhất
44
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 87
Models, Views, and Diagrams
Use Case
Diagrams
Use Case
Diagrams
Use Case
Diagrams
Scenario
Diagrams
Scenario
Diagrams
Collaboration
Diagrams
State
Diagrams
State
Diagrams
Component
Diagrams
Component
Diagrams
Component
Diagrams
Deployment
Diagrams
State
Diagrams
State
Diagrams
Object
Diagrams
Scenario
Diagrams
Scenario
Diagrams
Statechart
Diagrams
Use Case
Diagrams
Use Case
Diagrams
Sequence
Diagrams
State
Diagrams
State
Diagrams
Class
Diagrams
Activity
Diagrams
A model is a complete
description of a system
from a particular
perspective
Models
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 88
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
Chương 4: UML & Qui trình hơp nhất
45
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 89
Use Case Diagram
• Captures system functionality as seen by users
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 90
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
Chương 4: UML & Qui trình hơp nhất
46
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 91
Class Diagram
• Captures the
vocabulary of a
system
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 92
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
Chương 4: UML & Qui trình hơp nhất
47
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 93
Object Diagram
• Captures instances and links
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 94
Object Diagram
• Shows instances and links
• Built during analysis and design
• Purpose
— Illustrate data/object structures
— Specify snapshots
• Developed by analysts, designers, and
implementers
Chương 4: UML & Qui trình hơp nhất
48
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 95
Component Diagram
• Captures the physical structure of the
implementation
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 96
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
Chương 4: UML & Qui trình hơp nhất
49
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 97
Deployment Diagram
• Captures the
topology of a
system’s
hardware
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 98
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
Chương 4: UML & Qui trình hơp nhất
50
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 99
Sequence Diagram
• Captures
dynamic
behavior (time-
oriented)
• Purpose
— Model flow of
control
— Illustrate typical
scenarios
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 100
Collaboration Diagram
• Captures dynamic behavior
(message-oriented)
• Purpose
– Model flow of control
– Illustrate coordination of
object structure and control
Chương 4: UML & Qui trình hơp nhất
51
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 101
Statechart Diagram
• Captures dynamic behavior (event-oriented)
• Purpose
— — Model object lifecycle Model object lifecycle
— — Model reactive objects (user interfaces, devices, Model reactive objects (user interfaces, devices,
etc.) etc.)
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 102
Activity Diagram
• Captures dynamic
behavior (activity-
oriented)
• Purpose
— Model business
workflows
— Model operations
Chương 4: UML & Qui trình hơp nhất
52
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 103
Architecture and the UML
Organization
Package, subsystem
Dynamics
Interaction
State machine
Design View Implementation View
Process View
Components
Classes, interfaces,
collaborations
Active classes
Deployment View
Nodes
Use Case View
Use cases
Chương 4: UML & Qui trình hơp nhất
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 104
Architecture and Models
Architecture embodies a collection of views of the models
Views
Models
Use Case
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Analysis
Model
Chương 4: UML & Qui trình hơp nhất
53
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 105
Trương Đai Hoc Bach Khoa Tp. HCM
Khoa Cöng nghï Thöng tin
Chương 5
NĂÆM BĂÆT YÏU CÊU HĐT
ƒ Cac artifacts cền tao ra
ƒ Cac workers tham gia
ƒ Qui trònh phên tñch
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 106
Muc ₫ích cua hoat ₫ô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 cach dung cac use-case. Cac ₫iểm
băt ₫ầu cho hoat ₫ông nay kha ₫a dang :
ƒ tư mô hình nghiêp vu (business model) cho cac ưng dung nghiêp
vu.
ƒ tư mô hình lĩnh vưc (domain model) cho cac ưng dung nhung
(embeded).
ƒ tư ₫ăc ta yêu cầu cua hê thống nhưng ₫ươc tao bơi nhom khac
va/hoăc dung cac phương phap ₫ăc ta khac (thí du như hương
cấu truc).
ƒ tư 1 ₫iểm nao ₫o năm giưa cac ₫iểm xuất phat trên.
Mu  c ₫ È c h c u  a h o a  t ₫é  n g n ă  m b ă  t yãu cÝ ̀ u
Chương 5: Năm băt yêu cầu hương ₫ối tương
54
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 107
Mô hình use-case :
ƒ actor : ngươi/hê thống ngoai/thiết bị ngoai tương tac vơi hê thống
ƒ use-case : cac chưc năng co nghĩa cua hê thống cung cấp cho
actor.
— flow of events
— cac yêu cầu ₫ăc biêt cua use-case
ƒ ₫ăc ta kiến truc (view of use-case model)
ƒ bang thuât ngư
ƒ cac prototype giao diên vơi user (user-interface prototype)
C a c artif a ct s cÝ ̀ n ta  o r a tr o n g n ă  m b ă  t yãu c Ý ̀ u
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 108
Use-Case Model
Actor
Use-Case System
Use - Case
*
1
*
C a c artif a ct s cÝ ̀ n ta  o r a tr o n g n ă  m b ă  t yãu c Ý ̀ u
Chương 5: Năm băt yêu cầu hương ₫ối tương
55
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 109
Use-Case
Model
System
Analyst
chịu trach nhiêm về
Use-case
Specifier
User-Interface
Designer
Architect
chịu trach nhiêm về
chịu trach nhiêm về
chịu trach nhiêm về
Architecture
Description
User Interface
Prototype
Use-Case Glossary Actor
C a c wor ker s tr o n g n ă  m b ă  t yãu cÝ ̀ u
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 110
Architect
Use-Case
Specifier
Find Actors &
Use-Cases
Q ui trÉ nh n ă  m b ă  t yãu c Ý ̀ u
User-Interface
Designer
System Analyst
Structure the
Use-Case Model
Prioritize
Use-Cases
Detail a
Use-Case
Prototype
User-Interface
Chương 5: Năm băt yêu cầu hương ₫ối tương
56
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 111
Muc ₫ích nhân dang actor va use-case la ₫ể :
ƒ Giơi han hê thống vơi môi trương bao quanh no.
ƒ Phat hoa ai va cac gì se tương tac vơi hê thống va hê thống cung
cấp cac chưc năng gì.
ƒ Năm băt va ₫ịnh nghĩa danh sach cac thuât ngư chung thiết yếu
cho viêc tao cac ₫ăc ta về cac chưc năng cua hê thống.
Hoat ₫ông nay gồm 4 bươc :
ƒ Tìm cac actor cua hê thống.
ƒ Tìm cac use cases cua hê thống.
ƒ Miêu ta văn tăt về tưng use-case.
ƒ Miêu ta toan thể mô hình use-case.
T É m A ct o r s & U s e c a s e s
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 112
Viêc tìm cac actor phu thuôc vao ₫iểm xuất phat : nếu xuất phat tư mô
hình nghiêp vu hay mô hình lĩnh vưc thì viêc tìm actor rất ₫ơn gian. Con
nếu xuất phat tư cac y niêm mơ hồ thì hay tra lơi cac câu hoi sau :
ƒ Ai la ngươi sư dung chưc năng chính cua 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
cua ho ?
ƒ Ai phai thưc hiên công viêc bao dương, quan trị va giư cho hê
thống hoat ₫ông ?
ƒ Hê thống se kiểm soat thiết bị phần cưng nao ?
ƒ Hê thống ₫ang xây dưng cần tương tac vơi nhưng hê thống khac
không ? Hê thống nao ?
ƒ Ai hoăc vât thể nao quan tâm ₫ến hay chịu anh hương bơi kết
qua ma hê thống phần mềm tao ra ?
T É m A ct o r s
Chương 5: Năm băt yêu cầu hương ₫ối tương
57
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 113
Viêc tìm cac use-case phu thuôc vao ₫iểm xuất phat : nếu xuất phat 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
gian. Con nếu xuất phat tư cac y niêm mơ hồ thì hay tra lơi cac câu hoi
sau :
ƒ Actor yêu cầu chưc năng gì cua hê thống ?
ƒ Actor cần phai ₫oc, tao, xoa, sưa ₫ổi hoăc lưu trư thông tin nao
cua hê thống ?
ƒ Actor cần thiết phai ₫ươc canh bao về nhưng sư kiên trong hê
thống, hay actor cần phai bao hiêu cho hê thống về vấn ₫ề nao
₫o không ?
ƒ Hê thống co thể hỗ trơ môt số công viêc thương nhât cua actor
nao ₫o không ?
T É m U s e-C a s e s
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 114
Mỗi use-case sau khi tìm ₫ươc, nên ₫ươc ₫ăt tên, ₫ươc miêu ta băng vai
câu tổng kết cac hoat ₫ông rồi sau ₫o ₫ăc ta tưng bươc hê thồng cần gì
₫ể tương tac vơi actor.
Dung lươc ₫ồ va cac flow of events ₫ể miêu ta mô hình use-case tổng
thể, ₫ăc biêt la cac mối quan hê giưa cac use-case va vơi actor.
Quan hê giưa cac actors : tổng quat hoa (generalization).
Quan hê giưa actor va use-case : liên kết (association).
Quan hê giưa cac use-cases :
ƒ tổng quat hoa.
ƒ include
ƒ extend
Miãu ta v ă n tăt tư ng U s e- C a s e s
Chương 5: Năm băt yêu cầu hương ₫ối tương
58
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 115
Cac né́i quan hã giưa cac actor va use-cases
Actor A
Use-Case X
Use-Case Y
Actor B
Use-Case Z
Use-Case B
Use-Case C
Use-Case D
Use-Case A
<<include>>
<<extend>>
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 116
Store Manager
Add New User
Remove User
Edit User Information
POS Login User Maint enance
<<exten...
<<extend>>
<<extend>>
<<include>>
Cac né́i quan hã giưa cac use-cases va use-cases
Chương 5: Năm băt yêu cầu hương ₫ối tương
59
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 117
Customer
Retail S tor e
Customer
Telephone
Customer
Online
Customer
Cus tomers
Cac né́i quan hã giưa cac actor va actor
Chương 5: Năm băt yêu cầu hương ₫ối tương
Quan hê giưa cac actors : tổng
quat hoa (generalization).
Thí du Customer la actor tổng
quat hoa cua cac actor Online
Customer, Telephone Customer,
Retail Store Customer.
Lưu y actor tổng quat hoa
thương không co thât, no la
phần tư trưu tương.
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 118
Lươc ₫é̀ use-case Sales:From Order to Delivery
Chương 5: Năm băt yêu cầu hương ₫ối tương
Perform Transaction
Buyer
Order Goods & Services
Confirm Order
Invoice Buyer
Send Reminders
Seller
Accounti ng System
Pay Overdraft Fee
Pay Invoice
<<extend>>
Ini tiator
Initiator
Initiator
Initiator
Initiator
60
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 119
Lươc ₫é̀ trang thai cua use-case Pay Invoice
Chương 5: Năm băt yêu cầu hương ₫ối tương
Browsing
Invoice
Scheduled
Invoice Paid
Invoice
Cancelled
reject
schedule
pay on due date
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 120
Xây dưng cac lươc ₫ồ use-case va cac ₫ăc ta giai thích mô hình use-
case, nhất la cach thưc ma cac use-case quan hê vơi nhau hay vơi cac
actor :
ƒ lươc ₫ồ miêu ta cac use-case phuc vu cho 1 actor hay 1
use-case nghiêp vu.
ƒ ₫ể ₫am bao tính nhất quan khi miêu ta nhiều use-case ₫ồng
thơi, nên xây dưng 1 bang thuâ ngư chung (glossary).
ƒ mô hình use-case co thể ₫ươc tổ chưc dang cây thư bâc
nhơ cac package use-case.
ƒ xây dưng ₫ăc ta "survey" cho mô hình use-case tổng thể va
nhơ khach hang va ngươi dung kiểm tra, ₫anh gia lai.
Miãu ta té̉ng thã̉ mé hÉnh Use-Cases
Chương 5: Năm băt yêu cầu hương ₫ối tương
61
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 121
ƒ cac use-case tìm ₫ươc không phai thiết yếu như nhau, do ₫o
kiến truc sư cần săp xếp thư tư ưu tiên chung ₫ể xac ₫ịnh
use-case nao nên ₫ươc phat triển trươc, use-case nao ₫ươc
phat triển sau.
ƒ kết qua cua hoat ₫ông nay la xây dưng ₫ươc goc nhìn kiến
truc cua mô hình use-case, no ₫ươc dung ₫ể hoach ₫ịnh
cac bươc lăp cung vơi cac yếu tố khac như nghiêp vu, kinh
tế...
Săp thư tư ưu tiãn cac use-case
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 122
Muc ₫ích la ₫ăc ta "flow of events" cho tưng use-case :
ƒ cấu truc ₫ăc ta use-case.
ƒ ₫ăc ta use-case bao gồm nhưng gì.
ƒ hình thưc hoa ₫ăc ta use-case.
Cấu truc ₫ăc ta use-case :
ƒ gồm 1 luồng công viêc cơ ban va cac luồng phu.
Cac luồng phu co thể xay ra vì cac ly do :
ƒ Actor co thể chon thưc hiên 1 trong nhiều nhanh.
ƒ Nếu hơn 1 actor dung use-case, cac hoat ₫ông cua ho co
thể anh hương lẫn nhau.
ƒ Hê thống co thể phat hiên lỗi nhâp tư actor.
ƒ 1 số tai nguyên không hoat ₫ông tốt lam cho use-case
không hoan tất công viêc ₫ung cua no.
Chi tiã́t hoa Use-Case
Chương 5: Năm băt yêu cầu hương ₫ối tương
62
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 123
ƒ nên ₫ịnh nghĩa trang thai băt ₫ầu.
ƒ khi nao va cach nao use-case băt ₫ầu.
ƒ thư tư cac hoat ₫ông ₫ươc thưc hiên.
ƒ khi nao va cach nao use-case kết thuc.
ƒ nên ₫ịnh nghĩa trang thai kết thuc.
ƒ không cho phep nhiều 'path' thưc thi.
ƒ Co thể miêu ta luồng thi hanh phu trong ₫ăc ta luồng cơ
ban.
ƒ Đăc ta luồng phu ₫ươc rut trích tư luồng cơ ban.
ƒ Tương tac giưa hê thống va actor va chung trao ₫ổi nhưng
gì.
ƒ Viêc dung cac ₫ối tương, gia trị, tai nguyên trong hê thống.
ƒ Phai miêu ta ro rang hê thống lam gì va actor lam gì.
Đăc ta use-case gé̀m nhưng gÉ ?
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 124
Khi sư tương tac giưa actor va use-case gồm nhiều trang thai
phưc tap ta nên dung ky thuât mô hình trưc quan ₫ể diễn ta use-
case vì no giup nha phân tích hiểu ro hơn về use-case :
ƒ lươc ₫ồ trang thai UML co thể ₫ươc dung ₫ể miêu ta trang
thai cua use-case va sư chuyển giưa cac trang thai.
ƒ lươc ₫ồ hoat ₫ông co thể ₫ươc dung ₫ể miêu ta sư chuyển
trang thai chi tiết hơn dươi dang cac hoat ₫ông.
ƒ lươc ₫ồ tương tac co thể ₫ươc dung ₫ể miêu ta cac tương
tac giưa ₫ối tương use-case va ₫ối tương actor.
Không nên lam dung cac lươc ₫ồ vì ₫ây la ngôn ngư cua nha phat
triển, cac khach hang va ngươi dung kho long hiểu nổi.
HÉnh thưc hoa use-case (Formalizing)
Chương 5: Năm băt yêu cầu hương ₫ối tương
63
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 125
Mô hình use-case ₫ươc cấu truc lai ₫ể :
ƒ rut trích cac use-case tồng quat va dung chung bơi cac use-
case ₫ăc biêt hơn.
ƒ rut trích cac use-case nhiêm y va phu thêm ₫ể nơi rông use-
case khac.
Trươc khi hoat ₫ông nay xay ra :
ƒ nha phân tích ₫a nhân diên tương ₫ối ₫ầy ₫u cac actor va
use-case, miêu ta chung trong cac lươc ₫ồ ₫ể cấu thanh mô
hình use-case tổng thể.
ƒ ngươi ₫ăc ta use-case ₫a phat triển ₫ăc ta chi tiết cho mỗi
use-case.
CÝ́u truc lai mé hÉnh Use-Case
Chương 5: Năm băt yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 126
Cac công viêc cu thể :
ƒ Nhân dang cac use-case tổng quat ₫ươc dung chung.
ƒ Nhân dang cac use-case co quan hê "extend".
ƒ Nhân dang cac use-case co quan hê "include".
Môt số ₫iều lưu y :
ƒ Cấu truc cac use-case va mối quan hê giưa chung nên phan
anh cac 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 chon use-case qua lơn hay qua nho.
ƒ Tranh chia nho use-case.
CÝ́u truc lai mé hÉnh Use-Case
Chương 5: Năm băt yêu cầu hương ₫ối tương
64
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 127
Trương Đai Hoc Bach Khoa Tp. HCM
Khoa Cöng nghï Thöng tin
Chương 6
PHÊN TÑCH HƯƠNG ĐÖI TƯƠNG
ƒ Cac artifacts cền tao ra
ƒ Cac workers tham gia
ƒ Qui trònh phên tñch
Chương 6: Phân tích yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 128
Muc ₫ích cua hoat ₫ông phân tích yêu cầu la xây dưng mô hình phân
tích vơi cac ₫ăc ₫iểm sau :
ƒ dung ngôn ngư cua nha phat triển ₫ể miêu ta mô hình.
ƒ thể hiên goc nhìn tư bên trong cua hê thống.
ƒ ₫ươc cấu truc tư cac class phân tích va cac package phân tích.
ƒ ₫ươc dung chu yếu bơi nha phat triển ₫ể hiểu cach thưc tao hình
dang hê thống.
ƒ loai trư moi chi tiết dư thưa, không nhất quan.
ƒ phat hoa cac hiên thưc cho cac chưc năng bên trong hê thống.
ƒ ₫ịnh nghĩa cac 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.
Muc ₫Èch cua phÝn tÈch yãu cÝ̀u
Chương 6: Phân tích yêu cầu hương ₫ối tương
65
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 129
Mô hình phân tích = hê thống phân tích :
ƒ cac class phân tích
— boundary class
— entity class.
— control class
ƒ cac dẫn xuất use-case cấp phân tích :
— cac lươc ₫ồ class phân tích
— cac lươc ₫ồ tương tac (công tac,...).
— 'flow of events' ơ cấp phân tích
— cac yêu cầu ₫ăc biêt cua use-case
ƒ cac package phân tích
ƒ ₫ăc ta kiến truc (view of analysis model)
Cac artifacts cÝ̀n tao ra trong phÝn tÈch yãu cÝ̀u
Chương 6: Phân tích yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 130
Analysis
Model
Analysis
System
Use-Case Reali zation -
Analysis
Analysis Class
Analysis Package
Cac artifacts cÝ̀n tao ra trong phÝn tÈch yãu cÝ̀u
*
*
*
*
*
*
1
Chương 6: Phân tích yêu cầu hương ₫ối tương
66
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 131
Analysis
Model
Use-Case
Engineer
Component
Engineer
Architect
Architecture
Description
Use-Case
Realization -
Analysis
Analysis
class
Analysis
package
chịu trach nhiêm về chịu trach nhiêm về chịu trach nhiêm về
Chương 6: Phân tích yêu cầu hương ₫ối tương
Cac workers trong phÝn tÈch yãu cÝ̀u
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 132
Architect
Use-Case
Engineer
Architectural
Analysis
Analyze a
Use-Case
Analyze a
Class
Analyze a
Package
Qui trÉnh phÝn tÈch yãu cÝ̀u
Component
Engineer
Chương 6: Phân tích yêu cầu hương ₫ối tương
67
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 133
Muc ₫ích cua phân tích kiến truc la phat hoa mô hình phân tích va kiến
truc hê thống băng cach nhân dang cac package phân tích, cac class
phân tích dễ thấy va cac yêu cầu ₫ăc biêt chung cho hê thống.
Cac package phân tích giup tổ chưc hê thống thanh nhưng ₫ơn vị nho
dễ quan ly. Mỗi package chưa 1 số use-case vơi tính chất sau :
ƒ cac use-case hỗ trơ cho cung 1 qui trình nghiêp vu.
ƒ cac use-case hỗ trơ cho cung 1 actor.
ƒ cac use-case co quan hê lẫn nhau : tổng quat hoa, include va
extend.
Theo thơi gian, khi viêc phân tích tiến triển, sư tinh chế cấu truc cac
package se tiến triển theo.
PhÝn tÈch kiã́n truc : nhÝn dang cac package phÝn tÈch
Chương 6: Phân tích yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 134
Co 3 loai (stereotype) class phân tích :
ƒ class biên (boundary class) mô hình sư tương tac 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,
loai thông tin co tính bền vưng, tồn tai lâu dai.
ƒ class ₫iều khiển (control class) mô hình viêc xư ly, công tac, giao
tac trong use-case.
3 loai class phÝn tÈch
Chương 6: Phân tích yêu cầu hương ₫ối tương
Boundary class Entity class Control class
68
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 135
Tư cac class lĩnh vưc hay cac class nghiêp vu trong bươc năm băt yêu
cầu, ₫ề nghị 1 số class thưc thể quan trong nhất (tư 10-20).
Cac class phân tích con lai se ₫ươc nhân dang trong hoat ₫ông phân
tích use-case.
Cac yêu cầu ₫ăc biêt cung ₫ươc nhân dang ₫ể ₫ươc xư ly trong cac
bươc sau, chung gồm :
ƒ tính bền vưng.
ƒ sư phân tan & ₫ồng thơi.
ƒ cac tính chất an toan dư liêu.
ƒ ₫ề khang vơi lỗi.
ƒ quan ly giao tac.
Tính chất cua 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 kiã́n truc : nhÝn dang cac class thưc thã̉ dã̃ thÝ́y
Chương 6: Phân tích yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 136
Phân tích use-case la ₫ể :
ƒ nhân dang cac class phân tích co ₫ối tương cua chung tham
gia vao viêc thưc hiên 'flow of events' cua use-case.
ƒ phân phối hanh vi cua use-case băng cach cho cac ₫ối
tương phân tích tương tac nhau.
ƒ năm băt 1 số yêu cầu ₫ăc biêt cho dẫn xuất use-case.
PhÝn tÈch use-case
Chương 6: Phân tích yêu cầu hương ₫ối tương
69
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 137
Trong bươc nay ta nhân dang cac class ₫iều khiển, biên, thưc thể cần
thiết ₫ể hiên thưc use-case va phat hoa tên, trach nhiêm, thuôc tính va
cac mối quan hê giưa chung. Dung cac hương dẫn sau :
ƒ nhân dang cac class thưc thể băng cach chu y cac thông tin trong
₫ăc ta use-case va trong mô hình lĩnh vưc.
ƒ nhân dang class biên cơ sơ cho mỗi class thưc thể vưa tìm ₫ươc.
ƒ nhân dang class biên trung tâm cho mỗi actor la con ngươi.
ƒ nhân dang class biên trung tâm cho mỗi actor la hê thống ngoai
hay thiết bị I/O.
ƒ nhân dang class ₫iều khiển co trach nhiêm xư ly trong dẫn xuất
use-case.
Tâp hơp cac class phân tích tham gia vao dẫn xuất use-case thanh 1
(hay nhiều) lươc ₫ồ class.
PhÝn tÈch use-case : nhÝn dang cac class phÝn tÈch
Chương 6: Phân tích yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 138
Payment Request UI
Order Configmation
Order Handler
Payment Request
Payment Scheduler
Invoice
Buyer
(f rom Use-Case Model)
ThÈ du vã̀ lươc ₫é̀ class phÝn tÈch cho use-case Pay Invoice
Chương 6: Phân tích yêu cầu hương ₫ối tương
70
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 139
Cần chu y cac ₫iểm sau trong lươc ₫ồ công tac :
ƒ p. tư actor gơi 1 thông bao ₫ến class biên ₫ể kích hoat use-case.
ƒ mỗi class phân tích nên co ít nhất 1 ₫ối tương tham gia vao lươc
₫ồ công tac.
ƒ chưa vôi kết hơp tac vu cu thể cho thông bao.
ƒ cac mối nối trong lươc ₫ồ công tac thương la 'instance' cua mối
quan hê kết hơp giưa cac class tương ưng.
ƒ chưa tâp trung vao thư tư thơi gian cac thông bao.
ƒ Lươc ₫ồ công tac nên xư ly tất ca mối quan hê cua use-case
₫ươc hiên thưc.
ƒ cần bổ sung ₫ăc ta dang văn ban vao lươc ₫ồ công tac, ₫ăc ta
nay nên ₫ươc ₫ể vao 'flow of events cấp phân tích".
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
Chương 6: Phân tích yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 140
Cần chu y cac ₫iểm sau trong lươc ₫ồ công tac :
ƒ cac thông ₫iêp ₫ươc ₫anh số theo kiểu phân cấp.
— 3.4.2 xay ra sau 3.4.1 va ca 2 ₫ươc lồng trong 3.4
— 3.4.3a va 3.4.3b xay ra ₫ồng thơi va ₫ươc lồng trong 3.4
ƒ cu phap tổng quat cua 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)
Lươc ₫é̀ céng tac
Chương 6: Phân tích yêu cầu hương ₫ối tương
71
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 141
Lươc ₫é̀ céng tac
Cac thanh phần cua lươc ₫ồ công tac :
Chương 6: Phân tích yêu cầu hương ₫ối tương
: Buyer
: Payment Scheduler
: Payment Request UI
: Invoice
: Order Confirmation
: Order Handler
: Payment Request
1: Browse Invoice
4: Get
5: Get
6: Schedule InVoice for payment
8: New
2: Browse
9: setStatus(scheduled)
7: Schedule payment
3: Check Invoice
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 142
Muc ₫ích cua viêc phân tích class la :
ƒ nhân dang va duy trì cac nghĩa vu, trach nhiêm cua class phân
tích dưa vao vai tro cua no trong dẫn xuất use-case.
ƒ nhân dang va duy trì cac thuôc tính va cac mối quan hê cua class
phân tích.
ƒ năm băt cac yêu cầu ₫ăc biêt liên quan ₫ến viêc hiên thưc class
phân tích.
PhÝn tÈch class
Chương 6: Phân tích yêu cầu hương ₫ối tương
72
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 143
ƒ tổ hơp cac vai tro ma class ₫ong trong cac dẫn xuất use-case
khac nhau se cho ta 1 số nghĩa vu cua class.
ƒ nghiên cưu cac lươc ₫ồ class va lươc ₫ồ tương tac trong cac 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' cua dẫn xuất
use-case ₫ể tìm thêm cac nghĩa vu cac class.
PhÝn tÈch class : nhÝn dang cac nghĩa vu
Chương 6: Phân tích yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 144
Mỗi nghĩa vu thương cần 1 số thuôc tính. Dung cac 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 dung lai 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 tap, nên tach 1 số thuôc tính phưc
tap ra thanh class riêng.
ƒ thuôc tính cua class thưc thể thương dễ thấy.
ƒ thuôc tính cua 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ư cac field text,...
ƒ thuôc tính cua class biên giao tiếp vơi hê thống ngoai thương
miêu ta cac tính chất cua giao tiếp.
ƒ thuôc tính cua class ₫iều khiển ít khi co.
ƒ ₫ôi khi không cần cac thuôc tính hình thưc.
PhÝn tÈch class : nhÝn dang cac thuéc tÈnh
Chương 6: Phân tích yêu cầu hương ₫ối tương
73
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 145
Cac ₫ối tương tương tac nhau thông qua cac lươc ₫ồ công tac. Cac mối
liên kết nay thương la 'instance' cua mối quan hê kết hơp giưa cac
class. Cac mối liên kết nay cung co thể am chỉ nhu cầu về sư gôp
nhiều ₫ối tương. Mối quan hê gôp nên ₫ươc dung khi cac ₫ối tương
miêu ta :
ƒ cac khai niêm chưa vât ly khai niêm khac (xe chưa tai xế va
khach)
ƒ cac khai niêm ₫ươc xây dưng tư cac khai niêm khac (xe gồm cac
banh xe va ₫ông cơ).
ƒ cac khai niêm tao thanh tâp hơp y niêm nhiều ₫ối tương (gia ₫ình
gồm cha, me va con).
Để rut trích cac hanh vi chung cua nhiều class phân tích, ta co thể dung
class tổng quat hoa, nhưng chỉ nên ơ cấp y niêm.
PhÝn tÈch class : nhÝn dang mé́i quan hã giưa cac class
Chương 6: Phân tích yêu cầu hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 146
Muc ₫ích cua phân tích package la :
ƒ ₫am bao tưng package phân tích ₫ôc lâp vơi cac package khac
nhiều như co thể co.
ƒ ₫am bao package phân tích hoan thanh muc ₫ích cua no la hiên
thưc 1 số class lĩnh vưc hoăc 1 số use-case.
ƒ miêu ta cac phu thuôc sao cho co thể ươc lương anh hương cua
cac thay ₫ổi trong tương lai.
Dung cac hương dẫn sau :
ƒ ₫am bao package chưa cac class ₫ung, cố găng cho tính kết dính
cao băng cach gôp cac class co mối quan hê chưc năng.
ƒ han chế tối ₫a sư phu thuôc giưa cac package, phân phối lai cac
class qua phu thuôc vao package khac.
PhÝn tÈch package
Chương 6: Phân tích yêu cầu hương ₫ối tương
74
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 147
Trương Đai Hoc Bach Khoa Tp. HCM
Khoa Cöng nghï Thöng tin
Chương 7
THIÏT KÏ HƯƠNG ĐÖI TƯƠNG
ƒ Cac artifacts cền tao ra
ƒ Cac workers tham gia
ƒ Qui trònh thiḯt kḯ
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 148
Muc ₫ích cua công viêc thiết kế la :
ƒ ₫at tơi sư hiểu biết sâu săc cac vần ₫ề về cac rang buôc va cac
yêu cầu không chưc năng co liên quan ₫ến ngôn ngư lâp trình, sư
dung lai linh kiên, HĐH, công nghê phân tan, ₫ồng thơi, database,
giao diên, quan ly giao tac.
ƒ tao ra ₫ầu vao cho hoat ₫ông hiên thưc băng cach năm băt cac
hê thống con, cac interface va cac class.
ƒ chia công viêc hiên thưc ra nhiều phần dễ quan ly va xư ly bơi
cac ₫ôi khac nhau (co thể ₫ồng thơi).
ƒ năm băt cac interface chính giưa cac hê thống con.
ƒ co thể hiển thị trưc quan va xem xet bang thiết kế dung cac ky
hiêu chung.
ƒ tao ra mưc trưu tương cua sư hiên thưc hê thống.
Muc ₫Èch cua thiã́t kã́
Chương 7: Thiết kế hương ₫ối tương
75
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 149
Chương 7: Thiết kế hương ₫ối tương
Mô hình thiết kế = hê thống thiết kế :
ƒ cac hê thống con
ƒ cac class thiết kế.
ƒ cac interface cua hê thống con va class.
ƒ cac dẫn xuất use-case cấp thiết kế :
— cac lươc ₫ồ class
— cac lươc ₫ồ tương tac (trình tư, trang thai,...).
— 'flow of events' ơ cấp thiết kế.
— cac yêu cầu cấp hiên thưc.
ƒ ₫ăc ta kiến truc (view of design model)
Mô hình bố trí :
ƒ ₫ăc ta kiến truc (view of deployment model)
Cac artifacts cÝ̀n tao ra trong thiã́t kã́
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 150
Desgin Class
Design
Model
Desgin
System
Use-Case Realization -
Design
Interface
Design
Subsystem
*
*
* * *
*
*
*
1
Chương 7: Thiết kế hương ₫ối tương
Cac artifacts cÝ̀n tao ra trong thiã́t kã́
76
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 151
Class thiết kế la sư trưu tương trưc tiếp cua class hiên thưc :
ƒ dung ngôn ngư lâp trình ₫ể miêu ta class thiết kế.
ƒ thương xac ₫ịnh tầm vưc cua cac thanh phần.
ƒ cac mối quan hê co y nghĩa trưc tiếp tơi hiên thưc : tổng quat hoa
→thưa kế, quan hê gôp, kết hơp thanh 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 luc 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 tai trong mô hình
process thay vì trong mô hình thiết kế.
Đăc ₫iã̉m cua class thiã́t kã́
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 152
Use-Case
Engineer
Component
Engineer
chịu trach nhiêm về chịu trach nhiêm về chịu trach nhiêm về
Desgin
Model
Deployment
Model
Architecture
Description
Use-Case
Realization -
Desgin
Design
class
Design
Subsystem
Interface
Chương 7: Thiết kế hương ₫ối tương
Cac wokers trong hoat ₫éng thiã́t kã́
Architect
77
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 153
Architect
Use-Case
Engineer
Architectural
Design
Design a
Use-Case
Design a
Class
Design a
Subsystem
Chương 7: Thiết kế hương ₫ối tương
Qui trÉnh thiã́t kã́
Component
Engineer
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 154
Muc ₫ích cua thiết kế kiến truc la phat hoa mô hình thiết
kế va mô hình bố trí cung kiến truc cua chung băng
cach nhân dang cac vấn ₫ề sau :
ƒ Cac nut tính toan va cac cấu hình mang cua chung.
ƒ Cac hê thống con va interface cua chung.
ƒ Cac class thiết kế co y nghĩa kiến truc như cac class
chu ₫ông.
ƒ Cac cơ chế thiết kế tổng quat xư ly cac yêu cầu chung
như tính bền vưng, hiêu qua,... (₫ươc năm băt trong cac
class phân tích va cac dẫn xuất use-case ơ cấp phân
tích.
Chương 7: Thiết kế hương ₫ối tương
Thiã́t kã́ kiã́n truc : muc ₫Èch
78
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 155
Chương 7: Thiết kế hương ₫ối tương
Cấu hình mang vât ly se anh hương ₫ến kiến truc phần mềm, gồm cac
khía canh :
ƒ cac nut nao liên quan, kha năng về bô nhơ va công suất tính cua
nut.
ƒ kiểu nối kết va kiểu giao thưc nao giưa cac nut.
ƒ cac tính chất về sư nối kết va giao thưc như băng thông, ₫ô săn
sang, chất lương...
ƒ cần kha năng tính dư thưa, chế ₫ô ₫ề khang lỗi, di cư process,
sao lưu dư liêu,...
Thiã́t kã́ kiã́n truc : nhÝn dang nut va cÝ́u hÉnh mang
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 156
Chương 7: Thiết kế hương ₫ối tương
Chia công viêc thiết kế tư ₫ầu hay khi mô hình thiết kế phat triển thanh
phưc tap cần ₫ươc chia nho. Môt số hê thống con ₫ươc dung lai tư cac
project khac :
ƒ nhân dang cac hê thống con cấp ưng dung
ƒ nhân dang cac hê thống con cấp giưa va cấp hê thống
ƒ ₫ịnh nghĩa sư phu thuôc giưa cac hê thống con.
ƒ nhân dang giao tiếp cua cac hê thống con.
Thiã́t kã́ kiã́n truc : nhÝn dang hã thé́ng con va interface cua chung
79
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 157
Chương 7: Thiết kế hương ₫ối tương
Cần nhân dang cac class thiết kế quan trong về măt kiến truc ₫ể lam
tiền ₫ề cho hoat ₫ông thiết kế, cac class khac se ₫ươc nhân dang trong
viêc thiết kế use-case.
ƒ nhân dang cac class thiết kế tư cac class phân tích tương ưng
ƒ nhân dang cac class chu ₫ông khi chu y yêu cầu ₫ồng thơi trên hê
thống :
— cac yêu cầu về hiêu qua, ₫ô săn sang, throughput cua hê
thống
— sư phân tan cua hê thống trên cac nut.
— cac yêu cầu khac như khơi ₫ông, kết thuc, tranh deadlock,
tranh bao hoa, cấu hình lai cac nut, kha năng nối kết.
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
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 158
Chương 7: Thiết kế hương ₫ối tương
Tư cac yêu cầu chung va ₫ăc biêt ₫a ₫ươc nhân dang trong phần phân
tích (trong cac class phân tích va cac dẫn xuất use-case cấp phân tích),
quyết ₫ịnh cach xư ly chung 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 cac cơ chế thiết kế tổng quat. Cac yêu cầu cần
xư ly thương liên quan ₫ến :
ƒ tính bền vưng.
ƒ sư phân tan & ₫ồng thơi.
ƒ cac tính chất an toan dư liêu.
ƒ ₫ề khang vơi lỗi.
ƒ quan ly giao tac.
Thiã́t kã́ kiã́n truc : nhÝn dang cac cơ chã́ thiã́t kã́ té̉ng quat
80
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 159
Muc ₫ích cua thiết kế use-case la :
ƒ Nhân dang cac class thiết kế va cac hê thống con co
object cần cho viêc thưc hiên 'flow of events-design'
cua use-case.
ƒ phân tan hanh vi cua use-case băng cach cho cac
object thiết kế va hê thống con tương tac nhau.
ƒ ₫ịnh nghĩa yêu cầu trên cac tac vu cua class thiết kế,
hê thống con va interface cua chung.
ƒ năm băt cac yêu cầu cấp hiên thưc cho use-case.
Thiã́t kã́ Use-Case
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 160
Nhân dang cac class thiết kế như sau :
ƒ nghiên cưu cac 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 dang cac class thiết kế
nối vơi cac class phân tích nay.
ƒ nghiên cưu cac 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 dang cac class thiết kế hiên
thưc cac yêu cầu ₫ăc biêt nay.
ƒ gan nghĩa vu cho cac class thiết kế tìm ₫ươc.
ƒ nếu con thiếu 1 vai 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 truc sư va ky sư linh
kiên ₫ể ban bac.
ƒ xây dưng lươc ₫ồ class chưa cac class thiết kế tìm ₫ươc.
Thiã́t kã́ Use-Case : nhÝn dang cac class thiã́t kã́
Chương 7: Thiết kế hương ₫ối tương
81
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 161
Dung lươc ₫ồ trình tư :
ƒ lươc ₫ồ trình tư chưa cac phần tư actor, ₫ối tương thiết kế va
cac t.bao giưa chung.
ƒ nếu use-case co nhiều luồng ₫iều khiển khac nhau, nên tao
lươc ₫ồ trình tư cho tưng luồng.
ƒ nên chuyển lươc ₫ồ công tac ơ cấp phân tích thanh lươc ₫ồ
trình tư ban ₫ầu, tư ₫o phat triển thêm chi tiết.
ƒ dung 'flow of events', duyêt qua cac bươc trong no ₫ể quyết
₫ịnh cac tương tac nao cần thiết giưa cac ₫ố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ã́
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 162
Thiã́t kã́ Use-Case : miãu ta cac tương tac giưa cac object thiã́t kã́
Chương 7: Thiết kế hương ₫ối tương
Nên chu y cac ghi nhân sau trong viêc xây dưng lươc ₫ồ trình tư :
ƒ nên tâp trung vao trình tư trong lươc ₫ồ.
ƒ actor gơi thông bao ₫ế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 vao
lươc ₫ồ trình tư.
ƒ cac message ₫ươc gơi giưa cac ₫ương ₫ơi sống ₫ối tương,
co thể co tên tam va se trơ thanh tên tac vu tương ưng.
ƒ dung 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ê cua use-case
cần hiên thưc.
82
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 163
: People
: LoginForm
: Database
1: login(uname,pswd)
1.2 [succ = true]: welcome
1.1: succ := Verify(uname,pswd)
Lươc ₫é̀ céng tac
Cac thanh phần cua lươc ₫ồ công tac : (thí du lươc ₫ồ công
tac cho use-case Login cua hê thống ₫ăng ky môn hoc hê tín
chỉ thông qua Web.
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 164
: Database
: People
: LoginForm
1: submit(uname, psswd)
1.1: verify(uname, psswd)
1.2: welcome
Lươc ₫é̀ trÉnh tư
Cac thanh phần cua lươc ₫ồ trình tư : (thí du lươc ₫ồ trình tư
cho use-case Login cua hê thống ₫ăng ky môn hoc hê tín chỉ
thông qua Web.
Chương 7: Thiết kế hương ₫ối tương
83
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 165
Composed
entry/ assign ID
exit/ fill date
on char/ handle character
compose command
Stored
entry/ save into folder
Read
entry/ convert to rich text
unhightlight
focus
hightlight
read command / recover( id )
logout
save command
re-fwd cmd / quote / append subject
Sending
do/ send( repc )
send command[ recipents != null ] / parse
sending done
Lươc ₫é̀ trang thai
Cac thanh phần cua lươc ₫ồ trang thai : (thí du lươc ₫ồ trang
thai cho use-case Send/Read e-mail).
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 166
Show input for username
and password
Reject
[ psswd invalid ]
Welcome
[ psswd valid ]
Verify
Database LoginForm
Lươc ₫é̀ hoat ₫éng
Cac thanh phần cua
lươc ₫ồ hoat ₫ông :
(thí du lươc ₫ồ hoat
₫ông cho use-case
Login cua hê thống
₫ăng ky môn hoc hê
tín chỉ thông qua
Web.
Chương 7: Thiết kế hương ₫ối tương
84
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 167
Muc ₫ích cua viêc thiết kế class la tao ra class thiết kế hoan
thanh vai tro cua no trong dẫn xuất use-case va cac yêu cầu phu.
Bao gồm viêc duy trì class thiết kế va cac khía canh sau cua no :
ƒ cac tac vu cua class.
ƒ cac thuôc tính cua class.
ƒ cac mối quan hê ma class tham gia.
ƒ cac method cua class (hiên thưc tac vu tương ưng).
ƒ cac trang thai cua ₫ối tương.
ƒ cac phu thuôc tơi bất ky cơ chế thiết kế tổng quat nao.
ƒ cac yêu cầu co liên quan ₫ến hiên thưc cua class.
ƒ sư hiên thưc ₫ung cua bất ky interface ma class phai cung
cấp.
Thiã́t kã́ class
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 168
Bươc ₫ầu ta phat hoa cac class thiết kế tư cac interface va class phân
tích : 1 interface co 1 class thiết kế, con class phân tích thì :
ƒ thiết kế class biên phu thuôc vao công nghê tao interface : form,
activeX control... Để y dung cac prototype giao diên vơi user trong
bươc trươc.
ƒ thiết kế class thưc thể thương phu thuôc vao công nghê database.
Viêc anh 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 cac nhu cầu sau :
— vần ₫ề phân tan : cần nhiều class thiết kế trên cac nut khac nhau
₫ể hiên thưc 1 class ₫iều khiển.
— vấn ₫ề hiêu qua : nên dung 1 class thiết kế cho 1 class ₫iều khiển
— vấn ₫ề giao tac: class thiết kế cần tích hơp công nghê quan ly
giao tac.
Thiã́t kã́ class : Phat hoa class thiã́t kã́
Chương 7: Thiết kế hương ₫ối tương
85
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 169
Nhân dang cac tac vu ma class thiết kế cần cung cấp va tầm vưc
cua chung (dung cu phap ngôn ngư lâp trình). Cac ₫ầu vao cua
bươc nay la :
ƒ cac trach nhiêm cua bất ky class phân tích ma dẫn tơi class
thiết kế.1 trach nhiêm tương ưng 1 hay nhiều tac vu, nhưng
ơ ₫ây mơi phat hoa thông số hình thưc cac tham số.
ƒ cac yêu cầu ₫ăc biêt cua bất ky class phân tích ma dẫn tơi
class thiết kế.
ƒ cac interface ma class thiết kế phai 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 tac vu
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 170
Tac vu thương ₫oi hoi thuôc tính, cần dưa vao cac hương dẫn sau
:
ƒ chu y thuôc tính cua bất ky class phân tích ma dẫn tơi class
thiết kế.1 thuôc tính nay am chỉ 1 hay nhiều thuôc tính cua
class thiết kế.
ƒ han chế dung kiểu cua ngôn ngư lâp trình cho thuôc tính.
ƒ cố găng dung kiểu ₫a co.
ƒ nếu class thiết kế qua phưc tap, 1 vai thuôc tính cua no co
thể tach ra thanh cac class riêng.
ƒ nếu co qua nhiều thuôc tính hay thuôc tính qua phưc tap,
nên dung lươc ₫ồ class riêng ₫ể miêu ta thuôc tính.
Thiã́t kã́ class : NhÝn dang cac thuéc tÈnh
Chương 7: Thiết kế hương ₫ối tương
86
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 171
Cần theo cac hương dẫn sau :
ƒ chu y cac mối quan hê kết hơp & gôp cua 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 cua vai
tro, class kết hơp, kết hơp n-ary.
ƒ tinh chế hương cua mối quan hê kết hơp tư lươc ₫ồ tương
tac.
Nhân dang mối quan hê tổng quat hoa dung cu phap ngôn ngư
lâp trình, nếu ngôn ngư lâp trình không hỗ trơ, dung 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
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 172
Method ₫ăc ta cach tac vu ₫ươc hiên thưc. Miêu ta cac method
dung ngôn ngư tư nhiên hay ngôn ngư pseudocode. Nếu cung 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 ₫oan thiết kế.
Môt vai ₫ối tương thiết kế ₫ươc ₫iều khiển bơi trang thai : trang
thai xac ₫ịnh hanh vi cua no khi nhân 1 thông bao tư ngoai →
miêu ta trang thai dung lươc ₫ồ trang thai.
Xư ly cac yêu cầu ₫ăc biêt chưa ₫ươc chu y ơ cac bươc trươc.
Thiã́t kã́ class : NhÝn dang cac mé́i quan hã kã́t hơp & gép
Chương 7: Thiết kế hương ₫ối tương
87
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 173
Muc ₫ích cua viêc thiết kế hê thống con la :
ƒ ₫am bao hê thống con la ₫ôc lâp vơi nhau nhiều như co thể
co.
ƒ ₫am bao hê thống con la ₫ôc lâp vơi interface cua no nhiều
như co thể co.
ƒ ₫am bao hê thống con cung cấp ₫ươc interfcae ₫ung.
ƒ ₫am bao hê thống con hoan thanh muc ₫ích, tao hiên thưc
₫ung cho cac tac vu.
Thiã́t kã́ hã thé́ng con (Subsystem)
Chương 7: Thiết kế hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 174
Gồm cac công viêc sau :
ƒ duy trì sư phu thuôc giưa cac hê thống con (nên thông qua
interface), tối thiểu hoa sư phu thuôc băng cach bố trí lai
cac class qua phu thuôc vao hê thống con khac.
ƒ duy trì interface cua cac hê thống con.
ƒ duy trì nôi dung cua cac hê thống con.
Thiã́t kã́ hã thé́ng con (Subsystem)
Chương 7: Thiết kế hương ₫ối tương
88
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 175
Trương Đai Hoc Bach Khoa Tp. HCM
Khoa Cöng nghï Thöng tin
Chương 8
HIÏN THƯC HƯƠNG ĐÖI TƯƠNG
ƒ Cac artifacts cền tao ra
ƒ Cac workers tham gia
ƒ Qui trònh hiïn thưc
Chương 8: Hiên thưc hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 176
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Muc ₫ích cua hiên thưc la :
ƒ kế hoach cac 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 cac bươc nho va dễ quan ly).
ƒ phân tan hê thống băng cach anh xa cac thanh phần kha thi
trên cac nut trong mô hình bố trí (dưa chu yếu vao cac class
chu ₫ông).
ƒ hiên thưc cac class va hê thống con thiết kế.
ƒ kiểm tra ₫ơn vị trên cac thanh phần, tích hơp chung vao 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.
Muc ₫Èch cua giai ₫oan hiãn thưc
89
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 177
Mô hình hiên thưc = hê thống hiên thưc :
ƒ cac hê thống con hiên thưc
ƒ cac component (executable, file, library, table, document,...)
ƒ cac interface cua hê thống con va component.
ƒ kế hoach tích hơp cac "build"
ƒ ₫ăc ta kiến truc (view of Implementation model)
Cac artifacts cÝ̀n tao ra trong hiãn thưc
Chương 8: Hiên thưc hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 178
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Stub la 1 thanh phần ma phần hiên thưc chỉ ơ mưc ₫ô "template"
₫ể phat triển hoăc kiểm tra thanh phần khac phu thuôc va stub.
Stub co thể tối thiểu số thanh phần mơi cần hiên thưc cho mỗi
version cua hê thống. co phần hiên thưc, nhơ ₫o lam ₫ơn gian
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 tao
ra :
ƒ package trong java.
ƒ project trong VB.
ƒ thư muc cac file trong C++,...
Stub, hã thé́ng con
90
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 179
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Phần mềm ₫ươc hiên thưc theo tưng bươc nho dễ quan ly, mỗi
bươc ta xây dưng 1 build. Build la 1 version kha thi cua hê thống.
Lơi ích cua cach tiếp cân nay la :
ƒ version kha thi co thể tao ra kha sơm thay vì phai 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 cac thanh viên nôi bô hay cac ngươi liên
quan.
ƒ dễ dang phat 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 vao.
ƒ kiểm tra tích hơp thương nhanh hơn la kiểm tra toan bô hê
thống.
Build
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 180
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Kế hoach xây dưng build tích hơp miêu ta trình tư cac 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 vong ₫ươc hiên thưc trong build, ₫ây la danh
sach cac use-case va/hoăc cac kịch ban cua chung. Danh
sach nay cung chỉ ra cac yêu cầu phu kem theo.
ƒ Cac phần nao cua mô hình hiên thưc bị tac ₫ông trong build,
₫ây la danh sach cac hê thống con va cac thanh phần ₫ươc
₫oi hoi ₫ể hiên thưc chưc năng ky vong cua build.
Kã́ hoach xÝy dưng build tÈch hơp
91
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 181
Implementation
Model
Interface
Implementation
System
Implementation
Subsystem
Component
Cac artifacts cÝ̀n tao ra trong thiã́t kã́
1 *
*
*
*
* *
Chương 8: Hiên thưc hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 182
System
Integrator
Component
Engineer
chịu trach nhiêm về chịu trach nhiêm về chịu trach nhiêm về
Imple.
Model
Deployment
Model
Architecture
Description
Integration
Build Plan
Component Imple.
Subsystem
Interface
Cac workers trong hoat ₫éng hiãn thưc
Architect
Chương 8: Hiên thưc hương ₫ối tương
92
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 183
Chương 8: Hiên thưc hương ₫ối tương
Architect
System
Integrator
Architectural
Implementation
Integrate
System
Implement
a Subsystem
Perform
Unit Test
Qui trÉnh hiãn thưc
Component
Engineer
Implement
a Class
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 184
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Muc ₫ích cua hiên thưc kiến truc la phat hoa mô hình hiên thưc
va kiến truc cua no băng cach :
ƒ nhân dang cac thanh phần co y nghĩa kiến truc như cac
thanh phần kha thi (exe).
ƒ anh xa cac thanh phần tơi cac nut trong cấu hình mang liên
quan : 1 class chu ₫ông ₫ươc hiên thưc trong 1 thanh phần
kha thi va trơ thanh 1 process chay ơ 1 nut cu thể.
Hiãn thưc kiã́n truc
93
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 185
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Muc ₫ích cua tích hơp hê thống la :
ƒ tao 1 kế hoach tích hơp cac build miêu ta build nao trong
tưng bươc lăp va cac 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 vai tiêu chuẩn cho 1 build kế tiếp la :
ƒ build nên thêm 1 số chưc năng vao build trươc băng cach
hiên thưc hoan chỉnh use-case.
ƒ build không nên bao gồm qua nhiều thanh 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
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 186
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Ưng vơi mỗi use-case cần hiên thưc, lam cac 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 dang cac hê thống con va class thiết kế trong dẫn
xuất use-case cấp thiết kế.
ƒ nhân dang cac hê thống con hiên thưc va cac thanh phần
dẫn ngươc về hê thống con va class thiết kế.
ƒ chu y anh hương cua viêc hiên thưc cac yêu cầu lên cac hê
thống con va cac thanh phần nay, ₫anh gia anh hương ₫ể
quyết ₫ịnh nên hiên thưc use-case trong build nay hay delay
cho build sau.
TÈch hơp hã thé́ng (tt)
94
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 187
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Nếu build ₫ươc kế hoach cẩn thân thì viêc tích hơp no rất ₫ơn
gian :
ƒ chon version ₫ung cua cac hê thống hiên thưc va cac thanh
phần rồi dịch, liên kết chung ₫ể tao ra build.
ƒ chu y mối phu thuôc dang bottom-up khi dịch cac thanh
phần va hê thống con.
ƒ build vưa ₫ươc tao 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 cua 1
bươc lăp.
TÈch hơp 1 build
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 188
Chương 8: Hiên thưc hương ₫ối tương Chương 8: Hiên thưc hương ₫ối tương
Muc ₫ích cua hiên thưc hê thống con la ₫am bao no hoan thanh
vai tro cua no trong mỗi build :
ƒ mỗi class trong hê thống con thiết kế cần cho build hiên tai
nên ₫ươc hiên thưc bơi thanh phần trong hê thống con hiên
thưc tương ưng (va ₫ê qui).
ƒ mỗi interface cua hê thống con thiết kế cần cho build hiên
tai cung nên ₫ươc cung cấp bơi hê thống con hiên thưc
tương ưng (va ₫ê qui)..
Hiãn thưc hã thé́ng con
95
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 189
Chương 8: Hiên thưc hương ₫ối tương
Muc ₫ích cua hiên thưc class la hiên thưc tưng class thiết kế
thanh file thanh phân tương ưng, gồm cac công viêc sau :
ƒ Phat hoa 1 file thanh phần chưa source code cua class. 1
file co thể chưa nhiều class, nhưng theo qui ₫ịnh cua 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).
ƒ tao source code tư class thiết kế va cac mối quan hê ma
class tham gia.
ƒ hiên thưc cac tac vu cua class thiết kế dươi dang cac
method.
ƒ ₫am bao thanh phần cung cấp cung interface như class thiết
kế.
Hiãn thưc class
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 190
Chương 8: Hiên thưc hương ₫ối tương
Kha năng tai sư dung phu thuôc vao cac 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 rang.
ƒ giư cho mỗi method ₫u nho : nếu chiếm nhiều trang thì tach
ra nhiều method.
ƒ giư cho cac method thống nhất : nên dung cung danh sach
tham số cho cac method co y nghĩa sư dung giống nhau.
ƒ tach biêt method chiến lươc va phương thưc thưc thi.
ƒ mơ rông method cang nhiều cang tốt : khai quat hoa kiểu
tham số, số tham số,...
ƒ tranh dung dư liêu toan cuc.
Kha năng tai sư dung
96
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 191
Chương 8: Hiên thưc hương ₫ối tương
Kha năng mơ rông phu thuôc vao cac yếu tố sau :
ƒ bao ₫ong lơp con : ngay ca lơp bao ngoai cung không thấy
bên trong.
ƒ che dấu cấu truc dư liêu : không xuất ra bên ngoai.
ƒ tranh ₫a liên kết giư nhiều ₫ối tương : tham khao cho phep
thưc hiên chưc năng trên ₫ối tương tương ưng, tranh dung
no ₫ể tiếp tuc truy xuất gian tiếp ₫ến cac ₫ối tương khac.
ƒ tranh dung lênh switch trên kiểu ₫ối tương : ban thân ₫ối
tương tư hiểu mình la ai.
ƒ phân biêt tac vu public va private.
Kha năng mơ réng
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 192
Chương 8: Hiên thưc hương ₫ối tương
La xây dưng 1 phần mềm phưc tap cần nhiều nhom tham gia
₫ồng thơi, giao tiếp giưa cac thanh viên la rất quan trong :
ƒ Không băt ₫ầu lâp trình nếu chưa hiểu ro.
ƒ giư cho cac method dễ hiểu : ₫ô kết ₫ịnh cao va nho.
ƒ tao cho method dễ ₫oc : tên biến va kiểu co y nghĩa ro rang.
ƒ sư dung cung tên cho cac giai ₫oan khac nhau : phân tích,
thiết kế, hiên thưc...
ƒ lưa chon tên ky lương : thể hiên ₫ung vai tro, nghĩa vu.
ƒ sư dung cac hương dẫn va qui tăc lâp trình : style...
ƒ lâp tai liêu cho cac class va cac method : muc ₫ích, chưc
năng...
ƒ xuất ban ₫ăc ta hương dẫn cach sư dung class.
LÝp trÉnh ưng dung lơn
97
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 193
Muc ₫ích la kiểm tra chưc năng cua tưng ₫ơn vị ₫ươc hiên thưc 1
cach riêng le. Co 2 loai kiểm tra tưng ₫ơn vị :
ƒ kiểm tra ₫ăc ta (black-box testing) : kiểm tra hanh vi cua ₫ơn
vị như ₫ươc thấy tư ngoai.
ƒ kiểm tra cấu truc (white-box testing) : kiểm tra sư hiên thưc
bên trong ₫ơn vị.
Cung con 1 số loai kiểm tra ₫ơn vị khac như : kiểm tra tính hiêu
qua, kiểm tra viêc dung bô nhơ, kiểm tra tai, 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 ₫oan kiểm tra.
Thưc hiãn kiã̉m tra ₫ơn vị (Unit test)
Chương 8: Hiên thưc hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 194
Muc ₫ích kiểm tra ₫ăc ta (black-box testing) la kiểm tra hanh vi
cua ₫ơn vị như ₫ươc thấy tư ngoai :
ƒ kiểm tra xem component cho kết qua gì ưng vơi tưng dư liêu
nhâp va trang thai nao ₫o.
ƒ Số lương tổ hơp bô ba {gia trị dư liêu nhâp, trang thai 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 nay la không kha thi.
ƒ ta xac ₫ịnh cac lơp tương ₫ương cua "test case" va chỉ kiểm
tra trên cac lơp tương ₫ương nay. Lơp tương ₫ương la tất ca
cac "test case" lam ₫ơn vị cho hầu như cung hiêu ưng.
Kiã̉m tra ₫ăc ta
Chương 8: Hiên thưc hương ₫ối tương
98
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 195
Muc ₫ích cua kiểm tra cấu truc (white-box testing) la kiểm tra sư
hiên thưc bên trong ₫ơn vị :
ƒ ₫am bao moi hang lênh ₫ều ₫ươc kiểm tra (ít nhất la chay 1
lần).
ƒ kiểm tra moi path cần quan tâm : cac path chay thương
nhất, cac path dễ gây sai, cac path ít ₫ươc biết về giai thuât
nhất, cac path co rui ro cao.
Kiã̉m tra cÝ́u truc
Chương 8: Hiên thưc hương ₫ối tương
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 196
Trương Đai Hoc Bach Khoa Tp. HCM
Khoa Cöng nghï Thöng tin
Chương 9
KIÏM THƯ
ƒ Cac artifacts cền tao ra
ƒ Cac workers tham gia
ƒ Qui trònh kiï̉m thư
Chương 9: Kiểm thư
99
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 197
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 : cach thưc thưc hiên test case
ƒ Test component : tư ₫ông hoa 1 hay nhiều thu tuc kiêển thư
ƒ Plan Test : chiến lươc, tai nguyên, lịch
ƒ Defect : lỗi
ƒ Evaluate Test : phu cac testcase, cac code, trang thai lỗi
Cac artifacts cÝ̀n tao ra trong kiã̉m thư
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 198
Test Model Test System
1
*
*
*
Test
Component
Test
Procedure
Test Case
Cac artifacts trong kiã̉m thư
Chương 9 : Kiểm thư
100
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 199
Test Model Test case Test
Procedure
Test
Evaluation
Test
Component
Test
Engineer
Component
Engineer
Integration
Tester
System
Tester
Test Plan
Test
defect
chịu trach nhiêm về
chịu trach nhiêm về
chịu trach nhiêm về
Cac workers trong kiã̉m thư
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 200
Integration tester
System
Tester
Plan test
Qui trÉnh kiã̉m thư
Component
Engineer
Test Engineer
Evaluate test
Perform Integration
Test
Perform
System Test
Implement
Test
Design test
Chương 9 : Kiểm thư
101
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 201
Muc ₫ích la kế hoach hoa cac nổ lưc kiểm thư cho 1 bươc lăp
băng cach :
ƒ miêu ta chiến lươc kiểm thư : thưc hiên kiểu kiểm thư nao,
thưc hiên như thế nao, khi nao thư va ₫anh gia kết qua kiểm
thư như thế nao.
ƒ ươc lương cac yêu cầu cua nổ lưc kiểm thư, như cac tai
nguyên về hê thống hay tai nguyên về ngươi.
ƒ lăp lịch cho nổ lưc kiểm thư.
Ky sư kiểm thư dung chu yếu mô hình use-case va cac yêu cầu
phu, cung co thể dung thêm mô hình thiết kế.
Kã́ hoach viãc kiã̉m thư
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 202
Muc ₫ích la :
ƒ nhân dang va ₫ăc ta cac test case cho mỗi build.
ƒ nhân dang va cấu truc cac thu tuc kiểm thư ₫ể xac ₫ịnh
cach thưc hiên cac test case.
Cu thể :
ƒ thiết kế cac test case tích hơp.
ƒ thiết kế cac test case hê thống.
ƒ thiết kế cac test case "regression".
ƒ nhân dang va cấu truc cac thu tuc kiểm thư.
Thiã́t kã́ cac test case
Chương 9 : Kiểm thư
102
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 203
Thiết kế cac test case tích hơp :
ƒ test case tích hơp ₫ể kiểm tra cac thanh phần ₫ươc hiên
thưc trong build tương tac vơi nhau, thương dưa vao dẫn
xuất use-case ơ cấp thiết kế, chu yếu la cac lươc ₫ồ tương
tac va trình tư.
ƒ ₫ể giam nhe nổ lưc thiết kế test case, ky sư kiểm thư cố
găng tìm ra cac 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 ban riêng trong dẫn
xuất use-case.
ƒ sau khi kiểm thư, ky sư kiểm thư se so sanh cac tương tac
thưc sư giưa cac ₫ối tương vơi sơ ₫ồ tương tac trong thiết kế,
nếu giống thì Ok, nếu khac thì co lỗi.
Thiã́t kã́ cac test case tÈch hơp
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 204
Cac test case hê thống ₫ươc dung ₫ể kiểm tra xem cac chưc
năng hê thống co hoat ₫ông tốt ơ mưc tổng thể ? Mỗi test case
kiểm thư cac tổ hơp use-case hoat ₫ông dươi nhưng ₫iều kiên
khac nhau như cấu hình phần cưng, mưc tai, số actor, kích thươc
database.
Khi phat triển cac test case hê thống nên ₫ể y ₫ô ưu tiên cua cac
tổ hơp test case ma :
ƒ ₫ươc ₫oi hoi ₫ể hoat ₫ông song song.
ƒ co thể ₫ươc thưc hiên song song.
ƒ co anh hương vơi nhau nếu ₫ươc thưc hiên song song.
ƒ liên quan tơi nhiều process.
ƒ thương dung tai nguyên hê thống theo 1 cach phưc tap va
không thể tiên ₫oan.
Thiã́t kã́ cac test case hã thé́ng
Chương 9 : Kiểm thư
103
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 205
ƒ dưa vao tưng test case va ₫ề nghị thu tuc kiểm thư cho tưng
test case.
ƒ cố găng dung lai cac thu tuc kiểm thư ₫a co nhiều như co
thể (co thể co thay ₫ổi nho).
ƒ 1 thu tuc kiểm thư co thể tac ₫ông trên nhiều test case va 1
test case co thể co nhiều thu tuc kiểm thư.
Thiã́t kã́ cac thu tuc kiã̉m thư
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 206
Muc ₫ich la tư ₫ông hoa cac thu tuc kiểm thư băng cach tao cac
thanh phần kiểm thư (nếu co thể). Dưa vao cac thu tuc kiểm thư
ta tao cac thanh phần kiểm thư theo 2 công nghê :
ƒ dung tool tư ₫ông kiểm thư.
ƒ viết tương minh thanh phần kiểm thư.
Cac thanh phần kiểm thư thương nhân rất nhiều dư liêu nhâp vao
tao ra nhiều dư liêu xuất, do ₫o cần thiết phai hiển thị trưc quan
₫ươc cac dư liêu nay ₫ể dễ theo doi (dung bang tính hay
database).
Thưc hiãn kiã̉m thư
Chương 9 : Kiểm thư
104
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 207
Thưc hiên cac test case cua 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ư cac test case hay băng cac thanh
phần kiểm lỗi tư ₫ông.
ƒ So sanh kết qua co ₫ươc vơi kết qua ky vong.
ƒ thông bao cac lỗi tơi ky sư linh kiên liên quan.
ƒ thông bao cac lỗi tơi ky sư thiết kế test case ₫ể ₫anh gia kết
qua kiểm thư tổng thể.
Thưc hiãn kiã̉m thư tÈch hơp
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 208
ƒ muc ₫ích kiểm thư hê thống la thưc hiên cac test case ₫ươc
₫oi hoi cho mỗi bươc lăp va năm băt cac 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 thoa man cac muc tiêu chất kương tích
hơp ( khoang 95%).
ƒ qui trình kiểm thư hê thống tương tư như kiểm thư tích hơp.
Cac công viêc kiểm tra hê thống :
ƒ Kiểm tra tính phuc hồi sau lỗi (Recovery testing)
ƒ Kiểm tra tính bao 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).
Thưc hiãn kiã̉m thư hã thé́ng
Chương 9 : Kiểm thư
105
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 209
Ky sư kiểm thư quan tâm 2 thươc ₫o chính :
ƒ mưc ₫ô hoan thanh kiểm thư.
ƒ ₫ô tin cây : xu hương lỗi phat hiên so vơi xư hương test case
thanh công.
Dưa trên xu hương lỗi, ky sư kiểm thư co thể ₫ề nghị cac công viêc sau
:
ƒ thưc hiên thêm kiểm lỗi ₫ể xac ₫ịnh thêm lỗi.
ƒ nơi long tiêu chuẩn kiểm lỗi nếu muc tiêu chất lương qua cao so
vơi bươc lăp hiên hanh.
ƒ Tach cac bô phân co ve ₫at ₫ô tin cây, con cac bô phân chưa ₫at
phai ₫ươc xem xet va kiểm thư lai.
Cuối cung lâp tai liêu về mưc ₫ô hoan thanh kiểm thư, ₫ô tin cây, cac
công viêc ₫ề nghị (ta goi la ₫ăc ta ₫anh gia kiểm thư).
Đanh gia viãc kiã̉m thư
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 210
‰ 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
Tổng quát về hoạt ₫ộng debug ứng dụng
Chương 9 : Kiểm thư
106
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 211
Tổng quát về hoạt ₫ộng debug ứng dụng
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]
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 212
Tổng quát về hoạt ₫ộng debug ứng dụng
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ờ
người dùng ra lệnh
2. Người dùng ra lệnh nạp
vào tài khoản A số tiền
700USD →xử lý :
21a Đọc tài khoản A vào
bộ nhớ,
22a Tăng giá trị tài
khoản trong bộ nhớ
lên 700USD.
23a Ghi lại giá trị mới.
3. Quay về bước 1
1. hiển thị giao diện & chờ
người dùng ra lệnh
2. Người dùng ra lệnh rút tiền
từ tài khoản A 500USD →
xử lý :
21b Đọc tài khoản A vào
bộ nhớ,
22b Giảm giá trị tài
khoản trong bộ nhớ
₫i 500USD.
23b Ghi lại giá trị mới.
3. Quay về bước 1
Tài khoản
A
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).
Chương 9 : Kiểm thư
107
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 213
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).
Tổng quát về tiện ích debug tích hợp trong VC++
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 214
Cửa sổ Variable
Cửa sổ Watch
Cửa sổ Debug
Cửa sổ Registers
Cửa sổ Memory
Cửa sổ CallStack
108
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 215
Để 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à hiệu chỉnh biến dữ liệu
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 216
Để 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).
Các thao tác ₫ể xem vị trí thi hành hiện tại
Chương 9 : Kiểm thư
109
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 217
Để 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 thiết lập ₫iều kiện dừng
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 218
Để 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).
Các lệnh ₫iều khiển chạy tiếp ứng dụng
Chương 9 : Kiểm thư
110
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 219
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ả.
Các lệnh ₫iều khiển khác
Chương 9 : Kiểm thư
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 220
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
Chương 10 : Các mẫu cấu trúc
111
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 221
‰ 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
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 222
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…
Giới thiệu (tt)
Chương 10 : Các mẫu cấu trúc
112
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 223
‰ 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.
Giới thiệu (tt)
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 224
‰ 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…
Vai trò của design pattern
Chương 10 : Các mẫu cấu trúc
113
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 225
‰ 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 software patterns
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 226
‰ 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.
Phân loại Object Oriented Design Patterns
Chương 10 : Các mẫu cấu trúc
114
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 227
‰ 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.
Khả năng ứng dụng design patterns
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 228
‰ 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.
Cấu trúc design pattern sẽ trình bày
Chương 10 : Các mẫu cấu trúc
115
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 229
‰ 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.
Structural Patterns
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 230
‰ 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.
Adapter
Chương 10 : Các mẫu cấu trúc
116
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 231
Thí dụ về mẫu Adapter dùng object
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 232
Sơ ₫ồ cấu trúc của mẫu Adapter dùng class
Chương 10 : Các mẫu cấu trúc
‰ 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.
117
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 233
Sơ ₫ồ cấu trúc của mẫu Adapter dùng object
Chương 10 : Các mẫu cấu trúc
‰ 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.
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 234
‰ 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.
Các phần tử tham gia
Chương 10 : Các mẫu cấu trúc
118
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 235
‰ 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.
Các ngữ cảnh nên dùng mẫu Adapter
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 236
‰ 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ự...
Composite
Chương 10 : Các mẫu cấu trúc
119
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 237
Thí dụ về mẫu Composite
Chương 10 : Các mẫu cấu trúc
Graphic
Draw()
Add(Graphic)
Remove(Graphic)
GetChild(int)
for all g in graphics
g.Draw()
Line
Draw()
Text
Draw()
Rectangle
Draw()
Picture
Draw()
Add(Graphic)
Remove(Graphic)
GetChild(int)
add g to list of graphics
graphics
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 238
Sơ ₫ồ cấu trúc của mẫu Composite
Chương 10 : Các mẫu cấu trúc
120
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 239
‰ 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 phần tử tham gia
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 240
‰ 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…
Các ngữ cảnh nên dùng mẫu Composite
Chương 10 : Các mẫu cấu trúc
121
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 241
‰ 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.
Proxy
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 242
‰ 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…
Phân loại Proxy
Chương 10 : Các mẫu cấu trúc
122
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 243
Thí dụ về mẫu Proxy
Chương 10 : Các mẫu cấu trúc
Image
Draw()
GetExtent()
Store()
Load()
imageImp
extent
if (image==0)
image = LoadImage(filename);
else image->Draw();
ImageProxy
Draw()
GetExtent()
Store()
Load()
filename
extent
image
Graphic
Draw()
GetExtent()
Store()
Load()
DocumentEditor
if (image==0)
return extent;
else return image->GetExtent();
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 244
Sơ ₫ồ cấu trúc của mẫu Proxy
Chương 10 : Các mẫu cấu trúc
RealSubject
Request()
...
...
// prolog code
realSubject->Request();
// epilog code
Proxy
Request()
...
...
realSubject
Subject
Request()
...
Client
123
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 245
‰ 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.
Các phần tử tham gia
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 246
‰ 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ơ ₫ồ:
Các phần tử tham gia
Chương 10 : Các mẫu cấu trúc
124
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 247
‰ 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
‰ …
Các ngữ cảnh nên dùng mẫu Proxy
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 248
‰ Mục tiêu : thêm ₫ộng trách nhiệm cho ₫ối tượng.
‰ Nhu cầu áp dụ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...
Mẫu Decorator
Chương 10 : Các mẫu cấu trúc
aBorderDecorator
component
aScrollDecorator
component
aTextView
component
125
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 249
Decorator
Chương 10 : Các mẫu cấu trúc
ScrollDecorator
Draw()
ScrollTo()
scrollPosition
BorderDecorator
Draw()
DrawBorder()
borderWidth
Decorator
Draw()
VisualComponent
Draw()
TextView
Draw() component->Draw();
Decorator::Draw();
DrawBorder();
component
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 250
Sơ ₫ồ cấu trúc của mẫu Decorator
Chương 10 : Các mẫu cấu trúc
ConcreteDecoratorA
Operation()
addedState
Decorator
Operation()
Component
Operation()
ConcreteComponent
Operation() component->Operation();
Decorator::Operation();
AddedBehavior();
component
ConcreteDecoratorB
Operation()
AddedBehavior()
addedState
126
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 251
‰ 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 phần tử tham gia
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 252
‰ 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).
Các ngữ cảnh nên dùng mẫu Decorator
Chương 10 : Các mẫu cấu trúc
127
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 253
‰ 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.
‰ Nhu cầu áp dụng :
ƒ 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.
Facade
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 254
Thí dụ về cấu trúc Facade
Chương 10 : Các mẫu cấu trúc
Stream
BytecodeStream
CodeGenerator
St ack Machi neCodeGe
ner at or
RI SCCodeGene
r at or
Vari abl e No
de
Expr essi onN
ode
St at e me nt N
ode
Progr a mN
ode
Progr a mNode
Buf f er
Sy mb
ol
Toke
n
Parser
Scann
er
Compiler
Compile()
128
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 255
Sơ ₫ồ cấu trúc của mẫu Facade
Chương 10 : Các mẫu cấu trúc
Facade
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 256
‰ 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.
Các phần tử tham gia
Chương 10 : Các mẫu cấu trúc
129
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 257
‰ 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.
Các ngữ cảnh nên dùng mẫu Facade
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 258
‰ 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ỏ.
‰ Nhu cầu áp dụng :
ƒ 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
₫ó.
Mẫu Flyweight
Chương 10 : Các mẫu cấu trúc
130
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 259
Thí dụ về mẫu Flyweight
Chương 10 : Các mẫu cấu trúc
Character
Draw(Context)
Intersects(Point,Context
)
char c
Glyph
Draw(Context)
Intersects(Point,Context)
Row
Draw(Context)
Intersects(Point,Contex
t)
Column
Draw(Context)
Intersects(Point,Contex
t)
children
children
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 260
Sơ ₫ồ cấu trúc của mẫu Flyweight
Chương 10 : Các mẫu cấu trúc
ConcreteFlyweight
Operation(extrinsicState
)
intrinsicState
Flyweight
Operation(extrinsicState)
FlyweightFactory
GetFlyweight(key)
UnsharedConcreteFlyweight
Operation(extrinsicState)
allState
Client
if (flyweight(key) exists
return existing flyweight
else {
create new flyweight;
add it to pool of flyweights;
return the new flyweight;
}
131
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 261
‰ 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 phần tử tham gia
Chương 10 : Các mẫu cấu trúc
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 262
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.
Các ngữ cảnh nên dùng mẫu Flyweight
Chương 10 : Các mẫu cấu trúc
132
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 263
Trường Đại Học Bách Khoa Tp. HCM
Khoa Công nghệ Thông tin
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
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 264
‰ 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.
Creational Patterns
Chương 11 : Các mẫu Creational
133
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 265
‰ 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:
Ví dụ về quá trình khởi tạo ₫ối tượng
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 266
MapSite
Enter()
Room
Enter()
SetSide()
GetSide()
roomNumber
Maze
AddRoom()
RoomNo()
Wall
Enter()
Door
Enter()
isOpen
sides
rooms
Ví dụ về quá trình khởi tạo ₫ối tượng
Chương 11 : Các mẫu Creational
134
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 267
‰ 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;
};
Ví dụ về quá trình khởi tạo ₫ối tượng
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 268
‰ Class Wall có thể ₫ược hiện thực trong C++ như sau :
class Wall : public MapSite {
public:
Wall ();
virtual void Enter();
};
‰ Class Door có thể hiện thực trong C++ như sau :
class Door : public MapSite {
public:
Door (Room* = 0, Room*=0);
virtual void Enter();
Room* OtherSideFrom (Room*);
private:
Room* m_room1, m_room2;
bool m_isOpen;
};
Ví dụ về quá trình khởi tạo ₫ối tượng
Chương 11 : Các mẫu Creational
135
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 269
‰ 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 :
Ví dụ về quá trình khởi tạo ₫ối tượng
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 270
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.
Ví dụ về quá trình khởi tạo ₫ối tượng
Chương 11 : Các mẫu Creational
136
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 271
‰ 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.
Giải pháp khắc phục
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 272
Abstract Factory
Chương 11 : Các mẫu Creational
‰ 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.
137
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 273
‰ 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.
Ví dụ về quá trình khởi tạo ₫ối tượng
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 274
Thí dụ về mẫu AbstractFactory
Chương 11 : Các mẫu Creational
WidgetFactory
CreateScrollbar()
CreateWindow()
MotifWidgetFactory
CreateScrollbar()
CreateWindow()
PMWidgetFactory
CreateScrollbar()
CreateWindow()
Window
Client
PMWindow MotifWindow
Scrollbar
PMScrollbar MotifScrollbar
138
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 275
AbstractFactory
CreateProductA()
CreateProductB()
ConcreteFactory1
CreateProductA()
CreateProductB()
ConcreteFactory2
CreateProductA()
CreateProductB()
AbstractProductA
Client
ProductA2 ProductA1
AbstractProductB
ProductB2 ProductB1
Sơ ₫ồ cấu trúc của mẫu AbstractFactory
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 276
‰ 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.
Các phần tử tham gia
Chương 11 : Các mẫu Creational
139
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 277
‰ 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 phần tử tham gia
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 278
‰ 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.
Các ngữ cảnh nên dùng mẫu Abstract Factory
Chương 11 : Các mẫu Creational
140
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 279
‰ 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
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 280
‰ 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;
}
Ví dụ áp dụng
Chương 11 : Các mẫu Creational
141
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 281
‰ Để 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
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 282
‰ 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.
Ví dụ áp dụng
Chương 11 : Các mẫu Creational
142
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 283
Factory Method
Chương 11 : Các mẫu Creational
‰ 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.
‰ Nhu cầu áp dụng :
ƒ 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.
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 284
Application
CreateDocument()
NewDocument()
OpenDocument()
MyDocument
Sơ ₫ồ thí dụ
Chương 11 : Các mẫu Creational
Document
Open()
Close()
Save()
Revert()
Document* doc=CreateDocument();
docs.Add(doc);
doc->Open();
return new MyDocument;
MyApplication
CreateDocument()
docs
143
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 285
Sơ ₫ồ cấu trúc của mẫu Factory method
Chương 11 : Các mẫu Creational
Creator
FactoryMethod()
AnOperation()
ConcreteProduct
Product
...
Product = FactoryMethod();
...
return new ConcreteProduct;
ConcreteCreator
FactoryMethod()
docs
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 286
‰ 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.
Các phần tử tham gia
Chương 11 : Các mẫu Creational
144
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 287
‰ 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ể.
Các ngữ cảnh nên dùng mẫu Factory Method
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 288
‰ 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); }
};
Ví dụ áp dụng
Chương 11 : Các mẫu Creational
145
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 289
‰ 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
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 290
‰ 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); }
};
Ví dụ áp dụng
Chương 11 : Các mẫu Creational
146
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 291
Prototype
Chương 11 : Các mẫu Creational
‰ 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.
‰ Nhu cầu áp dụng :
ƒ 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.
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 292
Ví dụ về mẫu Prototype
Chương 11 : Các mẫu Creational
Tool
Manipulate()
return copy of self;
prototype
MusicsalNote
Draw(Position)
Clone()
p = protoype->Clone();
while (user drag mouse) {
p->Draw(new position);
}
insert p onto drawing
WholeNote
Draw(Position)
Clone()
return copy of self;
HalfNote
Draw(Position)
Clone()
MusicalNote
Staff
Draw(Position)
Clone()
GraphicTool
Manipulate()
RotateTool
Manipulate()
147
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 293
Sơ ₫ồ cấu trúc của mẫu Prototype
Chương 11 : Các mẫu Creational
Client
Operation()
return copy of self;
return copy of shelf;
prototype
Prototype
Clone()
p = protoype->Clone();
ConcretePrototype1
Clone()
ConcretePrototype2
Clone()
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 294
‰ 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ó.
Các phần tử tham gia
Chương 11 : Các mẫu Creational
148
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 295
‰ 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.
Một số vấn ₫ề hiện thực
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 296
‰ 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.
Các ngữ cảnh nên dùng mẫu Prototype
Chương 11 : Các mẫu Creational
149
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 297
‰ 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
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 298
‰ 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;
}
Ví dụ áp dụng
Chương 11 : Các mẫu Creational
150
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 299
‰ 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
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 300
‰ 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;
}
Ví dụ áp dụng
Chương 11 : Các mẫu Creational
151
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 301
‰ Để 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 ₫ó.
Ví dụ áp dụng
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 302
Mẫu Builder
Chương 11 : Các mẫu Creational
‰ 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.
‰ Nhu cầu áp dụng :
ƒ 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.
152
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 303
Ví dụ về mẫu Builder
Chương 11 : Các mẫu Creational
RTFReader
ParseRTF()
builder
while (t=getnexttoken()) {
switch (t.type) {
case CHAR :
builder->ConvertCharacter(t.Char);
break;
case FONT :
builder->ConvertFont(t.Font);
break;
case PARA :
builder->ConvertParagraph();
}
}
ASCIIConverter
ConvertCharacter()
GetASCIIText()
TextConverter
ConvertCharacter()
ConvertFont()
ConvertParagraph()
TeXConverter
ConvertCharacter()
ConvertFont()
ConvertParagraph()
GetTeXText()
TextWidgetConverter
ConvertCharacter()
ConvertFont()
ConvertParagraph()
GetTextWidget()
ASCIIText
TeXText TextWidget
builders
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 304
Sơ ₫ồ cấu trúc của mẫu Builder
Chương 11 : Các mẫu Creational
Director
Construct()
builder
forall objects in structure {
builder->BuildPart();
}
Builder
BuildPart()
ConcreteBuilder1
BuildPart()
GetResult()
Product1
builders
ConcreteBuilder2
BuildPart()
GetResult()
Product2
ConcreteBuilder3
BuildPart()
GetResult()
Product3
153
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 305
‰ 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 phần tử tham gia
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 306
‰ 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
Các ngữ cảnh nên dùng mẫu Builder
Chương 11 : Các mẫu Creational
154
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 307
‰ 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
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 308
‰ 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.
Ví dụ áp dụng
Chương 11 : Các mẫu Creational
155
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 309
Singleton
Chương 11 : Các mẫu Creational
‰ 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.
‰ Nhu cầu áp dụ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...
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 310
Sơ ₫ồ cấu trúc của mẫu Singleton
Chương 11 : Các mẫu Creational
return uniqueInstance ;
Singleton
static Instance()
SingletonOperation()
GetSingletonData()
static uniqueInstance
singletonData
156
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 311
‰ 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.
Các phần tử tham gia
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 312
Trường Đại Học Bách Khoa Tp. HCM
Khoa Công nghệ Thông tin
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
Chương 11 : Các mẫu Creational
157
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 313
‰ 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),..
Behavioral Patterns
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 314
Mẫu Chain of Responsibility
Chương 11 : Các mẫu Creational
‰ 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.
158
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 315
aPrintButton
handler
anOKButton
handler
aSavingDialog
handler
aPrintDialog
handler
anApplication
handler
Thí dụ về mẫu Chain of Responsibility
Chương 11 : Các mẫu Creational
‰ 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...
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 316
Thí dụ về mẫu Chain of Responsibility
Chương 11 : Các mẫu Creational
HelpHandler
HandleHelp()
handler
handler->HandleHelp();
Button
HandleHelp()
ShowHelp()
Application Widget
Dialog
if (can handle)
ShowHelp();
else
Handler::HandleHelp();
159
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 317
Lược ₫ồ cấu trúc của mẫu Chain of Responsibility
Chương 11 : Các mẫu Creational
Handler
HandleRequest()
successor
ConcreteHandler1
HandleRequest()
Client
ConcreteHandler2
HandleRequest()
aClient
aHandler
aConcreteHandler
successor
aConcreteHandler
successor
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 318
‰ 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.
Các phần tử tham gia
Chương 11 : Các mẫu Creational
160
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 319
‰ 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.
Các ngữ cảnh nên dùng mẫu Chain of Responsibility
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 320
Template Method
Chương 11 : Các mẫu Creational
‰ 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.
161
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 321
Document
Save()
Open()
Close()
DoRead()
document
Application
AddDocument()
OpenDocument()
DoCreateDocument()
CanOpenDocument()
AboutToOpenDocument()
MyDocument
DoRead()
MyApplication
DoCreateDocument()
CanOpenDocument()
AboutToOpenDocument()
return new MyDocument;
docs
Ví dụ về mẫu Template Method
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 322
AbstractClass
TemplateMethod()
PrimitiveOperation1()
PrimitiveOperation2()
...
PrimitiveOperation1();
...
PrimitiveOperation2();
...
ConcreteClass
PrimitiveOperation1()
PrimitiveOperation2()
Sơ ₫ồ cấu trúc mẫu Template Method
Chương 11 : Các mẫu Creational
162
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 323
‰ 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 phần tử tham gia
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 324
‰ 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.
Các ngữ cảnh nên dùng mẫu Template Method
Chương 11 : Các mẫu Creational
163
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 325
Mẫu Strategy
Chương 11 : Các mẫu Creational
‰ 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.
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 326
Ví dụ về nhu cầu ứng dụng Strategy
Chương 11 : Các mẫu Creational
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.
164
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 327
Composition
Traverse()
Repair()
compositor->Compose();
compositor
Ví dụ về mẫu Strategy
Chương 11 : Các mẫu Creational
Compositor
Compose()
ArrayCompositor
Compose()
TeXCompositor
Compose()
SimpleCompositor
Compose()
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 328
Context
ContextInterface()
strategy
Lược ₫ồ cấu trúc của mẫu Strategy
Chương 11 : Các mẫu Creational
Strategy
AlgorithmInterface()
ConcreteStrategyA
AlgorithmInterface()
ConcreteStrategyB
AlgorithmInterface()
ConcreteStrategyC
AlgorithmInterface()
165
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 329
‰ 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 phần tử tham gia
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 330
‰ 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…)
Các ngữ cảnh nên dùng mẫu Strategy
Chương 11 : Các mẫu Creational
166
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 331
Mẫu Command
Chương 11 : Các mẫu Creational
‰ 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:
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 332
Ví dụ về nhu cầu ứng dụng mẫu Command
Chương 11 : Các mẫu Creational
ƒ 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 ₫ó.
167
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 333
Ví dụ về mẫu Command
Chương 11 : Các mẫu Creational
Menu
Add(MenuItem)
Command
Execute()
command
command->Execute();
Document
Open()
Close()
Cut()
Copy()
Paste()
Application
Add(Document)
MenuItem
Clicked()
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 334
Ví dụ về mẫu Command
Chương 11 : Các mẫu Creational
Command
Execute()
PasteCommand
Execute()
Document
Open()
Close()
Cut()
Copy()
Paste()
document
document->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.
168
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 335
Ví dụ về mẫu Command
Chương 11 : Các mẫu Creational
‰ 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()
OpenCommand
Execute()
AskUser()
Application
Add(Document)
application
name = AskUser();
doc = new Document(name);
application-.Add(doc);
doc->Open();
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 336
Ví dụ về mẫu Command
Chương 11 : Các mẫu Creational
‰ Đô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()
MacroCommand
Execute()
commands
forall c in commands
c->Execute();
169
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 337
Lược ₫ồ class của mẫu Command
Chương 11 : Các mẫu Creational
Command
Execute()
receiver
receiver->Action();
Invoker Client
Receiver
Action() ConcreteCommand
Execute()
state
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 338
‰ 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.
Các phần tử tham gia
Chương 11 : Các mẫu Creational
170
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 339
Quá trình cộng tác giữa các phẩn tử
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 340
‰ 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.
Các ngữ cảnh nên dùng mẫu Command
Chương 11 : Các mẫu Creational
171
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 341
Mẫu State
Chương 11 : Các mẫu Creational
‰ 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.
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 342
state->Open();
state
Ví dụ về mẫu State
Chương 11 : Các mẫu Creational
TCPState
Open()
Close()
Acknowledge()
TCPConnection
Open()
Close()
Acknowledge()
TCPEstablished
Open()
Close()
Acknowledge()
TCPListen
Open()
Close()
Acknowledge()
TCPClosed
Open()
Close()
Acknowledge()
172
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 343
Lược ₫ồ cấu trúc của mẫu State
Chương 11 : Các mẫu Creational
state->Handle();
state
State
Handle()
...
Context
Request()
...
ConcreteStateA
Handle()
...
ConcreteStateB
Handle()
...
ConcreteStateC
Handle()
...
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 344
‰ 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.
Các phần tử tham gia
Chương 11 : Các mẫu Creational
173
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 345
‰ 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.
Các ngữ cảnh nên dùng mẫu State
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 346
Mẫu Observer
Chương 11 : Các mẫu Creational
‰ 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.
174
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 347
Ví dụ về mẫu Observer
Chương 11 : Các mẫu Creational
Spreadsheet BarChart PieChart
Database
request, modification
thay ₫ổi, notification
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 348
Lược ₫ồ cấu trúc của mẫu Observer
Chương 11 : Các mẫu Creational
forall o in observers
o->Update();
observers
Observer
Update()
Subject
Attach(Observer)
Detach(Observer)
Notify()
ConcreteObserver
Update()
observerState
observerState =
subject->GetState();
return subjectState();
ConcreteSubject
GetState()
SetState()
subjectState
175
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 349
‰ 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 phần tử tham gia
Chương 11 : Các mẫu Creational
Bö mön Cöng nghï phền mï̀m
Khoa CNTT
ĐH Bach Khoa Tp.HCM
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Slide 350
‰ 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.
Các ngữ cảnh nên dùng mẫu Observer
Chương 11 : Các mẫu Creational

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
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Slide 3

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

Chương 1

CAC KHAI NIÏM CƠ BAN CUA MÖ HÒNH HƯƠNG ĐÖI TƯƠNG

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 4

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.
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 5

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).
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 6

3

t ̀m vưc truy xu ́t mi u ta giơi han khach hang truy xu ́t dư li u.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 7 Tư lêp trònh co cếu truc ₫ḯn OOP Chương tr nh = c ́u truc dư li u + giai thu t module (package) entry 'start' global data local data of module local data of function Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 8 4 . 6... Chương tr nh c ̉ ₫i ̉n co c ́u truc ph n c ́p như sau : Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.) cho phep c ́u truc chương tr nh. sư dung lai code. .. . Đ ̉ truy xu ́t ₫ung 1 dư li u ta c ̀n : . 8. Dư li u cua 1 chương tr nh co th ̉ r ́t nhi ̀u va ₫a dang. Chương tr nh con (function. Chương tr nh c ̉ ₫i ̉n = giai thu t + dư li u..t n nh n dang.ki ̉u dư li u mi u ta c ́u truc dư li u. 7.. subroutine.Tư lêp trònh co cếu truc ₫ḯn OOP 5.

C++. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 10 5 . Sau ₫o xu ́t hi n th m : Object Pascal.… H nh thanh cac phương phap ph n t ch/thi ́t k ́ hương ₫ ́i tương. Eiffel.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 9 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. Java. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Tư lêp trònh co cếu truc ₫ḯn OOP Chương tr nh = t p cac ₫ ́i tương tương tac nhau ₫ ́i tương (object) entry local data of object local data of operation Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. C#. Nhưng ng n ngư hương ₫ ́i tương ₫ ̀u ti n : Smalltalk.

INOUT).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 11 Kiï̉u trưu tương (Abstract type) Abstract type (type) ₫ịnh nghĩa interface sư dung ₫ ́i tương. Đ ́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. OUT. Implementation (class) Interface (abstract type) Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Signature g ̀m : t n method (operation) danh sach ₫ ́i 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. tac vu (operation) : thưc hi n 1 c ng vi c nao ₫o. Interface la t p cac entry ma b n ngoai co th ̉ giao ti ́p vơi ₫ ́i tương. ₫ăc ta chưc năng cua method (thương la chu th ch). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Dung abstract type (chư kh ng phai class) ₫ ̉ ₫ăc ta ki ̉u cho bi ́n. Dung signature ₫ ̉ ₫ịnh nghĩa m ̃i entry.Đö́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. tham s ́ h nh thưc. m ̃i ₫ ́i s ́ ₫ươc ₫ăc ta bơi 3 thu c t nh : t n.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 12 6 . thu c t nh. type va chi ̀u chuy ̉n ₫ ng (IN.

trong trương hơp sau thu c t nh chưa tham khao ₫ ́n ₫ ́i tương khac. Định nghĩa cac method constructor va destructor.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 14 7 . protected Vector objects = null. } public int getAlignment( ) { return alignment. User kh ng c ̀n quan t n ₫ ́n class cua ₫ ́i tương. private int alignment = LEFT. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. // abstract operation } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. protected static final int RIGHT = 2.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 13 Vñ du vï̀ class trong Java class abstract HTMLObject { protected static final int LEFT = 0.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. } public void setAlignment( int algnmt ) { alignment = algnmt. coding cac method va cac internal function. HTMLObject( ){ // constructor objects = new Vector (5). ki ̉u cua thu c t nh co th ̉ la type c ̉ ₫i ̉n hay abstract type. Định nghĩa cac method tao va xoa ₫ ́i tương. } public abstract String toHTML( ). protected static final int MIDDLE = 1.

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.cohesion giưa cac ₫ ́i tương r ́t th ́p).Tñnh bao ₫ong (encapsulation) Bao ₫ong : che d ́u moi chi ti ́t hi n thưc cua ₫ ́i tương. che d ́u chi ti ́t hi n thưc cac method. k ́t qua override chỉ co nghĩa trong ₫ ́i tương class con. che d ́u cac internal function va sư hi n thưc cua chung. M ́i quan h  supertype/subtype va superclass/subclass. 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 . Đa thưa k ́ hay ₫ơn thưa k ́.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 15 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). 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 16 8 . Đ ́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. co th ̉ override cac method cua class cha. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

protected COLORREF color. // other attributes.. protected double xScale. yPos2. class Line extends Geometry { int xPos2.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 17 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.Vñ du vï̀ thưa kḯ va override . yPos. Goc nh n ngư nghĩa O2 O1 O3 O3 Goc nh n hi n thưc O2 O1 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 18 9 .Java class Geometry { public Draw(Graphics g). }. protected int xPos. yScale.. public Draw(Graphics g) { // cac l nh ve ₫oan thăng } } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

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. ~Group( ). virtual void Draw( Window *pWnd ). int geoCount. double xScale. class Group : public Geometry { public: Group( ).Draw (pWnd). COLORREF color. danh sach tham s ́ thưc c ̀n truy ̀n theo (hay nh n v ̀ tư) tac vu. yScale. 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. // override private: // pointer container Geometry **ppGeo.C++ class Geometry { // abstract base class public: Geometry( ).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 19 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. virtual void Draw( Window *pWnd ) = 0.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 20 10 . aCircle. v du : aCircle. // abstract operation protected: int xPos.SetRadius (3). ~Geometry( ).Vñ du vï̀ bao göp . }. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. yPos. }.

// tao ₫ ́i tương C2.). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp..meth1(. T1 p1... gan tham khao vao p1 p1..meth1(. ơ 2 vị tr khac nhau k ch hoat 2 method khac nhau cua 2 class khac nhau. // C1 va C2 la 2 class hi n thưc T1 . .)..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.). 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. 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. p1 = New C2. 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. p1 = New C1.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 21 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). L nh p1.. 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. 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.. gan tham khao vao p1 p1.meth1(. // tao ₫ ́i tương C1. danh sach ₫ ́i s ́ cua 2 method tương ưng phai băng nhau..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 22 11 .. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp..

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 24 12 . ₫ ́i tương phai bị xoa khi kh ng con tham khao nao ₫ ́n 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. vưng b ̀n kh ng phai la vĩnh hăng. 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.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. ₫ y la c ng vi c cua h  th ́ng th ng qua module 'garbage collection'. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. CDROM). Thương dung ngư nghĩa nay trong giai ₫oan ph n t ch/thi ́t k ́ ph ̀n m ̀m. 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. v tai thơi ₫i ̉m nay ₫ ́i tương la rac.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 23 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.

giưa cac class/₫ ́i tương co th ̉ t ̀n tai quan h  bao g p. t ̉ng quat hoa.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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 1: Cac khai ni m cơ ban cua m h nh hương ₫ ́i tương Slide 25 Trương Đai hoc Bach Khoa Tp. Cac tac vu thi ́t l p n n hanh vi cua ₫ ́i tương. Hö̀ Chñ Minh Khoa Cöng Nghï Thöng Tin Chương 2 THÑ DU VÏ NGÖN NGƯ OOP Visual C++ Java Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Cac ₫ ́i tương ₫ươc ph n loai băng class. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 26 13 . Cac ₫ ́i tương tương tac vơi nhau băng cach gơi th ng ₫i p. 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'. thưa k ́. 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.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 28 14 . 7. Đa hònh co chon loc nhơ 'virtual function' Chỉ hö̃ trơ cac ₫ö́i tương tam.2. 2. 8. 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. Tềm vưc truy xuết cac thanh phền. 6. Co thï̉ ₫ịnh nghĩa function overloaded. 5. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Chỉ hö̃ trơ khai niïm class. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 4.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 27 Chỉ hö̃ trơ khai niïm class 1. Đ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. 3. Override method khi thưa kḯ. 2.1 Ngön ngư Visual C++ 1. Dung 'abstract class' ₫ï̉ ₫ịnh nghĩa interface. Dung class ₫ ̉ ₫ịnh nghĩa ki ̉u cho cac bi ́n. Cho phep Đa thưa kḯ.

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. // pure virtual function protected: int xPos.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 30 15 . 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. class Geometry { // abstract class public: Geometry( ).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 29 Tềm vưc truy xuết thanh viïn 4. yPos. public : cho phep t ́t ca moi nơi truy xu ́t. Co th ̉ han ch ́ t ̀m vưc cua thanh vi n cua class cha khi thưa k ́. yScale. double xScale. Friend function : la function co th ̉ truy xu ́t tư do m ̃i thanh ph ̀n cua class hi n tai. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. chăt.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". Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. COLORREF color. }. protected : chỉ che d ́u b n ngoai nhưng cho phep cac ₫ ́i tương con. ~Geometry( ). truy xu ́t.. virtual void Draw( Window *pWnd ) = 0. chau.

Tham khao ₫ ́n ₫ ́i tương thưc ch ́t la pointer cuc b . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Cho phep ₫ịnh nghĩa cac ham 'overloaded' : cung t n nhưng 'signature' khac nhau.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 31 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. 7. 8. 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.Hö̃ trơ tñnh ₫a hònh co chon loc 5. 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 2 ₫ịa chỉ function 3 ₫ịa chỉ function i ₫ịa chỉ function n Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Co quy ̀n 'override' b ́t ky toan tư hay function nao cua class cha. VC++ h ̃ trơ hoat ₫ ng save/restore ₫ ́i tương nhơ kha năng 'Serialization'.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 32 16 . Đị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.

private : int xPos..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 34 17 ..}. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. yPos.. ~Geometry( )... }. }. class Line : Geometry { .. .. protected: COLORREF color. . class Polygon : Geometry {.. class Rectangle : Geometry {. yScale... .. class Point : Geometry {}..... double xScale...HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 33 Cếu truc 1 chương trònh Dialog based ₫ơn gian InitInstance() DoModal() CProgramDlg CProgramApp Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. // virtual method BOOL IsDisplayed(void).Skeleton ₫ịnh nghĩa class class Geometry : Object { // == class Geometry : public Object { public: Geometry( ).}... . virtual void Draw( Window *pWnd )..

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 35 Cếu truc 1 chương trònh MDI ₫ơn gian InitInstance() CChildFrame CProgramView CProgramDoc CMultiDocTemplate CProgramApp Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Cếu truc 1 chương trònh SDI ₫ơn gian InitInstance() CMainFrame CProgramView CProgramDoc CSingleDocTemplate CProgramApp Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 36 18 .

4. nhưng kh ng ₫ươc xoa ₫ ́i tương. Co th ̉ dung interface ₫ ̉ ₫ịnh nghĩa ki ̉u cho cac bi ́n.. 5. 6. Phai goi ham tao ₫ ́i tương 1 cach tương minh. 9. Hö̃ trơ package Đa hònh ₫ềy ₫u. Dung 'abstract class' ₫ï̉ ₫ịnh nghĩa interface. Co thï̉ ₫ịnh nghĩa function overloaded. 4. class C1 extends RootClass {. Hö̃ trơ 'interface' (1 dang cua type) va class.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 38 19 .HCM Hö̃ trơ Class va Interface 1. Chỉ hö̃ trơ ₫ö́i tương tam trong session JVM Override function khi thưa kḯ. 3. 2. thu c t nh. 8. Hö̃ trơ Đơn thưa kḯ. Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 37 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 3..} C1 o1. Tềm vưc truy xuết cac thanh phền. 7.2. Chu y ́u dung class ₫ ̉ ₫ịnh nghĩa ki ̉u cho cac bi ́n. 2. Interface chỉ ₫ươc dung trong trương hơp ₫ăc bi t va kh ng tương ₫ương vơi abstract type.2 Ngön ngư Java 1. Đơ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. // o1 chưa tham khao ₫ ́n ₫ ́i tương C1 o1 = New C1. thu c t nh. Đ ́i tương chỉ co th ̉ chưa tham khao ₫ ́n ₫ ́i tương khac.

chăt. truy xu ́t. friendly : cho phep moi ph ̀n tư trong package truy xu ́t. Abstract class co th ̉ chưa ₫ ̀y ₫u cac hi n thưc b n trong. .. protected : che d ́u b n ngoai nhưng cho phep cac ₫ ́i tương con. chau. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. protected double xScale.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 39 Tềm vưc truy xuết cac thanh phền 6. protected COLORREF color. nhưng thương chỉ co chưa cac 'abstract function'. class abstract Geometry { // abstract class protected int xPos..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 40 20 .. Đ y la t ̀m vưc default va kh ng co tư khoa t ̀m vưc tương minh. public abstract Draw(Graphics g).. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Hö̃ trơ abstract class 5. public : cho phep t ́t ca moi nơi truy xu ́t. yPos. }. 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... // abstract function . yScale. 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.

} 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 41 Hö̃ trơ ₫ềy ₫u tñnh ₫a hònh 8. public class Circle extends Graphic implements Draggable { . ₫ịa chỉ function 1 ₫ịa chỉ function 2 ₫ịa chỉ function 3 ₫ịa chỉ function i ₫ịa chỉ function n Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. T ́t ca cac public function ₫ươc quan ly trong 1 danh sach "public function table".Hö̃ trơ package 7..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 42 21 . Package la ₫ơn vị quan ly t ̀m vưc cua java.. package graphics. Nhi ̀u file source co th ̉ thu c cung 1package (dung cung t n trong phat bi ̉u package). co th ̉ chưa nhi ̀u class.

return. 11. Đ ́i tương se t ̀n tai m t khi con tham khao ₫ ́n no.out. } catch (UnknownHostException e) {.out. Cho phep ₫ịnh nghĩa cac ham 'overloaded' : cung t n nhưng 'signature' khac nhau.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 43 Thñ du vï̀ chương trònh Java import java.out. Ban co th ̉ tao ra cac ₫ ́i tương mơi ma kh ng c ̀n xoa no. 10.println("Usage: java AddrLookupApp <HostName>").getByName(args[0]).length!=1) { System.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 44 22 .} } } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp... Cac ₫ ́i tương chỉ t ̀n tai tam thơi trong 1session chay JVM.getHostName(). System. System. String hostName = host.getHostAddress()).println ("IP address:"+host.net.println ("Host name : "+hostName). } InetAddress host = InetAddress. Co quy ̀n 'override' b ́t ky function nao cua class cha. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. public class getnet { public static void main(String args[]) { try { if(args.Cac ₫ö́i tương ₫ï̀u 'tam thơi' 9.*.

private static final int NOROOM = -1.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 45 Thñ du vï̀ cac class Java public class AlarmClock { private static final int MAX_CAPACITY = 10. private long[] sleepFor = new long[MAX_CAPACITY]. } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Thñ du vï̀ chương trònh Java GUIClock 12. i < MAX_CAPACITY.25 <<chưa>> AlarmClock wakeup() Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. i++) sleepFor[i] = UNUSED.34. public AlarmClock () { for (int i = 0.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 46 23 . private Sleeper[] sleepers = new Sleeper[MAX_CAPACITY]. private static final int UNUSED = -1.

Thñ du vï̀ cac class Java
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; } }
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 47

Thñ du vï̀ cac class Java
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; }
Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 48

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

24

Thñ du vï̀ cac class Java
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); } } }
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 49

Thñ du vï̀ cac class Java
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(); }
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 50

25

Thñ du vï̀ cac class Java
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 Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 2: Th du v ̀ cac ng n ngư OOP Slide 51

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

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 52

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. • N n dung c ng cu h ̃ trơ như LEX. ph n t ch cu phap. YACC.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 54 27 . ph n t ch ngư canh. • Ta se mi u ta qui tr nh dịch 1 type va 1 class Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. • 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 53 Dịch 1 abstract type • Abstract type chỉ chưa th ng tin trưu tương (interface). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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.

public : int proc4(int i). . // cac field dư li u ₫i ̀u khi ̉n // tư tao bơi chương tr nh dịch void (*pvfaddr)() . YACC. .HCM typedef struct { // import cac field tư c ́u truc // ₫ươc sinh ra tư C0 // cac field tương ưng vơi C1 int C1_d. • C ̀n ₫ ̀y ₫u cac bươc : duy t tư vưng. }. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. • 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). ph n t ch ngư canh.. • N n dung c ng cu h ̃ trơ như LEX. .. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 56 28 .. int i . tao ma.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 55 Dịch thuöc tñnh dư liïu • class → c ́u truc record class C1 : C0 { double d.. int C1_i. void proc5 (double d). ph n t ch cu phap.Dịch 1 class • Dịch class la c ng vi c ch nh cua chương tr nh dịch OOP... } C1.

• chuy ̉n tưng thu c t nh cua class thanh tưng field cua record. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. mov bx. . • t n class → t n record.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 57 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.i = 5. 5 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. • copy cac field dư li u cua c ́u truc sinh ra tư class cha.o1. C1_o1 mov [bx+4]. 'tuy t ₫ ́i hoa' t n cua thu c t nh ₫ ̉ tranh nhăp nhăng.Dịch thuöc tñnh dư liïu (tt) • m ̃i class → 1 record c ̉ ₫i ̉n.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 58 29 .field C1 o1. C1_o1 db dup (sizeof(C1)) nhơ • truy xu ́t 1 thu c t nh dư li u trơ thanh vi c truy xu ́t dung cach ₫ịnh ₫ịa chỉ chỉ s ́ : . • 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).

• th m vao cac method mơi ₫ịnh nghĩa trong class hi n hanh. public : int proc4(int i. • hi u chỉnh lai cac ₫ịa chỉ cua cac method bị override.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 60 30 . • copy bang ₫ịa chỉ cua class cha ₫a co.. void proc5 (double d). double d. double k).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 59 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.. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Tao bang ₫ịa chỉ cac method pvftbl fname 0 "proc1" 1 "proc2" 2 "proc3" 3 "proc4" 4 "proc5" 5 .. k ̉ ca cac method thưa k ́. }.. class C1 : C0 { int i . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.... faddr C0_proc1 C1_proc2 C0_proc3 C1_proc4 C1_proc5 . .. . • 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..

double d) { int C1::proc1(int i.d). p2 = New(C2).d). if (strcmp ("proc2".Dịch 1 method int C1_proc1(C1* p. C2 *p2. p->C1_d = d.. t m. 1 // anh xa bang ₫ịa chỉ method p2->proc2(i. — goi gian ti ́p method th ng qua ₫ịa chỉ ph ̀n tư thư i trong bang. — t m chỉ s ́ cua method c ̀n goi trong bang (i). int i. C2 o2.d). // gơi th ng bao : ki ̉m tra. i. C1::i = i. C2_proc2(&o2.faddr)(p2. p2-> }. i ++) . load va anh xa bang ₫ịa chỉ cac method cua ₫ ́i tương. p->C1_i = i. // goi ham d = k. • goi ham internal → goi ham nhưng th m tham s ́ ₫ ̀u ti n. o2. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 61 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). pvftbl[i]. • 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.fname)==0) break. // truy xu ́t thu c t nh C2 *p2. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. • gơi th ng bao 3 bươc : — ki ̉m tra.d).double k) { C2 o2.. }. C1_proc5(p. load. proc5(d).. • 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).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 62 31 . 3 (*pvftbl[i].i.d). i <C1METHCNT.proc2(i. 2 for (i = 0.

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. t m chỉ s ́ method c ̀n goi va goi gian ti ́p qua ₫ịa chỉ trong bang. — bang ₫ịa chỉ method chi ́m nhi ̀u ch ̃. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 63 Tö́i ưu hoa code tao ra (tt) • trong C++. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. con cac function khac ₫ươc dịch ra lơi goi trưc ti ́p.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 64 32 . — t ́n thơi gian ₫ ̉ phuc vu l nh gơi th ng bao : ki ̉m tra. • 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. 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. load va anh xa bang ₫ịa chỉ. • chỉ co cac virtual function mơi ₫ươc giai quy ́t theo cơ ch ́ ₫a h nh. • 1 s ́ chương tr nh dịch t m cach t ́i ưu hoa cac v ́n ₫ ̀ nay. • m ̃i l ̀n tao ₫ ́i tương. • 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. • 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.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. HCM Khoa Cöng nghï Thöng tin 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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 3: Nguy n tăc dịch OOP Slide 65 Trương Đai Hoc Bach Khoa Tp. — t nh ₫a h nh chỉ ₫ung giưa cac ₫ ́i tương co m ́i quan h  con/cha.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 66 33 .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. 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". ơ ₫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.

documents • Worker: Architect Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 67 Key concepts • Cycle • Phase. Iterations • Process Workflows — Activity. and How to reach a certain goal. steps When does product happen? When does architecture happen? What does happen? What is produced? • Artifacts — models — reports. When to do it.HCM Who does it? Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 68 34 . New or changed requirements Software Engineering Process New or changed system Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.What Is a Process? • Defines Who is doing What.

.Key concepts time Cycle 1 Phase Inception Cycle 2 Cycle 3 Cycle 4 Cycle i Cycle n Elaboration Construction Transition Prelim Iteration .. specify features..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 69 Lifecycle Phases Inception Elaboration Construction Transition time • Inception • Elaboration • Construction • Transition Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Dev Iteration Dev Iteration . and baseline the architecture Build the product Transition the product to its users Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 70 35 .... Release Release Release Release Release Release Release Release Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Trans Iteration ..HCM Define the scope of the project and develop business case Plan project. Arch Iteration ..

Release Release Release Release Release Release Release Release An iteration is a sequence of activities with an established plan and evaluation criteria.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 72 36 . Dev Iteration Dev Iteration ..Major Milestones Inception Elaboration Construction Transition time Vision Baseline Architecture Initial Capability Product Release Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp... Trans Iteration .. Arch Iteration ..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 71 Phases and Iterations Inception Elaboration Construction Transition Prelim Iteration ... resulting in an executable release Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp..

#n+1 ite r. #n ite r.Iterations and Workflow Phases Core Workflows Requirements An iteration in the elaboration phase Analysis Inception Elaboration Construction Transition Design Implementation Test P r e lim in a ry Ite ra tio n (s ) ite r.HCM Mön It e r a tio n s Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 73 Workflows and Models UML diagrams provide views into each model Requirements Use Case Model Analysis Analysis Model Design Design Model Depl. Model Implementation Each workflow is associated with one or more models. Model Test Model Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 74 37 . Test Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. #2 ite r.HCM Impl. #n +2 ite r. #m ite r. #1 ite r. #m +1 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

Model Collaboration Diagrams Statechart Diagrams Activity Diagrams Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 75 Impl.HCM Analysis & Design Model Use Case Model Use Case Diagrams Class Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Object Diagrams Analysis Model Incl.HCM 38 . subsystems and packages Design Model Depl.Use Case Model Use Case Model Use Case Diagrams Class Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Object Diagrams Analysis Model Design Model Depl. Model Collaboration Diagrams Statechart Diagrams Activity Diagrams Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 76 Impl. Model Test Model Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Model Test Model Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

HCM Test Model Use Case Model Use Case Diagrams Class Diagrams Component Diagrams Deployment Diagrams Test model refers to all other models and uses corresponding diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams Object Diagrams Analysis Model Design Model Depl.Deployment and Implementation Model Use Case Model Use Case Diagrams Class Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Object Diagrams Analysis Model Design Model Depl. Model Test Model Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Model Impl. Model Incl. active classes and components Collaboration Diagrams Statechart Diagrams Activity Diagrams Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 77 Impl.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 78 39 . Model Test Model Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

ts Analysis Design Impl.Overview of the Unified Process • The Unified Process is — Iterative and incremental — Use case driven — Architecture-centric — Risk confronting Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 79 Use Case Driven Req.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 80 40 . Test Use Cases bind these workflows together Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 81 Architecture-Centric • Models are vehicles for visualizing. and documenting architecture • The Unified Process prescribes the successive refinement of an executable architecture Inception time Elaboration Construction Transition Architecture Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. constructing.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 82 41 . specifying.

subsystem • Other elements — note Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. active class. use case.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 84 42 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 83 Modeling Elements • Structural elements — class. component. state machine • Grouping elements — package.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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. node • Behavioral elements — interaction. collaboration. interface.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 85 Extensibility Mechanisms • Stereotype • Tagged value • Constraint Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Relationships • • • • Dependency Association Generalization Realization Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 86 43 .

there are nine standard diagrams — Static views: use case. and Diagrams A model is a complete description of a system from a particular perspective Use Case Use Case Diagrams Sequence Diagrams Diagrams Use Case Use Case Diagrams Use Case Diagrams Diagrams State State Diagrams Class Diagrams Diagrams State State Diagrams Object Diagrams Diagrams Scenario Scenario Diagrams Collaboration Diagrams Diagrams Models State State Diagrams Component Diagrams Diagrams Scenario Scenario Diagrams Statechart Diagrams Diagrams Component Component Diagrams Deployment Diagrams Activity Diagrams Diagrams Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. deployment — Dynamic views: sequence. statechart. activity Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 87 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. component. collaboration. class. Views. object.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 88 44 .Models.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 90 45 .Use Case Diagram • Captures system functionality as seen by users Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 89 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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

Class Diagram • Captures the vocabulary of a system Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. designers.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 91 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. and implementers Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 92 46 .

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 93 Object Diagram • Shows instances and links • Built during analysis and design • Purpose — Illustrate data/object structures — Specify snapshots • Developed by analysts.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 94 47 .Object Diagram • Captures instances and links Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. and implementers Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. designers.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 95 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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 96 48 .Component Diagram • Captures the physical structure of the implementation Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

networking engineers.Deployment Diagram • Captures the topology of a system’s hardware Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 97 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. and system engineers Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 98 49 .

Sequence Diagram • Captures dynamic behavior (timeoriented) • Purpose — Model flow of control — Illustrate typical scenarios Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 100 50 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 99 Collaboration Diagram • Captures dynamic behavior (message-oriented) • Purpose – Model flow of control – Illustrate coordination of object structure and control Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

) Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 102 51 . devices. etc.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 101 Activity Diagram • Captures dynamic behavior (activityoriented) • Purpose — Model business workflows — Model operations Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Statechart Diagram • Captures dynamic behavior (event-oriented) • Purpose — Model object lifecycle — Model reactive objects (user interfaces.

collaborations Implementation View Use cases Components Use Case View Process View Deployment View Active classes Nodes Organization Package.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 104 52 . subsystem Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Model Test Model Models Views Architecture embodies a collection of views of the models Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. interfaces.HCM Dynamics Interaction State machine Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 4: UML & Qui tr nh hơp nh ́t Slide 103 Architecture and Models Use Case Model Analysis Model Design Model Depl. Model Impl.Architecture and the UML Design View Classes.

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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 106 53 .Trương Đai Hoc Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 105 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. tư m h nh lĩnh vưc (domain model) cho cac ưng dung nhung (embeded). tư 1 ₫i ̉m nao ₫o năm giưa cac ₫i ̉m xu ́t phat tr n. HCM Khoa Cöng nghï Thöng tin 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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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).

HCM * Use .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.Case Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 108 54 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 107 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 * Actor Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. — 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) Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

HCM Prototype User-Interface Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 110 55 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 109 Q u i trÉnh n ă  m b ă  t yãu c Ý ̀ u System Analyst Find Actors & Use-Cases Prioritize Use-Cases Detail a Use-Case Structure the Use-Case Model Architect Use-Case Specifier User-Interface Designer Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.C a  c w o r k er s tr o n g n ă  m b ă  t yãu c Ý ̀ u System Analyst Use-case Specifier User-Interface Designer Architect 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 Model Actor Glossary Use-Case User Interface Prototype Architecture Description Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

T m cac use cases cua h  th ́ng. Mi u ta toan th ̉ m h nh use-case.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. 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 ? Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 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 . 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. Mi u ta văn tăt v ̀ tưng use-case.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 112 56 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 111 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Hoat ₫ ng nay g ̀m 4 bươc : T m cac actor cua h  th ́ng.

n n ₫ươc ₫ăt t n.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.HCM 57 . ₫ươ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. 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 ? Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Dung lươc ₫ ̀ va cac flow of events ₫ ̉ mi u ta m h nh use-case t ̉ng th ̉.C a s e s M ̃i use-case sau khi t m ₫ươc. Quan h  giưa cac actors : t ̉ng quat hoa (generalization). 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. 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. Quan h  giưa cac use-cases : t ̉ng quat hoa. include extend Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 114 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Quan h  giưa actor va use-case : li n k ́t (association). xoa.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 113 M iã u ta v ăn tăt tưng U s e. ₫ăc bi t la cac m ́i quan h  giưa cac use-case va vơi actor. tao.

<<extend>> Edit User Information Add New User Remove User Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 116 58 ..Cac né́i quan hã giưa cac actor va use-cases Use-Case Z Actor A Actor B Use-Case X <<extend>> Use-Case D Use-Case Y Use-Case A <<include>> Use-Case B Use-Case C Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 115 Cac né́i quan hã giưa cac use-cases va use-cases <<include>> Store Manager User Maint enance POS Login <<extend>> <<exten.

no la ph ̀n tư trưu tương. Lưu y actor t ̉ng quat hoa thương kh ng co th t.Cac né́i quan hã giưa cac actor va actor Quan h  giưa cac actors : t ̉ng quat hoa (generalization). Cus tom ers C us tom er R etail S tor e Cu s tom er Telephone C us tom er O nline Cus tom er Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 117 Lươc ₫é̀ use-case Sales:From Order to Delivery Order Goods & Services Ini tiator Confirm Order Initiator Initiator Buyer Initiator Initiator Invoice Buyer Seller Send Reminders Pay Invoice <<extend>> Accou nti ng System Perform Transaction Pay Overdraft Fee Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Telephone Customer. Retail Store Customer.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 118 59 . Th du Customer la actor t ̉ng quat hoa cua cac actor Online Customer.

n n x y dưng 1 bang thu  ngư chung (glossary).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 120 60 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 119 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 usecase. ₫anh gia lai. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 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m bao t nh nh ́t quan khi mi u ta nhi ̀u use-case ₫ ̀ng thơi.

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.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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. kinh t ́.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 121 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 ́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.. N ́u hơn 1 actor dung use-case. ₫ăc ta use-case bao g ̀m nhưng g .. 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. cac hoat ₫ ng cua ho co th ̉ anh hương l ̃n nhau. 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. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 122 61 . h nh thưc hoa ₫ăc ta use-case. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. use-case nao ₫ươc phat tri ̉n sau. H  th ́ng co th ̉ phat hi n l ̃i nh p tư actor.

n n ₫ịnh nghĩa trang thai k ́t thuc. Đăc ta lu ̀ng phu ₫ươc rut tr ch tư lu ̀ng cơ ban.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 123 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 usecase 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. khi nao va cach nao use-case k ́t thuc. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. gia trị.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 124 62 . khi nao va cach nao use-case băt ₫ ̀u. Co th ̉ mi u ta lu ̀ng thi hanh phu trong ₫ăc ta lu ̀ng cơ ban.Đăc ta use-case gé̀m nhưng gÉ ? n n ₫ịnh nghĩa trang thai băt ₫ ̀u. 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. thư tư cac hoat ₫ ng ₫ươc thưc hi n. Vi c dung cac ₫ ́i tương. tai nguy n trong h  th ́ng. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. cac khach hang va ngươi dung kho long hi ̉u n ̉i. Phai mi u ta ro rang h  th ́ng lam g va actor lam g . Tương tac giưa h  th ́ng va actor va chung trao ₫ ̉i nhưng g. 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. kh ng cho phep nhi ̀u 'path' thưc thi.

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 ́.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 126 63 . M ̃i use-case c ̀n ₫ươc xư ly như 1 artifact ri ng bi t.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 5: Năm băt y u c ̀u hương ₫ ́i tương Slide 125 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". do ₫o kh ng n n chon use-case qua lơn hay qua nho. rut tr ch cac use-case nhi m y va phu th m ₫ ̉ nơi r ng usecase khac. Tranh chia nho use-case. 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 ̉. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.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 usecase ₫ăc bi t hơn. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ngươi ₫ăc ta use-case ₫a phat tri ̉n ₫ăc ta chi ti ́t cho m ̃i use-case.

HCM Khoa Cöng nghï Thöng tin Chương 6 PHÊN TÑCH HƯƠNG ĐÖI TƯƠNG Cac artifacts cền tao ra Cac workers tham gia Qui trònh phên tñch Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 128 64 . loai trư moi chi ti ́t dư thưa. ₫ịnh nghĩa cac d ̃n xu ́t use-case.Trương Đai Hoc Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 127 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. ₫ươ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. phat hoa cac hi n thưc cho cac chưc năng b n trong h  th ́ng. kh ng nh ́t quan. ₫ươc c ́u truc tư cac class ph n t ch va cac package ph n t ch. 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. th ̉ hi n goc nh n tư b n trong cua h  th ́ng.

.).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.HCM Use-Case Realization Analysis Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 130 65 ... — '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) Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 129 Cac artifacts cÝ̀n tao ra trong phÝn tÈch yãu cÝ̀u 1 Analysis Model Analysis System * * Analysis Package * * * * Analysis Class Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. — 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.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 131 Qui trÉnh phÝn tÈch yãu cÝ̀u Architectural Analysis Architect Use-Case Engineer Analyze a Use-Case Component Engineer Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Cac workers trong phÝn tÈch yãu cÝ̀u Architect Use-Case Engineer Component Engineer chịu trach nhi m v ̀ chịu trach nhi m v ̀ chịu trach nhi m v ̀ Analysis Model Architecture Description Use-Case Realization Analysis Analysis class Analysis package Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Analyze a Class Analyze a Package Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 132 66 .

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 134 67 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. c ng tac. include va extend. 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. loai th ng tin co t nh b ̀n vưng. class ₫i ̀u khi ̉n (control class) m h nh vi c xư ly.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 use-case co quan h  l ̃n nhau : t ̉ng quat hoa. t ̀n tai l u dai. 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. giao tac trong use-case. cac use-case h ̃ trơ cho cung 1 actor. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 133 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. Boundary class Entity class Control class Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. sư tinh ch ́ c ́u truc cac package se ti ́n tri ̉n theo. khi vi c ph n t ch ti ́n tri ̉n. Theo thơi gian.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 136 68 . cac t nh ch ́t an toan dư li u. sư ph n tan & ₫ ̀ng thơi. 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. ₫ ̀ nghị 1 s ́ class thưc th ̉ quan trong nh ́t (tư 10-20). quan ly giao tac.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. chung g ̀m : t nh b ̀n vưng. năm băt 1 s ́ y u c ̀u ₫ăc bi t cho d ̃n xu ́t use-case. ₫ ̀ khang vơi l ̃i.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 135 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. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 138 69 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. thưc th ̉ c ̀n thi ́t ₫ ̉ hi n thưc use-case va phat hoa t n.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 137 ThÈ du vã̀ lươc ₫é̀ class phÝn tÈch cho use-case Pay Invoice Order Configmation Order Handler Invoice Buyer (f rom Use-Case Model) Payment Request UI Payment Scheduler Payment Request Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. bi n. nh n dang class bi n cơ sơ cho m ̃i class thưc th ̉ vưa t m ₫ươc.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. nh n dang class ₫i ̀u khi ̉n co trach nhi m xư ly trong d ̃n xu ́t use-case. 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. 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. thu c t nh va cac m ́i quan h  giưa chung. nh n dang class bi n trung t m cho m ̃i actor la con ngươi. trach nhi m.

1 va ca 2 ₫ươc l ̀ng trong 3.3b xay ra ₫ ̀ng thơi va ₫ươc l ̀ng trong 3.4.3a va 3. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.6]: invert(x.2 xay ra sau 3.2 *[i:=1. tư actor gơi 1 th ng bao ₫ ́n class bi n ₫ ̉ k ch hoat use-case.2/ 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.4. color) Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 4.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 139 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. c ̀n b ̉ sung ₫ăc ta dang văn ban vao lươc ₫ ̀ c ng tac. 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. 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.1: p := find(specs) — 1.1. chưa v i k ́t hơp tac vu cu th ̉ cho th ng bao..4.4 — 3. — 3.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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 140 70 .3. ₫ăc ta nay n n ₫ươc ₫ ̉ vao 'flow of events c ́p ph n t ch".4.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 141 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.Lươc ₫é̀ céng tac 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 6: Schedule InVoice for payment 1: Browse Invoice : Buyer : Payment Request UI 2: Browse : Invoice 9: setStatus(scheduled) 7: Schedule payment 8: New : Payment Scheduler : Payment Request Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 142 71 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 144 72 . thu c t nh cua class ₫i ̀u khi ̉n t khi co. n n tach 1 s ́ thu c t nh phưc tap ra thanh class ri ng.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 143 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. thu c t nh cua class thưc th ̉ thương d ̃ th ́y. ki ̉u thu c t nh ơ c ́p ph n t ch n n ơ c ́p y ni m. ₫ i khi kh ng c ̀n cac thu c t nh h nh thưc. 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. ₫ 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. Dung cac hương d ̃n sau : t n thu c t nh n n la danh tư. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. n ́u class ph n t ch qua phưc tap. 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.. 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.. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.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. n n dung lai ki ̉u ₫a co khi ₫ăc ta ki ̉u cho thu c t nh mơi. chưa c ̀n ki ̉u cu th ̉.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 145 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. 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. han ch ́ t ́i ₫a sư phu thu c giưa cac package. 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. 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. Đ ̉ rut tr ch cac hanh vi chung cua nhi ̀u class ph n t ch. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ₫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. 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ơ). me va con). 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. nhưng chỉ n n ơ c ́p y ni m. ph n ph ́i lai cac class qua phu thu c vao package khac.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. Dung cac hương d ̃n sau : ₫am bao package chưa cac class ₫ung. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ta co th ̉ dung class t ̉ng quat hoa. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 6: Ph n t ch y u c ̀u hương ₫ ́i tương Slide 146 73 .

Trương Đai Hoc Bach Khoa Tp. sư dung lai linh ki n. quan ly giao tac. database. tao ra mưc trưu tương cua sư hi n thưc h  th ́ng. 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). cac interface va cac class.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 148 74 . c ng ngh  ph n tan. giao di n. 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. 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. HCM Khoa Cöng nghï Thöng tin Chương 7 THIÏT KÏ HƯƠNG ĐÖI TƯƠNG Cac artifacts cền tao ra Cac workers tham gia Qui trònh thiḯt kḯ Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. HĐH. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 147 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. ₫ ̀ng thơi. năm băt cac interface ch nh giưa cac h  th ́ng con.

.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.). trang thai.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 149 Cac artifacts cÝ̀n tao ra trong thiã́t kã́ * 1 * Design Model Desgin System Design Subsystem * * * * * * Desgin Class Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ₫ă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) Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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ư. — 'flow of events' ơ c ́p thi ́t k ́. — cac y u c ̀u c ́p hi n thưc..HCM Use-Case Realization Design Interface Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 150 75 ..

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>>.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 152 76 . k ́t hơp thanh thu c t nh tương ưng.. method trong thi ́t k ́ → method trong hi n thưc. class thi ́t k ́ hi n thưc (hay cung c ́p) 1 interface. quan h  g p. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. nhưng n n t ̀n tai trong m h nh process thay v trong m h nh thi ́t k ́. thương xac ₫ịnh t ̀m vưc cua cac thanh ph ̀n. <<class module>>.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 151 Cac wokers trong hoat ₫éng thiã́t kã́ Architect Use-Case Engineer Component Engineer chịu trach nhi m v ̀ chịu trach nhi m v ̀ chịu trach nhi m v ̀ Desgin Model Use-Case Deployment Architecture Description Realization Model Desgin Design Design class Subsystem Interface Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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 ́.. <<user control>>.Đă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 ́. co th ̀ co 1 s ́ class active.

.HCM Design a Class Design a Subsystem Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 153 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. (₫ươ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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 154 77 . 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Cac class thi ́t k ́ co y nghĩa ki ́n truc như cac class chu ₫ ng...Qui trÉnh thiã́t kã́ Architectural Design Architect Use-Case Engineer Design a Use-Case Component Engineer Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. hi u qua.

. ₫  săn sang.. c ̀n kha năng t nh dư thưa. g ̀m cac kh a canh : cac nut nao li n quan.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 155 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.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.. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 156 78 . ch ́ ₫  ₫ ̀ khang l ̃i. sao lưu dư li u. kha năng v ̀ b  nhơ va c ng su ́t t nh cua nut.. di cư process. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ch ́t lương. ki ̉u n ́i k ́t va ki ̉u giao thưc nao giưa cac nut. nh n dang giao ti ́p cua cac h  th ́ng con. cac t nh ch ́t v ̀ sư n ́i k ́t va giao thưc như băng th ng.. 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.

K ́t qua la 1 t p cac cơ ch ́ thi ́t k ́ t ̉ng quat. cac class khac se ₫ươc nh n dang trong vi c thi ́t k ́ use-case. kha năng n ́i k ́t. quan ly giao tac. ₫ ̀ khang vơi l ̃i. 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. 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. — cac y u c ̀u khac như khơi ₫ ng.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 157 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). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ₫  săn sang. tranh bao hoa.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 158 79 . cac t nh ch ́t an toan dư li u. sư ph n tan & ₫ ̀ng thơi. tranh deadlock. Cac y u c ̀u c ̀n xư ly thương li n quan ₫ ́n : t nh b ̀n vưng. c ́u h nh lai cac nut. throughput cua h  th ́ng — sư ph n tan cua h  th ́ng tr n cac nut. k ́t thuc.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 ́.

x y dưng lươc ₫ ̀ class chưa cac class thi ́t k ́ t m ₫ươc.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 159 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 usecase c ́p ph n t ch tương ưng.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. năm băt cac y u c ̀u c ́p hi n thưc cho use-case. 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. 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. 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. gan nghĩa vu cho cac class thi ́t k ́ t m ₫ươc.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 160 80 . h  th ́ng con va interface cua chung. 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 ́. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. n ́u con thi ́u 1 vai class c ̀n cho vi c thi ́t k ́ use-case ₫ăc bi t. nh n dang cac class thi ́t k ́ n ́i vơi cac class ph n t ch nay.

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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. n n tao lươc ₫ ̀ tr nh tư cho tưng lu ̀ng. tư ₫o phat tri ̉n th m chi ti ́t. 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.bao giưa chu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. dung 'flow of events'.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 162 81 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 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ư.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 161 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 ₫ ̀. n ́u use-case co nhi ̀u lu ̀ng ₫i ̀u khi ̉n khac nhau.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.

: People : LoginForm 1: submit(uname.pswd) : People 1.Lươc ₫é̀ céng tac 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. psswd) Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 1: login(uname.pswd) : Database Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.2: welcome : Database 1.1: succ := Verify(uname.2 [succ = true]: welcome : LoginForm 1. psswd) 1.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 164 82 .1: verify(uname.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 163 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.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 166 83 . hightlight Composed focus compose command Read entry/ convert to rich text entry/ assign ID exit/ fill date on char/ handle character re-fwd cmd / quote / append subject save command send command[ recipents != null ] / parse read command / recover( id ) unhightlight Sending do/ send( repc ) sending done Stored entry/ save into folder logout Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 165 Lươc ₫é̀ hoat ₫éng Cac thanh ph ̀n cua lươc ₫ ̀ hoat ₫ ng : (th du lươc ₫ ̀ hoat ₫ ng 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 Show input for username and password Verify [ psswd invalid ] [ psswd valid ] Reject Welcome Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.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).

Đ ̉ y dung cac prototype giao di n vơi user trong bươc trươc. cac m ́i quan h  ma class tham gia. 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. sư hi n thưc ₫ung cua b ́t ky interface ma class phai cung c ́p. cac phu thu c tơi b ́t ky cơ ch ́ thi ́t k ́ t ̉ng quat nao.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. cac y u c ̀u co li n quan ₫ ́n hi n thưc cua class. cac trang thai cua ₫ ́i tương. c ̀n t p trung thi ́t k ́ class ₫i ̀u khi ̉n..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 168 84 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. cac method cua class (hi n thưc tac vu tương ưng). 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. activeX control..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 167 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 ́. 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. m h nh va c ng vi c ri ng. 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. — 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. cac thu c t nh cua class. thi ́t k ́ class thưc th ̉ thương phu thu c vao c ng ngh  database.

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 ́. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.1 trach nhi m tương ưng 1 hay nhi ̀u tac vu. 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. nhưng ơ ₫ y mơi phat hoa th ng s ́ h nh thưc cac tham s ́. han ch ́ dung ki ̉u cua ng n ngư l p tr nh cho thu c t nh. n ́u co qua nhi ̀u thu c t nh hay thu c t nh qua phưc tap. c ́ găng dung ki ̉u ₫a co.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 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 ́.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 170 85 .1 thu c t nh nay am chỉ 1 hay nhi ̀u thu c t nh cua class thi ́t k ́. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. d ̃n xu ́t use-case c ́p thi ́t k ́ ma class tham gia. 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 ́. cac interface ma class thi ́t k ́ phai cung c ́p. n n dung lươc ₫ ̀ class ri ng ₫ ̉ mi u ta thu c t nh.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 169 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.

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. t nh ch ́t cua vai tro. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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 cung ky sư linh ki n thưc hi n 2 kh u thi ́t k ́ va hi n thưc. Mi u ta cac method dung ng n ngư tư nhi n hay ng n ngư pseudocode.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 171 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. g p ₫ ̉ thay th ́. Xư ly cac y u c ̀u ₫ăc bi t chưa ₫ươc chu y ơ cac bươc trươc. n ́u ng n ngư l p tr nh kh ng h ̃ trơ. class k ́t hơp. tinh ch ́ s ́ ph ̀n tư tham gia. dung m ́i quan h  k ́t hơp. tinh ch ́ hương cua m ́i quan h  k ́t hơp tư lươc ₫ ̀ tương tac. k ́t hơp n-ary.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 ́. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. t n vai tro. ng ta thương t khi ₫ăc ta method trong giai ₫oan thi ́t k ́.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 172 86 .

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 173 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). duy tr interface cua cac h  th ́ng con. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 7: Thi ́t k ́ hương ₫ ́i tương Slide 174 87 . ₫am bao h  th ́ng con la ₫ c l p vơi interface cua no nhi ̀u như co th ̉ co. duy tr n i dung cua cac h  th ́ng con. ₫am bao h  th ́ng con hoan thanh muc ₫ ch. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.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. tao hi n thưc ₫ung cho cac tac vu. ₫am bao h  th ́ng con cung c ́p ₫ươc interfcae ₫ung.

Trương Đai Hoc Bach Khoa Tp. HCM Khoa Cöng nghï Thöng tin

Chương 8

HIÏN THƯC HƯƠNG ĐÖI TƯƠNG
Cac artifacts cền tao ra Cac workers tham gia Qui trònh hiïn thưc

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 175

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.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 176

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)

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 177

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++,...

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 178

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.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 179

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.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 180

90

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 181 Cac workers trong hoat ₫éng hiãn thưc Architect System Integrator Component Engineer chịu trach nhi m v ̀ chịu trach nhi m v ̀ chịu trach nhi m v ̀ Imple.Cac artifacts cÝ̀n tao ra trong thiã́t kã́ * 1 Implementation Model Implementation System * Implementation Subsystem * * * * Component Interface Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 182 91 . Subsystem Interface Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Model Deployment Architecture Description Model Integration Build Plan Component Imple.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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 ̉.HCM Implement a Subsystem Implement a Class Perform Unit Test Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 183 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).Qui trÉnh hiãn thưc Architectural Implementation Architect System Integrator Integrate System Component Engineer Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 184 92 .

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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. build n n dưa tr n build trươc theo cơ ch ́ nơi r ng tư dươi l n.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 186 93 . 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 ́. 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 ̀ usecase). 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. build kh ng n n bao g ̀m qua nhi ̀u thanh ph ̀n mơi hay ₫ươc tinh ch ́. 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 ́. ₫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. t ch hơp m ̃i build trươc khi ki ̉m tra t ch hơp.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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 185 TÈch hơp hã thé́ng (tt) Ưng vơi m ̃i use-case c ̀n hi n thưc.

li n k ́t chung ₫ ̉ tao ra build. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 187 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)..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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 188 94 . 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.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 189 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. 1 file co th ̉ chưa nhi ̀u class. tao source code tư class thi ́t k ́ va cac m ́i quan h  ma class tham gia. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. tranh dung dư li u toan cuc. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. co th ̉ 1 file chỉ chưa 1 class (VC++. tach bi t method chi ́n lươc va phương thưc thưc thi. giư cho m ̃i method ₫u nho : n ́u chi ́m nhi ̀u trang th tach ra nhi ̀u method. nhưng theo qui ₫ịnh cua ng n ngư l p tr nh va nguy n ly ph n chia module.. 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 ́. java). 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. hi n thưc cac tac vu cua class thi ́t k ́ dươi dang cac method..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 190 95 . ₫am bao thanh ph ̀n cung c ́p cung interface như class thi ́t k ́.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.

tranh dung no ₫ ̉ ti ́p tuc truy xu ́t gian ti ́p ₫ ́n cac ₫ ́i tương khac.. l p tai li u cho cac class va cac method : muc ₫ ch. xu ́t ban ₫ăc ta hương d ̃n cach sư dung class.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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 191 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. sư dung cac hương d ̃n va qui tăc l p tr nh : style.. 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. sư dung cung t n cho cac giai ₫oan khac nhau : ph n t ch.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 192 96 ... chưc năng. hi n thưc. 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. lưa chon t n ky lương : th ̉ hi n ₫ung vai tro. thi ́t k ́. nghĩa vu. ph n bi t tac vu public va private.. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. che d ́u c ́u truc dư li u : kh ng xu ́t ra b n ngoai. tao cho method d ̃ ₫oc : t n bi ́n va ki ̉u co y nghĩa ro rang.

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. ki ̉m tra tai. ki ̉m tra kha năng. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ki ̉m tra c ́u truc (white-box testing) : ki ̉m tra sư hi n thưc b n trong ₫ơn vị. trang thai băt ₫ ̀u. 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. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 193 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. ki ̉m tra vi c dung b  nhơ. S ́ lương t ̉ hơp b  ba {gia trị dư li u nh p. Cung con 1 s ́ loai ki ̉m tra ₫ơn vị khac như : ki ̉m tra t nh hi u qua.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 194 97 . 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.

cac path d ̃ g y sai. ki ̉m tra moi path c ̀n quan t m : cac path chay thương nh ́t. HCM Khoa Cöng nghï Thöng tin Chương 9 KIÏM THƯ Cac artifacts cền tao ra Cac workers tham gia Qui trònh kiï̉m thư Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. cac path co rui ro cao. cac path t ₫ươc bi ́t v ̀ giai thu t nh ́t.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9: Ki ̉m thư Slide 196 98 .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).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 8: Hi n thưc hương ₫ ́i tương Slide 195 Trương Đai Hoc Bach Khoa Tp.

trang thai l ̃i Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. tai nguy n.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 197 Cac artifacts trong kiã̉m thư Test Model 1 Test System * Test Case Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.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.HCM * Test Procedure * Test Component Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 198 99 . status. cac code. 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. lịch Defect : l ̃i Evaluate Test : phu cac testcase.

HCM Implement Test Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 200 100 .Cac workers trong kiã̉m thư Test Engineer Component Integration Engineer Tester System Tester chịu trach nhi m v ̀ chịu trach nhi m v ̀ chịu trach nhi m v ̀ Test Test Model Test Plan Test case Test Test Procedure Evaluation Component Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Test defect Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 199 Qui trÉnh kiã̉m thư Test Engineer Plan test Design test Evaluate test Integration tester Perform Integration Test Perform System Test System Tester Component Engineer Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

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. 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. khi nao thư va ₫anh gia k ́t qua ki ̉m thư như th ́ nao. n dang va c ́u truc cac thu tuc ki ̉m thư. Cu th ̉ : thi thi thi nh ́t k ́ cac test case t ch hơp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 202 101 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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 ́. thưc hi n như th ́ nao.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 201 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ư cac tai nguy n v ̀ h  th ́ng hay tai nguy n v ̀ ngươi. ́t k ́ cac test case h  th ́ng. ươc lương cac y u c ̀u cua n ̉ lưc ki ̉m thư. ́t k ́ cac test case "regression". lăp lịch cho n ̉ lưc ki ̉m thư. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

chu y ́u la cac lươc ₫ ̀ tương tac va tr nh tư. mưc tai. thương dưa vao d ̃n xu ́t use-case ơ c ́p thi ́t k ́. n ́u gi ́ng th Ok. 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. co anh hương vơi nhau n ́u ₫ươc thưc hi n song song. 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 ́. sau khi ki ̉m thư. ₫ ̉ 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.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. li n quan tơi nhi ̀u process.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 203 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. s ́ actor. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. co th ̉ ₫ươc thưc hi n song song. 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. Mön 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 Khoa CNTT ĐH Bach Khoa Tp. k ch thươc database.HCM Chương 9 : Ki ̉m thư Slide 204 102 . n ́u khac th co l ̃i.

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). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 205 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 ̉). 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ư.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 206 103 . 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ư. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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).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.

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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 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 ̉. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Ki ̉m tra trong hi u su ́t (Performance testing).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. th ng bao cac l ̃i tơi ky sư linh ki n li n quan. 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). So sanh k ́t qua co ₫ươc vơi k ́t qua ky vong.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 207 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ư.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 208 104 . Ki ̉m tra trong m i trương căng thăng (Stress Testing).

Tach cac b  ph n co ve ₫at ₫  tin c y.) và cú pháp của các phần tử cấu thành ứng dụng. Cu ́i cung l p tai li u v ̀ mưc ₫  hoan thanh ki ̉m thư. ₫  tin c y.. 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.Đ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ư. từ danh riêng. ta dễ dàng sửa chúng. ta sẽ thử chạy nó ₫ể xác ₫ịnh xem nó giải quyết ₫úng yêu cầu không. ₫  tin c y : xu hương l ̃i phat hi n so vơi xư hương test case thanh c ng. cac c ng vi c ₫ ̀ nghị (ta goi la ₫ăc ta ₫anh gia ki ̉m thư).' before type 'double‘ If (delta >= 0) // sai từ vựng vì If phải viết thường //error C2065: 'If' : undeclared identifier Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. // thiếu dấu . 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.' before identifier 'item' int a double b. con cac b  ph n chưa ₫at phai ₫ươc xem xet va ki ̉m thư lai. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. Ví dụ : ItemRec item. // sẽ báo sai nếu kiểu ItemRec chưa ₫ược ₫ịnh nghĩa // error C2146: syntax error : missing '.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 210 105 . 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 209 Tổng quát về hoạt ₫ộng debug ứng dụng Sau khi viết code cho ứng dụng xong. các lỗi về từ vựng (tên các phần tử. Dưa tr n xu hương l ̃i. ở trước double // error C2144: syntax error : missing '. Thường sau khi ₫ược VC++ thông báo về các lỗi này. Thường ứng dụng chứa nhiều lỗi sai thuộc 1 trong 3 loại sau : 1.

Ứng dụng sẽ chạy theo giải thuật ₫ược miêu tả. … b = 3.0. 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). hiển thị giao diện & chờ người dùng ra lệnh 2. // cũng sẽ làm b = 9. 22b Giảm giá trị tài khoản trong bộ nhớ ₫i 500USD. các lỗi run-time (giải thuật. 23a Ghi lại giá trị mới. Người dùng ra lệnh nạp vào tài khoản A số tiền 700USD → xử lý : 21a Đọc tài khoản A vào bộ nhớ... double b. 22a Tăng giá trị tài khoản trong bộ nhớ lên 700USD. cộng cụ này ₫ược gọi là 'Debug'. a[50] = 9. Người dùng ra lệnh rút tiền từ tài khoản A 500USD → xử lý : 21b Đọc tài khoản A vào bộ nhớ. ta phải tự ₫ánh giá tính ₫úng/sai về giải thuật. 23b Ghi lại giá trị mới. nhưng việc tìm lỗi giải thuật thường rất khó. 3.. 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. hiển thị giao diện & chờ người dùng ra lệnh 2.Tổng quát về hoạt ₫ộng debug ứng dụng 2. 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. Quay về bước 1 Tài khoản A 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).1416.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 211 Tổng quát về hoạt ₫ộng debug ứng dụng 3. Thí dụ 2 ứng dụng truy xuất tài khoản A ₫ồng thời : 1. Quay về bước 1 1. Để giúp ₫ở người lập trình dễ dàng tìm ra các lỗi giải thuật. Ví dụ : double a[50].HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 212 106 .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] Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. tràn bộ nhớ. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.).

ứ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. lịch sử gọi hàm trong call strack. 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. 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). 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).Tổng quát về tiện ích debug tích hợp trong VC++ Trong quá trình debug. 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úc này ứng dụng sẽ chuyển sang chế ₫ộ Running. ứ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.… ₫iều khiển việc thi hành tiếp theo của ứng dụng. Ở chế ₫ộ này. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.program counter ₫ể nói về lệnh này.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Slide 214 107 . thêm/bớt các ₫iều kiện dừng. ta dùng thuật ngữ PC . nó chuyển qua chế ₫ộ Running. Do tính lịch sử. Mỗi khi ứng dụng ₫ược chạy tiếp. lúc này ứng dụng sẽ chuyển về chế ₫ộ Pause. Trong quá trình debug.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 213 Cửa sổ Debug Cửa sổ Registers Cửa sổ Memory Cửa sổ CallStack Cửa sổ Variable Cửa sổ Watch Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

Xem nội dung của biến trong cửa sổ “Variable”. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. nó sẽ hiển thị lệnh chạy kế tiếp .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. 1 cửa sổ nhỏ chứa giá trị của biến ₫ó sẽ ₫ược hiển thị ₫ể người debug xem xét. người debug có thể : chọn menu View. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ấn phải chuột trên gáy cửa sổ bất kỳ rồi chọn mục “Call Stack”. 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ể : chọn menu Debug. 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ó. 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).Show Next Statement (thường khi ứng dụng dừng lại.Debug Windows. Để hiệu chỉnh giá trị của 1 biến nào ₫ó (do ₫ã bị sai.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 216 108 .Call Stack.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 215 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ể : dời chuột ₫ến tên biến trong cửa sổ code. Để xem vị trí PC hiện hành (lệnh sắp thực hiện 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).

o chọn menu Debug.Step Into ₫ể chạy tiếp 1 lệnh rồi dừng lại (Pause).Go ₫ể bắt ₫ầu chạy ứng dụng. người debug có thể : o chọn menu Debug.Go ₫ể chạy tiếp từ vị trí PC hiện hành. o chọn menu Debug. ứ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. 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ị. Muốn thiết lập ₫iểm dừng mới.Breakpoints ₫ể hiển thị cửa sổ Breakpoints. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 217 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. 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. Đây là lệnh cho phép thực hiện từng lệnh theo mức vĩ mô. 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).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). chọn thông báo cần dừng. Muốn thiết lập ₫iểm dừng mới dựa trên thông báo (message) của Windows. o chọn menu Debug. nhập biểu thức cần tính toán (biến cần quan tâm). o chọn menu Debug. chọn tab “Location”. chọn hàm xử lý.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 218 109 . có thể xóa từng ₫iểm dừng bằng cách chọn nó rồi ấn button “Remove”.Step Over ₫ể chạy tiếp 1 lệnh rồi dừng lại (Pause). chọn tab “Message”. 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. ứng dụng chỉ dừng lại khi gặp ₫iều kiện dừng nào ₫ó ₫ã ₫ược thiết lập. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. có thể xóa hết chúng bằng cách chọn button “Remove All”.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). chọn tab “Data”. Đây là lệnh cho phép thực hiện từng lệnh theo mức vi mô.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). ta chọn menu Edit. 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. 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.

Break ₫ể dừng ₫ột ngột việc chạy ứng dụng.Các lệnh ₫iều khiển khác Ngoài ra khi ứng dụng ở trạng thái 'Pause'.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 220 110 . sẽ không có lệnh nào ₫ược dánh dấu cả. Nếu ứng dụng ₫ang bị 'block' chờ biến cố I/O. người debug có thể thực hiện các lệnh sau : chọn menu Debug. lệnh ₫ang thực hiện sẽ ₫ược ₫ánh dấu ₫ể ta dễ theo dõi.Stop Debugging ₫ể kết thúc việc chạy ứng dụng.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 9 : Ki ̉m thư Slide 219 Trường Đại Học Bách Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. người debug có thể thực hiện các lệnh sau : chọn menu Debug. Khi ứng dụng ở trạng thái ‘Running'. Chức năng này giúp ta biết ứng dụng ₫ang bị 'loop' ở ₫oạn lệnh nào. 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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

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ế. 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. thay ₫ổi (VD: ₫ặc tính thừa kế. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 222 111 . Phụ thuộc vào giải thuật: khi hệ thống có nhiều giải pháp. nhất là lập trình hướng ₫ối tượng. 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. nhiều mức ₫ộ xử lý cho cùng một vấn ₫ề. 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.Giới thiệu Thiết kế phần mềm là một vấn ₫ề rất khó khăn. thay ₫ổi hệ thống. các component gọi lẫn nhau nhiều… Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 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 ₫ó. kiểm tra…). 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. nhất là khi phần mềm lớn.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 221 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. VD: lạm dụng thừa kế trong lập trình hướng ₫ối tượng. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Không tổng quát hóa khi lập trình. 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. ₫a hình…).

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ế. Giúp giải quyết những vấn ₫ề thiết kế thường gặp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 224 112 . → tăng ₫ộ tin cậy. tiết kiệm nguồn lực… Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 223 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á. Hình thành kho tri thức. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. nhất là lập trình hướng ₫ối tượng. thay ₫ổi. Chú trọng việc giúp cho bản thiết kế có tính uyển chuyển. ngữ vựng trong giao tiếp giữa những người làm phần mềm. 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. dễ nâng cấp. Giúp người tìm hiểu nắm vững hơn ₫ặc ₫iểm ngôn ngữ lập trình.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. mối quan hệ này là tĩnh (xác ₫ịnh tại thời ₫iểm dịch). che dấu giải thuật. Behavioral — Che dấu hiện thực của ₫ối tượng. organization patterns. Object patterns dựa trên mối quan hệ giữa các ₫ối tượng. design patterns. hỗ trợ việc thay ₫ổi cấu hình ₫ối tượng một cách linh ₫ộng. ràng buộc muộn (lower coupling) và cung cấp các cơ chế khác ₫ể thừa kế. hạn chế sự phụ thuộc platform.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 225 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). Creational — Khắc phục các vấn ₫ề khởi tạo ₫ối tượng.Phân loại software patterns Có nhiều loại Software patterns: analysis patterns. Class patterns dựa trên mối quan hệ thừa kế giữa các lớp. do ₫ó có thể thay ₫ổi ở thời ₫iểm chạy. 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ế). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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…). do ₫ó class patterns thích hợp cho hệ thống không cần thay ₫ổi ₫ộng trong thời gian chạy.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 226 113 .

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.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. Các ngữ cảnh nên áp dụng pattern. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ₫ối tượng) trong pattern và mối quan hệ giữa chúng. Hướng chương trình ₫ến ₫ặc ₫iểm: program to an interface. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 228 114 . 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. 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. not an implementation. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Xác ₫ịnh interface và hiện thực (implementation) của ₫ối tượng.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 227 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.

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). 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 ₫ó. 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. Proxy.. Hiện thực class Line. Facade. Ví dụ : chương trình drawing editor xử lý các ₫ối tượng ₫ồ họa Line. Mẫu Adapter giúp chúng ta giải quyết vấn ₫ề này. 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. chúng ta sẽ tìm hiểu các mẫu: Adapter. Text.. Polygon.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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Composite. Trong các slide tiếp theo. Flyweight. Decorator.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 230 115 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 229 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Thí dụ về mẫu Adapter dùng object Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 232 116 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 231 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.

Adapter (TextShape) : “chuyển” interface Adaptee sang interface Target. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Adaptee (TextView) : ₫ịnh nghĩa interface ₫ã có sẵn cần “chuyển” sang interface Target.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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 234 117 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 233 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.

. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Trong trường hợp này. Object Adapter sẽ chuyển interface của chỉ lớp cha.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 235 Composite Mục tiêu : tạo quan hệ thứ bậc bao gộp giữa các ₫ối tượ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 ₫ó. Mẫu Composite cung cấp giải pháp cho yêu cầu 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ử. Ví dụ : chương trình drawing editor vừa có các ₫ối tượng ₫ơn như ký tự. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. nâng cấp. hàng (gồm nhiều từ). 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).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. (₫ố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. 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.. ₫iểm ảnh vừa có các ₫ối tượng phức như từ (gồm nhiều ký tự). họ thường tác ₫ộng như nhau lên một từ và một ký tự.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 236 118 . nhóm các phần tử nhỏ hơn…Dưới góc ₫ộ người sử dụng.

Draw() add g to list of graphics Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 237 Sơ ₫ồ cấu trúc của mẫu Composite Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 238 119 .Thí dụ về mẫu Composite Graphic Draw() Add(Graphic) Remove(Graphic) GetChild(int) graphics Line Draw() Text Draw() Rectangle Draw() Picture Draw() Add(Graphic) Remove(Graphic) GetChild(int) for all g in graphics g.

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. chương trình text editor… Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. chương trình giao diện GUI (window là ₫ối tượng phức. Client : Sử dụng các component thông qua interface Component Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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…).Các phần tử tham gia 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. button là ₫ối tượng ₫ơn).bị bao gộp. Composite : Định nghĩa tác vụ cho những component bao gộp những component khác.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 239 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 . chương trình muốn ₫ối xử các phần tử bao gộp và bị bao gộp như nhau.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 240 120 . Leaf : Định nghĩa tác vụ cho cho những component cơ bản.

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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 242 121 . 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. Trong thời gian trì hoãn.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 ₫ó. Ví dụ các KernelProxies cung cấp truy xuất ₫ến Kernel của hệ ₫iều hành. 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. (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). proxy ₫óng vai trò thay thế ₫ối tượng. do ₫ó nên trì hoãn thời ₫iểm khởi tạo thực sự các ₫ối tượng này. Đối tượng cần ₫ược bảo mật khỏi tương tác trực tiếp với client. Đối tượng thay thế gọi là Proxy. Chương trình muốn truy xuất một ₫ối tượng ở không gian ₫ịa chỉ khác. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. proxy thực hiện việc load persistent object trong lần tham khảo ₫ầu tiên… Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Client chỉ tác ₫ộng ₫ược lên Proxy. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 241 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. Proxy chuyển yêu cầu Client xuống ₫ối tượng thực hiện yêu cầu. JINI). 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. Proxy thay thế ₫ối tượng ở máy remote. Mục ₫ích ₫ể trì hoãn thời ₫iểm tạo ₫ối tượng lớn. Proxy ₫óng vai trò ₫ối tượng kiểm soát. Ví dụ proxy kiểm tra số tham khảo ₫ến ₫ối tượng.

Thí dụ về mẫu Proxy
DocumentEditor Graphic Draw() GetExtent() Store() Load()

Image Draw() GetExtent() Store() Load() imageImp extent image

ImageProxy Draw() GetExtent() Store() Load() filename extent

if (image==0) image = LoadImage(filename); else image->Draw(); if (image==0) return extent; else return image->GetExtent();

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 10 : Các mẫu cấu trúc

Slide 243

Sơ ₫ồ cấu trúc của mẫu Proxy
Client Subject Request() ...

RealSubject Request() ... realSubject

Proxy Request() ...

// prolog code realSubject->Request(); // epilog code

...

...

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 10 : Các mẫu cấu trúc

Slide 244

122

Các phần tử tham gia
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.
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 10 : Các mẫu cấu trúc

Slide 245

Các phần tử tham gia
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ơ ₫ồ:

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 10 : Các mẫu cấu trúc

Slide 246

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 …

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 10 : Các mẫu cấu trúc

Slide 247

Mẫu Decorator
Mục tiêu : thêm ₫ộng trách nhiệm cho ₫ối tượng. Nhu cầu áp dụ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 component

aScrollDecorator component aTextView component

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 10 : Các mẫu cấu trúc

Slide 248

124

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 250 125 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 249 Sơ ₫ồ cấu trúc của mẫu Decorator Component Operation() component ConcreteComponent Operation() Decorator Operation() component->Operation().Decorator VisualComponent Draw() component TextView Draw() Decorator Draw() component->Draw(). DrawBorder(). AddedBehavior(). ScrollDecorator Draw() ScrollTo() scrollPosition BorderDecorator Draw() DrawBorder() borderWidth Decorator::Draw(). ConcreteDecoratorA Operation() addedState ConcreteDecoratorB Operation() AddedBehavior() addedState Decorator::Operation().

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 252 126 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. ScrollDecorator) thêm trách nhiệm cho thành phần gốc.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 251 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. 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).Các phần tử tham gia 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. ConcreteDecorator (BorderDecorator. tích lũy thêm các trách nhiệm của ₫ối tượ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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

Nhu cầu áp dụng : 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.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..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 253 Thí dụ về cấu trúc Facade Compiler Compile() Stream Sc a n n er Pa rs e r BytecodeStream Pro g r a m N o d e B u ff e r Toke n Sy mb ol Pro g r a m N 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 nerator Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM R ISCCodeGene rator V a ri a bl e N o de Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 254 127 . 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. BytecodeStream. 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. parser. Parser. ta có thể viết 1 ứng dụng gọi dịch vụ của từng class ₫ể duyệt token. ProgramNodeBuilder. ứ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. ProgramNode. Tuy nhiên làm như trên sẽ rất khó và dễ gây ra lỗi. Để dịch source code. tạo code ₫ối tượng. 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. nó cung cấp 1 hàm Compile (file). xây dựng cây cú pháp.

nhờ các ₫ối tượng liên quan thực hiêện request. không có tham khảo ₫ến Facade..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 255 Các phần tử tham gia Facade (Compiler) biết class nào liên quan ₫ến request xác ₫ịnh.. không cần biết Facade.Sơ ₫ồ cấu trúc của mẫu Facade Facade Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Parser. xử lý công việc ₫ược nhờ từ ₫ối tượng Facade.) hiện thực các chức năng của hệ thống con. subsystem classes (Scanner.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 256 128 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

Trạng thái trong ₫ược chứa trong flyweight.. ta tạo riêng 1 ₫ối tượng mới cho ký tự ₫ó thì rất không hiệu quả.. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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ự. 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..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 258 129 . Nhu cầu áp dụng : thiết kế hướng ₫ối tượng thường có nhiều ₫iểm lợi. . muốn tạo thêm lớp ngăn cách hệ thống con với client. Trạng thái ngoài phụ thuộc và thay ₫ổi theo ngữ cảnh. công thức. hình. ₫ộc lập với ngữ cảnh sử dụng (code ký tự.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 257 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ỏ. 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 ₫ó. 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ự.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. 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ả.. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Mẫu Flyweight rất thích hợp ₫ể giải quyết vấn ₫ề dùng chung ký tự.. nó không thể ₫ược chứa trong flyweight.

Contex t) Character Draw(Context) Intersects(Point.Thí dụ về mẫu Flyweight Glyph Draw(Context) Intersects(Point.Contex t) children Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. } Flyweight Operation(extrinsicState) ConcreteFlyweight Operation(extrinsicState ) intrinsicState Client Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. add it to pool of flyweights.HCM UnsharedConcreteFlyweight Operation(extrinsicState) allState Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 260 130 .Context) Row children Draw(Context) Intersects(Point.Context ) char c Column Draw(Context) Intersects(Point.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 259 Sơ ₫ồ cấu trúc của mẫu Flyweight FlyweightFactory GetFlyweight(key) if (flyweight(key) exists return existing flyweight else { create new flyweight. return the new flyweight.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 262 131 . ứng dụng không phụ thuộc vào tên nhận dạng ₫ối tượng. Client chứa tham khảo ₫ến flyweight và nhờ khi cần Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Các phần tử tham gia 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. 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ỏ.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 10 : Các mẫu cấu trúc Slide 261 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. FlyweightFactory tạo và quản lý các ₫ối tượng Flyweight. phần lớn trạng thái ₫ối tượng có thể ₫ể bên ngoài. giá bộ nhớ cao vì phải chứa số lượng lớn ₫ối tượng. UnsharedConcreteFlyweight (Character) hiện thực interface Flyweight thành các ₫ối tượng không dùng chung. ConcreteFlyweight (Character) hiện thực interface Flyweight thành các ₫ối tượng dùng chung.

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. 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.Trường Đại Học Bách Khoa Tp. quản lý và sử dụng ₫ố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. ai tạo ra ₫ối tượng ₫ó.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 263 Creational Patterns Creational design patterns giúp xây dựng hệ thống linh ₫ộng về mặt khởi tạo. HCM Khoa Công nghệ Thông tin 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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 264 132 . 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.

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:

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 11 : Các mẫu Creational

Slide 265

Ví dụ về quá trình khởi tạo ₫ối tượng
MapSite Enter()

sides
Maze AddRoom() RoomNo()

Room Enter() SetSide() GetSide() roomNumber

Wall Enter()

Door Enter()

rooms

isOpen

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 11 : Các mẫu Creational

Slide 266

133

Ví dụ về quá trình khởi tạo ₫ối tượng
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; };
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 11 : Các mẫu Creational

Slide 267

Ví dụ về quá trình khởi tạo ₫ối tượng
Class Wall có thể ₫ược hiện thực trong C++ như sau : class Wall : public MapSite { public: Wall (); virtual void Enter(); }; Class Door có thể hiện thực trong C++ như sau : class Door : public MapSite { public: Door (Room* = 0, Room*=0); virtual void Enter(); Room* OtherSideFrom (Room*); private: Room* m_room1, m_room2; bool m_isOpen; };
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 11 : Các mẫu Creational

Slide 268

134

Ví dụ về quá trình khởi tạo ₫ối tượng
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 :

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM

Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 11 : Các mẫu Creational

Slide 269

Ví dụ về quá trình khởi tạo ₫ối tượng
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.
Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML
Chương 11 : Các mẫu Creational

Slide 270

135

dễ bổ sung các họ ₫ối tượng mới. 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. 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. Đây là hướng tiếp cận của mẫu Abstract Factory. 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ộ. door. wall. door theo ₫ặc thù của ứng dụng. dễ chuyển ₫ổi giữa các họ ₫ối tượng. 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. chẳng hạn: chương trình có khả năng chạy trên nhiều platform. 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. Mỗi platform có một họ các lớp giao diện. CreateMaze ₫ược truyền các ₫ối tượng room. Khi ₫ó nếu muốn thay ₫ổi ₫ối tượng trong CreateMaze. Trong các slide sau chúng ta sẽ tìm hiểu các mẫu phần mềm này. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ta chỉ cần truyền vào các ₫ối tượng khác.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 272 136 . Đây là hướng tiếp cận của mẫu Builder. 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.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. Khi ₫ó nếu muốn thay ₫ổi maze thì chỉ cần truyền một ₫ố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. 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. trong ₫ó override các phương thức khởi tạo ₫ối tượng ở trên. wall có khả năng sinh ra ₫ối tượng tương tự chúng (clone).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 271 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. Đây là hướng tiếp cận của mẫu Factory Method.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 273 Thí dụ về mẫu AbstractFactory WidgetFactory CreateScrollbar() CreateWindow() Window Client PMWindow MotifWindow MotifWidgetFactory CreateScrollbar() CreateWindow() PMWidgetFactory CreateScrollbar() CreateWindow() Scrollbar PMScrollbar MotifScrollbar Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Hướng tiếp cận trên là của mẫu Abstract Factory.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 274 137 . gọi là AbstractProduct. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. gọi là AbstractFactory. 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. Cung cấp interface ₫ể khởi tạo các ₫ối tượng kiểu AbstractProduct. Để khởi tạo một ₫ối tượng cụ thể.Ví dụ về quá trình khởi tạo ₫ối tượng 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.

AbstractProduct : lớp Abstract. Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Sơ ₫ồ cấu trúc của mẫu AbstractFactory AbstractFactory CreateProductA() CreateProductB() AbstractProductA Client ProductA2 ProductA1 ConcreteFactory1 CreateProductA() CreateProductB() ConcreteFactory2 CreateProductA() CreateProductB() AbstractProductB ProductB2 ProductB1 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. thừa kế lớp Abstract Product. 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ể. các nhóm ₫ối tượng do các ConcreteFactory sinh ra tương ₫ồng nhau về vai trò. 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. mỗi ConcreteFactory sinh ra một nhóm ₫ối tượng.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 275 Các phần tử tham gia AbstractFactory : ₫ịnh nghĩa interface cho việc khởi tạo ₫ối tượng.HCM Slide 276 138 . Hệ thống có nhiều ConcreteFactory. ₫ịnh nghĩa interface cho một kiểu lớp (kiểu lớp button.

Client thông qua interface AbstractFactory ₫ể yêu cầu ₫ối tượng ConcreteFactory sinh ra các ₫ối tượng mong muốn. Quá trình tương tác giữa các phần tử : Tại thời ₫iểm compile.Các phần tử tham gia Client : chương trình cần tạo các ₫ối tượng. Tại thời ₫iểm run-time. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 277 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 278 139 . 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. 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. Client chỉ sử dụng các interface AbstractFactory và AbstractProduct. Client nắm giữ pointer ₫ến phần tử của lớp AbstractFactory (giả sử là _factory). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

} virtual Room* MakeRoom(int n) const { return new Room(n). Room* r2) const { return new Door(r1. r2). r1->SetSide(North. door. Phương thức CreateMaze ₫ược truyền một ₫ối tượng kiểu MazeFactory.MakeDoor(r1. aMaze->AddRoom(r2). } virtual Door* MakeDoor(Room* r1. Room* r2 = factory. virtual Maze* MakeMaze() const { return new Maze.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 279 Ví dụ áp dụng Lớp MazeGame ₫óng vai trò là Client sử dụng mẫu Abstract Factory. wall.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 280 140 .} virtual Wall* MakeWall() const { return new Wall. MazeFactory không sử dụng Constructor mà cung cấp các method Make ₫ể tạo ra các ₫ối tượng.MakeWall()). room.MakeRoom (2). } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. r2).MakeRoom (1).MakeMaze(). … return aMaze. MazeFactory có thể ₫ược hiện thực trong C++ như sau: class MazeFactory { public: MazeFactory(). } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. wall. factory.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. CreateMaze sử dụng ₫ối tượng này ₫ể sinh ra các ₫ối tượng cần thiết. Room* r1 = factory. Door* aDoor = factory. aMaze->AddRoom(r1). door khác. CreateMaze có thể ₫ược hiện thực trong C++ như sau: Maze* MazeGame::CreateMaze (MazeFactory& factory) { Maze* aMaze = factory. Các lớp con thừa kế có thể override các phương thức này ₫ể sinh ra các maze. room.

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). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. do ₫ó sẽ ảnh hưởng ₫ến hầu như tất cả các lớp khác.Ví dụ áp dụng Để thay ₫ổi ₫ối tượng tạo ra.CreateMaze(factory).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 281 Ví dụ áp dụng Khi áp dụng mẫu Abstract Factory. việc thêm một kiểu maze chỉ là thêm một họ các lớp. 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. BombedMazeFactory factory. 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. miễn là ₫ối tượng này thuộc kiểu MazeFactory.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 282 141 . game. ta chỉ việc truyền một ₫ối tượng factory khác. } Trong chương trình Game chỉ cần thực hiện ₫oạn code: MazeGame game. không ảnh hưởng ₫ến code chương trình ₫ã có. 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. 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. VD ₫ể tạo một maze mà trong room có thể có bom.

docs. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. MyDocument MyApplication CreateDocument() return new MyDocument. Factory Method tạo một phương thức ảo. doc->Open(). các lớp con sẽ override phương thức này ₫ể khởi tạo ₫ối tượng. Nhu cầu áp dụng : 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 283 Sơ ₫ồ thí dụ Document Open() Close() Save() Revert() docs Application CreateDocument() NewDocument() OpenDocument() Document* doc=CreateDocument().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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 284 142 . 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Add(doc). 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.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ConcreteProduct ConcreteCreator FactoryMethod() return new ConcreteProduct.Sơ ₫ồ cấu trúc của mẫu Factory method Product docs Creator FactoryMethod() AnOperation() . sản phẩm trả về là ₫ối tượng kiểu Product. override factory method ₫ể trả về ₫ối tượng ConcreteProduct.. Product = FactoryMethod(). Creator : ₫ịnh nghĩa factory method.. . ConcreteCreator : thừa kế lớp Creator.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 286 143 .. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. Hiện thực interface Product.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 285 Các phần tử tham gia 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.

r2). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. // factory methods: virtual Maze* MakeMaze() const { return new Maze. } virtual Room* MakeRoom(int n) const { return new Room(n). cung cấp các factory method ₫ể tạo các ₫ối tượng: class MazeGame { public: Maze* CreateMaze(). 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 288 144 . } }. } virtual Wall* MakeWall() const { return new Wall. Room* r2) const { return new Door(r1.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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. } virtual Door* MakeDoor(Room* r1. 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ể.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 287 Ví dụ áp dụng Lớp MazeGame ₫óng vai trò là Creator.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 290 145 . r2). aMaze->AddRoom(r1).Ví dụ áp dụng Method CreateMaze có thể ₫ược ₫ịnh nghĩa lại như sau: Maze* MazeGame::CreateMaze () { Maze* aMaze = MakeMaze(). r1->SetSide(North. MakeWall()). return aMaze. Room* r1 = MakeRoom(1). //……. r2->SetSide(North. } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. virtual Wall* MakeWall() const { return new BombedWall. aMaze->AddRoom(r2). } }. trong lớp này override factory method tạo ra ₫ối tượng muốn thay ₫ổi. //…….HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 289 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. } virtual Room* MakeRoom(int n) const { return new RoomWithABomb(n). VD: class BombedMazeGame : public MazeGame { public: BombedMazeGame(). Door* theDoor = MakeDoor(r1. MakeWall()). Room* r2 = MakeRoom(2).

Chương 11 : Các mẫu Creational Draw(Position) Clone() return copy of self.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.HCM Staff MusicalNote HalfNote Draw(Position) Clone() return copy of self. while (user drag mouse) { p->Draw(new position). } insert p onto drawing Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Giải pháp ₫ề nghị : + Framework cung cấp interface ₫ể copy một ₫ối tượng. Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Slide 292 146 . 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. + Ứng dụng phát triển từ Framework hay component tạo ra ₫ối tượng mong muốn. interface này sẽ ₫ược các lớp concrete cần sinh ra ₫ối tượng implement. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Nhu cầu áp dụng : 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 291 Ví dụ về mẫu Prototype Tool Manipulate() MusicsalNote Draw(Position) Clone() prototype RotateTool Manipulate() GraphicTool Manipulate() Draw(Position) Clone() WholeNote p = protoype->Clone(). Đây chính là phương pháp của mẫu Prototype.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 294 147 .Sơ ₫ồ cấu trúc của mẫu Prototype Client Operation() prototype Prototype Clone() p = protoype->Clone(). 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ó. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 293 Các phần tử tham gia 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ó. return copy of shelf. ConcretePrototype1 Clone() ConcretePrototype2 Clone() return copy of self.

Java. C++ có phương thức copy. SmallTalk. Nếu số lượng prototype trong ứng dụng không cố ₫ịnh. ₫ể ý vấn ₫ề tham khảo vòng. nên quản lý chúng bằng một ₫ối tượng prototype manager.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 296 148 . Đố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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. hoặc khi các ₫ối tượng của cùng một class có ít ₫iểm khác biệt. Eiffel cung cấp phương thức clone().HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 295 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).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. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Khi hiện thực deep copy. Tất cả những phương thức trên ₫ều mặc ₫ịnh thực hiện shallow copy. Có thể copy hoàn toàn (deep copy) hay share biến (shallow copy). 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.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 298 149 . } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ₫ố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. Wall* _wallPrototype. _wallPrototype = w. Door* _doorPrototype. Định nghĩa lớp MazePrototypeFactory thừa kế lớp MazeFactory. _doorPrototype = d. Door*). Wall* w. Door* d ) { _mazePrototype = m.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 297 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. MazePrototypeFactory có thể ₫ược hiện thực trong C++ như sau: class MazePrototypeFactory : public MazeFactory{ public: MazePrototypeFactory(Maze*. } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. Room* _roomPrototype. Wall*. .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.// Các method khởi tạo các phần tử của maze private: Maze* _mazePrototype. virtual Maze* MakeMaze() const. _roomPrototype = r.. Room* r. Room*.

_room2 = other. Room* _room2. Room *r2) const { Door* door = _doorPrototype->Clone(). virtual Door* Clone() const. return door. }.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 299 Ví dụ áp dụng Các phương thức khởi tạo wall.Ví dụ áp dụng Các lớp Door. r2). door ₫ều clone prototype có sẵn và set các giá trị nếu cần: Wall* MazePrototypeFactory::MakeWall () const { return _wallPrototype->Clone()._room1. door->Initialize(r1. } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Door::Door (const Door& other) { _room1 = other. } void Door::Initialize (Room* r1._room2.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 300 150 . } Door* Door::Clone () const { return new Door(*this). Room*). Door(const Door&). } Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Room* r2) { _room1 = r1. 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(). Wall. } Door* MazePrototypeFactory::MakeDoor (Room* r1. room. virtual void Initialize(Room*. _room2 = r2. private: Room* _room1.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 301 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ta chỉ cần cung cấp các factory cho constructor của MazePrototypeFactory : MazeGame game.Ví dụ áp dụng Để thay ₫ổi maze cần tạo. Đây chính là phương pháp của mẫu Builder. new RoomWithABomb. Tex. MazePrototypeFactory bombedMazeFactory( new Maze. + Mỗi ₫ịnh dạng cần chuyển tới sẽ ₫ược ₫ảm trách bởi 1 subclass của class TextConverter.. new Door ). 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 ₫ó. hay sang 1 ₫iều khiển soạn thảo text.CreateMaze(bombedMazeFactory). Giải pháp ₫ề nghị : + ₫ịnh nghĩa class TextConverter chứa các tác vụ chuyển ₫ổi token cơ bản.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 302 151 . Nhu cầu áp dụng : 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ô. Maze* maze = game. new BombedWall..

Ví dụ về mẫu Builder RTFReader ParseRTF() builders builder TextConverter ConvertCharacter() ConvertFont() ConvertParagraph() while (t=getnexttoken()) { switch (t. } } ASCIIConverter ConvertCharacter() GetASCIIText() TeXConverter ConvertCharacter() ConvertFont() ConvertParagraph() GetTeXText() TextWidgetConverter ConvertCharacter() ConvertFont() ConvertParagraph() GetTextWidget() ASCIIText TeXText TextWidget Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. case FONT : builder->ConvertFont(t. break.type) { case CHAR : builder->ConvertCharacter(t.Font). } ConcreteBuilder1 BuildPart() GetResult() ConcreteBuilder2 BuildPart() GetResult() ConcreteBuilder3 BuildPart() GetResult() Product1 Product2 Product3 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 304 152 .Char). case PARA : builder->ConvertParagraph().HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 303 Sơ ₫ồ cấu trúc của mẫu Builder Director Construct() builders builder Builder BuildPart() forall objects in structure { builder->BuildPart(). break.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 305 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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. TeXText) : miêu tả ₫ối tượng phức tạp cần xây dựng. cung cấp interface ₫ể nhận ₫ối tượng. ConcreteBuilder (ASCIIConverter.Các phần tử tham gia Director (RTFReader) : xây dựng ₫ối tượng dùng interface Builder. Product (ASCIIText. ₫ịnh nghĩa và ghi giữ ₫ối tượng mà nó tạo ra.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 306 153 . Builder (TextConverter) : cung cấp interface ₫ể xây dựng các phần của ₫ối tượng Product. 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.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 307 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(). public: // methods: virtual void BuildMaze() { }.Ví dụ áp dụng Ta xây dựng interface của builder bằng class MazeBuilder sau : class MazeBuilder { protected: MazeBuilder().HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 308 154 . builder. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. virtual Maze* GetMaze() { return 0. virtual void BuildDoor (int roomFrom.2). }. }. return builder. } 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. builder.GetMaze(). int RoomTo) { } . builder. virtual void BuildRoom (int n) { }.BuildDoor(1. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.BuildRoom(1).BuildRoom(2).

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 309 Sơ ₫ồ cấu trúc của mẫu Singleton Singleton static Instance() SingletonOperation() GetSingletonData() static uniqueInstance singletonData return uniqueInstance .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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 310 155 . chỉ 1 trình quản lý cho các file của hệ thống file.. Nhu cầu áp dụng : chỉ 1 "printer spooler" ₫ể quản lý các máy in.. chỉ 1 trình quản lý windows cho các cửa sổ trên màn desktop. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 312 156 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 311 Trường Đại Học Bách Khoa Tp. Instance() là tác vụ chung của class (hàm static trong C++). HCM Khoa Công nghệ Thông tin 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 Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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.Các phần tử tham gia Singleton : ₫ịnh nghĩa tác vụ Instance giúp client truy xuất instance duy nhất của class. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. chịu trách nhiệm về việc tạo instance duy nhất cho class.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. 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ó. Template Method (class pattern). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. 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ể. 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. Strategy (object pattern) và Command (object Pattern). 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). Các slide sau sẽ giới thiệu các pattern Chain of Responsibility.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 314 157 .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 313 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. 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.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.

. else Handler::HandleHelp(). Application Widget Dialog Button HandleHelp() ShowHelp() if (can handle) ShowHelp().HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 316 158 .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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational anApplication handler Slide 315 Thí dụ về mẫu Chain of Responsibility handler HelpHandler HandleHelp() handler->HandleHelp(). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. trình trợ giúp của Dialog có thể chuyển ₫iều khiển ₫ến Application. aSavingDialog handler aPrintButton handler aPrintDialog handler anOKButton handler Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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..

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 318 159 . nếu không forward request cho ₫ối tượng ₫i sau giải quyết. ConcreteHandler (PrintButton. (optional) hiện thực mối liên kết ₫ến ₫ối tượng ₫i sau (successor). Client : khởi ₫ộng request và gởi tới 1 ConcreteHandler ₫ầu tiên trong dây chuyền. PrintDialog) : xử lý request mà nó có trách nhiệm xử lý. nếu có thể xử lý ₫ược request. nó sẽ xử lý. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. có thể truy xuất ₫ối tượng ₫i sau.HCM successor Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 317 Các phần tử tham gia Handler (HelpHandler) : ₫ịnh nghĩa interface của tác vụ xử lý request.Lược ₫ồ cấu trúc của mẫu Chain of Responsibility Client Handler HandleRequest() successor ConcreteHandler1 HandleRequest() ConcreteHandler2 HandleRequest() aClient aHandler aConcreteHandler aConcreteHandler successor Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 320 160 . 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. muốn xác ₫ịnh tập các ₫ối tượng xử lý 1 request nào ₫ó 1 cách ₫ộng. Người lập trình không thể thay thế trình tự quá trình xử lý của Windows. Đố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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. 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. các tác vụ nhỏ hơn có thể cho lớp con override chính là các ₫iểm hook. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 319 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ụ ₫ó. 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. Hướng tiếp cận như trên là của mẫu Template Method.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.

MyApplication Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp... .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 322 161 . PrimitiveOperation1().. ConcreteClass PrimitiveOperation1() PrimitiveOperation2() Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp..HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 321 Sơ ₫ồ cấu trúc mẫu Template Method AbstractClass TemplateMethod() PrimitiveOperation1() PrimitiveOperation2() .. .Ví dụ về mẫu Template Method Document Save() Open() Close() DoRead() docs Application AddDocument() OpenDocument() DoCreateDocument() CanOpenDocument() AboutToOpenDocument() document MyDocument DoRead() DoCreateDocument() CanOpenDocument() AboutToOpenDocument() return new MyDocument.. PrimitiveOperation2().

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 323 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 324 162 . 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. hiện thực template method. 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. 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 phần tử tham gia 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.

Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. → hướng giải quyết vấn ₫ề của mẫu Strategy. Khi người chơi chọn mức ₫ộ khó dễ chính là thao tác chọn giải thuật. 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. Định nghĩa các lớp concrete hiện thực interface trên. 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.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. mỗi lớp concrete thể hiện một giải thuật. 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 ₫ề.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 325 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. Do ₫ó ₫ối tượng giải thuật phải tách biệt với code chương trình. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 326 163 . 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.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 327 Lược ₫ồ cấu trúc của mẫu Strategy Context ContextInterface() strategy Strategy AlgorithmInterface() ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() ConcreteStrategyC AlgorithmInterface() Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 328 164 .Ví dụ về mẫu Strategy Composition Traverse() Repair() compositor Compositor Compose() compositor->Compose(). SimpleCompositor Compose() TeXCompositor Compose() ArrayCompositor Compose() Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

. 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. Một số chương trình có thể áp dụng Strategy : Compiler. 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.Các phần tử tham gia Strategy (Compositor) : ₫ịnh nghĩa interface cho tất cả các lớp thể hiện giải thuật.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 330 165 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. thể hiện một giải thuật cụ thể. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 329 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. 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. ConcreteStrategy (SimpleCompositor.) : hiện thực interface Strategy. TeXCompositor. 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…) Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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ý.

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 ₫ó. 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. Menu hay button sẽ gọi phương thức Execute() trên ₫ối tượng ₫ó. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Mẫu Command Mục tiêu : ₫óng gói request vào trong một Object.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 332 166 . Vấn ₫ề này có thể ₫ược giải quyết như sau: Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. Các ₫ối tượng này override phương thức Execute() ₫ể xác ₫ịnh hành ₫ộng khi thực thi request. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 331 Ví dụ về nhu cầu ứng dụng mẫu Command Xây dựng lớp trừu tượng Command. log. 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. trong ₫ó có phương thức trừu tượng Execute().

Ví dụ về mẫu Command command Application Add(Document) Menu Add(MenuItem) MenuItem Clicked() Command Execute() Document Open() Close() Cut() Copy() Paste() command->Execute(). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. Command Execute() Document Open() Close() Cut() Copy() Paste() document PasteCommand Execute() document->Paste().HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 334 167 . tác vụ Execute gọi chức năng Paste trên Document nhận ₫ược. Phần tử nhận của PasteCommand là ₫ối tượng Document mà PasteCommand ₫ược cung cấp trong lúc "instantiation".HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 333 Ví dụ về mẫu Command Thí dụ ₫ối tượng PasteCommand hỗ trợ hoạt ₫ộng dán text từ clipboard vào 1 tài liệu.

doc = new Document(name). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. "add" document vào ứng dụng nhận rồi mở document. Command Execute() commands MacroCommand Execute() forall c in commands c->Execute(). application-. 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 336 168 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Add(doc).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 335 Ví dụ về mẫu Command Đôi khi 1 option Menu cần thực thi 1 chuỗi các lệnh. Command Execute() Application Add(Document) application OpenCommand Execute() AskUser() name = AskUser().Ví dụ về mẫu Command 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. doc->Open().

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 338 169 . Receiver (Document. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ConcreteCommand (PasteCommand.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 337 Các phần tử tham gia Command : Khai báo các phương thức ảo (Execute()…) ₫ể gọi thực thi hay quản lý request.Lược ₫ồ class của mẫu Command Command Execute() Client Invoker Receiver Action() receiver ConcreteCommand Execute() state receiver->Action(). Client (Application) : khởi tạo ₫ối tượng ConcreteCommand và truyền ₫ối tượng nhận tương tác cho nó. Biết cách thực hiện những hành ₫ộng ₫ể ₫áp ứng request. Override phương thức Execute trong lớp Command ₫ể ₫áp ứng request. Application) : Đối tượng nhận tương tác trong ConcreteCommand. Invoker (MenuItem): gửi request ₫ến ₫ối tượng Command. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. OpenCommand): Xác ₫ịnh ₫ối tượng nhận tương tác (₫ối tượng lớp Receiver).

Quản lý. Các hệ thống hỗ trợ transaction. 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. Trường hợp này có thể kết hợp mẫu Template Method. Vì trong mẫu Command. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Quá trình cộng tác giữa các phẩn tử Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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ó. redo các thao tác. 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. lưu trữ và thực thi request tại những thời ₫iểm khác nhau. Hỗ trợ undo.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 340 170 . (Ví dụ MS Word có chức năng recovery).HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 339 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.

₫ối tượng TCPConnection có thể ở 1 trong nhiều trạng thái : Established. Khi ₫ối tượng TCPConnection nhận request. Closed. nó sẽ ₫áp ứng khác nhau tùy vào trạng thái hiện hành. Nhu cầu áp dụng : trong class TCPConnection miêu tả 1 mối nối mạng. Listening.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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 342 171 . Ta có cảm giác như class của ₫ối tượng bị thay ₫ổi. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. TCPEstablished Open() Close() Acknowledge() TCPListen Open() Close() Acknowledge() TCPClosed Open() Close() Acknowledge() Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. → hướng giải quyết vấn ₫ề của mẫu State.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 341 Ví dụ về mẫu State TCPConnection Open() Close() Acknowledge() state TCPState Open() Close() Acknowledge() state->Open().

. 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. TCPClose) : ₫ịnh nghĩa hành vi cụ thể kết hợp với trạng thái của mình. TCPListen. state->Handle(). ConcreteStateB Handle() .... Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. ConcreteStateC Handle() . 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.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 344 172 ..... Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.Lược ₫ồ cấu trúc của mẫu State Context Request() .HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 343 Các phần tử tham gia Context (TCPConnection) : ₫ịnh nghĩa interface cần dùng cho client. ConcreteStateA Handle() ... 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ể. state State Handle() . ConcreteState (TCPEstablished.

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 346 173 . Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. Nhu cầu áp dụng : trong ứng dụng quản lý bảng tính. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.. 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.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 runtime khi trạng thái thay ₫ổi. barchart. 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.. → hướng giải quyết vấn ₫ề của mẫu Observer. 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ó. piechart.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 345 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).

HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 347 Lược ₫ồ cấu trúc của mẫu Observer Subject Attach(Observer) Detach(Observer) Notify() observers Observer Update() forall o in observers o->Update().Ví dụ về mẫu Observer Spreadsheet BarChart PieChart thay ₫ổi. modification Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 348 174 . notification Database request. ConcreteObserver Update() observerState observerState = subject->GetState(). ConcreteSubject GetState() SetState() subjectState return subjectState(). Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.

Có thể có nhiều observer quan sát 1 subject. Concretebserver : duy trì tham khảo tới ₫ối tượng ConcreteSubject.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 350 175 .Các phần tử tham gia Subject : biết observer của nó. gởi cảnh báo tới các observer khi trạng thái của nó thay ₫ổi. 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. ConcreteSubject : lưu trạng thái lưu ý tới các ₫ối tượng ConcreteObserver. cung cấp interface ₫ể Attach va Detach các observer vào mình. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp. 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. lưu trạng thái mà cần phải luôn nhất quán với subject của mình. 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. 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. Bö mön Cöng nghï phền mï̀m Khoa CNTT ĐH Bach Khoa Tp.HCM Mön Phân tích & Thiết kế hướng ₫ối tượng dùng UML Chương 11 : Các mẫu Creational Slide 349 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.

Sign up to vote on this title
UsefulNot useful