Tìm hiểu mô hình miền chuyên biệt và ứng dụng vào bài toán chuyển đổi dữ liệu cước

Định nghĩa ngôn ngữ mô hình cho một miền chuyên biệt Định nghĩa một ngôn ngữ mô hình bao gồm ba dạng: các khái niệm miền, ký hiệu đồ họa sử dụng để đại diện cho các mô hình, và các luật

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN DŨNG

TÌM HIỂU MÔ HÌNH MIỀN CHUYÊN BIỆT

VÀ ỨNG DỤNG VÀO BÀI TOÁN CHUYỂN

ĐỔI DỮ LIỆU CƯỚC

LUẬN VĂN THẠC SĨ

Hà Nội - 2011

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN DŨNG

TÌM HIỂU MÔ HÌNH MIỀN CHUYÊN BIỆT

VÀ ỨNG DỤNG VÀO BÀI TOÁN CHUYỂN

ĐỔI DỮ LIỆU CƯỚC

Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm

Mã số: 60 48 10

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Đặng Đức Hạnh

Hà Nội – 2011

I

Lời cam đoan

Tôi xin cam đoan luận văn “Tìm hiểu mô hình miền chuyên biệt và ứng dụng vào bài toán chuyển đổi dữ liệu cước” là do tôi tự nghiên cứu và hoàn thành dưới sự hướng dẫn của TS Đặng Đức Hạnh

Tôi xin chịu hoàn toàn trách nhiệm về lời cam đoan này

Hà nội, ngày 21 tháng 06 năm 2011

Nguyễn Văn Dũng

II

Lời cảm ơn

Tôi xin trân trọng gửi lời cảm ơn tới giáo viên hướng dẫn - TS Đặng Đức Hạnh

Là người hướng dẫn để tài, TS Đặng Đức Hạnh đã tận tình hướng dẫn tôi trong quá trình hoàn thành đề tài luận văn này

III

MỤC LỤC

Lời cam đoan I Lời cảm ơn II MỤC LỤC III Danh mục các ký hiệu, các chữ viết tắt IV Danh mục các hình vẽ V

MỞ ĐẦU 1

Chương 1 – TÌM HIỂU MÔ HÌNH MIỀN CHUYÊN BIỆT 2

1.1 Khái niệm và giải pháp mô hình miền chuyên biệt 2

1.2 Những lợi ích mô hình miền chuyên biệt cho người phát triển 9

1.3 Định nghĩa ngôn ngữ mô hình cho một miền chuyên biệt 11

1.4 Phát triển sinh code 13

1.5 Cách thực thi DSM 13

Chương 2 – MỘT TIẾP CẬN VỚI MÔ HÌNH MIỀN CHUYÊN BIỆT 15

2.1 Đặc trưng 1: Khả năng định nghĩa miền chuyên biệt 15

2.1.1 Tạo một DSL Solution trong Visual Studio 15

2.1.2 Định nghĩa một DSL 19

2.1.3 Định nghĩa mô hình miền 20

2.2 Đặc trưng 2: Khả năng định nghĩa các ràng buộc 20

2.2.1 Định nghĩa các luật 20

2.2.2 Định nghĩa các ràng buộc 21

2.3 Đặc trưng 3: Khả năng phát sinh code 21

2.4 Đặc trưng 4: Khả năng trình diễn 22

2.5 Đặc trưng 5: Khả năng cài đặt 31

Chương 3 – ỨNG DỤNG MIỀN CHUYÊN BIỆT TRONG THIẾT KẾ HỆ THỐNG CHUYỂN ĐỔI DỮ LIỆU CƯỚC 33

3.1 Phân tích miền định dạng dữ liệu cước 33

3.1.1 Tìm hiểu một số chính sách cước 33

3.1.2 Khảo sát một số khuôn dạng dữ liệu cước 39

3.2 Thiết kế hệ thống chuyển đổi dữ liệu cước 55

3.2.1 Xây dựng ý tưởng về hệ thống chuyển đổi dữ liệu cước 55

3.2.2 Mô tả hệ thống 57

3.2.3 Thiết kế hệ thống chuyển đổi dữ liệu cước 69

3.2.4 Mô hình vật lý của hệ thống 78

3.3 Cài đặt miền chuyên biệt định dạng dữ liệu cước để tạo ra các thư viện liên kết động 79 3.3.1 Định nghĩa miền chuyên biệt định dạng dữ liệu tổng đài 79

3.3.2 Định nghĩa các luật ràng buộc 83

3.3.3 Sinh thư viện liên dữ liệu tổng đài liên kết động 86

KẾT LUẬN 87

TÀI LIỆU THAM KHẢO 89

PHỤ LỤC 90

IV

Danh mục các ký hiệu, các chữ viết tắt

Thuật ngữ,chữ viết tắt Giải thích

DSM Domain-Specific Modeling

Mô hình miền chuyên biệt

DSL Domain-Specific Language

Ngôn ngữ miền chuyên biệt

UML Unified Modeling Language

Ngôn ngữ mô hình hóa đối tượng

V

Danh mục các hình vẽ

Hình 1-1 DSM cho thiết kế ứng dụng điện thoại di động 4

Hình 1-2 Sinh code và thực thi code theo mục đích 5

Hình 1-3 DSM cho tiến trình nghiệp vụ 6

Hình 1-4 Sinh các luồng công việc trong file XML 7

Hình 1-5 DSM for voice menu design 8

Hình 1-6 Generated 8-bit code to microcontroller 9

Hình 2-1 Domain-Specific Language Designer Wizard 15

Hình 2-2: Một DSL Solution 16

Hình 2-3: Project Debugging 18

Hình 2-5: Nút “Transform All Templates” 22

Hình 2-6: Thể hiện của một model trong designer kết quả 23

Hình 2-7: Định nghĩa diagram cho Issue State DSL 25

Hình 2-8: Định nghĩa của editor cho Issue State DSL 27

Hình 3-1 Sơ đồ kết nối của các cuộc gọi liên tỉnh trong VNPT 34

Hình 3-2 Sơ đồ kết nối các cuộc gọi quốc tế qua VTN 34

Hình 3-3 Các cuộc gọi quốc tế không qua VTN 34

Hình 3-4 Sơ đồ kết nối của các cuộc gọi VOIP liên tỉnh trong VNPT 35

Hình 3-5 Sơ đồ kết nối các cuộc gọi VOIP quốc tế trong VNPT 35

Hình 3-6 Sơ đồ kết nối các cuộc gọi di động qua VTN 36

Hình 3-7 Các cuộc gọi di động không qua VTN 36

Hình 3-8 Sơ đồ kết nối cuộc gọi VOIP liên tỉnh có qua POP 37

Hình 3-9 Sơ đồ kết nối cuộc gọi VOIP quốc tế đi không qua VTN 38

Hình 3-10 Cấu trúc của các file AMA 40

Hình 3-11 Lưu trữ và truyền file AMA 41

Hình 3-12 Bộ đệm chứa các bản ghi AMA 41

Hình 3-13 Đưa dữ liệu ra ngoài theo phương pháp giảm bộ đệm động 43

Hình 3-14 Đưa dữ liệu ra ngoài theo phương pháp điều chỉnh động 43

