Tải bản đầy đủ (.pdf) (99 trang)

Thao tác mô hình trong phát triển hướng mô hình

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 (4.05 MB, 99 trang )

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN HUY HỒNG

THAO TÁC MƠ HÌNH
TRONG PHÁT TRIỂN HƢỚNG MƠ HÌNH

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội-2014


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN HUY HỒNG

THAO TÁC MƠ HÌNH
TRONG PHÁT TRIỂN HƢỚNG MƠ HÌNH

LUẬN VĂN THẠC SĨ CƠNG NGHỆ THƠNG TIN
Ngành: Cơng nghệ thơng tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. ĐẶNG ĐỨC HẠNH

Hà Nội-2014



LỜI CAM ĐOAN
Tơi xin cam đoan đây là cơng trình nghiên cứu của riêng tôi, đƣợc thực hiện qua sự
hƣớng dẫn khoa học của TS. Đặng Đức Hạnh.
Các nội dung nghiên cứu và kết quả đạt đƣợc trình bày trong luận văn là hồn tồn
trung thực, do tơi tổng hợp, đúc kết bổ sung và biên soạn theo sự hiểu biết của minh
thông qua nghiên cứu từ các tài liệu tham khảo: Sách, báo cáo khoa học và các tài liệu
đƣợc công bố trên website, thƣ viện điện tử của cá nhân - tổ chức nghiên cứu khoa học
trên khắp thế giới.
Hà Nội, tháng 10 năm 2014
Ngƣời thực hiện

Nguyễn Huy Hoàng

.

i


LỜI CẢM ƠN
Lời đầu tiên, Luận văn xin cảm ơn đề tài nghiên cứu khoa học cấp Đại học Quốc
gia Hà Nội, mã số QG.14.06 do TS. Đặng Đức Hạnh làm chủ đề tài. Luận văn hoàn
thành đƣợc hỗ trợ một phần bởi đề tài nghiên cứu nêu trên.
Tôi cũng xin gửi lời cảm ơn sâu sắc nhất tới TS. Đặng Đức Hạnh – Giảng viên Bộ
môn Công nghệ Phần mềm – Khoa Công nghệ Thông tin – Trƣờng Đại học Công nghệ
- Đại học Quốc Gia Hà Nội, ngƣời đã định hƣớng nghiên cứu, tận tình hƣớng dẫn tơi
hồn thành luận văn này. Với bản thân tôi, lĩnh vực nghiên cứu này còn là mới nhƣng
qua sự định hƣớng về cách tiếp cận, hƣớng dẫn phƣơng pháp nghiên cứu của Thầy tôi
đã thu đƣợc những kiến thức nhất định sau khi thực hiện luận văn này.
Em xin gửi lời cảm ơn sâu sắc tới các giảng viên Khoa Công nghệ Thông tin –
Trƣờng Đại học Công nghệ - ĐHQG Hà Nội, các giảng viên sau đại học khoá K18

trƣờng Đại học Công nghệ - ĐHQGHN, những ngƣời đã giảng dạy, truyền đạt cho tôi
những kiến thức quý báu trong suốt quá trình học tập tại trƣờng.
Cuối cùng, tối xin gửi lời cảm ơn tới tất cả các bạn bè khoá sau đại học K18 ngành CNTT, các đồng nghiệp, những ngƣời thân trong gia đình đã hết sức tạo điều
kiện, giúp đỡ tơi trong q trình học tập và thực hiện luận văn này.
Mặc dù luận văn đã hoàn thành nhƣng do kiến thức của ngƣời thực hiện còn hạn
chế nên chắc chắn đề tài còn nhiều vấn đề hạn chế. Tôi chân thành mong nhận đƣợc
các ý kiến góp ý của tất cả mọi ngƣời để có định hƣớng trong các nghiên cứu tiếp theo.
Hà Nội, tháng 10 năm 2014
Ngƣời thực hiện

Nguyễn Huy Hoàng

ii


MỤC LỤC
LỜI CAM ĐOAN ................................................................................................................ i
LỜI CẢM ƠN .....................................................................................................................ii
MỤC LỤC ......................................................................................................................... iii
DANH MỤC KÝ HIỆU VÀ CÁC CHỮ VIẾT TẮT ...................................................... vi
DANH MỤC HÌNH ẢNH VÀ ĐỒ THỊ ..........................................................................vii
DANH MỤC BẢNG BIỂU ................................................................................................ x
CHƢƠNG 1 MỞ ĐẦU................................................................................................... 1
1.1

Đặt vấn đề .........................................................................................................1

1.2

Phạm vi nghiên cứu .........................................................................................2


1.3

Cấu trúc luận văn.............................................................................................2

CHƢƠNG 2

TỔNG QUAN PHÁT TRIỂN HƢỚNG MƠ HÌNH............................. 3

2.1

Phƣơng pháp phát triển phần mềm truyền thống ........................................3

2.2

Giới thiệu phát triển hƣớng mơ hình - MDD ................................................4

2.3

Các khái niệm trong phát triển hƣớng mô hình. ..........................................5

2.3.1

Model ...........................................................................................................5

2.3.2

Metamodel ...................................................................................................6

2.3.3


Metametamodel ...........................................................................................6

2.3.4

Chuyển đổi mơ hình. ...................................................................................7

2.3.5

Mơ hình nguồn ............................................................................................7

2.3.6

Mơ hình đích ...............................................................................................7

2.3.7

Ngơn ngữ chuyển mơ hình...........................................................................7

2.3.8

Luật chuyển mơ hình ...................................................................................7

2.3.9

Ánh xạ ..........................................................................................................8

2.4

Kiến trúc hƣớng mơ hình – MDA ..................................................................8


2.4.1

Giới thiệu kiến trúc hướng mơ hình ............................................................8

2.4.2

Các kiểu mơ hình trong MDA .....................................................................9

2.4.3

Những Lợi ích MDA mang lại ...................................................................11

2.5

Một số chuẩn liên quan MDD .......................................................................12

2.5.1

UML - Unified Modeling Language ..........................................................13

2.5.2

XMI - XML Metadata Interchange ............................................................14

2.5.3

MOF - Meta Object Facility ....................................................................14

2.5.4


OCL Object Contraint Language ..............................................................14

iii


CHƢƠNG 3
3.1

CHUYỂN ĐỔI MƠ HÌNH TRONG MDD ......................................... 16

Các hƣớng tiếp cận giải quyết vấn đề trong chuyển mơ hình ...................16

3.1.1

Chuyển đổi mơ hình sang mã nguồn .........................................................16

3.1.2

