Khóa luận Nghiên cứu một giải pháp bảo trì phần mềm tự động kết hợp với hệ thống quản lý cấu hình

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Bùi Chí Tài

NGHIÊN CỨU MỘT GIẢI PHÁP BẢO TRÌ PHẦN

MỀM TỰ ĐỘNG KẾT HỢP VỚI HỆ THỐNG

QUẢN LÝ CẤU HÌNH

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

HÀ NỘI - 2009

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Bùi Chí Tài

NGHIÊN CỨU MỘT GIẢI PHÁP BẢO TRÌ PHẦN

MỀM TỰ ĐỘNG KẾT HỢP VỚI HỆ THỐNG

QUẢN LÝ CẤU HÌNH

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

Cán bộ hướng dẫn: ThS. Đào Kiến Quốc

HÀ NỘI – 2009

TÓM TẮT NỘI DUNG

Trong khóa luận tốt nghiệp này, chúng tôi tìm hiểu và nghiên cứu về hệ thống quản

lý cấu hình phần mềm, mà nhiệm vụ quan trọng nhất là quản lý phiên bản. Hầu hết

công cụ quản lý phiên bản hiện thời chỉ chú trọng hỗ trợ cho những nhà phát triển

trong khi phát triển phần mềm nhằm kiểm soát mọi sự thay đổi của phần mềm do nhà

phát triển tạo ra, mà chưa hỗ trợ việc nâng cấp phần mềm tự động về phía khách hàng,

rộng hơn là bảo trì phần mềm tự động. Vì vậy trong khóa luận này, chúng tôi sẽ đề

xuất một giải pháp kết hợp việc nâng cấp tự động với hệ thống quản lý phiên bản.

Dựa trên ý tưởng đó, chúng tôi đã tiến hành phân tích, thiết kế và cài đặt thử

nghiệm chương trình mô phỏng kết hợp nâng cấp phần mềm với hệ thống quản lý

phiên bản.

MỤC LỤC

CHƯƠNG 1 MỞ ĐẦU........................................................................................ - 1 -

1.1. Khái niệm bảo trì phần mềm ..........................................................................- 1 -

1.2. Khái niệm quản lý cấu hình phần mềm..........................................................- 1 -

1.3. Vai trò của quản lý cấu hình phần mềm.........................................................- 1 -

1.4. Hoạt động quản lý cấu hình ............................................................................- 3 -

1.4.1.

1.4.2.

Các khái niệm cơ bản trong quản lý cấu hình ............................................ - 3 -

Các hoạt động chính trong quản lý cấu hình...............................................- 3 -

CHƯƠNG 2 THỰC TRẠNG VÀ GIẢI PHÁP................................................ - 12 -

2.1. Thực trạng .....................................................................................................- 12 -

2.2. Đề xuất giải pháp...........................................................................................- 13 -

CHƯƠNG 3 PHÂN TÍCH HỆ THỐNG MÔ PHỎNG HOẠT ĐỘNG NÂNG

CẤP TỰ ĐỘNG KẾT HỢP VỚI QUẢN LÝ PHIÊN BẢN ............................. - 14 -

3.1. Mục tiêu hệ thống...............................................................................................- 14 -

3.2. Các chức năng hệ thống .....................................................................................- 14 -

3.3. Mô hình khái niệm .............................................................................................- 14 -

3.3.1. Các khái niệm................................................................................................- 15 -

3.4. Xác định các tác nhân, ca sử dụng và mô tả ca sử dụng...................................- 15 -

3.4.1. Xác định các tác nhân....................................................................................- 15 -

3.4.2. Xác định các ca sử dụng (Use Case) ..............................................................- 16 -

3.5. Biểu đồ sử dụng theo gói và mô tả ca sử dụng của hệ thống.............................- 17 -

3.5.1. Gói quản lý phiên bản....................................................................................- 17 -

3.5.2. Gói quản lý mã nguồn....................................................................................- 21 -

3.5.3. Gói quản lý nâng cấp phiên bản.....................................................................- 23 -

3.6. Biểu đồ tuần tự hệ thống....................................................................................- 25 -

3.6.1. Gói quản lý phiên bản....................................................................................- 25 -

3.6.2. Gói quản lý mã nguồn....................................................................................- 28 -

3.6.3. Gói quản lý nâng cấp phiên bản.....................................................................- 30 -

3.7. Hợp đồng cho các thao tác hệ thống..................................................................- 31 -

CHƯƠNG 4 THIẾT KẾ HỆ THỐNG MÔ PHỎNG HOẠT ĐỘNG NÂNG CẤP

KẾT HỢP VỚI QUẢN LÝ PHIÊN BẢN ......................................................... - 37 -

4.1. Biểu đồ tuần tự đối tượng ..................................................................................- 37 -

4.1.1. Gói quản lý phiên bản....................................................................................- 37 -

4.1.2. Gói quản lý mã nguồn....................................................................................- 42 -

4.1.3. Gói quản lý nâng cấp phiên bản.....................................................................- 45 -

4.2. Biểu đồ lớp..........................................................................................................- 47 -

CHƯƠNG 5 CÀI ĐẶT THỬ NGHIỆM .......................................................... - 48 -

i

5.1. Môi trường triển khai.........................................................................................- 48 -

5.2. Phương pháp triển khai .....................................................................................- 48 -

5.3. Kết quả triển khai ..............................................................................................- 49 -

