Bài giảng Chương 2 phát triển phần mềm

Mụcđich:Chươngnàytậptrungvàocác hoạtđộngvà cácnguyêntắc để phát triển phầnmềmtheo hướngcấutrúc và hướngđốitượng

pdf139 trang | Chia sẻ: mamamia | Ngày: 04/02/2015 | Lượt xem: 1305 | Lượt tải: 0download
Bạn đang xem nội dung tài liệu Bài giảng Chương 2 phát triển phần mềm, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
CHƯƠNG 2 PHÁT TRIỂN PHẦN MỀM Mục đich: Chương này tập trung vào các hoạt động và các nguyên tắc để phát triển phần mềm theo hướng cấu trúc và hướng đối tượng NỘI DUNG 2.1 Các hoạt động phát triển p/mềm 2.1.1 Thiết kế phần mềm 2.1.2 Sinh mã – hiện thực, triển khai 2.1.3 Kiểm thử phần mềm 2.2 Nghệ thuật gỡ rối 2.2.1 Brute-force (ép buộc) 2.2.2 Loại trừ nguyên nhân 2.2.3 Theo vết 2.1 Các hoạt động phát triển p/mềm • Các giai đoạn p/triển gồm: 2.1.1 Thiết kế phần mềm (software design); 2.1.2 Sinh mã (code generation); 2.1.3 Kiểm thử phần mềm (software testing) 2.1.1 Thiết kế phần mềm • Là công việc đầu tiên của giai đoạn ↑ • Nhằm tạo ra các biểu diễn và dữ kiện của hệ thống p/mềm cần x/dựng từ kết quả phân tích yêu cầu để có thể dễ dàng thực hiện sau đó • Là lĩnh vực tương đối mới mẻ và đang phát triển với nhiều phương pháp khác nhau 2.1.1 Thiết kế phần mềm 2.1.1.1 Cơ sở của thiết kế p/mềm 2.1.2.2 Phân chia module hiệu quả 2.1.2.3 Các hoạt động thiết kế 2.1.2.3 Phương pháp thiết kế cổ điển 2.1.2.4 Phương pháp thiết kế hướng đối tượng 2.1.1.1 Cơ sở của thiết kế p/mềm • a) Trừu tượng hóa • b) Tinh chế • c) Phân chia moddule • d) Kiến trúc phần mềm • e) Cấu trúc dữ liệu • f) Thủ tục • g) Che dấu thông tin a) Trừu tượng hóa • Quá trình thiết kế trải qua nhiều mức độ trừu tượng hóa khác nhau: – Mức cao nhất: Vần đề cần thiết kế được mô tả một cách tổng quát sử dụng thuật ngữ hướng vấn đề – Mức thấp hơn: Hướng đến thủ tục xử lý chi tiết; kết hợp các thuật ngữ hướng đến hiện thực – Mức thấp nhất: Vấn đề được mô tả theo cách có thể thực hiện trực tiếp a) Trừu tượng hóa • Phân loại giữa trừu tượng hóa thủ tục và dữ liệu * Trừu tượng hóa thủ tục: Là chuỗi các lệnh liên tiếp thực hiện một chức năng nào đó. Ví dụ: - Mở cửa bao gồm: đi đến cửa, cầm lấy tay nắm, xoay tay nám, kéo cánh cửa ra - Thêm một phần tử vào danh sách có thứ tự: Xác định vị trí, chèn phần tử mới a) Trừu tượng hóa • * Trừu tượng hóa dữ liệu: Là tổ hợp dữ liệu mô tả một đối tượng dữ liệu • Ví dụ: một đối tượng thực thể là sự trừu tượng hóa của các tính chất và hành vi b) Tinh chế • Tinh chế là quá trình làm rõ vấn đề. Tinh chế và trừu tượng hóa là 2 khái niệm bù trừ nhau thể hiện: Càng tinh chế thì càng hạ thấp mức độ trừu tượng hóa c) Phân chia moddule • p/mềm được thực hiện bằng cách phân chia thành nhiều module, sau đó sẽ được tích hợp lại • Phân chia module làm cho việc quản lý phần mềm khoa học hơn. Thật vậy: – Giả sử C(x) là độ phức tạp của X, E(X) là công sức để thực hiện X. Rõ ràng nếu C(p1)>C(p2) thì E(p1)>E(p2). Nếu phân chia p = p1+p2 ta thấy (một cách trực quan) C(p1+p2) >C (p1)+C(p2)  E(p1+p2)>E(p1) +E(p2) c) Phân chia moddule • Số lượng module phụ thuộc vào độ phức tạp của hệ thống phần mềm cần xây dựng. Quá ít hay quá nhiều module đều không tốt Công sức bỏ ra Vùng tối ưu Công sức tích hợp Công sức từng module Số lượng module d) Kiến trúc phần mềm • Kiến trúc phần mềm mô tả các thành phần kiến tạo nên hệ thống phần mềm và sự giao tiếp giữa các thành phần đó. => Kiến trúc p/m = tập hợp các module/thành phần và quan hệ giữa chúng – Các thành phần/module có thể là: • Các module mã nguồn: hàm/nhóm hàm/lớp • Các file thực thi (*.dll. *.exe; *.class) • Các thành phần của kiến trúc hệ thống: ActiveX control, bean, ... • Các trang html: *.asp, *.jsp – Quan hệ: Sử dụng/gọi/kế thừa, …. Phần mềm nhìn từ cấu trúc phân cấp • Cấu trúc phần mềm là cấu trúc phân cấp (hierarchical structure): mức trên là hệ thống (system), dưới là các hệ thống con (subsystems) • Dưới hệ thống con là các chương trình • Dưới chương trình là các Modules hoặc Subroutines với các đối số (arguments) d) Kiến trúc phần mềm Phần mềm nhìn từ cấu trúc phân cấp System Subsystem Subsystem Program Program Module Module Subroutine Master files Temporary files Arguments Arguments Job unit Jobstep unit Member unit Common Module   d) Kiến trúc phần mềm Phần mềm nhìn từ cấu trúc và thủ tục • Hai yếu tố cấu thành của phần mềm – Phương diện cấu trúc – Phương diện thủ tục • Cấu trúc phần mềm: biểu thị kiến trúc các chức năng mà phần mềm đó có và điều kiện phân cấp các chức năng (thiết kế cấu trúc) • Thiết kế chức năng: theo chiều đứng (càng sâu càng phức tạp) và chiều ngang (càng rộng càng nhiều chức năng, qui mô càng lớn) d) Kiến trúc phần mềm • Sơ đồ phân cấp module được dùng để mô tả sự phân rã,quan hệ phụ thuộc giữa các môđun và giao diện (interface) giữa chúng Hệ số gộp đầu vào (fan - in) Chiều sâu Hệ số phân chia đẩu ra (fan - out) Chiều rộng d) Kiến trúc phần mềm Sơ đồ phân cấp – Không liên quan đến trình tự gọi các môđun, nhưng ngầm định là từ trái qua phải – Mỗi môđun xuất hiện trong cấu trúc 1 lần, có thể được gọi nhiều lần – Quan hệ trên dưới: không cần nêu số lần gọi – Tên môđun biểu thị chức năng (“làm gì”), đặt tên sao cho các môđun ở phía dưới tổng hợp lại sẽ biểu thị đủ chức năng của môđun tương ứng phía trên – Biến số (arguments) biểu thị giao diện giữa các môđun, biến số ở các môđun gọi/bịgọi có thể khác nhau – Mũi tên với đuôi tròn trắng biểu thị dữ liệu, đuôi tròn đen (hồng) biểu thị flag – Chiều của mũi tên là hướng truyền tham số d) Kiến trúc phần mềm Module A Module B Module C Module D Module E 1 Luồng dữ liệu Luồng flag d) Kiến trúc phần mềm • Các loại kiến trúc: Xét 3 mô hình kiến trúc thường được sử dụng: – Chia sẻ dữ liệu: Mô hình kho dữ liệu dùng chung (repository) – Chia sẻ dịch vụ: Mô hình client/server – Mô hình phân lớp (layered model) d) Kiến trúc phần mềm (1) Mô hình kho dữ liệu dùng chung * Nguyên tắc: - Dữ liệu chia sẻ được tập trung trong một CSDL - Các hệ thống con đều truy cập vào CSDL chung * Khi một lượng lớn dữ liệu cần chia sẻ giữa các hệ thống con => Mô hình này thường được sd Ưu điểm - Đơn giản - Hiệu quả khi chia sẻ một khối lượng lớn dữ liệu - Đảm bảo sự độc lập của các hệ thống con Hạn chế - Các hệ thống con phải thống nhất trên mô hình kho dữ liệu dùng chung (2) Mô hình Client – Server (còn gọi là mô hình phân tán) • Nguyên tắc: Dữ liệu và xử lý được phân tán trên nhiều thành phần khác nhau • Hệ thống gồm: - Các server cung cấp các dịch vụ - Các client yêu cầu các dịch vụ - Phương thức trao đổi giữa Client và server: Trên mạng hay trên một máy tính Ưu điểm: - Sử dụng hiệu quả mạng - Dễ dàng thêm các server mới hoặc nâng cấp server hiện tại - Phân tán dữ liệu dễ dàng Hạn chế - Mỗi hệ thống con tự quản lý dữ liệu riêng của nó => Có thể dẫn đến dư thừa - Không có kiến trúc tập trung ghi nhận các dịch vụ => Khó khăn để xác định dữ liệu hay các dịch vụ (3) Mô hình phân lớp Nguyên tắc: - Tổ chức hệ thống thành tập hợp các lớp - Mỗi lớp cung cấp một tập hợp các dịch vụ => Được sử dụng để mô tả quan hệ giữa các hệ thống con e) Cấu trúc dữ liệu • Cấu trúc dữ liệu mô tả sự tổ chức, phương thức truy xuất, mức độ liên kết và các xử lí khác của thông tin – Dữ liệu đơn là dạng cấu trúc dữ liệu đơn giản nhất – Một số dạng cấu trúc dữ liệu phức tạp hơn như: Véc tơ, ma trận, mảng nhiều chiều, danh sách liên kết, hàng đợi, ngăn xếp, cây, .... f) Thủ tục • Thủ tục tập trung vào chi tiết xử lí của mỗi module • Cung cấp đặc tả chi tiết của: – Chuỗi sự kiện – Vòng lặp – Quyết định rẽ nhánh – Có thể cả cấu trúc dữ liệu g) Che dấu thông tin • Che dấu thông tin là một trong các nguyên lý quan trọng của việc phân chia module. Các module giao tiếp với nhau bằng những thông tin thực sự cần thiết. • Những thông tin về thủ tục và dữ liệu cục bộ phải được che dấu khỏi các module khác • Lợi ích: Kiểm soát được thay đổi và sửa lỗi dễ dàng 2.1.2.2 Phân chia module hiệu quả • Phân chia module là bắt buộc trong giai đoạn thiết kế. => phân chia kiến trúc phần mềm thành một bộ module như thế nào là tốt nhất? Tiêu chí quan trọng nhất là tính độc lập chức năng của các module. Tính độc lập chức năng được đo bằng 2 tiêu chuẩn đó là độ kết dính (cohesion) và sự liên kết (coupling) => Các tiêu chuẩn để phân chia a) Độ kết dính (cohesion) • Dùng để đo sự phụ thuộc lẫn nhau giữa các tác vụ (task) của một module. • Module có độ kết dính cao nhất nếu nó chỉ đảm nhận đúng một tác vụ kết dính chức năng: – Một module là một đơn vị logic – Toàn bộ module cùng góp phần thực hiện một mục tiêu Khi thiết kế kiến trúc phần mềm ta cố gắng tăng độ kết dính a) Độ kết dính • Có nhiều mức độ kết dính (từ thấp đến cao): - Ngẫu nhiên: Các tác vụ không liên hệ với nhau - Lý luận: Các tác vụ liên quan logic với nhau - Nhất thời: các tác vụ phải được thực thi trong một khoảng thời gian - Giao tiếp: các tác vụ có sử dụng chung một dữ liệu nào đó - Thủ tục: các tác vụ phải được thực hiện theo một thứ tự nhất định - Chức năng: Chỉ có một tác vụ b) Sự liên kết (coupling) • Dùng để đo đạc quá trình giao tiếp giữa các module • Giao tiếp của module chứa nhiều tác vụ và nhiều thông số thì sự liên kết càng cao. Khi thiết kế kiến trúc phần mềm cố gắng giảm sự liên kết: các module nên liên kết lỏng lẻo (ít ràng buộc, phụ thuộc lẫn nhau) b) Sự liên kết • Có nhiều mức độ liên kết: - Liên kết nội dung: Sử dụng dữ liệu và điều khiển của module khác - Liên kết chung: Có sử dụng chung dữ liệu toàn cục - Liên kết ngoại vi: module phụ thuộc vào một I/O nào đó - Liên kết điều khiển: Thông số truyền ảnh hưởng tới điều khiển - Liên kết Stamp: Truyền cấu trúc dữ liệu phức tạp - Liên kết dữ liệu: Truyền các thông số đơn giản c) Một số phương pháp phân chia module – Phương pháp phân chia STS (Source/Transform/Sink: Nguồn/Biếnđổi/Hấpthụ) – Phương pháp phân chia TR (Transaction) (1) Phương pháp phân chia STS • 1) Chia đối tượng “bài toán” thành các chức năng thành phần Bài toán Problem F1 F2 F3 F4 F5 2) Tìm ra luồng dữ liệu chính đi qua các chức năng: từ đầu vào (Input) tới đầu ra (Output) F1 F2 F3 F4 F5 INPUT OUTPUT Luồng dữ liệu chính • 3) Theo luồng dữ liệu chính: thay từng chức năng bởi bong bóng và làm rõ dữ liệu giữa các bong bóng F2 F3 F4 F5F1 Data1 Data2 Data3 Data4 Data5 Data6 INPUT OUTPUT • 4) Xác định vị trí trừu tượng hóa tối đa đầu vào và đầu ra F2 F3 F4 F5F1 Data1 Data2 Data3 Data4 Data5 Data6 INPUT OUTPUT Trừu tượng hóa tối đa đầu vào Trừu tượng hóa tối đa đầu ra Source Module Transform Module Sink Module • 5) Chuyển sang sơ đồ phân cấp F2 F3 F4 F5F1Data1 Data2 Data3 Data4 Data5 Data6 INPUT OUTPUT Trừu tượng hóa tối đa đầu vào Trừu tượng hóa tối đa đầu ra Source Module Transform Module Sink Module Control Module Source Module Transform Module Sink Module 0 1 2 3 • 6) Xác định các tham số giữa các môđun dựa theo quan hệ phụ thuộc Module 0 Module 1 Module 2 Module 3 0 1 2 3 3 3 5 5 7) Với từng môđun (Source, Transform, Sink) lại áp dụng cách phân chia STS lặp lại các bước từ 1) đến 6). Đôi khi có trường hợp không chia thành 3 mô đun nhỏ mà thành 2 hoặc 1 8) Tiếp tục chia đến mức cấu trúc lôgic khi môđun tương ứng với thuật toán đã biết thì dừng. Tổng hợp lại ta được cấu trúc phân cấp: mỗi nút là 1 môđun với số nhánh phía dưới không nhiều hơn 3 (2) Phương pháp phân chia TR • Khi không tồn tại luồng dữ liệu chính, mà dữ liệu vào có đặc thù khác nhau ( như những nguồn khác nhau) => xem như các giao dịch khác nhau • Mỗi giao dịch ứng với 1 môđun xử lý nó d) Các kinh nghiệm cho việc phân chia module - Sửa lại bản thiết kế ban đầu để tăng độ kết dính và giảm độ liên kết - Khi chiều sâu tăng, hạn chế fan-out trong khi sử dụng fan – in - Giữ cho tầm ảnh hưởng của một module nằm bên trong tầm điều khiển của nó - Loại bỏ dư thừa trong giao tiếp của các module - Ưu tiên các module tất định, hạn chế các module nhiều ràng buộc - Đóng gói các module để đạt được tính khả chuyển (portability) 2.2.2.3 Các hoạt động thiết kế • Hoạt động thiết kế xuất hiện trong các mô hình phát triển phần mềm khác nhau • Bao gồm 2 giai đoạn thiết kế chính: – Thiết kế kiến trúc • Phân tích giải pháp thành các thành phần • Định nghĩa giao diện giữa các thành phần • Định nghĩa phần vấn đề được giải quyết bởi mỗi thành phần • Chọn chiến lược cài đặt và quản trị CSDL • Có thể được thực hiện bởi nhiều mức độ trừu tượng – Thiết kế chi tiết • Thiết kế thuật toán • Thiết kế cấu trúc dữ liệu • Các giai đoạn thiết kế Lợi ích của thiết kế • Có một kiến trúc tốt – Làm chủ được kiến trúc hệ thống – Chia để trị • Đạt được các tiêu chuẩn chất lượng – Tái sử dụng, dễ kiểm thử, dễ bảo trì • Thiết kế hướng đến sự thay đổi – Sự thay đổi là một tính chất đặc trưng của phần mềm – Dự báo thay đổi là cần thiết (vì giúp giảm chi phí bảo trì) • Gồm 4 công đoạn: – Thiết kế kiến trúc – Thiết kế giao diện người – máy – Thiết kế dữ liệu – Thiết kế thủ tục 2.2.2.3 Phương pháp thiết kế cổ điển Quy trình thiết kế b. Thiết kế kiến trúc • Mục tiêu: – Xây dựng sơ đồ phân cấp module từ DFD – Đặt nền móng để thiết kế chi tiết thủ tục và dữ liệu • Phân biệt dòng biến đổi (transform) và dòng xử lí (transaction) trong DFD Dòng biến đổi (transform) • Được mô tả như sau: Dòng đi vào Dòng biến đổi Dòng đi ra Dòng giao dịch (transaction) • gồm: Dòng đi vào, T – center và các đường xử lí đầu ra. • T – center chỉ có một đường ra được kích hoạt tại một thời điểm T - center Dòng đi vào Lưu ý: Khi phân chia module để xây dựng biểu đồ phân cấp ta cần: + Xác định luồng dữ liệu + Luồng tuyến tính thì theo phân chia STS + Luồng phân nhánh thì theo phân chia TR a. Thiết kế dữ liệu • Các bước: – Tìm kiếm biểu diễn lý luận cho các phần tử dữ liệu đã được nhận diện trong giai đoạn phân tích yêu cầu – Thiết kế các cấu trúc dữ liệu của chương trình và cơ sở dữ liệu – Thực hiện tinh chế từng bước a. Thiết kế dữ liệu • Một số nguyên tắc thiết kế dữ liệu – Nhận diện cả cấu trúc dữ liệu và tác vụ truy xuất – Chú ý sử dụng từ điển dữ liệu – Trì hoãn thiết kế dữ liệu mức thấp cho đến cuối giai đoạn này – Che dấu biểu diễn bên trong của cấu trúc dữ liệu – Phát triển một thư viện các cấu trúc dữ liệu và các tác vụ thường gặp – Nên áp dụng kiểu ADT trong thiết kế cũng như trong lập trình c. Thiết kế giao diện • Một số hướng dẫn chung; – Nên đồng nhất: menu, lệnh, hiển thị. ….. – Nên cung cấp feedback cho người dùng – Yêu cầu xác nhận những tác vụ mang tính chất phá hoại như xóa file, account, … – Nên hỗ trợ UNDO và REDO – Hạn chế lượng thông tin phải ghi nhớ giữa hai tác vụ liên tiếp – Tối ưu trong trình bày hộp thoại và di chuyển mouse – Chấp nhận lỗi từ phía người sử dụng – Cung cập trợ giúp trực tuyến – Dùng động từ đơn giản và ngắn gọn để đặt tên các lệnh c. Thiết kế giao diện • Đối với thông tin hiển thị (output): – Chỉ hiển thị những thông tin phù hợp với ngữ cảnh hiện tại – Dùng tên, từ viết tắt và mầu gợi nhớ – Cho phép tương tác trực quan – Tạo thông báo lỗi có ý nghĩa – Hiển thị dữ liệu ở nhiều dạng khác nhau trong cửa sổ – Thiết lập biểu diễn tương tự – Sử dụng không gian màn hình một cách tối ưu c. Thiết kế giao diện • Đối với thông tin input: – Hạn chế input trực tiếp (có thể lựa chọn từ một số dữ liệu có sẵn) – Nên đồng nhất giữa thông tin input và output – Nên cho phép tùy biến input – Cấm các chức năng không thích hợp trong ngữ cảnh hiện taị – Cho phép input ở nhiều dạng khác nhau – Để cho người sử dụng kiểm soát dòng điều khiển tương tác – Tự động tính các giá trị input cho người sử dụng nếu có thể d. Thiết kế thủ tục • Thiết lập giải thuật cho các module đã kiến tạo sao cho có thể dễ dàng mã hóa bởi ngôn ngữ lập trình có cấu trúc • Có thể dùng giả ngôn ngữ để mô tả giải thuật 2.2.2.4 Phương pháp thiết kế hướng đối tượng - Lấy đối tượng làm trung tâm - Hệ thống = tập hợp các đối tượng + Quan hệ giữa các đối tượng -Các đổi tượng trao đổi bằng cách truyền các thông điệp => Không sử dụng biến toàn cục -Hỗ trợ đóng gói -Cho phép kế thừa 2.2.2.4 Phương pháp thiết kế hướng đối tượng Phân biệt: * Lập trình cấu trúc: Thuật toán + cấu trúc dữ liệu = chương trình * Lập trình HĐT - Tập hợp các đối tượng = chương trình - Đối tượng = thuật toán + cấu trúc dữ liệu 2.2.2.4 Phương pháp thiết kế hướng đối tượng Ưu điểm chính - Gần gũi với thế giới thực - tái sử dụng dễ dàng - Đóng gói, che dấu thông tin làm cho hệ thống tin cậy hơn - Thừa kế là giảm chi phí, hệ thống có tính mở cao hơn - Cho phép xây dựng hệ thống lớn và phức tạp 2.2.2.4 Phương pháp thiết kế hướng đối tượng i) Giới thiệu ii) Thiết kế hành vi iii) Hoàn chỉnh đặc tả tĩnh a) Giới thiệu Tk • Giai đoạn thiết kế nhằm trả lời câu hỏi “how”: – Xác định các tác nhân tham gia hệ thống – Thứ tự các thông điệp trao đổi, thông số của thông điệp – Thuật giải của tác vụ đáp ứng – Cấu trúc dữ liệu cho các thuộc tính – Framework (console, document/view, 3 – tier...) a) Giới thiệu TK • Thiết kế cũng chụi ảnh hưởng từ: – Ngôn ngữ lập trình và thư viện lập trình (hỗ trợ list, map, véc tơ.....hay không, có hỗ trợ template hay không?) – Kiến trúc hệ thống (COM, CORBA hay EJB)? • Thiết lập mô hình động và chi tiết hóa mô hình tĩnh b. Thiết kế hành vi (1) Khái niệm mô hình tĩnh/ mô hình động (2) Tương tác giữa các đối tượng - Sự cộng tác – Miêu tả trình tự (3) Lược đồ trạng thái (4) Lược đồ hoạt động (1)Khái niệm mô hình tĩnh/động • Lược đồ lớp chỉ mô tả khía cạnh tĩnh của hệ thống => mô hình tĩnh (xác định các lớp và các thuộc tính, cũng như mối quan hệ của các lớp) • Hành vi của hệ thống được mô tả bằng các mô hình động. Các mô hình động bao gồm: – Tương tác giữa các đối tượng: Cộng tác hay trình tự – Trạng thái của đối tượng, lớp: Mô hình trạng thái – Quá trình hoạt động của lớp đối tượng: Lược đồ hoạt động (2)Tương tác giữa các đối tượng - Đối tượng tương tác với nhau bằng cách gửi - nhận các kích thích - Actor cũng có thể gửi các kích thích đến đối tượng - Kích thích khiến: - 1 tác vụ thực thi, - 1 đối tượng được tạo ra hay hủy đi, - hoặc gây ra một tín hiệu (2)Tương tác giữa các đối tượng • Thông điệp là một đặc tả của kích thích. Các loại thông điệp: Đơn giản: Đồng bộ Bất đồng bộ Trả về của gọi hàm Bât đồng bộ/đồng bộ: Khi đối tượng gửi thông điệp đến đối tượng khác, nó không chờ đợi mà tiếp tục thực hiện công việc khác/ chờ đợi để thực hiện công việc khác=>đồng bộ (2)Tương tác giữa các đối tượng Sự tương tác được biểu diễn qua 2 lược đồ: - Lược đồ cộng tác - Lược đồ miêu tả trình tự Lược đồ cộng tác • Định nghĩa một tập hợp các thành phần tham gia và quan hệ giữa chúng (nhấn mạnh cấu trúc kết hợp của các thành phần – khía cạnh không gian ). • Các thành phần tham gia tương tác là các đối tượng/lớp nhau • Thiết lập để cụ thể hóa một use – case hoặc một tác vụ. • Tương tác được thể hiện bằng việc gửi/nhận thông điệp có thứ tự và điều kiện Lược đồ cộng tác Lược đồ cộng tác Vi dụ: Lược đồ cộng tác Ví dụ: Biểu đồ cộng tác của tác vụ thanh toán Lược đồ miêu tả trình tự • Lược đồ trình tự nhấn mạnh trình tự của tương tác • Lược đồ tuần tự: – mô tả các đối tượng tương tác với nhau theo thời gian sống của nó. – Các thông điệp được trao đổi theo trình tự thời gian. – Các mối liên kết không được thể hiện trong lược đồ Lược đồ miêu tả trình tự • Ký hiệu: – Đường thẳng đứng: Thời gian sống của đối tượng – Thanh HCN: Thời gian thực thi tác vụ của đối tượng – Các dòng text phụ trợ: mô tả ràng buộc, thời gian…. được viết ở lề trái Lược đồ miêu tả trình tự Ví dụ: Biểu đồ trình tự của chức năng thanh toán Nhận xét Giữa biểu đồ lớp và biểu đồ tương tác có mối quan hệ chặt chẽ với nhau. Ví dụ: (3) Lược đồ trạng thái • Trạng thái và sự biến đổi trạng thái (State transition) • Biểu đồ trạng thái Trạng thái và sự biến đổi trạng thái (State transition) • Tất cả các đối tượng đều có trạng thái; • Trạng thái là một kết quả của các hoạt động trước đó đã được đối tượng thực hiện và nó thường được xác định qua giá
Tài liệu liên quan