Chuyển đổi mơ hình sang mơ hình ............................................................17

3.2

Một số cơng cụ trong chuyển đổi mơ hình ...................................................18

3.2.1

EMF - Eclipse Modeling Framework .......................................................18

3.2.2


Atlas Transformation Language - ATL .....................................................20

3.2.3

AndroMDA ................................................................................................20

3.2.4

ArcStyler ....................................................................................................20

3.2.5

OptimaJ .....................................................................................................20

3.2.6

QVT - Query/View/Transformation ..........................................................21

3.3

Một số phƣơng pháp sinh mã hƣớng mơ hình ............................................21

3.3.1

Phương pháp Template + Filterling ........................................................22

3.3.2

Phương pháp Template + Metamodel .....................................................23


3.3.3

Phương pháp sinh mã Inline-Code ...........................................................24

3.4

Ngôn ngữ xây dựng Template trong các bộ sinh mã ..................................25

3.4.1

Sử dụng ngôn ngữ .....................................................................................25

3.4.2

Sử dụng ngôn ngữ chuyên biệt miền .........................................................26

3.4.3

Sử dụng ngôn ngữ chuyển đổi mơ hình chun dụng ...............................26

CHƢƠNG 4
4.1

CƠNG CỤ CHUYỂN ĐỔI MƠ HÌNH ACCELEO M2T ................. 31

Tổng quan về Acceleo ....................................................................................31

4.1.1


Lịch sử phát triển của Acceleo ..................................................................31

4.1.2

Kiến trúc của Acceleo M2T .......................................................................31

4.1.3

Nguyên lý cơ bản của Acceleo M2T ..........................................................32

4.1.4

Template trong Acceleo M2T ....................................................................33

4.2

Cơng cụ chuyển đổi mơ hình Acceleo – JavaEE Generator ......................37

4.2.1

Các mơ hình sử dụng trong Accleo JavaEE Generator ............................37

4.2.2

Module sinh mã trong Acceleo-JavaEE Generator ..................................42

CHƢƠNG 5
5.1

CÀI ĐẶT VÀ THỰC NGHIỆM VỚI ACCELEO M2T.................... 47


Nội dung và phạm vi thực nghiệm................................................................47

5.1.1

Nội dung thực nghiệm ...............................................................................47

5.1.2

Phạm vi thực nghiệm .................................................................................49

5.2

Thiết kế các mơ hình ......................................................................................49

5.2.1

Mơ hình thực thể (Entity model) ...............................................................50

5.2.2

Mơ hình trình diễn (Cinematic Model) .....................................................51
iv


5.3

Cập nhật bộ công cụ Acceleo JavaEE Generator .......................................70

5.3.1


Bổ sung template sinh mã SQL .................................................................70

5.3.2

Cập nhật các template sinh mã Hibernate ................................................73

5.4

Thực hiện sinh mã và đánh giá kết quả .......................................................74

5.4.1

Sinh mã ứng dụng Công báo điện tử .........................................................74

5.4.2

Đánh giá hiệu quả sinh mã của Acceleo JavaEE Generator ....................75

KẾT LUẬN ....................................................................................................................... 78
TÀI LIỆU THAM KHẢO................................................................................................ 79
PHỤ LỤC .......................................................................................................................... 81

v


DANH MỤC KÝ HIỆU VÀ CÁC CHỮ VIẾT TẮT
API
ATL
CASE

CIM
CWM
DSL
DSM
EMF
EMOF
JET
JMI
JSP
M2M
M2T
MDA
MDD
MDE
MDR
MDRE
MDSD
MDSE
MOF
MVC
OCL
OMG
PIM
PM
PSM
QVT
RTM
UI
UML
XMI

XML

Application Programming Interface
ATLAS Transformation Language
Computer Aided Software Engineering
Computation Independent Model
Common Warehouse Metamodel
Domain-Specific Language
Domain-Specific Metamodel
Eclipse Modeling Framework
Essensial MOF
Java Emitter Templates
Java Metadata Interface
Java Server Pages
Model to Model
Model to Text
Model-Driven Architecture
Model-Driven Development
Model-Driven Engineering
Metadata Repository
Model Driven Reverse Engineering
Model-Driven Software Development
Model-Driven Software Engineering
Meta-Object Facility
Model-View-Controller
Object Constraint Language
Object Management Group
Platform-Independent Model.
Platform Model
Platform-Specific Model

Query/View/Transformation
Run Time Modeling
User Interface
Unified Modeling Language
XML Metadata Interchange
eXtensible Markup Language

vi


DANH MỤC HÌNH ẢNH VÀ ĐỒ THỊ
Hình 2.1 Mình hoạ phƣơng pháp phát triển phần mềm truyền thống .............................3
Hình 2.2 Áp dụng chuẩn MDA với mơ hình thác nƣớc ..................................................5
Hình 2.3 Mơ hình đƣợc viết bởi một ngơn ngữ và mơ tả hệ thống [3] ...........................6
Hình 2.4 Biểu diễn khái niệm metamodel [3] .................................................................6
Hình 2.5 Mơ tả chuyển đổi mơ hình [3] ..........................................................................7
Hình 2.6 Mơ phỏng kiến trúc – MDA ............................................................................8
Hình 2.7 Kiến trúc metadata MOF [3] ............................................................................9
Hình 2.8 Các mơ hình trong MDA [1] .........................................................................10
Hình 2.9 Khả năng tƣơng tác sử dụng cầu nối trong MDA ..........................................12
Hình 2.10 Mối liên hệ giữa các chuẩn của OMG ..........................................................13
Hình 3.1 Khung Eclipse Modeling Framework [8] .......................................................19
Hình 3.2 Mơ hình Ecore và nguồn của nó [6] ...............................................................19
Hình 3.3 Chuyển đổi mơ hình sang mã theo MDA .......................................................22
Hình 3.4 Mơ hình phƣơng pháp Template + Fillerling .................................................22
Hình 3.5 Mơ hình phƣơng pháp Template + Metamodel ..............................................24
Hình 3.6 Mơ hình phƣơng pháp sinh mã Inline-Code...................................................24
Hình 3.7 Sinh mã dựa trên Template.............................................................................25
Hình 3.8 JET Engine .....................................................................................................27
Hình 3.9 Quy trình chuyển đổi của JET ........................................................................28

