Ứng dụng kỹ thuật software factory trong phát triển phần mềm quản lý tài liệu lưu trữ bộ quốc phòng

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

ỨNG DỤNG KỸ THUẬT SOFTWARE FACTORY TRONG PHÁT

TRIỂN PHẦN MỀM QUẢN LÝ TÀI LIỆU LƯU TRỮ

BỘ QUỐC PHÒNG

LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM

…

Hà Nội – 2017

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

ĐỖ TRUNG TIẾN

ỨNG DỤNG KỸ THUẬT SOFTWARE FACTORY TRONG PHÁT

TRIỂN PHẦN MỀM QUẢN LÝ TÀI LIỆU LƯU TRỮ

SĐH.QT9.BM11 Ban hành lần 1 ngày 11/11/2014

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập – Tự do – Hạnh phúc

BẢN XÁC NHẬN CHỈNH SỬA LUẬN VĂN THẠC SĨ

Họ và tên tác giả luận văn : Tạ Văn Bảy

Đề tài luận văn: Nghiên cứu sử dụng lá cây cao su làm vật liệu xử lý chì trong

1 Đã bổ sung nguồn trích dẫn, tài liệu tham khảo phần tổng quan (trang 3-23)

2 Đã bổ sung các điều kiện tiến hành thí nghiệm chương 2, mục 2.5 (trang 29-31),

đã bổ sung cách tính dung lượng hấp phụ (trang 27), đã bổ sung điều kiện thí nghiệm của cột hấp phụ lien tục mục 2.3.2 (trang 27)

3 Đã thay đổi “ảnh hưởng của tốc độ khuấy trộn’’ là dùng máy lắc (trang 30, 31, 38)

4 Đã đưa ra kết quả tối ưu sau mỗi một kết quả để sử dụng trong thí nghiệm tiếp theo (trang 33÷47)

5 Đã sửa lại hình 3.11 và 3.12 (trang 43)

6 Đã bổ sung thảo luận kết quả, so sánh với các vật liệu sinh học khác (trang 42)

7 Đã cập nhật một số tài liệu tham khảo công bố trong 5 năm gần đây (TLTK)

1

MỤC LỤC Trang

LỜI CAM ĐOAN 4

DANH MỤC CÁC BẢNG 5

DANH MỤC CÁC TỪ VIẾT TẮT 6

DANH MỤC CÁC HÌNH VẼ 7

PHẦN MỞ ĐẦU 8

1 Lý do chọn đề tài 8

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

3 Bố cục luận văn 9

CHƯƠNG I TỔNG QUAN VỀ PHÁT TRIỂN PHẦN MỀM HƯỚNG MÔ HÌNH (MDD) 10

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

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

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

1.3.1 Mô hình (model) 13

1.3.2 Siêu mô hình (Metamodel) 14

1.3.3 Metametamodel 15

1.3.4 Chuyển đổi mô hình 15

1.3.5 Mô hình nguồn 15

1.3.6 Mô hình đích 15

1.3.7 Ngôn ngữ chuyển mô hình 16

1.3.8 Luật chuyển mô hình 16

1.3.9 Ánh xạ 16

1.4 Kiến trúc hướng mô hình - MDA 16

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

1.4.2 Các kiểu mô hình trong MDA 18

1.4.2.1 Mô hình độc lập tính toán - CIM 18

1.4.2.2 Mô hình độc lập nền - PIM 19

1.4.2.3 Mô hình phụ thuộc nền - PSM 19

1.4.2.4 Mô hình nền - PM 19

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

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

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

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

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

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

1.6 Một số công cụ trong chuyển đổi mô hình 21

2

1.6.1 EMF - Eclipse Modeling Framework 21

1.6.2 Atlas Transformation Language - ATL 23

1.6.3 AndroMDA 23

1.6.4 ArcStyler 23

1.6.5 OptimaJ 24

1.6.6 QVT - Query/View/Transformation 24

1.7 Software Factory của Microsoft 25

1.8 Kết chương 25

CHƯƠNG 2 KỸ THUẬT PHÁT TRIỂN PHẦN MỀM DỰA TRÊN SOFTWARE FACTORY 26

2.1 Software Factory 26

2.1.1 SF với các khía cạnh đổi mới 27

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

2.1.3 Software Factory làm việc như thế nào? 31

2.1.4 Software Factory Schema[4] 33

2.1.5 Software Factory Templates 36

2.1.6 Tái sử dụng có hệ thống 36

2.1.7 Công cụ để phát triển Software Factory 38

2.2 So sánh giữa Software Factories and Model-DrivenArchitecture 38

2.3 Phát triển phần mềm dựa trên Microsoft Software Factory (MSF) 41

2.4 Kết chương 46

CHƯƠNG 3 PHÁT TRIỂN PHẦN MỀM QUẢN LÝ TÀI LIỆU LƯU BỘ QUỐC PHÒNG SỬ DỤNG KỸ THUẬT SOFTWARE FACTORY 47

3.1 Giới thiệu về bài toán quản lý tài liệu lưu trữ Bộ Quốc phòng 47

3.1.1 Công tác quản lý, phân loại tài liệu lưu trữ Bộ Quốc phòng 48

3.1.1.1 Khái niệm về Phông lưu trữ 48

3.1.1.2 Cách đặt tên Phông lưu trữ 48

3.1.1.3 Điều kiện để thành lập Phông lưu trữ cơ quan 48

3.1.2 Quy trình quản lý tài liệu lưu trữ 50

3.2 Phân tích thiết kế hệ thống 52

3.2.1 Tổng quan các gói nghiệp vụ của hệ thống 52

3.2.2 Biểu đồ ngữ cảnh của hệ thống 52

3.2.3 Biểu đồ sử dụng tổng quát (Use Case Diagram) 55

3.2.4 Biểu đồ luồng dữ liệu 56

3.3 Lựa chọn công cụ phát triển ứng dụng WEB sử dụng Web Client Software Factory (WCSF) 57

3.3.1 Giới thiệu về WCSF 57

3.3.2 Áp dụng WCSF trong phát triển ứng dụng web quản lý tài liệu lưu trữ theo mô hình MVP 58

3.3.3 Phân tích các hoạt động của Pattern trong ứng dụng 62

3.3.3 Minh họa một số giao diện phần mềm 70

3

3.4 Đánh giá hiệu quả ứng dụng 73

KẾT LUẬN VÀ KIẾN NGHỊ 74

A Kết luận 74

B Kiến nghị 75

C Hướng phát triển của đề tài 75

DANH MỤC TÀI LIỆU THAM KHẢO 76

4

LỜI CAM ĐOAN

Tôi xin cam đoan: Luận văn "Ứng dụng kỹ thuật Software Factory trong phát triển

phần mềm quản lý tài liệu lưu trữ Bộ Quốc phòng" là do bản thân tôi tự thực hiện dưới

