Bài giảng Quy trình hợp nhất phần mềm

NẮM BẮT YÊU CẦU PHÂN TÍCH THIẾT KẾ HIỆN THỰC KIỂM THỬ 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 MODEL USE_CASE SYSTEM ACTOR USE_CASE 1 * * 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. 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: 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 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? 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. Miêu tả vắn tắt từng Use_Case: tên, trách nhiệm, mối quan hệ,… Miêu tả tổng thể về Use_Case: từ các mối quan hệ è lược đồ Use_Case. 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. Chi tiết hoá Use_Case: mỗi Use_Case có nhiều luồng sự kiện chính và phụ. 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 PACKAGE ANALYSIS MODEL ANALYSIS SYSTEM ANALYSIS CLASS USE_CASE REALIZATION ANALYSIS 1 * * * * * 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. 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. 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 QUI TRÌNH 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. 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. 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. 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,... Phân tích Package: bảo đảm từng class PT độc lập với nhau. 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. DESIGN SUBSYSTEM DESIGN MODEL DESIGN SYSTEM DESIGN CLASS USE_CASE REALIZATION ANALYSIS INTERFACE 1 * * * * * * * * 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. 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 ENGINEER: Thiết kế Class COMPONENT ENGINEER: Thiết kế HT con 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. 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. 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ự. 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ệ. 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 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ự IMPL SUBSYSTEM IMPLEMENTATION MODEL IMPL SYSTEM COMPONENT INTERFACE 1 * * * * * * 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 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ể. 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ế. 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. 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ế 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 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ị 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Ử TEST MODEL TEST SYSTEM TEST CASE TEST COMPONENT TEST PROCEDURE 1 * * * 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ậ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ử. Thiết kế các Test case: tích hợp, hệ thống và các thủ tục kiểm thử. 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. Đá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: 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 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 ? 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) ?