Bài giảng Phân tích thiết kế hướng đối tượng - Lê Trung Hiếu

MỤC LỤC > TRANG I 
Biên soạn: ThS. Lê Trung Hiếu 
PHÂN TÍCH 
THIẾT KẾ HƯỚNG 
ĐỐI TƯỢNG 
TRANG II > OOAD 
MỤC LỤC 
MỤC LỤC ......................................................................................................................................................... ii 
HƯỚNG DẪN .................................................................................................................................................. iv 
BÀI 1: QUY TRÌNH RUP ..................................................................................................... 1 
1.1 QUY TRÌNH PHÁT TRIỂN PHẦN MỀM ...................................................................................................... 1 
1.2 QUY TRÌNH RUP ........................................................................................................................................ 3 
1.2.1 Giới thiệu ............................................................................................................................................. 3 
1.2.2 Quy trình RUP ..................................................................................................................................... 5 
1.2.3 Phát triển theo mô hình lặp .................................................................................................................. 6 
1.2.4 Một số workflow chính trong RUP......................................................................................................... 8 
BÀI TẬP ĐỀ NGHỊ.......................................................................................................................................... 11 
BÀI 2: TỔNG QUAN UML ................................................................................................. 12 
2.1 KHÁI NIỆM ............................................................................................................................................... 12 
2.2 CÁC BIỂU ĐỒ CỦA UML ......................................................................................................................... 14 
2.2.1 Biểu đồ Usecase ................................................................................................................................ 14 
2.2.2 Biểu đồ hoạt động – Activity diagram ................................................................................................. 17 
2.2.3 Biểu đồ lớp – Class diagram .............................................................................................................. 21 
2.2.4 Biểu đồ tuần tự - Sequence diagram .................................................................................................. 24 
2.2.5 Biểu đồ giao tiếp – Communication diagram ....................................................................................... 27 
2.2.6 Biểu đồ trạng thái – State diagram ..................................................................................................... 28 
2.2.7 Biểu đồ gói – Package diagram .......................................................................................................... 29 
2.2.8 Biểu đồ thành phần – Component diagram ......................................................................................... 30 
2.2.9 Biểu đồ triển khai – Deployment diagram ........................................................................................... 30 
BÀI TẬP ĐỀ NGHỊ.......................................................................................................................................... 32 
BÀI 3: LẤY YÊU CẦU ........................................................................................................ 34 
3.1 KHÁI NIỆM ............................................................................................................................................... 34 
3.2 KỸ THUẬT LẤY YÊU CẦU ....................................................................................................................... 35 
MỤC LỤC > TRANG III 
3.2.1 Phỏng vấn ......................................................................................................................................... 36 
3.2.2 Họp nhóm .......................................................................................................................................... 36 
3.2.3 Quan sát ............................................................................................................................................ 37 
3.2.4 Công việc tạm thời ............................................................................................................................. 37 
3.2.5 Điều tra qua câu hỏi ........................................................................................................................... 37 
3.2.6 Xem xét tài liệu .................................................................................................................................. 38 
3.2.7 Xem xét phần mềm ............................................................................................................................ 38 
3.3 KẾT QUẢ CỦA GIAI ĐOẠN LẤY YÊU CẦU ............................................................................................. 38 
3.3.1 Kết quả .............................................................................................................................................. 38 
3.3.2 Đặc tả UC .......................................................................................................................................... 38 
BÀI TẬP ĐỀ NGHỊ.......................................................................................................................................... 41 
BÀI 4: PHÂN TÍCH & THIẾT KẾ ..................................................................................... 42 
4.1 GIỚI THIỆU .............................................................................................................................................. 42 
4.2 PHÂN TÍCH THIẾT KẾ HỆ THỐNG Ở TRẠNG THÁI TĨNH ....................................................................... 43 
4.3 PHÂN TÍCH THIẾT KẾ HỆ THỐNG Ở TRẠNG THÁI ĐỘNG .................................................................... 48 
BÀI TẬP ĐỀ NGHỊ.......................................................................................................................................... 50 
TÀI LIỆU THAM KHẢO ................................................................................................................................. 51 
PHỤ LỤC – ĐỒ ÁN THAM KHẢO .................................................................................................................. 52 
TRANG IV > OOAD 
HƯỚNG DẪN 
MÔ TẢ MÔN HỌC 
Môn học Phân Tích Thiết Kế Hướng Đối Tượng Cung cấp kiến thức và kỹ năng 
phân tích thiết kế phần mềm theo phương pháp hướng đối tượng, cung cấp 
kiến thức về UML và case tool để thiết kế hệ thống. 
Mục tiêu của môn học là sử dụng ngôn ngữ UML và các case tool để lấy yêu 
cầu, phân tích và thiết kế, viết tài liệu cho một phần mềm thực tiễn. 
Sau khi kết thúc môn học, người học phải có khả năng lấy yêu cầu, phân 
tích, thiết kế và viết tài liệu cho một phần mềm. 
NỘI DUNG MÔN HỌC 
Bài 1: Giới thiệu quy trình phát triển phần mềm RUP 
 Tổng quan 
 Giới thiệu quy trình RUP 
 Phát triển phần mềm theo quy trình lặp 
