ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

VŨ THANH HÀ

NGHIÊN CỨU VÀ CÀI ĐẶT
MỘT CÔNG CỤ TRÊN NỀN TẢNG ECLIPSE
ĐỂ HỖ TRỢ PHÁT TRIỂN CÁC ỨNG DỤNG JAVA
Ngành: Công nghệ Thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. ĐẶNG ĐỨC HẠNH

Hà Nội – 2018
L


LỜI CAM ĐOAN
Tôi xin cam đoan luận văn thạc sĩ “Nghiên cứu và cài đặt một công cụ trên
nền tảng Eclipse để hỗ trợ phát triển các ứng dụng Java” là công trình nghiên cứu
của riêng tôi và được sự hướng dẫn của TS. Đặng Đức Hạnh. Các nội dung nghiên cứu
và kết quả trong đề tài là trung thực và chưa từng được ai công bố trong bất kỳ công
trình nào khác.
Những phân tích, đánh giá được tác giả thu thập từ các nguồn khác nhau có ghi rõ
trong tài liệu tham khảo.

Học viên thực hiện


MỞ ĐẦU..................................................................................................................... 1
CHƯƠNG 1. KIẾN THỨC NỀN TẢNG ..................................................................... 3
1.1. Giới thiệu chương .............................................................................................. 3
1.2. Thiết kế hướng miền .......................................................................................... 3
1.2.1. Kiến thức về miền vấn đề ............................................................................ 3
1.2.2. Ngôn ngữ chung .......................................................................................... 4
1.2.3. Rằng buộc mô hình và cài đặt ...................................................................... 5
1.2.4. Cô lập miền ................................................................................................. 7
1.2.5. Mô hình được thể hiện trong phần mềm ...................................................... 9
1.2.6. Vòng đời của đối tượng miền .................................................................... 12
1.3. Phương pháp phát triển phần mềm hướng miền DDSDM ................................ 13
1.3.1. Phát triển một mô hình miền khái niệm ..................................................... 14
1.3.2. Định nghĩa các vòng lặp phát triển ............................................................ 15
1.3.3. Thực hiện các vòng lặp phát triển .............................................................. 15
1.3.4. Tích hợp các nguyên mẫu phần mềm ......................................................... 15
1.4. Công cụ hỗ trợ phát triển phần mềm hướng miền ............................................ 16
1.4.1. Lịch sử phát triển....................................................................................... 16
1.4.2. Tổng quan kiến trúc ................................................................................... 16
1.4.3. Ví dụ điển hình: CourseMan ...................................................................... 17
1.4.4. Phát triển các lớp miền .............................................................................. 18
1.4.5. Xây dựng nguyên mẫu phần mềm từ các lớp miền. ................................... 24
iii


1.5. Thành phần mở rộng Eclipse Plug-in ............................................................... 25
1.5.1. Kiến trúc mở của Eclipse ........................................................................... 25
1.5.2. Môi trường phát triển Plug-in .................................................................... 27
1.6. Tổng kết chương.............................................................................................. 30
CHƯƠNG 2. XÂY DỰNG ELCIPSE PLUGIN CHO ............................................... 31
2.1. Giới thiệu chương ............................................................................................ 31

Giao diện lập trình ứng dụng

DDD

Domain-Driven Design

Thiết kế hướng miền

IDE

Domain-driven software development Phương pháp phát triển phần
method
mềm hướng miền
Integrated Development Environment Môi trường phát triển tích hợp

JDT

Java Development Tools

Các công cụ phát triển Java

JRE

Java Runtime Environment

Môi trường chạy Java

MCC

Module Configuration Class


The Standard Widget Toolkit

Bộ công cụ đồ họa chuẩn

User interface

Giao diện người dùng

eXtensible Markup Language

Ngôn ngữ đánh dấu mở rộng

DDSDM

UI
XML

v

Nền tảng Java cho việc phát
triển và triển khai plug-in
Môi trường phát triển plug-in


DANH SÁCH CÁC HÌNH VẼ
Hình 1.1: Các thành phần của thiết kế hướng miền
Hình 1.2: Kiến trúc phân lớp
Hình 1.3: Vòng đời của đối tượng miền
Hình 1.4: Tổng quan về phương pháp phát triển phần mềm hướng miền

