ĐẠ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

Vũ Thanh Hà

i


LỜI CẢM ƠN
Để hoàn thành đƣợc luận văn thạc sĩ, bên cạnh sự nỗ lực của bản thân cịn có sự
hƣớng dẫn nhiệt tình của q Thầy Cơ, cũng nhƣ sự động viên ủng hộ của gia đình và
bạn bè trong suốt quá trình nghiên cứu và thực hiện luận văn.
Tơi xin chân thành bày tỏ lịng biết ơn sâu sắc đến Thầy TS. Đặng Đức Hạnh,
ngƣời đã tận tình hƣớng dẫn và tạo mọi điều kiện tốt nhất cho tơi hồn thành luận văn
này. Xin chân thành cảm ơn các thầy cô khoa Công nghệ thông tin, Trƣờng đại học
Công Nghệ đã truyền đạt những kiến thức quý báu cũng nhƣ giúp đỡ tơi trong q
trình học tập nghiên cứu tại trƣờng.
Cuối cùng, xin gửi lời cảm ơn đến gia đình, bạn bè, đồng nghiệp, những ngƣời
đã hỗ trợ tơi trong suốt q trình học tập, nghiên cứu và thực hiện luận văn.
Học viên thực hiện

Vũ Thanh Hà

ii


MỤC LỤC
Trang
LỜI CAM ĐOAN .............................................................................................................i
LỜI CẢM ƠN ................................................................................................................. ii
MỤC LỤC ..................................................................................................................... iii
DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT ....................................................v
DANH SÁCH CÁC HÌNH VẼ ......................................................................................vi

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

2.2. Mô tả yêu cầu cho Plug-in ..................................................................................31
2.3. Mơ hình thiết kế Eclipse Plugin cho phần mềm hƣớng miền ............................. 34
2.3.1. Mơ hình thiết kế UML cho Eclipse Plugin ................................................... 34
2.3.2. Thuật toán sinh phƣơng thức và Thuật toán sinh module phần mềm .........36
2.3.3 Thuật toán sinh cấu hình phần mềm SWC .................................................... 40
2.4. Cài đặt chi tiết thiết kế plug-in ............................................................................42
2.5. Tổng kết chƣơng .................................................................................................48
CHƢƠNG 3. CÀI ĐẶT VÀ THỰC NGHIỆM ............................................................. 49
3.1. Giới thiệu chƣơng ............................................................................................... 49
3.2. Môi trƣờng cài đặt ............................................................................................... 49
3.3. Bài tốn quản lý khóa học ................................................................................... 49
3.4. Kết quả thực nghiệm ........................................................................................... 52
3.5. Tổng kết chƣơng .................................................................................................64
KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN ....................................................................65
TÀI LIỆU THAM KHẢO ............................................................................................. 66

iv


DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
Từ viết tắt

Ý nghĩa

Thuật ngữ

API

Application Programming Interface


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


Lớp cấu hình mơ đun phần mềm

MVC

Model View Controller

Mơ hình thiết kế phần mềm

OSGi

Open Service Gateway Initiative

PDE

Plug-in Development Environment

RCP

Rich Client Platform

SWC

Software Configuartion

Nền tảng lập trình các ứng dụng
Desktop
Cấu hình phần mềm

SWT


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 1.5: Thiết kế cơ bản các lớp miền của phần mềm CourseMan
Hình 1.6: Áp dụng meta-attribute DAssoc cho ba liên kết của CourseMan
Hình 1.7: Kiến trúc mở của Eclipse
Hình 1.8: Hoạt động của plug-in
Hình 2.1: Các thử thách cho DSL dựa trên annotation
Hình 2.2: Biểu đồ tuần tự cho plug-in
Hình 2.3: Biểu đồ lớp cho plug-in
Hình 2.4: Biểu đồ triển khai cho plug-in
Hình 2.5: Mơ hình kiến trúc phần mềm COURSEMAN
Hình 2.6: Các bước xây dựng Plug-in
Hình 2.7: Màn hình nhập thơng tin ban đầu Plug-in mới
Hình 2.8: Màn hình chọn Template cho Plug-in mới
Hình 2.9: Màn hình dự án Plug-in mới đã tạo
Hình 2.10: Màn hình Extensions
Hình 2.11: Màn hình tạo các command
Hình 2.12: Màn hình khai báo các handlers
Hình 2.13: Màn hình khai báo các bindings
Hình 2.14: Màn hình khai báo vị trí của các item mới trên menu
Hình 3.1: Mơ hình ca sử dụng của CourseMan
Hình 3.2: Mơ hình miền khái niệm và các mơ hình con của CourseMan
Hình 3.3: Đầu vào của thực nghiệm
Hình 3.4: Giao diện menu sinh phương thức cho lớp miền
Hình 3.5: Giao diện menu sinh cấu hình mơ-đun phần mềm
Hình 3.6: Cấu hình mơ-đun phần mềm được sinh ra
Hình 3.7: Giao diện menu sinh cấu hình mơ-đun phần mềm
Hình 3.8: Cấu hình phần mềm SWC1 được sinh ra
Hình 3.9: Cấu hình phần mềm SWC1 được sinh ra
Hình 3.10: Cấu hình Run Configurations để chạy mã nguồn
Hình 3.11: Giao diện phần mềm CourseMan
Hình 3.12: Giao diện các form của CourseMan trong vịng lặp đầu tiê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 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