Bài 2: Tổng quan về ngôn ngữ UML 
 Khái niệm 
 Các biểu đồ của UML 
Bài 3: Lấy yêu cầu 
 Khái niệm 
 Kỹ thuật lấy yêu cầu 
 Kết quả giai đoạn lấy yêu cầu 
Bài 4: Phân tích & thiết kế 
HƯỚNG DẪN > TRANG V 
 Tổng quan 
 Phân tích và thiết kế ở trạng thái tĩnh 
 Phân tích và thiết kế ở trạng thái động 
KIẾN THỨC TIỀN ĐỀ 
Cấu trúc dữ liệu, Cơ sở dữ liệu, Lập trình trong window (Visual C++), Lập 
trình hướng đối tượng. 
YÊU CẦU MÔN HỌC 
Người học phải dự học đầy đủ các buổi lên lớp và tham gia thực hành đầy 
đủ. Người học phải có máy tính và sử dụng các case tool như: Astah, Star 
UML, Rational Rose. 
CÁCH TIẾP NHẬN NỘI DUNG MÔN HỌC 
Để học tốt môn này, người học cần phải tìm hiểu thông tin, kiến thức về 
các lĩnh vực mà phần mềm thực hiện hướng đến. 
PHƯƠNG PHÁP ĐÁNH GIÁ MÔN HỌC 
Môn học được đánh giá gồm: 
 Điểm quá trình: 30%. Hình thức và nội dung do GV quyết định, phù hợp 
với quy chế đào tạo và tình hình thực tế tại nơi tổ chức học tập. 
 Điểm báo cáo đồ án: 70%. Hình thức thi vấn đáp. Sinh viên làm việc 
nhóm và trả lời các câu hỏi liên quan về đề tài của mình. Hình thức phân 
chia công việc: phân chia theo Use Case. Một nhóm tối đa 3 sinh viên.
BÀI 1: QUY TRÌNH RUP > TRANG 1 
BÀI 1: QUY TRÌNH RUP 
1.1 QUY TRÌNH PHÁT TRIỂN PHẦN MỀM 
Quy trình phát triển phần mềm: gồm một tập hợp các hoạt động được tổ 
chức mà mục đích của nó là xây dựng và phát triển phần mềm: 
 Quy trình xác định ai làm gì, khi nào và bằng cách nào để đạt được một 
mục tiêu nào đó 
 Quy trình phần mềm xác định một bộ khung và tiêu chuẩn để triển khai 
công nghệ phần mềm 
Khi xây dựng và phát triển một phần mềm, thường thì cần phải làm việc 
trong đội, nhóm: 
Ngôn ngữ mô hình hóa hợp nhất (Unified Modeling Language - UML): 
Là ngôn ngữ dùng để 
 Xác định (Specifying) 
 Trực quan hóa (Visualizing) 
 Xây dựng (Constructing) 
 Lập tài liệu (Documenting) 
Cho các kết quả (artifacts) của quá trình thực hiện phần mềm. 
Lịch sử của UML: 
TRANG 2 > OOAD 
Những người tham gia tạo ra ngôn ngữ UML: 
BÀI 1: QUY TRÌNH RUP > TRANG 3 
1.2 QUY TRÌNH RUP 
1.2.1 GIỚI THIỆU 
Quy trình phát triển phần mềm hợp nhất Rational (Rational Unified Process 
hay RUP) là một quy trình phát triển phần mềm. Nó cung cấp các phương 
pháp, các nguyên tắc phân công nhiệm vụ và trách nhiệm trong các tổ chức 
phát triển phần mềm. Nó là phương pháp dùng để tạo ra một sản phẩm phần 
mềm có chất lượng cao đảm bảo các dự thảo về thời gian và và kinh phí với 
khách hàng. 
Quy trình này được tổ chức làm bốn giai đoạn: 
Từ phương diện quản lý, vòng đời của một phần mềm theo RUP được chia 
theo thời gian qua bốn giai đoạn nối tiếp nhau, mỗi giai đoạn có một mốc 
quan trọng, mỗi giai đoạn thực chất là khoảng giữa của 2 điểm mốc. Cuối 
mỗi giai đoạn, bộ phận kiểm định sẽ thực hiện thẩm định các đối tượng của 
TRANG 4 > OOAD 
giai đoạn này. Nếu việc kiểm tra thích hợp thì dự án sẽ được chuyển sang 
giai đoạn tiếp theo. 
Giai đoạn Inception: Kết quả của giai đoạn này là đạt được sự nhất trí giữa 
tất cả những người đóng vai trò chủ chốt về các mục tiêu của dự án. Trong 
giai đoạn này phải chỉ ra được các mục tiêu quan trọng cần cố gắng đạt 
được, trong đó rủi ro của các yêu cầu, các chức năng nghiệp vụ cũng phải 
được chỉ ra trước khi dự án bắt đầu. Trong giai đoạn này cũng đề cập đến 
việc cải tiến từ các hệ thống đã có, tuy nhiên vẫn chỉ tóm tắt, giai đoạn này 
chú trọng đến cả 2 điều quan trọng của dự án: đáng để làm hay không và 
khả năng thực hiện. 
Mục tiêu chính của giai đoạn Inception 
 Thiết lập phạm vi phần mềm và các điều kiện biên của dự án, bao gồm: 
