Nghiên cứu, phát triển và ứng dụng kiến trúc hướng mô hình trong công nghệ phần mềm
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.11 MB, 105 trang )
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
----------------
LÂM THỊ THÚY HOA
NGHIÊN CỨU, PHÁT TRIỂN VÀ ỨNG DỤNG
KIẾN TRÚC HƯỚNG MÔ HÌNH TRONG
CÔNG NGHỆ PHẦN MỀM
LUẬN VĂN THẠC SĨ
Hà Nội – 2009
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
----------------
LÂM THỊ THÚY HOA
NGHIÊN CỨU, PHÁT TRIỂN VÀ ỨNG DỤNG
KIẾN TRÚC HƯỚNG MÔ HÌNH TRONG
CÔNG NGHỆ PHẦN MỀM
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Ô VĂN HIỀN
Hà Nội – 2009
MỤC LỤC
Trang
Chƣơng 1 - CÁC NGUYÊN TẮC MÔ HÌNH HÓA TRỰC QUAN VÀ CÁC
ĐẶC TRƢNG TRONG CÔNG NGHỆ HƢỚNG ĐỐI TƢỢNG
2
1.1. Các nguyên tắc mô hình hóa trực quan
2
1.2. Các đặc trƣng trong công nghệ hƣớng đối tƣợng
3
Chƣơng 2 - TỔNG QUAN VỀ KIẾN TRÚC HƢỚNG MÔ HÌNH (MDA –
MODEL DRIVEN ARCHITECTURE)
5
2.1. Tổng quan về MDA
5
2.2. Các mô hình trong MDA
6
2.2.1. Mô hình độc lập với thao tác tính toán (CIM)
6
2.2.2. Mô hình độc lập với nền công nghệ (PIM)
7
2.2.3. Mô hình theo nền công nghệ cụ thể (PSM)
8
2.3. Sƣ̣ chuyển đổi mô hình trong MDA
9
2.3.1. Chuyển đổi từ CIM sang PIM
10
2.3.2. Chuyển đổi từ PIM sang PSM
12
2.3.3. Chuyển đổi mô hình trong một hệ thống phức tạp
16
Chƣơng 3 - PHƢƠNG PHÁP PHÂN TÍCH VÀ THIẾT KẾ HƢỚNG ĐỐI
TƢỢNG PHẦN MỀM ỨNG DỤNG THEO KIẾN TRÚC HƢỚNG MÔ
HÌNH
3.1. Phân tích kiến trúc hệ thống
17
17
3.1.1. Xác định các tầng kiến trúc của hệ thống
18
3.1.2. Xác định các cơ chế kiến trúc
19
3.1.3. Sự tham chiế u các tầng kiến trúc với MDA
22
3.2. Xác định nội dung của mô hình CIM
22
3.2.1. Xác định các trừu tƣợng hóa chính
22
3.2.2. Xác định các tác nhân và các trƣờng hợp sử dụng
23
3.2.3. Biều diễn mối quan hệ giữa tác nhân và trƣờng hợp sử dụng
26
3.2.4. Bổ sung mô tả cho trƣờng hợp sử dụng
28
3.3. Chuyển đổi mô hình CIM sang mô hình PIM
29
3.3.1. Chuyển đổi các thành phần của mô hình CIM thành các phần tử
phân tích trong mô hình PIM
29
3.3.2. Chuyển đổi các phần tử phân tích thành các phần tử thiết kế trong
mô hình PIM
3.4. Chuyển đổi mô hình PIM sang mô hình PSM
38
46
3.4.1. Lƣ̣a cho ̣n nề n công nghê ̣ thực thi hệ thống
46
3.4.2. Các luâ ̣t chuyể n đổ i phần tử thiết kế trong PIM sang PSM
48
3.4.3. Thiết kế chi tiế t các trƣờng hợp sử dụng
49
3.4.4. Thiết kế lớp chi tiết
53
3.5. Thiế t kế mô hình dữ liệu
54
Chƣơng 4 - ÁP DỤNG PHƢƠNG PHÁP PHÂN TÍCH THIẾT KẾ HƢỚNG
ĐỐI TƢỢNG THEO KIẾN TRÚC HƢỚNG MÔ HÌNH VÀO VIỆC PHÁT
TRIỂN HỆ THỐNG QUẢN LÝ TÍN DỤNG TRONG NGÂN HÀNG
57
4.1. Tìm hiểu nghiệp vụ hệ thống
57
4.2. Giới thiệu tổng quan hệ thống Quản lý tín dụng trong ngân hàng
60
4.3. Phân tích thiết kế chi tiết một trƣờng hợp sử dụng Quản lý Hợp đồng
vay 67
Chƣơng 5 - SO SÁNH VÀ ĐÁNH GIÁ MDA VỚI CÁC PHƢƠNG PHÁP
KHÁC
70
5.1. So sánh MDA với OO – Method
70
5.2. So sánh MDA với SOA
72
KẾT LUẬN VÀ KIẾN NGHỊ
75
DANH MỤC TÀI LIỆU THAM KHẢO
77
PHỤ LỤC
78
DANH MỤC CÁC CHỮ VIẾT TẮT
Ký hiệu
Viết đầy đủ
viết tắt
Ý nghĩa
Business System
Hệ thống con nghiệp vụ
Computation Independent
Mô hình độc lập với thao tác
Model
tính toán
CNTT
Công nghệ thông tin
Công nghệ thông tin
CSDL
Cơ sở dữ liệu
Cơ sở dữ liệu
DAO
Data Access Object
Đối tượng truy xuất dữ liệu
GDTD
Giao dịch tín dụng
Nhân viên giao dịch tín dụng
BUS
CIM
J2EE
Java 2 Platform, Enterprise
Edition
MDA
Model Driven Architecture
Kiến trúc hướng mô hình
MOF
Meta Object Facility
Khả năng siêu hướng đối tượng
OMG
Object Management Group
Tổ chức quản trị đối tượng
Object-Oriented Database
Hệ quản trị cơ sở dữ liệu hướng
Management System
đối tượng
PIM
Platform Independent Model
Mô hình độc lập với nền công
nghệ
PSM
Platform Specific Model
QLTD
Quản lý tín dụng
Quản lý tín dụng
RDBMS
Relational Database
Management System
Hệ quản trị cơ sở dữ liệu quan
hệ
UML
Unified Modeling Language
Ngôn ngữ mô hình hoá hợp nhất
OODBMS
VOPC
View Of Participating
Classes
Mô hình theo nền công nghệ cụ
thể
Tổng quan về các lớp tham gia
DANH MỤC CÁC HÌNH VẼ
Trang
Hình 1.1. Tổng quan các đặc trưng trong công nghệ hướng đối tượng
3
Hình 2.1. Sự phân loại các mô hình chính trong MDA
5
Hình 2.2. Ví dụ một quá trình phát triển phần mềm theo MDA
6
Hình 2.3. Ví dụ về CIM
7
Hình 2.4. Ví dụ về PIM - dựa theo hình 2.3
8
Hình 2.5. Ví dụ về PSM - dựa theo hình 2.4 với công nghệ .NET
9
Hình 2.6. Mô hình chuyển từ CIM sang PIM
10
Hình 2.7. Mô hình tình huống
11
Hình 2.8. Đánh dấu mô hình
12
Hình 2.9. Quá trình biến đổi Metalmodel.
12
Hình 2.10. Quá trình biến đổi mô hình
13
Hình 2.11. Ứng dụng mẫu
14
Hình 2.12. Một cách khác để sử dụng các mẫu
14
Hình 2.13. Mô hình kết hợp
15
Hình 2.14. Bổ sung thông tin để chuyển sang PSM
15
Hình 2.15. Sử dụng thông tin bổ sung trong kỹ thuật biến đổi cụ thể
16
Hình 2.16. Ví dụ về quy trình MDA cho một hệ thống phức tạp
16
Hình 3.1. Các tầng kiến trúc hệ thống
18
Hình 3.2. Ví dụ về một kết quả xác định các tầng kiến trúc
19
Hình 3.3. Ví dụ về mối liên hệ giữa các cơ chế kiến trúc
21
Hình 3.4. Ví dụ về các trừu tượng hóa chính
23
Hình 3.5. Ví dụ một tác nhân “Người quản lý hợp đồng vay”
23
Hình 3.6. Ví dụ một trường hợp sử dụng “Quản lý Hợp đồng vay”
24
Hình 3.7. Ví dụ về quan hệ “sử dụng” giữa các trường hợp sử dụng
25
Hình 3.8. Ví dụ về quan hệ “tổng quan hóa” giữa các trường hợp sử du ̣ng
25
Hình 3.9. Ví dụ về quan hệ “mở rộng” giữa các trường hợp sử dụng
26
Hình 3.10. Ví dụ một b iểu đồ diễn tiến thể hiê ̣n sự tương tác giữa tác nhân và
trường hơ ̣p sử du ̣ng trong chức năng “Ta ̣o mới mô ̣t Hợp đồng vay”
27
Hình 3.11. Ví dụ một biểu đồ hoạt động thể hiện dòng sự kiện rẽ nhánh
28
Hình 3.12. Ví dụ về việc bổ sung thông tin cho trường hợp sử dụng
29
Hình 3.13. Tổng quan về các lớp phân tích
30
Hình 3.14. Ví dụ một lớp biên “HopDongVayForm”
31
Hình 3.15. Ví dụ một lớp điều khiển “HopDongVayControl”
32
Hình 3.16. Ví dụ một lớp thực thể “HopDongVay”
33
Hình 3.17. Ví dụ việc mô tả thuộc tính của lớp thực thể “HopDongVay”
34
Hình 3.18. Ví dụ mô ̣t mối quan hệ “liên kết” giữa hai lớp “DMKhachHang” và
HopDongVay”
35
Hình 3.19. Ví dụ một biểu đồ diễn tiến thể hiê ̣n mố i quan hê ̣ giữa các lớp phân
tích trong chức năng “Tạo mới một Hợp đồng vay”
36
Hình 3.20. Biểu đồ tổng quan các lớp phân tích tham gia trường hợp sử dụng
“Quản lý Hợp đồng vay”
37
Hình 3.21. Ví dụ sự chuyển đổi các lớp phân tích thành các lớp thiết kế
39
Hình 3.22. Ví dụ về các thành phần của một hệ thống con “Hê ̣ thố ng Quản lý
hợp đồng”
42
Hình 3.23. Ví dụ một b iểu đồ diễn tiến thể hiê ̣n mố i quan hê ̣ giữa các lớp thiết
kế trong chức năng “Tạo mới một Hợp đồng vay”
45
Hình 3.24. Ví dụ sự phân phối các cơ chế kiến trúc cho các lớp thiết kế
45
Hình 3.25. Biểu đồ tổng quan các lớp thiết kế tham gia trường hợp sử dụng
“Quản lý Hợp đồng vay”
46
Hình 3.26. Tổng quan các thành phần của nền công nghệ .NET
47
Hình 3.27. Mô hình kiến trúc thiết kế ứng dụng với .NET
48
Hình 3.28. Ví dụ một hệ thống con UI của trường hợp sử dụng “Quản lý Hợp
đồng vay”
49
Hình 3.29. Ví dụ một hệ thống con BUS của trường hợp sử dụng “Quản lý
Hợp đồng vay”
50
Hình 3.30. Ví dụ một hệ thống con DAO của trường hợp sử dụng “Quản lý
Hợp đồng vay”
51
Hình 3.31. Biểu đồ diễn tiến thể hiê ̣n mố i quan hê ̣ giữa các hệ thống con thiết
kế trong chức năng “Tạo mới một Hợp đồng vay”
52
Hình 3.32. Biểu đồ tổng quan về các gói hệ thống con thiết kế tham gia trường
hợp sử dụng “Quản lý Hợp đồng vay”
53
Hình 3.33. Ví dụ về việc chuyển đổi một lớp thực thể thiết kế thành một mô
hình bảng dữ liệu trong mô hình dữ liệu
55
Hình 3.34. Ví dụ một sự ánh xạ quan hệ giữa các lớp thực thể thiết kế thành
quan hệ giữa các bảng trong mô hình dữ liệu
56
Hình 4.1. Các tác nhân chính tham gia hệ thống “Quản lý tín dụng”
61
Hình 4.2. Biểu đồ tổng quan các gói nghiệp vụ của hệ thống “Quản lý tín
dụng”
62
Hình 4.3. Gói các trường hợp sử dụng “Quản lý Hợp đồng vay”.
63
Hình 4.4. Gói các trường hợp sử dụng “Quản lý Tài sản bảo đảm”.
63
Hình 4.5. Gói các trường hợp sử dụng “Quản lý thu nợ”
64
Hình 4.6. Gói các trường hợp sử dụng “Quản lý báo cáo”
65
Hình 4.7. Gói các trường hợp sử dụng “Quản lý danh mục”
66
Hình 4.8. Gói các trường hợp sử dụng “Quản lý hệ thống”
66
1
MỞ ĐẦU
Trong kỷ nguyên công nghệ và nền kinh tế đa chiều, phần mềm đã và đang
đóng một vai trò vô cùng quan trọng trong việc định hướng phát triển cho mọi
doanh nghiệp và góp phần gia tăng giá trị cạnh tranh trong cộng đồng. Đối với
chính phủ, phần mềm là một trong những yếu tố cơ bản trong viêc xây dựng nền
tảng phát triển kinh tế của quốc gia và cải thiện các chính sách nhằm nâng cao chất
lượng cuộc sống của người dân.
Phương pháp tiếp cận Kiến trúc hướng theo mô hình (MDA: Model-Driven
Architecture) do tổ chức OMG (Object Management Group) phát triển là một cách
tiếp cận dùng các mô hình để phát triển phần mềm ứng dụng. Ba mục tiêu cơ bản
của MDA là khả năng di động, tính xuyên chức năng và sự sử dụng lại thông qua
việc tách rời các mối liên quan, ví dụ như là: mô hình độc lập với thao tác tính toán,
(CIM - Computation Independent Model), mô hình độc lập với nền công nghệ
(PIM - Platform Independent Model), mô hình cụ thể của nền công nghệ (PSM Platform Specific Model), sự chuyển đổi mô hình và các mẫu của MDA v.v…
Luận văn này được thực hiện nhằm mu ̣c đić h nghiên cứu về kiến trúc hướng
mô hình, phương pháp tiếp cận theo kiến trúc hướng mô hình trong công nghiệp
phát triển phần mềm và minh họa việc áp dụng lý thuyết nghiên cứu vào việc phát
triển hệ thống thực tế.
Luận văn bao gồm 5 chương chính như sau:
Chương 1. Các nguyên tắc mô hình hoá trực quan và các đặc trưng trong
công nghệ hướng đối tượng.
Chương 2. Tổng quan về kiến trúc hướng mô hình (MDA – Model Driven
Architecture).
Chương 3. Phương pháp phân tích và thiết kế hướng đối tượng các phần
mềm ứng dụng theo kiến trúc hướng mô hình.
Chương 4. Áp dụng phương pháp phân tích thiết kế hướng đối tượng theo
kiến trúc hướng mô hình vào việc phát triển hệ thống “Quản lý tín dụng trong ngân
hàng”.
Chương 5. So sánh MDA với các phương pháp khác
2
Chƣơng 1 - CÁC NGUYÊN TẮC MÔ HÌNH HÓA TRỰC QUAN VÀ
CÁC ĐẶC TRƢNG TRONG CÔNG NGHỆ HƢỚNG ĐỐI TƢỢNG
1.1. Các nguyên tắc mô hình hóa trực quan
Mô hình hoá trực quan là việc sử dụng các ngôn ngữ thiết kế có tính chất đồ
hoạ và các mô tả ngắn gọn để thể hiện các bản thiết kế phần mềm, ví dụ: ngôn ngữ
mô hình hoá hợp nhất UML. Mô hình hóa trực quan cho phép trừu tượng hoá các hệ
thống ở mức cao hơn, trong khi đó vẫn duy trì được ngữ nghĩa và cấu trúc căn bản
của hệ thống, giúp cho người đọc bản thiết kế dễ nắm bắt cấu trúc tĩnh và ứng xử
động của hệ thống. Mô hình hoá trực quan có bốn nguyên tắc cơ bản như sau:
Nguyên tắc 1: Các mô hình được tạo ra chi phối sâu sắc đến cách tiếp cận
và định hướng giải quyết một vấn đề.
Trong phát triển phần mềm, việc chọn các mô hình có thể ảnh hưởng rất lớn
đến thế giới quan của người làm phần mềm. Mỗi thế giới quan sẽ dẫn tới một loại
mô hình khác nhau với chi phí và lợi ích khác nhau. Nếu xây dựng hệ thống theo
con mắt của người thiết kế CSDL, kết quả nhận được sẽ là mô hình quan hệ thực
thể nêu ra cách xử lý trong các thủ tục lưu trữ và các trigger. Nếu xây dựng hệ
thống thông qua con mắt của người phân tích thiết kế hướng đối tượng, kết quả đầu
ra sẽ là một hệ thống có kiến trúc xoay quanh nhiều lớp và mẫu tương tác với nhau,
điều khiển các lớp đó làm việc với nhau.
Các mô hình đúng sẽ làm sáng tỏ những bài toán phát triển phần mềm phức
tạp, giúp cho người phát triển hệ thống không bị sa lầy vào những vấn đề không cần
thiết. Một mô hình sai sẽ làm cho người phát triển dễ bị lạc hướng vì tập trung vào
những vấn đề không liên quan.
Nguyên tắc 2: Mỗi mô hình được thể hiện ở mức độ chi tiết khác nhau.
Mỗi mô hình được chọn ở các mức chi tiết khác nhau tùy thuộc vào việc ai là
người sử dụng mô hình và tại sao cần sử dụng mô hình.
Ví dụ: Người sử dụng sử dụng khung nhìn trường hợp sử dụng (Use Case
View) để biết hệ thống có đáp ứng được yêu cầu nghiệp vụ của họ không, người
phân tích thiết kế sử dụng khung nhìn logic (Logical View) trong quá trình phân
tích thiết kế hệ thống, người triển khai sử dụng khung nhìn triển khai (Deployment
View) để chuẩn bị môi trường cho việc triển khai v.v..
Nguyên tắc 3: Các mô hình tốt nhất là các mô hình được liên hệ trong
thực tế.
3
Tất cả các mô hình đều là sự đơn giản hoá của thực tế. Một mô hình tốt sẽ
phản ánh đầy đủ những đặc trưng không thể thiếu về năng lực hệ thống và không
che lấp đi bất kỳ một chi tiết quan trọng nào. Mô hình vật lý của một hệ thống cũng
có thể không được đáp ứng trên thực tế do bị hạn chế về nguồn tài nguyên và kinh
phí. Vì vậy, mỗi mô hình khi xây dựng cần được xem xét và đặt trong thực tế.
Nguyên tắc 4: Không có một mô hình đơn lẻ nào là đầy đủ. Một hệ thống
tốt nhất phải được tiếp cận thông qua một tập các mô hình độc lập tương đối với
nhau.
“Độc lập tương đối” có nghĩa là các mô hình có thể được xây dựng và xem
xét độc lập nhau, nhưng chúng vẫn phải có mối quan hệ tương quan với nhau.
Ví dụ: Để hiểu cấu trúc của một hệ thống hướng đối tượng, những người
phát triển phần mềm cần kết hợp xem xét trên một số khung nhìn: khung nhìn
trường hợp sử dụng (Use Case View), khung nhìn logic (Logical View), khung nhìn
xử lý (Process View), khung nhìn thực thi (Implementation View), khung nhìn triển
khai (Deployment View). Mỗi khung nhìn được xây dựng từ những góc nhìn khác
nhau để thể hiện cấu trúc và ứng xử của hệ thống. Chúng cùng nhau tạo nên một
bản thiết kế đầy đủ, chi tiết cho một hệ thống phần mềm.
1.2. Các đặc trƣng trong công nghệ hƣớng đối tƣợng
Công nghệ hướng đối tượng là một tập các nguyên tắc hướng dẫn xây dựng
phần mềm với các ngôn ngữ, các cơ sở dữ liệu và các công cụ hỗ trợ cho các
nguyên tắc đó. Có bốn đặc trưng cơ bản trong công nghệ hướng đối tượng như sau:
Hình 1.1. Tổng quan các đặc trưng trong công nghệ hướng đối tượng
Đặc trƣng 1: Tính trừu tƣợng hoá (Abstraction)
Tính trừu tượng hoá cho phép người phát triển phần mềm giải quyết những
bài toán phức tạp bằng cách bỏ qua hay không chú ý đến một số khía cạnh chi tiết
4
của thông tin để tập trung vào các đặc trưng cốt yếu của một thực thể, các đặc trưng
làm thực thể đó nổi bật so với tất cả các thực thể khác. Trừu tượng hoá phụ thuộc
vào phạm vi và ngữ cảnh, những gì quan trọng trong ngữ cảnh này có thể không
quan trọng trong một ngữ cảnh khác.
Đặc trƣng 2: Tính đóng gói (Encapsulation)
Tính đóng gói cho phép ẩn dấu phần thực thi của các tính năng (các thuộc
tính và các ứng xử) theo cơ chế hộp đen, thông qua giao diện dùng chung.
Tính chất này không cho phép người sử dụng hoặc hệ thống tương tác tới các
đối tượng thay đổi trạng thái nội tại của một đối tượng, chỉ có các phương thức nội
tại của đối tượng mới được phép thay đổi trạng thái của nó. Người sử dụng hoặc hệ
thống tương tác có thể sử dụng các thao tác, các thuộc tính mà không cần biết bên
trong đối tượng được thực thi như thế nào. Việc cho phép môi trường bên ngoài tác
động lên các dữ liệu nội tại của một đối tượng theo cách nào là hoàn toàn tùy thuộc
vào người thực thi code. Nếu phần giao diện của tính năng đó không bị thay đổi,
người thực thi có thể thay đổi phần code mà không cần thông tin lại cho người sử
dụng hoặc hệ thống tương tác bên ngoài.
Đặc trƣng 3: Tính mô đun hoá (Modularity)
Mô đun hoá là tính chất cho phép chia một mô đun lớn và phức tạp thành
một tập các mô đun con và đơn giản hơn để xử lý. Các bài toán này có thể được
phân tích, thiết kế, thực thi độc lập và sau đó được tích hợp với nhau thành một hệ
thống lớn thông qua các giao diện của các mô đun con, để xử lý toàn bộ vấn đề.
Mô đun hoá làm cho một hệ thống dễ dàng hơn trong việc thiết kế, thực thi,
bảo trì và nâng cấp sau này, cũng như thuận lợi hơn cho việc tái sử dụng. Các mô
đun của một hệ thống có thể được thực thi, gỡ bỏ, kích hoạt, vô hiệu hóa thông qua
hệ thống quản lý mô đun.
Đặc trƣng 4: Tính phân cấp (Hierarchy )
Cấu trúc chung của một hệ thống hướng đối tượng là sự phân cấp các thành
phần theo các mức độ trừu tượng hoá như phân cấp lớp, phân cấp thừa kế, phân cấp
đặc tả v.v.. Các thành phần ở cùng một mức phân cấp thì nên tổ chức trong cùng
mức trừu tượng hoá.
5
Chƣơng 2 - TỔNG QUAN VỀ KIẾN TRÚC HƢỚNG MÔ HÌNH (MDA
– MODEL DRIVEN ARCHITECTURE)
2.1. Tổng quan về MDA
Kiến trúc hướng mô hình (MDA) là một cách tiếp cận mô hình hoá trực quan
trong suốt quá trình tìm hiểu, phân tích, thiết kế, thực thi một hệ thống phần mềm.
MDA phân chia các mô hình đặc tả về hệ thống từ mức độ trừu tượng hóa cao cho
đến mức chi tiết và cung cấp các luật chuyển đổi cho phép chuyển đổi giữa các mô
hình.
Các mô hình chính của MDA bao gồm:
Mô hình độc lập với thao tác tính toán (CIM - Computation
Independent Model) thể hiện hệ thống ở mức nghiệp vụ.
Mô hình độc lập với nền công nghệ (PIM - Platform Independent
Model) đặc tả các chức năng hệ thống nhưng độc lập với các nền công
nghệ thực thi hệ thống.
Mô hình theo nền công nghệ cụ thể (PSM - Platform Specific Model)
đặc tả các chức năng hệ thống theo một nền công nghệ cụ thể được
lựa chọn để thực thi hệ thống;.
Hình 2.1 trình bày một cách tổng quan về sự phân loại các mô hình
chính của MDA theo trật tự từ mức độ trừu tượng hóa đến cụ thể hoá.
Hình 2.1. Sự phân loại các mô hình chính trong MDA
Ví dụ: Hình 2.2 trình bày ví dụ về một quá trình phát triển phần mềm theo kiến trúc
hướng mô hình.
6
Hình 2.2. Ví dụ một
2.2. Các mô hình trong MDA
2.2.1. Mô hình độc lập với thao tác tính toán (CIM)
Mô hình độc lập với thao tác tính toán (CIM – Computation Model Model)
là sự xem xét hệ thống từ góc độ độc lập với các thao tác tính toán. Mô hình CIM
tập trung vào sự đặc tả hệ thống bằng các thuật ngữ gần gũi với người làm nghiệp
vụ, và được xác định bởi sự kết hợp làm việc giữa người phân tích nghiệp vụ và
những người làm nghiệp vụ sẽ sử dụng hệ thống. Và chính vì vậy, mô hình CIM
còn được gọi là mô hình phạm vi hay mô hình nghiệp vụ.
Ví dụ: Hình 2.3 trình bày một ví dụ về mô hình CIM. Trong mô hình này
không có thông tin nào chỉ ra giải pháp dựa trên thao tác tính toán.
7
Hình 2.3. Ví dụ về CIM
2.2.2. Mô hình độc lập với nền công nghệ (PIM)
Mô hình độc lập với nền công nghệ (PIM – Platform Independent Model) tập
trung vào việc mô hình hoá các thao tác của hệ thống, nhưng ở góc độ độc lập với
các nền công nghệ cho phép thực thi các chức năng hệ thống, tức là chưa chỉ ra
những chi tiết cần thiết để thực thi các chức năng hệ thống trên một nền công nghệ
cụ thể. PIM biểu diễn phần đặc tả về hệ thống mà các đặc tả này không bị thay đổi
giữa nền công nghệ này với nền công nghệ khác. Các đặc tả này có thể được chuyển
thành các mô hình của hệ thống cụ thể theo những nền công nghệ khác nhau được
lựa chọn để thực thi hệ thống.
Ví dụ: Hình 2.4 trình bày một ví dụ về PIM xuất phát từ ví dụ về CIM được
mô tả trên hình 2.3. Mô hình này có bao gồm các ứng xử của hệ thống đã tiến gần
tới việc thực thi nhưng không gắn với một nền công nghệ nào cả.
8
Hình 2.4. Ví dụ về PIM - dựa theo hình 2.3
2.2.3. Mô hình theo nền công nghệ cụ thể (PSM)
Mô hình theo nền công nghệ cụ thể (PSM – Platform Specific Model) đặc tả
hệ thống bằng các thông tin được xác định trong PIM kết hợp với chi tiết các kiểu
của một nền công nghệ cụ thể được lựa chọn để thực thi hệ thống, ví dụ như: nền
công nghệ .NET, J2EE v…v.
Hình 2.5 chỉ ra ví dụ về PSM xuất phát từ ví dụ về PIM được mô tả trên hình
2.4. Trong mô hình này, PSM đã thể hiện các thông tin của PIM thông qua các thuật
ngữ và cấu trúc của một công nghệ cụ thể đó là .NET.
9
Hình 2.5. Ví dụ về PSM - dựa theo hình 2.4 với công nghệ .NET
2.3. Sƣ ̣ chuyển đổi mô hình trong MDA
Sự chuyển đổi mô hình trong MDA là việc sử dụng một cơ chế nào đó để
biến đổi các mô hình ở mức trừu tượng hoá cao thành các mô hình ở mức cụ thể và
chi tiết hơn dựa trên sự định nghĩa các luật chuyển đổi. Đó là sự chuyển từ CIM
sang PIM, từ PIM sang PSM, và từ PSM có thể chuyển thành mã chương trình cụ
thể thực thi hệ thống. Việc chuyển đổi giữa các mô hình có thể được thực hiện qua
thao tác bằng tay, chuyển đổi tự động dựa vào các mẫu chuyển đổi khác nhau tuỳ
thuộc vào những công cụ chuyển đổi và nền công nghệ đích, hoặc kết hợp cả hai
10
phương thức. Cho đến nay, các công cụ hỗ trợ việc chuyển đổi mô hình trong MDA
tập trung chủ yếu vào giai đoạn chuyển đổi từ PIM sang PSM, chỉ có một số ít
chuyển đổi từ CIM sáng PIM
2.3.1. Chuyển đổi từ CIM sang PIM
Mục đích của phần này chính là cách tiếp cận để chuyển đổi một CIM sang
một PIM trong MDA. Đầu tiên sử dụng sơ đồ hoạt động UML2.x để xử lý các tác
vụ của người sử dụng. Sơ đồ hoạt động này được chỉ rõ trong các yêu cầu hệ thống.
Các thành phần hệ thống được suy luận từ mô hình yêu cầu. Cuối cùng một bộ các
nguyên mẫu giúp các thành phần hệ thống tạo ra PIM.
Hình 2.6. Mô hình chuyển từ CIM sang PIM
Elementary Business Process (EBP)
Một thực thể nghiệp vụ (EBP) được định nghĩa như một nhiệm vụ được thực
hiện bởi một người, tại một địa điểm và trong một thời điểm, phục vụ một sự kiện
nào đó, làm tăng khả năng thêm hiệu quả có thể đo đếm được cho nghiệp vụ và lưu
lại dữ liệu ở trạng thái ổn định.
Xây dựng CIM
CIM được xây dựng trên mô hình sử dụng sơ đồ hoạt động UML2.x bằng
một kỹ thuật đơn giản:
Mô hình quy trình nghiệp vụ - Business Process Model (BPM)
- Chia nhỏ các quy trình thành các nhóm EBP liên quan đến luồng
công việc từ người này tới người khác
11
- Mô tả mỗi EBP bằng cả hai hành động (mặt hoạt động, biến đổi) và
các đối tượng cần thiết (mặt cố định)
Mô hình yêu cầu - Requirement Model
- Giới thiệu trong BPM hệ thống như người thực hiện những xử lý
mong muốn
- Xây dựng các mô hình tình huống (Use Case) dùng sơ đồ hoạt động
ULM2.x (mỗi EBP sử dụng một Use Case)
Hình 2.7. Mô hình tình huống
Xây dựng PIM
Từ mô hình Use Case, chúng ta xác định hai thành phần khác biệt là:
- Thành phần quy trình nghiệp vụ tương ứng với quy trình xử lý
- Thành phần thực thể nghiệp vụ tương ứng với các tài nguyên và sản phẩm
hay dịch vụ
- Mỗi Use Case thường được chuyển thành các thành phần quy trình rồi liên
kết với các thực thể tùy thuộc vào vai trò của các thực thể trong quy trình.
Thành phần quy trình là Moment-Interval Archetype.
Thành phần thực thể là PPT và/hoặc Mô tả và/hoặc vai trò nguyên mẫu
Archetypes.
PIM được hoàn thành bởi việc chọn các thuộc tính và phương thức từ các thực thể
tổng quan của từng nguyên mẫu
12
2.3.2. Chuyển đổi từ PIM sang PSM
2.3.2.1.
Theo vết mô hình
Hình 2.8. Đánh dấu mô hình
Hình 2.8 mở rộng mô hình MDA nhằm miêu tả chi tiết một trong những cách
mà một chuyển đổi có thể được thực hiện.
Một nền công nghệ cụ thể được lựa chọn. Ánh xạ cho nền công nghệ này sẵn có và
được chuẩn bị. Ánh xạ này bao gồm một bộ thiết bị đánh dấu. Các dấu được sử
dụng nhằm đánh dấu các yếu tố mô hình để hướng dẫn cho quá trình biến đổi mô
hình. Việc sử dụng ánh xạ sẽ làm cho PIM đánh dấu được biến đổi xa hơn nhằm tạo
ra PSM.
2.3.2.2.
Quá trình biến đổi siêu mô hình – Metamodel
Hình 2.9. Quá trình biến đổi Metalmodel.
13
Hình 2.9 mở rộng các mô hình MDA để diễn tả thêm chi tiết của một trong
những cách mà một chuyển đổi có thể được thực hiện.
Mô hình được chuẩn bị bằng cách sử dụng một ngôn ngữ độc lập với nền
công nghệ được xác định bởi một metamodel. Một nền công nghệ cụ thể được lựa
chọn. Đặc tả mô hình chuyển đổi nền tảng này hiện có sẵn hoặc được chuẩn bị. Sự
chuyển đổi đặc tả này dưới dạng ánh xạ giữa các metamodel. Ánh xạ chỉ dẫn sự
chuyển đổi của PIM tạo ra PSM.
2.3.2.3.
Quá trình biến đổi mô hình
Hình 2.10. Quá trình biến đổi mô hình
Mô hình được chuẩn bị bằng cách sử dụng các kiểu độc lập nền công nghệ
trong mô hình. Các kiểu có thể là phần của một khung phần mềm. Các yếu tố trong
PIM là các kiểu phụ của dạng độc lập nền công nghệ. Một nền công nghệ cụ thể
được lựa chọn. Dạng biến đổi đặc tả nền công nghệ này sẵn có hoặc được chuẩn bị
sẵn. Sự biến đổi này là ánh xạ giữa các kiểu độc lập nền tảng và các kiểu phụ thuộc
nền tảng. Các yếu tố trong PSM là kiểu phụ của các kiểu đặc tả nền tảng.
Cách tiếp cận này khắc hẳn với ánh xạ metamodel chủ yếu bằng các kiểu đặc
tả trong một mô hình mà được sử dụng cho ánh xạ, thay thế cho các khái niệm đặc
tả bởi mô hình metamodel.
2.3.2.4.
Ứng dụng mẫu
Mở rộng các phương pháp tiếp cận ánh xạ siêu mô hình và mô hình bao gồm
các mẫu cùng với các kiểu hay các khái niệm ngôn ngữ mô hình.
14
Hình 2.11. Ứng dụng mẫu
Ngoài các kiểu độc lập nền tảng, mô hình chung có thể cung cấp các mẫu. Cả
hai kiểu và mẫu này có thể được ánh xạ tới các mẫu và các kiểu đặc tả nền tảng.
Phương pháp tiếp cận ánh xạ mô hình metamodel có thể sử dụng các mẫu
cùng một cách.
Hình 2.12. Một cách khác để sử dụng các mẫu
Hình 1.12 chỉ ra một cách khác để sử dụng các mẫu: khi các tên của nền tảng
cụ thể đánh dấu, có nghĩa là, tên của các mẫu thiết kế quy định cho một nền tảng.
15
2.3.2.5.
Mô hình kết hợp
Có một số cách tiếp cận MDA dựa vào các mô hình kết hợp.
Hình 2.13. Mô hình kết hợp
Hình 2.13 mở rộng mô hình MDA theo một cách khác nhằm miêu tả chi tiết
một trong những cách chuyển đổi khác có thể được thực hiện.
2.3.2.6.
Thông tin bổ sung
Ngoài những PIM và các nền tảng cụ thể đánh dấu, thông tin bổ sung có thể
được cung cấp để hướng dẫn việc chuyển đổi.
Thông tin bổ sung sẽ thường xuyên dựa trên các kiến thức thực tế của nhà
thiết kế.
Hình 2.14. Bổ sung thông tin để chuyển sang PSM
Hình vẽ mở rộng mẫu MDA đơn giản nhằm chỉ ra cách sử dụng của thông
tin bổ sung
16
Hình 2.15. Sử dụng thông tin bổ sung trong kỹ thuật biến đổi cụ thể
Hình 2.15 mở rộng thêm mẫu MDA nhằm chỉ ra cách sử dụng thông tin bổ
sung trong kỹ thuật biến đổi cụ thể.
Trong quá trình chuẩn bị mô hình PIM, ngoài việc sử dụng các tên mẫu có
sẵn thì các thông tin khác có thể được thêm vào để tạo ra PIM đánh dấu. Ngoài các
mẫu ra, các thông tin thêm cũng có thể được sử dụng khi PIM đánh dấu được biến
đổi thêm nhằm tạo ra PSM
2.3.3. Chuyển đổi mô hình trong một hệ thống phức tạp
Đối với những hệ thống phức tạp, mỗi mô hình của MDA có thể được tinh
chỉnh nhiều lần trước khi chuyển sang loại mô hình khác.
Ví dụ: Hình 2.16 mô tả quá trình chuyển đổi các mô hình trong một hệ thống
phức tạp: mô hình CIM được tinh chỉnh nhiều lần trước khi chuyển sang mô hình
PIM, mô hình PIM được tinh chỉnh nhiều lần trước khi chuyển sang mô hình PSM
và mô hình PSM cũng được tinh chỉnh nhiều lần trước khi chuyển sang code thực
thi.
Hình 2.16. Ví dụ về quy trình MDA cho một hệ thống phức tạp
17
Chƣơng 3 - PHƢƠNG PHÁP PHÂN TÍCH VÀ THIẾT KẾ HƢỚNG
ĐỐI TƢỢNG PHẦN MỀM ỨNG DỤNG THEO KIẾN TRÚC
HƢỚNG MÔ HÌNH
3.1.
Phân tích kiến trúc hệ thống
Phân tích kiến trúc hệ thống là việc xem xét lựa chọn một cách tổ chức cấu
trúc cơ bản cho việc phát triển một hệ thống phần mềm dựa trên các mẫu kiến trúc.
Mỗi mẫu kiến trúc cung cấp một tập các gói được định nghĩa trước, chỉ rõ các
nhiệm vụ của các gói đó, và bao gồm các luật và các nguyên tắc thiết lập quan hệ
giữa các gói.
Một số mẫu kiến trúc nhƣ sau:
Mẫu các tầng (Layer): Trong mẫu này một ứng dụng được phân chia thành
các mức trừu tượng hóa khác nhau. Các tầng giới hạn trong phạm vi từ các
tầng ứng dụng cụ thể ở trên đến các tầng thực thi hoặc nền công nghệ cụ thể ở
dưới.
Mẫu Mô hình - Hiển thị - Điều khiển (Model - View - Controller): Trong mẫu
này một ứng dụng được phân chia thành 3 phần:
- Mô hình thể hiện các luật nghiệp vụ và dữ liệu cơ bản,
- Phần hiển thị thể hiện các thông tin được trình diễn cho người sử dụng,
- Và các điều khiển xử lý thông tin đầu vào từ người sử dụng.
Mẫu ống dẫn và bộ lọc (Pipes and Filters): Trong mẫu này dữ liệu được xử lý
thành các luồng qua ống dẫn từ bộ lọc này đến bộ lọc khác. Ống dẫn (Pippe) ở
đây giống như hàng đợi, thông tin được xử lý trên cơ sở vào trước, ra trước
(first-in, first-out).
Mỗi mẫu kiến trúc đưa ra các đặc trưng nhất định cho hệ thống, các đặc trưng
về sự trình bày, về tiến trình xử lý và sự phân phối các thành phần trong kiến trúc.
Tùy vào đặc trưng của mỗi hệ thống phần mềm mà người phân tích kiến trúc có thể
sử dụng một mẫu kiến trúc hoặc kết hợp nhiều mẫu kiến trúc cho hệ thống.
Dựa trên đặc điểm của MDA là đi từ mô hình ở mức trừu tượng hóa cao đến
mô hình cụ thể hóa (được trình bày ở chương 2) và dựa trên đặc điểm của các mẫu
kiến trúc, kiến trúc tầng là loại kiến trúc hệ thống phù hợp nhất cho phương pháp
phân tích và thiết kế hệ thống theo MDA.