Hình 3.10 Quy trình chuyển đổi trong oAW [5] ...........................................................29
Hình 4.1 Minh hoạ kiến trúc của Acceleo M2T [15] ....................................................32
Hình 4.2 Nguyên lý cơ bản của Acceleo M2T ..............................................................32
Hình 4.3 Các bƣớc sinh mã trong Acceleo M2T ...........................................................34
Hình 4.4 Ví dụ mơ hình nguồn biểu diễn lớp NhanVien ..............................................34
Hình 4.5 Metamodel của biểu đồ lớp UML ..................................................................35
Hình 4.6 Ví dụ File generate.mtl sinh lớp Java .............................................................35
Hình 4.7 Ví dụ: Mã nguồn NhanVien.Java đƣợc sinh ra ..............................................36
Hình 4.8 Entity metamodel trong Entity Designer .......................................................38
Hình 4.9 Ví dụ về một mơ hình thực thể xây dựng bởi Entity Designer ......................38
Hình 4.10 Cinematic Metamodel trong Cinematic Designer ........................................39
Hình 4.11 Ví dụ Flow Diagram trên Cinematic Designer .............................................40
vii


Hình 4.12 Ví dụ về Package Diagram trên Cinematic Designer ...................................40
Hình 4.13 Ví dụ về UI-Structure trong Cinematic Designer .........................................40
Hình 4.14 SOA Metamodel trong SOA Designer .........................................................41
Hình 4.15 Ví dụ biểu đồ SOA biểu diễn trong SOA Designer .....................................42
Hình 4.16 Ví dụ biểu đồ Component Contract trong SOA Designer ............................42
Hình 4.17 Kiến trúc MVC của Struts Framework.........................................................43
Hình 4.18 Kiến trúc của Hibernate Framework ............................................................45
Hình 5.1 Đặc tả biểu đồ Usecase – Quản lý cơng báo ..................................................47
Hình 5.2 Đặc tả biểu đồ Usecase – Quản lý văn bản ....................................................48
Hình 5.3 Đặc tả biểu đồ Usecase - Quản trị hệ thống ...................................................48
Hình 5.4 Đặc tả biểu đồ Usecase - Quản lý danh mục ..................................................48
Hình 5.5 Đặc tả biểu đồ Usecase – Khách viếng thăm hệ thống ..................................49
Hình 5.6 Mơ hình tổng quan đặc tả ứng dụng Cơng báo điện tử ..................................50
Hình 5.7 Biểu đồ tổng quan các Block – Entity Model ................................................50
Hình 5.8 Biểu đồ thực thể của Bock Vanban – Entity Model .......................................51

Hình 5.9 Biểu đồ thực thể Bock Uer – Entity Model ....................................................51
Hình 5.10 Biểu đồ thực thể Block danhmuc - Entity Model .........................................51
Hình 5.11 Biểu đồ tổng quan các Package - Cinematic Model ....................................52
Hình 5.12 Biểu đồ tổng quan gói FrontEnd - Cinematic Model ...................................53
Hình 5.13 Biểu đồ Flow ViewCongBao trong gói FrontEnd – Cinematic Model ........54
Hình 5.14 Biểu đồ tổng quan gói BackEnd - Cinemantic Model..................................56
Hình 5.15 Biểu đồ Flow-Manage trong gói BackEnd – Cinematic Model ...................56
Hình 5.16 Biểu đồ Flow-ManageLinhVuc trong gói BackEnd – Cinematic Model.....58
Hình 5.17 Biểu đồ Flow-ManageLoaiVanBan trong gói BackEnd – Cinematic Model
.......................................................................................................................................59
Hình 5.18 Biểu đồ Flow-ManageCoQuanBH trong gói BackEnd – Cinematic Model 62
Hình 5.19 Biểu đồ Flow-ManageVanBan trong gói BackEnd – Cinematic Model ......62
Hình 5.20 Biểu đồ Flow-ManageCongBao trong gói BackEnd – Cinematic Model ....65
Hình 5.21 Biểu đồ tổng quan gói System – Cinematic Model ......................................66
Hình 5.22 Biểu đồ Flow-Login trong gói System – Cinematic Model .........................66
Hình 5.23 Biểu đồ Flow ManageAccount trong gói System – Cinematic Model ........67
Hình 5.24 Biểu đồ Flow-Monitor trong gói System – Cinematic Model .....................69
Hình 5.25 Tạo mới template sqlCreate.mtl ...................................................................70
viii


Hình 5.26 Nội dung Template sqlCreate.mtl – phần 1 .................................................71
Hình 5.27 Nội dung template sqlCreate.mtl phần -2 ....................................................71
Hình 5.28 Mã nguồn sinh ra bởi sqlCreate.mtl .............................................................73
Hình 5.29 Cập nhật daoHibernateDirect.mtl trong module sinh mã Hibernate ...........73
Hình 5.30 Cập nhật daoHibernateCfg.mtl trong module sinh mã Hibernate ................74
Hình 5.31 Cấu hình module StrutsArchitecture sinh mã từ mơ hình Cinematic ..........74
Hình 5.32 Cấu hình module StrutsPresentation sinh mã từ mơ hình Cinematic ...........75
Hình 5.33 Cấu hình module HibernateArchitectureEntity sinh mã từ Entity Model ....75
Hình 5.34 Thời gian và số lƣợng file sinh bởi Acceleo JavaEE Generator ..................76


ix


DANH MỤC BẢNG BIỂU
Bảng 5-1 Thành phần trong Flow-ViewCongBao – gói FrontEnd – Cinematic Model
.......................................................................................................................................55
Bảng 5-2 Danh sách Flow trong gói BackEnd – Cinemantic Model ............................56
Bảng 5-3 Thành phần trong Flow-Manage - gói BackEnd – Cinematic Model ...........57
Bảng 5-4 Thành phần trong Flow-ManageLinhVuc – gói BackEnd – Cinematic Model
.......................................................................................................................................58
Bảng 5-5 Thành phần trong Flow-ManageLoaiVanBan – gói BackEnd – Cinematic
Model. ............................................................................................................................60
Bảng 5-6 Thành phần trong Flow-ManageCoQuanBH – gói BackEnd –Cinematic
Model. ............................................................................................................................61
Bảng 5-7 Thành phần trong Flow-ManageVanBan – gói BackEnd – Cinematic Model.
.......................................................................................................................................63
Bảng 5-8 Thành phần trong Flow-ManageCongBao – gói BackEnd – Cinematic
Model. ............................................................................................................................64
Bảng 5-9 Thành phần trong Flow-ManageAccount – gói System – Cinematic Model 67
Bảng 5-10 Thành phần trong Flow-Mornitor – gói System – Cinematic Model ..........69

x


CHƢƠNG 1
1.1

MỞ ĐẦU


Đặt vấn đề