Hình 3-15 Quá trình ghi dữ liệu cước 44

Hình 3-16 Hoạt động của file ghi vòng 45

Hình 3-17 Thiết lập vùng copy trong file ghi vòng 47

Hình 3-18 Yêu cầu truyền FTAM bị ngắt 47

Hình 3-19 Cấu trúc gói tin AMA 48

Hình 3-30 Ý tưởng hệ thống chuyển đổi dữ liệu cước 55

Hình 3-22 Sơ đồ khối của hệ thống thu thập và xử lý dữ liệu 58

Hình 3-23 Quy trình tổng thể của hệ thống thu thập và xử lý số liệu 59

Hình 3-24 Sơ đồ hoạt động của hệ thống thu thập và xử lý dữ liệu 68

Hình 3-25 Quy trình hoạt động của khối điều khiển 70

Hình 3-26 Cấu trúc thư mục của giai đoạn chuyển đổi 71

Hình 3-27 Quy trình xử lý của quá trình chuyển đổi 72

Hình 3-28 Quy trình load dữ liệu 75

Hình 3-29 Quy trình xử lý dữ liệu 77

Hình 3-30 Mô hình vật lý của hệ thống thu thập và xử lý dữ liệu 78

Hình 3-31 Định nghĩa miền định dạng file cước tổng đài 82

Hình 3-32 Ứng dụng thiết kế trên miền định dạng file cước tổng đài 83

VI Hình 3-33 Định nghĩa ràng buộc trong miền định dạng file cước tổng đài 85

1

MỞ ĐẦU

Các mô hình sinh code hoạt động như là những cỗ máy giúp cho việc hiểu và ghi lại tài liệu code tốt hơn, ngoài ra chúng cũng có thể được sử dụng để sinh code hoàn thiện và khả dụng Sinh code hoàn thiện từ các mô hình đã trở thành mục tiêu của ngành công nghệ trong nhiều năm Việc phát triển tự động này giúp cải thiện hiệu năng, chất lượt và tránh được các vấn đề phức tạp

Không may là nhiều ngôn ngữ mô hình hóa hiện nay dựa trên code cơ bản và chỉ cung cấp chút ít khả năng để nâng cao mức trừu tượng trong thiết kế và để lưu trữ bộ sinh code hoàn thiện Ví dụ, UML sử dụng khái niệm lập trình trực tiếp (Lớp, giá trị trả lại, …) như là các cấu trúc mô hình Có biểu tượng hình chữ nhật để minh họa lớp trong biểu đồ nhưng mô tả bằng text tương đương trong ngôn ngữ lập trình lại không cung cấp khả năng sinh code thực – Mức trừu tượng trong mô hình và trong code là như nhau! Do đó, lập trình viên dễ dàng thấy rằng họ đã tự tạo mô hình mà mô tả chức năng và hành vi có thể dễ dàng viết trực tiếp như code Giới hạn về khả năng sinh code buộc người phát triển phải bắt đầu lập trình thủ công sau khi thiết kế Nó cũng dẫn đến vấn đề vòng luẩn quẩn: Có cùng một thông tin tại hai vị trí, tại code và tại các mô hình, là một sự rắc rối

Mô hình chuyên biệt miền nâng mức độ trừu tượng hơn cả lập trình bằng cách chỉ

ra giải pháp sử dụng trực tiếp khái niệm miền (domain) Sản phẩm cuối cùng được sinh ra bởi các đặc tả mức cao Quá trình tự động này là khả thi bởi vì cả ngôn ngữ và

bộ sinh code đều chỉ cần thỏa mãn yêu cầu của công ty và miền (domain) Luận văn tập trung tìm hiểu mô hình chuyên biệt miền và vận dụng vào thiết kế bài toán chuyển đổi dữ liệu cước

Luận văn được bố cục thành 5 chương Chương 1 tập chung tìm hiểu khái niệm

và lợi ích khi sử dụng mô hình miền chuyên biệt.Chương 2 trình bày về một tiếp cận

mô hình chuyên biệt miền bằng công cụ Microsoft DSL.Chương 3 minh họa việc ứng

dụng mô hình chuyên biệt miền trong thiết kế bài toán chuyển đổi dữ liệu cước

2

Chương 1 – TÌM HIỂU MÔ HÌNH MIỀN CHUYÊN BIỆT

Chương 1 tập chung tìm hiểu khái niệm và lợi ích khi sử dụng mô hình miền chuyên biệt Nội dung của chương được bố cục thành 5 mục Mục 1 trình bày tổng quan về khái niệm và giải pháp mô hình miền chuyên biệt Mục 2 nêu ra những lợi ích khi sử dụng miền chuyên biệt Mục 3 trình bày về định nghĩa mô hình cho một miền chuyên biệt Mục 4 mô tả chức năng phát sinh code Mục 5 mô tả về cách thực thi miền chuyên biệt

1.1 Khái niệm và giải pháp mô hình miền chuyên biệt

Những thách thức về vấn đề sinh code có thể được xử lý theo cách xử lý tương tự với các ngôn ngữ lập trình trước đây Bằng cách tiếp tục nâng dần mức trừu tượng Các mô hình không nên là code nhìn thấy được (visualize code), mà là mô hình mô tả mức trừu tượng cao hơn ngôn ngữ lập trình Tương tự, như trước đây việc chuyển sang

sử dụng ngôn ngữ C để nâng mức trừu tượng thì tốt hơn là ngôn ngữ hình tượng hóa đầu tiên: code Assembler (visualizing Assembler code)

Trong mô hình miền chuyên biệt (DSM: Domain-Specific Modeling), các thành phần mô hình đại diện mô tả các đặc trưng trong thế giới miền, không phải như trong thế giới code Ngôn ngữ mô hình tuân theo mức trừu tượng và ngữ nghĩa miền, cho phép người thiết kế mô hình biết được họ đang làm việc trực tiếp với khái niệm miền nào Các quy tắc của miền có thể được đưa vào ngôn ngữ lập trình như các ràng buộc,

ý tưởng là kiểm tra và ngăn chặn những mô hình thiết kế không hợp lệ hoặc không như mong muốn Sự liên kết chặt chẽ của ngôn ngữ và vấn đề miền mang lại nhiều lợi ích Những điều đó là cách phổ biến để chuyển ngôn ngữ lập trình lên các mức trừu tượng cao hơn: cải tiến hiệu năng, giảm đi sự phức tạp, và chất lượng hệ thống tốt hơn Mặc dù sự trừu tượng ở mức cao sẽ thay đổi giữa các ứng dụng và sản phẩm Mọi miền đều chứa đựng những khái niệm chuyên biệt của nó và các ràng buộc chính xác Cho nên, các ngôn ngữ mô hình cần là chuyên biệt cho mỗi một miền Ta lấy một ví

dụ Nếu chúng ta đang phát triển một cổng thông tin so sánh và mua các sản phẩm bảo hiểm, tại sao lại không sử dụng trực tiếp thuật ngữ bảo hiểm trong ngôn ngữ thiết kế? Các khái niệm ngôn ngữ như „Risk‟,‟Bonus‟ và „Dammage‟ phản ánh những bản chất của bảo hiểm hơn là các lớp Java Một ngôn ngữ chuyên biệt về bảo hiểm cũng có thể

