Báo cáo tóm tắt Đề tài Nghiên cứu giải pháp chuyển đổi trạng thái áp dụng trong quy trình phát triển phần mềm thích nghi

ĐẠI HỌC ĐÀ NẴNG  
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ  
TRUYỀN THÔNG VIỆT - HÀN  
BÁO CÁO TÓM TẮT  
ĐỀ TÀI KHOA HỌC VÀ CÔNG NGHỆ CẤP ĐẠI HỌC ĐÀ NẴNG  
NGHIÊN CỨU GIẢI PHÁP CHUYỂN ĐỔI TRẠNG THÁI ÁP DỤNG  
TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM THÍCH NGHI  
Mã số: B2018-ĐN07-03  
Chủ nhiệm đề tài: TS. Huỳnh Ngọc Thọ  
Đà Nẵng, 09/2020  
Danh sách thành viên  
Đơn vị công tác và  
lĩnh vực chuyên môn  
Nội dung nghiên cứu  
cụ thể được giao  
TT  
Họ và tên  
Trường ĐH Công nghệ Thông tin và  
Truyền thông Việt - Hàn, Chuyên  
ngành Công nghệ Thông tin  
1
Huỳnh Ngọc Thọ  
Chủ nhiệm đề tài  
Trường ĐH Công nghệ Thông tin và  
Truyền thông Việt - Hàn, Chuyên  
ngành Công nghệ Thông tin  
2
3
Nguyễn Văn Bình  
Nguyễn Anh Tuấn  
Tham gia nghiên cứu  
Khoa CNTT&TT – ĐH Đà Nẵng,  
Chuyên ngành Công nghệ Thông tin  
Thư ký khoa học  
1
ĐAI HỌC ĐÀ NẴNG  
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG  
VIỆT - HÀN  
THÔNG TIN KẾT QUẢ NGHIÊN CỨU  
1. Thông tin chung:  
- Tên đề tài: NGHIÊN CỨU GIẢI PHÁP CHUYỂN ĐỔI TRẠNG THÁI ÁP DỤNG  
TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM THÍCH NGHI  
- Mã số: B2018-ĐN07-03  
- Chủ nhiệm : TS. Huỳnh Ngọc Thọ  
- Thành viên tham gia: ThS. Nguyễn Văn Bình, ThS. Nguyễn Anh Tuấn  
- Cơ quan chủ trì: Đại học Đà Nẵng  
- Thời gian thực hiện: 24 tháng  
2. Mục tiêu:  
Đề xuất giải pháp chuyển đổi trạng thái tích hợp trong quá trình phát triển  
phần mềm. Giải pháp này bao gồm các mô hình chuyển đổi trạng thái áp dụng trong  
giai đoạn thiết kế. Mô hình đó sử dụng lại trong các giai đoạn tiếp theo của quá trình  
phát triển phần mềm hướng đến việc sinh tự động các module hỗ trợ cho việc chuyển  
đổi trạng thái khi thực hiện việc thay đổi cấu hình trong tương lai.  
3. Tính mới và sáng tạo:  
Đề tài đã có một số đóng góp trong lĩnh vực nghiên cứu về chuyển đổi trạng  
thái áp dụng trong quy trình phát triển phần mềm thích nghi:  
- Đề xuất mô hình đặc tả trạng thái để ứng dụng trong quy trình phát triển  
phần mềm thích nghi. Mô hình này được áp dụng trong giai đoạn thiết kế và được sử  
dụng trọng giai đoạn trong các giai đoạn sau của phần mềm.  
- Đề xuất cơ chế chuyển đổi trạng thái áp dụng mô hình chuyển đổi trên trong  
quá trình thích nghi của hệ thống phần mềm.  
4. Tóm tắt kết quả nghiên cứu:  
Kết quả đạt được của nghiên cứu vượt mức so với đăng ký được nêu trong  
thuyết minh, cụ thể trong khuôn khổ của nghiên cứu này đã công bố được 06 bài báo  
trong đó có 04 bài báo quốc tế và 02 bài báo trong nước. Trong số 04 bài báo quốc tế  
có 01 bài báo trong tạp chí xếp hạng Q2, 03 bài báo trong danh mục ISI/Scopus.  
5. Tên sản phẩm:  
- Sản phẩm khoa học:  
Bài báo quốc tế:  
o Bài báo trong tạp chí Q2:  
2
DA NANG UNIVERSITY  
VIET-HAN UNIVERSITY OF INFORMATION AND COMMUNICATION  
TECHNOLOGY  
INFORMATIONS ON RESEARCH RESULTS  
1. General information  
- Project title: RESEARCH SOLUTIONS FOR STATE TRANSFER  
APPLIED IN ADAPTIVE SOFTWARE DEVELOPMENT PROCESS  
- Code number: B2018-ĐN07-03  
- Project leader: Dr. Huỳnh Ngọc Thọ  
- Coordinator: ThS. Nguyễn Văn Bình, ThS. Nguyễn Anh Tuấn  
- Implementing institution: Danang University  
- Duration: 24 months  
2. Objectives  
The objectives of this project is to propose a solution for state transfer applied  
in adaptive software development process. This solution includes state transfer model  
applied in the design phase. The model is reused in the next stages of the software  
development process towards the generation of modules that support state transfer in  
adaptive software.  
3. Creativeness and innovativeness  
Some research results of this project contribute to the state transfer research  
domain with the creativeness and innovativeness as follows:  
- Proposing a state transfer model applied in adaptive software development  
process. This model is used in the design phase and reused in the next phase of  
software development.  
- Proposing a state transfer mechanism by using the state transfer model to  
realize adaptation actions during adaptation process.  
4. Research results  
The obtained results well match the project proposal, namely the framework  
of this projectm there have been 06 articles published including 04 international  
articles (1 article in a journal Q2, 03 articles indexed in ISI /Scopus lists) and 02  
national articles.  
5. Research products  
- Research products  
International papers:  
o 01 paper in a journal Q2:  
4
. Huynh Ngoc-Tho, Towards Automatically Generating State  
Transfer Model Integrated in Adaptive Software Development  
Process, International Journal of Applied Engineering Research  
(Q2), Volume 15, Number 02, 2020.  
o 03 papers indexed in ISI/Scopus list  
. Huynh Ngoc-Tho, State Transfer Management in Adaptive  
Software: An Approach from Design to Runtime, The 2019  
IEEE-RIVF International Conference on Computing and  
Communication Technologies, 2019.  
. Huynh Ngoc-Tho, An Analysis View of Component-Based  
Software Architecture Reconfiguration, The 2019 IEEE-RIVF  
International Conference on Computing and Communication  
Technologies, 2019.  
. Ngoc-Tho Huynh, Maria Teresa Segarra, Antoine Beugnard,  
Building Adaptive Software Architectures with Useful and  
Available Elements for Adaptation, The 2018 10th International  
Conference on Knowledge and Systems Engineering (KSE),  
2018.  
National papers:  
o Huynh Ngoc Tho, Duong Thi Mai Nga, and Huynh Cong Phap,  
Research Challenges for State Transfer in Adaptive Systems, Hội thảo  
Khoa học Quốc gia CITA2019  
o Ngoc-Tho Huynh, Anh-Tuan Nguyen, and Cong-Phap Huynh, Towards  
a State Transfer Model Applied in Adaptive Software Development,  
Hội thảo Khoa học Quốc gia CITA2018.  
- Other products:  
State transfer management model  
A final report  
6. Effects, transfer alternatives of research and applicability  
This research project has good scientific significant and applicabilities in  
adaptive software development.  
5
Mở đầu  
Các hệ thống phần mềm ngày càng mở rộng và “thông minh” hơn với nhiều  
tính năng mới, trong đó khả năng thích nghi của phần mềm là một tính năng quan  
trọng. Tính thích nghi của phần được thể hiện thông qua việc thay đổi cấu trúc và  
hành vi của phần mềm để thích ứng với sự thay đổi của môi trường hoạt động của nó  
(như thay đổi băng thông, chất lượng dịch vụ, vv) mà không dừng hoạt động của toàn  
hệ thống phần mềm. Trong công nghệ phần mềm hướng thành phần, việc thay đổi  
cấu trúc và hành vi của phần mềm được thực hiện bằng cách thay đổi các thành phần  
của hệ thống phần mềm (một hoặc nhiều thành phần bị loại bỏ, một hoặc nhiều thành  
phần mới được thêm vào).  
Việc thay thế một thành phần của hệ thống bởi thành phần khác trong khi phần  
còn lại của hệ thống đang chạy phải đảm bảo được tính toàn vẹn của hệ thống, nghĩa  
là việc thay đổi thành phần phần mềm không gây ra lỗi hệ thống, hoặc mất dữ liệu.  
Để làm được điều đó, trạng thái của thành phần bị loại bỏ phải được di trú sang thành  
phần mới. Các giải pháp tồn tại cung cấp một số cơ chế chuyển đổi trạng thái. Tuy  
nhiên, các cơ chế này chỉ được thực hiện trong giai đoạn cuối của chu trình phát triển  
phần mềm không quan tâm đến các giai đoạn sớm hơn. Điều này gây ra những khó  
khăn nhất định khi phát triển phần mềm thích nghi. Chính vì vậy đề tài này đề xuất  
một giải pháp chuyển đổi trạng thái trong các hệ thống phần mềm được áp dụng  
trong quy trình phảt triển phần mềm từ thiết kế đến khi triển khai thực hiện.  
Mục tiêu của đề tài là đề xuất giải pháp chuyển đổi trạng thái tích hợp trong  
quá trình phát triển phần mềm. Giải pháp này bao gồm các mô hình chuyển đổi trạng  
thái áp dụng trong giai đoạn thiết kế. Mô hình đó sử dụng lại trong các giai đoạn tiếp  
theo của quá trình phát triển phần mềm hướng đến việc sinh tự động các module hỗ  
trợ cho việc chuyển đổi trạng thái khi thực hiện việc thay đổi cấu hình trong tương  
lai.  
Đề tài tập trung vào các đối tượng gồm: Hệ thống phần mềm thích nghi, quy  
trình phát triển phần mềm thích nghi, cơ chế chuyển đổi trạng thái. Phạm vi nghiên  
cứu của đề tài tập trung vào việc chuyển đổi trạng thái cục bộ từ thành phần được  
thay thế đến thành phần thay thế trong hệ thống phần mềm.  
Cách tiếp cận chuyển đổi trạng thái chỉ được quan tâm ở các giai đoạn cuối  
trong chu trình phát triển phần mềm, chẳng hạn như trong giai đoạn implementation,  
lập trình viên xây dựng các module bổ sung cho phép đọc và ghi trạng thái. Một cơ  
chế thay đổi cấu hình được triển khai độc lập để điều khiển việc đọc/ghi trạng thái.  
Chúng tôi cũng dựa trên cách tiếp cận này, nhưng chúng tôi đặt mối quan tâm này ở  
các giai đoạn sớm hơn trong chu trình phát triển phần mềm, và đề xuất các mô hình  
6
thiết kế hỗ trợ yêu cầu này. Quá trình nghiên cứu của đề tài được chia thành hai giai  
đoạn chính: 1) nghiên cứu tổng quan các công việc liên quan đến đề tài, đánh giá, và  
xác định các vấn đề còn tồn tại; 2) Đề xuất giải pháp để giải quyết vấn đề dựa trên  
một ví dụ minh hoạ cụ thể.  
Báo cáo tổng kết đề tài này được chia làm 4 chương: Chương 1 trình bày  
nghiên cứu tổng quan về lĩnh vực liên quan của đề tài; Chương 2 trình bày một mô  
hình phát triển phần mềm thích nghi; Chương 3 trình bày giải pháp chuyển đổi trạng  
thái áp dụng trong quy trình phát triển phần mềm thích nghi; Chương 4 nêu những  
kết luận và hướng phát triển trong tương lai của đề tài.  
Chương 1. Nghiên cứu tổng quan  
1.1. Phát triển phần mềm  
Phần này giới thiệu tóm tắt hai phương pháp phát triển phần mềm gồm Công  
nghệ phần mềm dựa trên mô hình đặc tả (model) (Model-Driven Engineering -  
MDE), và công nghệ phần mềm hướng dòng sản phẩm (Software product line  
engineering – SPLE). Công nghệ phần mềm hướng mô hình tập trung vào thiết kế  
mô hình kiến trúc chung của hệ thống (Model Driven Architecture - MDA) và mô  
hình đặc tả cụ thể (Domain Specific modeling – DSM) của sản phẩm. Trong khi đó,  
phương pháp phát triển hướng dòng sản phẩm tập trung vào các tiến trình con (đặc tả  
nhóm sản phẩm và cấu hình sản phẩm cụ thể) và các kỹ thuật để quản lý các đặc tính  
khác nhau của các sản phẩm thuộc dòng sản phẩm. Việc quản lý các đặc tính khác  
nhau cho phép dễ dàng cấu hình sản phẩm cụ thể.  
1.2. Đặc tả phần mềm bằng CVL  
Trong phần này, chúng tôi sẽ giới thiệu những định nghĩa chính của CVL để  
đặc tả tính năng chung và những tính năng khác nhau của một dòng sản phẩm. CVL  
cung cấp một ngôn ngữ đặc tả và đồng thời cũng cung cấp một giải pháp để phát  
triển dòng sản phẩm. Tông quan về CVL được biểu diễn như Error! Reference  
source not found.. Với cách tiếp cận CVL, ba mô hình được định nghĩa gồm: mô  
hình cơ sở (base model) được sử dụng để mô tả các thành phần trong kiến trúc của hệ  
thống; mô hình biến đổi (variability model) được sử dụng để mô tả khả năng biến đổi  
trong mô hình cơ sở, ví dụ như các phiên bản khác nhau có thể có của một thành  
phần trong mô hình cơ sở; và mô hình giải pháp (resolution model) biểu diễn một cấu  
hình của sản phẩm, có nghĩa là từ mô hình này các thành phần trong mô hình biến  
đổi có thể được chọn. Trong báo cáo này chúng tôi dùng khái niệm mô hình CVL để  
nói về ba mô hình: mô hình cơ sở, mô hình biến đổi và mô hình giải pháp.  
1.3. Kiến trúc phần mềm  
Không có một định nghĩa chung về kiến trúc phần mềm được công nhận bởi  
cộng đồng các nhà nghiên cứu và phát triển. Như định nghĩa:  
Software architecture = {Elements, Form, Rationale}  
7
Điều này có nghĩa là kiến trúc phần mềm là tập hợp các thành phần mà có một  
dạng (form) riêng. Những thành phần này được phân thành 3 loại: thành phần xử lý,  
thành phần dữ liệu và thành phần kết nối. Thành phần xử lý và dữ liệu có thể được  
gọi chung là thành phần của kiến trúc (component). Rationale biểu diễn nguyên nhân  
hay lý do chọn các thành phần này khi cấu hình hệ thống.  
Trong nghiên cứu này chúng tôi xem xét, kiến trúc của hệ thống gồm: thành  
phần (component) và kết nối (connector).  
1.4. Phần mềm thích nghi  
Phần mềm thích nghi là khả năng thích ứng với sự thay đổi của môi trường  
hoạt động. Môi trường hoạt động bao gồm tât cả mọi thứ xung quanh phần mềm như  
người dùng cuối, thiết bị, phần cứng, vv. Khi môi trường hoạt động thay đổi, hệ  
thống cần được điều chỉnh để đáp ứng yêu cầu mới. Quá trình điều chỉnh như vậy sẽ  
là phần mềm chuyển từ phiên bản hiện tại sang một phiên bản mới.  
Đặc trưng của quá trình thích nghi là thời điểm thực hiện việc thay đổi. Dựa  
vào thời điểm thay đổi trong quá trình phát triển, hai kiểu thích nghi có thể được xác  
định: thích nghi tĩnh và thích nghi động. Thích nghi tĩnh là quá trình thay đổi hệ  
thống trong quá trình thiết kế hoặc trong thời gian phát triển. Thích nghi động là quá  
trình làm thay đổi ứng dụng trong quá trình thực thi nhằm giảm thời gian ngắt quảng  
quá trình hoạt động của hệ thống.  
Trong nghiên cứu này, chúng tôi tập trung vào nghiên cứu việc thích nghi  
động của phần mềm. Một trong những vấn đề của thích nghi động là đảm bảo sự hoạt  
động thông suốt của hệ thống và tính chính xác trước và sau khi quá trình thực hiện  
việc thay đổi. Trạng thái, dữ liệu trước và sau quá trình thay đổi được bảo toàn. Vấn  
đề này liên quan đến việc chuyển đổi trạng thái của phần mềm trong quá trình thực  
hiện việc thay đổi.  
1.5. Tổng quan chuyển đổi trạng thái trong phần mềm thích nghi  
Phần lớn các cách tiếp cập chuyển đổi trạng thái trong phần mềm thích nghi dựa  
vào tính tương đồng về trạng thái của thành phần thay thế và bị thay thế và sử dụng  
cơ chế đọc/ghi để chuyển đổi dữ liệu giữa hai thành phần. Nhiều nghiên cứu đã định  
nghĩa hàm chuyển đổi trạng thái giữa thành phần thay thế và bị thay thế. Hàm này  
ánh xạ trạng thái giữa hai thành phần. Tuy nhiên hàm này được kỹ sư định nghĩa cụ  
thể trước khi áp dụng vào trong quy trình thay đổi các thành phần. Để truy cập đến  
trạng thái của các thành phần đang chạy, hệ thống phải cung cấp các chức năng  
(interface) setVar() và getVar() để lấy và thiết lập dữ liệu.  
Chuyển đổi trạng thái đóng vai trò quan trọng trong quá trình thay đổi cấu  
hình của hệ thống để thích nghi với môi trường mới. Việc chuyển đổi trạng thái giúp  
hệ thống hoạt động chính xác và tin cậy trước và sau khi khi thay đổi cấu hình. Nhiều  
các tiếp cận khác nhau quan tâm đến vấn đề này. Giải pháp đơn giản nhất được nhiều  
tác giả quan tâm là xem xét tính tương đồng trạng thái giữa hai thành phần và từ đó  
xây dựng các chức năng cho phép đọc và ghi thông tin trạng thái. Trong trường hợp  
8
không có sự đồng nhất giữa các cấu hình việc chuyển đổi như trên sẽ gây ra lỗi dữ  
liệu, .. Chính vì thế một giải pháp khác đề nghị sử dụng các đơn vị chuyển đổi trung  
gian như mạng chuyển đổi trạng thái hoặc các hàm chuyển đổi trạng thái để ánh xạ  
trạng thái giữa các thành phần. Tuy nhiên đây vẫn còn là công việc phức tạp nếu  
thành phần đích không có không gian để lưu trữ trạng thái hoặc không gian lưu trữ  
hạn chế.  
Chương 2. Quy trình phát triển phần mềm thích nghi  
2.1. Tổng quan về quy trình phát triển  
Chươ  
ng này trình  
bày quy  
Variability and  
Commonality  
Component-Based  
Architecture  
CVL Metamodel  
ACME Metamodel  
trình phát  
triển phần  
mềm thích  
nghi. Quy  
conforms to  
conforms to  
Base Model  
Variability Model  
New Resolution  
Model  
Configuration  
State Transfer  
Model  
trình  
này  
Extended CVL  
Metamodel  
bao  
gồm  
refers to  
nhiều bước  
khác nhau  
từ việc đặc  
conforms to  
AdapSwAG tool  
Resolution Model  
Planning  
Adaptive Software  
Architecture Model  
tả  
phần  
mềm ở mức  
cao (high-  
level  
Reconfiguration  
Plan  
Generation  
tool  
specificatio  
n) đến việc  
chuyển  
Applying  
Implementation  
skeletons  
thành  
thực  
(code) của  
phần mềm.  
Quy trình  
này dựa trên  
mã  
thi  
Adaptive Software  
Architecture  
Implementation  
artifacts  
Manual programing  
and Composing  
AdapSwAG tool: Adaptive Software Architecture Generation tool  
công nghệ phát triển dòng sản phẩm phần mềm (software product line engineering).  
Như đã đề cập ở chương trước, công nghệ này phân biệt rõ 2 phần khác nhau gồm:  
công nghệ hướng miền ứng dụng và công nghệ hướng ứng dụng.  
2.2. Công nghệ hướng miền ứng dụng (domain engineering)  
Các kỹ thuật áp dụng trong giai đoạn này tập trung vào việc đặc tả mô hình  
biến đổi và mô hình cơ sở. Một yêu cầu quan trọng trong giai đoạn này là xác định  
9
các đặc trưng chung và riêng của các sản phẩm trong cùng một dòng. Để làm được  
điều này, vai trò của các thành viên tham gia trong quá trình phát triển được thể hiện.  
Thông tin của dòng sản phẩm phải được tập hợp, phân tích và mô hình hóa nó.  
Chúng tôi đã đề xuất các kịch bản khác nhau để phân tích và đặc tả những mô hình  
này.  
2.3. Công nghệ ứng dụng (application engineering)  
Phần này giới thiệu các bước để xây dựng sản phẩm cụ thể từ những thông tin  
đặc tả trong các mô hình trong công nghệ miền. Trong công nghệ dòng sản phẩm,  
một sản phẩm được tạo ra không có tính biến đổi, nghĩa là có không có khả năng  
thích nghi (thay đổi cấu hình) lúc đang hệ thống đang chạy.  
Chương 3. Quản lý chuyển đổi trạng thái trong phần mềm thích nghi  
3.1. Trạng thái và các trường hợp chuyển đổi trạng thái  
Trạng thái của một hệ thống được định nghĩa gồm các trạng thái cục bộ được  
lưu trữ trong các thành phần khác nhau của hệ thống và tất cả các thông điệp đang  
truyền qua mạng1. Trạng thái cục bộ của các thành phần phần mềm gồm thuộc tính  
của thành phần phần mềm, dữ liệu được lưu trữ trong các thành phần đó. Theo định  
nghĩa của Grondin, trạng thái của hệ thống được định nghĩa là một tập các giá trị  
được lưu trữ trong các biến của tất cả các cấu hình phần mềm.  
Trong nghiên cứu này, chúng tôi nghiên cứu trạng thái trong kiến trúc phần  
mềm dựa trên các thành phần. Hình 3-1 biểu diễn hai thành phần gồm, client và  
server, trong đó server cung cấp dịch vụ (providing a service) và client yêu cầu dịch  
vụ (requiring a service). Mỗi thành phần có thể cung cấp các dịch vụ điều khiển  
(control service) cho phép kích hoạt hoặc hủy kích hoạt component, đọc ghi trạng  
thái vào trong các component, vv.  
Hꢀnh 3-1. Mô hình client-server  
Việc chuyển đổi trạng thái là một vấn đề quan trọng của tái cấu hình hệ thống.  
Nó được xem như là một quá trình ghi lại trạng thái của một thành phần hoặc nhóm  
thành phần trong một hệ thống và sử dụng trạng thái này để khởi tạo cho thành phần  
1
X. Ma, L. Baresi, C. Ghezzi, V. Panzica, L. Manna, and J. Lu, “Version-consistent Dynamic Reconfiguration of Component-based  
Distributed Systems,” pp. 245–255, 2011.  
10  
 
