Thiết kế hướng đối tượng và xây dựng hệ thống thông tin phức tạp

Bộ Giáo dục và Đào tạo Viện KHoa học và Công Nghệ Việt nam
Viện Công nghệ thông tin


Nguyễn Mạnh Đức





thiết kế Hớng đối tợng
và xây dựng hệ thống thông tin phức tạp


Chuyên ngành: bảo Đảm toán học cho máy tính
và hệ thống tính toán

Mã số: 62. 46. 35. 01



Tóm tắt Luận án tiến sĩ toán học




Hà Nội 2007
Lun án đợc hoàn thành tại Viện Công nghệ thông tin,
Viện Khoa học và Công nghệ Việt Nam

Ngời hớng dẫn khoa học:
PGS.TS. Nguyễn Văn Vỵ
PGS.TS. Đặng Văn Đức

Phản biện 1:
GS.TS. Nguyn Thúc Hải
Trng HBK H Ni
Phản biện 2:
PGS.TS. Nguyn Ngc Bình
Trng HCN HQG H Ni
Phản biện 3:
PGS.TS. Đỗ Trung Tuấn
Trng HKHTN HQG H Ni


Luận án sẽ đợc bảo vệ trớc Hội đồng chấm luận án cấp Nhà nớc
tại Hội trờng Viện Công nghệ thông tin, Viện Khoa học và Công
nghệ Việt Nam vào hồi 15 giờ ngày12 tháng 09 năm 2007





Có thể tìm hiểu luận án tại:
Th viện Quốc gia Việt Nam
Th viện Viện Công nghệ thông tin
Th viện Trờng Đại học S phạm-Đại học Thái Nguyên

DANH MụC CáC CÔNG TRìNH Đã CÔNG Bố CủA TáC GIả
Và CáC CộNG Sự LIÊN QUAN ĐếN LUậN áN

[1] Nguyễn Mạnh Đức, Nguyễn Văn Vỵ (2004), Tái thiết kế hệ thống
phần mềm bằng UML, Báo cáo Hội thảo Quốc gia Một số vấn đề
chọn lọc của công nghệ thông tin, Đà Nẵng 8/2004.
[2] Nguyễn Mạnh Đức (2005), Mô hình hoá ứng dụng trên nền Web với
UML, Tạp chí khoa học và công nghệ, Đại học Thái Nguyên, 2 (34),
tr. 47-53.
[3] Nguyn Mnh c (2005), Thit k v ci t h thng phn mm x
lý s liu thng kờ v thc nghim, Hi tho Khoa hc ton quc
Phỏt trin cụng c tin hc tr giỳp cho ging dy, nghiờn cu v ng
dng toỏn hc, H Ni 4/2005, tr. 117-124.
[4] Nguyễn Mạnh Đức, Nguyễn Văn Vỵ, Đặng Văn Đức (2005), Mô
hình đại số quan hệ ca hệ thống hớng đối tợng, Tạp chí Tin học
và Điều khiển học, Viện Khoa học và Công nghệ Việt Nam, H Ni,
21 (3), tr.261-270.
[5] Nguyễn Văn Vỵ, Đặng Văn Đức, Nguyễn Mạnh Đức (2006), Phơng
pháp hình thức phát triển hệ thống hớng đối tợng dựa trên quan hệ
đại số, Báo cáo Hội thảo Quốc gia Một số vấn đề chọn lọc của công
nghệ thông tin và truyền thông, Đà Lạt 6/2006.
[6] Nguyễn Mạnh Đức, Đặng Văn Đức (2006), Về một cách tinh chế mô
hình lớp UML, Tạp chí Tin học và Điều khiển học, Viện Khoa học
và Công nghệ Việt Nam, H Ni, 22 (1), tr.63-74.
[7] Nguyễn Mạnh Đức, Đặng Văn Đức (2006), ứng dụng phơng pháp
hớng đối tợng và ngôn ngữ UML mô hình hoá hệ thống E-
Learning, Tạp chí Khoa học và Công nghệ, Viện Khoa học và Công
nghệ Việt nam, Hà Nội, 44 (3), tr.33- 42.

Mở đầu

1. Lý do v mc ớch nghiờn cu
Ngày nay, do sự tiến bộ nhanh chóng về công nghệ phần cứng, các tính năng của
máy tính tăng nhanh sau mỗi khoảng thời gian. Cùng với sự phát triển đó, yêu cầu phát
triển phần mềm có qui mô lớn phức tạp trở nên cấp bách và vấn đề bảo trì các hệ thống
trở thành vấn đề nghiêm trọng. Trớc những thách thức to lớn nh vậy, công nghệ phát
triển phần mềm hớng đối tợng cùng với các công cụ tự động hoá đi theo nó đã trở
thành một giải pháp công nghệ hữu hiệu cho các vấn đề đặt ra. Phát triển phần mềm
theo tiếp cận hớng đối tợng đã trở thành một vấn đề tất yếu trong công nghệ phần
mềm.
Thit k v phỏt trin h thng phn mm vi ngụn ng hng i tng ó c
nhiu chuyờn gia tha nhn l rt phc tp. Nhiu nh nghiờn cu ch ra s cn thit
phi phỏt trin cụng c hỡnh thc hoỏ lm nn tng cho vic phỏt trin cỏc phn mm
hng i tng. Phỏt trin nhng phn mm ln v phc tp khụng th lm theo kiu
mt ln l xong, m phi tinh ch dn tng bc, s phỏt trin t bc ny sang
bc kia phi ỳng n.
Mt cỏch thc phỏt trin bo m cht lng h thng phn mm l thc hin
theo chin lc tinh ch tng bc mt (step-by-step refinement). thc hin s
phỏt trin theo cỏch thc ú cn phi bo m rng: bc sau thc s l mt s
phỏt trin ca bc trc (bo m tớnh ỳng n, bo m mi iu ỳng trong
bc trc phi ỳng trong bc sau).
Mt trong cỏc phng phỏp rt quan trng l phng phỏp hỡnh thc, va cho
kh nng kim chng tớnh ỳng n, li va cú kh nng t ng hoỏ vic kim chng
ú; chng hn nh cụng c RAISE, cho ta kh nng t ng hoỏ vic kim chng tớnh
ỳng n cho tng bc; Nhng RAISE cú nhng hn ch: khụng c t c ht cỏc
h thng nh UML, vic tinh ch t bc ny sang bc do ngi dựng lm theo kinh
nghim, phi sau khi cú h thng sau mi kim tra c tớnh ỳng theo h thng trc.
Gn õy, mt nhúm nghiờn cu da trờn rCOS ó c t c cỏc h thng rng rói
hn RAISE, ó xõy dng v chng minh mt s lut phỏt trin cỏc h thng phn
mm theo cỏc lut ú thỡ tớnh ỳng n c tho món. Mt khỏc, ngụn ng c t

UML vi cỏc c im nh: tm s dng ln, mụ t c hu ht cỏc h thng mong


1
muốn; được sử dụng rất rộng rãi; có công cụ hỗ trợ rất hiệu quả là Rational Rose, có
thể thực hiện được phần lớn các đặc tả của UML.
Chúng ta đã có phần mềm Rational Rose, với những qui trình kinh nghiệm phát
triển để thực hiện theo cách thức đó, nhưng tôi chưa thấy có công trình nào chứng
minh tính đúng đắn cho những qui trình đó được công bố.
Trong vài năm gần đây, He Jifeng và các cộng sự đã đề xuất một ngôn ngữ đặc tả
rCOS, với ngôn ngữ đó họ đã chứng minh được một số luật tinh chế để bảo đảm tính
đúng đắn của quá trình tinh chế, chỉ ra các quy tắc mà khi tinh chế hệ thống theo
những qui tắc đó thì việc tinh chế ấy là đúng đắn, và như vậy không cần kiểm chứng
lại cho từng bước nữa.
Mục tiêu của luận án là: Sử dụng các luật của rCOS xây dựng các thuật toán tinh
chế, để phát triển các hệ thống đối tượng bảo đảm tính đúng đắn. Các vấn đề liên quan
bao gồm:
1. Tìm hiểu mô hình quan hệ của hệ thống hướng đối tượng, mô hình tính toán
rCOS để xây dựng các đặc tả khai báo và làm mịn các lớp.
2. Xây dựng các thuật toán tinh chế trên cơ sở các luật tinh chế của rCOS.
Với mục tiêu trên, luận án đi sâu nghiên cứu các nội dung:
1. Nghiên cứu cơ sở lý thuyết để tiến tới xây dựng một công cụ phục vụ cho
việc phát triển các hệ thống đối tượng. Cụ thể là đặc tả một công cụ để xây
dựng các hệ thống đối tượng, xây dựng các thuật toán dùng trong công cụ đó
để thiết kế các hệ thống, cho phép hỗ trợ từng bước tiến trình làm mịn các
lớp trong quá trình phát triển phần mềm theo tiếp cận hướng đối tượng.
2. Trên cơ sở xây dựng các đặc tả lớp cho hệ thống đối tượng, xây dựng các
thuật toán tinh chế biến đổi và làm mịn các lớp trong hệ thống.
3. Cài đặt chương trình ứng với mỗi cách đặc tả đó để kiểm tra tính đúng đắn.
4. Bằng thực nghiệm chỉ ra rằng, phương pháp này là rất đáng tin tưởng, có thể

mở rộng phát triển tiếp cho các hệ thống khác
2. Ph−¬ng ph¸p tiÕp cËn
Luận án khai thác và mở rộng các kết quả nghiên cứu của nhóm tác giả trên, sử
dụng các kết quả đó phục vụ cho việc thiết kế và phát triển các hệ thống phần mềm
theo chiến lược tinh chế dần từng bước. Cụ thể là đề xuất các thuật toán để tinh chế và
làm mịn đặc tả hệ thống theo các luật của mô hình rCOS, nhằm một mặt cho người sử
dụng ngôn ngữ mô hình hoá UML một loạt các qui tắc tinh chế và làm mịn bảo đảm


2
tính đúng đắn, mặt khác nghiên cứu xây dựng một công cụ đặc tả tuân theo các luật
tính chế và làm mịn nói trên.
3. Bố cục của luận án
Luận án bao gồm phần mở đầu, ba chương nội dung, phần kết luận, tài liệu tham
khảo và phần phụ lục.
Chương 1 - Tổng quan về phương pháp hướng đối tượng và quá trình thống nhất.
Chương này trình bày chung về mẫu hình phát triển phần mềm hướng đối tượng; Các
đặc trưng cơ bản của tiến trình thống nhất trong quá trình phát triển hệ thống phần
mềm.
Những kết quả trong chương này được dùng để mở rộng cho các nghiên cứu
trong các chương sau. Đặc biệt là tiến trình RUP được chú trọng tìm hiểu làm cơ sở
cho quá trình làm mịn mô hình UML sau này.
Chương 2 – Làm mịn hệ thống các lớp của chương trình hướng đối tượng.
Chương này sẽ trình bày ngữ nghĩa của hệ thống hướng đối tượng với việc đặc tả hình
thức các lớp, các liên kết động và các phương thức đệ qui; Mô hình tính toán rCOS;
Các đặc tả lớp trong hệ thống cùng với các thuật toán làm mịn hệ thống các lớp ứng
với các cách đã đặc tả.
Chương 3 – Phát triển đặc tả hệ thống hướng đối tượng theo mô hình quan hệ.
Chương này trình bày việc sử dụng ngôn ngữ hướng đối tượng hình thức và các luật
làm mịn kết hợp một số mô hình UML, xây dựng các thuật toán và qui trình cho phép

làm mịn dần quá trình thiết kế hệ thống phần mềm trên UML. Qua quá trình làm mịn
sẽ thu được mô hình thiết kế cuối cùng tương đối gần với mã có thể thực hiện được.
Phần phụ lục bao gồm: Phụ lục 1 trình bầy mô hình quan hệ hướng đối tượng của
hệ thống rCOS, một số luật làm mịn, tinh chế và chế tác lại; Phụ lục 2 sẽ xây dựng các
hệ thống quản lý các đặc tả và các thuật toán làm mịn theo ba cách đã đặc tả bằng
C++, xây dựng các dữ liệu để kiểm thử các hệ thống quản lý đặc tả và các thuật toán
làm mịn đã đề xuất; Phụ lục 3 sẽ trình bày một số hệ thống ứng dụng thực tiễn mà
chúng tôi đã xây dựng theo các thuật toán làm mịn đã đề xuất bằng công cụ Rational
Rose trên, để kiểm chứng tính đúng đắn của các thuật toán đó và phương pháp tinh chế
từng bước mà chúng tôi đưa ra.
4. Các đóng góp chính của luận án
1. Xây dựng ba phương pháp đặc tả hệ thống và những thuật toán phát triển các hệ
thống đó theo đúng các luật tinh chế của nhóm nghiên cứu rCOS. Những kết


3
qu ny cú th c s dng xõy dng cụng c phỏt trin cỏc h thng (theo
ngha c t) bo m tớnh ỳng n.
2. Xõy dng cỏc thut toỏn tinh ch cỏc h thng (mt s lp hn ch) trờn
UML theo kiu cỏc lut tinh ch ca rCOS.
3. Bng thc nghim trờn Rational Rose ch ra rng, phng phỏp ny l rt ỏng
tin tng, mi kim chng u cho kt qu ỳng theo tớnh toỏn. Cú th m rng
phỏt trin tip cho cỏc h thng khỏc
Chơng 1
Tổng quan về phơng pháp hớng đối tợng và
Quá trình thống nhất
Chơng ny trình bày chung về mô hình phát triển phần mềm hớng đối tợng,
cùng với các đặc trng chính của nó. Trong chơng này cũng trình bày các đặc trng
cơ bản của quá trình thống nhất trong tiến trình phát triển hệ thống phần mềm.
1.1. Hệ thống thông tin lớn v phức tạp

Một hệ thống thông tin gọi là lớn và phức tạp khi nó có qui mô lớn cả về số phần
tử và mối quan hệ, cũng nh tính đa dạng của chúng. Sự đa dạng về mối quan hệ thể
hiện ở sự khác nhau về số lợng, cờng độ, chiều hớng và tính chất của mối quan hệ
giữa các phần tử. Đó thờng là hệ có nhiều mục tiêu, nhiều ràng buộc trên các quan hệ.
1.2. Mẫu hình phát triển phần mềm hớng đối tợng
1.2.1. Gii thiu chung
Cách tiếp cận hớng đối tợng đặt trọng tâm vào việc xây dựng lý thuyết các hệ
thống tổng quát nh là khái niệm cơ sở. Hệ thống đợc xem nh là một tập hợp các
thực thể tác động qua lại với nhau để thực hiện một số mục đích nào đó. Thực thể có
thể là đối tợng vật lý nh các thiết bị và con ngời hoặc có thể là các khái niệm trừu
tợng nh các tệp dữ liệu và các hàm Các thực thể của thế giới thực đợc biểu diễn
trong mô hình hệ thống là các đối tợng. Những đối tợng này trao đổi thông tin với
nhau thông qua các giao diện sao cho những cặp bộ giữa chúng là tối thiểu nhng cố
kết hệ thống lại ở mức tối đa.
1.2.2. Phát triển phần mềm theo phơng pháp hớng đối tợng
Xây dựng hệ thống phần mềm theo phơng pháp hớng đối tợng bao gồm: phân
tích, thiết kế và lập trình hớng đối tợng. Phơng pháp hớng đối tợng giải quyết
đợc hố ngăn cách giữa phân tích và thiết kế hệ thống.
Phân tích hớng đối tợng làm nhiệm vụ xác định các đối tợng để xây dựng
các module của hệ thống phần mềm. Nhiệm vụ của giai đoạn này là tìm hiểu kỹ bài


4
toán, phân tách nó thành các phần nhỏ hơn, xây dựng mô hình logic mô tả chức năng
của toàn hệ thống.
Nhiệm vụ của thiết kế hớng đối tợng là xác định các đối tợng trong không
gian bài toán, chuyển chúng sang không gian lời giải, xây dựng mô hình kiến trúc và
mô hình tính toán cho hệ thống phần mềm.
Lập trình hớng đối tợng cho phép chúng ta kết hợp những tri thức bao quát về
các quá trình với các khái niệm trừu tợng đợc sử dụng trong máy tính. Chơng trình

hớng đối tợng xác định chính xác các đặc trng và hành vi của các kiểu dữ liệu,
trong đó có thể tạo ra những đối tợng mới đợc xây dựng từ những khuôn khổ có sẵn
hay tổ hợp để tạo ra những đặc trng mới.
1.3. Quỏ trỡnh thng nht
1.3.1. Khỏi nim v quỏ trỡnh thng nht
Quỏ trỡnh thng nht da trờn cỏc thnh phn, iu ú cú ngha l h thng phn
mm c xõy dng da trờn cỏc thnh phn phn mm kt ni vi nhau thụng qua
giao din ó c nh ngha trc.
Quỏ trỡnh thng nht s dng ngụn ng mụ hỡnh hoỏ thng nht UML thit k
cỏc h thng phn mm. Trờn thc t UML l mt phn tớch hp ca quỏ trỡnh thng
nht. Chỳng c phỏt trin liờn kt vi nhau. Nh vy ta thy quỏ trỡnh thng nht l
quỏ trỡnh phỏt trin phn mm hng i tng vi cụng c UML. Quỏ trỡnh ny cú 3
c trng sau: Ca s dng (Use Case) iu khin quỏ trỡnh phỏt trin; Ly kin trỳc
lm trung tõm; Tin trỡnh phỏt trin l lp v tng dn.
1.3.2. Cỏc c trng ca quỏ trỡnh thng nht
1.3.2.1. Use Case iu khin quỏ trỡnh phỏt trin
Use Case l mt phn chc nng ca h thng cung cp cho ngi dựng mang
li mt kt qu no ú khi s dng nú. Cỏc Use Case dựng nm bt cỏc yờu cu
chc nng. Tp hp tt c cỏc ca s dng lp thnh mụ hỡnh ca s dng mụ t y
chc nng ca h thng. Mụ hỡnh ny s thay th cho cỏc c t chc nng h thng
bng phng phỏp truyn thng.
1.3.2.2. Quỏ trỡnh thng nht ly kin trỳc lm trung tõm
Vai trũ ca kin trỳc h thng phn mm ging nh khung nn, da trờn ú phn
mm c xõy dng v phỏt trin n hon thin. Khỏi nim kin trỳc phn mm cha
ng cỏc khớa cnh tnh v ng cú ý ngha nht i vi h thng. Nú c phỏt trin
da theo yờu cu ca t chc, theo cm nhn ca ngi dựng v cỏc t chc cú liờn
quan khỏc c phn ỏnh qua cỏc Use Case. Mt khỏc, nú cng chu nh hng ca


5

rất nhiều nhân tố, chẳng hạn như môi trường nền của hệ thống, các khối xây dựng
dùng lại có sẵn, các điều cân nhắc triển khai và các yêu cầu phi chức năng (như tính
thể hiện, độ tin cậy ). Kiến trúc là một khung nhìn thiết kế tổng thể về những đặc
điểm quan trọng nhất của hệ thống và tạm bỏ qua các chi tiết.
1.3.2.3. Quá trình thống nhất là lặp và tăng dần
Việc phát triển một phần mềm nói chung đòi hỏi một số lớn công việc và có thể
diễn ra trong một khoảng thời gian nhất định. Việc chia nhỏ toàn bộ công việc thành
các phần nhỏ hoặc các dự án con là yêu cầu thiết thực. Mỗi dự án con là một bước lặp
và tạo nên một sự tăng trưởng. Điều này dễ dàng thực hiện được khi phát triển phần
mềm hướng đối tượng, vì nó được cấu thành từ các thành phần độc lập ghép nối lại với
nhau. Để đạt hiệu quả nhất, các bước lặp phải được điều khiển, nghĩa là chúng phải
được lựa chọn và tiến hành theo kế hoạch đã được định trước.
1.3.2.4. Vòng đời của một quá trình thống nhất
Quá trình thống nhất lặp lại một chuỗi các vòng đời trong việc xây dựng một hệ
thống. Mỗi vòng đời bao gồm một xuất phẩm (product release) cho khách hàng.
Mỗi vòng đời chứa 4 giai đoạn sau: Sơ bộ (inception), Chi tiết (elaboration), Xây
dựng (construction) và Chuyển giao (transtion). Mỗi giai đoạn (phase) lại được chia
thành nhiều bước lặp con.
1.4. Kết luận chương 1
Trong chương này chúng ta đã xem xét khái quát về hệ thống thông tin phức tạp,
phương pháp phát triển phần mềm theo tiếp cận hướng đối tượng. Đó là phương pháp
dựa trên nền tảng các đối tượng, chúng là tập các thực thể được xây dựng trên cơ sở
gắn liền dữ liệu của chúng với các phép toán xử lý, tương tác với nhau để thực hiện
các yêu cầu của bài toán đặt ra. Phát triển phần mềm theo tiếp cận hướng đối tượng sẽ
là một xu hướng tất yếu trong công nghệ phần mềm. Các kết quả nghiên cứu trong
chương này sẽ được vận dụng trong suốt quá trình nghiên cứu tiếp theo.

Chương 2
LÀM MỊN hÖ ThèNG CÁC LỚP CỦA CHƯƠNG TRÌNH
h−ínG ®èi t−îng

2.1. Hệ thống hướng đối tượng
Một hệ thống hoặc chương trình hướng đối tượng S theo mô hình rCOS (xem
trong phụ lục 1) có dạng:


6
cdecls●P
Ở đây:
 cdecls là phần khai báo một số hữu hạn các lớp, mỗi lớp có dạng như sau:
[private] class N [extends M] {
pri: <a
:U,u>; pro: <b:V,v>; pub: <c:W,w>;
meth: m
1
(x
11
: T
11
, y
12
: T
12
, z
13
: T
13
){c
1
};
…;

m
ℓ
(x
ℓ1
: T
ℓ1
, y
ℓ2
: T
ℓ2
, z
ℓ3
: T
ℓ3
){c
ℓ
}

}
 P được gọi là phương thức chính và có dạng (glb, c), trong đó glb là tập
hữu hạn các biến chung và kiểu dữ liệu của chúng còn c là các lệnh.
2. 2. Làm mịn hệ thống đối tượng
2.2.1. Các khái niệm
Sau đây ta xem xét một số khái niệm liên quan tới quá trình làm mịn mô hình hệ
thống:
Định nghĩa 1 (làm mịn thiết kế): Thiết kế D2 = (α, P2) là làm mịn của thiết kế
D1=(α, P1) được chỉ ra bởi D1
⊑
D2, nếu P2 dẫn tới P1, nghĩa là:
∀

x, x’, ok, ok’:
(P2
⇒
P1).
Ở đây x, , z là các biến chứa trong α. D1
≡
D2 nếu và chỉ nếu D1
⊑
D2 và D2
⊑

