Giáo trình môn Phân tích và thiết kế hệ thống thông tin

235 trang vanle 6340

Download

Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình môn Phân tích và thiết kế hệ thống thông tin", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

giao_trinh_mon_phan_tich_va_thiet_ke_he_thong_thong_tin.pdf

Nội dung text: Giáo trình môn Phân tích và thiết kế hệ thống thông tin

TRẦN ĐÌNH QUẾ GIÁO TRÌNH PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG THÔNG TIN PTIT
MỤC LỤC MỤC LỤC CHƯƠNG 1: CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 1 1.1 GIỚI THIỆU 1 1.2 CÁC KIỂU HỆ THỐNG THÔNG TIN 1 1.3 CÁC KHÁI NIỆM CƠ BẢN CỦA HỆ HƯỚNG ĐỐI TƯỢNG 2 1.3.1 Lớp và đối tượng 3 1.3.2 Phương thức và thông điệp 4 1.3.3 Đóng gói và ẩn dấu thông tin 5 1.3.4 Đa xạ và ràng buộc động 8 1.3.5 Quan hệ giữa các lớp 8 1.4 SỬ DỤNG LẠI 17 1.5 KẾT LUẬN 19 BÀI TẬP 19 CHƯƠNG 2: MÔ HÌNH HÓA HỆ PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 20 2.1 GIỚI THIỆU VỀ UML 20 2.1.1 Lịch sử phát triển của UML 20 2.1.2 UML – Ngôn ngữ mô hình hoá hướng đối tượng 20 2.1.3 Các khái niệm cơ bản trong UML 21 2.2 CÁC BIỂU ĐỒ TRONG UML 23 2.2.1 Biểu đồ ca sử dụng 24 2.2.2 Biểu đồ lớp 26 2.2.3 Biểu đồ trạng thái 32 2.2.4 Biểu đồ tuần tự PTIT 34 2.2.5 Biểu đồ giao tiếp 36 2.2.6 Biểu đồ hoạt động 38 2.2.7 Biểu đồ thành phần 40 2.2.8 Biểu đồ triển khai 41 2.3 PHƯƠNG PHÁP LUẬN PHÁT TRIỂN PHẦN MỀM 42 2.3.1 Khái niệm phương pháp luận 42 2.3.2 Các pha phát triển truyền thống 44 2.3.3 Phương pháp luận hướng đối tượng 45 2.3.4 UP 47 2.3.5 Một tiến trình phát triển phần mềm đơn giản 53 2.4 GIỚI THIỆU CÔNG CỤ PHÁT TRIỂN PHẦN MỀM 54 2.5 KẾT LUẬN 57 BÀI TẬP 57 CHƯƠNG 3: XÁC ĐỊNH YÊU CẦU 59 3.1 GIỚI THIỆU 59 3.2 CÁC BƯỚC TRONG PHA XÁC ĐỊNH YÊU CẦU 59
MỤC LỤC 3.2.1 Yêu cầu là gì? 59 3.2.2 Xác định yêu cầu 61 3.3 XÁC ĐỊNH YÊU CẦU NGHIỆP VỤ 62 3.3.1 Xác định và mô tả các tác nhân 63 3.3.2 Xây dựng Bảng Thuật ngữ 64 3.3.3 Xác định và mô tả các ca sử dụng nghiệp vụ 66 3.3.4 Mô tả chi tiết ca sử dụng 67 3.3.5 Xây dựng biểu đồ giao tiếp (Communication diagram) 67 3.3.6 Xây dựng biểu đồ hoạt động (Activity diagram) 68 3.4 XÁC ĐỊNH YÊU CẦU HỆ THỐNG 69 3.4.1 Xác định và mô tả các tác nhân 70 3.4.2 Xác định và mô tả các ca sử dụng 71 3.4.3 Xây dựng biểu đồ ca sử dụng 72 3.4.4 Xây dựng kịch bản 74 3.4.5 Xếp ưu tiên các ca sử dụng 77 3.4.6 Phác họa giao diện người dùng 78 BÀI TẬP 81 CHƯƠNG 4: PHÂN TÍCH YÊU CẦU 82 4.1 GIỚI THIỆU 82 4.2 CÁC BƯỚC TRONG PHA PHÂN TÍCH 83 4.3 PHÂN TÍCH TĨNH 84 4.3.1. Xác định các lớp 84 4.3.2 Xác định quan hệ giữa các lớp 85 4.3.3 Xây dựng biểu đồ lớp 85 4.3.4 Xác định thuộc tính lớp 89 4.4 PHÂN TÍCH ĐỘNG 93 4.4.1 Xây dựng biểu đồ giao tiếp 94 4.4.2 Gán phương thức cho các lớp 96 4.5 CASE STUDY: HỆ QUẢNPTIT LÝ ĐĂNG KÝ HỌC THEO TÍN CHỈ 100 4.5.1 Xác định yêu cầu 100 4.5.2 Phân tích tĩnh 113 4.5.3 Phân tích động 119 4.6 KẾT LUẬN 121 BÀI TẬP 122 CHƯƠNG 5: THIẾT KẾ KIẾN TRÚC HỆ THỐNG 123 5.1 GIỚI THIỆU 123 5.2 CÁC BƯỚC TRONG PHA THIẾT KẾ 124 5.3 LỰA CHỌN CÔNG NGHỆ MẠNG CHO HỆ THỐNG 125 5.3.1 Kiến trúc mạng đơn tầng và hai tầng 125 5.3.2 Kiến trúc ba tầng 128 5.3.3 Kiến trúc Client – Server và kiến trúc phân tán 129 5.3.4 Biểu diễn hình trạng mạng với UML 131 5.4 THIẾT KẾ TƯƠNG TRANH VÀ AN TOÀN-BẢO MẬT 132 5.4.1 Thiết kế tương tranh 132 5.4.2 Thiết kế an toàn-bảo mật 133 ii
MỤC LỤC 5.5 PHÂN RÃ HỆ THỐNG THÀNH CÁC HỆ THỐNG CON 135 5.5.1 Hệ thống và hệ thống con 135 5.5.2 Các cụm (Layer) 135 5.5.3 Ví dụ : Java Layers - Applet plus RMI 138 5.6 XÂY DỰNG BIỂU ĐỒ GÓI 139 5.7 KẾT LUẬN 140 BÀI TẬP 140 CHƯƠNG 6: THIẾT KẾ CÁC HỆ THỐNG CON 141 6.1 GIỚI THIỆU 141 6.2 XÂY DỰNG MÔ HÌNH LỚP THIẾT KẾ 141 6.2.1 Ánh xạ các phương thức 142 6.2.2 Các kiểu biến 142 6.2.3 Phạm vi của các trường 143 6.2.4 Các toán tử truy nhập 143 6.2.5 Ánh xạ các lớp, thuộc tính và kiểu quan hệ hợp thành 143 6.2.6 Ánh xạ các kiểu quan hệ khác 144 6.3 XÂY DỰNG LƯỢC ĐỒ CƠ SỞ DỮ LIỆU 148 6.3.1 Các hệ quản trị cơ sở dữ liệu 148 6.3.2 Mô hình quan hệ 149 6.3.3 Ánh xạ các lớp thực thể 150 6.3.4 Ánh xạ các liên kết 150 6.3.5 Ánh xạ trạng thái đối tượng 152 6.4 THIẾT KẾ GIAO DIỆN NGƯỜI SỬ DỤNG 155 6.5 SỬ DỤNG FRAMEWORK, MẪU VÀ THƯ VIỆN 160 6.6 KẾT LUẬN 160 BÀI TẬP 160 PHỤ LỤC A: LỰA CHỌN CÔNG NGHỆ 161 A.1 GIỚI THIỆU PTIT 161 A.2 CÔNG NGHỆ TẦNG CLIENT 161 A.3 GIAO THỨC GIỮA TẦNG CLIENT VÀ TẦNG GIỮA 162 A.4 CÔNG NGHỆ TẦNG GIỮA 163 A.5 CÔNG NGHỆ TẦNG GIỮA ĐẾN TẦNG DỮ LIỆU 164 A.6 CÁC CÔNG NGHỆ KHÁC 165 PHỤ LỤC B: CASE STUDY: HỆ QUẢN LÝ ĐĂNG KÝ HỌC THEO TÍN CHỈ 169 B.1 XÁC ĐỊNH YÊU CẦU 169 B.2 PHÂN TÍCH TĨNH 201 B3. PHÂN TÍCH ĐỘNG 207 TÀI LIỆU THAM KHẢO 227
LỜI NÓI ĐẦU LỜI NÓI ĐẦU Phân tích và thiết kế các hệ thống thông tin là một môn học bắt buộc thuộc chương trình Đại học dành cho sinh viên ngành Công nghệ thông tin. Có nhiều cách tiếp cận phát triển hệ thống tùy theo kiểu ta muốn xây dựng, yêu cầu người dùng và công nghệ mà chúng ta sử dụng. Tuy nhiên, dù theo cách tiếp cận phát triển nào, các dự án phát triển hệ thống thông tin cũng phải qua các pha truyền thống sau đây: Xác định yêu cầu (requirement determination), phân tích yêu cầu (requirement analysis), thiết kế (design), cài đặt (implementation), kiểm thử (testing) và bảo trì (maintenance). Ngày nay, cách tiếp cận hướng đối tượng càng ngày càng trở thành phổ biến trong công nghiệp phát triển phần mềm do tính hiệu quả về mặt phát triển cũng như sự hỗ trợ mạnh mẽ của nhiều công nghệ. Cách tiếp cận này xem hệ thống như một tập các lớp với các thuộc tính và thao tác hay hành vi tương ứng cùng với các tương tác giữa các đối tượng trong các lớp. Hơn nữa, sự phát triển mạnh mẽ về kỹ thuật, công nghệ, công cụ hỗ trợ và đặc biệt ngôn ngữ mô hình hóa UML (Unified Modeling Language) đã làm thay đổi căn bản quan niệm và cách phát triển hệ phần mềm. Giáo trình này được xây dựng theo chương trình đào tạo theo tín chỉ Ngành Công nghệ Thông tin tại Học viện Công nghệ Bưu chính Viễn thông. Nội dung tập trung trình bày một số vấn đề cơ bản của phân tích và thiết kế theo hướng đối tượng bao gồm trong các pha xác định yêu cầu, phân tích yêu cầu và thiết kế. Giáo trình được biên soạn dựa vào những tài liệu có sẵn được liệt kê trong phần tài liệu tham khảo và kinh nghiệm gỉang dạy nhiều năm của tác giả. Ngoài những ví dụ minh họa riêng rẽ, case study Hệ quản lý học tập theo tín chỉ được sử dụng xuyên suốt trong nhiều chương nhằm giúp cho bạn đọc dễ dàng theo dõi các bước của các pha phát triển. PTIT Mục đích của tài liệu này là nhằm phục vụ sinh viên ngành công nghệ thông tin khi học môn Phân tích và Thiết kế Hệ thống Thông tin. Tài liệu cũng có thể dành cho giảng viên tham khảo khi giảng dạy các môn học liên quan và sinh viên các ngành học khác như Điện tử - Viễn thông có thể tham khảo hay tự học để thiết kế các hệ thông thông tin thông dụng. Nội dung tài liệu bao gồm: Chương 1: Cơ sở của phát triển phần mềm hướng đối tượng Giới thiệu các kiểu hệ thống thông tin và mô hình hệ thống dựa vào cách tiếp cận hướng đối tượng. Các khái niệm đối tượng và lớp, đóng gói, quan hệ giữa các lớp và vấn đề sử dụng lại mã nguồn sẽ được xem xét ở mức độ vừa phải đủ để bạn đọc có cái nhìn tổng quan về những kiến thức lập trình hướng đối tượng phục vụ cho việc tìm hiểu các chương sau. Chương 2. Mô hình hóa hệ phần mềm hướng đối tượng iv
LỜI NÓI ĐẦU Nội dung bao gồm giới thiệu về UML, các biểu đồ UML và sử dụng các biểu đồ UML trong phân tích và thiết kế hướng đối tượng. Một số phương pháp luận phát triển phần mềm hướng đối tượng hiện nay cũng sẽ được điểm qua và đặc biệt phương pháp luận UP sẽ được khảo sát chi tiết hơn. Cuối chương sẽ trình bày các pha và các bước thực hiện trong mỗi pha để phục vụ cho các chương sau này. Chương 3. Xác định yêu cầu Nội dung tập trung trình bày pha xác định yêu cầu dựa trên quan điểm nghiệp vụ và quan điểm người phát triển. Một case study về Quản lý đăng ký học theo tín chỉ sẽ được xem xét. Chương 4. Phân tích yêu cầu Nội dung bao gồm tổng quan quá trình phân tích và phân tích tĩnh cũng như phân tích động. Phần phân tích tĩnh đề cập đến việc xác định các lớp và quan hệ giữa các lớp, các thuộc tính. Phần phân tích động bàn về việc thực thi các lớp, các lớp biên, điều khiển và thực thể, các biểu đồ giao tiếp, phương thức trong lớp và cách xây dựng dựa trên gán trách nhiệm cho lớp và biểu đồ trạng thái. Chương 5. Thiết kế kiến trúc hệ thống Trình bày các bước trong thiết kế hệ thống, chọn topo hệ thống mạng cho thiết kế, một số chủ đề về công nghệ, thiết kế đồng thời và an toàn hệ thống. Nội dung bao gồm: Các công nghệ tầng client; Các công nghệ tầng trung gian; Các công nghệ tầng trung gian đến tầng dữ liệu; Các kiểu cấu hình; Các gói theo UML. Chương 6. Thiết kế chi tiết Chương này trình bày ánh xạ mô PTIThình lớp phân tích thành mô hình lớp thiết kế, xử lý lưu trữ với cơ sở dữ liệu quan hệ, một số vấn đề liên quan đến giao diện người sử dụng, thiết kế các dịch vụ nghiệp vụ, sử dụng pattern, framework và thư viện. Tác giả vô cùng biết ơn các đồng nghiệp thuộc Khoa Công nghệ Thông tin, Học viện Công nghệ Bưu chính Viễn thông đã tạo động lực để tác giả hoàn thành tài liệu này. Trong quá trình sọan thảo giáo trình, sinh viên Khoa Công nghệ Thông tin qua nhiều thế hệ đã có nhiều đóng góp, đặc biệt góp phần xây dựng case study Hệ Quản lý Học tập theo tín chỉ. Vì vậy, tác giả muốn dành món quà này cho các bạn sinh viên trong gần 15 năm đã nuôi dưỡng niềm say mê giảng dạy và là cội nguồn của mọi cội nguồn để tác giả viết giáo trình này. Mặc dù tác giả đã có nhiều nỗ lực để giáo trình này ra đời nhưng chắc chắn không thể tránh khỏi những thiếu sót. Tác giả rất mong nhận được nhiều ý kiến đóng góp của các đồng nghiệp cùng các bạn sinh viên để tài liệu ngày được hoàn thiện hơn. Tác giả
CHƯƠNG 1 CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 1.1 GIỚI THIỆU Ngày nay, cách tiếp cận này hướng đối tượng đã được sử dụng rộng rãi cho phát triển các hệ thống phần mềm như trong quản lý doanh nghiệp, thương mại điện tử, các hệ thời gian thực, các hệ thống thông minh Mục đích của chương này nhằm trình bày các kiểu hệ thống thông tin, những khái niệm cơ bản trong lập trình hướng đối tượng như đối tượng, lớp, đóng gói, kế thừa, đa xạ. Phần cón lại xem xét, phân tích các quan hệ giữa các lớp, các cách sử dụng lại mã nguồn hiện nay. 1.2 CÁC KIỂU HỆ THỐNG THÔNG TIN Trong thực tế có rất nhiều kiểu hệ thống thông tin và để dễ phân loại người ta thường chia các hệ thống thông tin thành bốn mức: Các hệ thống điều khiển Các hệ cơ sở tri thức Các hệ thống quản lý Các hệ thống chiến lược Các hệ thống điều khiển: Dành cho các nhà quản lý vận hành hay quản lý hệ thống để thu được những câu trả lời cho các câu hỏi thường ngày. Ví dụ, hệ thống lưu vết trình tự các hoạt động và giao dịch hàng ngày như các hệ xử lý giao dịch (Transaction Processing Systems), điều khiển thiết bị hayPTIT dây chuyền sản xuất, lưu trữ giao dịch, lập lịch, xử lý đơn đặt hàng Các hệ cơ sở tri thức: Dành cho các nhân viên tri thức và xây dựng dữ liệu nhằm giúp tổ chức, khám phá và tích hợp tri thức mới từ tri thức hiện thời vào nghiệp vụ của họ hay điều khiển luồng công việc. Ví dụ, các hệ thống hoạt đông dựa trên tri thức, tự động hóa văn phòng, hệ xử lý ngôn ngữ, hệ thống tư vấn trong thương mại điện tử Các hệ thống quản lý: Dành cho các nhà quản lý trung gian để phục vụ việc giám sát, điều khiển, ra quyết định và các hoạt động quản trị hay hỗ trợ ra các quyết định quan trọng (ít có cấu trúc) với các yêu cầu về thông tin không rõ ràng. Ví dụ hệ thông tin quản lý, hệ hỗ trợ quyết định, hệ quản lý bán hàng cần biết hàng tồn kho, ngân sách hàng năm để lập kế hoạch sản xuất, phân tích chi phí, phân tích giá cả/lợi nhuận Các hệ thống chiến lược:Dành cho các nhà quản lý chính để giúp giải quyết và vạch ra các chiến lược và các xu hướng lâu dài; so sánh khả năng của tổ chức với những thay đổi của môi trường bên ngoài và cơ hội xảy ra trong khoảng thời gian dài. Ví dụ, hệ hỗ trợ 1
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG thực thi cho dự đoán ngân sách, xu hướng bán hàng trong năm năm, kế hoạch hoạt động trong năm năm, kế hoạch về lợi nhuận, nhân lực. Như vậy, dựa trên bốn mức trên có thể phân thành sáu kiểu hệ thống thông tin tương ứng như sau: Các hệ xử lý giao dịch (Transaction Processing Systems). Các hệ cơ sở tri thức (Knowledge based Systems). Các hệ tự động hóa văn phòng (Office Automation Systems). Các hệ thông tin quản lý (Management Information Systems). Các hệ trợ giúp quyết định (Decision Support Systems). Các hệ trợ giúp thực thi (Executive Support Systems). Tương ứng với các kiểu hệ thống thông tin, các quá trình xử lý và lưu trữ cũng sẽ được thể hiện khác nhau. Vì vậy, các nhà phát triển cần chú ý nắm vững những đặc trưng của kiểu hệ thống mà mình cần phải phát triển. Hơn nữa, đa phần các hệ thống thông tin trên môi trường Internet ngày nay càng trở nên phức tạp khi nó cần phải tích hợp nhiều kiểu hệ thống thông tin. Ví dụ, các hệ thương mại điện tử như eBay, Amazon là nhưng hệ phân tán không chỉ có chức năng quản lý giao dịch mua, đặt hàng, bán hàng, mà còn có chức năng quản lý giao dịch thanh toán và tư vấn khách hàng Để có thể thực hiện các chức năng này, các nhà phát triển hệ thống cần phải biết sử dụng các công nghệ, kỹ thuật lưu trữ và xử lý phân tán cũng như nắm vững các kỹ thuật trong biểu diễn và xử lý tri thức của các lĩnh vực liên quan như trí tuệ nhân tạo,PTIT khai phá dữ liệu, web ngữ nghĩa 1.3 CÁC KHÁI NIỆM CƠ BẢN CỦA HỆ HƯỚNG ĐỐI TƯỢNG Phần này nhằm trình bày một cách không hình thức một số khái niệm cơ bản của các hệ hướng đối tượng như lớp, đối tượng, phương thức, thông điệp, đóng gói, ẩn dấu thông tin, kế thừa, đa xạ, ràng buộc động. Những khái niệm này giúp cho các nhà phân tích phân rã những hệ thống phức tạp thành những môđun nhỏ hơn nhằm dễ dàng quản lý, thực thi và đồng thời dễ dàng tích hợp thành một hệ thống thông tin. Tính môđun hóa này sẽ giúp cho việc phát triển thuận lợi hơn vì qua đó dễ chia sẻ với các thành viên trong nhóm và dễ dàng trao đổi với người sử dụng trong quá trình khảo sát yêu cầu. Việc môdun hóa cũng giúp nhóm phát triển xây dựng được những gói phần mềm có thể sử dụng lại cho các dự án sau này. Hơn nữa, nhiều nghiên cứu đã chỉ ra rằng cách “tư duy đối tượng” được xem là hiện thực hơn cách tư duy thuật toán hay dữ liệu vì nó thể hiện cách suy nghĩ thông thường con người về thế giới xung quanh. 2
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 1.3.1 Lớp và đối tượng Lớp (class) là một thuật ngữ chung để xác định và tập hợp các thể hiện hay các đối tượng đặc biệt nào đó. Lớp đóng gói các đặc điểm chung của một nhóm các đối tượng. Khái niệm lớp đã được các nhà phát triển phần mềm hướng đối tượng sử dụng để mô tả các đặc trưng mà các dạng đối tượng cụ thể có thể có. Đối tượng (object) là một khởi tạo của lớp, nó có thể là một sự vật, một thực thể, một danh từ hoặc bất cứ cái gì mà bạn có thể nhặt lên hoặc ném đi, hay những gì mà bạn có thể tưởng tượng ra với một số đặc tính nào đó của nó. Mỗi đối tượng có các thuộc tính (attribute) mô tả thông tin về đối tượng đó. Trạng thái (state) của một đối tượng được xác định bởi bộ giá trị của những thuộc tính và quan hệ với những đối tượng khác tại một thời điểm cụ thể. Mỗi đối tượng có một số hành vi (behavior) nhằm đặc tả những gì đối tượng này có thể thực hiện được. Trong các mô hình hướng đối tượng, các thuật ngữ hành vi, hành động (action), thao tác (operation), phương thức (method) đều có nghĩa như nhau nhưng thường được dùng cho các ngữ cảnh khác nhau. Ví dụ, khi nói về các đối tượng thực tế thì ta thường hay nói hành vi hay hành động của đối tượng đó; khi đề cập đến đối tượng trong lập trình người ta thường dùng phương thức hay thao tác nhưng phương thức được dùng phổ biến, nó được xem là thể hiện cài đặt của hành vi. Ví dụ, lớp Sinh viên Sinhvien trong Hệ quản lý học tín chỉ có các thuộc tính là mã sinh viên, họ và tên, địa chỉ .Các đối tượng như sinh viên Nguyễn Minh Ngọc có mã sinh viên NH12345, địa chỉ 177 Nguyễn Trãi, Hà nội và có thể có các hành vi như đăng ký học, hủy đăng ký, xem lịch họcPTIT Lớp Sách Sach trong Hệ quản lý thư viện có các thuộc tính là tên sách sachTen, tên tác giả sachTacgia, nhà xuất bản sachNhaXuatban, năm xuất bản sachNamXuatban Các đối tượng như cuốn sách “Phân tích và thiết kế hướng đối tượng” của tác giả Đặng Văn Đức, nhà xuất bản Giáo dục, năm 2002 có thể có các hành vi như xóa sách xoaSach, thêm sách themSach, cập nhật thông tin sách capnhatThongtinSach Biểu diễn đối tượng và lớp Để có thể mô tả và suy nghĩ về lớp - đối tượng, chúng ta phải có cách biểu diễn chúng theo biểu đồ. Các ký hiệu biểu đồ mà chúng ta sử dụng ở đây là Biểu đồ lớp và đối tượng trong ngôn ngữ mô hình hóa UML (Chi tiết sẽ được trình bày trong Chương 2). Trong lớp Sách Sach được mô tả trong UML bao gồm ba thành phần là tên lớp, các thuộc tính và các phương thức kèm theo dấu ngoặc đơn như Hình 1.1: 3
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Sach sachTen sachTacgia sachNhaXuatban sachNamXuatban xoaSach() themSach() capnhatThongtinSach() Hình 1.1: Biểu diễn lớp sách và đối tượng sách được biểu diễn bởi Hình 1.2 Sach1: Sach sachTen = PhantichvaThietkeHuongdoituong sachTacgia = DangVanDuc sachNhaXuatban = Giaoduc sachNam = 2002 xoaSach() themSach() capnhatThongtinSach() Hình 1.2: Biểu diễn đối tượng sách PTIT Mỗi đối tượng được mô tả bởi ba thành phần tương ứng với lớp của nó: - Tên của đối tượng có gạch chân và dấu a:A thể hiện a thuộc lớp A - Các giá trị của thuộc tính - Các phương thức để trong dấu ngoặc thể hiện thao tác hay hành vi của đối tượng 1.3.2 Phương thức và thông điệp Phương thức (method) cài đặt hành vi (hay còn gọi hành động, thao tác) của đối tượng. Phương thức chính là hành động mà một đối tượng có thể thực hiện và nó tương tự như một hàm hay thủ tục trong ngôn ngữ truyền thống như C, Pascal. Tuy nhiên, sự khác biệt có thể dễ thấy là phương thức phải cài đặt trong một lớp nào đó, còn hàm có thể viết bất kỳ ở đâu. Thông điệp (message) là thông tin được gửi cho đối tượng để kích hoạt các phương thức. Một thông điệp chính là lời gọi hàm hay thủ tục truyền thống nhưng lại từ một đối tượng này đến đối tượng khác. 4
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Ví dụ, trong Hệ quản lý thư viện, nếu nhân viên thư viện cần chèn thêm một cuốn sách mới, những thông tin được đưa vào qua giao diện sẽ được hệ thống gửi đi dưới dạng thông điệp chèn cuốn sách mới cho chương trình ứng dụng. Khi đó đối tượng sách sẽ nhận thông điệp và thực hiện các công việc cần thiết gọi là thực hiện phương thức để chèn cuốn sách mới vào hệ thống. 1.3.3 Đóng gói và ẩn dấu thông tin Các ý tưởng đóng gói (encapsulation) và ẩn dấu thông tin (information hiding) có liên quan mật thiết nhau trong các hệ hướng đối tượng. Trong khi các cách tiếp cận phát triển hệ thống thông tin truyền thống chỉ chú trọng hoặc tiến trình hoặc dữ liệu, cách tiếp cận hướng đối tượng thể hiện tính đóng gói bằng cách kết hợp cả hai tiến trình và dữ liệu vào trong một thực thể gọi là đối tượng. Ẩn dấu thông tin thực ra đã được thể hiện trong phương pháp phát triển các hệ phần mềm theo hướng cấu trúc. Nguyên lý của ẩn dấu thông tin cho rằng chỉ thông tin được đòi hỏi để sử dụng môđun phần mềm là được công khai cho sử dụng môđun đó. Nghĩa là, chỉ thông tin được yêu cầu chuyển đến môđun này và thông tin trả về từ môđun đó là được công khai mà thôi. Chúng ta thực sự không quan tâm đến cách thức đối tượng thực hiện chức năng của nó thế nào. Trong các hệ hướng đối tượng, việc kết hợp đóng gói thông tin và nguyên lý ẩn dấu thông tin có nghĩa rằng nguyên lý này được áp dụng vào các đối tượng thay vì chỉ áp dụng vào hàm hay tiến trình. Khi PTITđó, các đối tượng được xem như là các hộp đen. Trong ví dụ Hệ quản lý thư viện 1.3.2, chúng ta chỉ quan tâm đến thông điệp chèn một cuốn sách mới nhưng thuật toán bên trong cần đáp ứng với thông điệp là ẩn dấu với các thành phần khác của hệ thống. Thông tin duy nhất mà đối tượng sách này cần biết là tập các phép toán hay phương thức mà các đối tượng khác có thể tiến hành và các thông điệp nào cần phải gửi để kích hoạt chúng. Các nghiên cứu trong cách tiếp cận hướng đối tượng đã chỉ ra rằng đóng gói có một số lợi ích sau đây: Đóng gói là an toàn vì một đối tượng không thể can thiệp để thay đổi trạng thái tức là các giá trị thuộc tính của các đối tượng khác. Đóng gói làm đơn giản hóa việc chuyển đổi một lớp đang tồn tại thành một lớp được dùng để tạo các đối tượng phân tán (từ xa). Đối tượng phân tán thường nằm ở máy chủ, các phương thức của nó có thể được gọi bởi các ứng dụng nằm trên các máy khác (nói cách khác là có thể được gọi thông qua mạng). Do đó, các 5
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG thuộc tính thuộc đối tượng đó không thể được gọi trực tiếp như với đối tượng cục bộ. Tuy nhiên, nếu đưa vào các phương thức set và get, ta có thể làm được điều này dễ dàng. Ngoài ra, việc sử dụng các phương thức set và get sẽ cô lập chúng ta khỏi những thay đổi khi cài đặt chi tiết thêm một tính chất. Ví dụ, có thể đổi thuộc tính từ kiểu int sang kiểu String mà không ảnh hưởng tới các lớp khác, miễn là chúng ta thực hiện việc chuyển đổi thích hợp trong các phương thức set và get. Ví dụ: Lớp Employee chứa các thông tin mà ứng dụng cần để miêu tả một nhân viên: public class Employee{ public int employeeID; public String firstName; public String lastName; } Các thuộc tính đều ghi là public nghĩa là chúng có thể được truy cập từ mọi lớp bằng các câu lệnh sau: Employee emp = new Employee(); emp.employeeID = 123456; emp.firstName = “John”; emp.lastName = “Smith”; Mặc dù Java cho phép đọc và sửa đổi các trường hay thuộc tính theo cách này, nhưng thông thường ta không nên làm như vậy. Thay vào đó, ta cần thay đổi phạm vi truy cập tới các trường để giới hạn khả năng truy cập của chúng bằng cách sử dụng các phương thức set, get cho mỗi trường để cóPTIT thể truy cập tới thuộc tính. public class Employee { protected int employeeID; protected String firstName; protected String lastName; public int getEmployeeID() { return employeeID; } public void setEmployeeID(int id) { employeeID = id; } public String getFirstName() { return firstName; } 6
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG public void setFirstName(String name) { firstName = name; } public String getLastName() { return lastName; } public void setLastName(String name) { lastName = name; } } Ví dụ tiếp tục sau đây chỉ ra ý nghĩa của đóng gói khi ẩn giấu việc vài đặt chi tiết public class Employee { protected String employeeID; protected String firstName; protected String lastName; public int getEmployeeID() { return Integer.parseInt(employeeID); } public void setEmployeeID(int id) { employeeID = Integer.toString(id); } public String getFirstName() { return firstName;PTIT } public void setFirstName(String name) { firstName = name; } public String getLastName() { return lastName; } public void setLastName(String name) { lastName = name; } } Mặc dù, việc cài đặt thuộc tính employeeID bị thay đổi, nhưng các lớp khác khi đọc và sửa đổi thuộc tính này sẽ không nhìn thấy bất kỳ thay đổi nào trong hành vi của nó, vì việc thay đổi trong cài đặt được che giấu bởi các phương thức set và get. Đóng gói các 7
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG thuộc tính của lớp cho phép định nghĩa các giá trị dẫn xuất có khả năng truy cập. Ví dụ, bạn có thể định nghĩa phương thức getFullName() trong lớp Employee để trả về họ tên đầy đủ dưới dạng một chuỗi đơn: public String getFullName() { return firstName + “ “ + lastName; } Tất nhiên, có thể lấy giá trị dẫn xuất mà không cần tạo phương thức get, nhưng như vậy thường sẽ tạo ra các đoạn mã trùng nhau khi sử dụng. Ví dụ, để dẫn xuất tên đầy đủ ở một số vị trí trong ứng dụng, bạn phải copy đoạn mã (firstName + “ “ + lastName) vào các vị trí đó và nếu thay đổi cài đặt, bạn phải thay đổi từng vị trí như khi bạn muốn có thêm middleName. Nhưng khi sử dụng phương thức getFullName() thì bạn chỉ cần thay đổi ở một vị trí trong mã nguồn mà thôi. 1.3.4 Đa xạ và ràng buộc động Đa xạ (polymorphism) có nghĩa là cùng một thông điệp có thể được thể hiện một cách khác nhau qua các lớp đối tượng khác nhau. Ví dụ, trong hệ quản lý thư viện, chèn thêm một cuốn sách khác với chèn thêm một bạn đọc hay một nhân viên vì thông tin các đối tượng này được đưa vào và truyền đi khác nhau và sau đó cũng lưu trữ khác nhau. May mắn là các ngôn ngữ lập trình hiện nay cho phép chúng ta chúng ta xử lý tính đa xạ này thông qua ràng buộc động (dynamic binding). Ràng buộc động là kỹ thuật cho phép hoãn định kiểu một đối tượng cho đến thời gian chạy. Nghĩa là một phương thức thực sự được gọi khi chương trình chạy. NgượcPTIT lại, trong ràng buộc tĩnh kiểu của đối tượng được xác định tại thời điểm biên dịch và do đó người phát triển phải tự chọn phương thức nào được gọi thay vì để hệ thống tự thực hiện. Ví dụ trong ngôn ngữ lập trình truyền thống như C, chúng ta phải viết một logic quyết định bằng cách sử dụng các toán tử if hay case để xác định đối tượng nào cần chèn thêm và phải gọi tên hàm tương ứng (thêm sách, thêm bạn đọc hay thêm nhân viên). Tuy nhiên, trong lập trình hướng đối tượng, chúng ta có thể thiết kế chương trình để cho hệ thống tự lựa chọn hàm thực thi tương ứng vào thời gian chạy. 1.3.5 Quan hệ giữa các lớp 1.3.5.1 Quan hệ liên kết, kết hợp và hợp thành Không có một đối tượng nào có thể tồn tại và hoạt động riêng lẻ. Tất cả các đối tượng đều được liên kết với các đối tượng khác một cách trực tiếp hoặc gián tiếp, mạnh hoặc 8
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG yếu. Các liên kết giúp ta tìm ra nhiều thông tin liên quan và hành vi phụ thuộc. Ví dụ, nếu ta đang xử lý một đối tượng khách hàng Customer có tên Ngọc và ta muốn gửi cho Lan một bức thư thì ta cần phải biết Ngọc đang sống ở số nhà 168 Nguyễn Trãi, Hà nội. Như vậy, ta muốn có thông tin về địa chỉ được lưu trữ trong đối tượng Address, vì vậy cần có kết nối giữa Customer và Address để biết thư được gửi đến đâu. Trong mô hình hóa đối tượng với UML, quan hệ giưã các đối tương được thể hiện theo ba cách chính sau đây: liên kết, kết hợp và hợp thành. Không phải dễ dàng để xác định chính xác sự khác biệt giữa ba quan hệ này, sau đây là một số gợi ý: Liên kết (association) là một dạng quan hệ trong đó các đối tượng là một phần của một nhóm, hoặc một họ các đối tượng nhưng chúng không hoàn toàn phụ thuộc vào đối tượng khác. Ví dụ, xét các đối tượng xe hơi, người lái xe và hai khách đi xe. Khi người lái xe và hai khách đi xe ở trong xe, họ được liên kết với nhau vì họ cùng đi về một hướng, họ cùng chiếm một khoảng không gian nhưng liên kết sẽ mất khi xe trả một vị khách nào đó ở nơi yêu cầu, vị khách đó sẽ không còn liên kết với các đối tượng khác nữa. Kết hợp (aggregation): nghĩa là đặt các đối tượng có liên kết với nhau để tạo thành một đối tượng lớn hơn. Ví dụ, máy tính được tạo bởi các bộ phận như màn hình, ổ cứng, bàn phím Kết hợp thường có dạng phân cấp bộ phận-toàn thể (part-whole). Kết hợp ám chỉ sự phụ thuộc giữa bộ phận và toàn thể. Ví dụ, màn hình vẫn là màn hình nếu lấy nó ra khỏi máy tính, nhưng máy tính sẽ mất tác dụng nếu thiếu màn hình. Hợp thành (Composition)PTIT: là dạng mạnh hơn của kết hợp trong đó bộ phận phụ thuộc vào toàn thể một cách duy nhất và đối tượng toàn thể có trách nhiệm tạo lập và hủy bỏ đối tượng bộ phận. Như vậy, khi đối tượng toàn thể bị huỷ thì đối tượng bộ phận cũng hủy theo. Như đã trình bày, không có một ranh giới rõ ràng để phân biệt giữa các quan hệ này đặc biệt quan hệ kết hợp và hợp thành. Nhưng không phải việc phân biệt này lúc nào cũng có thể giải quyết được vấn đề mà cần phải suy nghĩ thường xuyên và cần có kinh nghiệm. Việc lựa chọn này ảnh hưởng rất nhiều đến cách ta thiết kế phần mềm sau này. Ví dụ: Vấn đề quản lý hóa đơn bán hàng liên quan đến hóa đơn Order, các mặt hàng khách hàng đặt OrderLine, Danh sách hóa đơn OrderList và khách hàng Customer. Có nhiều cách cài đặt cho các quan hệ này, ở đây chúng ta sẽ trình bày một cách cài đặt để minh họa rõ hơn sự khác biệt của quan hệ này. 9
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Liên kết: Quan hệ liên kết thường được miêu tả giống như quan hệ tham chiếu (reference), trong đó một đối tượng nắm giữ một tham chiếu đến đối tượng khác. Hình 1.1: Quan hệ liên kết Có thể cài đặt với Java như sau: package relation; public class Customer { private String address; private String code; private String name; } package relation; public class Order { private relation.Customer customer; private OrderLine[] orderLine; private Currency total; public OrderLine addLine() { throw new UnsupportedOperationException(); } PTIT public void removeLine() { throw new UnsupportedOperationException(); } } Đây là quan hệ dễ cài đặt nhất, trong UML nó được biểu diễn bởi một đường thẳng nối giữa hai lớp. Chiều mũi tên nói lên rằng ta gọi đối tượng Customer từ đối tượng Order nhưng không gọi Order từ Customer. Kết hợp: Quan hệ giữa lớp OrderList và lớp Order thuộc kiểu kết hợp. Nghĩa là danh sách OrderList bao gồm nhiều Order nhưng các Order có đời sống riêng của nó và không cần phải là một bộ phận của danh sách OrderList cụ thể. 10
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Hình 1.2: Quan hệ kết hợp Cài đặt: package relation; public class Order { private relation.Customer customer; private OrderLine[] orderLine; private Currency total; public OrderLine addLine() { throw new UnsupportedOperationException(); } public void removeLine() { throw new UnsupportedOperationException(); } } package relation; import java.util.Vector; import aggregation.Order; public class OrderList { Vector PTIT order = new Vector (); public void add() { throw new UnsupportedOperationException(); } public int getCount() { throw new UnsupportedOperationException(); } public OrderIterator getIterator() { throw new UnsupportedOperationException(); } public void remove() { throw new UnsupportedOperationException(); } } 11
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Quan hệ kết hợp được biểu diễn trong UML bởi một đường thẳng có hình quả trám rỗng ở một đầu. Điều này xác định không có quan hệ sở hữu trong quan hệ này và các thể hiện của lớp được kết hợp sẽ được quản lý bên ngoài lớp kết hợp. Gian nhỏ chứa Customer chỉ ra một giới hạn, trong hàm khởi tạo của lớp OrderList có một tham số là Customer để giới hạn số lượng Order tương ứng với Customer đó trong Danh sách OrderList. Hợp thành Quan hệ giữa Order và OrderLine thuộc kiểu hợp thành. Các OrderLine của một Order đều thuộc về Order và không có ý nghĩa bên ngoài Order đó. Order có trách nhiệm hoàn toàn trong việc tạo, quản lý và xóa bất kỳ OrderLine nào trong Order đó. Trong UML, quan hệ này được biểu diễn bởi đường thẳng với một đầu có hình quả trám màu đen. Hình 1.3: Quan hệ hợp thành Cài đặt: package relation; public class OrderLine { private Currency value; aggregation.OrderPTIT orderLine; } package relation; public class Order { private Customer customer; private OrderLine[] orderLine; private Currency total; aggregation.OrderList unnamedOrderList_; public OrderLine addLine() { throw new UnsupportedOperationException(); } public void removeLine() { throw new UnsupportedOperationException(); } 12
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG } 1.3.5.2 Kế thừa Kế thừa (inheritance) là khái niệm đã được đề xuất và sử dụng rộng rãi trong xây dựng mô hình dữ liệu của nhưng năm 70, 80 thế kỷ trước. Nó cho phép ta thực hiện cách tư duy đặc biệt hóa (specialization) khi xây dựng một lớp mới bằng cách lấy lại một số đặc điểm, thuộc tính từ lớp cha và sau đó thêm vào một số đặc trưng riêng của nó. Kế thừa cũng cho phép ta thực hiện cách tư duy tổng quá hóa (generalization) bằng cách nhóm một số lớp thành một lớp tổng quát hơn để có thể đưa ra các đối tượng rộng hơn về thế giới mà ta đang sống. Để hiểu một cách đầy đủ hơn khái niệm kế thừa, chúng ta hãy xem xét một ví dụ thiết kế bộ sưu tập để lưu trữ các đối tượng cho sử dụng về sau này. Thiết kế kiến trúc phân cấp lớp Sau khi phân tích, chúng ta thấy có bốn kiểu bộ sưu tập như sau: Danh sách (List): lưu giữ các đối tượng theo thứ tự mà nó được đưa vào. Túi (Bag): lưu đối tượng nhưng không theo thứ tự. Danh sách liên kết (LinkedList): lưu các đối tượng theo thứ tự bằng cách cài đặt một chuỗi các đối tượng và mỗi đối tượng chỉ tới một đối tượng khác trong chuỗi. Danh sách liên kết cho phép cập nhật dễ dàng, nhưng truy cập chậm vì ta phải duyệt toàn bộ danh sách. PTIT Danh sách mảng (ArrayList): lưu các đối tượng theo thứ tự sử dụng như là một mảng, nghĩa là một chuỗi các ô nhớ liên tiếp. Mảng cho phép truy cập nhanh nhưng cập nhật chậm vì ta có thể phải dịch các phần tử hoặc tạo một mảng mới mỗi khi cập nhật. Làm thế nào thiết kế kiến trúc phân cấp lớp theo kiểu kế thừa? Điểm mấu chốt là cần phải xem xét sự tương đồng giữa các khái niệm với nhau. Rõ ràng, chúng đều là các bộ sưu tập, vì vậy lớp Collection sẽ đưa lên đầu. Trong bốn bộ sưu tập trên, chỉ có Bag là không lưu các đối tượng theo thứ tự, còn lại đều lưu đối tượng theo thứ tự. Do đó, ta đặt Bag trực tiếp ngay bên dưới Collection trong một nhánh riêng. Ta thấy, List không có ràng buộc gì về cài đặt bên trong, trong khi LinkedList và ArrayList thì có. Vì vậy, List sẽ là lớp cha của LinkedList và ArrayList. Như vậy, ta có cây phân cấp sau đây (Hình 1.4): 13
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Hình 1.4: Thiết kế kiến trúc phân cấp Trong thực tế, ta lại thường hay làm ngược lại. Trước hết, ta mô tả các lớp ở mức lá (Bag, ArrayList và LinkedList) và sau đó, tìm các khái niệm tổng quát hơn. Trong khi phát triển mô hình kế thừa, ta tìm các thông điệp để có thể chia sẻ, đưa chúng vào mô hình kế thừa càng ở các lớp trên càng tốt. Ta sẽ tìm các thông điệp trước khi tìm các thành phần lớp khác vì các thông điệp biểu diễn giao tiếp giữa các đối tượng với thế giới bên ngoài. Xét các thông điệp trong mô hình phân cấp Collection: contains(:Object): boolean Tìm các đối tượng trong bộ sưu tập và trả về true nếu bộ sưu tập chứa tham số, ngược lại trả về false. elementAt(:int): Object trả về đối tượng ở vị trí được xác định bởi tham số truyền vào. PTIT numberOfElements(): int trả về số nguyên là số đối tượng trong bộ sưu tập. Đặt các thông điệp này vào lớp nào? contains() có thể dùng đối với mọi bộ sưu tập, vì vậy đặt nó trong Collection. elementAt(: int) lấy đối tượng ở vị trí xác định nên phải đặt trong List, để tránh sự lặp lại nếu để trong ArrayList và LinkedList. numberOfElement() có thể dùng với mọi bộ sưu tập nên để nó trong Collection. Ta có cây phân cấp trình bày trong Hình 1.5. Cài đặt các phương thức trong phân cấp lớp Vì thuật toán tìm kiếm sẽ xử lý khác nhau đối với bộ sưu tập theo thứ tự và không theo thứ tự, nên contains() không thể cài đặt trong Collection. Ở Bag và List ta sẽ cài đặt hàm contains() khác nhau. 14
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG //Cài đặt hàm contains trong lớp List bolean contains(Object obj) { for (int i= 0; i< numberOfElements(); ++i) { if (elementAt(i) == 0) { return true; } } return false; } Hình 1.5: PTITĐưa các thông điệp vào các lớp Phương thức elementAt được cài đặt khác nhau trong hai lớp ArrayList và LinkedList. Vì vậy, ta phải có hai phương thức elementAt riêng, một cho lớp ArrayList – truy cập các phần tử một cách trực tiếp, một cho lớp LinkedList – duyệt toàn bộ danh sách. Cài đặt phương thức numberOfElements() phụ thuộc vào việc ta lưu số phần tử trong một trường hay tính số phần tử khi cần. Lưu số phần tử trong một trường: trường này sẽ tăng khi thêm phần tử và giảm khi xóa phần tử. Cách này cho phép ghi số phần tử một cách nhanh chóng tùy thuộc vào bộ nhớ nhưng chậm trong việc thêm và xóa đối tượng. Tính toán số phần tử khi cần: đối với LinkedList thì chậm vì phải duyệt toàn bộ số phần tử. Đối với ArrayList và Bag, các đối tượng bên trong có thể lưu trữ số phần tử, do đó sẽ nhanh hơn. Cách này sẽ không tốn bộ nhớ và không bị chậm trong việc thêm và xóa đối tượng. 15
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Ta có thiết kế phan cấp lớp như sau: Hình 1.6: Đưa các thông điệp vào các lớp Các phương thức in nghiêng là các phương thức ảo, còn lại là các phương thức thực. Phương thức ảo chỉ có tên mà không có các dòng mã cài đặt, còn phương thức thực thì ngược lại. Các lớp ảo Lớp ảo là lớp có ít nhất một phương thức ảo – nó có thể nằm trong lớp đó hoặc được kế thừa từ lớp cha. Khi thiết kế phân cấp lớp, ta nên hình dung trong đầu rằng lớp cha cao nhất là ảo. Định nghĩa lại các phương thứcPTIT Hướng đối tượng cho phép ta định nghĩa lại các phần tử dựa trên kế thừa. Ở dạng đơn giản nhất, định nghĩa lại cho phép lớp con thay đổi việc cài đặt phương thức được kế thừa. Tên phương thức vẫn như cũ nhưng các dòng code trong thân sẽ được thay thế hoặc tạo chuyển thông điệp từ private sang public hoặc đổi tên hoặc kiểu của một thuộc tính Sau đây, ta sẽ tập trung bàn về định nghĩa lại nội dung của phương thức, vì đó là lý do quan trọng nhất cho việc định nghĩa lại. Có ba lý do chính giải thích tại sao ta phải định nghĩa lại: Phương thức được kế thừa là ảo và ta muốn biến nó thành hiện thực bằng cách thêm vào một số dòng mã. Ví dụ, contains là ảo trong Collection nhưng cần là thực trong Bag và List. Phương thức cần phải thực hiện thêm một số công việc khi nằm ở lớp con. 16
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Ta có thể cung cấp một cài đặt tốt hơn cho lớp con. Ví dụ, nếu thêm một chỉ số vào lớp LinkedList, ta có thể định nghĩa lại contains để làm việc nhanh hơn thuật toán tuần tự được dùng với List. Khi ta thêm công việc, phải chắc chắn rằng định nghĩa lớp cha vẫn làm mọi thứ bình thường – để tăng việc chia sẻ mã nguồn và đơn giản hóa việc bảo trì (ví dụ, nếu sửa đổi định nghĩa của lớp cha, lớp con sẽ tự động có hành vi mới). Mỗi ngôn ngữ hướng đối tượng cho phép phương thức được định nghĩa lại có thể gọi phương thức trong lớp cha. //Ví dụ trong Java: void initialize() { //invoke the inherited initialize method super.initialize(); } Đa kế thừa Mỗi lớp con có nhiều lớp cha. Java có một dạng đa kế thừa đối với interface và lớp abstract (không cài đặt phương thức). 1.4 SỬ DỤNG LẠI Sử dụng lại (reuse) là khái niệm đã được bàn cãi rất nhiều trong công nghiệp phần mềm. Nhiều nghiên cứu và thực tế phát triển phần mềm đã chỉ ra rằng sử dụng lại dẫn đến phát triển nhanh hơn, hiệu quả hơn và đáng tin cậy hơn vì mã đã được kiểm thử nhiều lần. Hơn nữa, việc bảo trì cũng sẽ dễ dàng hơn. Chúng ta có thể liệt kê ra đây một số cách để sử dụng lại mã nguồn: PTIT Sử dụng lại các chức năng trong một hệ thống: Dạng đơn giản nhất là dùng lại mã nguồn (được sử dụng trong phát triển các hệ thống theo cách truyền thống) liên quan đến việc viết các hàm tiện ích được gọi từ nhiều nơi. Ví dụ, một số môdun trong hệ thống cần sử dụng chức năng tìm kiếm thông qua một danh sách tên khách hàng, do đó có thể viết một hàm tìm kiếm chung để có thể gọi từ các tình huống khác nhau. Sử dụng lại các phương thức trong một đối tượng: Các phương thức được đóng gói trong một đối tượng có thể được gọi từ các phương thức khác. Ví dụ, trong Java phương thức không public có thể sử dụng trong lớp nào thuộc cùng gói với nó. Bạn nên nghĩ đến việc sử dụng lại các phương thức trong một đối tượng bất cứ khi nào cần. Sử dụng lại các lớp trong một hệ thống: Nhiều lớp đã định nghĩa có thể được dùng trong các phần khác nhau của hệ thống. Ví dụ, nếu bạn xây dựng lớp khách 17
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG hàng Customer trong hệ thống marketing, bạn cũng muốn các đối tượng Customer tương tự xuất hiện trong nhiều phần khác nhau của mã nguồn hệ thống. Kiểu dùng lại này là cơ sở của cách tiếp cận hướng đối tượng. Sử dụng lại các chức năng trong một số hệ thống: Các chức năng chung có thể được sử dụng lại (trong phát triển hệ thống kiểu truyền thống cũng như hướng đối tượng) trong các hệ thống khác mà bạn và các đồng nghiệp tạo ra. Với một chức năng để đồng nghiệp có thể được dùng lại, ta phải giải thích cho họ hiểu nó. Giải thích có thể đặt vào nơi chứa tài nguyên dùng lại như một cơ sở dữ liệu các chức năng mà các lập trình viên có thể xem xét khi viết mã nguồn mới. Dùng lại các lớp trong một số hệ thống: Chúng ta cũng có thể sử dụng lại toàn bộ lớp (thuộc tính và phương thức) hơn chỉ là một phương thức. Ví dụ, ta có thể viết một lớp nhân viên Employee với một số thuộc tính cùng với các phương thức để sử dụng cho một số dự án của cùng một công ty. Dùng lại các lớp trong tất cả các hệ thống: Thành phần phần mềm cũng tương tự như các thành phần phần cứng. Nó có thể tạo ra và sử dụng lại toàn bộ cho nhiều dự án phần mềm. Các thành phần trong phần mềm được thiết kế để có thể dùng lại trong nhiều ngữ cảnh. Nó được đóng gói chặt chẽ (bên yêu cầu không biết công việc bên trong là gì) cùng với tiêu chuẩn của interface và được cung cấp sẵn từ bên thứ ba, thường là phải trả chi phí. Ví dụ, trong Java J2EE, các kiểu JavaBeans có thể sử dụng lại cho nhiều hệ phần mềm khác nhau. Các thư viện hàm: Các hàm liên quan, có chất lượng tốt có thể được nhóm lại thành một thư viện để choPTIT luôn sẵn sàng để sử dụng lại. Ví dụ trong ngôn ngữ C, thư viện stdio, bắt nguồn từ các hệ điều hành UNIX, đã cung cấp khả năng I/O cho các lập trình viên C. Các thư viện hàm được dùng cả trong việc phát triển phần mềm truyền thống cũng như phát triển phần mềm hướng đối tượng. Các thư viện được thiết kế tốt đôi khi được chuẩn hóa bởi các tổ chức như ISO hay ANSI. Các thư viện hàm có thể xuất phát từ bên trong công ty, sử dụng miễn phí hoặc bán để kiếm lời. Các thư viện lớp: Là sự phát triển của các thư viện chức năng, thường là các lớp hoàn chỉnh chứ không đơn thuần là các hàm. Viết một thư viện lớp đòi hỏi có nhiều kinh nghiệm. Ví dụ thư viện J2EE, cung cấp mã nguồn cho tất cả các kiểu dùng lại được liệt kê ở trên. Mẫu thiết kế (design pattern): Mẫu thiết kế là một sự mô tả cách tạo ra các phần của hệ thống hướng đối tượng một cách hợp lý và hiệu quả. Các mẫu cũng được áp dụng trong các lĩnh vực khác như kiến trúc hệ thống. Mỗi mẫu là một miêu tả 18
CHƯƠNG 1. CƠ SỞ CỦA PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG ngắn, chi tiết, cho biết khi nào dùng nó và mã nguồn minh họa. Thiết kế các mẫu đòi hỏi phải có nhiều kinh nghiệm, nhưng không bằng việc tạo ra thư viện lớp. Khuôn dạng (Framework): Là một cấu trúc đã có sẵn để bạn gắn mã nguồn của mình vào. Trong hướng đối tượng, một framework bao gồm một số lớp đã được viết trước, cùng với tài liệu miêu tả hướng dẫn lập trình viên các quy tắc phải tuân theo. Ví dụ, EJB framework – bao gồm thư viện J2EE và tài liệu đặc tả, dài hàng trăm trang – chỉ ra cách để lập trình viên viết được các thành phần có khả năng dùng lại, và cách để các bên thứ ba cài đặt máy chủ ứng dụng Java. Phần lớn các framework được thiết kế bởi các chuyên gia cao cấp (guru). 1.5 KẾT LUẬN Chương này đã trình bày một số vấn đề cơ bản nhất trong phát triển phần mềm hướng đối tượng. Nội dung tập trung vào xem xét những kiểu phần mềm; những đặc trưng cơ bản của các hệ hướng đối tượng như đối tượng, lớp đến những vấn đề phức tạp như quan hệ giữa các lớp. Những khái niệm này đã được trình bày ngắn gọn với những ví dụ minh họa để bạn đọc dễ hình dung. Thêm vào đó, vấn đề sử dụng lại cũng đã được đề cập đến để bạn đọc hiểu được yếu tố quan trọng của công nghiêp phần mềm ngày nay là sử dụng lại. Tuy nhiên, phân tích và thiết kế theo hướng đối tượng bao gồm nhiều vấn đề cần sự nghiên cứu lâu dài cũng như trải nghiệm thực tế qua nhiều dự án phần mềm mới có thể trở thành chuyên gia trong lĩnh vực này. Các chương tiếp theo sẽ giúp bạn đọc hiểu rõ hơn những vấn đề này. BÀI TẬP PTIT 1. Tìm hiểu và khảo sát các hệ thương mại điện tử, hệ quản lý thư viện, hệ quản lý học tập theo tín chỉ sau đó đề xuất các chức năng của hệ thống này. Liệt kê các tác nhân sử dụng hệ thống. 2. Hãy chọn ra các lớp từ các hệ thống trong câu 1 và chỉ ra các quan hệ giữa chúng. 3. Hãy thêm các thuộc tính và các phương thức vào các lớp chọn được. Giải thích lý do chọn lựa các mức độ truy nhập các thuộc tính trên và lý do gán phương thức vào các lớp. 4. Sử dụng khái niệm interface và abstract trong Java để cài đặt các lớp với phương thức chèn thêm sinh viên, chèn thêm môn học, chèn thêm đăng ký học. 5. Tương tự như các Câu 1 cho hệ quản lý khác. 6. Sinh viên tham khảo thêm các tài liệu để viết một số ví dụ một mẫu thiết kế. 19
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG CHƯƠNG 2 MÔ HÌNH HÓA HỆ PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Chương này trước hết giới thiệu ngôn ngữ mô hình hoá thống nhất và sau đó trình bày các phương pháp luận phát triển phần mềm hướng đối tượng cùng một tiến trình phát triển phần mềm đơn giản dành cho tài liệu này. Nội dung cụ thể bao gồm: Giới thiệu UML và các biểu đồ trong UML Các phương pháp luận phát triển phần mềm hướng đối tượng Giới thiệu công cụ phát triển phần mềm 2.1 GIỚI THIỆU VỀ UML 2.1.1 Lịch sử phát triển của UML Các ngôn ngữ lập trình hướng đối tượng ra đời khá sớm, ví dụ như Simula-67 (năm 1967), Smalltalk (đầu những năm 1980), C++, CLOS (giữa những năm 1980) Tuy nhiên, mãi cho đến năm 1995, những nhóm phát triển phần mềm mới có những phương pháp luận và ngôn ngữ mô hình với ký hiệu khác nhau, như Booch của Grady Booch, OMT của James Rambaugh, OOSE của Ivar Jacobson, hay OOA & OOD của Coad và Yordon Việc áp dụng rộng rãi phương pháp hướng đối tượng đã đặt ra nhu cầu phải xây dựng một ngôn ngữ mô hình hóa thống nhất như một chuẩn chung cho những người phát triển phần mềm hướng đối tượng trên khắp thế giới. Nỗ lực thống nhất đầu tiên bắt đầu khi Rumbaugh gia nhập nhóm nghiênPTIT cứu của Booch tại tập đoàn Rational năm 1994 và sau đó Jacobson cũng gia nhập nhóm này vào năm 1995. James Rumbaugh, Grady Booch và Ivar Jacobson đã cùng cố gắng xây dựng một Ngôn Ngữ Mô Hình Hoá Thống Nhất có tên là UML (Unifield Modeling Language) (Hình 2.1). Phiên bản UML đầu tiên được đưa ra năm 1997 và sau đó được chuẩn hoá để trở thành phiên bản 1.0. UML đã không ngừng phát triển (chi tiết tham khảo và phiên bản 2.0 đã được sử dụng rộng rãi trong công nghiệp phần mềm hiện nay với nhiều công cụ hỗ trợ. 2.1.2 UML – Ngôn ngữ mô hình hoá hướng đối tượng UML là ngôn ngữ mô hình hoá được xây dựng để đặc tả, phát triển và viết tài liệu cho các hệ phần mềm hướng đối tượng. UML bao gồm một tập các khái niệm, các ký hiệu, các biểu đồ và hướng dẫn sử dụng. 20
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Hình 2.1: Sự ra đời của UML Mục đích của ngôn ngữ UML là: (i) Mô hình hoá các hệ thống bằng cách sử dụng các khái niệm hướng đối tượng; (ii) Thiết lập sự liên hệ từ nhận thức của con người đến các sự kiện cần mô hình hoá; (iii) Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp với nhiều ràng buộc khác nhau; (iv) Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy. UMLPTIT hỗ trợ phân rã hệ hướng đối tượng dựa trên cấu trúc tĩnh và hành vi động của hệ thống. - Các cấu trúc tĩnh (static structure) xác định các kiểu đối tượng quan trọng của hệ thống và mối quan hệ giữa các đối tượng đó nhằm đến cài đặt sau này. - Các hành vi động (dynamic behavior) xác định các hành động của các đối tượng theo thời gian và tương tác giữa các đối tượng. 2.1.3 Các khái niệm cơ bản trong UML Khái niệm mô hình Mô hình (model) là một biểu diễn của sự vật, đối tượng hay một tập các sự vật trong một lĩnh vực ứng dụng nào đó theo một quan điểm nhất định. Mục đích của mô hình là nhằm nắm bắt các khía cạnh quan trọng của sự vật mà mình quan tâm và biểu diễn theo một tập 21
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG ký hiệu hoặc quy tắc nào đó. Các mô hình thường được xây dựng sao cho có thể vẽ được thành các biểu đồ dựa trên tập ký hiệu và quy tắc đã cho. Ví dụ, khi xây dựng Hệ quản lý bán hàng thì ta chỉ cần quan tâm đến các thuộc tính như họ tên, địa chỉ, phone, email của đối tượng khách hàng. Trong khi xây dựng hệ Quản lý Học tập theo tín chỉ ngoài các thông tin liên quan đến đối tượng sinh viên như họ tên, địa chỉ, email, phone ta còn phải quan tâm đến các thuộc tính như điểm, lớp học, môn học, khoa mà sinh viên đăng ký. Các phần tử mô hình và các quan hệ Một số ký hiệu để mô hình hóa hướng đối tượng thường gặp trong UML được biểu diễn trong Hình 2.2. Đi kèm với các phần tử mô hình này là các quan hệ. Các quan hệ này có thể xuất hiện trong bất cứ mô hình nào của UML dưới các dạng khác nhau như quan hệ giữa các ca sử dụng, quan hệ trong biểu đồ lớp PTIT Hình 2.2: Một số phần tử mô hình thường gặp trong UML Phụ thuộc Kế thừa Kế t hợp Hợp thành 22
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Hình 2.3: Một số dạng quan hệ trong UML 2.2 CÁC BIỂU ĐỒ TRONG UML UML chia các biểu đồ thành hai nhóm: Biểu đồ cấu trúc và Biểu đồ hành vi. Chúng được biểu diễn thành cây phân cấp như trong Hình 2.4 ( PTIT Hình 2.4: Cây phân cấp các biểu đồ UML Biểu đồ cấu trúc (Structure Diagram): Nhóm các biểu đồ này biểu diễn các cấu trúc tĩnh của hệ phần mềm cần được mô hình hoá. Các biểu đồ trong mô hình tĩnh tập trung biểu diễn khía cạnh tĩnh liên quan đến cấu trúc cơ bản cũng như các phần tử chính của hệ thống. UML đề xuất bảy dạng biểu đồ trong mô hình tĩnh bao gồm: - Biểu đồ lớp (class diagram) - Biểu đồ đối tượng (object diagram) - Biểu đồ thành phần (component diagram) 23
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG - Biểu đồ gói (package diagram) - Biểu đồ triển khai (deployment diagram) - Biểu đồ cấu trúc phức hợp (composite structure diagram) - Biểu đồ gói mở rộng (profile package) Biểu đồ hành vi (Behavior Diagram): Nhóm biểu đồ này nhằm nắm bắt các hoạt động và hành vi của hệ thống, cũng như tương tác giữa các phần tử bên trong và bên ngoài hệ thống. UML đề xuất bảy dạng biểu đồ trong mô hình hành vi bao gồm: - Biểu đồ ca sử dụng (use case diagram) - Biểu đồ hoạt động (activity diagram) - Biểu đồ tuần tự (sequence diagram) - Biểu đồ giao tiếp (communication diagram) - Biểu đồ trạng thái (state machine diagram) - Biểu đồ bao quát tương tác (interaction overview diagram) - Biểu đồ thời khắc (timing diagram) Phần tiếp theo chúng ta sẽ lần lượt xem xét chi tiết một số biểu đồ UML thường gặp, mỗi biểu đồ sẽ được trình bày về ý nghĩa, tập kí hiệu UML cho biểu đồ đó và ví dụ minh họa. 2.2.1 Biểu đồ ca sử dụng Ý nghĩa Biểu đồ ca sử dụng (use case diagram) biểu diễn các chức năng của hệ thống. Nó bao gồm một tập hợp các tác nhân (actor)PTIT, các ca sử dụng (use case) và các mối quan hệ (relationship) giữa các ca sử dụng. Có thể nói, biểu đồ ca sử dụng chỉ ra sự tương tác giữa các tác nhân và hệ thống thông qua các ca sử dụng. Tác nhân có thể là con người hay một hệ thống khác cung cấp thông tin hay tác động tới hệ thống. Biểu đồ ca sử dụng có thể được phân rã theo nhiều mức khác nhau. Từ tập yêu cầu xác định được của hệ thống, biểu đồ ca sử dụng sẽ chỉ ra hệ thống cần thực hiện điều gì để thoả mãn các yêu cầu của người dùng hệ thống đó. Đi kèm với biểu đồ ca sử dụng là các kịch bản (scenario) nhằm mô tả chi tiết quá trình thực hiện ca sử dụng đó. Tập ký hiệu UML cho biểu đồ ca sử dụng Chúng ta sẽ lần lượt xem xét các phần tử mô hình này: Hệ thống: Với vai trò là thành phần của biểu đồ ca sử dụng, hệ thống biểu diễn ranh giới giữa bên trong và bên ngoài của một chủ thể trong phần mềm chúng ta đang xây dựng. Chú ý rằng một hệ thống ở trong biểu đồ ca sử dụng không phải 24
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG bao giờ cũng nhất thiết là một hệ thống phần mềm; nó có thể là một chiếc máy, hoặc là một hệ thống thực (như một doanh nghiệp, một trường đại học, ). Tác nhân: là người sử dụng hệ thống, một tác nhân có thể là một người dùng thực hoặc các hệ thống máy tính khác có vai trò nào đó trong hoạt động của hệ thống. Một tác nhân có thể thực hiện nhiều ca sử dụng và ngược lại một ca sử dụng cũng có thể được thực hiện bởi nhiều tác nhân. Các ca sử dụng: Đây là thành phần cơ bản của biểu đồ ca sử dụng. Các ca sử dụng được biểu diễn bởi các hình elip thể hiện một chức năng xác định của hệ thống. Quan hệ giữa các ca sử dụng: giữa các ca sử dụng có thể có các quan hệ như sau: - Bao hàm (Include): Ca sử dụng UC1 có một số bước được cung cấp bởi ca sử dụng UC2 thì ta bảo UC1 bao hàm UC2. - Mở rộng (Extend): Ca sử dụng UC1 mở rộng ca sử dụng UC2 bằng cách cho thêm vào một số chức năng cụ thể. - Đặc biệt hóa (Specialization): Ca sử dụng UC1 kế thừa các chức năng từ ca sử dụng UC2 thì UC1 gọi là đặc biệt hóa của UC2 và UC2 là tổng quát hóa (Generalization) của UC1. Các phần tử mô hình ca sử dụng cùng với ý nghĩa và cách biểu diễn của nó được tổng kết trong Bảng 2.1. Việc xác định quan hệ giữa các ca sử dụng là khá tinh tế, phụ thuộc vào yêu cầu hệ thống và ngữ nghĩa cần thể hiện. Bạn đọc sẽ hiểu rõ hơn các quan hệ giữa các ca sử dụng sẽ được trình bày sau này trong Pha xác định yêu cầu ở Chương 3. Phần tử mô Ý nghĩa PTITCách biểu diễn Ký hiệu trong biểu đồ hình Ca sử dụng Biểu diễn một chức Hình ellip chứa tên của ca Tên ca sử dụng năng xác định của hệ sử dụng thống Tác nhân Là một đối tượng bên Biểu diễn hình người ngoài hệ thống tương tượng trưng tác trực tiếp với các use case Mối quan hệ Tùy từng dạng quan hệ Extend và include có > giữa các ca sử dạng các mũi tên kèm > dụng theo tên. Generalization 25
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG có dạng mũi tên tam giác. Biên của hệ Tách biệt phần bên Được biểu diễn bới một thống trong và bên ngoài hệ hình chữ nhật rỗng. thống Bảng 2.1: Các phần tử mô hình trong biểu đồ ca sử dụng Ví dụ: Một biểu đồ quan hệ ca sử dụng trong hệ thống quản lý mua-bán sách trực tuyến (Hình 2.5). Khách hàng có thể sử dụng hệ thống để lựa chọn sách và đăng ký mua. Để được mua sách, khách hàng phải là thành viên hệ thống và phải đăng nhập trước. Khi đó, các ca sử dụng đăng nhập và mua sách có quan hệ extend. Đăng nhập > Đăng ký Mua sách HìnhPTIT 2.5: Biểu đồ ca sử dụng 2.2.2 Biểu đồ lớp Ý nghĩa Trong phương pháp hướng đối tượng, một nhóm đối tượng có chung một số thuộc tính và phương thức tạo thành một lớp. Mối tương tác giữa các đối tượng trong hệ thống sẽ được biểu diễn thông qua mối quan hệ giữa các lớp. Các lớp (bao gồm cả các thuộc tính và phương thức) cùng với các mối quan hệ sẽ tạo thành biểu đồ lớp (class diagram). Biểu đồ lớp là một biểu đồ dạng mô hình tĩnh nhằm mô tả hướng cách nhìn tĩnh về một hệ thống bằng các khái niệm lớp, các thuộc tính, phương thức của lớp và mối quan hệ giữa chúng với nhau. Tập ký hiệu UML cho biểu đồ lớp Trong phần này, chúng ta sẽ xem xét các vấn đề liên quan đến biểu diễn biểu đồ lớp trong UML. 26
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Kí hiệu lớp: trong UML, mỗi lớp được biểu diễn bởi hình chữ nhật gồm ba phần: tên lớp, các thuộc tính và các phương thức. Thuộc tính: các thuộc tính trong biểu đồ lớp được biểu diễn theo cấu trúc chung như sau: phạmvi tên: kiểu sốĐốitượng = mặcđịnh (Giá trịGiớihạn ) Trong đó: phạmvi cho biết phạm vi truy nhập của thuộc tính. Có bốn kiểu xác định phạm vi thuộc tính là: +: thuộc tính kiểu public #: thuộc tính kiểu protected -: thuộc tính kiểu private. ~: thuộc tính được phép truy nhập tới từ các lớp trong cùng package Các phạm vi của thuộc tính có thể được biểu diễn dưới dạng ký hiệu (+, #, -, ~) như trong UML hoặc biểu diễn dưới dạng các từ khoá (public, protected, private) như trong các ngôn ngữ lập trình. Tên: là xâu ký tự biểu diễn tên thuộc tính. kiểu: là kiểu dữ liệu của thuộc tính. sốĐốitượng: chỉ ra số đối tượng khai báo cho thuộc tính ứng với một mặcđịnh: là giá trị khởi đầu mặc định (nếu có) của thuộc tính. GiátrịGiớihạn: là giới hạPTITn các giá trị cho thuộc tính (thông tin này không bắt buộc). Ví dụ Một khai báo thuộc tính đầy đủ: purchaseDate:Date[1] =”01-01-2000” (Saturday) Phương thức (method): các phương thức trong UML được biểu diễn theo cấu trúc chung như sau: phạmvi tênPhương thức(danhSáchThamsố): kiểuTralại { kiểuPhươngthức} Trong đó: Phạmvi biểu diễn phạm vi cho phương thức. Giống như đối với thuộc tính, có bốn dạng kiểu xác định cơ bản cho phương thức là: +: phương thức kiểu public #: phương thức kiểu protected 27
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG -: phương thức kiểu private ~: phương thức được phép truy nhập tới từ các lớp trong cùng package tên là xâu ký tự xác định tên của phương thức. kiểuTrảlại: chỉ ra kiểu giá trị trả về của phương thức. danhSáchThamsố: biểu diễn danh sách các tham số trong khai báo của phương thức. Mỗi tham số được biểu diễn dưới dạng chung: tên tham số: kiểu giá trị = giá trị mặc định. kiểuPhươngthức: không bắt buộc, cho biết kiểu phương thức. Phương thức có thể có một trong các kiểu đặc biệt sau: abstract: phương thức kiểu trừu tượng query: phương thức kiểu truy vấn. Ví dụ một khai báo phương thức cho một lớp: generatePurchaseList(prodID:int): String Các kiểu lớp trong UML UML định nghĩa ba kiểu lớp dựa trên vai trò của nó trong hệ thống bao gồm: - Lớp thực thể (entity class): là lớp đại diện cho các thực thể chứa thông tin về các đối tượng xác định nào đó. Ví dụ, lớp Khách hàng, Hóa đơn. - Lớp biên (boundary class): là lớp nằm ở ranh giới giữa hệ thống với môi trường bên ngoài nhằm thực hiện vai trò nhận yêu cầu trực tiếp từ các tác nhân và chuyển các yêu cầu đó choPTIT các lớp bên trong hệ thống. - Lớp điều khiển (controller class): thực hiện các chức năng điều khiển hoạt động của hệ thống tương ứng với các chức năng cụ thể nào đó của một nhóm các lớp biên hoặc nhóm các lớp thực thể. STT Kiểu lớp Kí hiệu UML 1 Lớp thực thể 2 Lớp biên (lớp giao diện) 3 Lớp điều khiển Bảng 2.2: Các kiểu lớp trong UML 28
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Các quan hệ trong biểu đồ lớp thực thể Như đã trình bày trong Chương 1, giữa các lớp thực có thể có bốn dạng quan hệ cơ bản. Phần tiếp theo sẽ trình bày chi tiết hơn cách biểu diễn quan hệ này trong UML: - Kế thừa (Inheritance): Kế thừa là mối quan hệ giữa một lớp có các đặc trưng mang tính khái quát cao hơn và một lớp có các tính chất đặc biệt hơn. Trong biểu đồ lớp, quan hệ kế thừa được biểu diễn bằng một mũi tên có tam giác rỗng gắn ở đầu. Xem ví dụ Hình 2.6. Khách hàng Khách hàng Khách hàng là không là hội hội viên viên Hình 2.6: Quan hệ kế thừa - Liên kết (Association): Một liên kết (association) là một sự kết nối giữa các lớp, cũng có nghĩa là sự kết nối giữa các đối tượng của các lớp này. Trong UML, quan hệ này nhằm mô tả mối liênPTIT quan về mặt ngữ nghĩa (semantic) giữa hai nhóm đối tượng được biểu diễn bởi các lớp tương ứng. Quan hệ liên kết được biểu diễn bởi đoạn thẳng hai chiều nối hai đối tượng và có thể kèm theo nghĩa của quan hệ tại hai đầu của đoạn thẳng. Ví dụ Hình 2.7, lớp khách hàng có quan hệ liên kết với lớp sản phẩm. Ngữ nghĩa của quan hệ này thể hiện ở chỗ: khách hàng mua sản phẩm, còn sản phẩm được bán cho khách hàng. Khách Được bán cho Sản hàng phẩm Mua Hình 2.7: Quan hệ liên kết hai chiều Quan hệ liên kết cũng có thể có dạng một chiều. Xem ví dụ Hình 2.8. 29
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Khách Hóa đơn hàng Có Hình 2.8: Quan hệ liên kết một chiều - Kết hợp (Aggregation): là dạng quan hệ mô tả một lớp A là một bộ phận của lớp B và lớp A có thể tồn tại độc lập. Quan hệ kết hợp được biểu diễn bằng một mũi tên gắn hình thoi rỗng ở đầu hướng về lớp bao hàm. Xem ví dụ Hình 2.9. Lớp Địa chỉ là một phần của lớp Khách hàng nhưng đối tượng Địa chỉ vẫn có thể tồn tại độc lập với đối tượng khách hàng. Khách Địa chỉ hàng Thuộc về Hình 2.9: Quan hệ kết hợp - Hợp thành (Composition): Quan hệ hợp thành biểu diễn một quan hệ kiểu tổng thể-bộ phận nhưng mạnh hơn quan hệ kết hợp. Lớp A có quan hệ hợp thành với lớp B nếu lớp A là một phần của lớp B và sự tồn tại của đối tượng lớp B điều khiển sự tồn tại của đối tượng lớp A. Quan hệ này được biểu diễn bởi một mũi tên gắn hình thoi đặc ở đầu. Xem ví dụ Hình 2.10. PTITKhách Họ và tên hàng Có Hình 2.10: Quan hệ hợp thành Bảng 2.3 tổng kết các phần tử trong ngôn ngữ mô hình UML được sử dụng trong mô hình lớp, ý nghĩa và ký hiệu tương ứng trong các biểu đồ. Phần tử mô Ý nghĩa Cách biểu diễn Ký hiệu trong biểu đồ hình 30
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Lớp (class) Biểu diễn tên lớp, Một hình chữ Tên lớp các thuộc tính và nhật gồm 3 phần phương thức của tách biệt. Các thuộc tính lớp đó. Các phương thức Quan hệ kế Lớp này thừa Mũi tên tam giác. thừa hưởng các thuộc tính - phương thức của lớp kia Quan hệ kiểu Biểu diễn quan hệ Một đường kẻ liên kết giữa hai lớp độc liền nét (có tên Tên lập, có liên quan xác định) nối đến nhau. giữa hai lớp. Quan hệ kết Biểu diễn quan hệ Đường kẻ liền hợp kiểu bộ phận – nét có hình thoi ở tổng thể. đầu. Quan hệ hợp Biểu diễn quan hệ Đường kẻ liền thành kiểu bộ phận – nét có hình thoi tổng thể mạnh. đặc ở đầu. Bảng 2.4: Tóm tắt cácPTIT phần tử mô hình UML trong biểu đồ lớp Ví dụ: Hình 2.11 biểu diễn một phần của biểu đồ lớp trong Hệ thống quản lý thư viện trong đó các lớp Thủ như (người quản lý thư viên) và Bạn đọc kế thừa từ lớp tổng quát là lớp Người. 31
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Hình 2.11: Biểu đồ lớp 2.2.3 Biểu đồ trạng thái Ý nghĩa - Biểu đồ trạng thái được sử dụng để biểu diễn các trạng thái và sự chuyển tiếp giữa các trạng thái của các đối tượng trong một lớp xác định. Thông thường, mỗi lớp sẽ có một biểu đồ trạng thái (trừ lớp trừu tượng là lớp không có đối tượng) được biểu diễn dưới dạng máy trạng thái hữu hạn với các trạng thái và sự chuyển tiếp giữa các trạng thái đó. Tập ký hiệu UML cho biểu đồ trạngPTIT thái Các thành phần trong một biểu đồ trạng thái bao gồm: - Trạng thái (state): Bên trong các trạng thái có thể miêu tả các biến trạng thái hoặc các hành động (action) tương ứng với trạng thái đó. - Trạng thái con (substate): là một trạng thái chứa bên trong một trạng thái khác. Trạng thái có nhiều trạng thái con gọi là trạng thái tổ hợp. Ví dụ có trạng thái con thể hiện trong Hình 2.12. 32
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Thực hiện tính toán Chưa tính toán Tinh() Thực hiện kiểm tra Kiểm tra lại Đã tính toán xong Return() Tính tổng Hình 2.12: Biểu đồ trạng thái có trạng thái con - Trạng thái khởi đầu (initial state): trạng thái đầu tiên khi kích hoạt đối tượng. - Trạng thái kết thúc (final state): kết thúc vòng đời đối tượng. - Các chuyển tiếp (transition): biểu diễn các chuyển đổi giữa các trạng thái. - Sự kiện (event): sự kiện tác động gây ra sự chuyển đổi trạng thái. Mỗi sự kiện được đi kèm với các điều kiện (guard) và các hành động (action). Trong một biểu đồ trạng thái của UML có thể có một số loại sự kiện sau đây: - Sự kiện gọi (call event): Yêu cầu thực hiện một hành động (một phương thức) - Sự kiện tín hiệu (signal event):PTIT Gửi thông điệp (chứa các giá trị thuộc tính tham số liên quan) giữa các trạng thái. - Sự kiện thời gian (time event): Biểu diễn quá trình chuyển tiếp theo thời gian, thường kèm theo từ mô tả thời gian cụ thể. Các phần tử mô hình UML và ký hiệu tương ứng cho biểu đồ trạng thái được tổng kết như trong Bảng 2.5. Phần tử Ý nghĩa Biểu diễn Ký hiệu trong biểu đồ mô hình 33
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Trạng thái Biểu diễn một trạng Hình chữ nhật tròn thái của đối tượng ở góc, gồm 3 phần: trong vòng đời của tên, các biến, và các đối tượng đó. hoạt động. Trạng thái Khởi đầu vòng đời Hình tròn đặc khởi đầu của đối tượng. Trạng thái Kết thúc vòng đời Hai hình tròn lồng kết thúc của đối tượng. nhau Chuyển tiếp Chuyển từ trạng thái Mũi tên liền nét với (transition) này sang trạng thái tên gọi là biểu diễn Tên chuyển tiếp khác của chuyển tiếp đó. Bảng 2.5: Các phần tử mô hình UML trong biểu đồ trạng thái Ví dụ Biểu đồ trang thái Để minh họa cho biểu đồ trạng thái, ta xét hệ thống mua hàng đơn giản. Một khách hàng gửi yêu cầu cần tìm mua một số hàng đến hệ thống. Đối tượng hàng hóa được tạo ra và chuyển sang trạng thái xử lý yêu cầu. Tùy thuộc vào yêu cầu, đối tượng này sẽ chuyển sang trạng thái xem hàng hóa. Với mỗi hàng hóa được lựa chọn, đối tượng sẽ chuyển sang trạng thái thêm vào giỏ hàngPTIT cho đến khi kết thúc quá trình lựa chọn. Xu ly yeu cau Them Xem hang Them vao hoa gio hang Hình 2.14: Biểu đồ trạng thái 2.2.4 Biểu đồ tuần tự Ý nghĩa 34
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Có hai loại biểu đồ tương tác: Biểu đồ tuần tự và biểu đồ cộng tác. Các biểu đồ tuần tự biểu diễn mối liên hệ giữa các đối tượng trong hệ thống và giữa các đối tượng với các tác nhân bên ngoài theo thời gian. Biểu đồ tuần tự nhấn mạnh thứ tự thực hiện của các tương tác. Tập ký hiệu UML cho biểu đồ tuần tự Các thành phần cơ bản của một biểu đồ tuần tự là: - Các đối tượng (object): được biểu diễn bởi các hình chữ nhật, bên trong là tên của đối tượng. Cách viết chung của đối tượng là: tên đối tượng: tên lớp. Nếu chỉ viết: tên lớp thì có nghĩa là bất cứ đối tượng nào của lớp tương ứng đó. Trong biểu đồ tuần tự, không phải tất cả các đối tượng đều cùng lúc xuất hiện trên một biểu đồ mà chúng chỉ xuất hiện (về mặt thời gian) khi thực sự tham gia vào tương tác. - Các thông điệp: được biểu diễn bằng các mũi tên hướng từ đối tượng gửi sang đối tượng nhận. Tên các thông điệp có thể biểu diễn dưới dạng phi hình thức (như các thông tin trong kịch bản) hoặc dưới dạng hình thức (với dạng giống như các phương thức). Rõ ràng rằng biểu diễn dưới dạng hình thức sẽ rất hữu ích cho việc xác định các phương thức cho lớp. Biểu đồ tuần tự cho phép có các thông điệp từ một đối tượng tới chính bản thân nó. - Trong biểu đồ tuần tự có thể có nhiều loại thông điệp khác nhau tuỳ theo mục đích sử dụng và tác động của thông điệp đến đối tượng. Các dạng thông điệp được tổng kết trong Bảng 2.6 dưới đây: STT Loại message PTITMô tả Biểu diễn 1 Gọi (call) Mô tả một lời gọi từ đối Method() tượng này đến đối tượng kia. 2 Trả về (return) Trả về giá trị ứng với lời gọi Giá trị trả về 3 Gửi (send) Gửi một tín hiệu tới một đối tượng Send() 4 Tạo (create) Tạo một đối tượng > 35
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 5 Huỷ (destroy) Huỷ một đối tượng > Bảng 2.6: Các dạng thông điệp trong biểu đồ tuần tự - Đường vòng đời: là một đường kẻ nối dài phía dưới đối tượng, mô tả quá trình tồn tại của đối tượng trong quá trình tương tác của biểu đồ. - Chú thích: biểu đồ tuần tự cũng có thể có chú thích để người đọc dễ dàng hiểu được nội dung của biểu đồ đó. Ví dụ: Dưới đây là một ví dụ biểu đồ tuần tự cho chức năng Đăng nhập trong một hệ thống quản lý bán hàng. Các đối tượng tham gia trong tương tác là tác nhân khách hàng, giao diện đăng nhập, điều khiển quản lý báo mật và thực thể người dùng. : Khach hang : Form Dang nhap : Quan ly bao mat : Nguoi dung Dang nhap Kiem tra nguoi dung Kiem tra thong tin chi tiet nguoi dung PTITThong tin chi tiet nguoi dung Xac thuc Ket qua xac thuc Ket qua xac thuc Hình 2.15: Biểu đồ tuần tự 2.2.5 Biểu đồ giao tiếp Ý nghĩa 36
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Biểu đồ giao tiếp là biểu đồ tương tác biểu diễn mối quan hệ giữa các đối tượng, giữa các đối tượng và tác nhân. Biểu đồ giao tiếp cũng có các thông điệp với nội dung tương tự như trong biểu đồ tuần tự. Tuy nhiên, các đối tượng được đặt một cách tự do trong không gian của biểu đồ và không có đường vòng đời cho các đối tượng; các thông điệp được đánh số thể hiện thứ tự thời gian. Tập ký hiệu UML cho biểu đồ giao tiếp Các thành phần cơ bản của một biểu đồ giao tiếp là: - Các đối tượng: được biểu diễn bởi các hình chữ nhật, bên trong là tên của đối tượng. Cách viết chung của đối tượng là: tên đối tượng: tên lớp. Trong biểu đồ giao tiếp, các đối tượng tham gia tương tác luôn xuất hiện tại một vị trí xác định. - Các liên kết: giữa hai đối tượng có tương tác sẽ có một liên kết nối 2 đối tượng đó. Liên kết này không có chiều. - Các thông điệp: được biểu diễn bằng các mũi tên hướng từ đối tượng gửi sang đối tượng nhận bên cạnh liên kết giữa 2 đối tượng đó. Trong biểu đồ giao tiếp, các thông điệp được đánh số theo thứ tự xuất hiện trong kịch bản mô tả ca sử dụng tương ứng. Ví dụ biểu đồ giao tiếp Dưới đây là một biểu đồ giao tiếp mô tả chức năng đăng nhập trong hệ thống đơn giản. Chi tiết chức năng này hoàn toàn PTITtương tự như đã mô tả trong biểu đồ tuần tự hình 2.15. 1: Dang nhap 7: Ket qua xac thuc : Khach hang : Form Dang nhap 2: Kiem tra nguoi dung 6: Ket qua xac thuc 5: Xac thuc 3: Kiem tra thong tin chi tiet 4: Thong tin chi tiet : Quan ly bao mat : Nguoi dung 37
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Hình 2.16: Biểu đồ giao tiếp 2.2.6 Biểu đồ hoạt động Ý nghĩa Biểu đồ hoạt động biểu diễn các hoạt động và sự đồng bộ, chuyển tiếp các hoạt động của hệ thống trong một lớp hoặc kết hợp giữa các lớp với nhau trong một chức năng cụ thể. Biểu đồ hoạt động có thể được sử dụng cho nhiều mục đích khác nhau, ví dụ như: Để xác định các hành động phải thực hiện trong phạm vi một phương thức. Để xác định công việc cụ thể của một đối tượng. Để chỉ ra một nhóm hành động liên quan của các đối tượng được thực hiện như thế nào và chúng sẽ ảnh hưởng thế nào đến những đối tượng xung quanh. Tập ký hiệu UML Các phần tử mô hình UML cho biểu đồ hoạt động bao gồm: Hoạt động (Activity): là một quy trình được định nghĩa rõ ràng, có thể được thực hiện bởi một phương thức hoặc một nhóm đối tượng. Hoạt động được thể hiện bằng hình chữ nhật tròn cạnh. Thanh đồng bộ hóa (Synchronisation bar): cho phép ta mở ra hoặc là đóng lại các nhánh chạy song song trong tiến trình. PTIT Hình 2.17: Thanh đồng bộ hoá trong biểu đồ động Điều kiện (Guard Condition): các biểu thức logic có giá trị hoặc đúng hoặc sai. Điều kiện được thể hiện trong ngoặc vuông, ví dụ: [Customer existing]. Các luồng (swimlane): Mỗi biểu đồ hoạt động có thể biểu diễn sự phối hợp hoạt động trong nhiều lớp khác nhau. Khi đó mỗi lớp được phân tách bởi một luồng (swimlane) riêng biệt và các luồng này được biểu diễn đơn giản là các ô khác nhau trong biểu đồ. 38
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Các ký hiệu UML cho biểu đồ hoạt động được tổng kết trong Bảng sau: Phần tử mô hình Ý nghĩa Ký hiệu trong biểu đồ Hoạt động Mô tả một hoạt động gồm tên hoạt động và đặc tả của nó. NewActivity Trạng thái khởi đầu Trạng thái kết thúc Thanh đồng bộ ngang Mô tả thanh đồng bộ nằm ngang Thanh đồng bộ hoá Mô tả thanh đồng bộ theo chiều dọc thẳng đứng Chuyển tiếp PTIT Quyết định Mô tả một lựa chọn điều kiện. Các luồng Phân tách các lớp đối tượng khác Phân cách nhau bởi một nhau tồn tại trong biểu đồ hoạt đường kẻ dọc từ trên động xuống dưới biểu đồ Bảng 2.7: Các phần tử của biểu đồ hoạt động Ví dụ biểu đồ hoạt động 39
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Dưới đây là ví dụ biểu đồ hoạt động mô tả chức năng kiểm tra yêu cầu mua hàng trong Hệ thống bán hàng. Nhan dat hang Xac thuc that bai Kiem tra tung san pham [Con trong kho] Huy dat hang Xac nhan dat mua san pham Tat ca cac san pham yeu cau deu con Yeu cau dat trong kho va xac thuc hang lai thanh cong Xu ly don hang HìnhPTIT 2.18: Biểu đồ hoạt động 2.2.7 Biểu đồ thành phần Ý nghĩa Biểu đồ thành phần được sử dụng để biểu diễn các thành phần phần mềm cấu thành nên hệ thống. Một hệ phần mềm có thể được xây dựng từ đầu bằng cách sử dụng mô hình lớp như đã trình bày trong các phần trước của tài liệu, hoặc cũng có thể được tạo nên từ các thành phần sẵn có. Mỗi thành phần có thể coi như một phần mềm nhỏ hơn, cung cấp một khối dạng hộp đen trong quá trình xây dựng phần mềm lớn. Nói cách khác, các thành phần là các gói được xây dựng cho quá trình triển khai hệ thống. Các thành phần có thể là các gói ở mức cao như JavaBean, các gói thư viện liên kết động dll, hoặc các phần mềm nhỏ được tạo ra từ các thành phần nhỏ hơn như các lớp và các thư viện chức năng. Tập ký hiệu UML 40
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Tập ký hiệu UML cho biểu đồ thành phần được tổng kết trong bảng sau: Phần tử mô hình Ý nghĩa Ký hiệu trong biểu đồ Thành phần Mô tả một thành phần của biểu Component đồ, mỗi thành phần có thể chứa nhiều lớp hoặc nhiều chương trình con. Giao tiếp Mô tả giao tiếp gắn với mỗi thành phần. Mối quan hệ phụ thuộc Mối quan hệ giữa các thành giữa các thành phần phần Bảng 2.8: Các ký hiệu của biểu đồ thành phần 2.2.8 Biểu đồ triển khai Ý nghĩa Biểu đồ triển khai biểu diễn kiến trúc cài đặt và triển khai hệ thống dưới dạng các đỉnh và các mối quan hệ giữa các đỉnh đó. Thông thường, các đỉnh được kết nối với nhau thông qua các liên kết truyền thông như các giao thức kết nối mạng TCP/IP, IIOP Tập ký hiệu UML cho biểu đồ triểnPTIT khai Tập ký hiệu UML cho biểu đồ triển khai hệ thống được biểu diễn trong Bảng sau: Phần tử mô hình Ý nghĩa Ký hiệu trong biểu đồ Các nodes (hay Biểu diễn các thành phần không có bộ Device các thiết bị) vi xử lý trong biểu đồ triển khai hệ thống Các bộ xử lý Biểu diễn các thành phần có bộ vi xử Processor lý trong biểu đồ triển khai hệ thống Các liên kết Nối các thành phần của biểu đồ triển truyền thông khai hệ thống. Thường mô tả một giao 41
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG thức truyền thông cụ thể. Bảng 2.8: Các ký hiệu của biểu đồ triển khai hệ thống 2.3 PHƯƠNG PHÁP LUẬN PHÁT TRIỂN PHẦN MỀM 2.3.1 Khái niệm phương pháp luận Sản xuất một phần mềm dù kích cỡ lớn hay nhỏ thế nào, dù phát triển đầy đủ trọn vẹn cả một sản phẩm hay chỉ là một phần như một môdun thì sản phẩm đó cũng thường được tạo ra bởi nhiều người và như vậy cần phải có một phương pháp luận (methodology) để sản xuất phần mềm đó. Phương pháp luận được hiểu là cách thức làm việc một cách có hệ thống. Bản chất của nó là một tiến trình (process) có thể lặp đi lặp lại từ trạng thái đầu tiên trong việc phát triển phần mềm (một ý tưởng được hình thành hoặc một cơ hội kinh doanh mới) và xuyên suốt đến phần bảo trì một hệ phần mềm đã được cài đặt. Cũng giống như tiến trình, một phương pháp luận cần phải chỉ rõ cái mà chúng ta mong được sản xuất ra khi ta thực hiện theo tiến trình đó (những cái mà sản phẩm cuối cùng nên có). Một phương pháp luận cũng có thể bao gồm cả những lời khuyên hay kỹ thuật để quản lý tài nguyên, kế hoạch, lập lịch và các nhiệm vụ quản lý khác. Một phương pháp luận tốt thường đề cập đến những nội dung sau đây: Lập kế hoạch (Planning) : Quyết định những gì cần thực hiện. Lập lịch (Scheduling): Xác định thực hiện các công việc khi nào Tài nguyên (Resoucing): Ước lượng và thu thập các nguồn nhân lực, phần mềm, phần cứng và các tài nguyênPTIT cần thiết khác. Luồng công việc (Workflow): các tiến trình con trong tiến trình lớn như thiết kế kiến trúc hệ thống, mô hình dữ liệu Hoạt động (Activites): Các công việc riêng lẻ bên trong luồng công việc như kiểm thử một thành phần, vẽ một biểu đồ lớp Vai trò (Roles): Vai trò của các nhân như người phát triển, kiểm thử trong phương pháp luận Sản phẩm (Artifacts): Các sản phẩm có liên quan đến quá trình phát triển phần mềm như một phần của phần mềm, tài liệu thiết kế, kế hoạch huấn luyện và viết tài liệu hướng dẫn sử dụng. Huấn luyện (Training): Xác định cách huấn luyện cho khách hàng, người dùng cuối, người bán hàng sử dụng hệ thống. 42
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Một phương pháp luận tốt có thể có lợi cho cả các dự án phần mềm cỡ lớn và các dự án phần mềm nhỏ. Đối với các dự án nhỏ, những hiểu biết căn bản về một phương pháp luận tốt được cho là cần thiết vì những lý do sau đây: Một phương pháp luận có thể giúp đưa ra những quy định trong viết mã nguồn. Qua những bước cơ bản của một phương pháp luận cũng có thể giúp chúng ta hiểu vấn đề hơn, từ đó cải tiến được chất lượng của việc giải quyết vấn đề. Viết mã nguồn chỉ là một trong nhiều hoạt động của việc phát triển phần mềm nên khi tiến hành một số các hoạt động khác sẽ giúp chúng ta hiểu được các lỗi về khái niệm và thực tế trước khi chúng ta tiến hành viết mã nguồn. Phương pháp luận giúp chúng ta dễ thay đổi mã nguồn và dễ sử dụng lại hơn cho lớp bài toán khác; ngoài ra nhờ việc có tài liệu cũng giúp dễ dàng soát lỗi hơn. Lợi ích của phương pháp luận cho những dự án phần mềm lớn có thể tóm lược sau đây: Tài liệu: Tất cả các phương pháp luận đều chú trọng đến khâu viết tài liệu trong mọi giai đoạn phát triển để khi một hệ thống đã hoàn thành và do đó không trở thành một khối không thể hiểu được. Giảm được độ trể: Vì các luồng công việc, các hoạt động, các vai trò và những mối liên quan bên trong đã được hiểu một cách thấu đáo hơn nên có ít cơ hội cho con người nhàn rỗi. Cải thiện may rủi: Giảm được sự may rủi trong việc phân phối sản phẩm đúng thời hạn và chi vượt kinh phí.PTIT Cải tiến giao tiếp: Một phương pháp luận tốt sẽ gíup việc giao tiếp giữa những người sử dụng, những người bán sản phẩm, những người quản lý và những nhà phát triển tốt hơn. Tính lặp lại: Vì những hoạt động được xác định rõ ràng nên những dự án giống nhau có thể được phân theo những giai đoạn tương tự nhau và chi phí như nhau. Nếu chúng ta sản xuất ra những hệ thống tương tự nhau lặp đi lặp lại cho những khách hàng khác nhau (ví dụ như những gian hàng thương mại điện tử), chúng ta có thể tổ chức được phương pháp luận tốt hơn để chỉ tập trung vào những mặt quan trọng mà sản phẩm mới nảy sinh. Tính toán chi phí chính xác hơn: Dựa trên kinh nghiệm đã có với các dự án trước nên có thể đưa ra ước lượng chi phí chính xác hơn. 43
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 2.3.2 Các pha phát triển truyền thống Không cứ là theo phương pháp luận nào, một số pha được cho là giống nhau cho mọi phương pháp luận. Vì vậy, cũng cần nhắc lại ở đây để bạn đọc có cách nhìn đầy đủ hơn và có ích khi trình bày các pha phát triển của các chương sau này. Việc kết hợp các pha này theo một kiểu nào đó sẽ dẫn đến các phương pháp luận khác nhau như thác nước, xoắn ốc, lặp và tăng dần. Xác định yêu cầu Đây là pha đầu tiên của quá trình phát triển phần mềm. Nó bao gồm 2 giai đoạn: Mô hình hóa nghiệp vụ: liên quan đến việc hiểu nghiệp vụ hiện thời với ngữ cảnh cụ thể của nó mà dự án cần phát triển. Nó có thể là mô hình quản lý đang hoạt động hiện thời, phần mềm đang sử dụng hiện thời Mô hình hóa yêu cầu hệ thống: xác định được yêu cầu thực sự của khách hàng cho hệ thống định xây dựng, xem khách hàng cần gì để biết được ta sẽ phải làm gì và không cần làm gi. Điều này cần xác định càng chi tiết càng rõ ràng càng tốt. Phân tích yêu cầu Phân tích có nghĩa là ta phải xét xem ta đang phải đối mặt với vấn đề gì. Trước khi tiến hành thiết kế một giải pháp, ta cần phải hiểu rõ ràng những thực thể liên quan, những tính chất và những mối quan hệ bên trong của chúng. Từ đó mới biết được ta đã thực sự hiểu về sản phẩm mà khách hàng yêu cầu hay chưa vì điều này liên quan đến khách hàng và người dùng cuối. PTIT Thiết kế Trong pha thiết kế, chúng ta vạch ra cách giải quyết vấn đề. Nghĩa là, chúng ta đưa ra những quyết định dựa trên kinh nghiệm, ước lượng hay trực giác về phần mềm gì chúng ta sẽ viết và cách triển khai nó như thế nào. Thông thường có hai giai đoạn thiết kế: Thiết kế hệ thống (system design) hay thiết kế kiến trúc (architecture design) và thiết kế các hệ thống con (subsystem design) hay thiết kế chi tiết (detailed design). Thiết kế hệ thống là phân rã một hệ thống thành các hệ thống con. Nó bao gồm thiết kế hệ thống con liên quan nhau về mặt logic (tiến trình) và hệ thống con liên quan nhau về vật lý (máy tính, mạng) dựa trên các công nghệ, thiết bị máy móc đã lựa chọn. Thiết kế hệ thống con là quyết định chuyển hệ thống con liên quan nhau về mặt logic thành mã thế nào. 44
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Cài đặt Pha này sẽ viết các đoạn mã nhỏ cho các hệ thống con, viết phần thân các phương thức trong lớp thiết kế. Tích hợp thành hệ thống lớn theo yêu cầu. Kiểm thử Sau khi phần mềm đã hoàn thành, nó phải được kiểm thử xem nó đã đáp ứng các yêu cầu của khách hàng chưa. Cách tốt nhất thường được tiến hành làm là thực hiện các kiểm thử nhỏ trong suốt quá trình phát triển phần mềm để đảm bảo chất lượng. Triển khai Pha này liên quan đến việc đưa phần cứng và phần mềm vào nơi người dùng cuối cùng với tài liệu hướng dẫn sử dụng và huấn luyện. Bảo trì Sau khi hệ thống được triển khai, có thể sẽ có nhiều lỗi hệ thống hay cũng có thể khách hàng yêu cầu sửa đổi, nâng cấp vì vậy cần có quá trình bảo trì hệ thống. 2.3.3 Phương pháp luận hướng đối tượng Theo những nhà sáng lập UML, Grady Booch, Ivar Jacobson và James Rumbaugh, mọi cách tiếp cận phát triển hệ hướng đối tượng phải tuân theo ba nguyên tắc (i) dựa vào ca sử dụng, (ii) dựa vào hướng kiến trúc; (iii) dựa vào lặp và gia tăng. Dựa vào ca sử dụng Dựa vào ca sử dụng (use case driven)PTIT có nghĩa là các ca sử dụng là công cụ mô hình ban đầu để xác định hành vi của hệ thống. Ca sử dụng mô tả cách người dùng tương tác với hệ thống để tiến hành một hoạt động nào đó như tạo hóa đơn, đặt hàng hay tìm kiếm thông tin. Các ca sử dụng được dùng để xác định và chuyển tải các yêu cầu hệ thống cho những người lập trình sau này. Các ca sử dụng được xem khá là đơn giản vì chúng nó tập trung vào chỉ một hoạt động tại mỗi thời điểm. Ngược lại, các biểu đồ mô hình tiến trình được sử dụng bởi các phương pháp luận hướng cấu trúc truyền thống là hơi phức tạp vì nó đòi hỏi các nhà phân tích phải xây dựng các mô hình cho cả hệ thống. Ngoài ra, theo cách tiếp cận truyền thống, mỗi hoạt động nghiệp vụ được phân rã thành một tập các tiến trình con và mỗi tiến trình con khi đó lại được phân rã tiếp tục cho đến khi không thể phân rã được nữa. Điều này đòi hỏi một khối lượng lớn tài liệu để biểu diễn biểu đồ. Hướng kiến trúc 45
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Hướng kiến trúc (architecture centric) có nghĩa là kiến trúc phần mềm cơ sở của hệ thống sẽ định hướng cách đặc tả, cách xây dựng và cách viết tài liệu hệ thống. Mọi cách tiếp cận phân tích và thiết kế các hệ hướng đối tượng phải hỗ trợ ít nhất ba quan điểm theo kiến trúc của hệ thống: Quan điểm chức năng, quan điểm tĩnh, quan điểm động. Quan điểm chức năng (functional view) mô tả hành vi bên ngoài của hệ thống theo cách nhìn của người sử dụng. Các ca sử dụng và các biểu đồ ca sử dụng là cách tiếp cận ban đầu được sử dụng để minh họa quan điểm chức năng. Trong một số trường hợp, các biểu đồ hoạt động cũng được sử dụng để hỗ trợ các ca sử dụng. Quan điểm tĩnh (static view) mô tả cấu trúc của hệ thống theo các lớp, thuộc tính, phương thức và quan hệ giữa các lớp. Các biểu đồ cấu trúc phác họa cách nhìn tĩnh của hệ hướng đối tượng đang tiến hóa và được biểu diễn bởi các biểu đồ cấu trúc trong UML. Quan điểm động (dynamic view) mô tả hành vi bên trong của hệ thống theo các thông điệp được truyền giữa các đối tượng và sự thay đổi trạng thái bên trong một đối tượng. Quan điểm động được biểu diễn bởi các biểu đồ hành vi trong UML. Lặp và gia tăng Lặp và gia tăng (Iterative and incremental): các cách tiếp cận phân tích và thiết kế hệ hướng đối tượng hiện nay nhấn mạnh phát triển lặp và tăng dần bằng cách tiến hành kiểm thử và mịn hóa liên tục suốt trong vòng đời của dự án. Mỗi quá trình lặp trong phát triển sẽ làm cho hệ thống tiến gần hơn với yêu cầu thực sự của người sử dụng. Cho đến nay có khá nhiều phương pháp luận hướng đối tượng đã được đề nghị. Mỗi phương pháp đều bàn đến triết lý PTITđằng sau mỗi pha, luồng công việc và những hoạt động, sản phẩm của mỗi pha và cách sử dụng các biểu đồ UML tương ứng cho mỗi pha. Các phương pháp luận được đưa ra đều là những phát triển dựa trên mô hình tiến trình hợp nhất (Unified Software Development Process) hay viết tắt là UP (Unified Process) do Booch, Jacobson, Rumbaugh đề xuất. Chúng ta có thể kể ra đây một số phương pháp luận phổ biến: Agile Unified Process (AUP) Basic Unified Process (BUP) Enterprise Unified Process (EUP) Essential Unified Process (EssUP) Open Unified Process (OUP) 46
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Rational Unified Process (RUP) Rational Unified Process – System Engineering (RUP-SE) 2.3.4 UP Để giúp bạn đọc hiểu rõ hơn ý nghĩa của phương pháp luận làm cơ sở cho các phương pháp luận hướng đối tượng, phần này sẽ dành trình bày chi tiết hơn phương pháp luận UP. Là một phương pháp phát triển phần mềm theo hướng ca sử dụng, kiến trúc và lặp và tăng dần, UP ( đã khắc phục các nhược điểm của các mô hình truyền thống như thác nước và xoắn ốc. UP có thể thay đổi tuỳ theo các công ty, tổ chức và các dự án riêng biệt. Nguyên lý lặp và tăng dần trong mô hình UP cho phép chia nhỏ các pha trong vòng đời dự án thành các giai đoạn nhỏ, mỗi giai đoạn có thể được lặp đi lặp lại và gia tăng theo thời gian và có thể theo các phiên bản (version) của sản phẩm trong dự án. Nghĩa là chúng ta có thể thêm và cải tiến các chức năng so với phiên bản trước của sản phẩm trong cùng một giai đoạn và việc cho phép thêm và cải tiến chức năng này gọi là sự phát triển tăng dần của các giai đoạn theo thời gian. UP là quá trình phát triển hệ thống theo hai chiều được mô tả bởi tập các pha (phase) và các công đoạn (workflow). Các pha bao gồm: khởi đầu, triển khai, xây dựng và chuyển giao. Các công đoạn bao gồm 7 công đoạn kỹ thuật và 3 công đoạn hỗ trợ. Các công đoạn kỹ thuật bao gồm: mô hình nghiệp vụ, xác định yêu cầu, phân tích yêu cầu, thiết kế, cài đặt, kiểm thử, triển khaiPTIT. Các công đoạn hỗ trợ bao gồm: quản lý dự án, quản lý cấu hình và thay đổi và môi trường. Trong phần còn lại trong mục này, chúng ta sẽ mô tả các pha và các công đoạn của UP (Xem Hình 2.7). Các pha (Phase) Các pha của UP mô tả cách tiến hóa theo thời gian của hệ thống thông tin. Phụ thuộc vào pha phát triển nào của hệ thống đang tiến hành mà mức độ hoạt động sẽ thay đổi tương ứng theo luồng công việc. Ví dụ, pha khởi động liên quan chủ yếu đến mô hình nghiệp vụ và luồng xác định yêu cầu mà bỏ qua luồng công việc kiểm thử và triển khai. Mỗi pha có một số bước lặp và mỗi bước lặp sử dụng những luồng công việc khác nhau để tạo nên các phiên bản mới của hệ thống thông tin. Khi hệ thống tiến hóa qua các pha, nó được cải tiến và trở nên đầy đủ hơn. Các pha được mô tả chi tiết hơn dưới đây: Pha khởi động (inception) 47
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Đây là pha đầu tiên và ngắn nhất trong vòng đời dự án, thực tế pha này nên được triển khai càng ngắn gọn càng tốt vì nếu thực hiện pha này kéo dài thì có nghĩa là đang có sự dư thừa trong việc đặc tả hệ thống. Mốc bàn giao yêu cầu và mục đích của dự án đánh dấu sự kết thúc của pha khởi động. Trong pha này, chúng ta cần trả lời các câu hỏi sau: Chúng ta có khả năng về mặt kỹ thuật để xây dựng hệ thống hay không? (Tính khả thi về mặt kỹ thuật) Nếu xây dựng được, nó có đem lại giá trị về mặt kinh tế hay không? (Tính khả thi về mặt kinh tế) Nếu xây dựng được, tổ chức hay doanh nghiệp có sử dụng nó hay không? (Tính khả thi về mặt tổ chức) Pha Khởi đầu Triển khai Xây dựng Chuyển giao Công đoạn Mô hình nghiệp vụ Yêu cầu Phân tích Thiết kế Cài đăt PTIT Kiểm thử Triển khai Quản lý dự án Quản lý cấu hình và thay đổi Môi trường 48
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Hình 2.19: Các pha và các công đoạn phát triển UP Để trả lời các câu hỏi này, nhóm phát triển cần tiến hành các công việc cơ bản liên quan đến mô hình nghiệp vụ, xác định yêu cầu và phân tích yêu cầu. Trong trường hợp do khó khăn về mặt kỹ thuật có thể gặp phải trong quá trình phát triển hệ thống, ta có thể xây dựng bản mẫu thử. Điều này có nghĩa là các luồng thiết kế, cài đặt và kiểm thử cũng có thể liên quan. Các luồng hỗ trợ quản lý dự án, môi trường rất liên quan đến pha này. Những sản phẩm chính của pha này bao gồm: (i) Tài liệu trong đó cần đề cập phạm vi của dự án, những yêu cầu và ràng buộc, kế hoạch dự án ban đầu và mô tả tính chấp nhận được của những rủi ro liên quan đến dự án; (ii) Sự thừa nhận về môi trường cần thiết để phát triển hệ thống. Pha triển khai (Elaboration) Rõ ràng những hoạt động trong pha triển khai của UP có liên quan nhiều nhất đến phân tích và thiết kế hướng đối tượng. Các luồng phân tích và thiết kế cơ bản tập trung suốt trong pha này. Pha triển khai tiếp tục bằng phát triển tài liệu bao gồm kết thúc các ca nghiệp vụ, hiệu chỉnh lại đánh giá rủi ro, hoàn thiện kế hoạch dự án với đầy đủ chi tiết để các bên liên quan dự án có thể thỏa thuận xây dựng hệ thống thực sự cuối cùng. Pha này giải quyết vấn đề thu thập yêu cầu, bằng cách xây dựng các mô hình của bài toán theo các biểu đồ hành vi và cấu trúc của UML và đồng thời chi tiết hóa cách mô hình bài toán tương thích với kiến trúc hệ thống thế nào. Vì phát triển lặp qua các luồng nên cần thiết phải xem xét đến vấn đề quản lý cấu hình và thay đổi. Các công cụ phát triển phát triển phần mềm (ví dụ như VP sẽ đượcPTIT đề cập trong cuối Chương này) sử dụng trong pha khởi động sẽ đóng vai trò chủ chốt để tiến hành các hoạt động trong pha này. Sản phẩm chính của pha này bao gồm: (i) Các biểu đồ cấu trúc và hành vi trong UML; (ii) Phiên bản nền thực thi được của hệ thống. Phiên bản nền này sẽ là cơ sở cho cả quá trình phát triển lặp sau này nên nếu có được cơ sở vững chắc tại thời điểm này thì những người phát triển có thể tiến hành hoàn thiện hệ thống trong các pha xây dựng và chuyển giao tiếp theo. Pha xây dựng (Construction) Pha xây dựng tập trung vào lập trình nên công việc chủ yếu liên quan đến luồng cài đặt. Tuy nhiên, các luồng xác định yêu cầu, phân tích và thiết kế cũng liên quan đến pha này. Chính pha này sẽ bổ sung những yêu cầu còn thiếu sót và cuối cùng hoàn thành những mô hình phân tích và thiết kế. Luồng quản lý cấu hình và thay đổi sẽ trở thành cực kỳ quan trọng trong pha xây dựng này. Sản phẩm chính của pha này là phiên bản cài đặt beta của hệ thống với kiểm thử chấp nhận. 49
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG Pha chuyển giao (Transition) Giống như pha xây dựng, pha chuyển giao bàn đến các khía cạnh liên quan đến pha cài đặt của cách tiếp cận phát triển phần mềm cố điển. Khi chuyển đến pha này, các luồng mô hình nghiệp vụ, xác định yêu cầu và phân tích ắt đã được hoàn thiện trong các vòng lặp trước. Pha này tập trung chủ yếu vào các luồng kiểm thử và triển khai. Phụ thuộc vào kết quả kiểm thử, có thể cần phải thiết kế lại hay cài đặt lại nhưng phải là tối thiểu tại thời điểm này. Sản phẩm chính của pha này là hệ thống thông tin thực thi thực sự. Các sản phẩm khác bao gồm tài liệu hướng dẫn sử dụng, bản kế hoạch để hỗ trợ người dùng và nâng cấp hệ thống trong tương lai. Các công đoạn (workflows) Các công đoạn mô tả các công việc hay các hoạt động mà người xây dựng cần thực hiện theo thời gian để phát triển hệ thống. Các công đoạn trong UP được nhóm thành hai phạm trù: Các công đoạn kỹ thuật (engineering workflows) và các công đoạn hỗ trợ (supporting workflows). Các công đoạn kỹ thuật Các công đoạn kỹ thuật bao gồm mô hình nghiệp vụ, xác định yêu cầu, phân tích yêu cầu, thiết kế, cài đặt, kiểm thử và triển khai. Các công đoạn kỹ thuật liên quan đến các hoạt động để sinh ra sản phẩm kỹ thuật là hệ thống thông tin. Tiếp theo, chúng ta sẽ mô tả chi tiết các công đoạn kỹ thuật này. Mô hình nghiệp vụ (business modeling) Công đoạn mô hình nghiệp vụ nhằm phát hiện vấn đề và xác định các dự án tiềm năng bên trong tổ chức của người dùng. Luồng công việc này giúp hiểu được phạm vi của dự án và hướng đến cải tiến hiệu quảPTIT và hiệu suất của tổ chức người dùng. Mục đích chủ yếu của mô hình nghiệp vụ là nhằm đảm bảo cả người phát triển và tổ chức người dùng hiểu được rằng hệ thống thông tin cần phải phát triển thích hợp ở đâu và như thế nào với tiến trình nghiệp vụ của tổ chức. Luồng công việc này chủ yếu được thực thi trong pha khởi đầu nhằm đảm bảo rằng hệ thống thông tin định phát triển có ý nghĩa về mặt nghiệp vụ. Những hoạt động xảy ra trong luồng này rất liên quan với pha lập kế hoạch của tiến trình phát triển cổ điển. Tuy nhiên, các kỹ thuật thu thập yêu cầu, mô hình hóa tiến trình nghiệp vụ và ca sử dụng cũng được sử dụng để hiểu các tình huống nghiệp vụ. Xác định yêu cầu (requirement determination) Trong UP, công đoạn xác định yêu cầu nhằm làm rõ cả yêu cầu chức năng (functional requirements) và yêu cầu phi chức năng (nonfunctional requirements). Các yêu cầu được thu thập từ các bên tham gia dự án như người dùng cuối, người quản lý trong tổ chức người dùng cuối và ngay cả khách hàng như trong các phần mềm trên mạng hiện nay. Có nhiều cách để nắm bắt yêu cầu như phỏng vấn, quan sát, hội thảo, phân tích tài liệu, 50
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG phiếu điều tra Công đoạn xác định yêu cầu được sử dụng trong các pha khởi đầu và triển khai. Các yêu cầu được xác định rất hữu ích trong việc phát triển tài liệu và các ca sử dụng suốt trong quá trình phát triển hệ thống. Phân tích yêu cầu (analysis) Công đoạn phân tích yêu cầu ưu tiên bàn đến việc tạo ra mô hình phân tích của lĩnh vực mà dự án quan tâm. Trong UP, nhà phân tích bắt đầu với thiết kế kiến trúc liên quan đến miền bài toán và sử dụng các biểu đồ hành vi và cấu trúc của UML để mô tả các lớp và tương tác của chúng. Mục đích thứ nhất của luồng công việc phân tích là đảm bảo rằng cả nhóm phát triển và tổ chức sử dụng hiểu được vấn đề cơ bản và giới hạn của miền mà dự án quan tâm. Mục đích thứ hai của phân tích là xác định những lớp thư viện mà có thể sử dụng lại để tránh phát triển dư thừa khi tạo ra những biểu đồ cấu trúc và hành vi. Công đoạn phân tích chiếm ưu thế trong pha triển khai nhưng cũng như pha xác định yêu cầu nó có thể sử dụng trong mọi pha của quá trình phát triển hệ thống. Thiết kế (design) Công đoạn thiết kế nhằm biến đổi mô hình phân tích thành dạng có thể sử dụng để cài đặt hệ thống và thường được gọi là mô hình thiết kế (design model). Trong khi công đoạn phân tích quan tâm đến việc hiểu lĩnh vực của bài toán, công đoạn thiết kế tập trung vào phát triển một giải pháp có thể thực thi được trong một môi trường xác định. Cơ bản là luồng thiết kế nâng cao mô tả hệ thống thông tin bằng cách thêm các lớp liên quan đến môi trường hệ thống thông tin trong mô hình phân tích. Luồng thiết kế bàn đến các hoạt động như thiết kế giao diện người sử dụng, thiết kế cơ sở dữ liệu, thiết kế kiến trúc vật lý, thiết kế chi tiết các lớp thực thể vàPTIT tối ưu hóa hệ thống. Luồng thiết kế trong UP chủ yếu liên quan đến các pha triển khai và xây dựng. Cài đặt (implementation) Mục đích chủ yếu của công đoạn cài đặt là tạo ra một giải pháp thực thi được dựa trên mô hình thiết kế. Điều này bao gồm ba giai đoạn chính: (i) Viết những lớp mới và kết nối với những lớp sử dụng lại từ các thư viện lớp để trở thành một giải pháp; (ii) Thực hiện kiểm thử các lớp mới và các tương tác của chúng với các lớp sử dụng lại; (iii) Khi có nhiều nhóm cùng tiến hành cài đặt, cần phải tiếp hành tích hợp các môdun riêng lẻ đã được kiểm thử để tạo ra một phiên bản thực thi được của hệ thống. Công đoạn cài đặt chủ yếu liên quan đến các pha triển khai và xây dựng. Kiểm thử (test) Mục đích chủ yếu của công đoạn kiểm thử là nhằm tăng cường chất lượng của hệ thống. Ngoài việc kiểm thử liên quan đến cài đặt, nó cũng bao gồm kiểm thử việc tích hợp các 51
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG moodun, kiểm thử chấp nhận với người sử dụng và kiểm thử phần mềm triển khai thực sự. Thực tế, công đoạn kiểm thử được trải khắp các pha phát triển phần mềm. Kiểm thử các mô hình phân tích và thiết kế được thực hiện trong các pha triển khai và xây dựng. Kiểm thử cài đặt được tiến hành chủ yếu trong pha xây dựng và chuyển giao. Triển khai (deployment) Công đoạn triển khai liên quan nhiều nhất đến pha chuyển giao trong UP. Luồng công việc triển khai bao gồm các hoạt động như đóng gói phần mềm, phân phối sản phẩm, cài đặt, kiểm thử. Khi triển khai thực sự hệ thống mới tại tổ chức người dùng, những người phát triển có thể phải chuyển đổi dữ liệu hiện thời, giao diện phần mềm mới với phần mềm hiện thời và tổ chức lớp huấn luyện sử dụng hệ thống mới. Các công đoạn hỗ trợ Các công đoạn hỗ trợ tập trung vào các khiá cạnh quản lý bao gồm quản lý dự án, quản lý cấu hình và thay đổi, và môi trường. Quản lý dự án (project management) Trong khi các công đoạn kỹ thuật liên quan đến cả bốn pha trong UP, công đoạn quản lý dự án thực sự chỉ là luồng công việc liên quan đến việc dịch chuyển giữa các pha. Tiến trình phát triển hỗ trợ phát triển lặp và gia tăng nên hệ thống sẽ tăng dần và tiến hóa theo thời gian. Tại cuối mỗi giai đoạn lặp, một phiên bản mới của hệ thống sẽ sẵn sàng cho phân phối. Do sự phức tạp của mô hình phát triển hai chiều (công đoạn và pha) của UP mà công đoạn quản lý dự án đóngPTIT vai trò rất quan trọng. Các hoạt động của công đoạn này bao gồm: xác định và quản lý rủi ro, ước lượng thời gian hoàn thành và chi phí cho mỗi bước lặp và toàn bộ dự án, theo dõi quá trình phát triển cho sản phẩm cuối cùng. Quản lý cấu hình và thay đổi (configuration and change management) Mục đích chủ yếu của công đoạn này là theo dõi sản phẩm hiện trạng của hệ thống đang phát triển. Một số sản phẩm hiện trạng bao gồm các biểu đồ, mã nguồn, mã thực thi. Suốt trong quá trình phát triển các sản phẩm này sẽ được sửa đổi. Một thỏa thuận về các thông tin quản lý dự án cần được xác định như tác giả, thời gian và vị trí của mỗi sửa đổi. Công đoạn này đa phần liên quan đến các pha xây dựng và chuyển giao. Môi trường (environment) Suốt trong quá trình phát triển dự án, nhóm phát triển cần sử dụng các công cụ và tiến trình khác nhau. Công đọan môi trường tập trung xem xét những nhu cầu này. Ví dụ, các 52
CHƯƠNG 2. MÔ HÌNH HÓA PHẦN MỀM HƯỚNG ĐỐI TƯỢNG công cụ phân tích và thiết kế, các công cụ quản lý dự án và cấu hình, môi trường lập trình Công đoan này chủ yếu liên quan đến pha khởi đầu trong UP. 2.3.5 Một tiến trình phát triển phần mềm đơn giản Các phương pháp luận dựa trên UP cũng phân chia tiến trình phát triển thành các pha, các công đoạn lặp theo thời gian nhưng mới chỉ là những khuôn mẫu mà chưa phải là những tiến trình cụ thể. Để có thể áp dụng được trong quá trình phát triển phần mềm thực sự, chúng ta còn phải chỉ ra các bước, công việc phải làm trong từng bước, biểu đồ UML nào sẽ sử dụng trong từng công đoạn và các sản phẩm của mỗi công đoạn. Do quen thuộc với cách gọi truyền thống nên các tài liệu hiện thời cũng gọi các công đoạn là các pha phát triển phần mềm. Giáo trình này cũng theo xu hướng như vậy nên từ bây giờ trở đi ta sẽ gọi công đoạn là các pha phát triển phần mềm. Mục đích của giáo trình này là tập trung vào trình bày ba pha chủ yếu: Pha xác định yêu cầu, Pha phân tích yêu cầu và Pha thiết kế. Pha xác định yêu cầu bao gồm hai giai đoạn: Xác định yêu cầu nghiệp vụ (tập trung xem xét các khía cạnh nghiệp vụ của tổ chức hiện thời), Xác định yêu cầu hệ thống (tập trung xem xét các yêu cầu cho hệ thống dự định phát triển). Pha phân tích yêu cầu tập trung mô hình hóa phần mềm với UML cho hệ thống mới. Pha thiết kế bao gồm hai giai đoạn: thiết kế hệ thống (phân rã hệ thống thành các hệ thống con và triển khai về mặt vật lý cho hệ thống) và thiết kế chi tiết (thiết kế các hệ thống con đã được phân rã). Các pha sẽ tương ứng với một số bước cần phải thực hiện và các biểu đồ UML nào sẽ sử dụng được cho trong Bảng 2.1. Các pha Các bước thực hiện UML Xác định Nghiệp vụ 1. XácPTIT định và mô tả các tác nhân Không yêu cầu 2. Xây dựng bảng thuật ngữ Không 3. Xác định và mô tả các ca sử dụng Không 4. Xây dựng kịch bản Không 5. Xây dựng biểu đồ hoạt động (Tùy chọn) Có 6. Xây dựng biểu đồ giao tiếp (Tùy chọn) Có Hệ thống 1. Xác định và mô tả các tác nhân Không 2. Xác định và mô tả các ca sử dụng Không 3. Xây dựng kịch bản Không 4. Xây dựng biểu đồ ca sử dụng Có 5. Xếp ưu tiên các ca sử dụng Không 6. Phác họa giao diện người dung Không Phân tích Phân tích 1. Xác định các lớp Không yêu cầu tĩnh 2. Xác định quan hệ giữa các lớp Có 3. Xây dựng biểu đồ lớp Có 4. Xác định thuộc tính lớp Không 5. Cập nhật bảng thuật ngữ và yêu cầu phi chức năng 53