CHƯƠNG 6 KẾT LUẬN.................................................................................. - 58 -

TÀI LIỆU THAM KHẢO ................................................................................. - 59 -

ii

Mở đầu

CHƯƠNG 1

MỞ ĐẦU

Chương này nhằm giới thiệu những khái niệm và hoạt động chung của việc “bảo trì

phần mềm” và “hệ thống quản lý cấu hình”.

1.1. Khái niệm bảo trì phần mềm

Bảo trì phần mềm (Software Maintenance) là việc chỉnh sửa một sản phẩm phần

mềm sau khi đã chuyển giao để sửa lỗi, để cải tiến hiệu năng (performance) hoặc các

thuộc tính khác, hoặc làm thích ứng sản phẩm trên một môi trường bị thay đổi.^[7]

Trong bảo trì phần mềm chúng ta xem xét hoạt động nâng cấp phần mềm

 Nâng cấp phần mềm: Là việc sử dụng hay triển khai (deploying) một phiên

bản phần mềm mới để thay thế cho một phiên bản phần mềm khác (cũ hơn).

Ví dụ: Nâng cấp phiên bản trình duyệt Firefox 3.0.4 lên Firefox 3.0.7

1.2. Khái niệm quản lý cấu hình phần mềm

Quản lý cấu hình phần mềm (Software Configuration Management – SCM) là sự

phát triển và áp dụng các chuẩn và các thủ tục để quản lý sự phát triển của hệ thống

sản phẩm. Quản lý cấu hình là hoạt động bao trùm trong suốt tiến trình phần mềm. Bởi

vì những thay đổi có thể xảy ra vào bất cứ lúc nào, hoạt động quản lý cấu hình được

phát triển để xác định thay đổi, kiểm soát thay đổi, đảm bảo rằng những thay đổi đó

được thi hành một cách đúng đắn, và báo cáo những thay đổi đó cho những người liên

quan.^[2]

Theo chuẩn CMM và ISO 15504: Mục đích của Quản Lý Cấu Hình là để thiết lập

và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như sản phẩm sau cùng

của một dự án phần mềm, xuyên suốt chu kỳ sống của dự án phần mềm đó.

1.3. Vai trò của quản lý cấu hình phần mềm

Tại sao lại phải quản lý cấu hình ?^[3]

Thực tiễn phát triển phần mềm chúng ta thường gặp những sự cố như:

 Một lỗi nào đó của phần mềm đang xây dựng đã tốn công sửa chữa, bỗng

nhiên xuất hiện trở lại.

- 1 -

Mở đầu

 Một chức năng nào đó của phần mềm đã được phát triển và kiểm tra cẩn

thận bỗng thất lạc hoặc biến mất một cách khó hiểu.

 Một chương trình đã được kiểm tra cẩn thận bỗng nhiễn không chạy được

nữa.

 Một chương trình gồm nhiều đơn thể (module), mỗi đơn thể gồm nhiều chức

năng, các chức năng được chia ra cho nhiều lập trình viên, mỗi chức năng

bao gồm nhiều tập tin mã nguồn, với nhiều phiên bản khác nhau. Khi tích

hợp hệ thống và biên dịch, trong hàng chục tập tin mã nguồn với hàng trăm

phiên bản, tập tin nào, phiên bản nào là đúng và cần lấy để tiến hành tích

hợp.

Quản lý cấu hình tốt sẽ giải quyết được nhiều vấn đề có thể xảy ra:

 Cập nhật đồng thời: Khi 2 hoặc nhiều lập trình viên làm việc cách biệt nhau

nhưng trên cùng một chương trình hoặc dự án, những thay đổi mà người này

thực hiện có thể phá vỡ kết quả làm việc của người khác. Ví dụ: Sản phẩm

anh A làm ra sử dụng kết quả công việc của anh B, sản phẩm của anh B thay

đổi dẫn đến sản phẩm của anh A không chạy được.

 Chia sẻ mã nguồn: Trong các hệ thống lớn, khi các chức năng chung bị thay

đổi, tất cả những người liên quan phải được biết. Không quản lý mã nguồn

tốt thì không có cách nào đảm bảo tất cả những người liên quan đều được

thông báo những thay đổi đó.

 Vấn đề phiên bản phần mềm (release): Hầu hết các chương trình hoặc hệ

thống lớn được phát triển với nhiều phiên bản từ thấp đến cao. Trong trường

hợp một phiên bản khách đang dùng, phiên bản khác đang được kiểm tra

(test), và một phiên bản khác nữa đang trong quá trình phát triển, khi có một

lỗi xảy ra, việc sửa lỗi phải đồng bộ giữa ba phiên bản này, nếu quản lý mã

- 2 -

Mở đầu

nguồn không tốt, vấn đề đồng bộ rất khó thực hiên được. Nếu lỗi do khách

hàng phát hiện ra, lỗi đó phải được sửa trong tất cả các phiên bản về sau.

Quản lý cấu hình được thực hiện xuyên suốt chu kỳ sống của dự án, từ lúc bắt

đầu đến lúc kết thúc, thậm chí vẫn còn trong giai đoạn bảo trì sản phẩm sau dự án.

1.4. Hoạt động quản lý cấu hình

1.4.1. Các khái niệm cơ bản trong quản lý cấu hình

 Hạng mục cấu hình (Configuration Item - CI): Là tên gọi của các sản phẩm, sản