Trong bối cảnh của thời đại tri thức, để phát triển vững mạnh và tiến bộ nhanh
chóng trong thời đại này, đối với hầu hết các lĩnh vực đều u cầu có những ứng dụng
về cơng nghệ thông tin để quản lý và hỗ trợ cho nghiệp vụ của tổ chức. Nói đến cơng
nghệ thơng tin, phần mềm đóng một vai trị cực kỳ quan trọng trong lĩnh vực công
nghệ thông tin. Trong giai đoạn hiện nay phát triển phần mềm đã trở thành ngành công
nghiệp và ở nƣớc ta đƣợc xác định là ngành công nghiệp mũi nhọn và đƣợc quan tâm
hàng đầu.
Tuy nhiên, một số trở ngại nhất định khiến trong phát triển phần mềm đó là việc
dung hồ giữa hiệu suất và chất lƣợng vẫn cịn là các mục tiêu khó đạt [14]:
 Khó nắm bắt chính xác u cầu của khách hàng: Các đơn vị phát triển phần
mềm thƣờng có hiểu biết hạn chế về lĩnh vực của khách hàng. Khách hàng
không có kiến thức về qui trình phát triển phần mềm. Thậm chí, khách hàng
cịn khơng biết hoặc khơng đƣa ra yêu cầu rõ ràng. Điều này thƣờng dẫn đến
nhu cầu thay đổi liên tục trong quá trình phát triển phần mềm.
 Đối phó thường trực với yêu cầu thay đổi. Thay đổi có thể diễn ra bất kỳ lúc
nào trong quá trình phát triển phần mềm. Rất nhiều loại thay đổi có thể xảy ra
nhƣ lỗi mã nguồn, thay đổi thiết kế, thay đổi nhân sự, thay đổi yêu cầu… Thay
đổi càng trễ chi phí khắc phục càng cao.
 Mơi trường phát triển không đồng nhất. Đối với những dự án phần mềm lớn
đội ngũ phát triển có thể bao gồm nhiều đội với nhiều nhân viên có những
kỹ năng lập trình, giao tiếp khác nhau đến từ nhiều nơi trên thế giới và sử dụng
những những nền tảng kỹ thuật khác biệt. Việc phối hợp các môi trƣờng này
thƣờng địi hỏi chi phí cao và làm phức tạp hóa quá trình phát triển.
Mặt khác, trong phát triển thƣơng mại, các công ty phát triển phần mềm luôn đặt
mục tiêu nâng cao khả năng tự động hoá, tăng năng suất lao động, giảm thiểu chi phí
sản xuất, nâng cao chất lƣợng sản phẩm… bằng cách áp dụng các công nghệ mới vào
quy trình sản xuất.
Để giải quyết các vấn đề nêu trên, các nhà phát triển phần mềm cần áp dụng nhiều

phƣơng pháp luận vào thực tiễn trong đó phƣơng pháp phát triển phần mềm hƣớng mơ
hình. Phƣơng pháp phát triển phần mềm hƣớng mơ hình ra đời với ý tƣởng chính là tập
trung vào việc mơ hình hố phần mềm, từ đó thơng qua việc chuyển đổi mơ hình, các
mơ hình nguồn chuyển đổi tự động sang các mơ hình đích, mơ hình đích có thể là các
mơ hình đặc tả, mã nguồn, tài liệu... Chính vì khả năng ƣu việt của phƣơng pháp phát

1


triển hƣớng mơ hình khiến tơi lựa chọn đề tài “Thao tác mơ hình trong phát triển
hướng mơ hình”.

1.2

Phạm vi nghiên cứu

Luận văn tập trung nghiên cứu và trình bày phƣơng pháp luận về kiến trúc hƣớng
mơ hình nói chung, phát triển hƣớng mơ hình nói riêng, các cơng cụ chuyển đổi mơ
hình sang mơ hình (M2M), mơ hình sang văn bản (M2T). Cụ thể hơn luận văn đi sâu
vào nghiên cứu và ứng dụng công cụ chuyển đổi mô hình sang văn bản – Acceleo
M2T.

1.3

Cấu trúc luận văn

Luận văn đƣợc cấu trúc thành 5 chƣơng:
 Chƣơng 1: Mở đầu – Đặt vấn đề và nêu ra định hƣớng nghiên cứu.
 Chƣơng 2: Tổng quan phát triển hƣớng mơ hình (MDD) – Trình bày những
kiến thức cơ bản về kiến trúc hƣớng mơ hình (MDA) và một số chuẩn liên quan

MDD.
 Chƣơng 3: Chuyển đổi mơ hình trong phát triển hƣớng mơ hình MDD- Trình
bày phƣơng pháp luận về chuyển đổi mơ hình, các hƣớng tiếp cận trong chuyển
đổi mơ hình, một số cơng cụ chuyển đổi mơ hình đang đƣợc áp dụng. Nghiên
cứu phƣơng pháp chuyển đổi mơ hình sang văn bản, chƣơng này trình bày một
số phƣơng pháp (pattern) sinh mã và ngôn ngữ xây dựng các khuôn mẫu
(template) trong bộ sinh mã.
 Chƣơng 4: Công cụ chuyển đổi mơ hình sang văn bản Acceleo– Chƣơng này
trình bày cơ sở lý thuyết của công cụ chuyển đổi mô hình sang văn bản
Acceleo. Nghiên cứu mã nguồn mở chuyển đổi mơ hình sang mã nguồn
Acceleo JavaEE Generator (Struts Framework, Hibernate Framework, Spring
Framework).
 Chƣơng 5: Cài đặt và thực nghiệm với Acceleo M2T – Hiệu chỉnh công cụ
chuyển đổi Acceleo JavaEE Generator nhằm đảm bảo việc chuyển đổi mơ hình
sang mã nguồn Struts, Hibernate hoạt động trên nền tảng Web theo kiến trúc
MVC với cơ sở dữ liệu Microsoft SQL Server và đƣa ra đánh giá khả năng sinh
mã của bộ công cụ.

2


CHƢƠNG 2

TỔNG QUAN PHÁT TRIỂN HƢỚNG MƠ HÌNH

Chƣơng này của luận văn trình bày khái quát Phát triển phần mềm hƣớng mơ hình
(Model Driven Software Development – MDSD). Để hiểu rõ hơn về phát triển hƣớng
mơ hình, Luận văn đƣa ra các khái niệm, cơ sở lý thuyết về kiến trúc hƣớng mơ hình,
các chuẩn liên quan đến phát triển hƣớng mơ hình và sự so sánh với phƣơng pháp phát
triển phần mềm truyền thống.


