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

DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮTAPI Application Programming Interface Giao diện lập trình ứng dụngDDD Domain-Driven Design Thiết kế hướng miền DDSDM Domain-driven software developme

ĐẠ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Ờ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ìnhnà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à

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 quý 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 hoàn thành luận vănnà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ọcCông Nghệ đã truyền đạt những kiến thức quý báu cũng như giúp đỡ tôi trong quá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 quá 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à

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

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 toá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

DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

API Application Programming Interface Giao diện lập trình ứng dụngDDD Domain-Driven Design Thiết kế hướng miền

DDSDM Domain-driven software development Phương pháp phát triển phần

IDE Integrated Development Environment Môi trường phát triển tích hợpJDT 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ềmMVC Model View Controller Mô hình thiết kế phần mềm

OSGi Open Service Gateway Initiative Nền tảng Java cho việc phát

triển và triển khai plug-inPDE Plug-in Development Environment Môi trường phát triển plug-inRCP Rich Client Platform Nền tảng lập trình các ứng dụng

DesktopSWC Software Configuartion Cấu hình phần mềm

SWT The Standard Widget Toolkit Bộ công cụ đồ họa chuẩn

XML eXtensible Markup Language Ngôn ngữ đánh dấu mở rộng

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

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ôngnghệ 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ầunghiệ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ầnmề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ânthủ 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ácviê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 đặtdướ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ắccủ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ómphá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ủaphầ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ưutrữ 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ủacô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 choDomainAppTool 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 quá trình phát triển phần mềm Điều này có ý nghĩaquan 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ụngrộng rãi hơn

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âydựng thuật toá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 đượcchia 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áttriể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ànhphầ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 sinhphươ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ưngtrọng tâm tập trung vào trình bày chi tiết thuật toá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 yêu cầu về môi trường cài

đặt thực nghiệm, bài toán thực nghiệm và cuối cùng là các kết quả đạt được

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

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ầuphứ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ướngmiề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ếtcá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ácbằ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àitoá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áplinh 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ế) Saunhiề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 khithiết kế trở nên hoàn hảo nhất Quá 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ápchú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 raphầ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ểncầ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ớichuyê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ànhcấ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ôngphải là một giản đồ cụ thể, quan trọng là ý tưởng mà giản đồ đó muốn truyền đạt; quantrọ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óamiề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ộtcô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 trongsuố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 đầutiê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ấutrú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 giamiền và chuyên gia phần mềm có thể hiểu nhau và cộng tác với nhau [2] Thôngthườ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àocả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ọngcho sự thành công của dự án Khi trao đổi về mô hình, có nhiều khái niệm chuyênngà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

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

Nguyên 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ềnvấ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ómphá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ượngkhá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ôngchuyển thành các đơn vị có thể lưu trữ, có thể phục hồi và đảm bảo tính toà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 đốimặ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 gianghiệ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ậnrằ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 choviệ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ếptrợ 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 vaitrò, 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áttriể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íchsớ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ìnhbê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íchhợ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ốichặ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ộtcô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ìnhphâ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ântí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

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êngia 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ểmnà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ả chiphí 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ểumiề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ềnthì 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 đề theomộ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ựngcù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ệntrong 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ìnhthiế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ậtsang 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ảiquyế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 Khimộ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ộtcá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ểnphầ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

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

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ôngnghiệ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ùnglayer 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ànhcông đều sử dụng một số phiên bản của bốn layer khái niệm sau:

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ệnhcủ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ôngphả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ượngmiề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ý chotươ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 tincho ứ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ệnthì 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ẻogiữ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ơnnê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ụ

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 đặtlogic 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úcphầ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 quantâ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ệntiê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 yê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áclự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 khungcủ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ácnhau 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áicủ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ệcxá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ủamiề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áchnhiệ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 địnhthiế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ếtchặ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 ápdụ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ầncủ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

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ệnbá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 bản ghiphù 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ấtquá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 đượcxá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 luôn tồn tại Mô hình hóa đốitượ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ảncủ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í điqua nhiều trạng thái Đối tượng đại diện cho một chuỗi định danh qua thời gian Đôikhi, 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ủachú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õimỗ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 đượcloạ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 đơngiả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ữngnhầ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 đốitượ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ốiloạ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ậnchiế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ệtkhi 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 đốivớ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áiniệ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ệncho 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ảnhay 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ụ, trongphầ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ânloạ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ạpkhô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 đốitượ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àngcủ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ườngliê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áckhá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 épcá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 đốitượ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ốiquan 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ộtdị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

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 đượcchia 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ụ đượcgiao 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êntắ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ântí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ươngtá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ạikhô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 địnhnghĩ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ơntá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ượngcủ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 để chothấ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 trongchú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ọncá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ủamô-đ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ảiqua 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ếtthú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àmkhở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 gomrá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ượngnà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

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 toà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 toà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

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ìnhnhờ 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 quá 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ẫuphầ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ử

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 giamiề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 choquá 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áttriể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ăngchi 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ànthiệ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 đượcxá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ướidạ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

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 đượckế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ữachú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 toàn bộ mô hìnhmiề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ácchứ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

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áttriể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 duynhấ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ềmcho một mô hình con chứ không phải toà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êntụ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 ngoà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ácvò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ơnbao 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 baohà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ểnDDSDM 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êucầ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 chocá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

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ênmẫ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ònglặ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 quaviệ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ênkhô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ácchứ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ềmhướng miền [5]