nhìn nhận khả năng thực hiện, các điều kiện thỏa thuận và những gì 
sản phẩm mong đợi và không mong đợi 
 Nhận định đúng đắn về các Use case của hệ thống, kịch bản của các 
hành vi trong hệ thống sẽ đóng vai trò định hướng quan trọng cho kết 
quả của phần thiết kế 
 Trình bày, minh họa một số kiến trúc ứng cử viên cho một vài kịch bản 
chính 
 Dự trù tất cả chi phí, lập kế hoạch cho toàn bộ dự án 
 Dự trù các rủi ro tiềm ẩn 
 Chuẩn bị môi trường hỗ trợ cho dự án 
Giai đoạn Elaboration: Kết quả của giai đoạn này là tạo ra một baseline 
cho kiến trúc của hệ thống tạo cơ sở cho quá trình thiết kế và thực thi trong 
giai đoạn construction. Kiến trúc này mở rộng việc phân tích các yêu cầu 
quan trọng của hệ thống (các yêu cầu có sự ảnh hưởng lớn đến hệ thống) và 
BÀI 1: QUY TRÌNH RUP > TRANG 5 
đánh giá các rủi ro. Sự ổn định của kiến trúc được đánh gia qua nhiều 
nguyên bản của kiến trúc. 
Giai đoạn Construction 
 Đây là giai đoạn xây dựng sản phầm và phát triển các phiên bản, kiến 
trúc, các kế hoạch cho đến khi đạt được phiên bản hoàn thiện nhất – có 
thể chuyển giao cho người dùng 
 Giai đoạn này sẽ được kết luận dựa vào các mốc là khả năng thực hiện 
các chức năng yêu cầu ban đầu đã xác định 
Giai đoạn Transition 
 Chuyển giao sản phẩm cho những người sử dụng nó, bao gồm: sản 
xuất, phân phát, huấn luyện, hỗ trợ và bảo trì cho đến khi người sử 
dụng hài lòng. 
 Giai đoạn này được kết luận thông qua mốc các phiên bản của sản 
phẩm – kết thúc từng chu trình lặp của giai đoạn này 
Thời gian dành cho các giai đoạn này được ước tính như sau: 
1.2.2 QUY TRÌNH RUP 
Quy trình RUP bao gồm 4 phases và 9 workflow, được thể hiện như sau: 
TRANG 6 > OOAD 
 Hàng ngang của biểu đồ mô tả qui trình về mặt thời gian và vòng 
đời của một giai đoạn trong qui trình (khởi tạo, chi tiết hóa, xây dựng 
và chuyển giao) 
 Hàng dọc của biểu đồ mô tả trạng thái tĩnh của qui trình, các giai 
đoạn của qui trình 
1.2.3 PHÁT TRIỂN THEO MÔ HÌNH LẶP 
Một dự án sử dụng quy trình phát triển lặp lại có một vòng đời chứa các quá 
trình lặp lại. Một quá trình lặp là sự kết hợp chặt chẽ một chuỗi các hoạt 
động: mô hình nghiệp vụ, tiếp nhận yêu cầu, phân tích và thiết kế, thực thi, 
kiểm lỗi và triển khai với mức độ lặp không giống nhau, tùy theo vị trí cụ thể 
của vòng phát triển. 
Quản lý, tiếp nhận yêu cầu và thiết kế là các hoạt động trọng điểm trong giai 
đoạn khởi tạo và phân tích chi tiết dự án; các hoạt động thiết kế, thực thi và 
kiểm lỗi đóng vai trò chủ chốt trong giai đoạn xây dựng; và các hoạt động 
kiểm lỗi, triển khai đóng vai trò chủ đạo trong giai đoạn chuyển giao dự án. 
BÀI 1: QUY TRÌNH RUP > TRANG 7 
Một thiết kế ban đầu chỉ là một sản phẩm chưa hoàn thiện, dựa trên các yêu 
cầu căn bản, về sau quá trình thiết kế càng phát hiện ra thêm nhiều nhược 
điểm đó là kết quả trả giá từ việc chạy thử và trong một số trường hợp dự án 
phải hủy bỏ. 
Tất cả các dự án đều có một tập các rủi ro phức tạp. Lúc ban đầu bạn có thể 
xác định để ngăn ngừa một vài rủi ro theo đúng như kế hoạch của mình. Tuy 
nhiên có rất nhiều rủi ro mà bạn không thể phát hiện ra một các đơn giản, 
trơn tru cho đến khi bạn cố gắng tích hợp hệ thống. Bạn sẽ không bao giờ có 
thể dự đoán trước được tất cả các rủi ro khi không quan tâm đến kinh 
nghiệm của nhóm phát triển. 
Lợi ích của phát triển lặp lại 
TRANG 8 > OOAD 
 Hạn chế được nhiều rủi ro do các phần tử được tích hợp, xây dựng dần 