mới. Quá trình này được xem là quá trình chuyển đổi trạng thái từ thành phần bị thay  
thế sang thành phần thay thế.  
Hꢀnh 3-2. Các trường hợp chuyển đổi trạng thái  
Như đề cập ở các phần trên, trạng thái bao gồm tất cả các thông tin trong các  
thành phần. Trong bài báo này, chúng tôi quan tâm đến trạng thái được lưu trữ trong  
các biến của thành phần. Giả sử, một thành phần có một biến x, các trường hợp  
chuyển đổi trạng thái như biểu diễn trong Hình 3-2. Trường hợp đầu tiên, giá trị của  
biến lưu trữ trong thành phần được thay thế sẽ chuyển sang biến được lưu trữ tương  
ứng trong thành phần thay thế. Cấu trúc của trạng thái này được duy trì từ thành phần  
bị thay thế sang thành phần thay thế. Trong trường hợp thứ 2, một biến trong thành  
phần bị thay thế có thể bị thay đổi và lưu ở hai biến khác nhau trong hai thành phần  
mới. Trong trường hợp này, các hàm chuyển đổi, f1 và f2, được sử dụng để thay đổi  
trạng thái từ thành phần bị thay thế đến thành phần thay thế và được lưu trong hai  
biến x1 và x2. Cuối cùng, nhiều biến trong thành phần bị thay thế, x1,x2 bị chuyển  
đổi và lưu trữ trong một biến của thànhh phần thay thế. Trường hợp này, hàm f được  
sử dụng và nhận x1,x2 như là đầu vào của nó. Kết quả đầu ra của hàm f được gán cho  
biến x trong thành phần thay thế. Ánh xạ giữa các biến của thành phần bị thay thế  
(biến nguồn) và thành phần thay thế (biến đích) được xem như là một điểm biến đổi  
trạng thái trong quá trình thích nghi của phần mềm.  
Trong công nghệ phần mềm hướng mô hình, một mô hình được sử dụng để  
đặt tả ánh xạ quá trình chuyển đổi trạng thái giữa thành phần bị thay thế và thành  
phần thay thế. Phần tiếp theo trình bày mô hình đề xuất đặc tả ánhh xạ này.  
3.2. Đặc tả mô hình quản lý trạng thái  
Hình 3-3 định nghĩa mô hình chuyển đổi trạng thái. Mô hình này xem xét  
nhiều điểm chuyển đổi trạng thái trong quá trình thích nghi của phần mềm. Mỗi điểm  
chuyển đổi ánh xạ đến một biến đích trong thành phần thay thế, có hoặc không biến  
nguồn. Nếu không có biến nguồn, giá trị đích có thể được gán bởi một hằng số và  
được đặc tả trong mô hình chuyển đổi trạng thái này.  
Mỗi điểm chuyển đổi có một hàm để thay đổi giá trị của biến nguồn chuyền  
vào biến đích. Trường hợp đầu tiên (như đề cập trong hình Hình 3-2) không sử dụng  
11  
 