Hình 3.13: Giao diện các form của CourseMan sau khi sửa cấu hình mô-đun

vi


MỞ ĐẦU
Một ứng ứng dụng có thể được phát triển với kiến trúc tuyệt với, sử dụng công
nghệ mới nhất và có giao diện tốt nhất nhưng nếu nó không giải quyết được yêu cầu
nghiệp vụ được đề ra thì ứng dụng đó không thể được xem là hữu ích. Do đó, thiết kế
hướng miền DDD được đưa ra [2]. Thiết kế hướng miền DDD nhằm phát triển phần
mềm một cách lặp đi lặp lại xung quanh một mô hình miền thực tế. Cả phần mềm và
mô hình miền đều nắm bắt triệt để các yêu cầu miền và khả thi để cài đặt xét về mặt kỹ
thuật [6]. Ý tưởng chính của DDD là mô hình hóa miền cho phát triển phần mềm. Về
lý thuyết, đội phát triển chỉ cần tập trung chủ yếu vào xây dựng mô hình miền, và tuân
thủ các nguyên tắc DDD khi cài đặt. Khi bộ xương của hệ thống rắn chắc, mọi thứ trở
nên dễ dàng hơn và việc triển khai các tính năng mới tương tự như việc lắp ghép các
viên gạch xếp hình.
Trên thực tế, việc xây dựng một phần mềm hướng miền không hề đơn giản, quá
nhiều công việc cần phải thực hiện: từ phân tích miền, xây dựng mô hình miền, cài đặt
dưới dạng mã nguồn sử dụng ngôn ngữ lập trình nhất định, đảm bảo các nguyên tắc
của DDD là gắn chặt cài đặt với mô hình, cô lập lớp miền và chứa các thành phần cơ
bản cấu thành nên DDD [2]. Để tăng hiệu suất tạo ra phần mềm, một công cụ Java hỗ
trợ phát triển phần mềm hướng miền tên là DomainAppTool, đã được nhóm tác giả [5]
đề xuất. Công cụ này sử dụng các nghiên cứu gần đây trong DDD là tập trung vào mở
rộng các ngôn ngữ lập trình hướng đối tượng dựa trên annotation để xây dựng mô hình
miền. Mô hình này không chỉ là cơ sở cho ngôn ngữ chung giữa các thành viên nhóm
phát triển mà còn được sử dụng như đầu vào để sinh ra phần mềm [6].
DomainAppTool tự động tạo ra phần mềm từ một tập các lớp miền được thiết kế
với các tính năng thiết kế hướng miền. Lợi ích chính của công cụ là cho phép các nhà
phát triển chỉ tập chung vào thiết kế mô hình miền để đưa ra một tập các lớp miền của


2


CHƯƠNG 1. KIẾN THỨC NỀN TẢNG
1.1. Giới thiệu chương
Chương này sẽ trình bày cơ sở lý thuyết và các công nghệ chính được sử dụng
trong luận văn. Bao gồm ba nội dung chính:
 Thiết kế hướng miền DDD: khái niệm, ngôn ngữ chung, thiết kế hướng mô
hình và kiến trúc ứng dụng sử dụng DDD
 Phương pháp phát triển phần mềm hướng miền DDSDM: khái niệm, các pha
trong phát triển các nguyên mẫu phần mềm từ mô hình miền.
 Công cụ hỗ trợ phát triển phần mềm hướng miền: lịch sử phát triển, tổng quan
kiến trúc, phát triển các lớp miền và các bước xây dựng nguyên mẫu phần mềm
từ các lớp miền.
 Thành phần mở rộng Eclipse Plug-in: Kiến trúc mở của Eclipse và môi trường
phát triển Plug-in.

1.2. Thiết kế hướng miền
Thiết kế hướng miền là một cách tiếp cận để phát triển phần mềm có các yêu cầu
phức tạp về việc liên kết cài đặt với một mô hình phát triển. Tiền đề của thiết kế hướng
miền [2] là:
 Đặt trọng tâm chính của dự án tập trung vào miền lõi và logic miền.
 Các thiết kế phức tạp được xây dựng dựa trên một mô hình miền.
 Sự cộng tác giữa chuyên gia miền và chuyên gia phát triển để trau dồi lặp đi