phẩm trung gian, một file hoặc một nhóm file, tài liệu hoặc một nhóm tài liệu

trong dự án mà ta cần phải quản lý và kiểm soát.

Ví dụ: một file mã nguồn, tài liệu về yêu cầu sản phẩm, bản thiết kế,…

 Ranh giới (Baseline): Là một mốc trong quá trình phát triển phần mềm mà sau

điểm mốc này thì mọi thay đổi phải được thông báo tới tất cả những người có

liên quan.

Ví dụ: Các thành phần của đặc tả thiết kế phải được viết thành tài liệu và

được xem xét lại, các lỗi phải được tìm ra và sửa cho đúng. Một khi mà tất cả

các phần của việc đặc tả đã được xem xét, sửa cho đúng và sau đó được phê

chuẩn thì bản đặc tả thiết kế trở thành một baseline.

1.4.2. Các hoạt động chính trong quản lý cấu hình

- 3 -

Mở đầu

a. Lập kế hoạch quản lý cấu hình

Thông thường việc lập kế hoạch quản lý cấu hình được thể hiện trong một tài liệu

có tên là kế hoạch quản lý cấu hình (Configuration Management Plan – CMP). Bản

kế hoạch này bao gồm các khoản sau:

 Ý nghĩa, mục đích và phạm vi áp dụng của bản kế hoạch.

 Vai trò và trách nhiệm của các nhóm, cá nhân trong dự án thực hiện các

hoạt động khác nhau liên quan đến quản lý cấu hình. Định nghĩa rõ ràng

ai thực hiện, ai tham gia xem xét (review), ai phê duyệt (approve) trên

các hạng mục cấu hình (CI) của dự án, cũng như vai trò của khách hàng,

người sử dụng đầu cuối. Ví dụ minh họa:

Role

Project

CM

Tool

Subsystem Full

Manager Responsible Librarian Responsible CCB

System

CCB

Task 1

Task 2

Task 3

R

I

S

R

I

C

I

A

C

R: Responsible;A:Approval;S:Support;I:Inform;C:Consult

- 4 -

Mở đầu

 Công cụ, môi trường và cơ sở hạ tầng. Phần này mô tả các công cụ phần

mềm hoặc quy trình thủ tục được sử dụng để hỗ trợ trong việc quản lý

cấu hình, chẳng hạn công cụ quản lý phiên bản sản phẩm (version

control). Mô tả vị trí các máy chủ, máy trạm, cấu hình hệ thống client-

server,…

 Phương pháp nhận diện (identification) và thiết lập các baseline trên các

CI

 Quy ước đặt tên trong dự án, kể cả tên file.

 Quy trình kiểm soát thay đổi (change control process).

 Chỉ định thành viên nhóm kiểm soát cấu hình (Configuration Control

Board –CCB).

 Thông tin nơi lưu trữ các CI.

 Kiểm kê và báo cáo cấu hình (configuration accounting and reporting)

 Quy trình thủ tục lưu trữ và chép dự phòng (backup and archive)

b. Định danh/đánh số các hạng mục cấu hình (Identification of Configuration

Items)

Định danh là một trong những hoạt động nền tảng của quản lý cấu hình.

Mục đích của định danh là để xác định tính duy nhất của một CI, cũng như mối

quan hệ giữa nó với các CI khác. Nó bao gồm việc mô tả tên, đánh số, đánh dấu đặc

trưng cho một CI, giúp nhận biết và phân biệt CI này với CI khác hay thành phần khác.

Trong sản xuất phần mềm, một CI có thể bao gồm một hay nhiều file, ví dụ: một

module ExpMod có thể coi là một CI, nó chứa 2 file khác nhau ExpMod.h và

ExpMod.c

Mỗi CI phải có một số định danh duy nhất, dạng thường thấy là:

Ví dụ: PRJ0001_REQB_1.0.4_draft_B

cho biết:

Số ID của dự án: PRJ0001

Số ID của Item: REQB

- 5 -

Mở đầu

Số phiên bản: 1.0.4_draft_B

Trong một dự án, thường số lượng file mã nguồn rất nhiều, do vậy quy

tắc

cơ bản cho các file mã nguồn (source code) là: các file cùng tạo nên một khối chức

năng thì nên gom chung thành một CI.

c. Kiểm soát phiên bản (Version Control)

Kiểm soát phiên bản là sự kiểm soát các phiên bản khác nhau của một CI (bao

gồm việc định danh và lưu trữ của CI đó).

Một phiên bản nói dễ hiểu là một thực thể mới của một CI sau khi đã qua một

hoặc nhiều lần xem xét và thay đổi.

Phiên bản của một CI khác với phiên bản của các file thành phần bên trong đó.

Ví dụ phiên bản của CI module “ExpMod” khác với phiên bản của file thành phần

“ExpMod.h” và “ExpMod.c”

Hình 04. Ví dụ phiên bản

Các phiên bản quan trọng của CI có thể được đánh nhãn (label) để đánh dấu và

biểu thị:

 Một “mốc” quan trọng trong tiến trình phát triển CI đó, ví dụ: một phiên

bản được nâng cấp sau một thay đổi lớn.

 Phiên bản mà CI được phê duyệt

 Phiên bản được baseline

d. Quản lý baseline

Các loại baseline thường gặp bao gồm: Chức năng

Kế hoạch

Yêu cầu khách hàng (Requirements)

- 6 -

Mở đầu