hàm để thay đổi giá trị giữa biến nguồn và biến đích. Điều này có nghĩa rằng, biến  
đích được gán trực tiếp bởi biến nguồn. Những trường hợp còn lại, một hoặc nhiều  
hàm được sử dụng để thay đổi trạng thái từ biến nguồn sang biến đích. Hàm này  
được biểu diễn bởi một biểu thức trong đó gồm các toán tử, hằng, và biến nguồn.  
Toán tử bao gồm toán tử số học, cộng, trừ, nhân, chia hoặc toán tử được định nghĩa  
bởi người dùng.  
Biến tham gia trong một điểm chuyển đổi trạng thái được đặc tả với tên biến  
(variable name), và kiểu dữ liệu của nó (datatype). Kiểu dữ liệu có thể là kiểu nguyên  
thủy hoặc kiểu đối tượng. Kiểu dữ liệu phải được đặc tả chính xác để đảm bảo tính  
chính xác của dữ liệu trong quá trình chuyển đổi trạng thái.  
Trước khi gán dữ liệu đến biến đích, dữ liệu của biến nguồn có thể được lưu  
trữ trong một biến tạm của một thành phần tạm. Ví dụn một thành phần cung cấp  
dịch vụ có thể nhận yêu cầu từ thành phần yêu cầu dịch vụ. Để thay thế thành phần  
cung cấp dịch vụ này bởi thành phần khác dịch vụ cung cấp phải được chặn lại.  
Chính vì vậy, để không mất yêu cầu mới từ thành phần yêu cầu dịch vụ, một thành  
phần tạm được sử dụng để lưu trữ những yêu cầu tạm trên.  
Hꢀnh 3-3. Mô hꢀnh đặc tả chuyển đổi trạng thái  
3.3. Cơ chế chuyển đổi trạng thái  
Để thực hiện việc chuyển đổi trạng thái trong quá trình thích nghi của phần  
mềm, mô hình chuyển đổi trạng thái được sử dụng. Mô hình này đặc tả ánh xạ trạng  
thái giữa các biến của các thành phần thay thế và bị thay thế. Thông tin được đặc tả  
trong mô hình này được khai thác thông qua một cơ chế chuyển đổi trạng thái để  
12  
 