sự hướng dẫn của TS Phùng Văn Ổn – Văn phòng Chính phủ, các thông tin số liệu và kết quả trong Luận văn có nguồn gốc rõ ràng, nội dung của Luận văn chưa từng được công bố trong bất kỳ một công trình nghiên cứu nào ở trong nước

Hà Nội, tháng 10 năm 2017

Tác giả Luận văn

Đỗ Trung Tiến

5

DANH MỤC CÁC BẢNG

Bảng 1 Sự khác nhau giữa Software Factory và Model-Driven Architecture 39 Bảng 2 Bảng nhóm các chức năng cơ bản của ứng dụng 53

6

DANH MỤC CÁC TỪ VIẾT TẮT

API Application Programming Interface

ATL ATLAS Transformation Language

CASE Computer Aided Software Engineering CIM Computation Independent Model

CWM Common Warehouse Metamodel

DSL Domain-Specific Language

DSM Domain-Specific Metamodel

EMF Eclipse Modeling Framework

EMOF Essensial MOF

JET Java Emitter Templates

JMI Java Metadata Interface

JSP Java Server Pages

MDRE Model Driven Reverse Engineering

MDSD Model-Driven Software Development MDSE Model-Driven Software Engineering

MOF Meta-Object Facility

MSF Microsoft Software Factory

MVC Model-View-Controller

OCL Object Constraint Language

OMG Object Management Group

PIM Platform-Independent Model

UML Unified Modeling Language

XMI XML Metadata Interchange

XML eXtensible Markup Language

WCSF Web Client Software Factory

7

DANH MỤC CÁC HÌNH VẼ

Hình 1 Minh hoạ phương pháp phát triển phần mềm truyền thống 10

Hình 2 Áp dụng chuẩn MDA với mô hình thác nước 12

Hình 3 Mô hình được viết bởi một ngôn ngữ và mô tả hệ thống 13

Hình 4 Biểu diễn khái niệm metamodel 14

Hình 5 Mô tả chuyển đổi mô hình 15

Hình 6 Mô phỏng kiến trúc - MDA 17

Hình 7 Kiến trúc metadata MOF 17

Hình 8 Các mô hình trong MDA 18

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

Hình 10 Mối quan hệ giữa các chuẩn OMG 21

Hình 11 Khung Eclipse Modeling Framework 22

Hình 12 Mô hình Ecore và nguồn 23

Hình 13 Khái niệm một dòng sản phẩm phần mềm 31

Hình 14 Tổng quan của Software Factory 32

Hình 15 Kiến trúc Software Factory 34

Hình 16 Tái sử dụng trong Software Factory 37

Hình 17 Minh họa các tài nguyên của Web Client Software Factory 42

Hình 18 Mối quan hệ và các thành phần trong WCSF 43

Hình 19 Mối quan hệ giữa các hành động triển khai ứng dụng với kỹ thuật SF 44

Hình 20 Mô hình đa lớp MVP trong WCSF 45

Hình 21 Sơ đồ phân loại tài liệu Phông lưu trữ Quốc gia Việt Nam 49

Hình 22 Các gói nghiệp vụ của hệ thống phần mềm 52

Hình 23 Biểu đồ ngữ cảnh của hệ thống 52

Hình 24 Sơ đồ phân rã chức năng 54

Hình 25 Biểu đồ Use Case của hệ thống 55

Hình 26 Biểu đồ luồng dữ liệu ở mức 1 56

Hình 27 Mô hình quan hệ cơ sở dữ liệu 57

Hình 28 Mô hình hệ thống Web Client Software Factory 58

Hình 29 Màn hình cài đặt công cụ mở rộng của WCSF 59

Hình 30 Màn hình khởi tạo ứng dụng WCSF 59

Hình 31 Thêm các modul nghiệp vụ, Presenter trong WCSF 60

Hình 32 Sơ đồ cài đặt một giải pháp WCSF 61

Hình 33 Mô phỏng hoạt động của các lớp Pattern 62

 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 triển hướng mô hình và cụ thể là ứng dụng quy trình phát triển phần mềm theo

nền tảng Software Factory khiến tôi lựa chọn đề tài “Ứng dụng kỹ thuật Software

Factory trong phát triển phần mềm quản lý tài liệu lưu trữ Bộ Quốc phòng”

9

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 quy trình phát triển phần mềm theo nền tảng Software Factory

3 Bố cục luận văn

Luận văn được thực hiện thành 3 chương như sau:

Chương 1: 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 Chuyển đổi mô hình trong phát triển hướng mô hình MDD 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

Chương 2: Kỹ thuật phát triển phần mềm dựa trên Software Factory - Trình bày về công cụ chuyển đổi mô hình dựa trên nền tảng Software Factory Nghiên cứu phương pháp ứng dụng quy trình phát triển phần mềm dựa trên nền tảng Software Facctory So sánh giữa Software Factories and Model-DrivenArchitecture

Chương 3: Lựa chọn công cụ phát triển ứng dụng Web dựa trên nền tảng Software Factory áp dụng cho phần mềm quản lý tài liệu lưu Bộ Quốc phòng

1.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 1

Hình 1 Minh hoạ phương pháp phát triển phần mềm truyền thống

Thu thập yêu cầu

Phân tích yêu cầu

Thiết kế

Cài đặt mã nguồn

Kiểm thử

Triển khai sử dụng

Dạng tài liệu đặc tả: Văn bản

Dạng tài liệu đặc tả: Văn bản,

11

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 đề:

 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

1.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 diện thống nhất, tất cả mọi thành phần được quy về mô hình” 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 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 [2]:

 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 - RTM (Run Time Modeling) thực hiện việc chuyển đổi

mô hình trong khi thực thi ứng dụng chứ không phải 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

12

 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