dần 
 Cho phép thay đổi các yêu cầu, các phương thức cho thích hợp hơn 
 Các tổ chức có thể nắm được phương pháp này và phát triển cho qui 
trình của họ 
 Tăng khả năng tái sử dụng 
1.2.4 MỘT SỐ WORKFLOW CHÍNH TRONG RUP 
Mô hình hóa nghiệp vụ 
Lấy yêu cầu: 
BÀI 1: QUY TRÌNH RUP > TRANG 9 
Phân tích thiết kế: 
TRANG 10 > OOAD 
Hiện thực 
Kiểm thử: 
BÀI 1: QUY TRÌNH RUP > TRANG 11 
Quản trị dự án: 
BÀI TẬP ĐỀ NGHỊ 
Câu 1: Đọc và nghiên cứu quy trình phát triển phần mềm XP (eXtreme 
Programming) 
TRANG 12| OOAD 
BÀI 2: TỔNG QUAN UML 
2.1 KHÁI NIỆM 
Ngôn ngữ mô hình hóa hợp nhất (Unified Modeling Language - UML): 
Là ngôn  ... các phần mềm đã tồn tại cung cấp cho chúng ta các thông tin về quá 
trình xử lý công việc hiện thời và các mở rộng có ràng buộc bởi thiết kế phần 
mềm. 
3.3 KẾT QUẢ CỦA GIAI ĐOẠN LẤY YÊU CẦU 
3.3.1 KẾT QUẢ 
Khi lấy yêu cầu, kết quả của giai đoạn này bao gồm: 
 Danh sách các actor 
 Danh sách các use case 
 Use case diagram 
 Cho từng Use Case: 