phần mềm, toàn bộ phần mềm bao gồm giao diện đồ họa ngƣời dùng và đối tƣợng lƣu
trữ sẽ đƣợc tạo ra tự động vào thời gian chạy. Tuy nhiên, một trong những hạn chế của
cơng cụ là chƣa có giao diện ngƣời dùng, ngƣời sử dụng phải thực hiện thủ công một
loạt các lệnh command line để tạo ra phần mềm. Phát triển phần mềm là một quá trình
lặp đi lặp lại để sinh ra phần mềm cuối cùng. Trong mỗi vịng lặp phát triển, nếu sử
dụng cơng cụ thì ngƣời dùng lại phải thực hiện các lệnh đó, gây ra khơng ít khó khăn
và tốn nhiều thời gian. Vì vậy, tôi xin chọn đề tài “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” . Mục tiêu của
luận văn là tạo ra một gói mở rộng plug-in cài trên cơng cụ hỗ trợ lập trình Eclipse cho
DomainAppTool. Từ đó, các chức năng của nó sẽ đƣợc trực quan hóa, ngƣời dùng có
thể sử dụng bất kỳ khi nào trong q trình phát triển phần mềm. Điều này có ý nghĩa
quan trọng giúp cho công cụ hỗ trợ phát triển phần mềm hƣớng miền đƣợc sử dụng
rộng rãi hơn.
1


Trong luận văn, tơi tập trung vào trình bày chi tiết hai đóng góp của mình là xây
dựng thuật tốn tạo ra cấu hình phần mềm và xây dựng gói Eclipse plug-in; cuối cùng
là các bƣớc thực hiện thực nghiệm và kết quả đạt đƣợc. Về phần bố cục, luận văn
đƣợc chia thành ba chƣơng chính nhƣ sau:
Chƣơng 1. Kiến thức nền tảng : 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: Thiết kế hƣớng miền, phƣơng pháp phát
triển phần mềm hƣớng miền, công cụ hỗ trợ phát triển phần mềm hƣớng miền và thành
phần mở rộng Eclipse Plug-in.
Chƣơng 2. Xây dựng Eclipse Plug-in cho phần mềm hƣớng miền : Trình bày
mơ hình thiết kế Plugin và cài đặt chi tiết của thiết kế. Các thuật toán tự động sinh
phƣơng thức cho lớp miền và cấu hình mơ-đun phần mềm cũng đƣợc giới thiệu nhƣng
trọng tâm tập trung vào trình bày chi tiết thuật tốn sinh cấu hình phần mềm.
Chƣơng 3. Cài đặt và thực nghiệm : Trình bày các u cầu về mơi trƣờng cài
đặt thực nghiệm, bài tốn thực nghiệm và cuối cùng là các kết quả đạt đƣợc.


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 ngun 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ể.

Điều này có nghĩa là thiết kế mọi thứ xung quanh hiểu biết và quan niệm về hầu hết
các khái niệm cần thiết của nghiệp vụ, chứng minh cho bất kỳ sự phát triển nào khác
bằng cách nó hỗ trợ miền lõi đó nhƣ thế nào.

1.2.1. Kiến thức về miền vấn đề
Phát triển phần mềm là quy trình xây dựng ra phần mềm để giải quyết các bài
toán nghiệp vụ thực tế hay miền vấn đề. Phần mềm bắt nguồn và liên quan chặt chẽ
với miền này. Mặt khác, phần mềm đƣợc làm từ mã nguồn. Nhà phát triển thƣờng sa
đà vào việc dành nhiều thời gian tạo ra mã nguồn và nhìn phần mềm nhƣ các đối
tƣợng và phƣơng thức đơn giản [2].
Xem xét ví dụ sản xuất ô tô [1]. Công nhân liên quan trực tiếp đến việc lắp ráp
linh kiện ơ-tơ có góc nhìn hạn chế về quy trình sản xuất một chiếc ơ tơ. Họ coi ô tô là
một tập khổng lồ những linh kiện và cần lắp ráp chúng với nhau; thực ra quy trình tạo
3