Hình 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 1.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 1.4) vào quy trình phát triển phần mềm theo mô hình thác nước (Hình 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 - PIM 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ỡ

Thu thập yêu cầu

Phân tích yêu cầu

“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” “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" [1]

Hình 3 Mô hình được viết bởi một ngôn ngữ và mô tả hệ thống Một số thuộc tính quan trọng của mô hình [1]:

Abstraction (Tính trừu tượng hóa): Thông qua tính trừu tượng hóa, một mô hình sẽ ẩn

đi được những hành động cụ thể và những thông tin chi tiết Như đã đề cập ở phần giới thiệu, các hệ thống phần mềm ngày càng trở lên phức tạp hơn, nếu các mô hình ẩn đi được sự phức tạp của hệ thống cơ sở thì người phát triển sẽ có một cái nhìn tổng quan hơn về các chức năng của hệ thống, từ đó sẽ đạt kết quả tốt hơn; năng xuất và chất lượng cao hơn Tính trừu tượng hóa cao cũng cho phép giao tiếp tốt hơn với các lĩnh vực chuyên môn, bởi vì mô hình ẩn đi thông tin và những hành động cụ thể từ đó cung cấp một ngôn từ gần gũi với lĩnh vực cần đề cập

Mô hình

Hệ thống

được viết bởi

Mô tả

14

Understandability (Tính dễ hiểu): Chỉ ẩn đi những thông tin không liên quan là chưa

đủ, một mô hình cần thể hiện những nội dung của nó một cách rõ ràng và dễ hiểu Mô hình có thể trình bày ở 2 dạng, dạng text và đồ họa Thông thường yêu cầu hệ thống được thể hiện trong tài liệu văn bản có cấu trúc, trong khi một mô hình đối tượng của

hệ thống phần mềm thường là dưới hình thức của một biểu đồ Điều quan trọng là chọn một phương pháp thể hiện nào đó mà kết quả cho ta một mô hình dễ hiểu Sẽ là không hợp lý nếu ta chọn một mô hình đối tượng dưới dạng text, bởi vi tính trừu tượng hóa này không cung cấp cho người phát triển một cái nhìn rõ ràng về hệ thống

Predictiveness (Khả năng dự đoán): Mô hình nên đưa ra cho hệ thống một cách nào

đó để nó có thể dự đoán chính xác những điểm chưa rõ ràng của hệ thống Ví dụ nếu chúng ta tạo ra một mô hình của một cây cầu, thì mô hình đó phải dự đoán được tải trọng tối đa nó có thể chịu được mà không bị sập, chúng ta nên sử dụng một loại mô hình cho phép chúng ta có thể có được thông số về vấn đề này

Accuracy (Tính chính xác): Các tính năng quan trọng của hệ thống cần được thể hiện

một cách chính xác trong mô hình

Inexpensiveness (Chi phí thấp): Một mô hình cần có chi phí thấp nhất

1.3.2 Siêu mô hình (Metamodel)

Metamodel 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 Ngôn ngữ để biểu diễn metamodel được gọi là meta- language [1]

Hình 4 Biểu diễn khái niệm metamodel

Mô hình

được định nghĩa bởi

Được viết bởi

Được viết bởi

1.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

1.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 Đị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” [1]

Hình 5 Mô tả chuyển đổi mô hình

1.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

16

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)

1.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

1.3.8 Luật chuyển mô hình

Theo định nghĩa [1] “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

1.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

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

1.4 Kiến trúc hướng mô hình - MDA

1.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) [10] 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

17

Hình 6 Mô phỏng kiến trúc - MDA

Trong Hình 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 1.4.2.2) chuyển đổi thành mô hình đích là một PSM (xem mục 1.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 1.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

 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 7 Kiến trúc metadata MOF

18

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 (Meta-Object Facility), xác định kiến trúc metadata như Hình 7 Trong đó, M0

là hệ thống mà phần 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

1.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)

Hình 8 Các mô hình trong MDA

1.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

1.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

1.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ể 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

1.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

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

1.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

20

1.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 9)

Như Hình 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

Hình 9 Khả năng tương tác sử dụng cầu nối trong MDA 1.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)

21

1.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

1.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 10

Hình 10 Mối quan hệ giữa các chuẩn OMG

1.6 Một số công cụ trong chuyển đổi mô hình

Ngày nay phát triển hướng mô hình đã được quan tâm và nghiên cứu nhiều hơn, cũng bởi vậy mà nhiều công cụ chuyển đổi mô hình theo hướng tiếp cận MDA ra đời Trong khuôn khổ của luận văn này, tôi xin được đề cập đến một số công cụ phổ biến như sau:

1.6.1 EMF - Eclipse Modeling Framework

Khung mô hình hoá Eclipse (EMF) là một bộ khung sinh mã mã mạnh mẽ hướng đến xây dựng các ứng dụng Java dựa trên định nghĩa các mô hình Nó được thiết kế để tạo các mô hình hoá thiết thực và hữu ích cho các lập trình viên Java EMF là sự thống nhất ba bền tảng quan trọng: Java, XML và UML Mô hình có thể được định nghĩa khi

EMF phần lớn là tương thích MDA với chỉ duy nhất sai lệch nhỏ từ một vài tiêu chuẩn

Ví dụ, nền tảng của ngôn ngữ mô hình meta-model của EMF được biết đến là Ecore Ecore không giống nhưng rất sát với Essential MOF (EMOF) được mô tả trong MOF 2.0 của MDA EMF thường có thể tải một EMOF meta-model, các ánh xạ và chuyển đổi được phát triển giữa EMOF và Ecore

Hình 11 Khung Eclipse Modeling Framework

EMF đi cùng với các cơ chế tiêu chuẩn dùng cho việc xây dựng meta-model và lưu lại chúng như các giao diện có thể lập trình được, cũng như mã nguồn và dữ liệu dạng XML Một khung soạn thảo mô hình (Editor) và khung sinh mã (Generators) cũng được cung cấp (xem Hình 11) EMF được tích hợp chặt chẽ với Eclipse và khả năng tận dụng kiến trúc và cơ sở hạ tầng của Eclipse hỗ trợ việc tích hợp meta-data riêng rẽ, qua nhiều công cụ trong một hệ sinh thái chung ăn theo Eclipse Điều này nâng cao mức độ tương tác giữa các công cụ phần lớn tương thích với MDA

Mô hình được sử dụng để biểu diễn mô hình trong EMF là Ecore Ecore chính là một

mô hình EMF do đó nó vừa là model, vừa là metamodel thậm chí nó còn là meta- metamodel Ecore là thành phần cốt lõi của EMF, Ecore được tạo ra từ một trong ba nguồn: Mô hình UML, lược đồ XML, hoặc ký hiệu Java Interface Hình 12 cho thấy

mô hình Ecore sau khi thực thi bởi Java sẽ sinh ra mô hình đích như đã lựa chọn

23

Hình 12 Mô hình Ecore và nguồn

Do tiêu chuẩn chuyển đổi mô hình vẫn tiếp tục phát triển và các sản phẩm thu nhận được đều từ chính việc sinh mã, nên hầu hết các công cụ hiện tại đều tập trung vào sinh

mã từ mô hình Nhìn chung, trên thị trường các công cụ MDA sử dụng EMF vẫn đang trưởng thành ở cả hai lĩnh vực thương mại cũng như các dự án mã nguồn mở

1.6.2 Atlas Transformation Language - ATL

ALT là một ngôn ngữ sử dụng trong việc chuyển đổi mô hình sang mô hình (M2M) ATL chỉ hỗ trợ cho phép chuyển đổi mô hình theo một hướng Một chương trình chuyển ATL bao gồm các luật chuyển mô tả cách tạo ra các phần tử của mô hình đích Ngôn ngữ được đặc tả như là metamodel và với cú pháp cụ thể dưới dạng ký tự ATL được tích hợp trong môi trường phát triển của Eclipse và có thể làm việc với các mô hình dựa trên EMF Mã nguồn ATL được biên dịch và sau đó được chạy trên máy chuyển mô hình

