Vấn đề 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 sẽ chuyển biểu đồ lớp khái niệm băn đầu về biểu đồ lớp thiết kế cuối cùng của phần mềm hệ thống.
Trong cách tiếp cận này, các khung nhìn của 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 nào được sử dụng.
Quasơ đồ 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ể là kế thừa) vào hệ thống, thêm thuộc tính, thêm phương thức cho một lớp của hệ thống, thay đổi đặc trưng của thuộc tính, của phương thức hay 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 của lớp trong hệ thống. Hơn nữa, mỗi hệ thống nhận được ở bước sau phải nhất quán và đồng bộ với bước trước. Để đạt được điều này, ở đây cần giải quyết hai vấn đề:
- Phải đặc tả hệ thống như thế nào để có thể kiểm tra sự nhất quán của nó ở mỗi bước
- Các phép biến đổi trên cần thực hiện như thế nào để đảm bảo phép biến đổi là đúng đắn.
Hướng giải quyết hai vấn đề này đã được đề xuất trong các nghiên cứu [1] và [3]. Việc chứng kiểm chứng tính đúng đắn của các phép biến đổi hoàn toàn có thể được thực hiện bằng việc áp dụng các phương pháp hình thức như rCOS. Thao tác kiểm chứng tính đúng đắn của các phép biến đổi được thực hiện qua hai phạm vi: tính đúng đắn trong một mô hình (kiểm chứng tĩnh) và tính phù hợp của đặc tả hệ thống trong hai bước biến đổi liên tiếp (kiểm chứng động). Do vậy hệ thống đặc cuối cùng thu được sẽ hoàn toàn đúng đắn.
II.2.2. Các bước của tiến trình
II.2.2.1.Xây dựng hệ thống khởi tạo
Mô hình hệ thống khởi tạo còn gọi là mô hình khái niệm thô. Đó chính là mô hình miền lĩnh vực, 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. Bước này tương ứng với bước phát triển mô hình nghiệp vụ hệ thống trong RUP vì vậy có thể sử dụng RUP để hỗ trợ tìm ra các lớp khái niệm nhờ phân tích các ca sử dụng.
Công việc đầu tiên trong tiến trình là tạo mô hình khởi tạo của hệ thống, cụ thể là bổ sung tên các lớp Ni đặc trưng cho các đối tượng miền lĩnh vực vào biểu đồ lớp của mô hình hệ thống có dạng APP0 = N1[]; N2[]; ...; Nk[] và xác định những quan hệ giữa các lớp khái niệm Ni. Phép biến đổi này được thực hiện bằng thuật toán addClassName như sau:
// Thuật toán AddClassName- bổ sung các lớp vào mô hình //Input: Hệ thống S = (α, P), xâu tên lớp N
//Output: Hệ thống mới S’ = (α’, P’) với S thuộc CNAME AddClassName (S, N)
Output: Lớp N trống (chưa có các thuộc tính hoặc phương thức). Format: addClassName ()
Begin
1. Nếu N là xâu trống hoặc N thuộc CNAME thì sang 3 2. CNAME := CNAME ∪N
3. Kết thúc End
II.2.2.2.Làm mịn đặc tả hệ thống qua các bước
Sau khi có được đặc tả hệ thống ban đầu APP0 sau bước xây dựng hệ thống
khởi tạo, nhà phát triển thực hiện liên tiếp n bước làm mịn để thu được đặc tả hệ thống lớp thiết kế cuối cùng APPn.
APP0 ⊑ APP1 ⊑…..⊑APPn
Sau đây là một trình tự các bước làm mịn chính, tuy nhiên có thể áp dụng mềm dẻo các bước này để thu được một đặc tả đầy đủ và chính xác. Các bước a, b, c đã được trình bày và chứng minh trong nghiên cứu [15], các luật làm mịn trong phần a, b và c là các luật khá cơ bản và thường gặp. Trong luận văn này tác giả đề xuất luật làm mịn thêm các quan hệ giữa các lớp và các ràng buộc của luật này (phần d).
a) Bổ sung các thuộc tính cho lớp
Khi đã có một lớp, ta cần xác định và bổ sung các thuộc tính private và định dạng các kiểu cho nó. (khi không giả thiết gì, 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 sau:
Ni [pri]; cdecls ⊑ Ni [pri∪ {T x = d}]; cdecls
Trong đó T là một kiểu dữ liệu và d (có thể không có) là giá trị khởi đầu của thuộc tính attributeName. Với mỗi lớp, thực hiện nhiều lần luật này để bổ sung đầy đủ các thuộc tính cho nó. Quá trình này có thể được mô tả bẳng thuật toán hình thức như sau:
//Input: Hệ thống S, C ∈ CNAME, newAatt {T x = d}
//Output: Hệ thống mới S’ = (α’, P) trong đó newAatt ∈ pri(C) AddAtribute (S, C, newAatt {T x = d})
Begin
1. Nếu C ∉ CNAME thì sang bước 4.
2. Nếu tên x không hơp lệ hoặc newAatt ∈ attr(C)thì sang bước 4
3. att(C) := att(C) ∪ newAatt 4. Dừng
End
Thực hiện k lần thuật toán này để bổ sung các thuộc tính cho k lớp của hệ thống.
b) Chuyên đổi dạng thuộc tính
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:
Ni[pri ∪ {T x = d}, prot]; cdecls ⊑ Ni[pri, prot∪ {T x = d}]; cdecls
Việc chuyển thuộc tính kiểu private trong một lớp sang kiểu protected theo thuật toán sau:
// Thuật toán PriAttToproAtt, chuyển kiểu thuộc tính private thành protected
//Algorithm ChangeAttPriToPro
//Input: S, C ∈ CNAME, attr ∈ pri(C). //Output: S’ = (α’, P) và attr ∈ prot(C). ChangeAttPriToPro (S, C, attr)
Begin
1.pri(C) := pri(C)\ attr 2. prot(C) := prot(C) ∪ attr End
Bằng cách tương tự, ta cũng có thể xây dựng các thuật toán chuyển kiểu thuộc tính protected sang kiểu public. 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 thống mới và ta có: Mô hình khái niệm thô ⊑ Mô hình khái niệm được làm mịn.
c) Bổ sung các phương thức cho lớp
Mô hình thiết kế là mô hình gồm các lớp có chứa đầy đủ thuộc tính và phương thức. Bằng cách bổ sung các phương thức cho các lớp của mô hình khái niệm ta được mô hình thiết kế. 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
Thuật toán bổ sung các phương thức vào một lớp có thể viết như sau: //Algorithm AddMethod
//Input: Hệ thống S, C ∈ CNAME, m(T1 x1, T2 x2, T3 x3){c} //Output: Hệ thống mới S’ = (α’, P) và m ∈ op(C).
AddMethod(S, C, m) Begin
1. Nếu m ∈ op(C) thì chuyển sang bước 3 2. op(C) = op(C) ∪ m
3. Kết thúc End
Sau phép biến đổi này ta có: Mô hình thiết kế ban đầu ⊑ mô hình khái niệm mịn.
d) Thêm các quan hệ giữa các lớp
Trong UML, một mối quan hệ giữa các lớp thể hiện rằng các lớp có mối liên quan tác động đến nhau, thể hiện bằng ký pháp có đường liên kết giữa các lớp tham gia mối quan hệ. Có 5 loại mối quan hệ: thừa kế (còn gọi là tổng quát hóa), phụ thuộc (dependency), liên kết (association), kết tập (aggregation) và hợp thành (composition) [2], [8], [27]. Trong khuôn khổ luận văn này, các nghiên cứu chỉ tập trung vào các quan hệ giữa hai lớp, các mối quan hệ có nhiều hơn hai lớp tham gia có thể được biến đổi về các mối quan hệ hai lớp.
Một mối quan hệ 2 lớp trong được mô tả trong đại số quan hệ bằng tích đề các CNAME x CNAME x Không_gian_đặc_tính_của_quan_hệ. Một đặc tính của quan hệ bao gồm các thông tin như loại quan hệ, tên quan hệ, vai trò của từng lớp, bản số của từng lớp.
Định nghĩa: Gọi tập các quan hệ của đặc tả hệ thống là RELATIONSHIP, một khai báo các lớp cdecls có tập các mối quan hệ RELATIONSHIP được ký hiệu
cdecls(RELATIONSHIP). Định nghĩa RELATIONSHIP như sau:
RELATIONSHIP = {relation (type, name, A, B, RoleA, RoleB, mulA, mulB) | type ∈
RELTYPE, name ∈ String, A ∈ CNAME, B ∈ CNAME, RoleA ∈ String, RoleB ∈ String, mulA ∈
MULTIPLICITY, mulB ∈ MULTIPLICITY} Trong đó:
RELTYPE = {inheritance, dependency, association, aggregation, composition}. o Inheritance: quan hệ thừa kế A thừa kế B.
o Dependency: quan hệ phụ thuộc A phụ thuộc B.
o Association: quan hệ liên liên kết giữa A và B. Quan hệ này có thể một chiều (từ A đến B tức là A biết B chứ B không biết A) hoặc 2 chiều (cả A và B đều biết nhau).
Composition: quan hệ cấu thành A chứa B.
MULTIPLICITY = {0..1, 0..*, 1…1, 1…*, x nguyên dương}.
Ràng buộc: Việc phát hiện quan hệ và quyết định chính xác loại quan hệ giữa các lớp là một công việc không dễ, đòi hỏi nhà phát triển phải có nhiều kinh nghiệm phân tích hệ thống và hiểu biết sâu sắc về UML. Một trong những sự phức tạp của hệ thống đặc tả của chúng ta là mối quan hệ giữa các lớp. Khi thêm một quan hệ vào đặc tả hệ thống thì không chỉ các lớp tham gia trực tiếp vào quan hệ đó ảnh hưởng mà đôi khi còn ảnh hưởng đến các lớp và quan hệ khác. Cần quan tâm đến các ràng buộc sau khi thêm quan hệ các lớp vào hệ thống:
- Các quan hệ thừa kế, kết tập, cấu thành không được làm thành một vòng khép kín (chu trình) trong biểu đồ (trừ các mối quan hệ từ một lớp tới chính nó).
- Bản số của lớp “toàn thể” tham gia mối quan hệ cấu thành phải là 0..1 hoặc 1.
Luật thêm mối quan hệ vào đặc tả hệ thống:
cdecls (RELATIONSHIP)⊑ cdecls (RELATIONSHIP ∪ relation)
Chứng minh:
Trường hợp kiểu quan hệ là thừa kế thì đây chính là luật thừa kế (luật 17 trong [15]):
∃N,M ∈ CNAME • (N[∅, pri, prot,pub,ops]; cdecls ⊑N[M,pri,prot,pub,ops]; cdecls)
Với:
N[∅, pri, prot, pub, ops]; cdecls = cdecls (RELATIONSHIP)
Trường hợp kiểu quan hệ là kết tập, cấu thành hoặc phụ thuộc:
relation(association ∨ aggregation ∨ composition, assocName, A, B, RoleA, RoleB, mulA, mulB).
Theo định nghĩa các mối quan hệ này (ở đây nếu kiểu quan hệ là liên kết, để đơn giản chỉ xét trường hợp một chiều từ A đến B, nếu kiểu quan hệ là liên kết 2 chiều thì chỉ thêm một thuộc tính và lớp B) phép biến đổi trên lớp A là phép thêm một thuộc tính có kiểu B, tức là: A[M, pri, prot, pub, ops] ⊢ A[M, pri ∪ (B: assocName), prot, pub, ops]. Theo luật bổ sung thuộc tính được trình bày trong phần a thì A[M, pri, prot, pub, ops] ; cdecls ⊑ A[M, pri∪(B: assocName), prot, pub, ops]; cdecls
Trường hợp kiểu quan hệ là phụ thuộc:
Hình 8.Quan hệ phụ thuộc A phụ thuộc B qua một phương thức
- Hoặc lớp B được dùng như một tham số của một phương thức của A (hình 8): trường hợp này áp dụng luật thêm phương thức ta có: A[M, pri, prot, pub, ops] ; cdecls ⊑ A[M, pri, prot, pub, ops∪ op(B : refB)]; cdecls
- Hoặc đối tượng của lớp B xuất hiện trong phần thân phương thức nào đó của lớp A, trường hợp này không làm thay đổi các khai báo lớp.
Thuật toán thêm một mối quan hệ vào đặc tả hệ thống:
//Algorithm AddRelationship
//Input: Hệ thống S, relation [type, name, RoleA, RoleB, mulA, mulB] //Output: Hệ thống mới S’ = (α’, P) relation ∪ RELATIONSHIP
AddRelationship (S, relation) Begin
1. Kiểm tra ràng buộc
a. Nếu tồn tại name’ là tên của một quan hệ đã có trong hệ
thống mà name = name’ thì sang bước 4.
b. Nếu type = inheritance|| type = dependency|| type = aggregation|| type = composition và việc relation sẽ tạo thành một vòng khép kín thì sang bước 4.
c. Nếu type = cấu thành mà mulA = 1..*||*||x>1 thì sang bước 4. 2. RELATIONSHIP := RELATIONSHIP ∪ relation//thêm quan hệ
3. Biến đổi các lớp
a. Nếu type = inheritance thì:
i. Với mỗi x ∈ prot (A) và x ∉ att(B) thì prot(B) := att(B) ∪ x
ii. Với mỗi x ∈ pub (A) và x ∉ att(B) thì pub(B) := att(B) ∪ x
iii. Với mỗi m ∈ op (A) và m có mức truy cập protected hoặc public và m ∉ op (B) thì op(B) := op(B) ∪ m
b. Nếu type = association thì
i. Nếu association là quan hệ một chiều từ A đến B thì Att(A) := Att(A) ∪ (B bObj[mulB])
ii. Còn nếu association là quan hệ 2 chiều thì Att(A) := Att(A) ∪ (B bObj[mulB]) và Att(B) := Att(B) ∪ (A aObj[mulA])
c. Nếu type = aggregation || type = composition thì Att(A) := Att(A) ∪ (B bObj[mulB])
d. Nếu type = dependency
i. Nếu sự phụ thuộc này thể hiện qua việc thêm một phương thức có đối số kiểu B thì meth(A) := meth(A)∪op(refB: B)
4. Kết thúc. End
e) Các phép làm mịn mô hình thiết kế hệ thống khác
Các công việc trong phần này tuỳ thuộc mỗi bài toán nghiệp vụ cụ thể đặt ra. Ta có thể áp dụng nhiều luật làm mịn khác nhau để làm mịn dần hệ thống từ mô hình thô về dạng sát với kiến trúc hệ thống 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ợ. Ở đây cần thực hiện các luật khác nhau để làm mịn dần cho hệ thống với các thao tác biến đổi sau đây [3]:
- 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 một lớp khác bằng cách áp dụng luật Move Field: cdecl; M[b:N, a:T, op]; N[] ⊒ cdecls; M[b:N, op]; N[a: T]
- Áp dụng các thao tác chế tác lại định hướng mẫu, như Decorator, Strategy [11], [20] luật thay thế điều kiện bằng tính đa hình, luật làm mịn hướng mẫu gán trách nhiệm, mẫu kết dính cao… [15]
II.3. Kết chương
Tiến trình phát triển RUP là tiến trình rất nổi tiếng và phổ biến dùng để phát triển phần mềm hướng đối tượng. Tuy nhiên, nhà phát triển sử dụng nó phải đối mặt một vài vấn đề về đảm bảo tính nhất quán các mô hình, khả năng tích hợp các khung nhìn. Áp dụng một tiến trình phát triển phần mềm hướng đối tượng mới dựa trên một khung nhìn duy nhất kết hợp với RUP là một hướng giải quyết vấn đề.
Mô hình quan hệ ngữ nghĩa của rCOS có thể được dùng để đặc tả hệt thống hướng đối tượng và chứng minh các luật làm mịn. Tiến hành các bước biến đổi làm mịn hệ thống theo các luật làm mịn của rCOS sẽ luôn đảm bảo tính đúng đắn của hệ thống do các bước làm mịn đã được kiểm chứng bởi các luật. Việc kiểm chứng tính đúng đắn của các phép biến đổi được thực hiện ở hai mức: mức tĩnh (trong một đặc tả hệ thống) và mức động (giữa hai đặc tả của hệ thống ở hai bước làm mịn trước sau).
Chương III: XÂY DỰNG CÔNG CỤ
III.1. Đặt vấn đề
Trong chương II, chúng tôi đã trình bày các nghiên cứu về một tiến trình phát triển phần mềm hướng đối tượng với các luật và thuật toán làm mịn trên đặc tả khung nhìn lớp. Đối với các hệ thống lớn thì khối lượng công việc cần thực hiện để thu được đặc tả thiết kế lớp hoàn chỉnh là khá lớn do sự bùng nổ của số lượng lớp cùng các đặc trưng của nó (thuộc tính, phương thức) và đặc biệt có sự phức tạp của các mối quan hệ giữa chúng. Nếu ta hình dung rằng, một hệ thống đối tượng khởi tạo đơn giản với 5 lớp, mỗi lớp có 5 thuộc tính và 5 phương thức, mỗi phương thức có 3 tham biến, giữa các cặp lớp có trung bình 1 mối quan hệ, thì chúng ta cần đến ít nhất (5tênlớp +5x(5biến+5phươngthức x 3tham số) + (4quanhệ x 2tênlớp) = 113 biến để đặc tả hệ thống. Con số này sẽ tăng lên không ngừng sau mỗi phép biến đổi. Cho nên, nếu thực hiện tiến trình phát triển trên đây bằng tay, thì đó sẽ là một công việc cực nhọc, chưa kể rất dễ mắc sai sót, và cũng chỉ có thể giải quyết được các bài toán nhỏ. Vì vậy, nhu cầu tạo công cụ để trợ giúp tiến trình phát triển này là một yêu cầu cấp bách và có ý nghĩa thiết thực [3].
Những nghiên cứu dưới đây là những kết quả bước đầu của việc phát triển cộng cụ trợ giúp sự tự động hóa tiến trình phát triển hệ thống hướng đối tượng đã nêu trên.
III.2. Phân tích hệ thống
III.2.1. Xác định yêu cầu
Công cụ này trợ giúp quá trình phát triển phần mềm hướng đối tượng dựa trên một khung nhìn duy nhất – khung nhìn biểu đồ lớp. Vì thế, công cụ cần trợ giúp người dùng thực hiện các thao tác thêm và biến đổi các thành phần của biểu đồ lớp, công cụ cần phải có một giao diện người dùng trực quan với các ký pháp UML. Người dùng chỉ cần chỉ ra các yêu cầu cần thiết bằng cách vẽ biểu đồ với các ký pháp đồ họa chuẩn, khi đó công cụ sẽ tiến hành các phép biến đổi phía trong theo đúng các luật và ràng buộc đặt ra để đảm báo tính đúng đắn của hệ thống đặc tả nhận được. Sử dụng công cụ thực hiện một loạt các phép biến đổi, người dùng có thể chuyển biểu đồ lớp khái niệm ban đầu về biểu đồ lớp thiết kế cuối cùng. Các thao tác cơ bản mà công cụ cần hỗ trợ bao gồm: thêm lớp (có thể kế thừa), thêm thuộc tính, thêm phương thức vào một lớp, thay đổi các đặc trưng của thuộc tính, của phương thức, thêm và thay đổi các mối quan hệ giữa các lớp.
Ngoài ra, công cụ cần có khả năng quản lý các tệp đặc tả hệ thống, bao gồm:
tạo mới một hệ thống hay mở tệp của một hệ thống đã có hay lưu chúng vào tệp để sử