ra một chiếc ô tô phức tạp hơn thế nhiều. Một chiếc xe tốt bắt nguồn từ một tầm nhìn
và nó đƣợc đặc tả một cách chi tiết, tiếp theo là thiết kế (rất, rất nhiều thiết kế). Sau
nhiều tháng, thậm chí có thể vài năm; thiết kế đó lại đƣợc thay đổi, cải tiến cho tới khi
thiết kế trở nên hồn hảo nhất. Q trình thiết kế có thể không làm luôn trên giấy,
nhiều phần thiết kế bao gồm việc mơ hình hóa và kiểm thử dƣới điều kiện cụ thể để
xem xe hoạt động hay khơng. Sau đó, thiết kế đƣợc thay đổi theo kết quả kiểm thử.
Cuối cùng, chiếc xe đƣợc đƣa vào sản xuất bao gồm sản xuất linh kiện và lắp ráp
chúng vào nhau. Việc phát triển phần mềm cũng tƣơng tự nhƣ vậy, không thể tạo ra
phần mềm phức tạp mà chỉ ngồi viết mã nguồn. Để tạo ra phần mềm tốt, nhà phát triển
cần hiểu về miền vấn đề mà phần mềm cần giải quyết thông qua việc trao đổi với
chuyên gia miền. Những kiến thức thô về nghiệp vụ không dễ dàng chuyển hóa thành
cấu trúc phần mềm trừ khi miền đƣợc “trừu tƣợng hóa”. “Trừu tƣợng hóa” miền vấn
đề là việc xây dựng một mơ hình miền. Theo Eric Evans, một mơ hình miền khơng
phải là một giản đồ cụ thể, quan trọng là ý tƣởng mà giản đồ đó muốn truyền đạt; quan

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 ngồ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.

Ngun tắc cốt lõi của thiết kế hƣớng miền là sử dụng ngơn ngữ dựa trên mơ
hình. Vì mơ hình là xuất phát điểm chung, là đầu vào cho phần mềm giải quyết miền
vấn đề. Ngôn ngữ chung kết nối mọi phần của thiết kế cũng nhƣ hoạt động của nhóm
phát triển.

1.2.3. Rằng buộc mơ hình và cài đặt
Đối tƣợng điển hình trong mơ hình có các liên kết phức tạp với các đối tƣợng
khác và mạng lƣới liên kết này có một vài đƣờng biên tự nhiên. Khi nhà phát triển bắt
đầu cài đặt ứng dụng, họ nhanh chóng phát hiện ra rằng mớ hỗn độn các liên kết không
chuyển thành các đơn vị có thể lƣu trữ, có thể phục hồi và đảm bảo tính tồn vẹn dữ
liệu [2]. Nếu dự án sử dụng cơ sở dữ liệu đối tƣợng thì nhà phát triển thậm chí phải đối
mặt với những thách thức của việc ánh xạ các đối tƣợng vào các bảng quan hệ. Ở mức
độ cơ bản, mơ hình khơng cung cấp hƣớng dẫn để cài đặt.
Mơ hình là “chính xác” nếu là kết quả của sự cộng tác chặt chẽ giữa chuyên gia
nghiệp vụ và nhà phân tích kỹ thuật. Tuy nhiên, các nhà phát triển đã đi đến kết luận
rằng các đối tƣợng dựa trên khái niệm khơng thể là nền tảng thiết của họ [2]. Vì vậy,
họ tiến hành phát triển thiết kế sử dụng một vài tên lớp và thuộc tính giống nhau cho
việc lƣu trữ dữ liệu, nhƣng nó khơng dựa trên bất kì mơ hình đang tồn tại.
Dự án có một mơ hình miền nhƣng mơ hình chỉ tốt trên giấy trừ khi nó trực tiếp
trợ giúp sự phát triển phần mềm. Mơ hình đến từ nhiều nguồn và phục vụ nhiều vai
trị, thậm chí những vai trị đƣợc giới hạn trong từng hoàn cảnh của một dự án phát
triển phần mềm. Thiết kế hƣớng miền đề xuất một mơ hình khơng chỉ hỗ trợ phân tích
sớm mà cịn là nền tảng của thiết kế. Việc liên kết chặt chẽ mã nguồn với một mơ hình
bên dƣới mang lại ý nghĩa lớn cho mã nguồn, đồng thời làm cho mơ hình trở nên thích
hợp. Nhiều dự án phức tạp áp dụng một số mơ hình miền nhƣng khơng duy trì kết nối
chặt chẽ giữa mơ hình và mã nguồn. Mơ hình đƣợc phát triển có thể hữu ích nhƣ một
cơng cụ thăm dị ban đầu nhƣng nó ngày càng trở nên khơng liên quan đến mã nguồn
và thậm chí gây hiểu lầm khi mã nguồn khơng gắn chặt với mơ hình.
Thiết kế hƣớng mơ hình
Nhiều phƣơng pháp thiết kế ủng họ mơ hình phân tích khá khác biệt so với thiết

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ị qn 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 ln xuất hiện trong q 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ế.
Q 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ả

