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.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 -
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 -
65 trang |
Chia sẻ: netpro | Lượt xem: 1563 | Lượt tải: 1
Bạn đang xem trước 20 trang tài liệu 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, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
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
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.
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
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)
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.
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:
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
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.
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
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
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
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á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ữ
CHƯƠNG 2
THỰC TRẠNG VÀ GIẢI PHÁP
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.
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.
Đề 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.
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
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
Mô tả
Phienban
Phiên bản của phần mềm
Manguon
Mã nguồn của phần mềm (file mã nguồn, file tài liệu,…)
Phienban_Manguon
Phiên bản phần mềm và mã nguồn phụ thuộc
HanhdongChuyendoi
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 vụ
Kết quả đem lại
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ên bản
Xác định các file mã nguồn của 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
Xóa phiên bản trong cơ sở dữ liệu
Tạo mã nguồn
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 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)
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
Uc6. Xóa phiên bản
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
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
- Tác nhâ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
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
- Tác nhâ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:
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 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ệ:
Uc3. Gán mã nguồn cho phiên bản
- Tên ca sử dụng:
Gán mã nguồn cho phiên bản
- Tác nhâ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, rồi chọn nút “add/remove source”
2. Hiển thị form gán mã nguồn cho 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:
Sửa thông tin phiên bản
- Tác nhâ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
- 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 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
- Tác nhâ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
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
- Tác nhân:
Người dùng (User)
- 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
- 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
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
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
- Tác nhâ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 đó
- 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ề 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
- 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:
Sửa thông tin mã nguồn
- Tác nhân:
Người dùng (User)
- 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
- Tham chiếu:
R.2.2
- 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 sửa (Change)
2. Hiển thị form thông tin về mã nguồn cho 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
- 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
- Tên ca sử dụng:
Xem thông tin mã nguồn
- Tác nhâ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
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
- Tác nhâ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
- Mô tả khái quát:
Người dùng chọn mã nguồn và chọn xóa
- Tham chiếu:
R.2.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 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
- Tác nhân:
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 hiện dùng
2. Hiển thị danh sách các phiên bản để người dùng chọn
3. Chọn phiên bản, rồi nhấn “Ok”
4. Lưu phiên bản lựa chọn
- Ngoại lệ:
Uc12. Kiểm tra update
- Tên ca sử dụng:
Kiểm tra update
- Tác nhân:
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
- 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
Hồi đáp của hệ thống
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”
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”
Hình 14. Biểu đồ tuần tự luồng sự kiện “Gán mã nguồn cho phiên bản”
Luồng sự kiện “Sửa thông tin phiên bản”
Hình 15. Biểu đồ tuần tự luồng sự kiện “Sửa thông tin phiên bản”
Luồng sự kiện “Xem thông tin phiên bản”
Hình 16. Biểu đồ tuần tự luồng sự kiện “Xem thông tin phiên bản”
Luồng sự kiện “Xóa phiên bản”
Hình 17. Biểu đồ tuần tự luồng sự kiện “Xóa phiên bản”
3.6.2. Gói quản lý mã nguồn
Luồng sự kiện “Tạo mã nguồn”
Hình 18. Biểu đồ tuần tự luồng sự kiện “Tạo mã nguồn”
Luồng sự kiện “Sửa thông tin mã nguồn”
Hình 19. Biểu đồ tuần tự luồng sự kiện “Sửa thông tin mã nguồn”
Luồng sự kiện “Xem thông tin mã nguồn”
Hình 20. Biểu đồ tuần tự luồng sự kiện “Xem thông tin mã nguồn”
Luồng sự kiện “Xóa mã nguồn”
Hình 21. Biểu đồ tuần tự luồng sự kiện “Xóa mã nguồn”
3.6.3. Gói quản lý nâng cấp phiên bản
Luồng sự kiện “Lựa chọn phiên bản hiện dùng”
Hình 22. Biểu đồ tuần tự luồng sự kiện “Lựa chọn phiên bản hiện dùng”
Luồng sự kiện “Kiểm tra update”
Hình 23. Biểu đồ tuần tự luồng sự kiện “Kiểm tra update”
3.7. Hợp đồng cho các thao tác hệ thống
Op1. Tạo phiên bản
Tên
Tạo phiên bản
Trách nhiệm
Tạo một phiên bản mới của phần mềm
Tham chiếu
Uc1
Ngoại lệ
Trùng với phiên bản đã có, hoặc người dùng nhập sai thông tin
Đầu ra
Thông báo phiên bản có được tạo hay không
Tiền điều kiện
Hậu điều kiện
Phiên bản mới phải có ngày release sau ngày các phiên bản trước
Op2. Thiết lập quan hệ phiên bản
Tên
Thiết lập quan hệ phiên bản
Trách nhiệm
Thiết lập quan hệ giữa các phiên bản được chọn với nhau, phiên bản nào phát triển từ phiên bản nào
Tham chiếu
Uc2
Ngoại lệ
Đầu ra
Thông báo mối quan hệ được thiết lập hay không
Tiền điều kiện
Hậu điều kiện
Phiên bản được phát triển từ phiên bản khác phải là phiên bản được tạo muộn hơn
Op3. Gán mã nguồn cho phiên bản
Tên
Gán mã nguồn cho phiên bản
Trách nhiệm
Bổ sung hoặc loại bỏ các mã nguồn có trong 1 phiên bản cụ thể
Tham chiếu
Uc3
Ngoại lệ
Đầu ra
Thông báo các mã nguồn đã được gán tới phiên bản
Tiền điều kiện
Hậu điều kiện
Mã nguồn được tạo ra sau, không được phép gán tới phiên bản trước đó
Op4. Sửa thông tin phiên bản
Tên
Sửa thông tin phiên bản
Trách nhiệm
Sửa đổi thông tin của phiên bản và cập nhật vào cơ sở dữ liệu
Tham chiếu
Uc4
Ngoại lệ
Người dùng nhập không đầy đủ hoặc sai thông tin
Đầu ra
Thông báo thông tin phiên bản đã được thay đổi
Tiền điều kiện
Hậu điều kiện
Ngày release không được sớm hơn ngày tạo các mã nguồn của nó, và phải thỏa mãn trong mối quan hệ với các phiên bản khác
Op5. Xem thông tin phiên bản
Tên
Xem thông tin phiên bản
Trách nhiệm
Xem thông tin chi tiết của một phiên bản
Tham chiếu
Uc5
Ngoại lệ
Đầu ra
Hiển thị thông tin phiên bản
Tiền điều kiện
Hậu điều kiện
Op6. Xóa phiên bản
Tên
Xóa phiên bản
Trách nhiệm
Xóa phiên bản khỏi hệ thống và cơ sở dữ liệu
Tham chiếu
Uc6
Ngoại lệ
Không được phép xóa, nếu có phiên bản được phát triển từ phiên bản này
Đầu ra
Thông báo phiên bản có được xóa hay không
Tiền điều kiện
Hậu điều kiện
Op7. Tạo mã nguồn
Tên
Tạo mã nguồn
Trách nhiệm
Tạo mã nguồn và lưu thông tin của nó
Tham chiếu
Uc7
Ngoại lệ
Người dùng nhập không đầy đủ hoặc sai thông tin, hoặc là trùng tên mã nguồn khác có trong cơ sở dữ liệu
Đầu ra
Thông báo mã nguồn có được tạo hay không
Tiền điều kiện
Hậu điều kiện
Op8. Sửa thông tin mã nguồn
Tên
Sửa thông tin mã nguồn
Trách nhiệm
Sửa thông tin của mã nguồn và lưu lại vào cơ sở dữ liệu
Tham chiếu
Uc8
Ngoại lệ
Người dùng nhập không đầy đủ hoặc sai thông tin
Đầu ra
Thông báo thông tin mã nguồn đã được thay đổi
Tiền điều kiện
Hậu điều kiện
Ngày tạo mã nguồn không được muộn hơn ngày release của các phiên bản mà mã nguồn phụ thuộc
Op9. Xem thông tin mã nguồn
Tên
Xem thông tin mã nguồn
Trách nhiệm
Xem thông tin chi tiết về mã nguồn
Tham chiếu
Uc9
Ngoại lệ
Đầu ra
Hiển thị thông tin mã nguồn
Tiền điều kiện
Hậu điều kiện
Op10. Xóa mã nguồn
Tên
Xóa mã nguồn
Trách nhiệm
Xóa mã nguồn khỏi cơ sở dữ liệu
Tham chiếu
Uc10
Ngoại lệ
Mã nguồn không thể bị xóa, do nó đang có trong một phiên bản nào đó
Đầu ra
Thông báo mã nguồn có được xóa hay không
Tiền điều kiện
Hậu điều kiện
Op11. Lựa chọn phiên bản hiện dùng
Tên
Lựa chọn phiên bản hiện dùng
Trách nhiệm
Chọn một trong số các phiên bản làm phiên bản hiện tại của hệ thống
Tham chiếu
Uc11
Ngoại lệ
Đầu ra
Thông báo phiên bản hiện dùng
Tiền điều kiện
Hậu điều kiện
Op12. Kiểm tra update
Tên
Kiểm tra update
Trách nhiệm
Kiểm tra xem có phiên bản mới không để nâng cấp
Tham chiếu
Uc12
Ngoại lệ
Không có phiên bản mới
Đầu ra
Hiển thị tiến trình nâng cấp
Tiền điều kiện
Hậu điều kiện
Thay đổi phiên bản hiện dùng thành phiên bản vừa nâng cấp
CHƯƠNG 4
THIẾT KẾ HỆ THỐNG MÔ PHỎNG HOẠT ĐỘNG
Các file đính kèm theo tài liệu này:
- 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.doc