1.6.3 AndroMDA

AndroMDA là nền tảng mã nguồn mở tương thích MDA, nó có cơ chế cho phép các nền tảng và các thành phần hỗ trợ có thể hoán đổi trong và ngoài bất cứ lúc nào Nó được khai thác nhiều bởi các dự án nguồn mở hiện tại cho cả mục đích xây dựng dịch

vụ phụ thuộc nền (XDoclet cho EJB) và dịch vụ nền tảng chung (Apache Velocity cho việc xây dựng khuôn mẫu chuyển đổi)

Với AndroMDA, lập trình viên có thể mở rộng ngôn ngữ mô hình hoá hiện tại qua các tiện ích như “metafacades” Phần mở rộng được phản ánh qua một UML Profile trong thư viện mô hình hoá và khuôn mẫu trong các công cụ chuyển đổi AndroMDA hỗ trợ chủ yếu việc chuyển đổi từ mô hình sang mã

 Mô hình miền được chuyển đổi tự động sang mô hình ứng dụng (OptimalJ Application Model), tương ứng với PSM trong MDA Miền ứng dụng định nghĩa ứng dụng, dựa trên công nghệ được lựa chọn như J2EE

 Cuối cùng miền ứng dụng được chuyển đổi tự động sang mô hình mã (OptimalJ Code Model) tương ứng với Code/Text trong MDA

1.6.6 QVT - Query/View/Transformation

QVT - Query/View/Transformation là một ngôn ngữ chuẩn cho chuyển mô hình được tạo ra bởi OMG QVT sử dụng ngôn ngữ ràng buộc OCL, MOF và được định hướng theo kiến trúc MDA Cũng giống như cái tên của nó đã thể hiện rõ rằng QVT cho phép thực hiện: Chuyển đổi mô hình (transíormation), biểu diễn mô hình (View) và truy vấn (Query) Truy vấn mô hình và biểu diễn mô hình được xem như một phương pháp đặc biệt của chuyển đổi mô hình QVT cũng được tích hợp trên Eclipse

QVT định nghĩa ba ngôn ngữ trong việc chuyển đổi mô hình tới mô hình (M2M) tuân thủ theo chuẩn MOF 2.0:

 QVT Relational: Là một ngôn ngữ chuyển đổi mô hình khai báo Hai dạng cú pháp được định nghĩa trong QVT là cú pháp dạng ký tự và cú pháp dạng đồ hoạ Ngôn ngữ QVT hỗ trợ chuyển đổi hai chiều Một phép chuyển được đặc tả như

là một tập quan hệ giữa các metamodel nguồn và đích Phép chuyển này cũng

có thể được kiểm tra tính hợp lệ của hai mô hình

 QVT Core: Chính là nền tảng cho ngôn ngữ QVT Relational, nó là một ngông ngữ chuyển đổi mô hình khai báo cấp thấp

 QVT Operational: Là ngôn ngữ chuyển đổi mệnh lệnh, được áp dụng để cho phép chuyển đổi theo một hướng duy nhất

25

1.7 Software Factory của Microsoft

Microsoft giới thiệu SF như một mô hình phát triển phần mềm mới SF chủ yếu tập trung vào phát triển các dòng sản phẩm, cái mà phần lõi được phát triển giống nhau nhưng đáp ứng được cho nhiều sản phẩm khác nhau Khi đó SF phụ thuộc nhiều vào

mô hình và tự động hóa, đó cũng là một điều đáng lưu ý của MDD [1]

Một SF có hai yếu tố trung tâm, một là lược đồ SF (Sofware Fatory Schema) và mẫu

SF (Software Factory Template) Lược đồ SF sẽ xác định, phân loại và tóm lược những yếu tố thiết yếu để xây dựng một dòng sản phẩm phần mềm Nó có thể được xem như

là một công thức ghi tên các thành phần, công cụ và tiến trình của ứng dụng Mẫu SF được dựa trên lược đồ SF và đại diện cho việc thực hiện lược đồ SF, có nghĩa là các yếu tố được xác định phải được xây dựng và thực hiện Việc thực hiện bao gồm các hoạt động phát triển DSLs (Domain-Specific Languages) Mẫu SF có thể được xem như một ngăn chứa, chứa các thành phần được liệt kê bên trong

Một nguyên tắc cốt lõi trong cách tiếp cận SF là cho phép tái sử dụng ở mức cao tài nguyên hiện có và phát triển các tài nguyên tái sử dụng mới Sự phát triển của một thành viên cụ thể của một dòng sản phẩm bao gồm việc tái sử dụng tài nguyên hiện có

và phát triển tài nguyên này bằng cách biến đổi cho thành viên cụ thể đó Cách tiếp cận

SF sử dụng khái niệm về mô hình hoá miền chuyên biệt (Domain-Specific Modeling - DSM), sử dụng các ngôn ngữ miền chuyên biệt (DSLs) để mô hình hóa

1.8 Kết chương

Trong Chương I luận văn đã trình bày tổng quan cơ bản về phát triển phần mềm hướng

mô hình và giới thiệu một số vấn đề chính cũng như các công cụ trong phát triển phần mềm hướng mô hình Những khái niệm được trình bày trong Chương I là những kiến thức nền tảng cơ bản trong phát triển phần mềm hướng mô hình Các tính chất đưa ra

là đặc trưng cho các kỹ thuật tiên tiến trong phát triển phần mềm mà sau đây sẽ xem xét đến

hướng mô hình, cụ thể là Software Factory của Microsoft và Model-Driven

Architecture (MDA) của nhóm quản lý đối tượng (Object Management Group) Trong

cả hai cách tiếp cận phần mềm được thiết kế theo mô hình ở mức độ trừu tượng cao hơn, từ đó code được tạo ra để xây dựng các hệ thống thực tế Tuy nhiên, cả hai phương pháp này sử dụng các phương pháp khác nhau để xác định các mô hình Trường hợp MDA đề xuất UML tạo mô hình, còn SF xây dựng trên ngôn ngữ miền chuyên biệt (Domain-Specific Languages - DSL) Trong thiết kế phần mềm hiện nay chủ yếu dựa trên hai phương pháp này [3]

Bên cạnh MDA và SF còn có các phương pháp khác, ít phổ biến hơn trong phương pháp tiếp cận MDD, cụ thể là Domain-Oriented Programming và Agile Model-Driven Development

2.1 Software Factory

Các yêu cầu ngày càng phức tạp và thay đổi nhanh chóng đang làm cho sự phát triển của công nghệ trở nên ngày càng khó khăn Tuy nhiên, những cải tiến vượt bậc đã được thực hiện bằng các phương pháp khác nhau như kiến trúc dựa trên thành phần và kiến trúc hướng mô hình; kiến trúc phần mềm, lập trình hướng đối tượng, và các yêu cầu, tiến trình và kỹ thuật dòng sản phẩm phần mềm Chúng ta sẽ trình bày về SF, một mô hình tự động phát triển phần mềm tích hợp những cải tiến này để rút ngắn thời gian, tăng năng suất và tính dự báo trong toàn bộ vòng đời của phần mềm Chúng ta sẽ giới thiệu một ví dụ về một SF và thực hiện các bài tập nhóm nhỏ giúp chúng ta hiểu rõ hơn

về cách tiếp cận này Chúng ta sẽ tìm hiểu về lược đồ của SF, một sơ đồ các quan điểm được sử dụng để tách mối quan tâm, các công việc liên quan được thực hiện ở một mức

độ trừu tượng, trong một phần của hệ thống, hoặc trong một giai đoạn của vòng đời;

để làm việc ở các cấp độ khác nhau, hoặc trong các phần khác nhau, các giai đoạn và

về cách lược đồ có thể được sử dụng để đưa ra hướng dẫn và hỗ trợ việc đưa ra các luật thông qua việc chuyển đổi mô hình; kiểm thử hạn chế và các kỹ thuật khác Chúng

27

ta cũng sẽ mô tả vòng đời của SF và cho thấy SF có thể được chuyên môn hóa và sáng tạo như thế nào Cuối cùng, chúng ta sẽ thảo luận về các chuỗi cung ứng phần mềm và cho thấy SF biên soạn qua các ranh giới tổ chức như thế nào

Microsoft đề xuất Software Factory (SF) cho sự phát triển nhanh chóng của một loại hình cụ thể của ứng dụng Với phương pháp này, Microsoft hy vọng sẽ nâng cao năng suất bằng cách chuyển từ sản xuất thủ công sang sản xuất dây truyền trong ngành công nghiệp phần mềm Với sự tập trung vào kinh tế vi mô, nơi mà nhiều sản phẩm đặc thù nhưng được phát triển hàng loạt, họ xây dựng phần mềm dựa trên khái niệm dòng sản phẩm nhằm công nghiệp hóa ngành công nghiệp phần mềm Một dòng sản phẩm phần mềm hỗ trợ phát triển các dòng sản phẩm, về trực quan đó là sự tách rời tính phổ biến

và tính đa dạng Phần lớn các thành viên trong họ sản phẩm thường là tương tự nhau

do đó chúng có thể được tái sử dụng Việc tái sử dụng có thể là các yêu cầu, thiết kế cấu trúc, lập kế hoạch, xây dựng mã, kiểm thử,… Như ta thấy, Software Factory mang

ý nghĩa nhiều về một dòng sản phẩm

Như vậy ta có định nghĩa về SF như sau:

Software Factory là một dòng sản phẩm cái mà cấu hình các công cụ mở rộng, tiến trình và nội dung sử dụng một mẫu SF dựa trên một lược đồ SF để tự động hóa việc phát triển và bảo trì các biến thể của một sản phẩm nguyên mẫu bằng cách thích ứng, lắp ráp và cấu hình các thành phần cơ sở nền tảng [1]

Định nghĩa bao quát này có thể lại mang đến cho ta nhiều câu hỏi Dòng sản phẩm phần mềm là gì? SF mẫu và lược đồ SF là gì? Phần sau chúng ta sẽ trả lời những câu hỏi đó và giải thích như nào MDD được áp dụng để nhận biết SF

2.1.1 SF với các khía cạnh đổi mới

SF được xây dựng dựa trên 3 khía cạnh đổi mới đó là: Tính trừu tượng (Abstraction), tính chi tiết (Granularity) và tính đặc trưng (Specificity) Để đổi mới những vấn đề này,

SF đưa ra cho người dùng hai phương án phát triển, Model-Driven Development (MDD) và Component-based Development (CBD) Chúng ta sẽ nói về vấn đề này trong các phần tiếp theo

Trước hết chúng ta làm rõ một số khái niệm:

Tính trừu tượng (Abstraction): Là một khía cạnh quan trọng của mô hình MDD Ở mức trừu tượng cao hơn, càng có nhiều thông tin chi tiết của hệ thống được bỏ qua trong các mô hình thì càng làm giảm độ phức tạp nhưng thu hẹp phạm vi áp dụng MDD

28

được ứng dụng trong SF để cho mô hình ở mức trừu tượng cao hơn và tạo ra mã nguồn ứng dụng SF không đề xuất UML để mô hình hóa bởi vì nó không cung cấp các yêu cầu cần thiết cho miền chuyên biệt để mô hình hóa Thay vào đó SF sử dụng ngôn ngữ miền chuyên biệt (domain-specific languages) để nâng cao mức độ trừu tượng Tính chi tiết (Granularity) là thước đo kích thước của cấu trúc phần mềm được sử dụng trong khía cạnh trừu tượng Tính chi tiết càng cao, sự hoàn thiện về khả năng tái sử dụng càng lớn hơn, vì thành phần lõi càng thô, càng đóng gói nhiều chức năng hơn so với các thành phần lõi thu gọn, và ít phụ thuộc Lấy ví dụ một công ty chuyên về phát triển phần mềm hệ thống cho các tổ chức cung cấp sản phẩm cho khách hàng Mỗi hệ thống phần mềm phát triển cho tổ chức này có thể bao gồm các chức năng để lưu trữ

và quản lý thông tin khách hàng giống như: Tên khách hàng, địa chỉ thanh toán, số điện thoại, địa chỉ email, Nếu tính chi tiết của các thành phần trong một hệ thống phần mềm thấp, phần code thực hiện các chức năng quản lý khách hàng có khả năng

bị phân tán trên nhiều tập tin mã nguồn của ứng dụng Điều này không cho phép tái sử dụng mã nguồn này trong một ứng dụng khác Tuy nhiên, nếu chúng ta tập hợp tất cả các code liên quan đến quản lý khách hàng trong một thành phần dịch vụ thì chúng ta

có thể có được khả năng tái sử dụng của chức năng này Trong một dự án mới, người phát triển chỉ cần gộp các thành phần quản lý khách hàng để sử dụng chức năng quản

lý khách hàng

Lý tưởng nhất, một nhà phát triển phần mềm tích hợp một số thành phần lõi thô có sẵn

để thành một hệ thống phần mềm mới, từ đó sẽ rút ngắn đáng kể thời gian phát triển của ứng dụng Tuy nhiên, vì mỗi ứng dụng có thể có một số khía cạnh mà không tồn tại trong các thành phần hiện có, các nhà phát triển vẫn sẽ phải viết code cho ứng dụng

cụ thể Điều này cũng giống như việc nhà phát triển phải viết code để liên kết nhiều thành phần với nhau… Tính chi tiết cao được lưu trữ cùng với CBD, một phương pháp phát triển hướng tới sự phát triển độc lập của các thành phần lõi thô để cải thiện khả năng tái sử dụng