Năm 2014, DomainAppTool bắt đầu được phát triển dựa trên jDomainApp donhu 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 đã đượcchứng minh là hữu ích sau khi áp dụng tại khoa Công nghệ thông tin trong việc giảngdạ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 jDomainAppnói chung là liên tục không ngừng Công cụ được sử dụng không chỉ để chứng minhkhả 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ểnnà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ấtbả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ếtcố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

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ớpJava đượ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ầumiề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áclớ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àngthự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ầnmề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ốttrong 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 đốitượ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ácthô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 đốitượ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 raphầ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ăngsau: 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 đượccung 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ềmphải tự tính toán ra điểm cuối cùng của sinh viên trong mỗi mô-đun khóa học đó Thứ

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 Ngoà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 sinhtheo 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 duynhấ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ộctí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ớnhơ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óahọ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.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ủakhoa (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ự đơnthuộc một trong các thành phần sau: “E”- Giỏi, “G”- Khá, “P”- Trung bình, “F”- Yếu

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

meta-attribute được mô hình hóa như một lớp được gọi là lớp meta-attribute và tên bắt

đầu bằng ký tự “@” Sự đính kèm của lớp này vào lớp miền hoặc một trong các thànhviên của lớp miền được mô hình hóa như một liên kết Để phân biệt liên kết này vớiliên trên lớp thông thường, trong sơ đồ lớp sử dụng đường màu xám có chu trình tại

phía đối diện với lớp meta-attribute Đường liên kết tới một lớp được kết nối với một

trong các cạnh của hình chữ nhật chứa lớp Mặt khác, đường liên kết tới một thànhviên của lớp sẽ vượt qua ranh giới và đi vào bên trong hình chữ nhật chứa lớp, cho đến

vị trí ngoài cùng bên trái của thành viên đó Mỗi thuộc tính của meta-attribute được

định nghĩa với một giá trị mặc định Khi cần tiết kiệm không gian, chỉ những thuộctính có giá trị khác với giá trị mặc định được hiển thị trong mô hình thiết kế

Hình 1.5 : Thiết kế cơ bản các lớp miền của phần mềm

CourseMan Meta-attribute DClass

Meta-attribute này có bốn thuộc tính cơ bản là schema, serialisable, singleton, mutable Các thuộc tính khác có thể được thêm vào nếu cần thiết Hình 1.5 biểu thị meta-attribute này được mô hình hóa trong sơ đồ lớp của phần mềm CourseMan Các giá trị mặc định của bốn thuộc tính cơ bản được liệt kê trong đặc tả meta-attribute của

lớp SClass

Thuộc tính schema xác định tên của schema cơ sở dữ liệu lưu trữ các đối tượng

miền của lớp miền

Thuộc tính serialisable (thuộc kiểu boolean) xác định các đối tượng miền có thể

được chuyển đổi thành một mảng byte để lưu trữ trong bộ nhớ ngoài của phần mềm

như một tệp hoặc cơ sở dữ liệu Khi thuộc tính này là true, các đối tượng miền có thể

được lưu trữ trong không gian lưu trữ có tên được xác định bởi thuộc tính schema Thuộc tính singleton xác định chỉ một đối tượng miền của lớp miền được sử dụng

trong toàn bộ thời gian chạy của phần mềm hay không Nếu thuộc tính được gán true, lớp miền và các đối tượng của có thể được xử lý hiệu quả hơn bởi bộ điều khiển Ví

dụ, trong cài đặt CourseMan, bộ điều khiển đọc đối tượng miền của lớp singleton từ bộ

nhớ bên dưới một lần và giữ nó trong bộ nhớ cho tới khi kết thúc phần mềm

Thuộc tính mutable xác định các đối tượng miền có thể thay đổi được hay không

tức là trạng thái của chúng có thể được thay đổi Giá trị thuộc tính này ảnh hưởng đếncác lớp miền và các đối tượng của nó được xử lý bởi phần mềm Ví dụ, nếu thuộc tính

được thiết lập true thì chế độ xem lớp miền sẽ hiển thị các đối tượng miền dưới dạng chỉ đọc read-only để người người không được phép chỉnh sửa trạng thái của chúng.

Chú ý, thuộc tính này áp dụng cho tất cả các đối tượng của lớp

Meta-attribute DAttr

Các thuộc tính của một lớp miền được xác định cùng với meta-atrribute DAttr Meta-atrribute này có hai tập thuộc tính Tập thứ nhất xác định các thông tin rằng buộc của một thuộc tính miền Tập này có chính thuộc tính : name, type, mutable, optional, length, min, max, defaultValue, format Tập thứ hai có bốn thuộc tính cơ bản:

id, auto, serialisable, filter.

Thuộc tính id xác định thuộc tính miền có phải là một định danh hay không Chú

ý, đây là một định danh hướng miền, không phải là một định danh đối tượng kèm theomọi lớp Thuộc tính này được sử dụng để hướng dẫn phần mềm cách tạo ra các giá trịđịnh danh cho các đối tượng miền Các giá trị như vậy cần thiết cho các tác vụ như trảlời các truy vấn tìm kiếm của người dùng cho các đối tượng

Thuộc tính auto xác định giá trị của thuộc tính miền có tự động được tính toán

bởi phần mềm hay không Nếu được thiết lập false, các giá trị thuộc tính miền phải

được xác định bởi người dùng

Thuộc tính serialisable xác định giá trị thuộc tính miền được lưu khi đối tượng

miền được tuần tự hóa hay không Thuộc tính này được sử dụng cùng với thuộc tính

serialisable của DClass.

Thuộc tính filter được sử dụng một cách cụ thể cho các thuộc tính miền loại

collection trong liên kết 1:M giữa lớp miền sở hữu chúng với các lớp miền khác Giá

trị của thuộc tính này là một chú thích khác tên Select Chú thích này có hai thuộc tính:

clazz và attributes, cùng với nhau chúng xác định một tập con các thuộc tính miền của

lớp miền chỉ định có các giá trị được quan tâm trong collection.

Ví dụ, đặc tả Java cho các thuộc tính miền của lớp miền SClass :

@DClass (schema = "courseman")

public class SClass {

@DAttr (name= "id", id= true, auto= true, type= Type.Integer,

length= 6, mutable = false)

private int id ;

private static int idCounter;

@DAttr (name = "name", length = 20, type = Type.String)

private String name ;

@DAttr (name = "students", type = Type.Collection, serialisable =

false, optional = false, filter = @Select (clazz =

Student.class))

@DAssoc (ascName = "class-has-student", role = "class",

ascType = AssocType.One2Many, endType =

AssocEndType.One,

associate= @Associate (type= Student.class, cardMin= 1,

cardMax= 25)) private List<Student> students ;

}

Meta-attribute DAssoc

Meta-atrribute này được sử dụng để xác định một đầu cuối của liên kết nhị phân giữa hai lớp miền Về mặt khái niệm, một liên kết là một tập DAssoc được đặt tên, mỗi DAssoc xác định một đầu cuối của liên kết Một DAssoc được gắn cho thuộc tính miền

thực hiện đầu cuối liên kết Thuộc tính này được gọi là thuộc tính kết hợp

DAssoc bao gồm các thuộc tính: ascName, role, acsType, endType, associate, dependOn Hình 1.6 minh họa cách DAssoc được sử dụng để định nghĩa ba liên kết

trong sơ đồ lớp CourseMan, trong đó, một lớp bổ sung tên là City có liên kết một – một với lớp Student.

Thuộc tính ascName xác định tên của liên kết Nó là định danh duy nhất của liên kết, do đó nó được sử dụng để xác định tập các DAssoc của liên kết Một DAssoc thuộc tập này sẽ có cùng giá trị thuộc tính ascName Trong hình 1.6, giá trị thuộc tính

này là sự kết hợp tên của các lớp tham gia vào liên kết và một từ khóa mô tả bản chấtcủa liên kết Từ khóa đó thông thường là một động từ, giúp phân biệt giữa các liên kếtkhác nhau có thể tồn tại trong cùng một tập các lớp

Thuộc tính role xác định vai trò của lớp miền có chứa DAssoc trong liên kết nghĩa là

lớp tham gia vào liên kết với vai trò đó

Thuộc tính ascType xác định loại liên kết, là một trong các loại sau: một – một,

một – nhiều, nhiều – nhiều Tương tự như thuộc tính tên, giá trị của thuộc tính này

cũng cần giống nhau đối với các DAssoc trong cùng một tập.

Thuộc tính endType xác định loại đầu cuối của liên kết, có thể là một hoặc nhiều.

Hình 1.6: Áp dụng meta-attribute DAssoc cho ba liên kết của CourseMan

Thuộc tính associate xác định đầu cuối của liên kết Loại thuộc tính này là một meta-attribute khác tên là Associate, có bốn thuộc tính: type, cardMin, cardMax, determinant Trong đó, thuộc tính type xác định lớp miền được kết hợp của đầu cuối liên kết Ở hình 1.6, giá trị của type được viết bằng cách sử dụng ký hiệu lớp của Java

(bao gồm tên lớp được theo sau bởi từ khóa class) Các thuộc tính cardMin, cardMax

cùng với nhau, xác định rằng buộc chính xác về số lượng cho đầu cuối của liên kết

Cuối cùng nhưng không phần quan trọng, thuộc tính determinant xác định lớp miền

được liên kết có phải là yếu tố quyết định của liên kết (nghĩa là một thực thể mạnh)

hay không Giá trị thuộc tính này bằng true chỉ đối với các liên kết một – một có đầu cuối là một thực thể mạnh Trong hình 1.6, Student là một yếu tố quyết định của liên kết giữa nó và City.

Thuộc tính dependsOn xác định lớp miền tại đầu cuối này có phụ thuộc vào đầu

cuối kia hay không Nếu được thiết lập bằng true, các đối tượng của lớp miền tại đầu

cuối này có thể chỉ tồn tại khi nó được kết hợp với một đối tượng miền của lớp ở đầu

cuối kia Trong hình 1.6, Enrollment phụ thuộc vào Student.

Ví dụ, đặc tả mã Java cho hai lớp miền City và Student thể hiện một số thuộc

tính miền và các liên kết

@ DClass(schema = "courseman")

public class Student {

@ DAttr(name ="id", id = true, auto= true, type = Type.String,

length = 6, mutable = false, optional = false)

private String id ;

private static int idCounter = 0;

@ DAttr(name = "name", type = Type.String, length = 30, optional =

false) private String name ;

@ DAttr(name= "address", type = Type.Domain, length = 20, optional

= true) @ DAssoc(name = "student-has-city", role = "student",

type = AssocType.One2One, endType = AssocEndType.One,

associate = @ Associate(type= City.class, cardMin= 1,

cardMax= 1)) private City address ;

@ DAttr(name = "sclass", type = Type.Domain, length = 6)

@ DAssoc(name = "class-has-student", role = "student",

type = AssocType.One2Many, endType = AssocEndType.Many,

associate= @ Associate(type= SClass.class, cardMin= 1,

cardMax= 1)) private SClass sclass ;

}

@ DClass(schema = "courseman")

public class City {

@ DAttr(name = "id", id = true, auto = true, type =

Type.Integer, length = 3, mutable = false, optional =

false)

private int id ;

private static int idCounter;

@ DAttr(name = "name", type = Type.String, length = 20, mutable =

false, optional = false)

private String name ;

@ DAttr(name = "student", type = Type.Domain, optional =

true, serialisable = false)

@ DAssoc(name = "student-has-city", role = "city",

type = AssocType.One2One, endType = AssocEndType.One,

associate = @ Associate(type= Student.class, cardMin= 1,

cardMax = 1, determinant = true))

private Student student ;

}

Các phương thức

Sau khi cấu trúc nền tảng của lớp miền được xây dựng sử dụng các attribute, cần định nghĩa các phương thức của lớp đó Ở đây, các thuộc tính miền cùng với các meta-attribute của chúng được sử dụng để xác định các phương thức cần thiết

meta-bao gồm phương thức khởi tạo, getter, setter và các phương mặc định khác.

Các phương thức được sinh ra một cách tự động sử dụng thuật toán BspaceGen

do các tác giả của DomainAppTool đề xuất

1.4.5 Xây dựng nguyên mẫu phần mềm từ các lớp miền.

Công cụ DomainAppTool sử dụng phương pháp phát triển phần mềm hướngmiền DDSDM để xây dựng nguyên mẫu phần mềm từ các lớp miền Trong mỗi vòng

lặp phát triển, đầu vào là các lớp miền chứa các meta-attribute dưới dạng các annotation đặc tả dữ liệu cho một loại đối tượng, thông tin cơ bản mô tả về đối tượng.

Các lớp miền đầu vào hiện tại được viết dưới dạng ngôn ngữ chuyên biệt dựa trên

annotation DCSL chỉ chứa một tập các rằng buộc cấu trúc cần thiết cho một lớp miền.

Ban đầu, công cụ cần tự động sinh ra đặc tả hành vi hay các phương thức cho lớpmiền Tiếp theo, để sinh ra được nguyên mẫu phần mềm, công cụ cần một cấu hìnhphần mềm mô tả chi tiết hơn giao diện, thuộc tính (kiểu thuộc tính, các rằng buộc trênthuộc tính,…), controller và lớp miền cần sử dụng Tuy nhiên, mỗi lớp miền đầu vàolại có cấu hình riêng cho thuộc tính, phương thức, giao diện của mình được gọi là cấuhình mô-đun phần mềm Nếu sinh trực tiếp cấu hình phần mềm từ lớp miền thì cấuhình này phải chứa tất cả các cấu hình mô-đun phần mềm Trong mỗi vòng lặp pháttriển, các lớp miền được sử dụng là khác nhau nên thao tác sinh cấu hình mô đun sẽđược thực hiện lại khi sinh cấu hình phần mềm cuối cùng Một cách đơn giản hơn, đểtăng tính mô-đun hóa cho quá trình xây dựng phần mềm hướng miền từ lớp miền: thay

vì coi lớp miền là đầu vào cho các vòng lặp phát triển, hãy xây dựng cấu hình mô-đunphần mềm cho từng lớp miền và lấy cấu hình mô-đun đó là đầu vào cho các vòng lặpphát triển Công cụ không thể tự sinh ra phương thức cho lớp miền, cấu hình mô-đunhay cấu hình phần mềm Các công việc này được thực hiện thủ công sử dụng thư viện

sinh phương thức, sinh cấu hình mô-đun và sinh cấu hình phần mềm tương ứng Kết

quả cuối cùng là cấu hình phần mềm sẽ được DomainAppTool sử dụng

Hình 1.7:Quá trình xây dựng nguyên mẫu phần mềm từ lớp miền

Thuật toán Bspace được sử dụng để tự động sinh phương thức cho lớp miền đầu

vào Tuy nhiên, các phương thức được sinh ra còn đơn giản: getter/setter, tự động

tăng id, thêm/xóa đối tượng trong danh sách Thuật toán MCC được sử dụng để sinh

cấu hình mô-đun phần mềm từ lớp miền hoàn chỉnh và cấu hình phần mềm được sinh

ra từ cấu hình mô-đun phần mềm nhờ thuật toán SWC Cuối cùng, công cụDomainAppTool sẽ sử dụng cấu hình phần mềm để tạo ra nguyên mẫu phần mềm.Trong mỗi vòng phát triển, cấu hình mô-đun phần mềm được sử dụng đầu vào của quátrình tạo ra nguyên mẫu phần mềm Tuy nhiên, khi mô hình lớp miền thay đổi thì cầncập nhật các thay đổi đó trên cấu hình mô-đun phần mềm

1.5 Thành phần mở rộng Eclipse Plug-in

Eclipse là một công cụ hỗ trợ lập trình, mã nguồn mở, được phát triển bởi IBM.Eclipse là nền tảng được thiết kế để xây dựng công cụ phát triển ứng dụng vào web.Theo thiết kế, bản thân nền tảng này không cung cấp nhiều chức năng người dùng đầucuối Giá trị của nền tảng nằm ở chỗ nó khuyến khích phát triển nhanh các tính năngtích hợp dựa trên mô hình plug-in [3]

Eclipse cung cấp một mô hình giao diện người dùng chung (UI) để làm việc vớicác công cụ Nó được thiết kế để chạy trên nhiều hệ điều hành trong khi vẫn cung cấpkhả năng tích hợp mạnh mẽ với mỗi hệ điều hành bên dưới Plug-in có thể lập trìnhtrên các APIs của Eclipse và chạy ổn định trên bất kì hệ điều hành được hỗ trợ nào.Lõi của Eclipse là một kiến trúc để phát hiện, tải và chạy các plug-ins một cáchlinh động Nền tảng xử lý việc tìm kiếm và chạy đúng mã nguồn Nền tảng UI cungcấp một mô hình điều hướng người dùng chuẩn Sau đó, mỗi plug-in có thể tập trungvào việc thực hiện tốt một số tác vụ riêng (bất kì tác vụ nào mà nhà phát triển có thểnghĩ ra như biên dịch, gỡ lỗi, kiểm thử, minh họa, …)

1.5.1 Kiến trúc mở của Eclipse

Nền tảng Eclipse định nghĩa một kiến trúc mở để mỗi nhà phát triển plug-in cóthể tập trung vào nhiệm vụ cụ thể của họ thay vì lo lắng về các vấn đề tích hợp Nềntảng quản lý sự phức tạp của các môi trường chạy khác nhau như hệ điều hành hay cácmôi trường máy chủ làm việc nhóm Nền tảng được thiết kế tốt, các tính năng mớiquan trọng và mức độ tích hợp có thể được bổ sung mà không ảnh hưởng đến các công

cụ khác [4]

Nền tảng Eclipse được xây dựng từ khái niệm plug-in Plug-in là các gói mãnguồn và/hoặc dữ liệu có cấu trúc đóng góp chức năng cho hệ thống Chức năng có thểđược đóng góp dưới dạng thư viện mã nguồn (các lớp Java với API công khai), cácthành phần mở rộng của nền tảng hoặc thậm chí là tài liệu Plug-in có thể định nghĩacác điểm mở rộng để các plug-in khác thêm chức năng nào

Bản thân nền tảng Eclipse được cấu trúc như các hệ thống con mà mỗi hệ thốngcon lại được cấu trúc như một tập các plug-in cài đặt một số chức năng chính Một vài

plug-in thêm tính năng hiển thị vào nền tảng, một số khác thì cung cấp các thư viện lớpđược sử dụng để cài đặt các thành phần mở rộng hệ thống Các hệ thống con được xâydựng trên đỉnh của cơ chế chạy run-time.

Hình 1.8: Kiến trúc mở của Eclipse [4]

Mỗi hệ thống con định nghĩa ra các điểm mở rộng cho việc bổ sung các chứcnăng vào nền tảng Các thành phần chính sau [4] của nền tảng được cài đặt như mộthoặc nhiều plug-in :

Platform runtime

Thành phần này định nghĩa ra điểm mở rộng và mô hình plug-in Nó tự độngphát hiện, chạy và duy trì thông tin về các plug-in và các điểm mở rộng của chúngtrong một bộ đăng ký của nền tảng Các plug-in được khởi tạo khi được yêu cầu vàphụ thuộc vào hoạt động của người dùng Một plug-in là một thành phần có cấu trúc

mô tả chính nó cho hệ thống bằng cách sử dụng tệp kê khai OSGi (MANIFEST.MF)

và một tệp kê khai plug-in (plugin.xml) Nền tảng sẽ duy trì một danh sách đăng kýcác plug-in đã cài đặt và chức năng mà chúng cung cấp

Mục tiêu chính của platform runtime là ở chỗ người dùng cuối không phải tốn tài

nguyên bộ nhớ hay hiệu năng hệ thống cho các plug-in đã cài đặt nhưng không sửdụng Một plug-in có thể được cài đặt và thêm vào danh sách đăng ký nhưng plug-in

đó sẽ không được kích hoạt, trừ khi một chức năng mà nó cung cấp được yêu cầu theohoạt động của người dùng

Resource management

Thành phần này định nghĩa ra một mô hình nguồn tài nguyên chung để quản lý

các artifact của plug-in Plug-in có thể tạo và sửa đổi các dự án, thư mục và các tệp để

tổ chức và lưu trữ các artifact trên đĩa.

Workbench UI

Plug-in này cài đặt giao diện làm việc và định nghĩa một số điểm mở rộng chophép các plug-in khác thêm mới các thành phần giao diện người dùng như: item trênmenu và thanh công cụ, các hành động kéo thả, hộp thoại, chế độ xem và trình soạnthảo Nó còn cung cấp các bộ công cụ bổ sung (JFace và SWT) cho việc xây dựnggiao diện người dùng Các dịch vụ UI được cấu trúc sao cho việc xây dựng các ứngdụng RCP, sử dụng tập con UI plug-in, sẽ độc lập với mô hình quản lý nguồn tàinguyên và workspace Các plug-in tập trung IDE định nghĩa các chức năng bổ sung đểđiều hướng và thao tác trên nguồn tài nguyên

Team support

Thành phần này định nghĩa một mô hình lập trình nhóm để quản lý các phiên bản

mã nguồn và tài nguyên khác nhau

Plug-in của các công cụ phát triển Java (JDT) mở rộng workbench của nền tảng

bằng cách cung cấp các tính năng chuyên biệt cho việc chỉnh sửa, xem, biên dịch, gỡlỗi và chạy mã nguồn Java

PDE

Môi trường phát triển plug-in (PDE) cung cấp các công cụ tự động tạo, thao thác,

gỡ lỗi và trên khai các plug-in, fragment, feature

1.5.2 Môi trường phát triển Plug-in

Phần mở rộng và điểm mở rộng

Một nguyên tắc cơ bản để xây dựng các hệ thống phần mềm mô-đun hóa là tránhcác thành phần phụ thuộc chặt chẽ lẫn nhau Nếu các thành phần được tích hợp chặtchẽ, nó sẽ trở nên khó khăn để thêm mới hoặc thay thế một thành phần có cài đặt khác

mà không gây ra những thay đổi trên toàn hệ thống Liên kết lỏng lẻo (loose coupling)trong Eclipse thu được một phần thông qua cơ chế phần mở rộng và các điểm mở rộng

Ví dụ, trong cửa hàng điện, ổ cắm là điểm mở rộng, phích cắm hay bóng đèn kết nốiđến ổ cắm là phần mở rộng Giống như ổ cắm điện, các điểm mở rộng có nhiều hìnhdạng và kích cỡ khác nhau và chỉ các phần mở rộng được thiết kế cho điểm mở rộng

cụ thể đó mới phù hợp [4]

Khi một plug-in muốn cho phép các plug-in khác mở rộng hoặc tùy chỉnh một

phần chức năng của nó, nó sẽ khai báo một điểm mở rộng chứa các nguyên tắc(thường là sự kết hợp giữa XML và các giao diện Java) mà các phần mở rộng bắt buộcphải tuân theo Các plug-in muốn kết nối đến điểm mở rộng này nhất thiết phải cài đặtcác nguyên tắc trên trong phần mở rộng của mình Thuộc tính then chốt ở đây làplugin đang được mở rộng không biết gì về plug-in đang kết nối đến nó, ngoài trừphạm vi trong các nguyên tắc của điểm mở rộng Điều này cho phép các plug-in đượcxây dựng bởi các cá nhân hay tổ chức có thể tương tác với nhau một cách liền mạchngay cả khi họ không biết nhiều về nhau.

Hình 1.8: Hoạt động của plug-in

Ví dụ, plug-in A khai báo một điểm mở rộng P chứa interface I và plug-in B

đang muốn mở rộng hoặc tùy chỉnh plug-in A Plug-in B sẽ khai báo plug-in A cùng

interface I trong dependencies của mình, sau đó nó mới có thể tạo lớp C cài đặt interface I.

Feature

Một feature được sử dụng để đóng gói một nhóm plug-in với nhau thành một đơn

vị có thể cài đặt và cập nhật Các feature có một tệp kê khai, cung cấp thông tin cơ bản

về feater và nội dung của nó Nội dung có thể chứa các plug-in, fragment và các tệp

quan trọng cho feature Một feature cũng có thể chứa các feature khác Định dạng phân phối của một feature là JAR, nhưng mỗi plug-in cũng được cung cấp dưới dạng

một tệp JAR riêng biệt

Fragment

Một fragment được sử dụng để thay thế hoặc mở rộng chức năng của một plug-in đang tồn tại Fragment thường thêm môi trường (hệ điều hành, kiến trúc, …), mã

nguồn cụ thể vào nó Tùy thuộc vào môi trường, plug-in có thể được cài đặt mã nguồn

plug-in cơ sở cùng với fragment chính xác Khi một fragment được phát hiện bởi nền

tảng và plug-in cha của nó được tìm thấy; các thư viện, phần mở rộng và điểm mở

rộng của fragment được hợp nhất với các thành phần tương ứng của plug-in cha Mặc

dù, cơ chế hợp nhất này tốt cho thời gian chạy runtime nhưng các nhà phát triển cần

xem các fragment như các thực thể riêng biệt khi làm việc với chúng.

Fragment có thể được xem là các plug-in giới hạn Chúng có tất cả khả năng của plug-in thông thường nhưng chúng không có khái niệm vòng đời Fragment không có

lớp cao nhất chứa các phương thức “khởi động” và “tắt”

Plug-in có thể mở rộng được bằng cách sử dụng các phần mở rộng và điểm mởrộng Một plug-in có thể cung cấp một hoặc nhiều điểm mở rộng để các plug-in khác

có thể thêm chức năng vào nó Một plug-in cũng có thể cung cấp các phần mở rộng đểkết nối đến các plug-in khác

Plug-in có thể chia sẻ Một plug-in có thể được lưu dưới dạng một thư mục hoặcmột tệp JAR để các ứng dụng khác sử dụng Các plug-in có thể được nhóm dưới dạng

các feature để phân phối và cài đặt trong các ứng dụng.

Eclipse plug-in dựa trên các gói OSGi OSGi được sử dụng để quản lý các plugin

trong ứng dụng Eclipse Một plug-in nhất thiết phải chứa một tệp kê khai (manifest) có

tiêu đề OSGi hợp lệ cho tên và phiên bản plug-in Ngoài OSGi, tính năng phần mởrộng và điểm mở rộng được thêm vào Eclipse

Sản phẩm

Một sản phẩm dựa trên Eclipse là một chương trình độc lập được xây dựng cùngvới nền tảng Eclipse Sản phẩm này có thể được đóng gói và phân phối một cách tùy

chọn dưới dạng một hoặc nhiều feature, được quản lý như một thực thể duy nhất bởi

cơ chế cập nhật của Eclipse

Sản phẩm bao gồm tất cả mã nguồn và các plug-in cần thiết để chạy chúng (mộtmôi trường chạy Java (JRE) và mã nguồn nền tảng Eclipse) Mã nguồn plug-in, JRE vànền tảng Eclipse thường được cài đặt cùng với một chương trình cài đặt sản phẩmchuyên dụng Nhà cung cấp sản phẩm được tự do sử dụng bất kỳ công cụ hoặc chươngtrình cài đặt nào phù hợp với nhu cầu của họ

Khi được cài đặt, người dùng bắt đầu chạy sản phẩm và được hiển thị với mộtEclipse workbench được cấu hình đặc biệt cho mục đích sử dụng như phát triển Web,phát triển chương trình C++ hay bất kỳ mục đích khác Nền tảng giúp dễ dàng cấuhình các nhãn, hộp thoại, đồ họa và màn hình để người dùng xem workbench như làcửa sổ chính của sản phẩm

Trang web cập nhật

Được sử dụng để tổ chức và xuất các feature để chúng có thể được cài đặt trong

các ứng dụng Eclipse Để tạo một trang cập nhật, nhà phát triển cần tạo một filesite.xml và xây dựng một trang web PDE cung cấp một trình soạn thảo cho việc tạo ra

các trang web đó Một trang web sẽ chứa một hoặc nhiều feature được sắp xếp trong các danh mục Khi trang web được xây dựng, các feature (cùng với tất cả các plug-in của feature đó) sẽ được xuất ra dưới dạng có thể cài đặt được và hai tệp “content.xml”

và “artifacts.xml” sẽ được sinh ra cùng giúp cho việc cài đặt được dễ dàng hơn Cáctệp này cùng với “site.xml” chung thành một trang cập nhật Eclipse Để làm cho trangweb cập nhật khả dụng với người khác thì tất cả các tệp trên phải có trong một thưmục hoặc trang web chia sẻ được

1.6 Tổng kết chương

Chương này đã trình bày các kiến thức nền tảng được sử dụng trong luận văn.Đầu tiên, các khái niệm về thiết kế hướng miền DDD được giới thiệu Mục tiêu củathiết kế hướng miền là 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ếtcài đặt với một mô hình phát triển Tiếp theo, phương pháp phát triển phần mềmhướng miền DDSDM và công cụ hỗ trợ phát triển phần mềm hướng miềnDomainAppTool được trình bày một cách chi tiết DDSDM là một phương pháp pháttriể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 và nhờ có sự

hỗ trợ của công cụ DomainAppTool mà nguyên mẫu phần mềm được sinh ra một cáchnhanh chóng, phù hợp với các nguyên tắc thiết kế phần mềm hướng miền Cuối cùng,thành phần mở rộng Eclipse Plug-in với kiến trúc mở cho phép mở rộng nền tảngEclipse theo mục đích cụ thể thông qua việc xây dựng các plug-in

Hiện tại, việc sinh ra phần mềm từ mô hình đang được thực hiện một cách thủcông bằng các dòng lệnh command line Điều này gây khó khăn cho người sử dụng khimuốn xem hoặc chỉnh lớp miền và các mô-đun phần mềm được sinh ra Chương tiếptheo của luận văn sẽ trình bày quá trình xây dựng một Eclipse Plug-in cho phần mềmhướng miền

CHƯƠNG 2 XÂY DỰNG ELCIPSE PLUGIN CHO

PHẦN MỀM HƯỚNG MIỀN 2.1 Giới thiệu chương

Đầu tiên, các yêu cầu xây dựng Plug-in sẽ được mô tả, bao gồm yêu cầu đầu vào

và yêu cầu đầu ra Tiếp đến, mô hình thiết kế Eclipse Plug-in cho phần mềm hướngmiền được trình bày: từ mô hình thiết kế UML đến các thuật toán được sử dụng choplug-in là thuật toán tự động sinh phương thức Bspace, thuật toán sinh cấu hình mô-đun phần mềm MCC và thuật toán sinh cấu hình phần mềm SWC Cuối cùng là chi tiếtcác bước thực hiện cài đặt plug-in

2.2 Mô tả yêu cầu cho Plug-in

Các nền tảng phần mềm DDD hiện nay tập trung chính vào việc sử dụng thành

phần mở rộng dựa trên annotation của ngôn ngữ lập trình hướng đối tượng (OOPL) để

xây dựng mô hình miền Mô hình miền này không chỉ là cơ sở cho ngôn ngữ chungđược phát triển và sử dụng bởi tất các thành viên trong nhóm phát triển mà còn được

sử dụng như đầu vào để sinh phần mềm [7] Phát triển DSL dựa trên annotation cho

DDD cần vượt qua hai khoảng trống kỹ thuật (hình 2.1) tồn tại giữa các mô hình miềncủa ba đối tượng chính trong nhóm phát triển DDD là chuyên gia miền, nhà thiết kế và

lập trình viên [6] Domain gap được gây ra bởi sự không khớp nhau trong quan điểm

của chuyên gia miền và nhà thiết kế về các khái niệm và rằng buộc miền cần được xác

định trong mô hình miền Model gap do sự không khớp nhau trong quan điểm của nhà

thiết kế và lập trình viên về tính khả thi và hiệu quả cài đặt của mô hình miền

Hình 2.1: Các thử thách cho DSL dựa trên annotation [6]

Domain gap có thể là cầu nối đảm bảo rằng DSL dựa trên annotation vừa trừu tượng vừa có hàm ý để thể hiện miền một cách đầy đủ và toàn diện Mặt khác, model gap có

thể là cầu nối đảm bảo ngôn ngữ được định nghĩa là ngôn ngữ mô hình hóa mức cao(ví dụ như UML) hữu ích cho việc phân tích các yêu cầu miền Các nghiên cứu vềDDD có bốn hạn chế chính đối với việc lập đầy các khoảng trống trên và sinh phầnmềm Đầu tiên, các giải pháp mô hình hóa cấu trúc không hỗ trợ đầy đủ các liên kết,không định nghĩa các rằng buộc cấu trúc cần thiết và thiếu sự hỗ trợ giữa trạng thái