trong mơ hình.
Có nhiều cách trừu tƣợng hóa một miền và cũng có nhiều cách thiết kế có thể
giải quyết vấn đề của ứng dụng. Đây chính là thứ làm cho việc liên kết chặt chẽ mơ
hình và thiết kế trở nên thực tế. Liên kết này khơng khiến cho mơ hình phân tích bị suy
yếu, tổn hại bởi việc xem xét các yếu tố kỹ thuật; hay phải chấp nhận các thiết kế phản
ánh ý tƣởng miền vụng về nhƣng không sử dụng các nguyên tắc thiết kế phần mềm.
Khi một mô hình dƣờng nhƣ khơng phù hợp với thực tế cài đặt hoặc không thể hiện
một cách trung thực các khái niệm thì mơ hình đó nên đƣợc thay thế. Do đó, quy trình
mơ hình hóa và thiết kế trở thành một vòng lặp tiếp tục. Yêu cầu liên kết chặt chẽ giữa
mơ hình miền và thiết kế cung cấp thêm một tiêu chí cho việc lựa chọn các mơ hình
hữu ích trong vơ số mơ hình có thể có.
Từ mơ hình, thuật ngữ đƣợc sử dụng trong thiết kế và phân công công việc. Mã
nguồn trở thành sự thể hiện của mơ hình, vì vậy, một sự thay đổi mã nguồn có thể là
một thay đổi mơ hình. Ảnh hƣởng của nó chắc chắn sẽ lan ra hoạt động cịn lại của dự
án. Việc gắn cài đặt với mơ hình thƣờng yêu cầu các công cụ và ngôn ngữ phát triển
phần mềm hỗ trợ mơ hình hóa nhƣ lập trình hƣớng đối tƣợng.
Thiết kế hƣớng mơ hình là trái tim của thiết kế hƣớng miền [2]. Hình 1.1. mơ tả
các thành phần cơ bản cấu thành nên thiết kế hƣớng mơ hình.

6


Hình 1.1: Các thành phần cơ bản của thiết kế hướng mơ hình [2]
Trong các phần tiếp, các thành phần cơ bản này sẽ đƣợc trình bày một cách chi tiết.

1.2.4. Cô lập miền
Trong phần mềm, việc giải quyết các vấn đề cụ thể từ miền thƣờng chỉ chiếm
một phần nhỏ trong tồn bộ phần mềm mặc dù nó rất quan trọng. Các thành phần của
mơ hình cần đƣợc xem xét nhƣ một hệ thống và các đối tƣợng miền cần đƣợc tách biệt
khỏi các chức năng khác của hệ thống để tránh gây nhầm lẫn khái niệm miền với khái

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 ngồ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

thì nó khá trực quan (layer làm việc nhƣ thế nào và làm sao để duy trì liên kết lỏng lẻo
giữa các layer). Nhƣng một số vấn đề kỹ thuật đòi hỏi nhiều dạng cơ sở hạ tầng hơn
nên các nền tảng tích hợp nhiều cơ sở hạ tầng thƣờng đƣợc yêu cầu cho các layer khác.
Khi áp dụng một nền tảng, các mục tiêu phải cần đƣợc tập trung là xây dựng một cài
đặt thể hiện cho một mơ hình miền và sử dụng nó để giải quyết các vấn đề.
Kiến trúc phân tầng đƣợc sử dụng trong hầu hết các hệ thống hiện nay theo các
sơ đồ phân tầng khác nhau. Tuy nhiên, thiết kế hƣớng miền chỉ yêu cầu một tầng cụ
thể phải tồn tại đó là tầng nghiệp vụ.
8