2.1

Phương pháp phát triển phần mềm truyền thống

Ngày nay, việc phát triển phần mềm theo phƣơng pháp truyền thống vẫn đang đƣợc
áp dụng phổ biến. Với các hệ thống phần mềm ở quy mơ nhỏ thì phƣơng pháp này vẫn
đáp ứng và khả dụng. Tuy nhiên khi nhu cầu tin học hoá hầu hết các nghiệp vụ trong
mọi lĩnh vực của một tổ chức thì quy mô của một hệ thống phần mềm là lớn và lúc đó
việc sử dụng phƣơng pháp truyền thơng sẽ gặp phải các khó khăn.
Một ví dụ minh hoạ các pha phát triển phần mềm trên mơ hình thác nƣớc nhƣ Hình
2.1.
Thu thập yêu cầu
Dạng tài liệu đặc tả: Văn bản

Phân tích yêu cầu
Dạng tài liệu: Văn bản, biểu đồ

Thiết kế
Dạng tài liệu: Văn bản, biểu đồ

Cài đặt mã nguồn
Mã chương trình

Kiểm thử
Tài liệu: Mã chương trình, văn
bản

Triển khai sử
dụng


Hình 2.1 Mình hoạ phƣơng pháp phát triển phần mềm truyền thống
Trong phƣơng pháp phát triển phần mềm truyền thống, giả sử những ngƣời phát
triển phần mềm đã tuân thủ rất chặt chẽ quy trình phát triển, các tài liệu ở các pha Thu
thập yêu cầu, phân tích yêu cầu, thiết kế hệ thống, cài đặt mã nguồn… đã thể hiện các
ràng buộc và sự liên quan cần có. Điều đó vẫn không tránh khỏi các vấn đề:

3


 Khi có sự thay đổi về yêu cầu của ngƣời dùng, các pha sẽ đều phải thực hiện
lại từ đầu. Điều này dẫn đến mất nhiều thời gian và gây khó khăn cho ngƣời
phát triển trong việc quản lý.
 Sản phẩm cuối cùng sẽ phụ thuộc vào một nền tảng công nghệ cụ thể, khi
nhu cầu công nghệ thay đổi sẽ dẫn đến phải xây dựng hệ thống lại từ đầu.
Trên đây là một số vấn đề mà phƣơng pháp phát triển phần mềm truyền thống đã
và đang gặp các thách thức.

2.2

Giới thiệu phát triển hướng mơ hình - MDD

“Kỹ nghệ hƣớng mơ hình (MDE) là phƣơng pháp xem xét ở mức đại điện thống
nhất, tất cả mọi thành phần đƣợc quy về mơ hình”[10]. Trong lĩnh vực phát triển phần
mềm thì MDE đƣợc hiểu nhƣ phát triển hƣớng mơ hình (MDD) hƣớng tới việc sử
dụng các mơ hình nhƣ là tác nhân chính trong tồn bộ vịng đời phát triển của ứng
dụng, các ứng dụng đƣợc sinh mã từ các mơ hình trừu tƣợng.
Cũng theo Jean Bezivin [10] trong lĩnh vực phát triển phần mềm thì MDE hay
MDD có ba hƣớng tiếp cận:
 Phát triển phần mềm hƣớng mơ hình – MDSD (Model Driven Software

Development) phục vụ cho việc sinh mã từ mơ hình. Việc chuyển đổi mơ
hình đƣợc thực hiện trong thời gian phát triển.
 Tái kỹ nghệ hƣớng mơ hình - MDRE (Model Driven Reverse
Engineering) áp dụng cho việc sinh các mơ hình từ mã. Việc chuyển đổi
thƣờng đƣợc thực hiện trong lúc bảo trì.
 Mơ hình thời gian thực thi - RTM (Run Time Modeling) thực hiện việc
chuyển đổi mơ hình trong khi thực thi ứng dụng, không phải là trong lúc
phát triển hay khi bảo trì. Các ứng dụng phổ biến ở đây nhằm đạt đƣợc khả
năng tƣơng tác giữa các hệ thống không đồng nhất.
MDD ra đời với các mục tiêu giải quyết một số vấn đề:
 Mã nguồn đƣợc tự động sinh ra từ việc chuyển đổi mơ hình, tính tự động
hố càng cao đồng nghĩa với việc thời gian và hiệu suất đƣợc cải tiến.
 Chất lƣợng phần mềm đƣợc nâng cao khi các luật chuyển đổi đƣợc định
nghĩa và thẩm định rõ ràng.
 Không bị phụ thuộc vào việc thay đổi nền tảng (platform), khi cần thay đổi
nền mới chỉ phụ thuộc vào việc điều chỉnh các luật chuyển đổi và sự thay
đổi sẽ tự động đƣợc áp dụng.
 Khả năng tái sử dụng cũng đƣợc nâng cao, các mô hình, luật chuyển đổi
hồn tồn có thể sử dụng cho những ứng dụng khác nhau do có sự tách biệt
giữa các thành phần liên quan.
4


Thu thập yêu cầu
Dạng tài liệu đặc tả: Văn bản
CIM

Phân tích yêu cầu
Platform Independent Model
PIM


Thiết kế
Platform Specific Model
PSM

Cài đặt mã nguồn
Mã chương trình

Kiểm thử
Tài liệu: Mã chương trình, văn
bản

Triển khai sử
dụng

Hình 2.2 Áp dụng chuẩn MDA với mơ hình thác nƣớc
So sánh với phƣơng pháp phát triển phần mềm truyền thống (xem mục 2.1). Sử
dụng phƣơng pháp phát triển hƣớng mơ hình, áp dụng chuẩn MDA (xem mục 2.4) vào
quy trình phát triển phần mềm theo mơ hình thác nƣớc (xem Hình 2.2). Tại mỗi pha
phát triển, các tài liệu đƣợc đặc tả bởi các mơ hình hình thức do vậy việc chuyển đổi tự
động giữa các mơ hình là khả dụng. Thông qua các công cụ chuyển đổi mô hình, từ
mơ hình độc lập nền - PSM có thể chuyển đổi sang các mơ hình phụ thuộc nền- PSM;
từ mơ hình phụ thuộc nền – PSM có thể đƣợc chuyển đổi sang dạng mã nguồn, tài
liệu… Vì vậy các vấn đề gặp khó khăn với phƣơng pháp truyền thống đã có thể đƣợc
tháo gỡ.

2.3

Các khái niệm trong phát triển hướng mơ hình.


2.3.1

Model

Mơ hình là một phƣơng pháp biểu diễn hệ thống một cách đơn giản nhằm giúp hiểu
hơn về hệ thống. Mơ hình đƣợc biểu diễn bằng các ký hiệu đồ hoạ và thƣờng đƣợc
diễn đạt bởi ngôn ngữ đặc tả miền cụ thể hoặc dƣới dạng ngôn ngữ hình thức. Chúng
ta có thể định nghĩa mơ hình nhƣ sau:
“Mơ hình là một mơ tả một phần của hệ thống hoặc tồn bộ hệ thống được viết bởi
ngơn ngữ hình thức” [3]. “Ngơn ngữ hình thức là ngơn ngữ với mẫu được xác định rõ
ràng và ngữ nghĩa phù hợp với việc biên dịch tự động bởi máy tính”[3].

5


Hình 2.3 Mơ hình đƣợc viết bởi một ngơn ngữ và mô tả hệ thống [3]
2.3.2

Metamodel

Metamodel [3] cũng là một mơ hình, nó thể hiện ở mức trừu tƣợng hơn và sử dụng
để biểu diễn mơ hình (model). Ngơn ngữ để biểu diễn metamodel đƣợc gọi là metalanguage.

Hình 2.4 Biểu diễn khái niệm metamodel [3]
Nói cách khác, metamodel của mơ hình A mơ tả cấu trúc hợp lệ của mơ hình A.
Trong chuyển đổi mơ hình thì metamodel là điều kiện tiên quyết.
2.3.3

Metametamodel


Một Metametamodel của mơ hình A là metamodel đƣợc sử dụng để mơ tả
metamodel của model A. Nó có thể đƣợc hiểu nhƣ ngữ pháp của một ngơn ngữ đƣợc
sử dụng để mô tả ngữ pháp của ngôn ngữ A.
6


2.3.4

Chuyển đổi mơ hình.

Trong lĩnh vực phát triển hƣớng mơ hình thì chuyển đổi mơ hình là trọng tâm, nó
đƣợc xem nhƣ một hộp đen cung cấp các cơ chế đƣợc thiết lập nhằm cho việc tự động
tạo ra và cập nhật các mơ hình đích dựa trên thơng tin đầu vào đƣợc biểu diễn bởi mơ
hình nguồn. [3] Định nghĩa về chuyển đổi mơ hình: “Chuyển đổi mơ hình là tập hợp
các luật chuyển đổi cùng mô tả cách một mơ hình tại ngơn ngữ nguồn có thể được
chuyển đổi thành một mơ hình ở ngơn ngữ đích”

Hình 2.5 Mơ tả chuyển đổi mơ hình [3]
2.3.5

Mơ hình nguồn

Trong ngữ cảnh của chuyển đổi mơ hình, nếu một mơ hình đóng vai trị là đầu vào
của bƣớc chuyển đƣợc gọi là mơ hình nguồn. Mơ hình nguồn phải tn thủ metamodel
nguồn. Có thể có một hoặc nhiều mơ hình nguồn là đầu vào của bƣớc chuyển.
2.3.6

Mơ hình đích

Trong ngữ cảnh của chuyển đổi mơ hình, nếu một mơ hình đóng vai trò là đầu ra

của bƣớc chuyển đƣợc gọi là mơ hình đích. Mơ hình đích phải tn thủ metamodel
đích. Có thể có một hoặc nhiều mơ hình đích đƣợc sinh ra sau một bƣớc chuyển. Thuật
ngữ mơ hình đích thƣờng đƣợc sử dụng trong chuyển đổi mơ hình sang mơ hình
(M2M – Model To Model).
2.3.7

Ngơn ngữ chuyển mơ hình

Một ngơn ngữ chuyển mơ hình là một tập từ vựng và một ngữ pháp đƣợc định
nghĩa ngữ nghĩa tốt cho khả năng chuyển mơ hình.
2.3.8

Luật chuyển mơ hình

Theo [3] định nghĩa “Một luật chuyển đổi mơ hình là sự mơ tả cách một hoặc nhiều
cấu trúc trong ngôn ngữ nguồn có thể được chuyển đổi thành một hoặc nhiều cấu trúc
trong ngơn ngữ đích”. Một luật chuyển đổi mơ hình là thực thể nhỏ nhất trong chuyển
mơ hình. Nó mơ tả cách một phần của mơ hình nguồn có thể đƣợc chuyển thành một
phần của mơ hình đích. Một luật chứa một mẫu nguồn và một mẫu đích, đối với một
phần xuất hiện của mẫu nguồn trong mơ hình nguồn sẽ có ánh xạ tƣơng ứng với một
phần của mẫu đích trong mơ hình đích.

7


2.3.9

Ánh xạ

Ánh xạ là các đặc tả cho một cơ chế chuyển đổi các phần tử của một mơ hình đƣợc

xây dựng tuân theo một metamodel cụ thể này sang các phần tử của một mơ hình đƣợc
xây dựng tn theo một metamodel khác.[16].
Các nhãn trong chuyển đổi mơ hình là khái niệm biểu diễn một khái niệm trong mơ
hình đích và đƣợc áp dụng cho một phần tử của mơ hình nguồn để chỉ ra phần tử đó
đƣợc chuyển đổi nhƣ thế nào. [16].

2.4

Kiến trúc hướng mơ hình – MDA

2.4.1

Giới thiệu kiến trúc hướng mơ hình

Kiến trúc hƣớng mơ hình - MDA (Model Driven Architecture ) [20] là một phƣơng
pháp chun biệt hố trong phát triển hƣớng mơ hình đƣợc đề xuất bởi tổ chức OMG
(Object Management Group) từ năm 2001. MDA đƣợc đề xuất bắt nguồn từ nhu cầu
làm rõ và đặc tả các tác vụ của hệ thống, xác định rõ ràng thành phần nào phụ thuộc
vào nền tảng, thành phần nào không phụ thuộc vào nền tảng và đồng thời phân nhỏ các
mức độ phụ thuộc vào nền tảng. Hƣớng tiếp cận của MDA trong phát triển phần mềm
là sự chuyển đổi các mơ hình.

Hình 2.6 Mơ phỏng kiến trúc – MDA
Trong Hình 2.6 mơ tả mơ hình MDA bao gơm: Một bộ cơng cụ chuyển đổi lấy mơ
hình nguồn là một PIM (xem mục 2.4.2.2) chuyển đổi thành mơ hình đích là một PSM
(xem mục 2.4.2.3). Ở một ngữ cảnh khác với một bộ công cụ chuyển đổi có thể chọn
mơ hình nguồn là PSM (xem mục 2.4.2.3) và chuyển đổi thành mơ hình đích dạng văn
bản (mã nguồn, tài liệu…).
MDA định hƣớng cho các ứng dụng đạt đƣợc các điểm sau:
 Thể hiện sự tách biệt rõ ràng giữa hệ thống và nền tảng.

 Đặc tả mơ hình hệ thống trên nền tảng độc lập.
 Xác định một nền tảng chuyên biệt mà hệ thống phù hợp.
8


 Chuyển hệ thống từ đặc tả trên nền tảng độc lập sang nền tảng thực thi cụ
thể.
Ba mục tiêu chính của MDA là khả năng chuyển đổi (portability), tính tƣơng vận
(interoperability) và khả năng tái sử dụng (reusability).

Hình 2.7 Kiến trúc metadata MOF [3]
MDA định hƣớng phát triển phần mềm theo kiểu kiến trúc hƣớng mơ hình theo đặc
tả MOF (xem mục 2.5.3), xác định kiến trúc metadata nhƣ Hình 2.7. Trong đó, M0 là
hệ thống mà phần mềm mà chúng ta cần xây dựng. Hệ thống này đƣợc mơ tả bởi các
mơ hình ở mức M1. Mức M2 chứa các metamodel quy định cấu trúc và ngữ nghĩa cho
các mơ hình ở mức M1. Mức M3 trên cùng là mức meta-metamodel định nghĩa cấu
trúc và ngữ nghĩa biểu diễn metamodel ở mức M2.
2.4.2

Các kiểu mơ hình trong MDA

Trong kiến trúc hƣớng mơ hình – MDA, các loại mơ hình đƣợc sự dụng bao gồm:
Mơ hình độc lập tính tốn - CIM, mơ hình độc lập nền – PIM, mơ hình phụ thuộc nền
– PSM và mơ hình nền tảng – PM. Ba kiểu mơ hình CIM, PIM, PSM thể hiện các
hƣớng nhìn hệ thống theo các khía cạnh khác nhau và ở mức độ trừu tƣợng tƣơng ứng
với các pha phân tích yêu cầu, thiết kế và cài đặt trong phƣơng pháp phát triển phần
mềm truyền thống (xem Hình 2.2).
9



Mơ hình u cầu
Requirements Model

CIM
CIM ~
~ Mơ
Mơ hình
hình
phân
phân tích
tích u
u cầu
cầu

Chuyển đổi
CIM2PIM & PIM2PIM

PIM
PIM ~
~ Mơ
Mơ hình
hình thiết
thiết kế
kế

Mơ hình thiết kế
Design Model

Chuyển đổi
PIM2PSM


PSM
PSM ~
~ Mơ
Mơ hình
hình thực
thực thi
thi

Mơ hình thực thi
Implementation Model

Hình 2.8 Các mơ hình trong MDA [1]

2.4.2.1

Mơ hình độc lập tính tốn - CIM

Mơ hình độc lập tính tốn – CIM là mơ hình nhằm mơ hình hố các u cầu của hệ
thống, nó miêu tả các ngữ cảnh mà hệ thống sẽ sử dụng. CIM có thể ẩn đi các thông
tin về cách xử lý các dữ liệu trong hệ thống. Tuỳ theo ngữ cảnh khác nhau mà có gọi
CIM là mơ hình phân tích, mơ hình miền hoặc mơ hình nghiệp vụ.
Mơ hình độc lập tính tốn – CIM là mơ hình của hệ thống để thể hiện vị trí, vai trị
của hệ thống trong mơi trƣờng triển khai nó. CIM giúp chúng ta biểu diễn chính xác
những gì mà chúng ta mong đợi hệ thống sẽ thực hiện đƣợc. Ngồi ra, sự hữu ích của
CIM không chỉ giúp hiểu đƣợc các vấn đề chung của hệ thống mà cịn giúp chúng ta
có thêm cơ sở để xây dựng các mơ hình khác của hệ thống một cách đúng đắn. Nó
đóng vai trị quan trọng trong việc lấp khoảng trống giữa các chuyên gia phân tích trên
miền cụ thể, những chuyên gia thiết kế, triển khai hay bảo trì.


2.4.2.2

Mơ hình độc lập nền – PIM

Mơ hình độc lập nền – PIM là một mơ hình độc lập với các nền tảng. Nó mơ tả hệ
thống nhƣng khơng nêu rõ nó sẽ đƣợc sử dụng cho một nền tảng cụ thể nào. Một mơ
hình độc lập nền sẽ phù hợp cho các kiểu kiến trúc đặc biệt, nó có thể đƣợc sử dụng
cho máy ảo, một loại nền tảng chung hoặc là các nền tảng trừu tƣợng.

2.4.2.3

Mơ hình phụ thuộc nền – PSM

Mơ hình phụ thuộc nền – PSM là mơ hình đƣợc xây dựng cho một nền tảng cụ thể.
Nó có nguồn gốc từ mơ hình PIM và thêm một số các thơng tin liên quan. Do vậy kết
hợp đƣợc các đặc điểm của kỹ thuật nền tảng độc lập với chi tiết các nền tảng cụ thể.
10


Tuỳ thuộc vào mục đích sử dụng mà PSM có thể cung cấp ít hay nhiều thơng tin chi
tiết về hệ thống. Nếu PSM bao gồm tất cả các thông tin chi tiết cần thiết cho việc tự
động sinh ra các thành phần của hệ thống từ mơ hình thì đó là một mơ hình phụ thuộc
nền tảng triển khai. Mặt khác, PSM có thể yêu cầu bƣớc sàng lọc tự động hay thủ cơng
trƣớc khi khi có đƣợc một mơ hình phụ thuộc nền tảng triển khai.

2.4.2.4

Mơ hình nền – PM

Mơ hình nền – PM cung cấp một tập các khái niệm kỹ thuật, biểu diễn các phần

khác nhau tạo nên nền tảng và những dịch vụ cung cấp bởi nền tảng đó. Mặt khác, nó
cũng cung cấp cho việc sử dụng mơ hình phụ thuộc nền các khái niệm biểu diễn các
thành phần khác nhau trên một nền tảng cụ thể, nghĩa là một mơ hình nền cung cấp
một metamodel cho mơ hình phụ thuộc nền.
2.4.3

Những Lợi ích MDA mang lại

2.4.3.1

Đảm bảo hiệu suất và chất lượng phần mềm.

