Qui trình hợp nhất phần mềm (RUP)
Tài liệu tóm tắt cho các thiết kế phần mềm, từ nắm bắt yêu cầu, phân tích, thiết kế, hiện thực, chạy thử
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 1
NẮM BẮT
PHÂN TÍCH THIẾT KẾ HIỆN THỰC KIỂM THỬ
YÊU CẦU
WORKFLOW REQUIREMENT NẮM BẮT YÊU CẦU
ARTIFACTS (các sản phẩm cần tạo ra)
- ACTORS: người hay hệ thống thiết bị ngoài tương tác vào hệ thống.
- USE_CASE: các chức năng hệ thống cung cấp cho Actor.
USE_CASE 1 USE_CASE
- Flow Of Events: luồng các sự kiện. MODEL SYSTEM
- Các yêu cầu đặc biệt của các Use_Case.
- VIEW OF USE_CASE MODEL: đặc tả kiến trúc. * *
ACTOR USE_CASE
- GLOSSARY: bảng thuật ngữ.
- USER_INTERFACE PROTOTYPE: các prototype giao diện người dùng.
WORKERS
- SYSTEM ANALYST: chịu trách nhiệm về Use_Case Model, Actor và Glossary.
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 2
- USE_CASE SPECIFIER: chịu trách nhiệm về Use_Case.
- USER INTERFACE DESIGNER: chịu trách nhiệm về User_Interface Prototype.
- ARCHITECT: chịu trách nhiệm về Architecture Desciption.
QUI TRÌNH
ANALYST:
ANALYST:
Nhận dạng Actor &
Structure the
Use_Case
Use_Case Model
ARCHITECT:
Prioritize
Use_Case
USE_CASE
SPECIFIER:
Detail a Use_Case
USER_INTERFACE
DESIGNER:
1. Tìm và nhận dạng Actor: trả lời các câu hỏi AI? Hệ THốNG, THIếT Bị NÀO?
Prototype User_Interface
2. Tìm và nhận dạng Use_Case: trả lời các câu hỏi CÁI GÌ? Hệ thống cung cấp cho actor những gì và actor cần gì ở hệ thống.
3. Miêu tả vắn tắt từng Use_Case: tên, trách nhiệm, mối quan hệ,…
4. Miêu tả tổng thể về Use_Case: từ các mối quan hệ lược đồ Use_Case.
5. Sắp xếp thứ tự ưu tiên các Use_Case: phát triển Use_case nào trước, nào sau.
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 3
6. Chi tiết hoá Use_Case: mỗi Use_Case có nhiều luồng sự kiện chính và phụ.
7. Cấu trúc lại mô hình Use_Case: nhận dạng và rút trích các Use_case tổng quát, mở rộng hay bao gộp
MỘT SỐ NỘI DUNG LIÊN QUAN
Mục đích của NBYC: Xây dựng mô hình hệ thống sử dụng Use_Case, bắt đầu từ mô hình nghiệp vụ cho các ứng dụng nghiệp vụ; từ
mô hình lĩnh vực cho các ừng dụng nhúng, từ đặc tả yêu cầu hệ thống bởi các nhóm khác nhau với phương
pháp đặc tả khác nhau.
Các loại quan hệ: Actor & Actor t.quát hoá; Actor & Use_case l.kết; Use_case & Use_case t.quát hoá / mở rộng / bao gộp.
Các loại lược đồ: Trạng thái (UML) có thể dùng để miêu tả trạng thái của Use_case hay sự chuyển đổi giữa các trạng thái.
Hoạt động dùng để miêu tả sự chuyển trạng thái chi tiết hơn dưới dạng các hoạt động.
Tương tác miêu tả sự tương tác giữa các đối tượng (actor, use_case).
WORKFLOW ANALYSIS – PHÂN TÍCH
ARTIFACTS (các sản phẩm cần tạo ra) Mô hình phân tích = Hệ thống phân tích
- ANALYSIS CLASS: 3 loại: Biên (Boundary) - Thực thể (Entity) - Điều khiển (Control).
*
- USE_CASE REALIZATION ANALYSIS: ANALYSIS ANALYSIS ANALYSIS
1 *
MODEL SYSTEM PACKAGE
- Các lược đồ class phân tích, tương tác, cộng tác,…
- Luồng sự kiện và các yêu cầu đặc biệt của Use_Case.
- ANALYSIS PACKAGE. * *
ANALYSIS* USE_CASE REALIZATION
CLASS ANALYSIS
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 4
- VIEW OF ANALYSIS MODEL: đặc tả kiến trúc.
WORKERS
- ARCHITECT: chịu trách nhiệm về Analysis Model, Analysis System, Architecture Description.
- USE_CASE ENGINEER: chịu trách nhiệm về Use_Case Realization.
- COMPONENT ENGINEER: chịu trách nhiệm về Analysis Class và Package.
QUI TRÌNH
ARCHITECT:
Phân tích kiến trúc
USC ENGINEER:
Phân tích
Use_Case
COMPONENT COMPONENT
ENGINEER: ENGINEER:
Phân tích Class Phân tích Package
1. Phân tích kiến trúc: nhận dạng các Package và Class PT.
- Nhận dạng Package: các Package PT tổ chức hệ thống thành các đơn vị nhỏ, dễ quản lý. Mỗi Package chứa một số
Use_case có tính chất: hỗ trợ cho cùng 1 Actor; hỗ trợ cho cùng qui trình nghiệp vụ hoặc là có quan hệ lẫn nhau.
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 5
- Nhận dạng Class: mặc dù có 3 loại class PT, nhưng vì từ các class lĩnh vực hay nghiệp vụ (ở bước NBYC) và vì class
Thực thể dễ thấy nên ở bước này ta chỉ nhận dạng class thực thể. Các loại Class khác, sẽ được nhận dạng trong bước
phân tích Use_Case.
2. Phân tích Use_Case:
- Nhận dạng các Class PT: nhận dạng các loại Class biên, thực thể, điều khiển cần thiết để hiện thực Use_case; phát
hoạ tên, trách nhiệm, thuộc tính và mối quan hệ giữa chúng,.. theo hướng dẫn sau:
- Nhận dạng các class Thực thể trước bằng cách chú ý thông tin trong đặc tả Use_case và trong mô hình lĩnh vực.
- Nhận dạng các class biên cơ sở cho các class thực thể vừa tìm được.
- Nhận dạng class biên trung tâm cho mỗi Actor là người.
- Nhận dạng class biên trung tâm cho mỗi Actor là hệ thống ngoài hay thiết bị I/O.
- Nhận dạng các class điều khiển có trách nhiệm xử lý trong dẫn xuất Use_case.
- Miêu tả sự tương tác giữa các đối tượng PT: dùng lược đồ CỘNG TÁC để biết Actor làm gì, có quan hệ với đối tượng
nào, các mối quan hệ giữa các Use_case.
3. Phân tích Class:
- Nhận dạng Class bằng nghĩa vụ.
- Nhận dạng Class bằng thuộc tính.
- Nhận dạng Class bằng mối quan hệ giữa các class: đối tượng này chứa vật lý đối tượng (bao gộp); đối tượng này
được xây dựng từ các đối tượng khác (liên kết); đối tượng này là tập hợp của nhiều đối tượng rời,...
4. Phân tích Package: bảo đảm từng class PT độc lập với nhau.
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 6
MỘT SỐ NỘI DUNG LIÊN QUAN
Mục đích của PT: Xây dựng mô hình phân tích hệ thống với các đặc điểm: dùng ngôn ngữ nhà thiết kế để miêu tả mô hình; thể hiện
góc nhìn từ bên trong của hệ thống; được cấu trúc từ các class và Package PT ; được dùng chủ yếu bởi nhà phát
triển để hiểu cách thức tạo hình dạng hệ thống; loại trừ các chi tiết thừa, ko nhất quán; phát hoạ các hiện thực
chức năng trong hệ thống; định nghĩa các dẫn xuất Use_case, 1 dẫn xuất PT miêu tả sự phân tích 1 Use_case.
3 loại Class PT: Biên (Boundary): mô hình tương tác giữa Actor và hệ thống; Thực thể: mô hình thông tin cần cho hệ thống, loại thông
tin vững bền, tồn tại lâu dài; Điều khiển: mô hình xử ý, cộng tác, giao tác trong Use_case.
WORKFLOW DESIGN - THIẾT KẾ
*
ARTIFACTS (các sản phẩm cần tạo ra) DESIGN 1 DESIGN DESIGN
*
MODEL SYSTEM SUBSYSTEM
Mô hình thiết kế = Hệ thống thiết kế
- SUBSYSTEM: các hệ thống con.
* * * * *
- DESIGN CLASS: các Class TK. DESIGN * USE_CASE REALIZATION
ANALYSIS INTERFACE
CLASS
- INTERFACE CỦA SUBSYSTEM VÀ CLASS
- USE_CASE REALIZATION DESIGN:
- Các lược đồ class thiết kế, tương tác (trình tự, trạng thái,…)
- Luồng sự kiện cấp thiết kế và các yêu cầu cấp hiện thực.
- VIEW OF DESIGN MODEL: đặc tả kiến trúc.
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 7
Mô hình bố trí
- VIEW OF DEPLOYMENT MODEL: đặc tả kiến trúc.
WORKERS
- ARCHITECT: chịu trách nhiệm về Design Model, Deployment System, Architecture Description.
- USE_CASE ENGINEER: chịu trách nhiệm về Use_Case Realization Design.
- COMPONENT ENGINEER: chịu trách nhiệm về Design Subsystem, Design Class và Interface.
QUI TRÌNH
ARCHITECT:
Thiết kế kiến trúc
USC ENGINEER:
Thiết kế Use_Case
COMPONENT COMPONENT
ENGINEER: ENGINEER:
1. Thiết kế kiến trúc: Thiết kế Class Thiết kế HT con
- Nhận dạng nút và cấu hình mạng: để biết các nút liên quan, kiểu kết nối giữa các nút.
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 8
- Nhận dạng hệ thống con và Interface của chúng.
- Nhận dạng các class TK quan trọng về kiến trúc: từ các class PT tương ứng.
- Nhận dạng các cơ chế thiết kế tổng quát: từ các yêu cầu chung và đặc biệt đã được nhận dạng từ phần PT.
2. Thiết kế Use_case:
- Nhận dạng các class thiết kế: từ các class PT, cho phép tinh chỉnh.
- Miêu tả các tương tác giữa các đối tượng TK: dùng lược đồ trình tự.
3. Thiết kế Class:
- Phát hoạ Class TK: từ các Class PT và các Interface.
- Nhận dạng các tác vụ: dựa vào trách nhiệm, yêu cầu đặc biệt, interface hay dẫn xuất của Class PT tương ứng với Class TK.
- Nhận dạng các thuộc tính: cũng dựa trên các thuộc tính của class PT tương ứng với class TK.
- Nhận dạng các mối quan hệ kết hợp và gộp: trước hết, nhận dạng mối quan hệ từ class PT, tinh chế số phần tử tham gia,
tên vai trò, tính chất,…và hướng của mối quan hệ.
4. Thết kế hệ thống con:
- Duy trì phụ thuộc giữa các hệ thống con (thông qua Interface), bố trí lại để tối thiểu hoá sự phụ thuộc.
- Duy trì Interface các hệ thống con.
- Duy trì nội dung của các hệ thống con.
MỘT SỐ NỘI DUNG LIÊN QUAN
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 9
Mục đích của TK: Tạo đầu vào cho hoạt động hiện thực bằng cách nắm bắt các hệ thống con, Interface và class; Chia công việc hiện
thực ra nhiều phần dễ quản lý và xử lý bởi các đội khác nhau; có thể hiển thị trực quan hay xem xét bản thiết kế
dùng các kí hiệu chung; tạo mức trừu tượng cho sự hiện thực hệ thống.
Lược đồ trình tự
WORKFLOW IMPLEMENTATION - HIỆN THỰC
*
IMPLEMENTATION 1 IMPL IMPL
ARTIFACTS (các sản phẩm cần tạo ra) *
MODEL SYSTEM SUBSYSTEM
Mô hình hiện thực = Hệ thống hiện thực
- IMPLEMENTATION SUBSYSTEM: các hệ thống con hiện thực.
* * *
*
- COMPONENT: exe, file, lib, table, doc,… COMPONENT INTERFACE
- INTERFACE CỦA SUBSYSTEM VÀ COMPONENT.
- KẾ HOẠCH TÍCH HỢP CÁC “BUILD”.
- VIEW OF DESIGN MODEL: đặc tả kiến trúc.
WORKERS
- ARCHITECT: chịu trách nhiệm về IMPL Model, Deployment System, Architecture Description.
- SYSTEM INTEGRATOR: chịu trách nhiệm về Integrator Build Plan.
- COMPONENT ENGINEER: chịu trách nhiệm về IMPL Subsystem, Component và Interface.
QUI TRÌNH
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 10
1. Hiện thực kiến trúc: nhận dạng các thành phần kiến trúc khả thi, 1 class được thực hiện trong 1 t.phần khả thi trở thành 1
process chạy ở 1 nút cụ thể.
2. Tích hợp hệ thống: tích hợp các Build (chọn cùng version, chú ý đến mối quan hệ phụ thuộc), mỗi build hiện thực hoàn chỉnh
Use_case ứng với mỗi Use_case cấp tiết kế.
3. HIện thực hệ thống con: bảo đảm hệ thống con hoàn thành vai trò trong mỗi build.
4. Hiện thực Class: phát hoạ 1 file chứa mã nguồn của 1 class (VC++ hoặc Java) thiết kế
5. Thực hiện kiểm tra đơn vị: kiểm thử hộp đen – hành vi thấy từ bên ngoài; kiểm thử hộp trắng – hiện thực bên trong đơn vị.
ARCHITECT:
Hiện thực kiến trúc
SYSTEM
INTEGRATOR:
Tích hợp hệ thống
COMPONENT
ENGINEER:
Hiện thực Class
COMPONENT
COMPONENT
ENGINEER:
ENGINEER:
Kiểm thử đơn vị
Hiện thực HT con
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 11
MỘT SỐ NỘI DUNG LIÊN QUAN
Mục đích của TK: HIện thực các class và hệ thống con TK. Kiểm tra đơn vị trên các thành phần trước khi gửi đi kiểm tra tích hợp hoặc
kiểm tra hệ thống.
Build: là phần mềm được hiện thực theo từng bước nhỏ cho dễ quản lý – là 1 version khả thi của hệ thống.
WORKFLOW TEST - KIỂM THỬ
ARTIFACTS (các sản phẩm cần tạo ra)
TEST 1 TEST
Mô hình kiểm thử = Hệ thống kiểm thử MODEL SYSTEM
- TEST CASE: 1 trường hợp kiểm thử.
- TEST PROCEDURE: cách thức thực hiện Test case. * *
*
TEST CASE TEST PROCEDURE TEST COMPONENT
- TEST COMPONENT: tự động hoá 1 hay nhiều thủ tục kiểm thử.
- PLAN TEST: chiến lược tài nguyên hay lịch.
- EVALUATE TEST: phụ các Test case, code hay trạng thái lỗi.
WORKERS
- TEST ENGINEER: chịu trách nhiệm về Test Model, Test case, Tset plan, Test procedure, Evaluate test.
- COMPONENT ENGINEER: Test Component.
- INTEGRATION TESTER và SYSTEM TESTER: Test defect
QUI TRÌNH
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 12
1. Lập kế hoạch kiểm thử: chủ yếu dùng mô hình Use_Case hoặc Thiết kế để miêu tả chiến lược kiểm thử.
2. Thiết kế các Test case: tích hợp, hệ thống và các thủ tục kiểm thử.
3. Thực hiện kiểm thử: dùng các Test case đã thiết kế để tiến hành kiểm thử tích hợp, hệ thống. So sánh kết quả kiểm thử với
kết quả kì vọng.
4. Đánh giá kiểm thử: kỹ sư cần quan tâm đến 2 thước đo chính: mức độ hoàn thành kiểm thử và độ tin cậy. Lập tài liệu về kiểm
thử.
TEST ENGINEER: TEST ENGINEER:
Kế hoạch kiểm thử Kiểm các phụ khác
TEST ENGINEER:
Thiết kế Test case
INTEGRATION
TESTER:
Kiểm thử tích hợp
SYSTEM TESTER
Kiểm thử hệ thống
COMPONENT
ENGINEER:
Thực hiện kiểmthử
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 13
STT TÊN MẪU OBJ/CLASS NGỮ CẢNH DÙNG MẪU GHI CHÚ
CÁC MẪU CẤU TRÚC (6): Không chỉ thiết kế p.mềm đúng mà còn hạn chế lỗi hoặc hỗ trợ tái thiết kế trong tương lai
1 Adapter O/C chuyển đổi Interface của Class thành một interface khác TL có nói qh
2 Composite O tạo quan hệ thứ bậc, bao gộp Qh bao gộp
3 Proxy O tạo đối tượng đại diện cho đối tượng khác, đối tượng đại diện gọi là Proxy ?
4 Decorator O thêm “động” nhiệm vụ cho 1 số đối tượng cụ thể theo mong muốn ?
5 Façade O cung cấp 1 interface hợp nhất các interface của các hệ thống con Thầy giảng
6 Flyweight O dùng phương tiện dùng chung để quản lý số lượng lớn các đối tượng nhỏ Thầy giảng
CÁC MẪU KHỞI TẠO (5): giúp hệ thống linh hoạt trong việc khởi tạo, quản lý và sử dụng đối tượng
c.cấp interface để khởi tạo đ.tượng mà ko cần x.định lớp cụ thể tương
1 Abstract Factory O ?
ứng
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 14
2 Factory Method O cho phép 1 lớp chuyển quyền khởi tạo đối tượng cho lớp con ?
3 Prototype O khởi tạo đối tượng bằng cách copy Prototype) một đối tượng đang tồn tại ?
4 Builder O tách việc xây dựng đối tượng phức tạp khỏi việc miêu tả nó ?
5 Singleton C đảm bảo 1 class có 1 instance, c.cấp 1 điểm t.xuất toàn cục đến đ.tượng ?
STT TÊN MẪU OBJ/CLASS NGỮ CẢNH DÙNG MẪU GHI CHÚ
CÁC MẪU ĐẶC TẢ HÀNH VI (6): tập trung vào giải thuật và sự phân bố công việc giữa các đối tượng
Chain of
1 C tránh gắn kết cứng giữa phần tử gửi request với p.tử nhận và xử lý req TL có nói qh
Responsibility
Template tạo bộ khung giải thuật trong 1 tác vụ, cho phép lớp con được quyền hiện
2 C TL có nói qh
Method thức 1 số phần trong tác vụ đó
cung cấp một họ giải thuật, cho phép Client lựa chọn linh động 1 giải
3 Strategy O thuật cụ thể khi sử dụng (vd: chọn mức độ chơi dễ - tb – khó trong TL có nói qh
games)
đóng gói req vào một Obj có thể thông số hoá c.trình nhận req và
4 Command O TL có nói qh
t.hiện các thao tác xử lý req
LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 15
cho phép đ.tượng thay đổi hành vi khi trạnh thái bên trong của nó thay
5 State O ?
đổi. Có cảm giác như class của đ.tượng đó cũng thay đổi.
đ.nghĩa sự phụ thuộc 1–n sao cho khi 1 đ.tượng thay đổi trạng thái thì các
6 Observer O ?
đ.tượng khác đc cảnh báo hầu hiệu chỉnh tự động (đảm bảo nhất quán)
LÂM BÌNH – CH0401003