- Phát thảo giao diện 
- Vẽ sơ đồ hoạt động 
- Viết đặc tả Use case 
3.3.2 ĐẶC TẢ UC 
Đặc tả một Use Case thường được thực hiện trong văn bản. Đây là lời đặc 
tả đơn giản và nhất quán về việc các actor và các Use Case (hệ thống) tương 
tác với nhau ra sao. Nó tập trung vào ứng xử đối ngoại của hệ thống và 
BÀI 3: LẤY YÊU CẦU > TRANG 39 
không đề cập tới việc thực hiện nội bộ bên trong hệ thống. Ngôn ngữ và các 
thuật ngữ được sử dụng trong lời miêu tả chính là ngôn ngữ và các thuật ngữ 
được sử dụng bởi khách hàng/người dùng. 
Nội dung đặc tả UC thường bao gồm: 
- Mục đích của Use Case: Mục đích chung cuộc của Use Case là gì? Cái gì 
cần phải được đạt tới? Use Case nói chung đều mang tính hướng mục đích và 
mục đích của mỗi Use Case cần phải rõ ràng. 
- Use Case được khởi chạy như thế nào: Tác nhân nào gây ra sự thực 
hiện Use Case này? Trong hoàn cảnh nào? 
- Chuỗi các thông điệp giữa actor và Use Case: Use Case và các actor 
trao đổi thông điệp hay sự kiện nào để thông báo lẫn cho nhau, cập nhật 
hoặc nhận thông tin và giúp đỡ nhau quyết định? Yếu tố nào sẽ miêu tả dòng 
chảy chính của các thông điệp giữa hệ thống và actor, và những thực thể nào 
trong hệ thống được sử dụng hoặc là bị thay đổi? 
- Dòng chảy thay thế trong một Use Case: Một Use Case có thể có 
những dòng thực thi thay thế tùy thuộc vào điều kiện. Hãy nhắc đến các yếu 
tố này, nhưng chú ý đừng miêu tả chúng quá chi tiết đến mức độ chúng có 
thể “che khuất“ dòng chảy chính của các hoạt động trong trường hợp căn 
bản. Những động tác xử lý lỗi đặc biệt sẽ được miêu tả thành các Use Case 
khác. 
- Use Case sẽ kết thúc với một giá trị đối với tác nhân như thế nào: 
Hãy miêu tả khi nào Use Case được coi là đã kết thúc, và loại giá trị mà nó 
cung cấp đến tác nhân. 
Ví dụ: 
Chi tiết tài khoản: // tên Use Case 
Số Use Case: UCSEC35 
Miêu tả ngắn: // miêu tả ngắn gọn Use Case 
Use Case "chi tiết tài khoản" cho phép nhân viên nhà băng xem các chi tiết của một tài khoản mà 
anh ta định tìm hiểu. 
TRANG 40| OOAD 
Dòng chảy các sự kiện: // dòng logic chung 
Nhân viên chọn Chi Tiết Tài Khoản trên menu. Một con đường khác để chỉ ra các thông tin chi 
tiết của tài khoản là gọi từ Màn Hình Tóm Tắt Thông Tin Về Tài Khoản (xem Use Case số 
UCSEC99). 
Dòng hành động chính: // dòng logic chi tiết. 
Mỗi khách hàng sẽ có một số định danh gọi là CustomerId. Một khách hàng có thể có nhiều tài 
khoản. Sau khi nhân viên nhập CustomerId vào hệ thống, màn hình phải in ra tất cả những tài 
khoản thuộc về khách hàng này và thuộc về nhà băng ABC, rải rác tại tất cả các chi nhánh. Khi 
chọn tiếp loại tài khoản và số tài khoản, các chi tiết của tài khoản mong muốn sẽ được in ra. 
Loại tài khoản tiết kiệm: Nếu loại tài khoản được chọn là tài khoản tiết kiệm, thì theo Use Case 
số UCSEC45, các chi tiết sau đây sẽ được in ra: 
- Mức tiền hiện có 
- Các tờ sec chưa thanh toán 
- Lượng tiền tín dụng được phép 
- Lượng tiền lãi cho tới ngày hôm nay 
- Lượng tiền tối thiểu cần phải có trong tài khoản 
Loại tài khoản đầu tư: Nếu loại tài khoản được chọn là loại đầu tư, thì theo Use Case số 
UCSEC46, các chi tiết sau đây sẽ được in ra. 
- Hạn đầu tư 
- Số tiền đầu tư 
- Ngày đầu tư 
- Lượng tiền cuối hạn 
- Ngày cuối hạn 
- Tỷ lệ lời 
Dòng hành động thay thế: // chuỗi logic thay thế 
Không tìm thấy chi tiết: Khi chọn một số tài khoản không thích hợp (không có tài khoản tương 
ứng) dù vì lý do chức năng hay kỹ thuật, theo Use Case số UCSEC12, hệ thống sẽ đưa ra một 
màn hình báo lỗi. 
Điều kiện thoát: // Use Case kết thúc như thế nào? 
Nút Thoát: Khi chọn nút thoát, người sử dụng sẽ quay trở lại màn hình chính. 
BÀI 3: LẤY YÊU CẦU > TRANG 41 
Nút Xem Thêm: Khi chọn nút này, người sử dụng sẽ được yêu cầu chọn loại tài khoản từ một 
danh sách đổ xuống. 
Nút Xem Giao Dịch: Khi chọn nút này, người sử dụng sẽ được chuyển sang màn hình "Giao 
dịch" và theo Use Case số UCSEC91, màn hình sẽ chỉ ra những giao dịch đã xảy ra đối với tài 
khoản, bên cạnh những chi tiết chính của tài khoản. 
Nút Yêu Cầu In Kết Quả: Khi chọn phần thực đơn này, kết quả giao dịch theo Use Case số 
UCSEC70 sẽ được in ra ở một máy in địa phương nối trực tiếp với máy tính của nhân viên. 
Các yêu cầu đặc biệt: // các yêu cầu đặc biệt 
Theo Use Case số UCSEC110, hệ thống có khả năng in lên màn hình bằng những ngôn ngữ khác. 
Chức năng này sẽ được kích hoạt khi người sử dụng chọn mục Ngoại Ngữ trên menu. 
Điều kiện trước đó: // điều xảy ra trước khi Use Case được thực hiện 
Bảo an: Người sử dụng (nhân viên tiếp khách) được cung cấp một số định danh riêng biệt để truy 
nhập vào hệ thống. 
Dịch chuyển: Người sử dụng chỉ đến được màn hình Chi Tiết Tài Khoản sau khi đã truy nhập 
thành công và Identify thành công. 
Điều kiện sau đó: // điều gì xảy ra sau khi Use Case được thực hiện? 
Hệ thống sẽ không lưu trữ lại bất kỳ một thông tin nào liên quan tới khách hàng lên đĩa cứng cục 
bộ. 
BÀI TẬP ĐỀ NGHỊ 
Câu 1: Lấy yêu cầu cho hệ thống quản lý thư viện 
TRANG 42| OOAD 
BÀI 4: PHÂN TÍCH & THIẾT KẾ 
4.1 GIỚI THIỆU 
Các công việc và vai trò phải thực hiện trong giai đoạn phân tích thiết kế: 
Trong phần này, chúng ta sẽ tìm hiểu phân tích và thiết kế theo định 
hướng từng Use Case. Cho từng Use Case, chúng ta sẽ phân tích thiết kế ở 
trạng thái tĩnh và trạng thái động: 
BÀI 4: PHÂN TÍCH & THIẾT KẾ > TRANG 43 
Các bước dùng cho quá trình phân tích thiết kế như sau: 
4.2 PHÂN TÍCH THIẾT KẾ HỆ THỐNG Ở TRẠNG THÁI 
TĨNH 
Khi phân tích hệ thống ở trạng thái tĩnh, ta tiến hành tìm các lớp phân tích 
và vẽ sơ đồ class diagram, tìm kiếm các thuộc tính cho các lớp này. 
Lớp bao gồm 3 thành phần như sau: 
TRANG 44| OOAD 
Với mỗi một UC, có thể tồn tại 3 loại lớp: Lớp boundary, lớp control và lớp 
entity. 
Ký hiệu: 
BÀI 4: PHÂN TÍCH & THIẾT KẾ > TRANG 45 
 Lớp biên (boundary): Dùng để mô tả sự tương tác giữa các actor với hệ 