a.Một số ví dụ về miền chuyên biệt

Chúng ta sẽ tiếp tục minh họa lợi ích của DSM qua việc sử dụng các ví dụ thực

tế Chúng ta chỉ ra ở đây ba trường hợp từ các miền ứng dụng khác nhau: ứng dụng điện thoại di động, luồng xử lý nghiệp vụ và voice menus (danh mục giọng nói) trong

bộ vi điều khiển 8bit Những ví dụ này tập trung vào tính logic và hành vi của ứng dụng, chứ không chỉ tập trung vào các cấu trúc tĩnh mà thường được tạo ra dễ dàng hơn

Những ứng dụng điện thoại Symbian Series 60

Hỗ trợ bạn phát triển những ứng dụng doanh nghiệp cho di động Sau đó, những phát triển viên của bạn sẽ tạo ra các ứng dụng như: kiểm tra trạng thái kiểm kê, thứ tự, đăng ký sự kiện, Trước khi xây dựng bất kể một ứng dụng mới nào, thì người phát triển cũng đều phải thiết kế chúng trong miền chuyên biệt “phone” Điều này kéo theo việc áp dụng những thuật ngữ và quy tắc của chiếc điện thoại, như là danh bạ, phím nóng, views, tin nhắn văn bản, và các hành động của người sử dụng DSM sẽ áp dụng trực tiếp những khái niệm tương tự này trong ngôn ngữ mô hình

Một ví dụ của ngôn ngữ mô hình miền chuyên biệt được mô tả trong Hình 1-1 Nếu bạn đã quen với một số ứng dụng phone, giống như phone book hoặc lịch, thì bạn gần như đã hiểu hết ứng dụng này dùng để làm gì Một người sử dụng có thể đăng ký cuộc họp bằng cách sử dụng tin nhắn văn bản, lựa chọn một phương thức thanh toán, hiển thị chương trình và dữ liệu giọng nói, duyệt chương trình hội thảo qua web hoặc cũng có thể hủy đăng ký

Mô hình thiết kế trực tiếp dựa trên các khái niệm miền, như Note, Pop-up, Text Message, Form, và các truy vấn DSM sử dụng những widgets và services của điện thoại như là những khái niệm mô hình và đảm bảo các điều kiện ràng buộc mà mô

4

hình lập trình phone được tuân thủ Nó cũng ngăn chặn rất nhiều những thiết kế không hợp lệ hoặc không mong muốn - Như là: dẫn đến giảm hiệu năng hệ thống Sau đó, bộ sinh code cụ thể sẽ sinh ra code hoàn thiện từ mô hình thiết kế, được gọi là các dịch vụ nền của phone (phone‟s platform services), và thực thi kết quả trong bộ giả lập hoặc thiết bị cuối (Hình 1-2)

Hình 1-1 DSM cho thiết kế ứng dụng điện thoại di động

5

Hình 1-2 Sinh code và thực thi code theo mục đích

Ở đây, DSM cho phép tăng mức độ trừu tượng một cách đáng kể mà không làm mất đi tính linh động Ngay cả trong trường hợp thay đổi nguyên tắc cơ bản trong kiến trúc hoặc dịch vụ nền xảy ra thì cũng chỉ tương ứng với việc chỉ thay đổi bộ sinh code hay ngôn ngữ mô hình

Mô hình tiến trình nghiệp vụ

Ví dụ này minh họa: làm thế nào để phần mềm có thể được sinh ra dựa trên mô hình tiến trình nghiệp vụ Những người quản lý nghiệp vụ có thể tập trung vào việc tìm kiếm giải pháp cho tiến trình nghiệp vụ của công ty sử dụng những khái niệm tự nhiên hoặc phổ biến Họ vẽ ra những mô hình sử dụng những khái niệm như là quy trình của

6

các loại khác nhau, sự kiện, tiến trình con, các đơn vị trong một tổ chức … như được

mô tả trong Hình 1-3 DSM cung cấp các khái niệm mô hình cơ bản theo các quy tắc: làm cách nào để định nghĩa các tiến trình

DSM cũng được tạo với mục đích sinh code để sinh ra các mô tả luồng công việc theo một định dạng mà một workflow engine có thể thực hiện được Tạo ra bộ sinh code cũng trở nên dễ dàng hơn như đặc tả: không cần phải xác thực – vì ngôn ngữ DSM và các ràng buộc quan hệ đã được kiểm tra

Hình 1-3 DSM cho tiến trình nghiệp vụ

7

Hình 1-4 Sinh các luồng công việc trong file XML

Voice menus for an 8-bit microcontroller

Ví dụ này minh họa một DSM sử dụng để phát triển danh bạ giọng nói - voice menus cho hệ thống tự động gia đình Bởi vì thiết bị này có bộ nhớ và các tài nguyên khác giới hạn nên DSM giúp tối ưu code Hình 1-5 minh họa luồng thực thi của một hệ thống voice menu

DSM cung cấp những trừu tượng được định nghĩa trước, thích hợp với nhu cầu phát triển cụ thể Với các nhà phát triển, nghĩ về chuỗi logic truyền thông như là

„Menu‟, ‟Prompt‟, và „Voice entry‟ thì tự nhiên hơn là nghĩ nó như các thuật ghi nhớ Assembler

8

Bộ sinh mã tạo ra code assembler với chức năng cần thiết để đánh địa chỉ bộ nhớ, tính toán … (Hình 1-6) Cần lưu ý rằng, mặc dù nền đích và mã là ở mức thấp, nhưng

ngôn ngữ DSM vẫn có thể thao tác trên các khái niệm miền thuần, như là: menu item,

voice message and menu selection Vì thế, bằng cách thay đổi trình sinh code chúng ta

có thể sinh ra cho các đối tượng C từ các thiết kế tương tự

Hình 1-5 DSM for voice menu design

Những thay đổi yêu cầu thường do miền vấn đề (problem domain) chứ không phải do miền thực thi (implementation domain), cho nên việc tạo ra những sự thay đổi trong ngôn ngữ mô hình, mà sử dụng thuật ngữ miền, thì dễ hơn Thêm vào đó, trong một số miền, không cần có lập trình viên cũng có thể tạo ra đặc tả hoàn chỉnh và chạy

bộ sinh code để tạo ra code

10

Giữ các đặc tả ở mức trừu tượng hóa cao hơn đáng kể so với mã nguồn truyền thống Bởi vì một ngôn ngữ cần phù hợp với chỉ một miền cụ thể, thường miền đó là nghiệp vụ của một công ty, DSM có thể rất nhẹ Nó không bao gồm nhiều kỹ thuật hay cấu trúc mà tạo thêm nhiều công việc không cần thiết cho người phát triển

DSM giảm bớt sự cần thiết của việc học ngữ nghĩa mới Các khái niệm miền vấn

đề (Problem domain concepts) đã được sử dụng phổ biến, thì những ngữ nghĩa dễ xác định đã tồn tại và được coi là tự nhiên như là bản chất của nó Bởi vì ngữ nghĩa miền

cụ thể luôn phải được quản lý, vậy tại sao lại không đặt trạng thái lớp đầu tiên cho chúng? Người phát triển không cần phải học ngữ nghĩa bổ sung (ví dụ UML) và ánh