Sản phẩm (Product)

Bản phân phối (Release)

Kiểm thử (Test)

Môi trường hoạt động (Environment)

Quản lý baseline bao gồm:

 Chọn các CI cho mỗi loại baseline

 Tiến hành “ghim chết” baseline tại thời điểm sau khi các thay đổi đã

được chấp thuận và phê duyệt

Thông thường baseline được tiến hành tại điểm kết thúc của mỗi pha (phase) hay

các “mốc” quan trọng trong dự án.

Hình 05. Mô tả baseline

Đồng thời, trong quản lý baseline, vai trò và nhiệm vụ của những người thiết lập

và phê chuẩn baseline cũng phải được xác định.

e. Kiểm soát thay đổi (Change Control)

Yêu cầu thay đổi là điều không thể tránh khỏi trong quá trình phát triển hay bảo

trì phần mềm.

Mục đích của “Change Control” là để kiểm soát đầy đủ tất cả các thay đổi ảnh

hưởng đến việc phát triển phần mềm. Đôi lúc chỉ vài thay đổi trong yêu cầu của khách

hàng dẫn đến tất cả các giai đoạn phát triển phần mềm (thiết kế, code, kiểm thử) đều

phải thay đổi theo.

Yêu cầu trong kiểm soát thay đổi là mọi sự thay đổi phải được thông báo đến tất

cả những người hoặc nhóm làm việc có liên quan.

Hình sau mô tả một quy trình kiểm soát thay đổi cơ bản:

- 7 -

Mở đầu

Hình 06. Quy trình kiểm soát thay đổi

Các bước cơ bản trong kiểm soát thay đổi gồm:

 Nghiên cứu, phân tích

 Phê chuẩn hoặc không phê chuẩn

 Thực hiện việc thay đổi

 Kiểm tra việc thay đổi

 Xác lập baseline mới

Khái niệm CCB (Change Control Board) là nhóm kiểm soát thay đổi, nhóm này

được thành lập trong từng dự án.

CCB thông thường bao gồm những người sau trong dự án:

 Người quản lý cấu hình

 Trưởng dự án

 Trưởng nhóm kĩ thuật (Technical lead)

 Trưởng nhóm kiểm thử (Test lead)

 Kỹ sư chất lượng (Quality Engineer)

 Và những ai bị ảnh hưởng bởi các thay đổi

Nhiệm vụ của CCB thường là:

 Bảo đảm tất cả các thay đổi được các bộ phận liên quan nhận biết và

tham gia

- 8 -

Mở đầu

 Xem xét, phê chuẩn hoặc phủ quyết các thay đổi trên các baseline

 Kiểm tra, xác nhận các thay đổi

 Phê chuẩn các bản phân phối sản phẩm đến khách hàng

f. Báo cáo tình trạng cấu hình (Configuration Status Accounting)

Công việc này bao gồm việc ghi nhận và báo cáo tình trạng của các CI cũng như

các yêu cầu thay đổi, tập hợp các số liệu thống kê về các CI góp phần tạo nên sản

phẩm. Nó trả lời các câu hỏi như: có bao nhiêu files bị ảnh hưởng khi sửa chữa một lỗi

phần mềm (bug) nào đó ?

Kết quả của công việc này được ghi lại trong báo cáo Configuration Status

Accounting Report (CSAR). Báo cáo chỉ rõ các điểm:

 Liệt kê tất cả các baseline và các CI thành phần có liên quan

 Làm nổi bật các CI đang được phát triển hoặc vừa bị thay đổi

 Liệt kê các thay đổi đang còn dang dở hay đang hoàn thành, và các

baseline bị ảnh hưởng bởi các thay đổi đó

Báo cáo này được làm thường xuyên và định kỳ, xuyên suốt dự án.

g. Kiểm định (Auditing)

Có 3 loại kiểm định thường được thực hiện:

CSAR Audit

Kiểm định này thường được làm sau mỗi lần một CSAR được tạo ra, bao

gồm:

 Bảo đảm rằng các baseline mới nhất được liệt kê trong CSAR

 Bảo đảm rằng tất cả các CI tạo nên một baseline được liệt kê

 Kiểm tra các CI đã bị thay đổi từ lần baseline trước đó, so sánh chúng

với các yêu cầu thay đổi để khẳng định sự thay đổi trên các CI là hợp lý

Physical configuration audit (PCA)

Kiểm định này nhằm mục đích khẳng định xem những gì khách hàng yêu

cầu có được hiện thực trong thực tế hay không, cụ thể bao gồm 2 việc:

 Kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu khách hàng và việc

hiện thực viết code trong dự án: requirements <-> code

- 9 -

Mở đầu

 Xác định những gì sẽ được phân phối cho khách hàng (các file chạy, mã

nguồn, tài liệu đi kèm,v..v..) có đáp ứng với yêu cầu khách hàng không

Functional configuration audit (FCA)

Kiểm định này nhằm mục đích khẳng định xem những gì khách hàng yêu

cầu có được kiểm tra chặt chẽ trên sản phẩm tạo ra trước khi giao cho khách

hàng hay không, cụ thể là kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu

khách hàng và việc kiểm tra sản phẩm: requirements <-> test

h. Quản lý sản phẩm chuyển giao (release management)

Khái niệm “build” và “release”:

Quá trình phát triển sản phẩm thường qua nhiều lần tích hợp, kết quả của mỗi lần