thống, lớp biên có thể là: Giao diện người dùng, Lớp tương tác với các 
thiết bị phần cứng, lớp tương tác với các hệ thống khác. 
 Lớp điều khiển ( controller): thông thường 1 UC có 1 lớp Controller điều 
khiển hoạt động của UC 
 Lớp Thực thể ( Entity): Mô tả các thực thể chứa dữ liệu cần thiết để 
hiện thực UC. 
Các lớp này được thể hiện trong sơ đồ sau: 
TRANG 46| OOAD 
Ví dụ: 
Entity class: 
BÀI 4: PHÂN TÍCH & THIẾT KẾ > TRANG 47 
Control class 
Sau khi phân tích, dựa vào đặc tả ta có thể tìm kiếm các attribute của các 
lớp. Sơ đồ class diagram được vẽ như sau: 
TRANG 48| OOAD 
4.3 PHÂN TÍCH THIẾT KẾ HỆ THỐNG Ở TRẠNG THÁI 
ĐỘNG 
Khi phân tích và thiết kế ở trạng thái động, ta vẽ sơ đồ tuần tự & sơ đồ 
giao tiếp để tìm kiếm các hàm ( method) cho các lớp phân tích ở trên. 
Mỗi một thông điệp giữa các object là lời gọi hàm để hiện thực UC. 
BÀI 4: PHÂN TÍCH & THIẾT KẾ > TRANG 49 
Nếu UC có nhiều luồng thông tin, ta phải vẽ nhiều sơ đồ: 
Ở giai đoạn thiết kế, ta thêm vào các tham số cho hàm, kiểu dữ liệu cho 
các tham số, kiểu kết quả trả về. 
TRANG 50| OOAD 
BÀI TẬP ĐỀ NGHỊ 
Câu 1: Phân tích & thiết kế hệ thống đã lấy yêu cầu ở bài 3 
BÀI 5: > TRANG 51 
TÀI LIỆU THAM KHẢO 
1. Pro ASP.NET 4 in CSharp 2010, Matthew MacDonald, Adam Freeman, 
and Mario Szpuszta, appress 2010. 
2. ASP.NET 2.0 Everyday Apps For Dummies, Doug Lowe, Wiley 
Publishing, 2007 
PHỤ LỤC – ĐỒ ÁN THAM KHẢO 
Đề bài: phân tích và thiết kế hệ thống tạo khảo sát online 
UC Diagram 
Danh sách Actor: 
 Thành viên 
 Người dùng 
 Quản trị 
Danh sách Usecase 
 Tạo khảo sát 
 Quản lý khảo sát 
 Tạo câu hỏi 
 Quản lý câu hỏi 
 Nạp phí thành viên 
 Xem kết quả khảo sát 
 Xem biểu đồ 
 Tìm kiếm khảo sát 
 Quản trị quản lý khảo sát 
 Quản trị quản lý thành viên 
Sơ đồ Usecase: 
BÀI 5: > TRANG 53 
Thiết kế chi tiết chức năng: 
Giao diện trang chủ: 
Tạo khảo sát 
 Phát thảo giao diện: 
 Đặc tả usecase: 
Name Tạo khảo sát 
Description Thành viên tạo khảo sát 
Actor Thành viên 
Pre conditions  Đăng nhập vào tài khoản thành viên 
 Hiển thị trang tạo khảo sát 