Khía cạnh cuối cùng là tính đặc trưng (specificity) trong đó được sắp xếp từ mục đích

chung tới từng miền chuyên biệt Đối với các SF, khía cạnh này có lẽ là khía cạnh quan trọng nhất của sự đổi mới, theo Greenfield và Short [1]: Tính đặc trưng xác định phạm

vi của một khái niệm trừu tượng; phạm vi này càng hẹp hơn, khả năng tái sử dụng càng

29

cao hơn Tuy nhiên, khái niệm trừu tượng với tính đặc trưng cao hơn có thể sử dụng trong hạn chế hơn UML là một ví dụ của một mô hình ngôn ngữ đặt ra mức độ trừu tượng với một phạm vi rộng; nó có thể thiết kế một luồng object-oriented của phần mềm trong một miền có sẵn bất kỳ Tuy nhiên, một DSL đặt ra mục tiêu một miền chuyên biệt SF kế thừa tính đặc trưng cao từ dòng sản phẩm phần mềm, cái mà chúng được xây dựng dựa trên đó

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

Một ngôn ngữ miền chuyên biệt (domain-specific language - DSL) là một ngôn ngữ

lập trình giải quyết cụ thể một vấn đề miền chuyên biệt Một định nghĩa rộng hơn do van Deursen, Klint, và Visser[2]:

Một ngôn ngữ miền chuyên biệt (DSL) là một ngôn ngữ lập trình hoặc thực hiện ngôn ngữ đặc trưng thông qua các ký hiệu thích hợp và trừu tượng, khả năng diễn đạt tập trung, và thường bị hạn chế, một miền chủ yếu

Một ví dụ của DSL là ngôn ngữ truy vấn có cấu trúc (SQL) thường được áp dụng để lấy, lưu trữ, cập nhật và xóa dữ liệu trong một cơ sở dữ liệu quan hệ SQL là một DSL

vì nó hướng vào một vấn đề miền chuyên biệt - quản lý dữ liệu trong một cơ sở dữ liệu

Một ví dụ về một DSL đồ họa là người xây dựng hình thức trong Visual Studio của Microsoft để phát triển các giao diện đồ họa người dùng cho các ứng dụng NET Chức năng kéo và thả cho phép bạn nhanh chóng xác định vị trí điều khiển trong một mẫu Các tính năng khác của bộ điều khiển được hiển thị trong một danh sách và có thể được thay đổi nếu cần thiết Đằng sau hậu trường, Visual Studio tạo ra các code cần thiết để tạo ra khuôn dạng trong thời gian thực Rõ ràng là tính năng này làm việc nhanh hơn rất nhiều so với định vị điều khiển bằng cách thiết lập thuộc tính vị trí trong code bằng tay và chạy các ứng dụng để xem kết quả

DSL trong và ngoài: DSL ngoài là ngôn ngữ viết bằng một ngôn ngữ khác với ngôn

ngữ của ứng dụng chính, trái ngược với DSL nội bộ được viết bằng cùng ngôn ngữ như mã nguồn của ứng dụng chính Ví dụ về các DSL bên ngoài là Little Languages trong Unix và các tập tin cấu hình XML thường được sử dụng trong các dự án Java và NET DSL nội bộ có thể được tạo ra trong mọi ngôn ngữ lập trình Có một số vấn đề

30

ảnh hưởng đến sự lựa chọn giữa một DSL trong và ngoài Bây giờ chúng ta thảo luận

về kết quả của lựa chọn một trong hai loại DSL

Sử dụng một DSL ngoài trong SF đòi hỏi bạn phải thiết kế cú pháp và ngữ nghĩa của

nó, và viết một trình thông dịch phân tích và thực thi mã lệnh trong DSL Đây chính là một lợi thế về tự do thiết kế của ngôn ngữ, nhưng khả năng để viết trình thông dịch cho ngôn ngữ này là bắt buộc Phép phân tích cú pháp có thể được hỗ trợ trong quá trình tạo ra một phân tích cú pháp, nhưng ngay cả với sự hỗ trợ này, đây là một nhiệm

vụ phức tạp DSL càng phức tạp hơn, càng khó khăn hơn để viết một phân tích cú pháp cho ngôn ngữ Trong một số trường hợp điều này là dễ dàng hơn Với DSL dựa trên XML, bạn có thể sử dụng các chức năng xử lý XML có sẵn trong hầu hết các ngôn ngữ cùng mục đích chung Tuy nhiên, điều này hạn chế trong tự do thiết kế của ngôn ngữ,

vì ký hiệu thẻ được sử dụng bởi XML là không thể tránh khỏi Trong cả hai trường hợp, cần viết một trình thông dịch cho DSL, và cho dù đơn giản hay không, điều này

có nghĩa là nhiều việc cần phải làm hơn và đó cũng là một điều bất lợi

Viết một ngôn ngữ mới từ đầu có nhiều hệ quả Đầu tiên liên quan đến việc thiết kế của các cú pháp và ngữ nghĩa của ngôn ngữ Mặc dù DSL có nghĩa là đơn giản và toàn diện, rất khó để viết một DSL đáp ứng các đặc tính này mà khống mất khả năng diễn đạt và tính đặc trưng của nó Thứ hai, không có công cụ cho các ngôn ngữ mới Đối với văn bản mã nguồn, các nhà phát triển ít nhất là mong đợi làm nổi bật cú pháp, các màu của các yếu tố ngôn ngữ, như từ khóa của một biên tập viên Ngày nay người ta thường sử dụng một môi trường phát triển tích hợp (IDE) cho phát triển phần mềm Tiếp theo làm nổi bật cú pháp, các ứng dụng này thường hỗ trợ tái cấu trúc, chỉnh sửa ngữ nghĩa - giống như tự động hiển thị một danh sách các phương pháp có sẵn của một đối tượng khi bạn gõ kí hiệu '.' trong Visual Studio IDE và gỡ lỗi Những công cụ này không có sẵn cho một thiết kế ngôn ngữ mới và rất khó để phát triển Cuối cùng, các nhà phát triển phải học thêm một ngôn ngữ Tuy nhiên, do DSL có nghĩa là đơn giản nên điều bất lợi cuối cùng này không phải là vấn đề lớn

Vấn đề cuối cùng được trình bày bởi Fowler [3] có liên quan đến việc đánh giá code được viết trong DSL Vì DSL trong được viết bằng ngôn ngữ lập trình giống như ứng dụng chính, chúng thường được biên soạn cùng với các tập tin nguồn khác Vì vậy, đánh giá diễn ra tại thời gian biên dịch DSL ngoài có thể được đánh giá tại thời gian biên dịch

31

hoặc theo thời gian thực Trong trường hợp đầu tiên một biên dịch chuyển mã DSL để viết code trong một ngôn ngữ với mục đích chung, sau đó được biên dịch thành một hệ thống có thể thực thi Khi đánh giá theo thời gian thực, không cần phải biên dịch lại toàn

bộ hệ thống nếu có thay đổi được thực hiện cho code viết bằng DSL Hãy nghĩ về cấu hình XML file, ví dụ, một dự án NET Nếu một tham số cấu hình trong tập tin cấu hình được thay đổi, không cần thiết phải biên dịch lại hệ thống để áp dụng những thay đổi trong cấu hình của hệ thống; chỉ chạy lại ứng dụng một lần nữa là đủ

Hình 13 Khái niệm một dòng sản phẩm phần mềm

Thật khó để nói rằng cách tiếp cận này tốt hơn cách tiếp cận kia Sự lựa chọn giữa DSL trong và DSL ngoài phụ thuộc nhiều vào tình hình thực tế Nếu thời gian là có hạn, phát triển một DSL ngoài có thể không phải là một lựa chọn tốt, vì điều này đòi hỏi nhiều thời gian hơn thực hiện một DSL trong Tuy nhiên, nếu thời gian không phải là một vấn đề và các kỹ năng để phát triển, phân tích cú pháp cho một DSL ngoài có sẵn, rất đáng để thiết kế một DSL tùy chỉnh

2.1.3 Software Factory làm việc như thế nào?

Từ khi SF được xác định là dòng sản phẩm hướng mô hình, thì đầu tiên ta phải giải thích các dòng sản phẩm phần mềm là gì, trước khi chúng ta đi sâu vào cách SF làm việc Một dòng sản phẩm phần mềm thường sử dụng để tạo ra các thành viên của một

họ sản phẩm trong hệ thống phần mềm Hệ thống phần mềm trong một họ như vậy có chung các tính năng phổ biến, nhưng không hoàn toàn giống nhau Dòng sản phẩm tận dụng lợi thế của tính tương đồng và tính đa dạng

Một dòng sản phẩm bao gồm bốn khái niệm cơ bản, như trình bày trong Hình 11 Dòng

Sản phẩm cần đầu vào dưới hình thức một tập hợp các tài nguyên phần mềm (software

assets) Những tài nguyên này là yêu cầu, thành phần, các trường hợp kiểm thử và nền

tảng,… Từ khi chúng ta làm việc với họ sản phẩm, tài nguyên phải được cấu hình để

Product Decisions

Software Asset Inputs

Production Process

Software Product Outputs

32

cho phép sự sáng tạo của tất cả các sản phẩm trong họ này Một mô hình ra quyết định

(decision model) mô tả tính đa dạng giữa các sản phẩm trong dòng sản phẩm Đối với

mỗi thay đổi trong mô hình ra quyết định, một quyết định - được gọi là quyết định sản

phẩm (product decision) phải được thực hiện Mỗi sản phẩm trong dòng sản phẩm

được xác định duy nhất bởi các quyết định sản phẩm của mình Các cấu hình thực tế của tài nguyên phần mềm dựa trên các quyết định sản phẩm được gọi là cơ chế sản xuất (production mechanism) Kết quả của cơ chế sản xuất là một thành viên cụ thể của họ sản phẩm được hỗ trợ bởi dòng sản phẩm

Như vậy chúng ta biết các yếu tố cần thiết để các dòng sản phẩm phần mềm làm việc như thế nào, chúng ta có thể tập trung vào SF SF dựa trên ba ý tưởng chính: lược đồ

SF (software factory schema), mẫu SF (software factory template), IDE mở rộng (extensible IDE) Trong đó mẫu SF là một kho dữ liệu mẫu cho quá trình phát triển

phần mềm; sơ đồ SF sẽ liệt kê một số phần hạng mục như: thư mục mã nguồn, các tập tin cấu hình cần thiết để sản xuất một thành viên của một họ sản phẩm Nó cũng mô tả việc DSL được sử dụng và làm thế nào các mô hình thiết kế với những DSL được chuyển thành code, hoặc các mô hình ở một mức độ trừu tượng thấp hơn Các mẫu SF chứa các mục quy định trong lược đồ SF Các đề mục trong các mẫu được sử dụng để xây dựng các thành viên của một họ sản phẩm; ví dụ như patterns, templates, frameworks, visual DSL editing tools, scripts và style sheets Cuối cùng, các thành phần này được kết hợp với nhau và các kết quả của chúng có thể được so sánh với các IDE mở rộng Tổng quan về các SF được đưa ra trong Hình 12

Hình 14 Tổng quan của Software Factory

Product Line

Schema Software

Template

Software Factory

Product Developer

Family Member

builds & users

builds

load into IDE

users

builds

33

Nếu chúng ta nhìn vào các mô tả của các dòng sản phẩm phần mềm và SF đưa ra ở trên, chúng ta thấy rất nhiều điểm tương đồng và một số khác biệt Cả hai dòng sản phẩm và các SF sử dụng tài nguyên cấu hình phần mềm để tạo ra một sản phẩm cụ thể trong họ của các sản phẩm Sự khác biệt nằm ở cách các tài nguyên này được cấu hình Dòng sản phẩm phần mềm không chỉ định cách cấu hình các tài nguyên phần mềm được thực hiện Trong một SF, DSL nhúng được sử dụng để cấu hình các tài nguyên được định nghĩa trong lược đồ SF Lược đồ này tương ứng với mô hình ra quyết định cho các dòng sản phẩm, nhưng sản phẩm quyết định trong SF được thực hiện theo cách tiếp cận hướng mô hình Đây là lý do tại sao các SF được định nghĩa là dòng sản phẩm hướng mô hình

SF là một dòng sản phẩm phần mềm cấu hình các công cụ, quy trình và nội dung mở rộng, sử dụng một khuôn mẫu sản phẩm phần mềm dựa trên lược đồ SF để tự động phát triển và duy trì các biến thể của một sản phẩm archetypical bằng cách thích ứng, lắp ráp và cấu hình các thành phần dựa trên khuôn khổ

SF có hai yếu tố trung tâm, một là lược đồ SF và hai là mẫu SF Một lược đồ SF xác định, phân loại và tóm tắt các hiện vật và tài nguyên cần thiết để xây dựng một dòng sản phẩm phần mềm Nó có thể được xem như là một công thức liệt kê thành phần, công cụ và tiến trình ứng dụng Một mẫu SF được dựa trên biểu đồ SF và đại diện cho việc thực hiện biểu đồ SF có nghĩa là tất cả tài nguyên được xác định và hiện vật phải được xây dựng và sẵn có Việc thực hiện bao gồm các hoạt động phát triển DSLs Mẫu

SF có thể được xem như một bộ dữ liệu chứa các thành phần được liệt kê trong công thức

2.1.4 Software Factory Schema[4]