tích hợp là một bản “build” được hình thành, trong rất nhiều bản “build” đó, một số

bản đáp ứng yêu cầu đã định hoặc lập kế hoạch trước (theo yêu cầu khách hàng), sẽ

được gửi cho khách hàng để kiểm tra hoặc đánh giá. Các bản “build” này sẽ được gọi

là “release”, và công việc tạo ra và phân phối các bản release sẽ được gọi là công việc

“release”. Sản phẩm sau cùng cũng là một bản release, đôi khi còn gọi là “final

release”.

Quản lý release bao gồm nhóm các công việc để bảo đảm rằng tất cả các bản

release gửi cho khách hàng là:

 Hoàn thành, và

 Có thể được tái tạo bởi khách hàng, ví dụ: Khách hàng có thể tạo ra file

chạy (executable) từ các file mã nguồn được gửi tới

Trong quá trình chuyển giao (release), việc quản lý đòi hỏi phải thực hiện các

công việc sau:

 Tiến hành “ghim chết” baseline môi trường phát triển sản phẩm và các

file, tài liệu (sẽ chuyển giao)

 Thực hiện báo cáo CSAR

 Thực hiện các kiểm nghiệm (audit) PCA và FCA

 Đóng gói các file và tài liệu sẽ chuyển giao

 Xác nhận đã nhận bản release từ khách hàng

i. Lưu trữ và chép dự phòng (Backup and Archive)

- 10 -

Mở đầu

Lưu trữ và chép dự phòng là một hoạt động của quản lý cấu hình, đồng thời là

một trong những hoạt động quan trọng của sản xuất phần mềm. Nó giúp khắc phục các

trường hợp rủi ro bị mất mát dữ liệu do thao tác sai, do virus, hoặc do sự cố phần

cứng, phần mềm. Ngoài ra, công việc này còn hỗ trợ cho hoạt động kiểm soát phiên

bản trong trường hợp muốn sử dụng các phiên bản khác nhau.

Lưu trữ và chép dự phòng đòi hỏi toàn bộ sản phẩm và sản phẩm trung gian của

dự án phải được định kỳ chép dự phòng trên những thiết bị hoặc những nơi khác một

cách an toàn.

Khi dự án kết thúc, cần thực hiện các công việc sau:

 Lưu trữ toàn bộ dữ liệu dự án, tuân thủ quy trình lưu trữ đã được thiết

lập (định nghĩa bởi dự án hoặc quy định ở cấp công ty)

 Lưu trữ hoặc hủy bỏ các tài liệu ở dạng giấy

 Dọn sạch dữ liệu hoặc thông tin của dự án vừa kết thúc, sau khi đã chép

lưu trữ

- 11 -

Thực trạng và Giải pháp

CHƯƠNG 2

THỰC TRẠNG VÀ GIẢI PHÁP

2.1. Thực trạng

Một trong những nhiệm vụ chính của hệ thống quản lý cấu hình là kiểm soát

phiên bản phần mềm (control version), hiện nay có rất nhiều công cụ kiểm soát phiên

bản phần mềm, chẳng hạn như: SubVersion, CVS (phần mềm mã nguồn mở), IBM

Rational ClearCase, Visual SourceSafe (của Microsoft),..v.v..

Mục đích của hệ thống kiểm soát phiên bản là theo dõi, kiểm soát mọi sự thay

đổi đã và đang diễn ra đối với phần mềm trong suốt quá trình phát triển, bao gồm sự

thay đổi của các file mã nguồn, tài liệu, các file mới được bổ sung, sửa đổi hay loại

bỏ,…Và do vậy kiểm soát được nhiều phiên bản phần mềm khác nhau.

Hình vẽ sau minh họa mô hình hệ thống kiểm soát phiên bản client-server điển

hình:

Hình 07. Mô hình hệ thống kiểm soát phiên bản^[4]

Trong đó:

 Repository (Kho dữ liệu – đặt tại server): là nơi chứa toàn bộ dữ liệu liên

quan đến phần mềm (ví dụ: file mã nguồn, tài liệu, file exe, ….)

 Client: sẽ chứa bản copy (working copy) của kho dữ liệu, là nơi làm việc

của mỗi nhà phát triển phần mềm.

Do vậy sẽ có nhiều nhà phát triển phần mềm làm việc song song với nhau.

- 12 -

Thực trạng và Giải pháp

Hệ thống kiểm soát phiên bản có cơ chế để đảm bảo việc chia sẻ dữ liệu giữa các

nhà phát triển xảy ra tin cậy, và mọi sự thay đổi diễn ra trong kho dữ liệu đều được

kiểm soát.

Hầu hết các công cụ quản lý cấu hình hiện thời mới chỉ kiểm soát phiên bản mã

nguồn phục vụ trong quá trình phát triển phần mềm, mà chưa hỗ trợ kiểm soát phiên

bản theo hướng “nâng cấp phần mềm” từ phía người sử dụng. Chẳng hạn: khách hàng

đang dùng phần mềm, họ muốn thực hiện nâng cấp lên một phiên bản khác (mới hơn),

điều gì sẽ xảy ra, và phải quản lý thế nào ?

Vì vậy chúng tôi sẽ trình bày một giải pháp nâng cấp phần mềm tự động kết hợp

với hệ thống kiểm soát phiên bản.

2.2. Đề xuất giải pháp