Post conditions Thông báo kết quả tạo khảo sát 
Flow of events 1. Hệ thống lấy thông tin tài khoản người dùng 
2. Hệ thống kiểm tra tài khoản. 
3. Hệ thống hiển thị tùy chọn tạo khảo sát có tính 
phí hay không. 
4. Người dùng nhập tên khảo sát 
5. Người dùng nhập giới thiệu khảo sát 
6. Chọn ngày bắt đầu khảo sát 
7. Chọn ngày kết thúc khảo sát 
BÀI 5: > TRANG 55 
8. Nhấn nút tạo khảo sát 
8.1 Hệ thống lưu nội dung khảo sát xuống cơ sở 
dữ liệu 
8.2 Không lưu được: A1 
8.3 Thông báo kết quả lên trang web 
Alternative flow A1: Thông báo không tạo được khảo sát. 
 Trở lại trang tạo khảo sát 
A2: Thông báo không lưu được khảo sát 
 Trở lại trang tạo khảo sát 
 Activity diagram: 
 Sequence diagram: 
 Class diagram: 
Quản lý khảo sát 
Giao diện: 
BÀI 5: > TRANG 57 
 Đặc tả usecase: 
Name Thành viên quản lý khảo sát 
Description Thành viên quản lý các khảo sát đã tạo 
Actor Thành viên 
Pre conditions  Đăng nhập vào tài khoản thành viên 
 Hiển thị trang thành viên quản lý khảo sát 
Post conditions Thông báo kết quả thao tác 
Flow of events 1. Hệ thống load danh sách khảo sát đã tạo của 
thành viên. 
2. Hệ thống hiển thị danh sách khảo sát đã tạo 
3. Người dùng chọn khảo sát 
4. Nhấn nút chỉnh sửa 
5. Không sửa được: A1 
6. Hệ thống hiển thị trang cập nhật khảo sát 
7. Người dùng nhấn nút xoá khảo sát 
9. Hệ thống xoá khảo sát khỏi cơ sở dữ liệu 
10. Thông báo kết quả xoá 
11. Quay lại trang quản lý khảo sát 
Alternative flows A1: Thông báo không cập nhật được khảo sát 
A2: Thông báo không xoá được khảo sát 
 Activity diagram: 
 Sequence diagram: 
BÀI 5: > TRANG 59 
 Class diagram: 
Tạo câu hỏi 
 Giao diện 
 Đặc tả usecase: 
Name Tạo câu hỏi 
Description Thêm mới câu hỏi khảo sát 
Actor Thành viên 
Pre conditions  Đăng nhập vào tài khoản thành viên 
 Hiển thị trang danh sách câu hỏi 
Post conditions Thông báo kết quả tạo câu hỏi 
Flow of events 1. Hệ thống hiển thị trang tạo câu hỏi 
2. Người dùng chọn loại câu hỏi 
3. Người dung chọn trang hiển thị 
4. Nhập nội dung câu hỏi 
BÀI 5: > TRANG 61 
6. Nhấn nút tạo câu hỏi 
6.1 Không lưu được câu hỏi : A1 
6.2 Hệ thống lưu câu hỏi xuống cơ sở dữ liệu 
7. Nhấn nút huỷ: quay lại trang quản lý câu hỏi 
Alternative flow A1: Thông báo không lưu được câu hỏi 
 Activity diagram: 
 Class diagram: 
Quản lý câu hỏi 
Giao diện 
BÀI 5: > TRANG 63 
 Đặc tả usecase: 
Name Quản lý câu hỏi 
Description Thành viên quản lý tạo, cập nhật, xoá câu hỏi 
Actor Thành viên 
Pre conditions  Đăng nhập vào tài khoản thành viên 
 Hiển thị trang quản lý câu hỏi 
Post conditions Thông báo kết quả thao tác 
Flow of events 1. Hệ thống lấy danh sách câu hỏi theo khảo sát và 
người tạo khảo sát. 
2. Hệ thống hiển thị danh sách câu hỏi 
3. Không hiển thị được: A1 
4. Người dùng nhấn nút tạo câu hỏi 
5. Hệ thồng chuyển sang trang tạo câu hỏi mới 
6. Người dùng nhấn nút chỉnh sửa của câu hỏi 
7. Hệ thống hiển thị trang chỉnh sửa câu hỏi 
7.1 Không thể sửa: A2 
8. Người dùng nhấn nút xoá câu hỏi 
8.1 Không thể xóa: A3 
Altenative flows A1: Thông báo không hiển thị được. 
A2: Thông báo không sửa được câu hỏi 
A3: Thông báo không xóa được câu hỏi. 
 Activity diagram: 
 Sequence diagram: 
BÀI 5: > TRANG 65 
 Class diagram: 
Xem kết quả khảo sát 
 Giao diện: 
 Đặc tả usecase: 
