Qui trình hợp nhất phát triển phần mềm (RUP) potx

BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 1
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.
- Flow Of Events: luồng các sự kiện.
- 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.
- 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
NẮM BẮT
YÊU CẦU
PHÂN TÍCH THIẾT KẾ HIỆN THỰC KIỂM THỬ
USE_CASE
MODEL
USE_CASE
SYSTEM
ACTOR USE_CASE
1
*
*
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
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?
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
ANALYST:
Nhận dạng Actor &
Use_Case
ARCHITECT:
Prioritize Use_Case
USE_CASE
SPECIFIER:
Detail a Use_Case
USER_INTERFACE
DESIGNER:
Prototype User_Interface
ANALYST:
Structure the
Use_Case Model
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:
- 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.
LÂM BÌNH – CH0401003
ANALYSIS
PACKAGE
ANALYSIS
MODEL
ANALYSIS
SYSTEM
ANALYSIS
CLASS
USE_CASE REALIZATION
ANALYSIS
1
*
*
*
*
*
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

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
ARCHITECT:
Phân tích kiến trúc
USC ENGINEER:
Phân tích
Use_Case
COMPONENT
ENGINEER:
Phân tích Class
COMPONENT
ENGINEER:
Phân tích Package
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)
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.
- 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
DESIGN
SUBSYSTEM
DESIGN
MODEL
DESIGN

SYSTEM
DESIGN
CLASS
USE_CASE REALIZATION
ANALYSIS
INTERFACE
1
*
*
*
*
*
*
*
*
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
1. Thiết kế kiến trúc:
- 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
ARCHITECT:
Thiết kế kiến trúc
USC ENGINEER:
Thiết kế Use_Case

COMPONENT
ENGINEER:
Thiết kế Class
COMPONENT
ENGINEER:
Thiết kế HT con
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
ARTIFACTS (các sản phẩm cần tạo ra)
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,…
- 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
IMPL
SUBSYSTEM
IMPLEMENTATION
MODEL
IMPL
SYSTEM
COMPONENT
INTERFACE
1
*
*
*
*
*
*
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ị.
LÂM BÌNH – CH0401003
ARCHITECT:
Hiện thực kiến trúc
COMPONENT
ENGINEER:
Hiện thực Class
SYSTEM
INTEGRATOR:
Tích hợp hệ thống
COMPONENT
ENGINEER:
Hiện thực HT con
COMPONENT
ENGINEER:
Kiểm thử đơn vị
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)
Mô hình kiểm thử = Hệ thống kiểm thử

- TEST CASE: 1 trường hợp kiểm thử.
- TEST PROCEDURE: cách thức thực hiện Test case.
- 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
TEST
MODEL
TEST
SYSTEM
TEST CASE
TEST COMPONENT
TEST PROCEDURE
1
*
*
*
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ử.
LÂM BÌNH – CH0401003

TEST ENGINEER:
Kế hoạch kiểm thử
INTEGRATION
TESTER:
Kiểm thử tích hợp
TEST ENGINEER:
Thiết kế Test case
COMPONENT
ENGINEER:
Thực hiện kiểmthử
SYSTEM TESTER
Kiểm thử hệ thống
TEST ENGINEER:
Kiểm các phụ khác
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
1 Abstract Factory O c.cấp interface để khởi tạo đ.tượng mà ko cần x.định lớp cụ thể tương ứng
?
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
?

LÂM BÌNH – CH0401003
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 14
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
1
Chain of
Responsibility
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
2
Template
Method
C
tạo bộ khung giải thuật trong 1 tác vụ, cho phép lớp con được quyền hiện
thức 1 số phần trong tác vụ đó
TL có nói qh
3 Strategy O
cung cấp một họ giải thuật, cho phép Client lựa chọn linh động 1 giải thuật
cụ thể khi sử dụng (vd: chọn mức độ chơi dễ - tb – khó trong games)
TL có nói qh
4 Command O
đóng gói req vào một Obj  có thể thông số hoá c.trình nhận req và
t.hiện các thao tác xử lý req
TL có nói qh
5 State O

cho phép đ.tượng thay đổi hành vi khi trạnh thái bên trong của nó thay đổi.
Có cảm giác như class của đ.tượng đó cũng thay đổi.
?
6 Observer O
đ.nghĩa sự phụ thuộc 1–n sao cho khi 1 đ.tượng thay đổi trạng thái thì các
đ.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
BẢNG TÓM TẮT NỘI DUNG MÔN HỌC UML Trang 15
LÂM BÌNH – CH0401003