Giải pháp đưa ra là xây dựng một công cụ vừa cho phép quản lý phiên bản phần

mềm, vừa hỗ trợ xử lý hoạt động nâng cấp phần mềm tự động theo yêu cầu của người

sử dụng.

Công cụ này cần phải lưu các phiên bản đã có, cũng như mối quan hệ giữa các

phiên bản, các hoạt động diễn ra khi nâng cấp từ một phiên bản này tới một phiên bản

khác

Do thời gian nghiên cứu về lĩnh vực này không nhiều và kinh nghiệm còn hạn

chế, nên chúng tôi mới chỉ xây dựng hệ thống mô phỏng hoạt động nâng cấp tự động

kết hợp với quản lý phiên bản với các chức năng đã nêu mà bỏ qua nhiều chức năng

khác của hệ thống quản lý phiên bản, và chưa xây dựng được một hệ thống client –

server hoàn chỉnh.

Chương 3,4 sẽ trình bày phần phân tích và thiết kế hệ thống trên, chương 5 sẽ là

cài đặt hệ thống.

- 13 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

CHƯƠNG 3

PHÂN TÍCH HỆ THỐNG MÔ PHỎNG HOẠT ĐỘNG NÂNG CẤP TỰ

ĐỘNG KẾT HỢP VỚI QUẢN LÝ PHIÊN BẢN

3.1. Mục tiêu hệ thống

Mục tiêu của hệ thống là mô phỏng hoạt động nâng cấp phần mềm kết hợp với

một hệ thống quản lý phiên bản đơn giản.

3.2. Các chức năng hệ thống

R.1. Gói quản lý phiên bản

R.1.1. Tạo phiên bản

R.1.2. Thiết lập quan hệ giữa các phiên bản

R.1.3. Gán mã nguồn cho phiên bản

R.1.4. Sửa thông tin phiên bản

R.1.5. Xem thông tin phiên bản

R.1.6. Xóa phiên bản

R.2. Gói quản lý mã nguồn

R.2.1. Tạo mã nguồn

R.2.2. Sửa thông tin mã nguồn

R.2.3. Xem thông tin mã nguồn

R.2.4. Xóa mã nguồn

R.3. Gói quản lý nâng cấp phiên bản

R.3.1. Lựa chọn phiên bản hiện dùng

R.3.2. Kiểm tra update

3.3. Mô hình khái niệm

- 14 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

Hình 08. Mô hình khái niệm hệ thống

3.3.1. Các khái niệm

Khái niệm

Phienban

Manguon

Mô tả

Phiên bản của phần mềm

Mã nguồn của phần mềm (file mã

nguồn, file tài liệu,…)

Phienban_Manguon

HanhdongChuyendoi

Phiên bản phần mềm và mã nguồn phụ

thuộc

Các hành động được thực hiện khi nâng

cấp phiên bản (giữ nguyên, xóa, thêm,

sửa một mã nguồn nào đó)

QuanhePhienban

Quan hệ giữa hai phiên bản kế tiếp nhau

3.4. Xác định các tác nhân, ca sử dụng và mô tả ca sử dụng

3.4.1. Xác định các tác nhân

Hệ thống mô phỏng chỉ gồm 1 tác nhân: Người dùng

- 15 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

Tác nhân

Các ca sử dụng nghiệp

vụ

Kết quả đem lại

Người sử dụng Tạo phiên bản

Thiết lập quan hệ giữa

các phiên bản

Tạo phiên bản, lưu vào cơ sở dữ liệu

Tạo mối quan hệ giữa các phiên bản,

lưu vào cơ sở dữ liệu

Gán mã nguồn cho phiên Xác định các file mã nguồn của

bản

phiên bản, lưu vào cơ sở dữ liệu

Sửa thông tin phiên bản

Sửa các thông tin của phiên bản và

lưu lại

Xem thông tin phiên bản Hiển thị thông tin về phiên bản được

chọn

Xóa phiên bản

Tạo mã nguồn

Xóa phiên bản trong cơ sở dữ liệu

Tạo mã nguồn mới, lưu vào cơ sở dữ

liệu

Sửa thông tin mã nguồn

Sửa thông tin của mã nguồn và lưu

lại

Xem thông tin mã nguồn Hiển thị thông tin mã nguồn

Xóa mã nguồn Xóa mã nguồn trong cơ sở dữ liệu

Lựa chọn phiên bản hiện Chọn một phiên bản làm phiên bản

dùng

hiện thời để thực hiện chức năng mô

phỏng nâng cấp

Kiểm tra update

Kiểm tra xem có phiên bản mới hơn

phiên bản hiện dùng hay không để

nâng cấp

3.4.2. Xác định các ca sử dụng (Use Case)

1. Gói quản lý phiên bản

Uc1. Tạo phiên bản

Uc2. Thiết lập quan hệ giữa các phiên bản

- 16 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

Uc3. Gán mã nguồn cho phiên bản

Uc4. Sửa thông tin phiên bản

Uc5. Xem thông tin phiên bản

Uc6. Xóa phiên bản

2. Gói quản lý mã nguồn

Uc7. Tạo mã nguồn

Uc8. Sửa thông tin mã nguồn

Uc9. Xem thông tin mã nguồn

Uc10. Xóa mã nguồn

3. Gói quản lý nâng cấp phiên bản

Uc11. Lựa chọn phiên bản hiện dùng

Uc12. Kiểm tra update