Mơ hình miền là một tập hợp các khái niệm. Tầng nghiệp vụ là sự thể hiện của
mơ hình đó và tất cả các thành phần thiết kế trực tiếp liên quan đến. Thiết kế và cài đặt
logic nghiệp vụ tạo thành tầng nghiệp vụ. Trong thiết kế hƣớng mô hình, các cấu trúc
phần mềm của tầng nghiệp vụ phản ánh các khái niệm mơ hình. Nói cách khác, mơ
hình đƣợc tồn tại trong tầng nghiệp vụ.
Để thu đƣợc mô hình miền trong khi logic miền đƣợc trộn lẫn với các mối quan
tâm khác của chƣơng trình là khơng thực tế. Việc cô lập cài đặt miền là một điều kiện
tiên quyết cho thiết kế hƣớng miền.

1.2.5. Mơ hình được thể hiện trong phần mềm
Để hài hòa với cài đặt mà không làm mất điểm mạnh của một thiết kế hƣớng mơ
hình u cầu phải tập hợp lại các nền tảng cơ bản. Kết nối mơ hình và cài đặt phải
đƣợc thực hiện trong nhiều mức chi tiết. Đầu tiên là những vấn đề liên quan đến thiết
kế và tinh giảm các liên kết. Liên kết giữa các đối tƣợng rất đơn giản để tƣởng tƣợng
và vẽ ra, nhƣng cài đặt chúng là một vũng lầy tiềm ẩn. Các liên kết minh họa các quyết
định triển khai chi tiết, quan trọng đối với khả năng tồn tại của thiết kế hƣớng mơ hình.
Tự mình chuyển sang đối tƣợng, nhƣng tiếp tục xem xét mối quan hệ giữa các
lựa chọn mô hình chi tiết và các mối quan tâm đến cài đặt, ba mẫu của các thành phần
mơ hình đƣợc sử dụng để thể hiện mơ hình: thực thể, đối tƣợng của giá trị và các dịch

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

bản ghi phù hợp và khởi tạo các đối tƣợng dựa trên chúng. Tất cả thiết kế cùng phản
ánh cùng mơ hình. Thiết kế phải xác định một cơ chế truyền tải cụ thể mà hành vi của
nó nhất quán với liên kết trong mơ hình.
Các thực thể
Thực thể đƣợc biết đến là đối tƣợng tham chiếu. Nhiều đối tƣợng không đƣợc
xác định một cách cơ bản bởi các thuộc tính của chúng mà bởi một chuỗi liên tục và
định danh. Ví dụ, một ngƣời có định danh kéo dài từ khi sinh ra đến khi chết đi và
thậm chí sau đó. Các thuộc tính vật lý của ngƣời đó biến đổi và cuối cùng biến mất,
thuộc tính của ngƣời có thể thay đổi nhƣng danh tính ln tồn tại. Mơ hình hóa đối
tƣợng có xu hƣớng tập trung các thuộc tính của một đối tƣợng nhƣng khái niệm cơ bản
của một thực thể là một chuỗi liên tục trừu tƣợng hóa qua một vịng đời và thậm chí đi
qua nhiều trạng thái. Đối tƣợng đại diện cho một chuỗi định danh qua thời gian. Đôi
khi, một đối tƣợng phải đƣợc khớp với một đối tƣợng khác mặc dù thuộc tính của
chúng khác nhau. Một đối tƣợng phải đƣợc phân biệt với đối tƣợng khác dù chúng có
thể có cùng thuộc tính. Nhần lẫn định danh có thể dẫn tới những sai hỏng dữ liệu.
Các đối tƣợng của giá trị
Do các đối tƣợng dễ thấy nhất trong mơ hình thƣờng là thực thể và việc theo dõi
mỗi định danh của thực thể là rất quan trọng, nên xem xét việc gán 1 thực thể cho tất
cả đối tƣợng miền. Một số nền tảng gán một định danh duy nhất cho tất cả đối tƣợng.
Hệ thống phải thực hiện tất cả công việc theo dõi; và nhiều tối ƣu hiệu năng đƣợc
loại bỏ. Cần nỗ lực phân tích để xác định các định danh có ý nghĩa và tìm ra cách đơn
giản để theo dõi đối tƣợng trên các hệ thống phân tán hoặc trong lƣu trữ cơ sở dữ liệu.
Quan trọng không kém là những định danh giả làm rối loạn mơ hình, gây ra những
nhầm lẫn.
Theo dõi định danh của thực thể là cần thiết, nhƣng gắn định danh cho các đối
tƣợng khác có thể làm giảm hiệu năng hệ thống, thêm cơng việc phân tích và làm rối
loạn mơ hình do tất cả các đối tƣợng trông giống nhau. Thiết kế phần mềm là một trận
chiến liên tục với sự phức tạp. Cần phải tạo ra sự khác biệt để áp dụng xử lý đặc biệt
khi cần thiết. Trong thực tế, các đối tƣợng này có đặc điểm riêng và ý nghĩa riêng đối
với mơ hình.

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ị