D1.
Định nghĩa 2 (làm mịn dữ liệu): Cho
ρ
là ánh xạ (cũng có thể được coi như là
thiết kế) từ α2 tới α1. Thiết kế D2 = (α2, P2) là làm mịn của thiết kế D1 = (α1, P1)
dưới
ρ
, được chỉ ra bởi D1
⊑
ρ
D2, nếu (
ρ
; P1)
⊑
(P2;
ρ
). Trong trường hợp này
ρ

được gọi là ánh xạ tinh chế.
Định nghĩa 3 (làm mịn hệ thống): Cho S1 và S2 là các đối tượng chương trình
có cùng một tập các biến chung glb. S2 là làm mịn của S1, được chỉ ra bởi S1
⊑
sys
S2,
nếu hành vi của nó có thể kiểm soát và dự đoán nhiều hơn trong S1, tức là:
∀
x, x’,
ok, ok’: (S2
⇒
S1).
Định nghĩa 4 (làm mịn lớp): Cho cdecls1 và cdecls2 là hai phần khai báo.
cdecls1 là làm mịn của cdecls2, được chỉ ra bởi cdecls1
⊒
class
cdecls2 nếu như phần
trước có thể thay thế phần sau trong bất kỳ hệ thống đối tượng: cdecls1
⊒
class
cdecls2


7
def
∀
P (cdecls1
•
P
⊒

sys
cdecls2
•
P). Ở đây P đóng vai trò cho phương thức chính
(glb, c).
2.2.2. Các luật làm mịn
Nói chung, một luật (quy tắc) làm mịn có dạng như sau:
cdecls • P ⊑ cdecls1 • P
Trong đó, chương trình vế trái của ⊑ là một thành phần được làm mịn và vế bên phải
có một chương trình kết quả của việc làm mịn. Ở đây ta thấy rằng các luật chỉ bao gồm
làm mịn các lớp, do đó chúng ta có thể không phải viết chương trình chính P.
Khi viết các luật làm mịn, chúng ta sử dụng ký pháp sau để chỉ sự khai báo lớp N:
N [M, pri, pro, pub, op]
Trong đó, M là tên lớp cha của N; pri, pro và pub là các tập thuộc tính private,
protected và public của N; op là tập các phương thức của N. Ta có thể chỉ đưa ra các
tham số liên quan cần thiết chẳng hạn như, nếu sử dụng N[op] để chỉ lớp N với tập các
phương thức op, N[pro, op] chỉ lớp N với các thuộc tính protected là pro và các
phương thức là op
Chi tiết về các luật làm mịn có thể xem trong trong phụ lục 1.
2.3. Mô tả hệ thống
Cho một hệ thống đối tượng S = (α, P), trong đó P có dạng p(x) ⊢ R(x, x’)
và α gồm 3 thành phần như sau:
1. Phần thứ nhất: Cung cấp các thông tin ngữ cảnh lớp và các quan hệ của chúng:
• cname: Tập các tên lớp đã được khai báo.
• superclass: Là ánh xạ từ một tên lớp tới tên lớp cha của nó.
2. Phần thứ hai: Mô tả chi tiết cấu trúc của mỗi lớp: với mỗi tên lớp N ∈ cname, nó
bao gồm:
• attribute(N): Là ánh xạ từ một lớp N tới tập các thuộc tính được khai báo của
nó, tập thuộc tính có dạng <a: T, d>. Trong đó a là tên thuộc tính, T là kiểu và
d là giá trị khởi đầu.

• Attribute là hàm mở rộng của attribue(N), với mỗi lớp N bao gồm các thuộc
tính protected và public mà N được kế thừa từ các lớp ông cha của nó.
• meth(N): Là ánh xạ từ một lớp N tới tập các phương thức được khai báo của
N, tập phương thức có dạng:
Hoặc: m → (<x: T
x
, y: T
y
, z: T
z
> { c }) | (paras, D)


8
Trong đó: m là tên phương thức và có x, y và z tương ứng là tham biến giá trị,
tham biến kết quả và tham biến giá trị-kết quả của nó; T
x
, T
y
và T
z
là các kiểu
dữ liệu. Thiết kế D biểu diễn hành vi của phương thức m.
• Meth(N) là hàm bao gồm các thương thức được kế thừa từ các lớp ông cha của
nó.
3. Phần thứ ba: Nhận biết các biến mà chương trình sử dụng:
• alphabet: Tập các biến chung cùng với kiểu của chúng đã biết trong chương
trình, nó có dạng <x: T>. Ở đây, x là tên biến, T là kiểu của x.
• locvar: Tập các biến địa phương có dạng <v: T>. Trong đó v là tên biến, T là
kiểu của nó.

• visibleattr: Tập các thuộc tính tường minh trong lớp hiện tại, tức là tất cả thuộc
tính đã được khai báo thuộc miền private, protected và public (đã khai báo) của
lớp. Nó bao gồm 3 ánh xạ:
pri: N → <a: T, d>, pro: N → <a: T, d>, pub: N → <a: T, d>
Trong đó N là tên lớp, a là tên thuộc tính, T là kiểu của thuộc tính và d là trị
khởi đầu.
Ta coi hệ thống ban đầu S mà trong đó các thành phần của α đều là trống. Trong
quá trình tạo thêm lớp mới, huỷ bỏ lớp, thay đổi thêm hay huỷ bỏ các biến, chuyển
thuộc tính từ lớp này sang lớp khác khi thực hiện hệ thống thì các thành phần của α
có thể sẽ thay đổi và cho hệ thống mới S’ = (α’, P’).
Ở đây ta chỉ quan tâm tới việc đưa ra một số thuật toán xử lý các lớp, tinh chế và
làm mịn các thành phần dữ liệu, các quan hệ giữa chúng trong phần khai báo cdecls,
nên thành phần P của hệ thống không thay đổi.
Vấn đề phải giải quyết là đưa ra các cách đặc tả các lớp và các thuật toán xử lý
trên các lớp được mô tả như vậy. Có ba cách mô tả các lớp trong hệ thống, đó là:
1. Mỗi lớp là một tập các file văn bản (text), tương ứng với một cách mô tả lớp
theo cách này là các thuật toán làm mịn thông qua việc xử lý các file.
2. Mô tả mỗi lớp là một hệ thống các biến, tương ứng với các thuật toán làm mịn
thông qua việc xử lý biến đổi các biến.
3. Mô tả mỗi lớp đúng như Hoare đã mô tả, theo cách này thì mỗi lớp là một file
văn bản, tương ứng với các thuật toán làm mịn trên một file văn bản đó.
Sau đây ta sẽ xem xét chi tiết từng cách đặc tả lớp theo đề xuất trên, xây dựng
một số thuật toán cơ bản làm mịn hệ thống. Việc cài đặt chương trình bằng C++ để
kiểm thử theo mỗi cách đặc tả đó có thể xem trong phụ lục 2.


9
2.4. Đặc tả lớp bằng tập các file văn bản
Trong cách mô tả hệ thống này, chúng ta sử dụng các tệp văn bản để đặc tả lớp và
biểu diễn quá trình biến đổi của hệ thống đã trình bày ở trên, nghĩa là thành phần α là

một tập các file văn bản mô tả sự biến đổi của hệ thống. Ta qui định tên của các tệp đó
như sau:
• cname.txt lưu trữ tên các lớp được tạo ra trong hệ thống, nó biểu diễn tập
cname.
• super_C.txt lưu trữ tên lớp cha của một lớp, nó biễu diễn hàm super(C).
• meth_C.txt lưu tập các phương thức của các lớp C trong hệ thống, nó biểu
diễn hàm meth(C).
• pri_C.txt lưu tập các thuộc tính private của các lớp C trong hệ thống, nó biểu
diễn hàm pri(C).
• pro_C.txt lưu tập các thuộc tính protected của các lớp C trong hệ thống, nó
biểu diễn hàm pro(C).
• pub_C.txt lưu tập các thuộc tính public của các lớp C trong hệ thống, nó
biểu diễn hàm pub(C).
Khi một lớp mới trống được tạo ra trong hệ thống (lớp chỉ có tên mà chưa có một
thuộc tính hay phương thức nào) thì tên của lớp sẽ được bổ sung vào tệp cname.txt và
các tệp văn bản biểu diễn cho lớp đó: super_C.txt, meth_C.txt, pri_C.txt, pro_C.txt và
pub_C.txt sẽ được tạo ra, ban đầu nội dung của các tệp đó là trống. Trong quá trình
thực hiện các biến đổi để làm mịn và tinh chế hệ thống như: thêm hoặc huỷ bỏ các
thuộc tính trong các lớp, chuyển đổi phương thúc của các lớp thì nội dung của các
tệp văn bản trên sẽ thay đổi theo phù hợp với sự thay đổi của các lớp trong hệ thống.
Kết quả là ta sẽ được một hệ thống mới được làm mịn từ hệ thống trước đó.
2.5. Đặc tả một lớp là một hệ thống các biến
Theo cách mô tả này, một đối tượng lớp có thể được đặc tả bởi cấu trúc bản ghi
(record) bao gồm các biến như sau:
attr_type = record {
name: String; visibility: String[3];}
class_type = record {
name: String;
attrName[50]: attr_type;
super: String;

10
meth: String;
}
Ở đây, thành phần tên các thuộc tính của lớp là một cấu trúc mảng kích thước tối
đa là 50 có hai thành phần: name chỉ tên của các thuộc tính trong lớp và visibility chỉ
phạm vi của các thuộc tính, nó có thể nhận một trong ba giá trị pri, pro hoặc pub
tương ứng biểu diễn các thuộc tính private, protected hoặc public (một lớp như vậy có
tối đa 50 thuộc tính).
Khi đó ta có thể khai báo một biến đối tượng lớp như sau:
name_class: class_type;
Khi đó tất cả các thành phần của lớp đều trống. Sau đó ta xẽ xây dựng các thuật
toán xử lý và biến đổi lớp để làm mịn hệ thống.
2.6. Đặc tả lớp bằng một file văn bản
Trong cách mô tả hệ thống này, chúng ta sử dụng một tệp văn bản để đặc tả các
thành phần của một lớp và biểu diễn quá trình biến đổi của nó trong hệ thống, nghĩa là
thành phần α của hệ thống là một là một tập các file văn bản, mỗi file văn bản đặc
trưng cho một lớp bao gồm các thành phần đã mô tả trong mục trên như sau:
• name: tên lớp
• supername: tên lớp cha
• meth: các phương thức được khai báo
• pri: các thuộc tính private
• pro: các thuộc tính protected
• pub: các thuộc tính public
Trong file văn bản đặc tả lớp như trên: Thành phần mô tả tên lớp name là bắt
buộc phải có (khác trống) và không thay đổi; Các thành phần khác có thể thay đổi
hoặc không thay đổi trong quá trình hoạt động của hệ thống, do các xử lý như thêm
bớt các thuộc tính hay phương thức, thay đổi tính visibility của các thành phần trong
lớp…

2.7. Các thuật toán làm mịn hệ thống
Ứng với mỗi cách đặc tả lớp như trên chúng tôi đã đưa ra các thuật toán biến đổi
làm mịn hệ thống dựa trên các luật tinh chế như sau:
• Thêm một tên lớp vào hệ thống: AddNewClass
• Thêm một tên thuộc tính riêng vào một lớp: AddAttr


11
• Chuyển một thuộc tính pri thành pro: MovePro
• Chuyển một thuộc tính pro thành pub: MovePub
• Chuyển một thuộc tính pri thành pub: MovePub1
• Chuyển thuộc tính từ một lớp tới lớp cha: MoveAtt
• Lập kế thừa cho một lớp: Inheritance, Inheri
• Thêm một phương thức vào một lớp: AddMethod
• Chuyển phương thức từ một lớp sang lớp khác: MoveMethod
• Lập quan hệ kết hợp giữa hai lớp: Relation.
Chúng tôi đã đưa ra tính đúng đắn và độ phức tạp thời gian cho từng thuật toán
trên trong mỗi cách đặc tả lớp (xem trong các mục mục 2.5, 2.6 và 2.7 của luận án).
2.8. Kết hợp các thuật toán làm mịn
Trong các phần trên, ta đã đưa ra các thuật toán cơ bản để làm mịn các lớp của hệ
thống. Xong để thuận lợi cho người dùng, đảm bảo tính thống nhất, tăng tốc độ thực
hiện… ta có thể kết hợp các thuật toán đó vào các module để thực hiện một loạt các
thao tác nào đó trong quá trình làm mịn. Sau đây là một số modul mô tả các kết hợp
đó: Thêm một lớp mới vào hệ thống S bằng cách thực hiện thêm một lớp trống, sau đó
có thể thực hiện các công việc làm mịn nó như: thêm các thuộc tính mới, thay đổi tính
visibility các thuộc tính, thêm các phương thức mới…
Sau đây là thuật toán làm mịn hệ thống với các lớp được đặc tả bằng hệ thống file
văn bản, còn thuật toán cho hệ thống với các lớp được đặc tả bằng một hệ các biến
hoặc một file văn bản có thể được viết tương tự.
refine(S) {

1. Thêm một lớp mới
var C: String;
read(C);
if (C ∉ cname and C<> “”) AddNewClass(C);
2. Thêm các thuộc tính riêng vào lớp
var st: String, ok: Boolean;
ok := true;
while ok Do {
read(st); AddAttr(S, C, st); read(ok);
}
3. Chuyển một số thuộc tính private sang protected


12
ok := true;
while ok Do {
read(st); MovePro(S, C, st); read(ok);
}
4. Chuyển một số thuộc tính protected sang public
ok := true;
while ok Do {
read(st); MovePub(S, C, st); read(ok);
}
5. Thêm các phương thức vào lớp
var m: String;
ok := true;
while ok Do {
read(m, st); AddMethod(S, C, m, st); read(ok);
}
end m, st, ok;

}
Tương tự cho các làm mịn khác, ta có thể kết hợp các thuật toán trên hoặc xây
dựng thêm một số thuật toán mới, theo các luật làm mịn đã đưa ra trong phần phụ lục
1 để thoả mãn các yêu cầu của bài toán đặt ra.
2.9. Nhận xét
Trong các phần trên, chúng tôi đã đưa ra ba cách đặc tả hệ thống các lớp trong
một chương trình hướng đối tượng. Tương ứng với mỗi cách đặc tả đó, chúng tôi đã
đưa ra một số thuật toán làm mịn các lớp đó dựa trên một số luật làm mịn do Hoare,
He Jifeng và các cộng sự đề xuất và đã chứng minh về tính đúng đắn cho sự biến đổi
của hệ thống khi áp dụng các luật đó. Mỗi cách đặc tả lớp như trên có những đặc điểm,
ưu điểm và những hạn chế như sau.
2.9.1. Đặc tả lớp là một tập các file văn bản
Theo các đặc tả này, mỗi lớp cần phải có 5 tệp văn bản để mô tả các thành phần
của lớp. Do đó việc xử lý sẽ có những đặc điểm sau:
• Dễ dàng xử lý cho sự biến đổi các thành phần của một lớp, trực quan vì
mỗi thành phần của lớp đặt ở một tệp riêng.


13
• Thông tin về các lớp trong hệ thống được lưu trên bộ nhớ ngoài, dễ dàng
cho việc bảo quản, lưu trữ, mở rộng qui mô do thông tin lưu trên tệp văn
bản có thể rất lớn…
• Nếu hệ thống có nhiều lớp thì sẽ có rất nhiều tệp văn bản mô tả nó được
sinh ra, chính điều này sẽ dẫn đến phải xử lý nhiều thao tác vào ra với các
tệp, và sẽ làm cho tốc độ xử lý tính toán sẽ bị hạn chế.
2.9.2. Đặc tả lớp là một tập các biến
Theo các đặc tả này, thông tin về lớp được lưu ở các biến trong bộ nhớ, nên các
công việc xử lý có các đặc điểm sau:
• Tốc độ xử lý sẽ nhanh.
• Khi hệ thống hoạt động kết thúc thì các thông tin biến đổi sẽ bị mất, vì

chúng chỉ được lưu ở các biến trong bộ nhớ trong.
• Hệ thống sẽ bị hạn chế qui mô, nếu số lượng các lớp trong hệ thống tăng
lên và thông tin trong mỗi lớp lớn lên…
2.9.3. Đặc tả lớp là một file văn bản
Các đặc tả lớp kiểu này giống như các đặc tả của Hoare, mỗi lớp được đặc tả bởi
một tệp văn bản có nhiều thành phần. Do đó các thuật toán xử lý có các đặc điểm sau:
• Thông tin về các lớp trong hệ thống được lưu trên bộ nhớ ngoài, dễ dàng
cho việc bảo quản, lưu trữ, quan sát, mở rộng qui mô do thông tin lưu trên
tệp văn bản có thể rất lớn…
• Các thao tác vào ra chỉ trên một tệp văn bản chính mô tả lớp. Chính điều
đó cũng có hạn chế là nếu tệp lớn và có nhiều thao tác xử lý đồng thời thì
sẽ rất phức tạp.
• Do chỉ có một tệp văn bản mô tả lớp, nên các thao tác với các thành phần
trong tệp sẽ phức tạp hơn cách thứ nhất, nếu không cẩn thận sẽ hay bị
nhầm lẫn…
2.10. Kết luận chương 2
Chương này tập trung vào các vấn đề sau: Tìm hiểu mô hình quan hệ của hệ
thống hướng đối tượng – mô hình rCOS; mô tả hệ thống hướng đối tượng theo mô
hình rCOS; xây dựng các thuật toán tinh chế hệ thống đã đặc tả theo các luật làm
mịn… Kết quả chính của chương này bao gồm:
• Nghiên cứu mô hình quan hệ của hệ thống hướng đối tượng rCOS để xây dựng
các đặc tả khai báo và các hệ thống. Xây dựng ba cách đặc tả lớp cho hệ thống


14
theo mụ hỡnh rCOS. Xõy dng cỏc thut toỏn lm mn tng ng vi cỏc cỏch
c t lp ó xut.
xut v xõy dng cỏc thut toỏn lm mn trong h thng i tng da trờn
mụ hỡnh rCOS: AddNewClass, AddAttr, MovePro, MovePub, MoveAtt
AddMethod, Inheritance, Inheri, MoveMethod, Relation tng ng vi ba

cỏch biu din lp lm c s cho vic thit lp mụ hỡnh thit k h thng trờn
UML. Xỏc nh tớnh ỳng n v phc tp thi gian cho tng thut toỏn ó
xut.
Ci t cỏc chng trỡnh mụ phng cho cỏc thut toỏn lm mn tng ng vi
cỏc cỏch c t. Vic chy kim th cỏc chng trỡnh ó cho kt qu ỳng nh
tớnh toỏn theo lý thuyt v hon ton ỳng nh kt qu x lý theo phn mm
Rational Rose. Cỏc kt qu nghiờn cu ny s lm c s cho vic tin ti ci t
cụng c h tr cho vic thit k v phỏt trin h thng i tng.
Cỏc kt qu ny s c s dng vo vic phỏt trin c t cho h thng hng
i tng trong chng sau.

Chng 3
Phát triển Đặc tả hệ thống hớng đối tợng
theo mô hình quan hệ
3.1. Gii thiu
Trong quỏ trỡnh phỏt trin da trờn UML nh RUP, mt s mụ hỡnh ca UML ó
c s dng biu din v phõn tớch cu trỳc c to ra trong mi pha ca vic
phỏt trin h thng: cỏc biu lp biu din phõn tớch tnh (khung nhỡn tnh), biu
trng thỏi ca vic c t cỏc hnh vi ng v tớnh phự hp (khung nhỡn hnh vi), biu
trỡnh t v biu cng tỏc gia cỏc i tng, ngụn ng rng buc i tng c
t chc nng v cỏc rng buc trong mi quan h tng tỏc cỏc i tng (khung nhỡn
chc nng) Ngụn ng UML s dng ng thi nhiu khung nhỡn trong vic mụ hỡnh
hoỏ h thng mang li nhiu thun li. Ngi xõy dng mụ hỡnh cú th phõn tỏch mụ
hỡnh h thng thnh mt s khung nhỡn khỏc nhau qun lý theo khuụn kh riờng.
Mi khung nhỡn n s tp trung vo mt khớa cnh riờng bit, phõn tớch v hiu rừ
cỏc c trng khỏc nhau ca mụ hỡnh h thng. Tuy nhiờn, mt mụ hỡnh nhiu khung
nhỡn phi i mt vi cỏc khú khn v s tn ti cỏc khung nhỡn nhng thi gian


15

khác nhau, các bài toán đặt ra có quan hệ khác nhau và sự giải quyết chúng dẫn đến
điều khiển phát triển mô hình phải xét đến các mặt như sau:
1. Tính nhất quán của mô hình (model consistency): Các mô hình bao gồm nhiều
khung nhìn khác nhau đòi hỏi chúng phải tương thích về cú pháp và ngữ
nghĩa với việc quan tâm về các khía cạnh của hệ thống được mô tả trong các
mô hình con (nhất quán ngang – horizontal consistency).
2. Sự biến đổi và tiến hoá mô hình (model transformation and evolution): Nó đòi
hỏi mô hình được làm mịn phải có ngữ nghĩa phù hợp và sự làm mịn nhất
quán theo chiều dọc (vertical consistency) trong suốt quá trình phát triển.
3. Tính lần vết của mô hình (model traceability): Sự thay đổi trong mô hình của
một khung nhìn chỉ dẫn đến sự thay đổi phù hợp trong các mô hình của các
khung nhìn khác liên quan trực tiếp với nó.
4. Tính tích hợp của mô hình (model integration): Những mô hình của các
khung nhìn khác nhau cần phải được tích hợp trước khi có sản phẩm phần
mềm.
Sự nghiên cứu tính nhất quán và phân tích hình thức của các mô hình UML đã
được tiến hành trong những năm gần đây. Tuy nhiên, phần lớn chỉ liên quan với hình
thức của các biểu đồ riêng lẻ và tính nhất quán của các mô hình loại 1 hoặc loại 2, như
là tính nhất quán của biểu đồ lớp hoặc các máy trạng thái của chúng. Từ những kinh
nghiệm của chúng tôi, có nhiều công việc nhỏ có thể giải quyết với sự tinh chế các mô
hình UML dựa trên các luật làm mịn đã có.
3.3. Cách tiếp cận mới
Nhìn lại tiến trình phát triển hệ thống phần mềm hướng đối tượng theo RUP ta
thấy, bắt đầu của tiến trình phát triển với khung nhìn nghiệp vụ, có chứa mô hình lớp
khái niệm, và cho đến khi kết thúc tiến trình trước khi chuyển sang mã nguồn, chúng
ta lại nhận được biểu đồ lớp thiết kế của hệ thống phần mềm. Nếu ta chỉ sử dụng một
khung nhìn duy nhất được biểu diễn bằng các biểu đồ lớp, ta sẽ khắc phục được tính
đa khung nhìn của tiến trình phát triển ở trên. Vấn đề duy nhất còn cần phải giải quyết
ở đây là: làm sao xây dựng được các phép biến đổi và các quy tắc kiểm tra sự đúng
đắn của chúng, khi đó bằng một loạt các phép biến đổi đúng đắn, ta có thể chuyển

biểu đồ lớp khái niệm ban đầu thành biểu đồ lớp thiết kế cuối cùng của phần mềm hệ
thống (hình 3.2).


16
Lúc này, các khung nhìn khác của tiến trình RUP sẽ được sử dụng như các công cụ
trợ giúp cho việc xác định các phép biến đổi cụ thể để tận dụng được thế mạnh của các
khung nhìn này. Vấn đề cuối cùng đặt ra được giải quyết bằng công cụ hình thức hóa
dựa theo mô hình quan hệ của hệ thống hướng đối tượng.











Phương
pháp
mới
Tiến
trình
RUP
Hình 3.2. Ý tưởng cho phương pháp giải quyết vấn đề
…
khung
nhìn k

mô hình
thiết kế
khung
nhìn 2
mô hình
phân tích
khung
nhìn 1
mô hình
nghiệp vụ
…
phép
BĐn
phép
BĐ2
bi
ể
u đ
ồ
lớp
được làm
mịn 1
phép
BĐ1
biểu đồ lớp
thiết kế phần
mềm hệ thống
biểu đồ lớp
khái niệm
miền lĩnh vực

Nhìn trên sơ đồ ta thấy, để đạt đến biểu đồ lớp thiết kế cuối cùng, chúng ta cần đến
các phép biến đổi sau: thêm lớp (có thể kế thừa), thêm liên kết lớp mới với các lớp đã
có, thêm thuộc tính, thêm phương thức, thay đổi đặc trưng của thuộc tính, của phương
thức, thay đổi liên kết giữa các lớp và các biến đổi tương ứng trong mỗi phương thức.
3.4. Phát triển đặc tả hệ thống hướng đối tượng
3.4.1. Tiến trình phát triển đặc tả hình thức hệ thống dựa theo RUP
Trong chương 2, chúng ta đã nghiên cứu các đặc tả các lớp đối tượng và các phép
toán làm mịn chúng tuân theo các luật cho trước để đảm bảo tính đúng đắn của hệ
thống nhận đựợc. Những nghiên cứu đó sẽ được vận dụng để xây dựng một tiến trình
đặc tả hệ thống hướng đối tượng dựa theo RUP (hình 3.3).
3.4.2. Các quy tắc làm mịn và chế tác lại
Các quy tắc làm mịn và chế tác lại được coi như là các luật làm mịn trong hệ
thống. Nói chung, một quy tắc chế tác lại có dạng như sau:
cdecls • P ⊒ cdecls1 • P1
Trong đó, chương trình vế phải của ⊒ là một thành phần được làm mịn và vế bên trái
có một chương trình kết quả của việc làm mịn. Tuy nhiên, một số luật chỉ bao gồm
làm mịn lớp, trong những trường hợp đó thì không phải viết chương trình chính P .


17
Chi tiết về các luật làm mịn và chế tác lại xem trong phụ lục 1.

tiên
Phân tích
gói nghiệp
vụ, sắp ưu
- các gói ca
sử dung
- thứ tự ưu
tiên
đ
ặc tả ca
sử dụng
Phát tri
ể
n
mô hình
nghiệp vụ

hệ thống
M
ô hình
miền lĩnh
v
ự
c
M
ô hình
nghiệp vụ
AP
P
i-1
AP
P
i
0
AP
P
i
1
AP
P
i
k
Hình 3.3.Tiến trình phát triển đặc tả hình thức hệ
thống dựa theo RUP

Một bước
của phương

pháp đặc tả
hình thức

…
Bước n
APP
n
APP
i
4. Bổ sung lớp
mới cần thiết
vào APP
i
k
3. Làm mịn các
lớp trong APP
i
k
dựa vào mẫu
2. Làm mịn
các lớp trong
APP
i
0
dựa vào
ca sử d
ụ
n
g

1. Bổ sung các
lớp còn thiếu
của gói i vào
APP
i-1
Phát triển đặc
tả hệ thống
khởi tạo APP
0
Làm mịn các
lớp trong
APP
0
bước 0
0.Xác định các
lớp thực hiện
gói các ca sử
dụng thứ i
bước i
bước i-1
…
RU
P
APP
0
đặc tả mẫu
thiết kế
3.4.3. Các quy tắc chế tác lại định hướng mẫu
Trong khuôn khổ công việc ở đây, mỗi làm mịn định hướng theo mẫu có thể được
hình thức hoá như luật làm mịn sau:

C
d
; cdecls • P(c) ⊒ C
0
• cdecls; P(c
0
)


18
Ở đây: C
0
đóng vai trò là khai báo lớp trong phần mã thô; C
d
là phần khai báo lớp
trong thiết kế mã định hướng theo mẫu; cdecls là các phần khai báo khác còn lại giống
như mỗi phần của luật; P(c
0
) và P(c) đóng vai trò tương ứng là mô hình thiết kế gốc và
mô hình thiết kế dựa trên mẫu.
3.4.4. Mô tả nội dung thực hiện các bước
3.4.4.1. Phát triển đặc tả hệ thống khởi tạo
Mô hình hệ thống khởi tạo ban đầu còn gọi là mô hình khái niệm thô, đó chính là
một phần của mô hình nghiệp vụ (mô hình lĩnh vực miền), mô tả các khái niệm quan
trọng của hệ thống qua các đối tượng của lĩnh vực nghiệp vụ và các liên kết giữa
chúng với nhau. Công việc đầu tiên là bổ sung các tên lớp N
i
đặc trưng cho các đối
tượng vào biểu đồ lớp của mô hình hệ thống:
APP

0
= N
1
[]; N
2
[]; ; N
k
[]
và xác định những quan hệ giữa các N
i
. Ta xây dựng thuật toán addClassName để bổ
sung các lớp vào mô hình dựa trên luật :
cdecls ⊑ N[]; cdecls
Input: Một tên xâu cho định danh cho lớp N
i
.
Output: Lớp N
i
trống chưa có các thuộc tính hoặc phương thức.
Format addNewClass()
Method:
var stop: Boolean, s: String; stop := false;
while ¬ stop do {
read(s); if {(s <> ””) → AdditionClassName(s)} fi;
read(stop);
}
end stop, s;
end
3.4.4.2. Xây dựng mô hình khái niệm mịn cho hệ thống
Xác định và bổ sung các thuộc tính thành phần private cho các lớp N

i
, (chú ý
rằng trong ngôn ngữ hướng đối tượng của chúng ta, nếu không có chỉ định gì thì kiểu
các thuộc tính trong lớp mặc định là private). Việc thêm một thuộc tính thành phần
vào một lớp có thể được thực hiện theo luật bổ sung thuộc tính như sau:
N
i
[]; cdecls ⊑ N
i
[pri <attributeName: T, d>]; cdecls
Trong đó T là một kiểu dữ liệu của thuộc tính attributeName và d là giá trị khởi
đầu nếu cần. Với mỗi lớp N
i
thực hiện nhiều lần luật này để bổ sung đầy đủ các thuộc


19
tính cho nó. Quá trình này có thể được mô tả bằng thuật toán hình thức
addAttributeName:
// Thuật toán addAttributeName- bổ sung các thuộc tính vào lớp
Input: Một lớp N
i
của hệ thống ứng dụng.
Output: Lớp N
i
bao gồm các thuộc tính kiểu private cần thiết.
Format addAttributeName () {
Method:
var stop: Boolean, s: String; stop := false;
while ¬ stop do {

read(s);
if {(s <> ””) → AdditionAttributeName(s)} fi;
read(stop);
}
end stop, s;
end
Tiếp theo là chuyển các thuộc tính kiểu private cần thiết sang kiểu protected để
được hỗ trợ các dịch vụ nhiều hơn. Muốn vậy ta sẽ áp dụng luật chuyển đổi kiểu thuộc
tính sau:
N
i
[pri <attributeName: T, d>]; cdecls ⊑
N
i
[pro <attributeName: T, d>]; cdecls
Công việc này được thực hiện bởi thuật toán
priAttToproAtt:
Input: Một lớp khái niệm N
i
của hệ thống ứng dụng.
Output: Lớp N
i
bao gồm các thuộc tính kiểu protected cần thiết.
Format priAttiToproAtt () {
Method:
var stop: Boolean, ok: Boolean; stop := false; ok := false;
while ¬ stop do {
if {(type(N
i
.AttributeName) = private) → {

Question (ok);
if { ok = true → priTopro(N
i
.AttributeName)} fi;} fi;
read(stop);
}
end stop, ok;
end
Xây dựng các thuật toán chuyển kiểu thuộc tính protected sang kiểu public nếu
cần thiết theo luật sau:
N
i
[pro <attributeName: T,d>]; cdecls ⊑


20
N
i
[pub <attributeName: T, d>]; cdecls
Thuật toán proAttTopubAtt- chuyển thuộc tính protected thành public.
Thuật toán RelationShip -Tạo quan hệ giữa lớp N
i
và N
j
.
Sau mỗi bước thực hiện các công việc làm mịn trên sẽ thu được một mô hình hệ
thống mới, theo các luật làm mịn ta sẽ có: Mô hình khái niệm thô ⊑ Mô hình khái
niệm mịn ban đầu.
3.4.4.3. Xây dựng mô hình thiết kế ban đầu cho hệ thống
Chúng ta có thể phải thực hiện các công việc sau để xây dựng mô hình thiết kế

cho hệ thống: Bổ sung các phương thức cho các lớp, có thể áp dụng các luật bổ sung
phương thức như sau:
N[op]; cdecls ⊑ N[op ∪ m(paras) {c}]; cdecls
để thêm các phương thức vào một lớp. Thuật toán
addMethodName sẽ bổ sung các
phương thức vào lớp.
Thực hiện thuật toán này với các lớp N
i
trong hệ thống để được mô hình thiết kế.
theo các luật làm mịn ta sẽ có: Mô hình khái niệm mịn ⊑ Mô hình thiết kế ban đầu.
3.4.4.4. Làm mịn mô hình thiết kế hệ thống
Các công việc trong phần này tuỳ thuộc nhiều vào bài toán nghiệp vụ cụ thể đặt
ra. Trong bước này chúng ta có thể áp dụng các luật làm mịn và chế tác lại để làm mịn
dần hệ thống từ mô hình thô về dạng sát với mã trình có thể thực hiện được, tạo điều
kiện thuận lợi cho quá trình dịch xuôi từ mô hình UML sang một ngôn ngữ hướng đối
tượng mà nó hỗ trợ. Chúng ta có thể phải thực hiện các công việc sau để xây dựng mô
hình thiết kế và làm mịn dần cho hệ thống:
- Làm mịn các phần thân phương thức m(){c} trong các lớp: Áp dụng luật
Extract Method, Move Method, Add Parameter
- Chuyển thuộc tính từ một lớp tới lớp khác: Áp dụng luật Move Field, để chuyển
thuộc tính từ một lớp sang lớp khác như sau:
cdecl; M[b: N, a: T, op]; N[] ⊒ cdecls; M[b: N, op]; N[a: T]
Thuật toán MoveAtt- chuyển thuộc tính từ một lớp sang một lớp khác.
Thuật toán MoveMethod- chuyển một phương thức một lớp sang lớp cha của
nó.
- Xây dựng các thừa kế cho các lớp: Áp dụng các luật tạo quan hệ giữa các lớp,
luật thay thế điều kiện bằng tính đa hình, chế tác lại định hướng theo mẫu như
Decorator, Strategy
Để mở rộng phạm vi của một lớp, tạo quan hệ kế thừa với một lớp khác, ta có thể
áp dụng luật sau: Giả sử S là một lớp không thể thay đổi và M là tên một lớp mới

không được sử dụng trong cdecls, thì ta có luật làm mịn như sau:


21
cdelcs; M[S, m()]; S[] ⊒ cdecls; S[]
Thuật toán làm mịn quan hệ kế thừa Inheritance1.
Luật thay thế điều kiện bằng tính đa hình có thể xác định như sau:
cdecls; M[m()]; M
1
[M, m(){ c
1
}]; M
2
[M], m() {c
2
}] ● P’ ⊒
cdecls; M[m() {c
1
⊳ e ⊲c
2
}] ● P
Thuật toán thay thế điều kiện bằng tính đa hình Polymorphism.
Để làm mịn quan hệ kế thừa giữa các lớp, ta có thể đưa ra thuật toán dựa trên luật
sau: Nếu không có thuộc tính của lớp M được khai báo trong N hoặc bất kỳ lớp cha
nào của N trong phần cdecls, thì có:
M[∅, pri, pro, pub, op]; cdecls ⊑ M[N, pri, pro, pub, op]; cdecls
Với mỗi hệ thống ứng dụng cụ thể, ta có thể linh hoạt áp dụng các luật làm mịn
cho bài toán đặt ra. Theo các luật làm mịn ta sẽ có: Mô hình thiết kế ban đầu ⊑ Mô
hình thiết kế đã được làm mịn, tức là: APP
i

⊑ APP
i+1
. Sau mỗi lần làm mịn ta sẽ thu
được mô hình sát thực và tối ưu hơn. Việc chuyển mô hình từ bước i sang i+1 là đúng
đắn, do sự biến đổi dựa trên các luật, các qui tắc định hướng mẫu và chế tác lại đã
được xác định đúng.
3.6. Vận dụng các luật làm mịn của rCOS vào phát triển phần mềm dựa trên
Rational Rose
Việc vận dụng các luật của rCOS và mô hình UML vào thực hiện trên Rational
Rose là đúng đắn vì: biểu diễn lớp của rCOS và biểu diễn lớp của UML cơ bản là
giống nhau như đã phân tích; mô hình rCOS được đưa ra để đặc tả hệ thống hướng đối
tượng, các quy tắc và các luật đảm bảo sự đúng đắn của hệ thống đặc tả; với các hệ
thống đã được xây dựng phát triển và kiểm nghiệm, chứng tỏ rằng phương pháp tinh
chế từng bước là đáng tin cậy và có thể mở rộng áp dụng cho các hệ thống khác.
3.7. Kết luận chương 3
Chương 3 tập trung vào việc xây dựng qui trình làm mịn các mô hình UML cho
quá trình tinh chế từng bước hệ thống phần mềm. Các kết quả chính của chương này
bao gồm:
• Đưa ra một tiến trình dựa trên RUP để phát triển mô hình hệ thống. Xây dựng
các thuật toán trên cơ sở của các thuật toán trong mô hình quan hệ của hệ thống
hướng đối tượng và các luật làm mịn, phục vụ cho việc tinh chế và làm mịn mô
hình thiết kế hệ thống trên UML, thực hiện bằng Rational Rose được dễ dàng và
hiệu quả hơn.
• Quá trình tinh chế và làm mịn theo cách thức chỉ ra ở trên đã được chúng tôi
kiểm nghiệm trên công cụ Rational Rose, đảm bảo tính lôgic, tính đúng đắn và


22