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

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

NGUYỄN HUY HOÀ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 HOÀ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à hoàn toà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
hoà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 quá 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 chuyên 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 yê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 hoà 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 yê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 hoá 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 toà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
hoá 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
hoàn toà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 toà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 tuân 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 tuân 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 tuân 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 chuyên biệt hoá 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 toá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 yêu cầu
Requirements Model

CIM
CIM ~
~ Mô
Mô hình
hình
phân
phân tích
tích yêu
yê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 toán - CIM

Mô hình độc lập tính toán – CIM là mô hình nhằm mô hình hoá các yê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 toá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. Ngoà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ẽ hoàn
toà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 hoá thống nhất UML cung cấp các chuẩn trừu tƣợng nhằm đơn
giản hoá 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. Ngoà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 hoá, 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
khuôn 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 hoá, 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