Phát triển theo MDA tập trung vào việc xây dựng mơ hình PIM, ở bƣớc này chúng
ta làm việc một cách độc lập mà không phụ thuộc vào nền tảng đích, các vấn đề liên
quan đến nền tảng kỹ thuật sẽ tự động thêm vào bởi việc chuyển đổi từ PIM sang PSM
hay việc chuyển đổi từ PSM sang Text cũng đƣợc tự động hoá. Do vậy chúng ta tập
trung vào việc giải quyết các vấn đề nghiệp vụ tại thời điểm đầu của pha thiết kế hoặc
trong việc bảo trì nâng cấp hệ thống, chính vì thế sẽ cải tiến đƣợc hiệu suất và chất
lƣợng của phần mềm.
2.4.3.2

Khả năng tương tác

Khi PSM đƣợc xác định cho các nền tảng khác nhau, chúng không thể trao đổi trực
tiếp với nhau. Bằng cách nào đó chúng ta cần chuyển đổi các khái niệm từ một nền
tảng này thành các khái niệm đƣợc sử dụng ở nền tảng khác. Đây là những gì mà khả
năng tƣơng tác đề cập tới. MDA giải quyết vấn đề này bằng cách tạo ra các cầu nối
(bridge) cần thiết giữa chúng (xem Hình 2.9).
Nhƣ Hình 2.9, giả sử chúng ta chuyển đổi một PIM thành hai PSM phụ thuộc vào
hai nền tảng khác nhau, tất cả thông tin chúng ta cần để thu hẹp khoảng cách giữa hai

PSM là đã có sẵn. Cụ thể, với mỗi thành phần trong PSM thứ nhất ta biết từ thành
phần nào trong PIM mà nó đã đƣợc chuyển đổi. Từ thành phần trong PIM ta biết thành
phần tƣơng ứng nào ở trong PSM thứ hai. Do đó, ta có thể suy ra có bao nhiêu thành
phần từ PSM thứ nhất liên quan đến các thành phần ở PSM thứ hai. Khi ta biết tất cả
chi tiết kỹ thuật nền tảng cụ thể của cả hai PSM, ta có tất cả thông tin cần thiết để tạo
một cầu nối giữa hai PSM.

11


Hình 2.9 Khả năng tƣơng tác sử dụng cầu nối trong MDA

2.4.3.3

Khả năng tương thích và tái sử dụng

Khi xem xét đến khía cạnh tƣơng thích ngƣợc, thì từ một PIM có thể chuyển đổi
sang nhiều PSM cho nhiều nền tảng đích khác nhau, do đó việc thiết kế PIM sẽ hồn
tồn tƣơng thích với nền tảng mới sử cơng nghệ mới. Mặt khác khi những nền tảng
công nghệ mới đƣợc phát minh trong tƣơng lai, thì chúng ta chỉ cần thay đổi những
công cụ chuyển đổi phù hợp, điều này cho phép chúng ta nhanh chóng triển khai hệ
thống mới dựa trên nền tảng cũ (PIM).

2.4.3.4

Bảo trì và tài liệu.

Với sự tập trung vào công việc thiết kế và sự tự động chuyển đổi từ từ mơ hình
sang mơ hình hay từ mơ hình sang dạng mã nguồn, tài liệu, hơn nữa là cả bộ Testcase
sẽ dễ dàng cho các pha vận hành bảo trì sau này.


2.5

Một số chuẩn liên quan MDD

Điểm đặc biệt quan trọng để tích hợp thành công cũng nhƣ đạt đƣợc sự liên tác và
quản lý các siêu dữ liệu độc lập với các ứng dụng, các nền tảng, các công cụ và các cơ
sở dữ liệu cũng nhƣ dễ dàng thực hiện các chuyển đổi trong MDA nói riêng hay MDD
nói chung là việc đƣa ra các chuẩn chung thống nhất. Tổ chức OMG đã đƣa một số
chuẩn cơ bản cho MDA nhƣ: MOF, UML, XMI, CWM, chúng có sự liên kết chặt chẽ
với nhau nhƣ thể hiện trong Hình 2.10.

12


XMI

Mapping to XML

MOF
Model

JMI

Mapping to Java

Instance Of
Instance Of
UML
Metamodel


Instance Of
CWM
OLAP

Mapping to Java

JOLAP
Metadata

Extend

Serializes
Instance Of
CWM Data
Mining

JDM
Metadata

Hình 2.10 Mối liên hệ giữa các chuẩn của OMG
2.5.1

UML - Unified Modeling Language

Ngơn ngữ mơ hình hố thống nhất UML cung cấp các chuẩn trừu tƣợng nhằm đơn
giản hố việc làm tài liệu, hiểu và bảo trì các hệ thống phần mềm phức tạp. Cơ chế mở
rộng của UML hỗ trợ xây dựng các mơ hình cho hệ thống và đặc tả một cách chi tiết,
chính xác. Ngồi ra, UML còn cung cấp UML Profile hỗ trợ việc đặc tả các chi tiết
gần hơn tới mơ hình cài đặt cũng nhƣ cho phép xây dựng các ánh xạ, các luật chuyển

đổi.
UML là ngơn ngữ mơ hình hố, cho phép chúng ta làm việc ở mức độ trừu tƣợng
cao mà ít quan tâm tới nền tảng cơng nghệ, do vậy nó làm giảm mức độ phức tạp của
hệ thống, trực quan và dễ nắm bắt hệ thống hơn. Chuẩn UML có thể đƣợc mở rộng
cho từng dự án cụ thể khi chúng ta cần bằng cách dùng UML profiles. Những ngữ
nghĩa có thể đƣợc thêm vào cùng với các phần tử UML đã có giúp ta định nghĩa các
khn mẫu (Stereotypes), các giá trị đích và các ràng buộc. UML hƣớng ngƣời phát
triển tới kiến trúc của các hệ thống cụ thể. Để đạt đƣợc hiệu quả đó giống nhƣ một
cơng cụ mơ hình hố, các biểu đồ UML biểu diễn hệ thống ở mức trừu tƣợng cao, ẩn
đi nhiều chi tiết ở mức thấp. Theo thời gian, ngƣời dùng UML nhận thấy rằng cách tốt
nhất để đạt đƣợc mục đích của mình là áp dụng MDA, mà trong đó các mơ hình UML
đƣợc chuyển đổi tự động từ mức trừu tƣợng cao tới trừu tƣợng ở mức thấp hơn và cuối
cùng là chuyển đổi thành mã nguồn trên một ngôn ngữ đƣợc lựa chọn. Mặc dù không
phải là bắt buộc nhƣng UML là một cơng nghệ chính cho việc phát triển phần mềm
theo phƣơng pháp MDA.

13


×