V. CỗN BỘ HƯỚNG DẪN (Ghi r› học hˆm, học vị, họ, t•n):
4 Thiết kế m™ h“nh dịch vụ tại GeneralRessorts
!
! Để hiểu r› hơn qu‡ tr“nh thiết kế, chœng ta minh họa từng bước thiết kế bằng c‡ch ‡p dụng cho v’ dụ của c™ng ty GR. Trong giới hạn của luận văn, chœng ta chỉ tập trung vˆo một dịch vụ thương mại đơn giản lˆ xử lý đơn đặt hˆng. Chœng ta sẽ minh họa từng bước của phương ph‡p dựa tr•n v’ dụ nˆy. Để thuận tiện, th™ng tin in nghi•ng sẽ tương ứng với t•n của một phần tử tr•n m™ h“nh.
Cuối c•ng, dưới đ‰y lˆ định nghĩa cho những lớp m™ h“nh vˆ những bước được đề xuất trong qu‡ tr“nh thiết kế.
Thiết kế dịch vụ thương mại (Business Service Design)
Trong lớp đầu ti•n, người thiết kế sẽ x‡c định những dịch vụ thương mại, xem h“nh 12. Như h“nh vẽ, chœng ta thể hiện một ph‰n khœc bao gồm c™ng ty GeneralRessort vˆ CustomerCompany. C— một dịch vụ thương mại ch’nh được m™ h“nh:
OrderProcessing. Chœng ta kh™ng thể hiện tổ chức của c™ng ty cũng như những dịch vụ
con (hˆnh động con). V“ vậy, lớp m™ h“nh nˆy đại diện cho hệ thống ở mức toˆn bộ (GeneralRessort[w]), hˆnh động ở mức toˆn bộ (OrderProcessing[w]).
Như đ‹ đề cập trong phần 2, cả hai phần hˆnh vi vˆ dữ liệu của dịch vụ sẽ được thể hiện ra. Phần hˆnh vi sẽ được biểu diễn bởi đơn vị chức năng (fu) được t™ mˆu xanh. Chœng biểu diễn những hˆnh động đơn như find, create, etc. Chœng cũng được truyền th™ng số như giải th’ch ở tr•n (bởi li•n kết criteriaAndWhichSet, input, output). Thuộc
t’nh Set biểu diễn một tập c‡c phần tử của c•ng một loại, v’ dụ Customer. Mối quan hệ
giữa những phần tử được thể hiện bởi relationship. Ở mỗi thuộc t’nh, chœng ta thể hiện bậc vˆ t•n.
H“nh 12 Ð Thiết kế dịch vụ thương mại
Dữ liệu đầu vˆo vˆ đầu ra được biểu diễn mˆu vˆng. Qu‡ tr“nh xử lý đơn hˆng ở lớp dịch vụ thương mại c— hai th™ng số đầu vˆo, Name vˆ CustomerPartId vˆ một th™ng số đầu ra, OrderConfirmed. OrderInitial vˆ OrderConfirmed được đ‡nh dấu với prop- woIn vˆ prop-woOut. woIn vˆ woOut nghĩa lˆ chœng đi vˆo vˆ đi ra khỏi hệ thống
GeneralRessort lần lượt từ CustomerCompany.
Tương tự, mỗi dịch vụ cũng c— một sự kiện (trong trường hợp nˆy event-woIn)
li•n quan đến n—, thể hiện những thực thể k’ch hoạt dịch vụ. Trong bước nˆy, kh™ng c— ai t‡c động vˆo hệ thống từ b•n ngoˆi, do đ— chỉ c— những sự kiện b•n trong toˆn bộ hệ thống GeneralRessort được thể hiện.
Đơn vị chức năng c— thể được kết nối với những đường thẳng chứa v˜ng tr˜n vˆ c— thể được chứa t•n của dữ liệu chœng chia sẽ, chẳng hạn như Customer, nghĩa lˆ fu find vˆ create chia sẻ một dữ liệu kiểu Customer.
Thiết kế dịch vụ thương mại kết hợp (Joint Business Service Design)
Trong lớp m™ h“nh kế tiếp nˆy, cấu trœc b•n trong của hệ thống sẽ được tiết lộ vˆ những dịch vụ thương mại kết hợp sẽ được định nghĩa bằng c‡ch cung cấp chi tiết về tr‡ch nhiệm dữ liệu c— li•n quan đến dịch vụ của những vai tr˜ b•n trong c™ng ty. V“ vậy, lớp nˆy tương ứng với hệ thống ở mức bao gộp, hˆnh động ở mức tổng qu‡t.
Người thiết kế sẽ định nghĩa những vai tr˜ (role) b•n trong hệ thống vˆ ph‰n phối dữ liệu c— li•n quan đến dịch vụ tới những vai tr˜ nˆy, tương ứng với nhiệm vụ của chœng. Xem h“nh 13 để thấy được ma trận nˆy.
Người thiết kế sẽ định nghĩa t•n hai vai tr˜: OrderEntryPerson vˆ ERP, được t™ mˆu xanh trong ma trận vˆ trong sơ đồ kế tiếp.
Sau đ— tất cả dữ liệu (data) từ lớp m™ h“nh trong h“nh12, được thể hiện lˆ những d˜ng trong ma trận được ph‰n phối tới những vai tr˜ (role) mới được định nghĩa.
(a)Định nghĩa vai tr˜ trong hệ thống
(b)Tr‡ch nhiệm dữ liệu của từng vai tr˜ H“nh 13 Ð Quyết định thiết kế cho bước 1
H“nh 14 Ð Thiết kế dịch vụ thương mại kết hợp
Như chœng ta c— thể thấy, qu‡ tr“nh thiết kế dịch vụ thương mại kết hợp chứa những dịch vụ thương mại mˆ kh™ng thay đổi những đơn vị chức năng (functional units). Tuy nhi•n, những thuộc t’nh li•n quan đến dịch vụ, cũng như những dữ liệu đầu vˆo, đầu ra được ph‰n phối tới những vai tr˜ mới được định nghĩa. Chœ ý rằng, mới chỉ c— một dịch vụ (OrderProcessing) được định nghĩa giữa nhiều vai tr˜ n•n ta vẫn chưa biết được vai tr˜ nˆo chịu tr‡ch nhiệm cho phần nˆo của dịch vụ.
Thiết kế dịch vụ IT kết hợp (Joint IT Service Design)
Lớp m™ h“nh kế tiếp định nghĩa vai tr˜ nˆo thực hiện phần nˆo trong hệ thống. Điều nˆy cho phŽp ta c— c‡i nh“n s‰u hơn vˆo những phần chức năng của hệ thống, mˆ kh™ng phải ph‰n r‹ hoˆn toˆn dịch vụ. V“ vậy lớp nˆy tương ứng với hệ thống ở mức bộ phần, hˆnh động lˆ mối quan hệ đa ng™i.
Người thiết kế định nghĩa những dịch vụ mới cho những vai tr˜ đ‹ được tạo mới ở bước tr•n vˆ ph‰n phối những đơn vị chức năng vˆo những dịch vụ nˆy.
Người thiết kế định nghĩa hai dịch vụ mới lˆ OrderEntryPerson vˆ ERP, t™ mˆu xanh dương trong ma trận ở h“nh 15 vˆ h“nh 16.
Dựa tr•n quyết định thiết kế, những đơn vị chức năng (functional unit) sẽ được ph‰n phối tự động tới những dịch vụ của vai tr˜ được đ‡nh với dấu ƠXÕ. Dựa tr•n những đường mũi t•n kết nối tới những đơn vị chức năng, những đơn vị chức năng sẽ được th•m vˆo c‡c vai tr˜ ở đ— điểm đầu vˆ cuối của đường thẳng sẽ lˆ enter vˆ get. enter được th•m vˆo nếu vai tr˜ đ— k’ch hoạt fu (đường thẳng đi từ vai tr˜ đ— đi ra), vˆ get khi vai
tr˜ đ— nhận kết quả từ fu (đường thẳng đi tới vai tr˜ đ—). Điều nˆy dựa tr•n mẫu Ơsend- respond-replyÕ được mi•u tả trong [25]. Tr•n đường thẳng kết nối những fu nˆy, t•n của dữ liệu được ghi l•n gồm: Name, CustomerPartId, OrderConfirmed.
Chœng ta đạt được kết quả sau khi đ‹ ra những quyết định thiết kế như h“nh 16. Như ta c— thể thấy, thiết kế hoạt động IT kết hợp chứa những dịch vụ cho mỗi vai tr˜ của c™ng ty, chứa một số hˆm chức năng c— sẵn vˆ một số mới được th•m vˆo. Thuộc t’nh vẫn giữ nguy•n kh™ng thay đổi trong bước nˆy. Chœ ý rằng kh™ng c— kết quả trung gian trong những dịch vụ, bởi v“ đ‰y lˆ hˆnh động c— mối quan hệ đa ng™i, tất cả c‡c dịch vụ nˆy biểu diễn chung cho một dịch vụ, chœng vẫn kh™ng hoˆn toˆn độc lập.
(a)Định nghĩa dịch vụ cho từng vai tr˜
(b)Tr‡ch nhiệm hˆnh vi của từng dịch vụ H“nh 15 Ð Ra quyết định cho thiết kế
H“nh 16 Ð Thiết kế dịch vụ IT kết hợp
Thiết kế dịch vụ IT nội bộ (Localized IT Service Design)
Trong bước nˆy, những dịch vụ con mới (vˆ những sự kiện của chœng) sẽ được định nghĩa, vˆ những hˆm đơn vị chức năng được ph‰n phối tới những dịch vụ nˆy. V“ vậy, lớp nˆy thể hiện hệ thống ở mức bộ phận, vˆ hˆnh động ở mức bộ phận.
Người thiết kế định nghĩa những dịch vụ con mới vˆ ph‰n phối c‡c hˆm chức năng tới những dịch vụ nˆy. Điều nˆy được lặp lại đối với mỗi vai tr˜. Những sự kiện cho những dịch vụ con mới sẽ ngầm được định nghĩa. Ngoˆi ra, người thiết kế c— thể x‡c định những sự kiện được chia sẻ giữa những vai tr˜ kh‡c nhau.
V’ dụ, người thiết kế định nghĩa những dịch vụ mới cho ERP: FindCustomer, FindPart vˆ CreateOrderConfirmed. Chœng được t™ mˆu đỏ trong ma trận như h“nh 17 vˆ tạo ra kết quả như h“nh 18. V“ vậy, người thiết kế ph‰n phối những hˆm chức năng đang tồn tại của ERP tới những dịch vụ con đ‹ được định nghĩa. Anh ta cũng c— thể lˆm tương tự đối với OrderEntryPerson, sẽ được định nghĩa với s‡u dịch vụ con. Cuối c•ng, anh sẽ sẽ x‡c định những sự kiện được chia sẻ, chẳng hạn dich vụ EnterName của OrderEntryPerson vˆ dịch vụ FindCustomer của ERP, thể hiện sự truyền đi từ vai tr˜ nˆy
đến vai tr˜ kh‡c.
Dựa tr•n những quyết định thiết kế, những dịch vụ mới sẽ được tạo ra b•n trong những dịch vụ đang tồn tại vˆ đang chứa những đơn vị chức năng (functional unit). Ngoˆi
những vai tr˜ sẽ được thay thế bởi những thuộc t’nh tương ứng trong chœng, chẳng hạn
prop-woOutName vˆ prop-woIn Name. Cũng như vậy, tương tự c‡ch ta lˆm đối với c‡c
dịch vụ con, ta cũng c— thể th•m những dữ liệu trung gian (chẳng hạn Customer) vˆ
những hˆm fu (chẳng hạn get) tương ứng. Những hˆm fu nˆy cũng được th•m vˆo ma trận ph‰n phối của người thiết kế. Cuối c•ng, một dịch vụ con IT mặc định được th•m vˆo (CreateOrderProcessing), chịu tr‡ch nhiệm cho qu‡ tr“nh khởi tạo cơ bản của những dịch vụ trong hệ thống IT.
Tất cả dữ liệu cần thiết cho dịch vụ ERP giờ đ‹ xuất hiện trong hệ thống ERP, bởi v“ những dịch vụ của tất cả c‡c vai tr˜ hiện tại đ‹ được ph‰n chia vˆ hệ thống của chœng đ‹ chứa tất cả dữ liệu cần thiết cho những dịch vụ của chœng. V“ vậy, nếu chœng ta c— thể biểu diễn toˆn bộ những vai tr˜ kh‡c trong m™ h“nh, chœng ta sẽ c— thể nh“n thấy tất cả mọi thứ cần thiết cho một vai tr˜.
M™ h“nh nˆy chứa những dịch vụ IT độc lập với nền tảng vˆ sẵn sˆng được thực thi tr•n bất cứ ng™n ngữ nˆo. Ngoˆi ra, n— cũng chứa những dịch vụ của con người vˆ những tương t‡c giữa người vˆ người, điều nˆy rất quan trọng khi thực hiện những dự ‡n tư vấn cho kh‡ch hˆng.
(a)Định nghĩa của dịch vụ IT
(b)Hỗ trợ dịch vụ thương mại H“nh 17- Bước 3 Ð Quyết định thiết kế
5 Giả lập vˆ sinh m‹ từ m™ h“nh
Một trong những th‡ch thức ch’nh trong việc thiết kế dịch vụ lˆ giải quyết c‰u hỏi lˆm sao để tạo ra nhanh ch—ng một bản thử mẫu của dịch vụ (tạo, ph‡t triển, kiểm tra vˆ đ‡nh gi‡ ý tưởng) th™ng qua qu‡ tr“nh thiết kế [15]. Trong phần nˆy, chœng ta sẽ giải th’ch một c‡ch ngắn gọn lˆm sao để giả lập vˆ tạo ra c‡c bản mẫu thử nghiệm đối với phương ph‡p được đề xuất.
Phương ph‡p giả lập những lớp của m™ h“nh cho phŽp người thiết kế giả lập hˆnh vi của những lớp m™ h“nh vˆ t“m thấy những lỗi thiết kế ở giai đoạn sớm nhất. Ngoˆi ra m™ h“nh cuối c•ng (H“nh 18) c— thể được thực thi tr•n nền tảng đ’ch, cũng lˆ một c‡ch để kiểm tra m™ h“nh.
5.1 Giả lập dịch vụ
Để giả lập dịch vụ, chœng ta d•ng Alloy [1]. Đầu ti•n chœng ta h“nh thức h—a m™ h“nh trong Alloy vˆ sau đ— chœng ta chạy vˆ giả lập chœng bằng c‡ch sử dụng Alloy Analyzer Tool. Chœng ta d•ng Alloy, bởi v“ n— c— thể được d•ng để kiểm tra sự tinh chế giữa những lớp m™ h“nh kh‡c nhau, đ‹ được giải th’ch ở [26].
Những m™ h“nh của chœng ta sẽ được chuyển đổi thˆnh meta-model của Alloy. Khi đ— một c™ng cụ (đang được ph‡t triển) sẽ nhận meta-model của m™ h“nh chœng ta, meta-model của Alloy vˆ c‡c đơn vị chức năng như lˆ dữ liệu đầu vˆo. Dựa tr•n những dữ liệu đầu vˆo nˆy, Alloy Analyzer sẽ sinh ra m‹ Alloy, c— thể chạy vˆ ph‰n t’ch trong SEAMCad, bởi v“ Alloy Analyzer đang được t’ch hợp trong SEAMCad th™ng qua Alloy Analyzer API (Application Programming Interface). Dưới đ‰y ra kết quả của m™ h“nh cuối c•ng (Localized IT Service Design) sau khi đ‹ chạy qua Alloy Analyzer, ta c— được một thực thể như h“nh 19.
Như minh họa, customer vˆ part được tạo ra trong trường hợp chœng kh™ng tồn tại trong tập hợp. Company_pre vˆ Company_post lˆ trạng th‡i của c™ng ty
General Ressort, trước vˆ sau khi đơn hˆng được thực thi. Như ta thấy, chœng c•ng c— OrderInitial lˆ dữ liệu đầu vˆo cho dịch vụ vˆ OrderConfirmed lˆ đầu ra cho dịch vụ. Trước khi đơn hˆng thực th“, kh™ng c— kh‡ch hˆng với t•n Name
trong OrderInital, v“ vậy một kh‡ch hˆng mới Customer với t•n nˆy được tạo ra trong customerSet, vˆ v“ vậy n— cũng ở trong Company_post. Ngoˆi ra
OrderConfirmed chứa th™ng tin về kh‡ch hˆng vˆ trở thˆnh thˆnh vi•n của OrderSet.
H“nh 19: Một thực thể được sinh ra bởi Alloy
5.2. Sinh m‹
C™ng cụ sinh m‹ của chœng ta dựa tr•n c™ng cụ BUD [19]. N— sẽ lấy m™ h“nh cuối c•ng (H“nh 18) lˆm dữ liệu đầu vˆo vˆ chuyển đổi n— thˆnh bản thử c— thể thực thi được. N— lˆm việc theo hai bước:
Sinh ra tập tin ng™n ngữ độc lập lˆm trung gian (JSON [19])
Sinh ra ứng dụng c— thể thực thi được cho ng™n ngữ lập tr“nh đ’ch.
Chœng ta sẽ giải th’ch những bước nˆy tr•n v’ dụ xử lý đơn đặt hˆng (GeneralRessorts). Ứng dụng nˆy được sinh ra dưới dạng ứng dụng JavaEE. Đầu vˆo của c™ng cụ sinh m‹ được thấy như h“nh 20.
! ! !
H“nh 20 Ð Bộ sinh m‹ trong SEAM
M™ h“nh SEAM cuối c•ngchỉ cho thấy một hˆnh động xảy ra do nhiều t‡c nh‰n t‡c động lˆ orderProcessing, với những hˆnh động con của n—. Trong hệ thống thật, chœng ta sẽ c— nhiều hˆnh động kết hợp như thế xảy ra c•ng một lœc (vˆi kh‡ch hˆng đặt hˆng những bộ phận song song). V“ lý do nˆy, chœng ta th•m một bảng chứa những định nghĩa trong m™ h“nh vˆo cơ sở dữ liệu của chœng ta: một bảng Task tập hợp tất cả những th™ng tin cần thiết cho một hˆnh động kết hợp. Với c‡ch nˆy, nếu c— hai đơn đặt hˆng đang chờ được xử lý, một người sẽ được giao vai tr˜ c— thể lựa chọn hˆnh động kết hợp nˆo (joint action) mˆ c™ ấy muốn xử lý.
Trong c™ng cụ sinh m‹ của SEAM, tập tin mẫu JSON (JSON Template) [17] được sử dụng, ng™n ngữ mẫu nˆy tuy nhỏ nhưng rất mạnh, c— thể d•ngcho cả Python vˆ JavaScript. Mẫu JSON cho phŽp chœng ta định nghĩa cấu trœc chương tr“nh sử dụng mẫu cho bất kỳ ng™n ngữ nˆo vˆ từ điển dữ liệu. Từ điển dữ liệu quyết định phần nˆo trong tập tin mẫu (template) n•n được thay thế bởi th™ng tin g“, chi tiết về c‡ch d•ng JSON Template được m™ tả trong [17].
Trong bước đầu ti•n, c™ng cụ sinh m‹ chuyển đổi m™ h“nh cuối c•ng của SEAM thˆnh từ điển dữ liệu. Đối với tập tin nˆy chœng ta sử dụng JSON (Java Script Object Notation), một định dạng trao đổi dữ liệu gọn nhẹ, dựa tr•n một tập con của ng™n ngữ lập tr“nh JavaScript, dễ dˆng cho con người đọc vˆ viết, dễ dˆng
SEAM Model in JSON (enriched with Alloy code)
SEAMCad with SEAM models J2EE/ASP.NET JSON Templates Data dictionary (JS file)
cho m‡y m—c ph‰n t’ch vˆ tạo ra. Một phần của từ điển dữ liệu chœng ta lấy được từ v’ dụ xử lý đơn hˆng được thấy như h“nh 21. N— cho thấy th™ng tin về kh‡ch hˆng phải được chuyển đổi thˆnh Customer JPA.
(a) (b)
H“nh 21: Từ điển dữ liệu (tập tin JS) (a). Từ điển dữ liệu cho lớp Customer
(b). Từ điển dữ liệu cho hˆnh động t“m kiếm kh‡c hang.
Ở bước thứ hai, tập tin mẫu vˆ từ điển dữ liệu (tập tin JS) được kết hợp vˆ ph‰n t’ch sử dụng JavaCC, vˆ những tập tin tương ứng được tạo thˆnh. Một v’ dụ của tập tin mẫu mˆ tạo ra JPA (Java Persistence API) được thể hiện như h“nh 22.
Chœ ý đ‰y chỉ lˆ một bản rœt gọn của tập tin hoˆn chỉnh cho case study đ‹ được đề cập ở những phần tr•n (GR Case Study). Sử dụng từ điển dữ liệu trong h“nh 21 vˆ tập tin mẫu như h“nh 22, ta thu được tập tin như h“nh 23.
H“nh 22: Tập tin mẫu JPA
H“nh 23: Customer JPA
V’ dụ tr•n chỉ thể hiện phần tĩnh của hệ thống dịch vụ. Tương tự như Alloy, phần động của m™ h“nh sẽ chứa những c‡ch thức lˆm việc (logic) của dịch vụ vˆ
sự tương t‡c giữa c‡c dịch vụ với nhau. V’ dụ của một template về c‡ch thức lˆm việc của một dịch vụ (phần động) được thể hiện ở h“nh 10.
6 Kết luận
6.1 C‡c kết quả đ‹ đạt được
M™i trường được đề xuất cho thiết kế dịch vụ, giả lập vˆ sinh ra bản mẫu (prototype) dựa tr•n MDA (model driven architecture) [13]: n— đề xuất một tập c‡c m™ h“nh mở rộng từ CIM (computation-independent model), mức đồ trừu tượng cao nhất của MDA, tới PIM (platform-independent model) vˆ PSM (platform-specific model). Dịch vụ thương mại (business service) vˆ dịch vụ thương mại kết hợp (joint business service) tương ứng với mức độ CIM, bởi v“ chœng thể hiện ngữ cảnh vˆ mục đ’ch của m™ h“nh. Dịch vụ IT kết hợp (Joint IT service) vˆ dịch vụ IT nội bộ (localized IT service) tương ứng với PIM. N— thể hiện những bộ phận được hoˆn thˆnh bởi ứng dụng phần mềm vˆ thể hiện hˆnh vi cũng như cấu trœc bất chấp nền tảng được thực thi. Trong phần giả lập dịch vụ, những dự ‡n trung gian chứa c‡c tập tin mẫu (template) vˆ đặc tả của đối tượng