xạ trước sau giữa miền và các ngữ nghĩa UML Việc ánh xạ không cần thiết này là tốn thời gian và tài nguyên, dễ dấn tới lỗi, và được thực hiện bởi tất cả những người thiết

kế - một số người có thể làm tốt hơn, nhưng thường thì mọi người làm khác nhau DSM dẫn tới hệ thống chất lượng tốt hơn, phần lớn bởi hai lý do Thứ nhất, DSM

có thể chứa những luật của miền làm cho nó chính xác hơn, và thường không thể tạo ra những điều không hợp lệ hoặc những đặc tả không mong muốn Đây cũng là một cách giảm chi phí để loại trừ gỡ lỗi: càng phát hiện lỗi sớm càng tốt hơn Thứ hai, người sinh code cung cấp ánh xạ tới một mức trừ tượng thấp hơn Sau cùng, đặc tả được tạo với thuật ngữ miền thường dễ đọc hơn, dẽ hiểu, dễ nhớ, hợp lệ và dễ giao tiếp với nó

a.Sử dụng DSM

Mô hình miền đặc biệt cho phép phát triển nhanh hơn, dựa trên nền tảng các mô hình của mô hình bài toán hơn là trên các mô hình của code Kinh nghiệm của DSM chỉ ra rằng mục tiêu chính là cải tạo hiệu năng sản phẩm, giảm thấp công sức phát triển

và chất lượng tốt hơn Các nhân tố cốt lõi đó đóng góp các điều sau:

 Vấn đề được xử lý một lần tại mức trừu tượng cao nhất và code cuối cùng được sinh ra ngay từ giải pháp này

 Tập trung của người phát triển chuyển từ code tới thiết kế, xử lý vấn đề Độ phức tạp và sự triển khai chi tiết có thể được ẩn đi, và quen thuộc với người sử dụng

11

 Tính bền vững của sản phẩm và ít gặp lỗi đã đạt được tính đơn trị tốt hơn của môi trường phát triển và giảm đi sự chuyển đổi giữa các mức thiết kế và triển khai

 Kiến thức về miền được tạo ra rõ ràng cho nhóm phát triển, và được nắm bắt trong ngôn ngữ mô hình và hỗ trợ các tiện ích

Sự cài đặt DSM không phải đầu tư bổ sung thêm nếu người thiết kế quan tâm đến tất cả chu trình từ thiết kế đến sinh mã Hơn nữa, nó lưu các tài nguyên phát triển: Thông thường tất cả các người phát triển đều làm việc với các khái niệm miền vấn đề

xử lý và ánh xạ chúng tới các khái niệm thực thi một cách thủ công Và giữa các nhà phát triển, có một sự khác nhau lớn Một số thì làm tốt, nhưng không phải là ai cũng làm tốt Vì thế để những người phát triển có kinh nghiệm định nghĩa ra các các khái niệm và ánh xạ chúng, và những người còn lại không cần làm điều đó nữa Nếu hàm sinh code đặc biệt chuyên nghiệp, nó sẽ cho ra những những dụng chất lượng tốt hơn

so với việc phát triển thủ công

1.3 Định nghĩa ngôn ngữ mô hình cho một miền chuyên biệt

Định nghĩa một ngôn ngữ mô hình bao gồm ba dạng: các khái niệm miền, ký hiệu

đồ họa sử dụng để đại diện cho các mô hình, và các luật để hướng dẫn tiến trình của

mô hình Định nghĩa một ngôn ngữ hoàn chỉnh là một công việc khó nhưng đó là điều cần thiết nếu bạn muốn xây dựng một ngôn ngữ chuyên biệt cho tất cả Công việc đó

dễ hơn đáng kể nếu bạn tạo nó duy nhất cho một miền bài toán trong một công ty Chìa khóa cho việc tìm kiếm những khái niệm miền là sự cung cấp kinh nghiệm bởi các chuyên gia miền Điển hình, chuyên gia là những người phát triển có kinh nghiệm phát triển một vài sản phẩm trong miền đó Họ có thể thiết kế kiến trúc đằng sau các sản phẩm, hoặc phải chịu trách nhiệm cho việc tạo ra các thư viện đối tượng Anh ta có thể dễ dàng nhận ra những khái niệm miền từ các mô tả hệ thống và đối tượng dịch vụ

Trong ví dụ ứng dụng phone, các khái niệm miền đến từ các thành phần UI (ví dụ: Form,Popup), menu và cấu trúc các button (các khóa người sử dụng có thể định nghĩa) và các dịch vụ ngầm (ví dụ: text messages, web browsing) Bằng những khái niệm được gán cho ngôn ngữ mô hình và có thể định nghĩa lại chúng trong tương lai,

12

chúng ta có thể tạo một phần khái niệm của ngôn ngữ mô hình Mục tiêu ở đây là tạo

ra sự lựa chọn các khái niệm ánh xạ chính xác tới ngữ nghĩa của miền

Tuy nhiên, các khái niệm miền đơn ban đầu không tạo ra ngôn ngữ mô hình: chúng ta cần kiến thức về miền: làm cách nào để ghép nối chúng với nhau Với miền này, chúng ta chọn luồng ứng dụng giống như mô hình cơ bản của sự tính toán Sự mô

tả các khái niệm miền tương tác như thế nào trong suốt quá trình ứng dụng thực thi (nhìn Hình 1-1 để minh chứng) Chúng ta giới thiệu các khái niệm của sự bắt đầu và kết thúc các luồng trực tiếp-có hoặc không có điều kiện Các điều kiện được sử dụng khi người sử dụng có thể lựa chọn một trong những sự lựa chọn có thể, ví dụ thông qua list hoặc một menu Chúng cũng thêm khái niệm cho code thư viện, tạo ra nó có khả năng liên kết trong một đối tượng mở rộng trung gian và gọi chúng với các tham

số

Tiếp theo, những khái niệm cơ bản thì được bổ sung với các luật của miền Đặc trưng, các luật ràng buộc sự sử dụng của ngôn ngữ bằng các định nghĩa các loại kết nối giữa các khái niệm là hợp lệ.Chúng ta có thể đặc biệt hóa làm thế nào để chắc chắn các khái niệm có thể được tái sử dụng và làm cách nào để các mô hình có thể được tổ chức Trong ví dụ phone, các luật định nghĩa khi các phần tử UI có thể có sở hữu các menus, cái mà có thể định nghĩa các buttons bởi người sử dụng, và làm cách nào để các dịch vụ phone khác nhau có thể được gọi trong quá trình thực thi ứng dụng Các luật cùng với các khái niệm được đánh mã và cách điệu hóa vào trong sự đặc tả ngôn ngữ cái mà thường xuyên được gọi như là một metamodel Một metamodel mô tả ngôn ngữ mô hình hóa, giống nhưu cách mô tả ngôn ngữ của một ứng dụng

Cung cấp phần chú thích của ngôn ngữ mô hình, chúng ta định nghĩa các biểu tượng đại diện cho giao diện đồ họa của các khái niệm miền Giống như miền ví dụ của chúng ta đó là mối quan hệ giao diện người dùng, chúng ta có thể dựa trên một số biểu tượng đó trên giao diện của phone

a.Định nghĩa domain framework

Domain framework cung cấp giao diện giữa quá trình sinh code và tầng nền dưới Trong một số trường hợp, code framework mở rộng không cần thiết: sự sinh code có thể trực tiếp gọi các đối tượng nền và các dịch vụ của họ là đủ Cho dù thế, định nghĩa những code tiện ích framework mở rộng để tạo cho việc sinh code nhanh hơn Như

13

vậy các đối tượng có thể đã tồn tại từ kết quả của sự phát triển trước và các sản phẩm mới được tạo tạo ra chỉ cần một ít sự tác động lên các đối tượng đã có

Trong ví dụ của chúng ta, framework ứng dụng chuyên nghiệp Symbian/Series

60 đã đưa ra một tập các dịch vụ tốt, ở mức cao hơn so với nền Series 60.domain framework như vậy chỉ thêm hai chức năng: một bộ điều phối để thực hiện luồng logic của ứng dụng, và hiển thị sự quản lý cho các ứng dụng nhiều khung nhìn

1.4 Phát triển sinh code

Sau cùng, chúng ta muốn đóng khoảng trống giữa mô hình và code bởi định nghĩa cách sinh code Những vấn đề đặc biệt khi sinh code là làm cách nào các thông tin được đưa ra từ các mô hình và chuyển chúng vào trong code Code đó sẽ được liên kết với framework và biên dịch thành có khả năng thực thi cuối cùng mà không cần bổ sung thêm các điều kiện một cách thủ công Code được sinh ra đơn giản là một trung gian từ sản phẩm trong quá trình tới khi kết thúc sản phẩm,giống như các file o trong quá trình biên dịch C

Chìa khóa đưa ra trong việc xây dựng một bộ sinh code là các khái niệm mô hình được ánh xạ với code như thế nào Domain framework và thư viện đối tượng có thể tạo ra các nhiệm vụ một cách dễ dàng bằng cách tăng dần các mức trừu tượng phía code Trong trường hợp đơn giản nhất, mỗi một biểu tượng mô hình sản sinh ra code

cố định, bao gồm các giá trị được nhập vào các biểu tượng như là các tham số Hàm sinh có thể sinh ra các code khác nhau phụ thuộc vào các giá trị trong các biểu tượng, các mối quan hệ nó có cùng với các biểu tượng khác, hoặc các thông tin khác trong mô hình

1.5 Cách thực thi DSM

Để có được lợi ích DSM cải tiến về năng suất, chất lượng và giảm đi độ phức tạp, chúng ta cần một ngôn ngữ miền chuyên biệt mô tả miền và bộ sinh code Trước đây, người thiết kế vẫn phải cần một công cụ hỗ trợ cài đặt, thực thi DSM hỗ trợ tất cả các tính năng đó

Ngày nay, công việc cần được giảm xuống để chỉ phải định nghĩa ngôn ngữ và sinh ra code, từ khi các công cụ mô hình cơ bản cho việc mô hình hóa và sinh ra code được hình thành Các công cụ đó cho phép tạo ra một môi trường làm việc sẵn sàng

14

DSM trong nhiều ngày thay vì hàng tháng, các công cụ đó yêu cầu thêm vào lập trình thủ công Hơn nữa điều quyết định là giữ được môi trường phát triển đáp ứng tới việc thay đổi miền: các công cụ có thể bảo trì các mô hình trong sự đồng bộ với sự tiến hóa của ngôn ngữ và bộ sinh nên việc thiết kế công việc an toàn trong các điều kiện công việc thật

15

Chương 2 – MỘT TIẾP CẬN VỚI MÔ HÌNH MIỀN CHUYÊN BIỆT

Chương 2 trình bày một tiếp cận mô hình miền chuyên biệt bằng công cụ thiết kế DSL của Microsoft Bố cục của chương gồm 5 mục Mục 1 hướng dẫn định nghĩa một miền chuyên biệt Mục 2 hướng dẫn tạo ra các luật trong miền Mục 3 hướng dẫn cách sinh mã Mục 4 hướng dẫn cách tạo giao diện hiển thị cho miền chuyên biệt Mục 5 hướng dẫn cách tạo bộ cài đặt

2.1 Đặc trưng 1: Khả năng định nghĩa miền chuyên biệt

Đặc trưng này cho phép người sử dụng định nghĩa miền chuyên biệt bởi ngôn ngữ miền chuyên biệt bằng công cụ Microsoft DSL Tools

2.1.1.Tạo một DSL Solution trong Visual Studio

New Project ->Nếu có cài Visual Studio SDK, trong phần Extensibility -> Domain-Specific Language Designer

Hình 2-1 Domain-Specific Language Designer Wizard

Các template bao gồm:

 Minimal Languages: Chỉ đủ thể hiện một loại box và một loại line

