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


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

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ể

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

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

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
};
…;

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
ρ


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.

• 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à
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…

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;

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

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

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
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ụ

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


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

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 {

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ế

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