sẽ gây ra méo mó định nghĩa của đối tƣợng dựa vào mơ hình hoặc thêm vào các đối
tƣợng giả vơ nghĩa. Một dịch vụ là một hoạt động đƣợc cung cấp nhƣ một giao diện
độc lập trong mơ hình mà khơng đóng gói trạng thái nhƣ thực thể và đối tƣợng của giá
trị. Dịch vụ là một mơ hình chung trong các nền tảng kỹ thuật nhƣng chúng cũng có
thể áp dụng trong tầng nghiệp vụ (domain layer). Tên của dịch vụ nhấn mạnh mối
quan hệ với các đối tƣợng khác. Dịch vụ vẫn có thể là một định nghĩa trừu tƣợng. Một
dịch vụ vẫn nên có trách nhiệm rõ ràng; trách nhiệm đó và giao diện thực hiện nên
đƣợc định nghĩa nhƣ một phần của mơ hình miền. Các tham số và kết quả nên là các
đối tƣợng miền.
Một dịch vụ tốt có ba đặc tính:
 Hoạt động liên quan đến khái niệm miền khơng phải là thành phần vốn có của
một thực thể hay một đối tƣợng của giá trị.
 Giao diện đƣợc định nghĩa dƣới dạng các thành phần khác của mơ hình miền.
 Hoạt động khơng có trạng thái.
11


Các mơ-đun
Mơ-đun đƣợc sử dụng nhƣ một phần chính thức của mơ hình. Mã nguồn đƣợc
chia nhỏ thành tất cả các danh mục, từ khía cạnh kiến trúc kỹ thuật đến nhiệm vụ đƣợc
giao của nhà phát triển. Sự thật là nên có sự liên kết lỏng lẻo giữa các mô-đun và sự
gắn kết cao bên trong chúng.
Liên kết lỏng lẻo (low coupling) và gắn kết cao (high cohension) là các nguyên
tắc thiết kế chung, áp dụng nhiều cho các đối tƣợng riêng lẻ nhƣ mô-đun, nhƣng chúng
đặc biệt quan trong trong mơ hình hóa và thiết kế hƣớng miền. Bất cứ khi nào hai phần
tử của mơ hình đƣợc tách thành các mơ-đun khác nhau thì mối quan hệ giữa chúng trở
nên ít trực tiếp hơn so với giải pháp ban đầu (tăng chi phí hiểu vị trí của chúng trong
mơ hình). Liên kết lỏng lẻo giữa các mơ-đun tối thiểu hóa chi phí này và có thể phân
tích nội dung của một mô-đun với mức độ tham chiếu đến mơ-đun khác (mà nó tƣơng
tác) là ít nhất.

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 tố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:

 Duy trì tính tồn vẹn trong suốt vịng đời.
 Ngăn chặn mơ hình khỏi sa lầy vào sự phức tạp của quản lý vòng đời.
Các vấn đề này sẽ đƣợc giải quyết thông qua ba pattern: Aggregates, Factories,
Repositories.
Aggregates
Pattern này rất quan trọng để duy trì tính tồn vẹn trong tất cả các pha của vịng
đời. Nó thắt chặt mơ hình nhờ việc định nghĩa rõ ràng quyền sở hữu và các ranh giới,
tránh sự hỗn loạn và rắc rối trong đối tƣợng.
Factories
Pattern này đƣợc sử dụng để tạo và tái tạo các đối tƣợng phức tạp trong giai đoạn
đầu của vòng đời, giữ cho cấu trúc bên trong của chúng đƣợc đóng gói.
Repositories
Pattern này thực hiện ở giữa và cuối vòng đời, cung cấp các phƣơng pháp tìm
kiếm và truy xuất các đối tƣợng cùng với đóng gói tất cả cơ sở hạ tầng liên quan.
Mặc dù repositories và factories không tự xuất phát từ miền nhƣng chúng có vai
trị ý nghĩa trong thiết kế miền. Những pattern này hoàn thiện thiết kế hƣớng mơ hình
nhờ việc cung cấp các xử lý, có thể truy cập đƣợc đến các đối tƣợng mơ hình. Mơ hình
hóa aggregates và bổ sung factories, repositories vào thiết kế sẽ cung cấp khả năng
thao tác với các đối tƣợng mơ hình một cách hệ thống trong suốt vịng đời của chúng.
Aggregates đánh dấu phạm vi mà trong đó các bất biến phải đƣợc duy trì ở mọi giai
đoạn của vịng đời. Factories và Repositories hoạt động trên aggregates, đóng gói sự
phức tạp của các q trình chuyển đổi trạng thái trong vòng đời cụ thể.