16

 Components Models: Các box với các port

 Classes Diagrams: Tương tự như lược đồ lớp UML (UML class

Hình 2-2: Một DSL Solution

Gần như tất cả code từ các file khác trong 2 project được phát sinh từ việc định nghĩa DSL Khi ta muốn thay đổi từ các template DSL sang DSL của ta, thì ta sẽ làm việc trên DSL definition

Code trong 2 project bao gồm 3 phần chính:

 Trình thiết kế (Designer) (hay ngôn ngữ mà ta đang định nghĩa) – Trình soạn thảo mà DSL user sẽ vẽ các model

mà tác giả DSL chọn để viết

a.Các thành phần trong DSL Solution:

Hai project được tạo lúc ban đầu bởi DSL creation wizard là Dsl và DslPackage Project Dsl cung cấp:

 Một serializer/deserializer (bộ xuất bản/hủy xuất bản) để đọc và ghi các thể hiện DSL của bạn xuống file

 Những định nghĩa lớp (class) để xử lý DSL và các lược đồ của nó trong một ứng dụng

 Một bộ xử lý chỉ dẫn(chỉ huy – directive processor) cho phép bạn có thể viết các text template mà sẽ xử lý DSL của bạn

 Các thành phần thiết yếu của trình thiết kế mà sẽ biên tập (edit) DSL này trong Visual Studio

Project DslPackage cung cấp code cho phép DSL được biên tập (edit) trong Visual Studio (Có thể viết một ứng dụng stand-alone (đứng một mình – riêng rẽ) mà

xử lý DSL chỉ sử dụng assembly được tạo bởi project Dsl ) Những file này tương tự nhau như trong các gói (pagkage) Visual Studio SDK khác

 Tài liệu (document) xử lý code nhận biết được phần mở rộng file của DSL và mở trình thiết kế thích hợp

 Các menu lệnh (menu command) kết hợp với trình thiết kế DSL

 Các file item template từ đó các thể hiện mới của DSL có thể được tạo

ra

Trong mỗi project, có một thư mục có tên là GeneratedCode Thư mục này chứa các file text template (phần mở rộng là tt), mỗi file có một file được phát sinh (generated file) như là phần phụ trợ của nó Trong solution explorer, click vào dấu [+]

để thấy generated file Hầu hết các file text template có nhiều tham chiếu đến các

b.Chạy thử một DSL Solution

Để chạy được solution ta nhấn F5 (sẽ build solution và chạy trong chế độ debugging), việc tương đương với menu lệnh “Debug Start Debugging” Chúng ta sẽ xem DSL trong 1 trình thiết kế (trình biên tập đồ họa) chạy chung với Visual Studio Khi nhấn F5 sẽ xuất hiện 1 thể hiện khác của Visual Studio, được khởi tạo để thể hiện 1 ví dụ của DSL

Thể hiện mới của Visual Studio sẽ mở một project mẫu tên là Debugging, ta mở file

mô hình là có tên là Sample.* (ví dụ Sample.iss)

Hình 2-3: Project Debugging

 Cửa sổ lớn nhất là màn hình thiêt kế, phần trình bày chính của 1 thể hiện DSL Ta phải biên tập lại việc định nghĩa DSL (trong thể hiện Visual Studio chính) để có thể thêm các định nghĩa của các thành phần Khi toàn bộ DSL làm việc và được triển khai, người sử dụng DSL sẽ vẽ các lược đồ của họ ở đây

19

 Bên trái là toolbox Để thêm một phần tử mới, ta drag từ toolbox và kéo vào diagram (lược đồ); Để tạo 1 mối kết nối mới (connector) mới, ta click vào công cụ liên quan, click trên phần tử source, sau đó là phần tử đích trên lược đồ Ta phải biên tập DSL definition để mà có thể thay đổi tên của công cụ và add thêm tool

 Bên phải là model explorer Nó hiển thị model dưới dạng cây Nó hiển thị các phần tử (element) và các mối quan hệ nhúng của chúng Trong một vài DSL, có nhiều phần tử không xuất hiện trong màn hình thiết kế chính nhưng sẽ luôn xuất hiện trong model explorer

 Solution explorer hiển thị project Debugging chứa file mẫu Ta có thể đổi tên project Khi nó được triển khai, các bản sao của project này sẽ chạy cùng với mã của ứng dụng mà ta viết cho Thêm các text template file mà sẽ đọc các thể hiện DSL của người sử dụng và tạo ra code

 Bên dưới là properties window dùng để thay đổi các thuộc tính của các phần tử được chọn

2.1.2.Định nghĩa một DSL

Để định nghĩa DSL ta mở file DslDefinition.dsl trong project Dsl, sẽ mở ra trình thiết

kế DSL Trình thiết kế trong giống như trình thiết kế của Minimal language hay bất kỳ DSL cụ thể khác

Cửa sổ chính gồm 2 swimlane hay cột: bên tay trái, là mô hình miền là các domain class và relationship, bên tay phải là các shape và các connector mà thể hiện chúng lên màn hình Ta có thể thêm mới các phần tử bằng cách sử dụng các công cụ trong toolbox Trình thiết kế duy trì mốt sự trình bày dạng cây các phần tử và các mối quan

hệ của chúng Click phải lên domain class, sẽ tìm được lệnh sắp xếp lại cây

Ta edit tên của domain class, shape, connector, diagram, role name (nhãn trên 2 cánh tay của mỗi relationship), và tên của relationship Tất cả có thê edit trực tiếp trên diagram, ngoại trừ role name

Để thay đổi nhãn xuất hiện trên 1 relationship role, edit tên của role đối diện

Để đổi tên của các công cụ sẽ xuất hiện trong toolbox Những tên này không hiển thị trong main diagram của việc định nghĩa DSL – thay vào đó nhìn vào DSL explorer; sự

20

định nghĩa các tool có thể được tìm thấy trong node Editor Tên của chúng có thể được edit trong properties window cùng với các tooltip và tiêu đề mà sẽ hiển thị cho người

sử dụng

2.1.3.Định nghĩa mô hình miền

Phần này mô tả làm thế nào để định nghĩa mô hình miền và một mô hình miền có nghĩa gì trong vai trò của một công cụ DSL được phát sinh (generated DSL tool) Tất cả các DSL đều có một mô hình miền ở nhân của nó Nó định nghĩa các khái niệm được trình bày (đại diện – miêu tả) bởi ngôn ngữ, các thuộc tính của chúng, và các mối quan hệ của chúng Tất cả các người sử dụng DSL phải có kiến về những cái này tới một vài phàm vi, bởi vì tất cả các phần tử họ tạo ra và thao tác trong khi sử dụng DSL

sẽ được mô tả bởi mô hình miền Mô hình miền giống như một ngữ pháp cho DSL; nó định nghĩa các phần tử mà cấu thành một model và đưa ra các luật để làm thế nào các phần tử này có thể được kết nối với nhau

Mô hình miền cũng cung cấp các nền tảng cho việc xây dựng các khía cạnh khác của ngôn ngữ Việc định nghĩa các ký hiệu, toolbox, explorer, cửa sổ thuộc tính, việc xác định tính hợp lệ, sự xuất bản, và sự triển khai, tất cả đều được xây dựng trên mô hình miền Nó cũng được dùng để phát sinh API có thể lập trình, mà bạn có thể sử dụng để tùy biến và mở rộng ngôn ngữ, và có thể truy cập từ các template đẻ phát sinh code và các artifact nguyên bản khác

Các thành phần cơ bản của mô hình miềning khá đơn giản nếu bạn quen thuộc với thiết kế hướng đối tượng hay lập trình hướng đối tượng

2.2 Đặc trưng 2: Khả năng định nghĩa các ràng buộc

2.2.1.Định nghĩa các luật

Một khái niệm quan trọng khác khi làm việc với các model trong store là các luật

Chúng ta sẽ gặp các luật này khi viết các tùy biến Một luật được định nghĩa khi tác

giả DSL cần lan truyền các thay đổi tới các phần tử trong store để mà các phần tử khác cũng bị ảnh hưởng Ví dụ, các luật được sử dụng để sửa các diagram một cách tự

động bất cứ khi nào model thay đổi Bây giờ chúng ta sẽ chú ý một vài điều thiết yếu sau:

 Luật có một thuộc tính RuleOn chỉ ra lớp nào nó áp dụng trên đó

 Luật được thực thi với giao tác trong đó sự thay đổi xuất hiện Nó có thể tạo ra các thay đổi để luật được áp dụng (được đưa vào hang đời để được thực thi)

Phải đăng ký custom rule nay trong lớp DomainModel:

public partial class IssueStateModelsDomainModel

 Thay đổi trên mô hình

 Tạo 1 file C# trong 1 thư mục tách biệt sát cạnh mã được phát sinh (generated code), file này sẽ chứa 1 phần định nghĩa class, thêm các phương thức xác nhận tính hợp lệ vào trong các class được phát sinh (generated class)

2.3 Đặc trưng 3: Khả năng phát sinh code

Code (mã) cho trình thiết kế của DSL được phát sinh từ file định nghĩa DSL Để thực hiện, vào solution explorer( trong Visual Studio chính) click vào nút “Transform All Templates” Tất cả các file mã sẽ được phát sinh

22

Hình 2-5: Nút “Transform All Templates”

Sau khi biên tập việc định nghĩa DSL, luôn luôn nhấn nút “Transform All Templates” Thư mục “GeneratedCode” chứa các file text template với phần mở rộng là tt Mỗi file có có một file phụ trợ đó là kết quả được phát sinh Click dấu [+] để xem Các file được phát sinh bao gồm cả C# và resource file Đừng thay đổi các file được phát sinh (generated file)

Nhấn F5 để qua experimental Visual Studio (Debugging project) Thêm file mới vào project Debugging (menu lệnh “Add new item”), thêm vào nó các phần tử và mối quan hệ

2.4 Đặc trưng 4: Khả năng trình diễn

Mục này mô tả cách làm thế nào để định nghĩa presentation aspect – giao diện Đó là làm thế nào thông tin được mã hóa trong các model element bên dưới được hiển thị thông qua giao diện người dùng của trình thiết kế

Có 3 cửa sổ trong giao diện người dùng mà các thông tin được hiển thị: vùng thiết kế,

model explorer, và cửa sổ thuộc tính

Việc định nghĩa khía cạnh trình bày (presentation aspect – giao diện) bao gồm việc định nghĩa các ký hiệu đồ họa trên vùng thiết kế, việc tùy biến sự xuất hiện của trình explorer, và sự tùy biến sự xuất hiện của cửa sổ thuộc tính

Phần phức tạp nhất là việc định nghĩa các ký hiệu đồ họa, vì thế hầu hết chương này sẽ giải thích về khía cạnh này Trình explorer và cửa sổ thuộc tính sẽ giải quyết sau cùng

Ký hiệu Đồ họa (Graphical Notation) – Tổng quan

Một trình thiết kế đồ họa trình bày (hiển thị) một vài element của một model trên vùng thiết kế thông qua một kí hiệu đồ họa mà sử dụng các shape (hình) và các connector (mối kết nối) Tất cả các phần tử (element) được tạo ra thông qua các menu mặc định

23

trên explorer, và các hình (shape) được tạo ra trên diagram một cách tự động Nói chung, việc tạo ra một model element (phẩn tử của mô hình) sẽ tự động tạo ra phần tử giao diện tương ứng (shape hay connector – hinh hay mối kết nối)

Hình 2-6: Thể hiện của một model trong designer kết quả

Các hình (shape) trên lược đồ (diagram) được ánh xạ tới các phần tử (element) trong

mô hình (model)

Các hình (shape) và mối kết nối (connector) trong định nghĩa DSL (DSL definition)

có nhiều thuộc tính cho phép tùy biến màu sắc và kiểu (style), kích thước ban đầu khi shape được tạo ra lần đầu tiên, hình dáng hình học của shape, và v.v… Bạn có thể định nghĩa bộ trang trí văn bản (text và iocn decorator) và icon cho các shape và mối kết nối Một text decorator (bộ trang trí text) được sử dụng để hiển thị text, thường là giá trị của một vài domain property bên dưới, với hay liền kề với một shape

Để các model element trong DSL có thể được trực quan hóa (visualize) trên diagram (diagram surface) Ta cần phải định nghĩa:

 Loại (kind) và vẻ bề ngoài (appearance – sự xuất hiện) của các hình (shape) mà sẽ được sử dụng để thể hiện (present) những phần tử (element) đó

24

 Một ánh xạ từ định nghĩa hình (shape definition) tới domain class của các phần tử, mà sẽ điều khiển hành động sắp đặt (placement behavior) của một hình (shape) và diện mạo (appeareance) của trình trang trí (decorator) bị ảnh hưởng như thế nào khi dữ liệu thay đổi

Để các link có thể được trực quan hóa trên diagram thì cần phải định nghĩa:

 Diện mạo của mối kết nối (connector) mà sẽ được sử dụng để thể hiện các link

 Một ánh xạ từ định nghĩa connector tới domain relationship cho các link,

sẽ xác định cách hành xử kết nối của một connector và diện mạo của decorator bị ảnh hưởng như thế nào khi dữ liệu thay đổi

Có nhiều loại shape (ví dụ shape hình học và shape hình ảnh) Shape hình ảnh hiển thị một hình ảnh cụ thể Một shape hình học hiển thị một shape với đường nét hình học bên ngoài như hình chữ nhật (người sử dụng DSL có thể resize)

Diagram và Editor

Việc định nghĩa kí kiệu đồ họa được thực hiện trong ngữ cảnh của một diagram, sau

đó được tham chiếu bởi việc định nghĩa editor

Định nghĩa diagram và editor xuất hiện như là các node trong DSL explorer Cả 2 node này trong định nghĩa DSL được tạo ra khi tạo một project DSL sử dụng project template DSL designer Nếu bạn xóa nó, có thể tạo lại nó băng cách click lên node cấp cao nhất (Dsl) trong DSL explorer và chọn “Add Diagram” hay chọn “Add Custom Editor” / “Add Designer” từ menu ngữ cảnh

Diagram

Việc định nghĩa diagram là một vật chứa (container) cho các shape map và connector map Hình bên dưới trình bày định nghĩa của diagram cho Issue State DSL

25

Hình 2-7: Định nghĩa diagram cho Issue State DSL

Cửa sổ bên tay trái trình bày các phần tử con (sub-element) của định nghĩa diagram trong DSL explorer, và cửa sổ bên tay phải là các thuộc tính của định nghĩa DSL Các thiết đặt thuộc tính được tóm tắt trong bảng sau

như màu background

sinh cho diagram Tất cả các thiết đặt này được kề thừa từ domain class, bởi vi một định nghĩa diagram cũng là một domain class

namespace, base diagram), với sự bổ sung thêm một thuộc