thực hiện việc chuyển đổi trạng thái trong quá trình thích nghi của phần mềm. Một  
thành phần chính trong cơ chế này là bộ điều khiển tái cấu hình (reconfigurator). Bộ  
điều khiển này điều khiển quá trình thích nghi của phần mềm bao gồm các hoạt động  
như dừng các thành phần, xóa bỏ các thành phần, thêm và khởi động các thành phần  
mới, thay đổi kết nối giữa các thành phần, đọc và ghi trạng thái, vv. Trong nghiên  
cứu này, chúng tôi tập trung vào cơ chế để đọc và ghi trạng thái thông qua mô hình  
chuyển đổi trạng thái.  
Hình 3-4 biễu diển cơ chế chuyển đổi trạng thái sử dụng mô hình chuyển đổi  
trạng thái như đề cập ở trên. Cơ chế này dựa trên thành phần bị thay thế và thành  
phần thay thế. Các thành phần này được xác định bằng cách tính toán sự khác nhau  
của hai cấu hình trước và sau khi thực hiện quá trình thích nghi (current  
configuration và new configuration). Kết quả của quá trình tính toàn này cho phép  
xác định thành phần nào sẽ bị loại bỏ khỏi hệ thống (placement componens), và  
thành phần này sẽ được thêm vào (replacement components). Dựa trên tập các thành  
phần bị thay thế và thay thế và mô hình chuyển đổi trạng thái đã được đặc tả, các  
hoạt động chuyển đổi trạng thái được xác định. Các hoạt động này được mô tả trong  
một kịch bản chuyển đổi trạng thái. Kịch bản chuyển đổi trạng thái này có thể được  
sinh ra tự động bằng một mô đun sinh kịch bản. Mô đun này được xây dựng dựa trên  
nền tảng Xpand2.  
Hꢀnh 3-4. Cơ chế chuyển đổi trạng thái  
2
13  
 
Để thực thi kịch bản chuyển đổi trạng thái trên hệ thống đang chạy, bộ điều  
khiển tái cấu hình cần có một số chức năng cho phép đọc và ghi trạng thái. Những  
chức năng này có thể can thiệp vào các biến bên trong các thành phần thay thế và bị  
thay thế. Như đề cập ở trên, trước khi ghi trạng thái và thành phần mới, trạng thái này  
có thể được biến đổi theo hàm định nghĩa trong mô hình chuyển đổi trạng thái.  
3.4. Ứng dụng thử nghiệm giải pháp chuyển đổi trạng thái trên  
Để thử nghiệm cho giải pháp đề xuất, chúng tôi kế thừa một ví dụ về thực hiện  
quá trình thích nghi3. Ví dụ này đề cập một dịch vụ web với kiến trúc được mô tả như  
hình Hình 3-5. Giả sử, thành phần helloServer sẽ bị loại bỏ khỏi hệ thống thông qua  
quá trình thích nghi và thành phần dynEngine và dynHello sẽ được thêm vào hệ  
thống.  
Dịch vụ web được khởi tạo với bốn thành phần gồm: receiver, dispatcher,  
fileServer và helloServer. Thành phần receiver sẽ nhận các và giải mã yêu cầu. Thành  
phần dispatcher sẽ điều hướng các yêu cầu phù hợp đến các dịch vụ khác nhau như  
fileServer và helloServer. Thành phần fileServer xác định tên tập tin trong yêu cầu và  
gửi trả lời tương ứng. Thành phần helloServer phản hồi thông điệp với một thông tin  
dưới dạng văn bản. Mỗi thành phần cung cấp một dịch vụ với giao diện của nó,  
chẳng hạn như fileServer cung cấp giao diện với tên serve cho phép nhận các yêu  
cầu.  
Hꢀnh 3-5. Dịch vụ web  
Chúng tôi xây dựng ứng dụng này trên nền tảng mô hình thành phần của  
OSGi/iPOJO. Mô hình này cho phép xây dựng những ứng dụng động nghĩa là nó hỗ  
trợ thêm và loại bỏ các thành phần lúc hệ thống đang chạy. Ngoài ra mô hình này  
cung cấp các dịch vụ cho phép đọc và ghi trạng thái của các thành phần độc lập.  
Ngoài ra, chúng tôi sử dụng CXF framework để kết nối các thành phần trên4.  
Kịch bản thích nghi trong ví dụ này là việc thay thế helloServer bằng hai  
thành phần dynEngine và dynHello. Thành phần fileServer không bị ảnh hưởng bởi  
quá trình thích nghi nên vẫn nhận và xử lý các yêu cầu trong suốt quá trình thích nghi  
của hệ thống.  
3 J. Buisson, E. Leroux, F. Dagnat, and E. Leroux, “Safe reconfiguration of Coqcots and Pycots components,” J. Syst. Softw., 2015.  
4 https://github.com/nthohuynh/project_dn2018  
14  
 