1.3. Phƣơng pháp phát triển phần mềm hƣớng miền DDSDM
DDSDM là một phƣơng pháp phát triển lặp cho việc phát triển các nguyên mẫu
phần mềm từ mơ hình miền do nhóm tác giả [5] đề xuất. Các nguyên mẫu này đƣợc sử
13


dụng theo hai cách: Cách sử dụng đầu tiên và cũng là chủ yếu dành cho các chuyên gia

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
q 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 hồ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 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



hoặc nhiều lớp miền cùng với liên kết giữa chúng (nếu có). Ví dụ, ca sử dụng F1 đƣợc
kết nối đến mơ hình con chứa hai lớp miền (tên là Cz và Cw) cùng với kết nối giữa
chúng. Các mô hình con của hai chức năng chồng lên nhau ở một lớp miền đƣợc chia
sẻ và/hoặc một liên kết giữa các hai lớp miền của hai mơ hình con. Thơng qua các
điểm chồng lẫn này mà các mơ hình con đƣợc kết hợp để tạo thành tồn bộ mơ hình
miền. Ví dụ, hình 1.4 cho thấy cách mơ mình con F1 chồng lên một mơ hình con khác
chứa hai lớp là Cz và Cx thơng qua lớp Cz, mơ hình con này lại chồng lên một mơ
hình con khác chỉ chứa lớp Cy thông qua kết nối giữa Cx và Cy.

1.3.2. Định nghĩa các vịng lặp phát triển
Khi mơ hình miền ở mức cao đã đƣợc tạo, pha tiếp theo là định nghĩa ra các vòng
lặp. Cùng với nhau, các vòng lặp này sẽ xây dựng kế hoạch phát triển cho phần mềm.
Ý tƣởng chính là định nghĩa ra mỗi vịng lặp theo ranh giới của một mơ hình con.
Đầu ra của mỗi vòng lặp là một nguyên mẫu phần mềm cho mơ hình con đó. Một mơ
hình con có thể là mơ hình con đƣợc định nghĩa cho mỗi chức năng trong pha trƣớc
hoặc là mơ hình con nhỏ hơn trong mơ hình con này. Kích thƣớc chính xác của mơ
hình con phụ thuộc tài ngun phát triển (quan trọng nhất là nguồn tài nguyên con
ngƣời) sẵn có cho dự án.
Mỗi vòng lặp liên quan đến việc thực hiện bốn hoạt động của một quy trình phát
triển phần mềm điển hình là phân tích, thiết kế, lập trình và kiểm thử. Sự khác biệt duy
nhất ở đây là thực hiện các hoạt động này để phát triển một nguyên mẫu phần mềm
cho một mơ hình con chứ khơng phải tồn bộ mơ hình miền.
Về mặt khái niệm, các vịng lặp phát triển hình thành một chu trình phát triển liên
tục. Hình 1.4 minh họa chu trình phát triển này bằng một đƣờng cong bên ngồi có
mũi tên đi qua và kết nối bốn hoạt động phát triển phần mềm.

1.3.3. Thực hiện các vòng lặp phát triển
Mỗi vòng lặp phát triển đƣợc thực hiện bởi việc phân tích, thiết kế, lập trình và

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 hồn thành, tạo ra một tập các ngun 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 tố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ử

dụng để phát triển nhanh phần mềm phù hợp với các nguyên tắc thiết kế phần mềm
hƣớng miền [5].

1.4.1. Lịch sử phát triển
Năm 2012, ý tƣởng xây dựng một nền tảng phần mềm hƣớng miền tên là
jDomainApp đã đƣợc các tác giả [5] khởi xƣớng. Ban đầu, nền tảng đƣợc hình thành
để phục vụ nhƣ một công cụ cho việc giảng dạy một phƣơng pháp phát triển chƣơng
trình hƣớng đối tƣợng trong Java. Phƣơng pháp này đƣợc đề xuất trong một cuốn sách
[10] đã đƣợc cập nhật và điều chỉnh bởi tác giả để giảng dạy hai mơ-đun khóa học
chính của kỹ sƣ phần mềm tại khoa Công nghệ thông tin, Đại học Hà Nội.
Năm 2014, DomainAppTool bắt đầu đƣợc phát triển dựa trên jDomainApp do
nhu cầu cần một công cụ thân thiện với ngƣời sử dụng, có thể đƣợc sử dụng để thực
thi và kiểm thử các lớp miền một cách nhanh chóng và tƣơng tác. Công cụ này đã
đƣợc chứng minh là hữu ích sau khi áp dụng tại khoa Cơng nghệ thơng tin trong việc
giảng dạy một mơ-đun khóa học khác của kỹ sƣ phần mềm là môn “Dự án 2”.
Sự phát triển của cơng cụ DomainAppTool nói riêng và nền tảng jDomainApp
nói chung là liên tục khơng ngừng. Cơng cụ đƣợc sử dụng không chỉ để chứng minh
khả năng của nền tảng mà còn để thử nghiệm một cách nhanh chóng bất kì ý tƣởng mơ
hình hóa miền mới nào đƣợc tích hợp vào nền tảng. Đến cuối năm 2016, sự phát triển
này đã đạt tới một cột mốc quan trong khi ba bài báo khoa học chính thức đƣợc xuất
bản tại hội nghị KSE với mục tiêu củng cố và khẳng định tính đúng đắn của lý thuyết
cốt lõi của nền tảng và công cụ.

1.4.2. Tổng quan kiến trúc
Công cụ đƣợc thiết kế dựa trên kiến trúc phần mềm MVC. Về mặt khái niệm,
kiến trúc của công cụ đƣợc xây dựng từ thành phần chính: quản lý mơ hình, quản lý
hiển thị và quản lý đối tƣợng.
16



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

Để minh họa ứng dụng của cơng cụ DomainAppTool trong việc tự động tạo ra
phần mềm, phần mềm quản lý khóa học CourseMan đƣợc sử dụng. Các phần sau đây
sẽ mô tả các yêu cầu của phần mềm này.
Các yêu cầu chức năng
CourseMan là một phần mềm quản lý khóa học đơn giản bao gồm các chức năng
sau: Thứ nhất, cho phép khoa quản lý sinh viên và quản lý các mơ-đun khóa học đƣợc
cung cấp cho sinh viên. Thứ hai, phần mềm cho phép sinh viên đăng kí vào các mơđun khóa học trong mỗi học kì, cho phép khoa nhập điểm của sinh viên và phần mềm
phải tự tính tốn ra điểm cuối cùng của sinh viên trong mỗi mơ-đun khóa học đó. Thứ
17


ba, phần mềm cần cho phép khoa quản lý các lớp từ các nhóm sinh viên. Ngồi ra,
phần mềm cũng cần cung cấp một số báo cáo liên quan ví dụ nhƣ báo cáo học sinh
theo tên, cho phép ngƣời dùng tìm kiếm tất cả các sinh viên có tên chứa một chuỗi xác
định trƣớc.
Các yêu cầu dữ liệu
Sinh viên đƣợc đặc trƣng bởi các thuộc tính cơ bản: mã sinh viên, tên sinh viên,
ngày tháng năm sinh, địa chỉ và email. Thuộc tính mã sinh viên là một định danh duy
nhất đƣợc sinh ra một cách tự động bởi hệ thống theo công thức: bắt đầu bằng chữ “S”
và theo sau bởi một số tự động tăng lên từ năm hiện tại. Ví dụ, sinh viên đầu tiên đăng
ký vào chƣơng trình học trong năm 2016 có mã sinh viên là S2016 thì sinh viên thứ
hai của năm đó sẽ có mã sinh viên là S2017, .vv.. Lớp Student đƣợc mô tả bởi mã
sinh viên, tên và địa chỉ.
Mô-đun học (course module) đƣợc đặc trƣng bởi các thuộc tính: định danh (id),
mã mô-đun (code), tên mô-đun (name), kỳ học (semester) và số tín chỉ (credits).
Thuộc tính kỳ học phải có giá trị nằm trong phạm vi từ 1 đến 10, trong khi số tín chỉ
phải lớn hơn 0. Thuộc tính mã mơ-đun đƣợc tạo ra một cách tự động nhờ kết hợp chữ
“M” với 1 số đƣợc tính bằng việc nhân học kỳ với 100 và cộng với một số tự động
tăng bắt đầu từ 0. Ví dụ, mã mơ-đun khóa học đầu tiên trong học kỳ 1 là “M100”, mã
mơ-đun khóa học thứ hai là “M101”, .vv.. Có hai loại mơ-đun khóa học là bắt buộc và

tự chọn. Ngồ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 chun 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