26

tính để chỉ rõ lớp của element được thể hiện bởi một diagram

liệu định nghĩa một thuộc tính chứa các note (ghi chú) về thiết kế của DSL

được sử dụng với giao diện của trình thiết kế đích Tài nguyên được phát sinh trong file resx để mà chúng có thể được cục bộ hóa cho các văn hóa khác nhau Một từ khóa

để drive F1 Help trong trình thiết kế đích có thẻ được cung cấp

Bảng 0-1: Các mục thiết đặt thuộc tính cho diagram

Editor

Có 2 loại editor: một trình thiết kế đồ họa (giao diện – graphical designer) và một trình soạn thảo tùy biến Định nghĩa của một editor xuất hiện trong node “Editor” trong DSL explorer Dữ liệu được định nghĩa ở đây được sử dụng để phát sinh ra các cái đặt (implementation) của lớp EditorFactory, toolbox, và các hành động xác nhận tính hợp

lệ Mặc định khi bạn tao ra một DSL authoring project mà sử dụng DSL designer project template, định nghĩa DSL định nghĩa một trình thiết kế (designer) như là một trình soạn thảo của nó (editor)

Trình soạn thảo (một phần của định nghĩa DSL) chứa định nghĩa của toolbox và hành động xác định tinh hợp lệ

Ví dụ: Định nghĩa của editor cho Issue State DSL được chỉ ra trong hình sau:

27

Hình 2-8: Định nghĩa của editor cho Issue State DSL

Các thuộc tính của editor bao gồm một tham chiếu tới “Root Class” mà liên kết với designer (trình thiết kế) (ví dụ, xuất hiện như là phần tử trên cùng trong editor‟s explorer được phát sinh) “Editor Guid” được sử dụng trong code cho lớp EditorFactory được phát sinh

Trong mục “Resources”, có các thiết đặt để định nghĩa phần mở rộng của file được sử dụng để chứa các model cho DSL và định nghĩa icon liên đới với nhứng file đó (ví dụ, trong Windows Explorer hay Visual Studio solution explorer)