3.5. Biểu đồ sử dụng theo gói và mô tả ca sử dụng của hệ thống

3.5.1. Gói quản lý phiên bản

Hình 09. Biểu đồ Use Case gói quản lý phiên bản

- 17 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

Mô tả Use Case trong gói quản lý phiên bản

Uc1. Tạo phiên bản

- Tên ca sử dụng:

- Tác nhân:

Tạo phiên bản

Người dùng (User)

- Mục đích:

Khởi tạo phiên bản phần mềm mới, lưu vào cơ sở dữ

liệu

- Mô tả khái quát:

Người dùng nhấn nút yêu cầu tạo phiên bản mới, rồi

thực hiện các chỉ dẫn tạo phiên bản

- Tham chiếu:

R.1.1

- Mô tả diễn biến:

Hành động của tác nhân

1. Chọn mục tạo phiên bản

Hồi đáp của hệ thống

2. Hiển thị form tạo phiên bản

3. Người dùng nhập thông tin cần thiết 4. Lưu thông tin phiên bản mới tạo

vào form, rồi nhấn nút “Create” vào cơ sở dữ liệu

- Ngoại lệ:

- Đã tồn tại phiên bản giống vậy trong cơ sở dữ liệu

- Người dùng nhập không đầy đủ hoặc sai thông tin,

yêu cầu nhập lại

Uc2. Thiết lập quan hệ giữa các phiên bản

- Tên ca sử dụng:

- Tác nhân:

Thiết lập quan hệ giữa các phiên bản

Người dùng (User)

- Mục đích:

Xác định mối quan hệ giữa các phiên bản với nhau và

lưu lại trong cơ sở dữ liệu

- Mô tả khái quát:

Người dùng chọn phiên bản cần thiết lập quan hệ, rồi

chọn chức năng thiết lập quan hệ phiên bản.

- Tham chiếu:

R.1.2

- Mô tả diễn biến:

- 18 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn phiên bản cần thiết lập quan

hệ, rồi chọn nút thiết lập quan hệ

2. Hiển thị form thiết lập quan hệ

phiên bản

3. Lựa chọn phiên bản bị tác động, rồi 4. Lưu lại quan hệ giữa các phiên bản

nhấn “Ok”

vào cơ sở dữ liệu

- Ngoại lệ:

Uc3. Gán mã nguồn cho phiên bản

- Tên ca sử dụng:

- Tác nhân:

Gán mã nguồn cho phiên bản

Người dùng (User)

- Mục đích:

Xác định phiên bản gồm những mã nguồn nào

- Mô tả khái quát:

Người dùng chọn phiên bản, sau đó chọn chức năng

“gán mã nguồn cho phiên bản” để thực hiện

- Tham chiếu:

R.1.3

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn phiên bản cần gán mã nguồn, 2. Hiển thị form gán mã nguồn cho

rồi chọn nút “add/remove source”

phiên bản

3. Chọn những mã nguồn muốn gán,

rồi nhấn “Ok”

4. Lưu lại thông tin về chỉ định mã

nguồn cho phiên bản vào cơ sở dữ liệu

- Ngoại lệ:

Uc4. Sửa thông tin phiên bản

- Tên ca sử dụng:

- Tác nhân:

Sửa thông tin phiên bản

Người dùng (User)

- Mục đích:

Sửa thông tin của một phiên bản nào đó

- Mô tả khái quát:

Người dùng chọn phiên bản cần sửa và nhấn nút sửa

- 19 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

- Tham chiếu: R.1.4

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn phiên bản cần sửa, rồi nhấn

nút sửa

2. Hiển thị form sửa thông tin phiên

bản

3. Người dùng nhập thông tin cần sửa 4. Lưu lại thông tin phiên bản mới sửa

vào form, rồi nhấn “Save”

đổi vào cơ sở dữ liệu

- Ngoại lệ:

- Người dùng nhập không đầy đủ hoặc sai thông tin,

yêu cầu nhập lại

Uc5. Xem thông tin phiên bản

- Tên ca sử dụng:

- Tác nhân:

Xem thông tin phiên bản

Người dùng (User)

- Mục đích:

Xem thông tin chi tiết của một phiên bản nào đó

- Mô tả khái quát:

Người dùng chọn phiên bản, và nhấn nút xem thông

tin phiên bản

- Tham chiếu:

R.1.5

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn phiên bản rồi chọn nút View

3. Chọn Cancel để thoát

- Ngoại lệ:

2. Hiển thị thông tin về phiên bản

4. Thoát form

Uc6. Xóa phiên bản

- Tên ca sử dụng:

- Tác nhân:

Xóa phiên bản

Người dùng (User)

- Mục đích:

Xóa phiên bản khỏi cơ sở dữ liệu

- 20 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

- Mô tả khái quát:

Người dùng chọn phiên bản, và nhấn nút xóa

- Tham chiếu:

R.1.6

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn phiên bản rồi chọn nút Delete 2. Hiển thị thông điệp xác nhận muốn

xóa

3. Chọn “Ok” để xóa

- Ngoại lệ:

4. Xóa phiên bản khỏi cơ sở dữ liệu

Không được phép xóa, nếu có phiên bản khác được

phát triển từ nó

3.5.2. Gói quản lý mã nguồn

Hình 10. Biểu đồ Use Case gói quản lý mã nguồn

Mô tả Use Case trong gói quản lý mã nguồn

Uc7. Tạo mã nguồn

- Tên ca sử dụng:

- Tác nhân:

Tạo mã nguồn

Người dùng (User)

- Mục đích:

Khởi tạo mã nguồn với các thông tin cần thiết

- Mô tả khái quát:

Người dùng chọn chức năng tạo mã nguồn rồi nhập

các thông tin cần thiết về mã nguồn đó

- 21 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

- Tham chiếu: R.2.1

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn chức năng tạo mã nguồn

2. Hiển thị form tạo mã nguồn

3. Người dùng nhập các thông tin về

4. Lưu thông tin mã nguồn vào cơ sở

mã nguồn đang tạo vào form, rồi nhấn dữ liệu

“Ok”

- Ngoại lệ:

- Người dùng nhập không đầy đủ hoặc sai thông tin,

yêu cầu nhập lại

- Mã nguồn đã tồn tại, yêu cầu nhập lại

Uc8. Sửa thông tin mã nguồn

- Tên ca sử dụng:

- Tác nhân:

Sửa thông tin mã nguồn

Người dùng (User)

- Mục đích:

Sửa thông tin về mã nguồn nào đó

Người dùng chọn mã nguồn, rồi nhấn nút sửa

R.2.2

- Mô tả khái quát:

- Tham chiếu:

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn mã nguồn cần sửa và nhấn nút 2. Hiển thị form thông tin về mã nguồn

sửa (Change) cho phép sửa đổi

3. Người dùng nhập thông tin cần sửa 4. Lưu thông tin mã nguồn mới sửa

vào form, rồi nhấn “Save

vào cơ sở dữ liệu

- Ngoại lệ:

- Người dùng nhập không đầy đủ hoặc sai thông tin,

yêu cầu nhập lại

Uc9. Xem thông tin mã nguồn

- 22 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

- Tên ca sử dụng:

- Tác nhân:

Xem thông tin mã nguồn

Người dùng (User)

- Mục đích:

Xem thông tin về mã nguồn nào đó

- Mô tả khái quát:

Người dùng chọn mã nguồn và nhấn nút View để xem

thông tin

- Tham chiếu:

R.2.3

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn mã nguồn rồi nhấn nút View

3. Chọn Cancel để thoát

- Ngoại lệ:

2. Hiển thị form thông tin về mã nguồn

4. Thoát form

Uc10. Xóa mã nguồn

- Tên ca sử dụng:

- Tác nhân:

Xóa mã nguồn

Người dùng (User)

- Mục đích:

Xóa thông tin về mã nguồn ra khỏi cơ sở dữ liệu

Người dùng chọn mã nguồn và chọn xóa

R.2.4

- Mô tả khái quát:

- Tham chiếu:

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn mã nguồn cần xóa, rồi nhấn

2. Hiển thị thông điệp xác nhận muốn

nút “Delete”

xóa

3. Người dùng nhấn “Ok” để xóa

4. Xóa mã nguồn trong cơ sở dữ liệu

- Ngoại lệ:

- Mã nguồn không thể bị xóa, thông báo lại cho người

dùng

3.5.3. Gói quản lý nâng cấp phiên bản

- 23 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

Hình 11. Biểu đồ Use Case gói quản lý nâng cấp phiên bản

Mô tả Use Case trong gói quản lý nâng cấp phiên bản

Uc11. Lựa chọn phiên bản hiện dùng

- Tên ca sử dụng:

- Tác nhân:

Lựa chọn phiên bản hiện dùng

Người dùng (User)

- Mục đích:

Lựa chọn một phiên bản làm phiên bản hiện dùng để

mô phỏng nâng cấp

- Mô tả khái quát:

Người dùng nhấn nút chọn chức năng lựa chọn phiên

bản hiện dùng

- Tham chiếu:

R.3.1

- Mô tả diễn biến:

Hành động của tác nhân

Hồi đáp của hệ thống

1. Chọn chức năng lựa chọn phiên bản 2. Hiển thị danh sách các phiên bản để

hiện dùng

người dùng chọn

3. Chọn phiên bản, rồi nhấn “Ok”

- Ngoại lệ:

4. Lưu phiên bản lựa chọn

Uc12. Kiểm tra update

- Tên ca sử dụng:

- Tác nhân:

Kiểm tra update

Người dùng (User)

- Mục đích:

Kiểm tra xem có các phiên bản mới hơn phiên bản

hiện dùng không để nâng cấp

- 24 -

Phân tích hệ thống mô phỏng hoạt động nâng cấp tự động kết hợp với quản lý phiên bản

- Mô tả khái quát:

Người dùng nhấn nút check update, nếu có update,

thông tin về các phiên bản mới sẽ hiện ra, người dùng

lựa chọn phiên bản để nâng cấp

- Tham chiếu:

R.3.2

- Mô tả diễn biến:

Hành động của tác nhân

1. Nhấn nút “Check update”

Hồi đáp của hệ thống

2. Hiển thị thông tin các phiên bản mới

nếu có

3. Chọn phiên bản, rồi nhấn “Ok”

4. Hiển thị tiến trình nâng cấp

- Ngoại lệ:

- Không có phiên bản mới, thông báo cho người dùng

3.6. Biểu đồ tuần tự hệ thống

3.6.1. Gói quản lý phiên bản

Luồng sự kiện “Tạo phiên bản”

Hình 12. Biểu đồ tuần tự luồng sự kiện “Tạo phiên bản”

- 25 -