Một lược đồ SF là một tài liệu phân loại và tóm tắt các thao tác được sử dụng để xây dựng và duy trì một hệ thống, chẳng hạn như các tài liệu XML, các mô hình, các tệp cấu hình, các kịch bản xây dựng, các tệp mã nguồn, tệp SQL, tệp bản địa hóa, tài liệu phát triển và định nghĩa các trường hợp thử nghiệm, một cách có trật tự, và xác định mối quan hệ giữa chúng, để chúng ta có thể duy trì tính nhất quán

Một lược đồ SF được biểu diễn dưới dạng đồ thị trực tiếp mà các nút là các điểm quan sát và các cạnh của nó là các quan hệ tính toán giữa các điểm được gọi là ánh xạ Điều

34

này cho phép các nút không lân cận nhau trong một biểu diễn lưới là có liên quan Ngoài ra, nó làm giảm sự ràng buộc nhân tạo do một mạng lưới mà các quan điểm phải phù hợp với các sơ đồ phân loại gọn gàng, tạo ra hàng và cột Cuối cùng, và quan trọng nhất, nó cho phép lược đồ phản ánh kiến trúc phần mềm Ví dụ, một giản đồ cho một

họ sản phẩm ứng dụng kinh doanh có thể chứa nhiều cụm quan điểm, một cho mỗi hệ thống con như quản lý khách hàng, quản lý danh mục, hoặc thực hiện đơn hàng Các quan điểm trong mỗi cụm có thể sau đó được nhóm lại thành các tập hợp con phản ánh kiến trúc lớp của mỗi hệ thống con

Hình 15 Kiến trúc Software Factory

Một lược đồ SF mô tả các hiện vật bao gồm một sản phẩm phần mềm, giống như một lược đồ XML mô tả các phần tử và thuộc tính bao gồm một tài liệu và một giản đồ cơ

sở dữ liệu mô tả các hàng và cột chứa cơ sở dữ liệu Giống như Architectural Description Standard (ADS), một giản đồ SF là một khuôn mẫu để mô tả các thành viên của một họ sản phẩm phần mềm Mặc dù có sự giống nhau này, tuy nhiên có một

số khác biệt lớn giữa một lược đồ SF và ADS:

Trong khi ADS chỉ đề cập đến kiến trúc, lược đồ SF đề cập đến nhiều khía cạnh khác của họ sản phẩm phần mềm, chẳng hạn như yêu cầu, thực thi, mã nguồn, kiểm thử khai

để thể hiện cách các thành viên trong họ khác với kiểu mẫu họ Mặt khác, một giản đồ

SF nhắm tới một họ sản phẩm phần mềm cụ thể và có thể được tạo ra và tùy chỉnh để

mô tả một thành viên trong dòng cụ thể về sự khác biệt so với họ mẫu

Trong khi một ADS không nhất thiết hỗ trợ tự động hóa, một giản đồ SF có thể được thực hiện bằng một khuôn mẫu SF để tự động hoá các nhiệm vụ phát triển phần mềm Tất nhiên, tài nguyên thiết yếu của một giản đồ SF là nó cung cấp sự tách rời nhiều chiều của các mối quan tâm dựa trên các khía cạnh khác nhau của các hiện vật được tổ chức, như mức độ trừu tượng, vị trí trong kiến trúc, chức năng hoặc các tính năng hoạt động

Chúng ta có thể phân tích miền ứng dụng bằng cách sử dụng các nguyên tắc phổ biến

và biến thể để chia thành các lĩnh vực phụ, mỗi trong số đó có thể thích hợp cho việc thiết kế theo một mô hình cụ thể

Bây giờ chúng ta có thể thấy lưới là một phép chiếu hai chiều của đồ thị vẽ một hoặc nhiều khía cạnh trên trục ngang và các mức trừu tượng khác nhau trên trục thẳng đứng Một phép chiếu hai chiều khác là một mặt phẳng khía cạnh, đưa các quan điểm liên quan vào một phần của kiến trúc sản phẩm, cung cấp một cái nhìn tổng hợp từ quan điểm đó

Một lược đồ SF cơ bản định nghĩa một công thức để xây dựng thành viên của một họ sản phẩm phần mềm Rõ ràng, các quan điểm mô tả các thành phần và các công cụ được sử dụng để chuẩn bị cho chúng, nhưng đâu là quá trình chuẩn bị chúng mô tả? Nhớ lại rằng một khuôn khổ quá trình được xây dựng bằng cách gắn một quy trình vi

mô cho mỗi quan điểm, mô tả sự phát triển của các khung nhìn phù hợp và bằng cách xác định các ràng buộc như điều kiện tiên quyết cần phải thỏa mãn trước khi tạo ra một khung nhìn, sau điều kiện phải được thỏa mãn sau khi nó được sản xuất, và các biến thể bất biến phải giữ khi các quan điểm đã ổn định Khung này định nghĩa không gian

2.1.5 Software Factory Templates

Như Greenfield nói[4]: "Nếu tất cả chúng ta có giản đồ SF, thì chúng ta có thể mô tả các tài nguyên được sử dụng để xây dựng các thành viên trong họ, nhưng chúng ta thực

sự không có tài nguyên Trước khi chúng ta có thể xây dựng bất kỳ thành viên họ sản phẩm nào, chúng ta phải thực hiện lược đồ SF; định nghĩa DSL, mẫu, khuôn khổ và các công cụ mà họ mô tả, đóng gói và cung cấp cho các nhà phát triển sản phẩm Nói chung, các tài nguyên này tạo thành mẫu SF

Một mẫu SF bao gồm mã và siêu dữ liệu có thể được tải vào các công cụ có thể mở rộng, như Môi trường phát triển tương tác (Interactive Development Environment-IDE) hoặc bộ công cụ vòng đời doanh nghiệp để tự động phát triển và duy trì các thành viên trong sản phẩm Chúng tôi gọi nó là một mẫu SF vì nó cấu hình các công cụ để sản xuất một loại phần mềm cụ thể, giống như một mẫu tài liệu được tải vào một công

cụ như Microsoft Word hoặc Excel cấu hình nó để sản xuất một loại tài liệu cụ thể "

2.1.6 Tái sử dụng có hệ thống

Một trong những tiến bộ quan trọng nhất trong phát triển phần mềm là xác định một

họ sản phẩm phần mềm, có thành viên khác nhau, trong khi chia sẻ nhiều tính năng chung Một họ sản phẩm phần mềm cung cấp một bối cảnh, trong đó các vấn đề phổ biến cho các thành viên trong họ sản phẩm đó có thể được giải quyết chung Điều này cho phép tiếp cận có hệ thống hơn để tái sử dụng bằng cách cho phép ta xác định và phân biệt giữa các tính năng không thay đổi nhiều so với nhiều sản phẩm và những sản phẩm khác nhau Một họ sản phẩm phần mềm có thể bao gồm các thành phần hoặc toàn bộ sản phẩm