Designer (Trình thiết kế)

Khi trình soạn thảo (editor) là một trình thiết kế (designer), có một entry bên dưới mục định nghĩa trong cửa sổ thuộc tính tham chiếu tới lớp Diagram được sử dụng bởi trình thiết kế (ví dụ, IssueStateDiagram) Root class liên đới với trình thiết kề và lớp mà referenced diagram represent phải giống nhau Nếu chúng không giống nhau, một lỗi xác định tính hợp lệ trong DSL designer sẽ xuất hiện

Custom Editor(trình soạn thảo tùy biến)

Ta có thể định nghĩa một trình soạn thảo tùy biến (là một trình soạn thảo không có diagram) Ta sẽ chọn cách này nếu vùng thiết kế đồ họa (graphical design surface) không thích hợp để present (trình bày) thông tin mà bạn muốn capture (đưa vào) trong DSL của bạn Trong trường hợp này, bạn phải tạo ra một control Windows Form để cung cấp sự trình bày tùy biến (custom presentation) của dữ liệu từ mô hình

28

Để làm được điều này, xóa trình thiết kế đang đóng vai là một trình soạn thảo (chọn node Editor trong DSL explorer và nhấn delete) Và sau đó thêm vào một trình soạn thảo tùy biến (với root node trong explorer được chọn, chọn “Add Custome Editor” và thiết đặt các thuộc tính của nó

Bất cứ khi nào bạn thay đổi định nghĩa DSL, click nút “Transform All Templates” trong header của solution explorer Việc này sẽ tạo lại nội dung của các thư mục GeneratedCode Sau đó sử dụng phím F5 để complile lại code và chạy trình designer

để xem tác dụng của các thay đổi

Double click trên lỗi này sẽ dẫn bạn tới đoạn code với những chỉ dẫn trên cái bạn phải làm

Shapes(hình)

Shape là những node của một kí hiệu đồ họa và được sử dụng để trực quan hóa các phần tử của một model Phần này đi sau vào chi tiết của việc định nghĩa shape và shape map

Kind of Shapes (Các loại Shape)

Có 5 loại shape khác nhau: geometry shape (shape hình học) , compartment shape (shape ngăn ra từng phần), imgae shape (shape hình ảnh), port (cổng), và swimlane Các thiết lập (categories of setting) áp dụng cho tất cả các shape tương tự như của Diagram, cộng thêm mục “Layout” Chúng được tóm tắt trong bảng sau:

sắc, độ dày của đường kẻ, v.v…

của shape Tất cả các thiết đặt được kề thừa từ domain class, bởi vì các định nghĩa shape cũng là định nghĩa domain class

namespace, base geometry shape), với việc thêm một thuộc tính tooltip định nghĩa các hành xử của tooltip khi hover trên một shape trong trình thiết kế đích

documentation (tài liệu) định nghĩa một thuộc tính để chứa các note về thiết kế của DSL

của shape

sử dụng với giao diện của trình designer đích Các tài nguyên được phát sinh trong file resx để mà chúng có thể đượ địa phương hóa cho nhiều nên văn hóa khác nhau

Bảng 0-2: Các categories setting của shape

Các thiết đặt về outline và fill area không ảnh hương đến vẻ bề ngoài của imgae shape Tuy nhiên có 2 setting liên qua tới image shape:

 Trước tiên đó là “Image Resources” xác định image (hình) nào được hiển thị

 Thứ hai là thiết đặt “Has Default Connection Points” xác định xem shape

có các điểm kết nối (connection point) Bắc-Nam-Đông-Tây Nếu là

True thì các giá trị mặc định, nếu là False thì các mối nối sẽ nối ở bất kì

đâu dọc theo một hình chữ nhật vô hình

Ports

30

Một port là một shape đính kèm vào đường viền bên ngoài của một shape mà chỉ có thể di chuyển xung quanh đường viền đó Đình nghĩa của nó giống như của geometry shape.Hình sau minh họa một port

Swimlanes

Swimlane được sử dụng đẻ phân chia một diagram thành các dòng hay cột

Hình sau định nghĩa một swimlane thẳng đứng

Có các thiết đặt để thay đổi vẻ bề ngoài của swimlane header và separator, cũng như thuôc tính “Layout” xác định swimlane phân chia diagram theo chiều dọc hay chiều ngang Chiều rộng của horizontal swimlane được lờ đi, chiều cao của vertical swimlane thường bị bỏ qua

Shape Inheritance

Cho phép kế thừa giữa các hình, với một hạn chế là một shape thuộc một loại chỉ có thể kế thừa từ một shape cùng loại Một shape con sẽ kề thừa các decorator và compartment (nếu thích hợp) của base shape nhưng phải override các thuộc tính appearance, layout và resource với dữ liệu của nó Nếu bạn muốn nó giống base shape thì phải set bằng tay

Mapping Definition Common to All Shapes

“Parent element path” xác đinh phần tử là logical parent cho domain class được tham chiếu

Mapping Compartments

Các compartment được liệt kê bên tay trái, chọn một compartment sẽ hiện ra định nghĩa của ánh xạ cho compartment đó Có 2 thông tin cần cung cấp để mapping một compartment Thứ nhất đó là tập hợp các element được sử dụng để tạo các entry trong compartment Thứ hai là thông tin hiện tại sẽ được display cho mỗi element Hộp chọn

“Use custom element collection” thì generated code không được build, và lỗi sẽ dẫn bạn tới nơi có lỗi để xử lý

Một Port không thể được xác định cha trên Diagram Trong ShapeMap ánh xạn InPort tới InPortShape, thì parent element path dẫn tới Component-Model, mà mapped shape

là ComponentDiagram

Khi mapping swimlane, parent path nên chỉ ra element được map tới diagram (“Has custom parent element” được set là True) Nếu không, sẽ có validation error

2.5 Đặc trưng 5: Khả năng cài đặt

Một khi DSL và framework nó phát sinh đã được phát triển, chúng có thể được đóng gói trong 1 trình cài đặt và được phân phối dưới dạng chuẩn là file msi (Windows installer) Trình cài đặt bao gồm:

 Một trình thiết kế, sự phát hành và các thành phần xử lý text template cho DSL

 Một item template cho lệnh “Add new item” của Visual Studio, cho phép người sử dụng DSL tạo ra một thể hiện file mới của DSL trong một project Visual Studio

 Một project template cho lệnh “New Project” cho phép người sử dụng DSL tạo một thể hiện project mới trong đó DSL được sử dụng – bao gồm tất cả các template phát sinh code cho ứng dụng

 Các assembly được biên dịch mà cần thiết cho ứng dụng được phát sinh Điển hình các phần được phát sinh của một ứng dụng có thể được tách biệt khỏi các phần chung không thay đổi; cái sau có thể được biên dịch trong dạng đó hơn là như là source

Nếu máy tính khác chỉ có standard Visual Studio, không có Visual Studio SDK thì trình cài đặt sẽ tự động cái DSL Tool runtime và sau đó là cài DSL, Bây giờ ta có thể tạo, hiệu chỉnh, và sử dụng các thể hiện của ngôn ngữ