Quá trình thích nghi để thực hiện việc thay đổi trên bao gồm các bước chính  
như sau: 1) tách thành phần helloServer và chặn tất cả các yêu cầu mới, 2) thêm và  
kích hoạt thành phần mới, dynEngine và dynHello, 3) thay đổi kết nối từ thành phần  
dispacher tơi thành phần dynEngine, 4) chuyển đổi các yêu cầu bị chặn trong  
helloServer sang thành phần mới dynEngine, 5)Kích hoạt xử lý các yêu cầu trong  
dynEngine, 6) xóa bỏ helloServer. Trong nghiên cứu này chúng tôi quan tâm bước  
thứ tư liên quan đến việc chuyển đổi yêu cầu sang thành phần mới.  
Để xác định bước thứ tư trong quá trình thích nghi, bộ điều khiển thích nghi  
(reconfigurator) cần một vài thông tin liên quan đến việc ánh xạ trạng thái giữa  
helloServer và dynEngine. Thông tin này được đặt tả trong mô hình chuyển đổi trạng  
thái dưới dạng XML như sau:  
<StateTransferModel>  
<points>  
<srcVariable name="buffer">  
<type type="ObjectType" class="Message"/>  
<variableHandle mofRef="helloServer"/>  
</srcVariable>  
<dstVariable name="newBuffer">  
<type type="ObjectType" class="Message"/>  
<variableHandle mofRef="dynEngine"/>  
</dstVariable>  
</points>  
</StateTransferModel>  
Trong mô hình đặc tả trên, một biến buffer trong thành phần helloServer chứa  
các yêu cầu mới nhận được từ thành phần dispatcher. Một biến tên newBufffer trong  
dynEngine thể hiện không gian lưu trữ các yêu cầu được chuyển từ buffer sang. Cả  
hai thành phần helloServer và dynEngine cung cấp cùng một dịch vụ với giao diện  
HelloServer/serve. Dựa vào mô hình chuyển đôi trạng thái, thành phần điều khiển có  
thể xác định được trạng thái sẽ được chuyển đổi.  
3.5. Kết luận chương  
Chương này trình bày mô hình chuyển đổi trạng thái áp dụng trong quá trình  
phát triển phần mềm thích nghi để đặc tả ánh xạ trạng thái giữa các thành phần thay  
đổi. Mô hình này cho phép xác định được các hoạt động chuyển đổi trạng thái tương  
ứng giữa các thành phần thông qua các hàm chuyển đổi và kiểu dữ liệu được đặc tả.  
Mô hình này được định nghĩa bằng EMF framework được tích hợp trong Eclipse.  
Dựa vào tập các API được sinh ra từ nền tảng này cho phép xây dựng cơ chế chuyển  
đổi trạng thái phù hợp. Mô hình này được thiết kế trong quá trình phát triển và được  
sử dụng lúc hệ thống đang chạy để xác định các hoạt động chuyển đổi trạng thái. Các  
15  
hoạt động chuyển đổi này được thực hiện thông qua bộ điều khiển quá trình thích  
nghi để thực hiện việc chuyển đổi tương ứng.  
Kết luận  
Nghiên cứu này đề xuất giải pháp chuyển đổi trạng thái trong quá trình phát  
triển phần mềm thích nghi. Giải pháp này đề xuất một mô hình đặc tả ánh xạ chuyển  
đổi trạng thái giữa các thành phần phần mềm tại thời điểm thiết kế. Mô hình đặc tả  
này được sử dụng trong khi phần mềm đang chạy để xác định các hoạt động chuyển  
đổi trạng thái cụ thể. Bên cạnh đó đề tài đề xuất cơ chế sử dụng mô hình chuyển đổi  
trạng thái để hỗ trợ thực hiện việc chuyển đổi trạng thái trong quá trình thích nghi  
của hệ thống.  
Mô hình chuyển đổi trạng thái cho phép xác định ánh xạ trạng thái giữa các  
thành phần bị thay thế và thành phần thay thế trong phần mềm thích nghi. Bên cạnh  
đó, mô hình hình này cũng cho phép đặc tả hàm biến đổi trạng thái giữa thành phần  
bị thay thế và thành phần thay thế. Nhờ vào mô hình này, bộ phần điều khiển quá  
trình thích nghi sẽ đọc trạng thái cụ thể trong thành phần bị thay thế, biến đổi nó (nếu  
có) và ghi lại trong thành phần thay thế thông qua các hoạt động đọc ghi.  
Bên cạnh đó, đề tài cũng đề xuất một cơ chế thực hiện việc chuyển đổi trạng  
thái bằng cách sử dụng mô hình chuyển đổi trạng thái như đầu vào của nó bên cạnh  
hai cấu hình hệ thống: hệ thống đang chạy và hệ thống mới sau khi thích nghi. Cơ  
chế này cho phép sinh ra một kịch bản thích nghi (adaptation script). Kịch bản này  
được thực hiện bởi bộ điều khiển quá trình thích nghi và áp dụng các hoạt động như  
đọc/ghi trạng thái, thêm/bớt các thành phần lên hệ thống đang chạy.  
Chúng tôi đã áp dụng giải pháp đề xuất lên một ví dụ cụ thể (một dịch vụ web  
đơn giản) và thực hiện việc chuyển đổi trạng thái được lưu trữ trong các thành phần  
phần mềm. Nghiên cứu này chưa quan tâm đến trạng thái đang được truyền qua  
mạng. Đây được xem là một trong những hướng phát triển để hoàn thiện cơ chế  
chuyển đổi trạng thái trong quá trình thích nghi. Bên cạnh đó, cách tiếp cận của  
chúng tôi chưa quan tâm đến việc phục hồi lại trạng thái trước đó khi quá trình thích  
nghi bị lỗi hoặc không hoàn thành.  
Mặc dù nghiên cứu đã quan tâm đến các trường hợp chuyển đổi trạng thái tuy  
nhiên vẫn còn một số khía cạnh cần được hoàn thiện. Cụ thể, như đề cập ở trên,  
nghiên cứu này quan tậm việc chuyển đổi trạng thái của các biến được lưu trữ trong  
các thành phần mà chưa quan tâm đến dữ liệu được truyền đi trên mạng. Bên cạnh đó  
trạng thái trong tiến trình đang thực thi của thành phần cũng chưa được quan tâm.  
Việc chuyển đổi trạng thái trong một tiến trình phụ thuộc vào nền tảng hỗ trợ chuyển  
đổi trạng thái riêng và ngoài phạm vi nghiên cứu của đề tài này.  
Ngoài ra, việc quan tâm đến ràng buộc giữa các trạng thái cũng là một vấn đề  
cần được nghiên cứu, có nghĩa là trạng thái nào được chuyển trước, trạng thái nào  
được chuyển sau. Ví dụ, một hệ thống client-server bị thay đổi cả hai phía client và  
server. Trong trường hợp này để đảm bảo hệ thống hoạt động thông suốt, trạng thái  
16  
của server phải được thực hiện trước và sẵn sàng phục vụ trước khi chuyển đổi trạng  
thái của client.  
17  
pdf 19 trang yennguyen 17560 Free
Bạn đang xem tài liệu "Báo cáo tóm tắt Đề tài Nghiên cứu giải pháp chuyển đổi trạng thái áp dụng trong quy trình phát triển phần mềm thích nghi", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

File đính kèm:

  • pdfbao_cao_tom_tat_de_tai_nghien_cuu_giai_phap_chuyen_doi_trang.pdf