lặp lại một mô hình miền khái niệm giải quyết các vấn đề miền cụ thể.
Thiết kế hướng miền phát triển từ tiền đề coi trái tim của phát triển phần mềm là
kiến thức về vấn đề cần giải quyết và tìm các cách hữu ích nhất để hiểu vấn đề đó. Sự
phức tạp cần giải quyết chính là sự phức tạp của miền chứ không phải là kiến thức kỹ
thuật, không phải là giao diện người dùng hay thậm chí không phải chức năng cụ thể.

trọng không phải là kiến thức trong đầu của chuyên gia miền mà là sự trừu tượng hóa
miền kết hợp chặt chẽ với kiến thức đó và cả nhóm phát triển có thể hiểu được [1].
Mô hình là một sự thể hiện của miền cần xem xét và rất cần thiết trong suốt quá
trình phát triển phần mềm. Mô hình hóa miền đòi hỏi kiến thức xử lý theo cách tương
tự các nhà phân tích tài chính xử lý những con số để hiểu hiệu suất hàng quý của một
công ty. Khi làm việc với chuyên gia miền, người mô hình hóa miền sẽ thử đưa ra một
số ý tưởng tổ chức tập các khái niệm, sau đó, tạo các mô hình, dùng thử chúng, một số
mô hình bị loại bỏ trong khi một số khác bị biến đổi.
Phát triển là lặp đi lặp lại, phân tích kiến thức về miền vấn đề là liên tục trong
suốt vòng đời của dự án. Các nỗ lực mô hình hóa được tạo ra trong các vòng lặp đầu
tiên thường hời hợt. Sự trừu tượng hóa xuất hiện theo thời gian và phải được tái cấu
trúc và sử dụng vào trong mô hình. Để đạt được điều này cần duy trì một mối quan hệ
chặt chẽ, liên tục với các chuyên gia miền.

1.2.2. Ngôn ngữ chung
Yêu cầu đầu tiên của cách tiếp cận DDD là ngôn ngữ chung cho phép chuyên gia
miền và chuyên gia phần mềm có thể hiểu nhau và cộng tác với nhau [2]. Thông
thường, lập trình viên chỉ nghĩ tới lớp, phương thức, thuật toán và khuynh hướng diễn
đạt mọi vấn đề dưới dạng mã nguồn. Khi nhìn vào các đối tượng nào đó và quan hệ
mô hình giữa chúng, lập trình viên nghĩ đến kế thừa, đa hình, lập trình hướng đối
tượng,… Tuy nhiên, chuyên gia miền thường không hiểu những khái niệm đó. Để vượt
qua rào cản giao tiếp này, DDD khuyến khích xây dựng mô hình, trao đổi ý tưởng về
mô hình, về những thành phần liên quan đến mô hình. Giao tiếp tốt ở mức này rất quan
trọng cho sự thành công của dự án. Khi trao đổi về mô hình, có nhiều khái niệm
chuyên ngành rất dễ bị hiểu sai với người ngoài ngành. Vì vậy, cần có một từ điển
thuật ngữ dự án giải thích chi tiết các khái niệm đó, đảm bảo tất cả các bên liên quan
4


đến dự án đều hiểu đúng về mô hình.

kế và thường được phát triển bởi những người khác nhau. Nó được gọi là một mô hình
phân tích bởi vì nó là sản phẩm phân tích miền nghiệp vụ nhằm sắp xếp các khái niệm
mà không quan tâm đến các phần khác trong hệ thống phần mềm. Một mô hình phân
tích có ý nghĩa như là một công cụ để chỉ để hiểu miền vấn đề; việc kết hợp với cài đặt
sẽ làm sao nhãng việc tập trung vào phân tích vấn đề. Do đo, thiết kế được tạo ra có
thể chưa tương ứng với mô hình phân tích.
Một số kiến thức được xem xét, phân tích trong mô hình phân tích nhưng hầu hết
nó lại bị quên khi lập trình, khi nhà phát triển buộc phải đưa ra các trừu tượng hóa cho
5


thiết kế. Sau đó, không có gì đảm bảo rằng các thông tin chi tiết thu được từ chuyên
gia phân tích được nhúng vào mô hình, sẽ được lưu lại và tái sử dụng. Tại thời điểm
này, việc duy trì bất kì sự ánh xạ nào giữa thiết kế và mô hình là không hiệu quả chi
phí. Thậm chí, mô hình phân tích thuần túy còn thiếu mục tiêu chính của nó là hiểu
miền vấn đề do những khám phá quan trọng luôn xuất hiện trong quá trình thiết kế/cài
đặt. Kết quả là mô hình phân tích không được sử dụng ngay sau khi việc viết mã
nguồn bắt đầu và kiến thức nền tảng phải được xem xét lại [2].
Nếu thiết kế hoặc một số phần trung tâm của nó không ánh xạ lên mô hình miền
thì mô hình đó không mang lại giá trị lớn và tính chính xác của phần mềm vẫn còn bị
nghi ngờ. Đồng thời, các ánh xạ phức tạp giữa các mô hình và các chức năng thiết kế
rất khó hiểu và trên thực tế không thể duy trì khi thay đổi thiết kế.
Quá trình phân tích phải nắm bắt được các khái niệm cơ bản từ miền vấn đề theo
một cách dễ hiểu. Thiết kế phải xác định một tập các thành phần có thể được xây dựng
cùng với các công cụ lập trình được sử dụng trong dự án, các công cụ này sẽ thực hiện
trong môi trường triển khai đích một cách hiệu quả và giải quyết chính xác các vấn đề
đặt ra cho ứng dụng.
Thiết kế hướng mô hình loại bỏ sự phân tách giữa mô hình phân tích và mô hình
thiết kế để tìm ra một mô hình duy nhất phục vụ cả hai mục đích. Đặt vấn đề kỹ thuật
sang một bên, mỗi đối tượng trong thiết kế đóng vai trò một khái niệm được mô tả

niệm khác chỉ liên quan đến công nghệ phần mềm. Các kỹ thuật phức tạp cho sự cô lập
này đã xuất hiện. Đây là nền tảng vững chắc, quan trọng đối với việc áp dụng thành
công các nguyên tắc mô hình hóa miền từ quan điểm hướng miền [2].
Có rất nhiều cách phân chia một hệ thống phần mềm, nhưng trong ngành công
nghiệp phần mềm, kiến trúc phân tầng (layer) được sử dụng rộng rãi. Nguyên tắc cơ là
bất kỳ thành phần nào của một layer chỉ phụ thuộc vào các thành phần khác trong cùng
layer hoặc layer bên dưới. Mặc dù có nhiều biến thể nhưng hầu hết các kiến trúc thành
công đều sử dụng một số phiên bản của bốn layer khái niệm sau:

7


Hình 1.2: Kiến trúc phân lớp [2]
Tầng giao diện người dùng
Chịu trách nhiệm cho việc hiển thị thông tin cho người dùng và diễn giải các lệnh
của người dùng. Tác nhân bên ngoài đôi khi có thể là một hệ thống khác chứ không
phải con người.
Tầng ứng dụng
Định nghĩa các công việc mà phần mềm sẽ thực hiện và điều khiển các đối tượng
miền giải quyết các vấn đề. Các nhiệm vụ của layer này là phối hợp các xử lý cho
tương tác với các layer ứng dụng của các hệ thống khác.
Tầng nghiệp vụ
Chịu trách nhiệm cho việc biểu diễn các khái niệm, thông tin về nghiệp vụ trong
hệ thống. Logic nghiệp vụ được điều khiển và sử dụng ở đây, mặc dù các chi tiết kỹ
thuật lưu trữ nó được giao cho cơ sở hạ tầng.
Tầng cơ sở hạ tầng
Cung cấp khả năng kỹ thuật chung hỗ trợ các layer cao hơn như: gửi các bản tin
cho ứng dụng, sự tồn tại lâu bền cho miền, vẽ các widget cho UI, … Layer này cũng
có thể hỗ trợ mô hình tương tác giữa bốn layer thông qua một nền tảng kiến trúc. Khi
cơ sở hạ tầng được cung cấp dưới dạng các dịch vụ được gọi thông qua các giao diện

vụ [2]. Xác định các đối tượng nắm bắt các khái niệm miền dường như là rất trực quan
bên ngoài, nhưng ẩn dấu nhiều thử thách nghiêm trọng bên trong sắc thái ý nghĩa. Một
số khác biệt đã xuất hiện, làm rõ nghĩa của các thành phần mô hình và gắn vào khung
của thiết kế để tạo ra các loại đối tượng cụ thể. Một đối tượng có đại diện cho một thứ
gì đó có tính liên tục, có định danh và theo dõi được thông qua các trạng thái khác
nhau hoặc thậm chí các cài đặt khác nhau; hay nó là một thuộc tính mô tả trạng thái
của thứ gì khác. Đây là sự khác biệt cơ bản giữa thực thể và đối tượng của giá trị. Việc
xác định rõ ràng các đối tượng theo một pattern làm cho đối tượng ít mơ hồ hơn và
đưa ra phương hướng cho việc lựa chọn một thiết kế tốt nhất. Sau đó, các khía cạnh
của miền được thể hiện rõ ràng hơn dưới dạng hành động hoặc hoạt động chứ không
chỉ là đối tượng. Mặc dù là một xuất phát nhỏ từ mô hình hướng đối tượng truyền
thống, nhưng tốt nhất, thể hiện chúng dưới dạng các dịch vụ thay vì buộc phải gán
trách nhiệm cho một hoạt động trên thực thể hay đối tượng của giá trị. Một dịch vụ là
thứ gì đó được thực hiện do client theo yêu cầu.
Cuối cùng, mô-đun được sử dụng để dẫn đến quan điểm rằng mọi quyết định
thiết kế nên được thúc đẩy bởi một số hiểu biết sâu sắc về miền. Ý tưởng về sự gắn kết
chặt chẽ và gắn kết lỏng lẻo thường được coi là các tiêu chí kỹ thuật có thể được áp
dụng cho chính các khái niệm đó. Trong thiết kế hướng mô hình, mô-đun là một phần
của mô hình và chúng nên phản ánh các khái niệm trong mô hình.
Các liên kết
Sự tương tác giữa mô hình hóa và các cài đặt đặc biệt phức tạp do những liên kết
9


giữa các đối tượng. Một mô hình cho thấy liên kết giữa một khách hàng và đại diện
bán hàng tương ứng với hai thứ. Một là nó trừu tượng quan hệ giữa hai người thực, hai
là nó tương ứng với một con trỏ giữa hai đối tượng Java; hoặc một sự đóng gói của tra
cứu cơ sở dữ liệu. Ví dụ, một liên kết one-to-many có thể được cài đặt như một tập
hợp các instance của đối tượng. Nhưng thiết kế không cần thiết quá rõ ràng. Có thể
không có tập hợp nào; một phương thức truy nhập truy vấn cơ sở dữ liệu để tìm các

Một đối tượng đại diện cho một khía cạnh của miền, không có định danh về mặt
khái niệm được gọi là đối tượng của giá trị. Đối tượng của giá trị được khởi tạo để đại
diện cho các thành phần của thiết kế mà chỉ quan tâm chúng là cái gì và không quan
10


tâm chúng là ai. Ví dụ, trong phần mềm đặt hàng qua mạng, địa chỉ thư điện tử cần
được cung cấp để xác nhận thẻ tín dụng và thực hiện ship hàng. Dù là chủ tài khoản
hay không, chỉ cần biết được thông tin về địa chỉ thư điện tử thì đều đặt được hàng.
Các đối tượng của giá trị thậm chí có thể là các thực thể tham chiếu. Ví dụ, trong
phần mềm cho dịch vụ bưu chính, nhằm tổ chức các tuyến giao hàng, cây quốc gia có
thể được tạo theo phân cấp vùng, thành phố, mã khu vực bưu chính, lô và cuối cùng
địa chỉ. Các đối tượng địa chỉ sẽ lấy mã của mình trong cây quốc gia và nếu dịch vụ
bưu chính sẽ quyết định gán mã khu vực bưu chính, tất cả các địa chỉ trong đó sẽ cùng
đi trong một chuyến.
Khi cần quan tâm đến thuộc tính của một thành phần trong mô hình, hãy phân
loại nó thành một đối tượng của giá trị. Nhờ đó mà thể hiện ý nghĩa của thuộc tính mà
nó truyền tải và cung cấp cho nó chức năng liên quan. Hãy coi đối tượng của giá trị là
không thay đổi và không gán cho nó bất kì định danh nào nhằm tránh sự phức tạp
không cần thiết trong thiết kế để duy trì thực thể.
Dịch vụ
Sai lầm phổ biến nhất là từ bỏ dễ dàng việc đưa hành vi phù hợp với một đối
tượng cụ thể và dần trượt về phía lập trình thủ tục. Khi buộc một hoạt động vào một
đối tượng không phù hợp với định nghĩa của đối tượng thì đối tượng mất đi sự rõ ràng
của khái niệm và trở nên khó hiểu hoặc tái cấu trúc. Và do các hoạt động này thường
liên quan đến nhiều đối tượng miền nên việc kết hợp chúng và thêm vào các hành
động hay trách nhiệm sẽ tạo nên nhiều sự phụ thuộc vào tất cả các đối tượng đó, các
khái niệm không thể được hiểu một cách độc lập.
Một số khái niệm từ miền không tự nhiên để mô hình như các đối tượng. Việc ép
các chức năng được yêu cầu thành trách nhiệm của thực thể hay đối tượng của giá trị

Mô-đun và các thành phần nhỏ hơn nên cùng phát triển, nhưng thông thường lại
không như vậy. Mô-đun được chọn để tổ chức một dạng rất sớm của các đối tượng.
Sau đó, các đối tượng có xu hướng thay đổi theo cách giữa trong trong giới hạn định
nghĩa của mô-đun hiện có. Việc tái cấu trúc mô-đun trở nên vất vả hơn và rắc rối hơn
tái cấu trúc lớp và không thể làm thường xuyên. Nhưng cũng giống như các đối tượng
của mô hình có xu hướng bắt đầu là cụ thể và đơn giản, sau đó dần dần biến đổi để cho
thấy cái nhìn sâu sắc hơn, mô-đun có thể trở nên tinh tế và trừu tượng. Việc để các
mô-đun phản ánh sự thay đổi hiểu biết về lớp miền cũng cho phép đối tượng bên trong
chúng tự do phát triển.
Giống như các thành phần khác trong mô hình hướng miền, mô-đun là một cơ
chế trao đổi. Ý nghĩa của các đối tượng cần được phân vùng để thúc đẩy việc lựa chọn
các mô-đun. Nếu mô hình là một quyển sách thì các mô-đun là các chương. Tên của
mô-đun truyền tải ý nghĩa có nó.

1.2.6. Vòng đời của đối tượng miền
Mỗi đối tượng đều có một vòng đời. Một đối tượng được sinh ra, nó có thể trải
qua các trạng thái khác nhau và cuối cùng là nó được lưu trữ hoặc bị xóa đi khi kết
thúc vòng đời của mình. Một số đối tượng đơn giản được tạo ra bằng việc gọi hàm
khởi tạo của nó, được sử dụng trong một số tính toán và cuối cùng được bộ thu gom
rác truy tìm và xóa bỏ khỏi bộ nhớ khi chương trình không dùng đến; các đối tượng
này không cần làm phức tạp chúng. Nhưng các đối tượng có vòng đời dài hơn, có phụ
thuộc phức tạp với các đối tượng khác, chúng trải qua những thay đổi trạng thái cho
đến khi bất biến thì việc quản lý các đối tượng này là thử thách khi áp dụng thiết kế
hướng mô hình.

12


Hình 1.3: Vòng đời của đối tượng miền [2]
Những thử thách này chia thành hai loại:

miền và các nhóm phát triển để phát triển mô hình miền một cách tăng dần, hợp tác và
tương tác. Cách sử dụng thứ hai là nguyên mẫu sẽ được tái sử dụng trong giai đoạn sau
để phát triển ra phần mềm thương mại.
Hình 1.4 mô tả DDSDM bao gồm các pha sau:





Pha 1: Phát triển mô hình miền khái niệm
Pha 2: Định nghĩa các vòng lặp phát triển
Pha 3: Thực hiện các vòng lặp để phát triển một tập các nguyên mẫu phần mềm
Pha 4: Tích hợp các nguyên mẫu phần mềm để tạo ra nguyên mẫu cuối cùng.

Hình 1.4: Tổng quan về phương pháp phát triển phần mềm hướng miền [5]

1.3.1. Phát triển một mô hình miền khái niệm
Đây là một mô hình miền ở mức cao, sẽ được sử dụng làm điểm khởi đầu cho
quá trình phát triển. Mô hình này được sử dụng để định nghĩa ra các vòng lặp phát
triển, hiệu suất phát triển và dần dần làm phong phú thêm mô hình miền với tính năng
chi tiết mới.
Mô hình miền ở mức cao chỉ bao gồm các lớp miền lõi (có cấu trúc không hoàn
thiện) và các liên kết ban đầu giữa các lớp miền đó. Các lớp miền và liên kết này được
xác định từ yêu cầu chức năng của phần mềm. Các yêu cầu đó thường được mô tả dưới
dạng các ca sử dụng.
Về nguyên tắc, mỗi chức năng được xác định từ một tập các lớp miền liên quan
trong mô hình gọi là mô hình con. Hình 1.4 mô tả các yêu cầu chức năng sử dụng mô
hình ca sử dụng. Mỗi ca sử dụng được kết nối tới một mô hình con của mô hình miền.
Ranh giới của mỗi mô hình con được biểu diễn bởi một hình ô-van đây có chứa một
14

kiểm thử để tạo ra một nguyên mẫu phần mềm của một mô hình con. Thông qua các
vòng lặp này, các mô hình con trở nên phong phú hơn với các tính năng chi tiết hơn
bao gồm các lớp miền mới, các thuộc tính và phương thức mới.
Thực tế là các vòng lặp được thực hiện lặp đi lặp lại trên các mô hình phần mềm
(mô hình chức năng và mô hình miền) bằng cách đóng gói chu trình phát triển bao
hàm cả mô hình ca sử dụng và mô hình miền. Tính năng chính của chu trình phát triển
DDSDM là ở chỗ các vòng lặp phát triển có thể được tổ chức để thực hiện song song
do các mô hình con của chúng (mặc dù có chồng lên nhau) chủ yếu thực hiện các yêu
cầu chức năng khác nhau.

1.3.4. Tích hợp các nguyên mẫu phần mềm
Khi các vòng lặp phát triển được hoàn thành, tạo ra một tập các nguyên mẫu cho
các mô hình con thì pha cuối cùng là tích hợp các nguyên mẫu này. Mục tiêu của việc
15


tính hợp này: thứ nhất, tạo ra mô hình miền cuối cùng ;và thứ hai, tạo ra một nguyên
mẫu hoàn chỉnh. Tích hợp phần mềm thu được một cách dễ dàng trong DDSDM nhờ
khả năng của công cụ hỗ trợ phát triển phần mềm DomainAppTool do cùng các tác giả
của DDSDM xây dựng. Khi các mô hình con được làm phong phú thêm nhờ các vòng
lặp, chúng sẽ hợp với nhau bằng cách sử dụng các lớp miền chia sẻ và/hoặc thông qua
việc xác định các liên kết mới kết nối các lớp miền trong mô hình con.
Bởi vì tất cả các chức năng phần mềm đã được tính toán bằng các vòng lặp nên
không cần thiết thực hiện bất kỳ phân tích, thiết kế và lập trình nào nữa trong pha này.
Hoạt động duy nhất phải thực hiện trong pha này là kiểm thử để đảm bảo toàn các
chức năng của nguyên mẫu phần mềm là chính xác (nghĩa là tất cả các phần của nó
hoạt động với nhau một cách chính xác).

1.4. Công cụ hỗ trợ phát triển phần mềm hướng miền
DomainAppTool là một công cụ phát triển phần mềm Java thuần túy, được sử

Quản lý mô hình
Thành phần này chịu trách nhiệm xử lý các lớp miền. Một lớp miền là một lớp
Java được thiết kế với các tính năng thiết kế hướng miền. Mỗi lớp nắm giữ các yêu cầu
miền của một khái niệm hoặc một thực thể quan tâm đến phần mềm. Các lớp miền
được xác định như đầu vào khi chạy công cụ.
Một tính năng chính của công cụ là nó chỉ yêu cầu nhà phát triển xác định tập các
lớp miền của một phần mềm. Toàn bộ phần mềm bao gồm giao diện đồ họa GUI và
lưu trữ đối tượng sẽ được tạo ra một cách tự động tại thời điểm chạy.
Quản lý hiển thị
Phần mềm do công cụ tạo ra có giao diện đồ họa GUI, giúp người dùng dễ dàng
thực hiện các chức năng của phần mềm. Giao diện GUI này được tạo ra một cách tự
động tại thời điểm chạy từ thông tin thiết kế được nhúng trong các lớp miền của phần
mềm và quản lý hiển thị là thành phần chịu trách nhiệm cho nhiệm vụ này.
Về nguyên tắc, quản lý hiển thị cung cấp một desktop manager cho việc quản lý
các biểu mẫu đối tượng khác nhau, một thư viện các thành phần dựa trên Java Swing
được sử dụng để tạo ra các biểu mẫu đó. Biểu mẫu đối tượng là thành phần then chốt
trong việc cung cấp một giao diện cho phép người dùng xem và thao tác trên các đối
tượng miền của một lớp miền.
Quản lý đối tượng
Thành phần này chịu trách nhiệm quản lý các đối tượng miền của phần mềm.
Quản lý đối tượng quản lý hiệu quả các đối tượng trong bộ nhớ trong và cung cấp một
cơ chế để lưu trữ các đối tượng trong bộ nhớ ngoài.
Hiện tại, công cụ DomainAppTool đã hỗ trợ hệ thống quản trị cơ sở dữ liệu quan
hệ Java DB, được cung cấp với nền tảng Java. Cơ sở dữ liệu được tạo một cách tự
động cho phần mềm trong lần chạy đầu tiên. Schema của cơ sở dữ liệu được tạo từ các
thông tin thiết kế nhúng trong các lớp miền của phần mềm. Tại thời điểm chạy, các đối
tượng miền của phần mềm được chuyển đổi thành các bản ghi và được lưu trữ trong
cơ sở dữ liệu này.

1.4.3. Ví dụ điển hình: CourseMan

tự chọn. Ngoài các thuộc tính chung, một mô-đun tự chọn được đặc trưng bởi thuộc
tính tên của khoa (deptName) giảng dạy mô-đun đó. Khoa này có thể khác với khoa
mà sinh viên đang theo học.
Sự ghi danh (enrolment) thực tế là sinh viên đăng ký học một mô-đun khóa học
cụ thể trong một kỳ nhất định. Nó lưu các dữ liệu về điểm quá trình, điểm cuối kỳ và
điểm trung bình của sinh viên trong từng mô-đun. Điểm trung bình là một ký tự đơn
thuộc một trong các thành phần sau: “E”- Giỏi, “G”- Khá, “P”- Trung bình, “F”- Yếu.

1.4.4. Phát triển các lớp miền
Phần này sẽ giải thích cách phát triển các lớp miền sử dụng các tính năng DDD.
Tổng quan thiết kế
Lớp miền là lớp được thiết kế với thông tin chuyên biệt miền. Các nền tảng ngôn
ngữ hướng đối tượng hiện tại (ví dụ : .NET và Java) cung cấp hỗ trợ đặc tả các thông
tin đó như một phần của thiết kế lớp. Ý tưởng là mô hình hóa thông tin chuyên biệt
miền như một tập các meta-attribute, có thể được gắn vào lớp, vào các thành viên của
lớp hoặc cả hai. Một meta-attribute là một tập các thuộc tính có giá trị cụ thể khi thuộc
tính được đính kèm.
Trong DomainAppTool, năm meta-attribute cơ bản được sử dụng để mô hình
hóa một lớp miền là DClass, Dattr, DAssoc, DOpt, AttrRef. Trong đó, DClass được
đính kèm vào lớp, còn các thuộc tính khác được đính kèm vào thành viên của lớp. Một
18