Name Xem kết quả khảo sát 
Description Người dùng xem kết quả khảo sát đã kết thúc 
Actor Người dùng 
Pre conditions  Đăng nhập vào tài khoản người dùng 
 Hiển thị trang xem kết quả 
Post conditions Hiển thị kết quả khảo sát 
Flow of events 1. Hệ thống tải lên danh sách các khảo sát 
2. Không tải lên được: A1 
3. Hệ thống hiển thị danh sách các khảo sát 
4. Người dùng chọn tên khảo sát 
5. Hệ thống tải lên danh sách các câu hỏi 
6. Không tải được câu hỏi: A2 
7. Hệ thống hiển thị danh sách các câu hỏi 
8. Hệ thống hiển thị câu trả lời và tỉ lệ 
BÀI 5: > TRANG 67 
10. Nhấn nút xem chi tiết 
11. Không hiển thị được: A3 
12. Hệ thống hiển thị chi tiết kết quả khảo sát của 
câu hỏi đã được chọn. 
Alternative flows A1: Thông báo lên trang web không tải được khảo 
sát 
A2: Thông báo không tải được câu hỏi 
A3: Thông báo không hiển thị được chi tiết. 
 Activity diagram: 
 Sequence diagram: 
 Class diagram: 
Tham gia khảo sát 
 Giao diện 
BÀI 5: > TRANG 69 
 Đặc tả usecase: 
Name Tham gia khảo sát 
Description Người truy cập web tham gia khảo sát 
Actor Người dùng web 
Pre conditions  Hiển thị trang tham gia khảo sát 
Post conditions Thông báo kết quả hoàn thành khảo sát 
Flow of events 1. Hệ thống hiển thị trang giới thiệu khảo sát 
2. Người dùng nhấn nút bắt đầu 
3. Hệ thống hiển thị trang câu hỏi đầu tiên 
4. Hệ thống tải danh sách câu hỏi và trả lời 
5. Người dùng chọn câu trả lời 
6. Nhấn nút tiếp tục 
7. Hệ thống lưu câu trả lời của người dùng xuống 
8. Không lưu được: A2 
9. Hiển thị trang cảm ơn người tham gia khảo sát 
Alternative flows A1: Thông báo không lưu được dữ liệu 
 Activity diagram: 
 Sequence diagram: 
BÀI 5: > TRANG 71 
 Class diagram: 
Xem biểu đồ 
 Giao diện 
 Đặc tả usecase: 
Name Xem biểu đồ khảo sát 
Description Người dùng xem biểu đồ kết quả khảo sát đã kết 
thúc 
Actor Người dùng 
BÀI 5: > TRANG 73 
Pre conditions  Đăng nhập vào tài khoản người dùng 
 Hiển thị trang xem kết quả 
Post conditions Hiển thị biểu đồ kết quả khảo sát 
Flow of events 1. Hệ thống tải lên danh sách các khảo sát 
2. Không tải lên được: A1 
3. Hệ thống hiển thị danh sách các khảo sát 
4. Người dùng chọn tên khảo sát 
5. Nhấn nút xem biểu đồ 
6. Hệ thống tạo biểu đồ 
7. Không tạo được biểu đồ: A2 
8. Hệ thống hiển thị biểu đồ lên trang web 
Alternative flows A1: Thông báo không tải dữ liệu lên được 
A2: Thông báo không tạo được biểu đồ 
 Activity diagram: 
 Sequence diagram: 
BÀI 5: > TRANG 75 
 Class diagram: 
Tìm kiếm khảo sát 
 Giao diện 
BÀI 5: > TRANG 77 
Name Tìm kiếm khảo sát 
Description Người dùng tìm kiếm khảo sát 
Actor Người dùng 
Pre conditions  Hiển thị trang tìm kiếm khảo sát 
Post conditions Hiển thị kết quả tìm kiếm khảo sát 
Flow of events 1. Hệ thống tải lên danh sách các khảo sát 
2. Không tải lên được: A1 
3. Hệ thống hiển thị danh sách các khảo sát 
4. Người dùng chọn điều kiện tìm kiếm 
5. Nhập vào thông tin tìm kiếm 
6. Nhấn nút tìm kiếm 
7. Hệ thống tìm kiếm khảo sát trong cơ sở dữ liệu 
8. Không tìm thấy khảo sát:A2 
9. Hệ thống tải lên các khảo sát tìm được 
10. Không tải lên được:A3 
11. Hiển thị danh sách khảo sát tìm được 
Alternative flows A1: Thông báo không tải dữ liệu lên được 
A2: Thông báo không tìm thấy khảo sát 
A3: Thông báo không tải dữ liệu lên được 
 Activity diagram: 
 Sequence diagram: 
BÀI 5: > TRANG 79 
 Class diagram: