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

Tài liệu tham khảo công nghệ thông tin 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

Trang 1

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

Trang 2

ĐẠ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

Trang 3

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

Trang 4

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 Các khái niệm cơ bản trong quản lý cấu hình 3

-1.4.2 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.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.2 Biểu đồ lớp 47

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

Trang 5

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

Trang 9

-Mở đầu

Trang 10

Mở đầu

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àythự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ườnghợ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ộtlỗ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ã 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

Trang 11

Mở đầu

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ảnphẩ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

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

Trang 12

Mở đầu

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:

RoleProject

Manager

CM Responsible

CM Librarian

Tool Responsible

SubsystemCCB

Full System CCB

 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

Trang 13

Mở đầu

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à

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”

Trang 14

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

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

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

Trang 15

Mở đầu

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:

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:

Trang 16

Mở đầu

 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

 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ỗiphầ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

Trang 17

Mở đầu

 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

 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

 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ôngFunctional 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ầntí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ẽ

Trang 18

Mở đầu

đượ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

 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)

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áctrườ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

Trang 19

Mở đầu

 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ữ

Trang 20

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

Trang 21

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

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

Trang 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

Trang 23

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

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

nguồn, file tài liệu,…)Phienban_Manguon Phiên bản phần mềm và mã nguồn phụ

thuộcHanhdongChuyendoi 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

Tác nhân Các ca sử dụng nghiệp Kết quả đem lại

Trang 24

vụNgười sử dụng Tạo phiên bản Tạo phiên bản, lưu vào cơ sở dữ liệu

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

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ênbản

Xác định các file mã nguồn của phiên bản, lưu vào cơ sở dữ liệuSử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ạiXem thông tin phiên bản Hiển thị thông tin về phiên bản được

chọnXóa phiên bản Xóa phiên bản trong cơ sở dữ liệuTạo mã nguồn Tạo mã nguồn mới, lưu vào cơ sở dữ

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

lạiXem thông tin mã nguồn Hiển thị thông tin mã nguồnXóa mã nguồn Xóa mã nguồn trong cơ sở dữ liệuLựa chọn phiên bản hiện

dùng

Chọn một phiên bản làm phiên bản 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

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

Trang 25

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

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ạo phiên bản

Trang 26

- 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

- 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ục tạo phiên bản 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

vào form, rồi nhấn nút “Create”

4 Lưu thông tin phiên bản mới tạo 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: Thiết lập quan hệ giữa các phiên bản

- 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

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

nhấn “Ok”

4 Lưu lại quan hệ giữa các phiên bản vào cơ sở dữ liệu

- Ngoại lệ:

Trang 27

- Tên ca sử dụng: Gán mã nguồn cho phiên bản

- 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

1 Chọn phiên bản cần gán mã nguồn,

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

2 Hiển thị form gán mã nguồn cho phiên bản

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

- Tên ca sử dụng: Sửa thông tin phiên bản

- 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

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

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

4 Lưu lại thông tin phiên bản mới sửađổ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: Xem thông tin phiên bản

Trang 28

- 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

1 Chọn phiên bản rồi chọn nút View 2 Hiển thị thông tin về phiên bản

3 Chọn Cancel để thoát 4 Thoát form

- Ngoại lệ:

Uc6 Xóa phiên bản

- Tên ca sử dụng: Xóa phiên bản

- Mục đích: Xóa phiên bản khỏi cơ sở dữ liệu

- Mô tả khái quát: Người dùng chọn phiên bản, và nhấn nút xóa

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 4 Xóa phiên bản khỏi cơ sở dữ liệu

- Ngoại lệ: 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

Trang 29

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ạo mã nguồn

- 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 đó

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ề

mã nguồn đang tạo vào form, rồi nhấn

“Ok”

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

dữ liệu

- 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: Sửa thông tin mã nguồn

Trang 30

- Mục đích: Sửa thông tin về mã nguồn nào đó

- Mô tả khái quát: Người dùng chọn mã nguồn, rồi nhấn nút sửa

1 Chọn mã nguồn cần sửa và nhấn nút

sửa (Change)

2 Hiển thị form thông tin về mã nguồncho phép sửa đổi

3 Người dùng nhập thông tin cần sửa

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

4 Lưu thông tin mã nguồn mới sửa vào cơ sở dữ liệu

Uc9 Xem thông tin mã nguồn

- Tên ca sử dụng: Xem thông tin mã nguồn

- 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

1 Chọn mã nguồn rồi nhấn nút View 2 Hiển thị form thông tin về mã nguồn

3 Chọn Cancel để thoát 4 Thoát form

- Ngoại lệ:

Uc10 Xóa mã nguồn

- Tên ca sử dụng: Xóa mã nguồn

- Mục đích: Xóa thông tin về mã nguồn ra khỏi cơ sở dữ liệu

- Mô tả khái quát: Người dùng chọn mã nguồn và chọn xóa

Trang 31

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

nút “Delete”

2 Hiển thị thông điệp xác nhận muốn 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

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: Lựa chọn phiên bản hiện dùng

- 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

1 Chọn chức năng lựa chọn phiên bản

Trang 32

- Ngoại lệ:

Uc12 Kiểm tra update

- Tên ca sử dụng: Kiểm tra update

- 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

- 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ùnglựa chọn phiên bản để nâng cấp

1 Nhấn nút “Check update” 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”

Trang 33

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

Luồng sự kiện “Thiết lập quan hệ phiên bản”

Hình 13 Biểu đồ tuần tự luồng sự kiện “Thiết lập quan hệ phiên bản”

Luồng sự kiện “Gán mã nguồn cho phiên bản”

Định dạng
Số trang	66
Dung lượng	1,89 MB

Tài liệu tham khảo	Loại	Chi tiết
[3] Ngô Văn Toàn. Giới thiệu về quản lý cấu hình phần mềm.http://www.fpt.edu.vn/chitiet.php?id=129	Link
[6] Mika Karlstedt. Dynamic upgrade of software [7] Wikipedia.http://en.wikipedia.org/wiki/Software_maintenancehttp://en.wikipedia.org/wiki/Revision_controlhttp://en.wikipedia.org/wiki/Subversion_(software)	Link
[1] Nguyễn Thị Hoa. Hệ thống quản lý phiên bản phần mềm. Luận văn tốt nghiệp ngành công nghệ thông tin – Đại học Công Nghệ, 2008	Khác
[2] ThS Đào Kiến Quốc. Bài giảng Quản lý cấu hình. Khoa Công nghệ Thông tin – Đại Học Công Nghệ	Khác
[4] Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilat. Version Control with Subversion	Khác
[5] Marcin Solarski. Dynamic Upgrade of Distributed Software Components, January – 2004, tr. 19-31	Khác