Giáo trình Phân tích và thiết kế hướng đối tượng - Nghề: Thiết kế trang web - Trình độ: Cao đẳng - Trường Cao đẳng nghề Đà Lạt

Nội dung text: Giáo trình Phân tích và thiết kế hướng đối tượng - Nghề: Thiết kế trang web - Trình độ: Cao đẳng - Trường Cao đẳng nghề Đà Lạt

1. ỦY BAN NHÂN DÂN TỈNH LÂM ĐỒNG TRƢỜNG CAO ĐẲNG NGHỀ ĐÀ LẠT GIÁO TRÌNH MƠN HỌC/ MƠ ĐUN: PHÂN TÍCH VÀ THIẾT KẾ HƢỚNG ĐỐI TƢỢNG NGÀNH/ NGHỀ: THIẾT KẾ TRANG WEB TRÌNH ĐỘ: CAO ĐẲNG Ban hành kèm theo Quyết định số: 1157/QĐ-CĐNĐL ngày 11 tháng 12 năm 2019 của Hiệu trưởng Trường Cao đẳng Nghề Đà Lạt (LƢU HÀNH NỘI BỘ) Lâm Đồng, năm 2019
2. TUYÊN BỐ BẢN QUYỀN Tài liệu này thuộc loại sách giáo trình nên các nguồn thơng tin cĩ thể đƣợc phép dùng nguyên bản hoặc trích dùng cho các mục đích về đào tạo và tham khảo. Mọi mục đích khác mang tính lệch lạc hoặc sử dụng với mục đích kinh doanh thiếu lành mạnh sẽ bị nghiêm cấm. Giáo trình đƣợc lƣu hành nội bộ Trƣờng Cao đẳng Nghề Đà Lạt. Phát triển phần mềm bằng UML trang | 1
3. LỜI GIỚI THIỆU Vài nét về xuất xứ giáo trình: Giáo trình này đƣợc viết theo căn cứ Thơng tƣ số 03/2017/TT-BLĐTBXH ngày 01 tháng 03 năm 2017 của Bộ Lao động – Thƣơng binh và Xã hội về việc Quy định về quy trình xây dựng, thẩm định và ban hành chƣơng trình; tổ chức biên soạn, lựa chọn, thẩm định giáo trình đào tạo trình độ trung cấp, trình độ cao đẳng. Quá trình biên soạn: Giáo trình này đƣợc biên soạn cĩ sự tham gia tích cực của các giáo viên cĩ kinh nghiệm, cùng với những ý kiến đĩng gĩp quý báu của các chuyên gia về lĩnh vực cơng nghệ thơng tin. Mối quan hệ của tài liệu với chương trình, mơ đun/mơn học: Căn cứ vào chƣơng trình đào tạo nghề Thiết kế trang web, giáo trình giúp cung cấp cho ngƣời học những kiến thức cơ bản về phân tích thiết kế hệ thống cũng nhƣ kỹ năng sử dụng phần mềm Rose để thiết kế hƣớng đối tƣợng. Để học đƣợc mơ đun này ngƣời học cần cĩ kiến thức cơ bản về cơ sở dữ liệu và hệ quản trị cơ sở dữ liệu quan hệ. Cấu trúc chung của giáo trình này bao gồm 9 chương: CHƢƠNG 1. MỞ ĐẦU CHƢƠNG 2. KHÁI QUÁT VỀ UML CHƢƠNG 3. MƠ HÌNH HĨA TRƢỜNG HỢP SỬ DỤNG CHƢƠNG 4. MƠ HÌNH HĨA TƢƠNG TÁC ĐỐI TƢỢNG CHƢƠNG 5. BIỂU ĐỒ LỚP VÀ GĨI CHƢƠNG 6. BIỂU ĐỒ CHUYỂN TRẠNG THÁI VÀ BIỂU ĐỒ HOẠT ĐỘNG CHƢƠNG 7. BIỂU ĐỒ KIẾN TRÚC VẬT LÝ VÀ PHÁT SINH MÃ TRÌNH CHƢƠNG 8. VÍ DỤ ÁP DỤNG CHƢƠNG 9. MÃ TRÌNH PHÁT SINH TRONG ROSE Hệ thống tin học ngày càng phức tạp. Xu thế áp dụng phƣơng pháp hƣớng đối tƣợng (phƣơng pháp mới) thay cho phƣơng pháp cấu trúc (phƣơng pháp truyền thống) ngày càng phổ biến khi xây dựng các hệ thống phần mềm lớn và phức tạp. Hơn nữa, từ khi Ngơn ngữ mơ hình hĩa thống nhất (Unified Modeling Language – UML) đƣợc tổ chức OMG (Object Management Group) cơng nhận là chuẩn cơng nghiệp thì nĩ đã trở thành cơng cụ phổ dụng và hữu hiệu cho phƣơng pháp mới này. Mục tiêu của tài liệu này nhằm giới thiệu các khái niềm cơ bản về tiếp cận hƣớng đối tƣợng và mơ hình hĩa hệ thống phần mềm theo phƣơng pháp hƣớng đối tƣợng. Các khái niệm mới đƣợc mơ tả, hƣớng dẫn thực hành thơng qua ngơn ngữ chuẩn UML và phần mềm cơng cụ mơ hình hĩa nổi tiếng Rational Rose của Raitonal Software Corporation. Phƣơng pháp phân tích thiết kế hƣớng đối tƣợng đƣợc sử dụng rộng rãi tại các nƣớc phát triển và bắt đầu đƣợc sử dụng tại một số đơn vị tin học tại Việt Nam. Tuy nhiên tài liệu bằng tiếng Việt về lĩnh vực này cịn rất hiếm hoi, khơng đáp ứng nhu cầu Phát triển phần mềm bằng UML trang | 2
4. hiện tại. Hơn nữa, nhận thức đƣợc tầm quan trọng của phƣơng pháp mới này, một số trƣờng đại học đã hình thành mơn học liên quan đến vấn đề nĩi trên cho sinh viên, cịn một số trƣờng khác đang cĩ kế hoạch đƣa chủ đề này vào chƣơng trình đào tạo chính khĩa. Chủ điểm của tài liệu đƣợc thể hiện dƣới gĩc nhìn của ngƣời phát triển hệ thống phần mềm, khơng thể hiện dƣới gĩc độ quan sát của nhà phƣơng pháp luận. Lựa chọn này xuất phát từ thực tế là từ phƣơng pháp luận hƣớng đối tƣợng dẫn đến việc ứng dụng nĩ vào xây dựng phần mềm cụ thể cịn một khoảng cách xa vời và đầy khĩ khăn, đặc biệt với trình độ tin học hiện này nĩi chung cịn chƣa cao tại Việt Nam. Với quan điểm này, tài liệu đƣợc cấu trúc nhƣ sau: Chƣơng mở đầu trình bày khái quát về mơ hình và mơ hình hĩa; các bƣớc xây dƣng hệ thống phần mềm và tầm quan trọng của phƣơng pháp hƣớng đối tƣợng. Chƣơng tiếp theo giời thiệu ngơn ngữ chuẩn cơng nghiệp UML, một cơng cụ hữu hiệu mơ hình hĩa hệ thống phần mềm. Trong các phần tiếp theo là trình bày kỹ thuật mơ hình hĩa, từ phân tích yêu cầu đến thiết kế hệ thống, kiến trúc hệ thống và cài đặt bằng ngơn ngữ lập trình. Chƣơng cuối cùng là bài học thực nghiệm các kỹ thuật đã trình bày trong các chƣơng trƣớc vào bài tốn cụ thể. Đặc biệt, trong mỗi chƣơng tài liệu đều cĩ phần thực hành trên phần mềm Rational Rose để độc giả cĩ thể áp dụng ngày cơng cụ mới, kỹ thuật mới vào giải quyết vấn đề của riêng họ. Phần phụ lục trình bày một số mã trình trong một vài ngơn ngữ thơng dụng tƣơng ứng với các nhĩm phần tử trong biểu đồ UML Hiện nay phần lớn các bạn sinh viên đại học năm cuối hoặc các kỹ sƣ tin học mới ra trƣờng đều gặp khĩ khăn khi nhận nhiệm vụ xây dựng hệ thống phần mềm mới hay nâng cấp phần mềm cĩ sẵn. Các bạn thƣờng khơng biết bắt đầu từ đâu và làm nhƣ thế nào để cĩ đƣợc phần mềm và phần mềm tốt, nĩi cách khác là cịn thiếu phƣơng pháp. Do vậy, quyển sách này cĩ thể là tài liệu tham khảo tốt cho các bạn sinh viên và các kỹ sƣ tin học. Lời cảm ơn Giáo trình đƣợc biên soạn trên cơ sở các văn bản quy định của Nhà nƣớc và tham khảo nhiều tài liệu liên quan cĩ giá trị. Song chắc hẳn quá trình biên soạn khơng tránh khỏi những thiếu sĩt nhất định. Ban biên soạn mong muốn và thực sự cảm ơn những ý kiến nhận xét, đánh giá của các chuyên gia, các thầy cơ đĩng gĩp cho việc chỉnh sửa để giáo trình ngày một hồn thiện hơn. Lâm Đồng, ngày 10 tháng 12 năm 2019 Tham gia biên soạn 1. Phạm Đình Nam 2. Ngơ Thiên Hồng 3. Nguyễn Quỳnh Nguyên 4. Phan Ngọc Bảo Phát triển phần mềm bằng UML trang | 3
5. Phát triển phần mềm bằng UML trang | 4
6. Mục lục CHƢƠNG 1 MỞ ĐẦU 8 1.1 LỊCH SỬ HƢỚNG ĐỐI TƢỢNG 10 1.2 MỘT SỐ KHÁI NIỆM CƠ BẢN 11 1.3 NGUYÊN TẮC QUẢN LÝ ĐỘ PHỨC TẠP 14 1.4 NGUYÊN TẮC MƠ HÌNH HĨA 15 1.5 KHÁI QUÁT VỀ TIẾN TRÌNH PHÁT TRIỂN PHẦN MỀM 17 1.5.1 - Các phương pháp mơ hình hĩa hệ thống 17 1.5.2 - Các pha phát triển phần mềm 19 CHƢƠNG 2 KHÁI QUÁT VỀ UML 27 2.1 GIỚI THIỆU UML 27 2.2 MƠ HÌNH KHÁI NIỆM CỦA UML 29 2.2.1 - Phần tử mơ hình trong UML 29 2.2.2 - Các quan hệ trong UML 31 2.2.3 - Kiểu dữ liệu 32 2.2.4 - Biểu đồ UML 32 2.3 KIẾN TRÚC HỆ THỐNG 41 2.3.1 - Khung nhìn UC 41 2.3.2 - Khung nhìn thiết kế 42 2.3.3 - Khung nhìn cài đặt 42 2.3.4 - Khung nhìn triển khai 42 2.3.5 - Khung nhìn tiến trình 43 2.3.6 - Cần bao nhiêu khung nhìn 43 2.4 RATIONAL ROSE LÀ GÌ? 43 2.5 KHẢ NĂNG SỬ DỤNG UML 44 2.6 THỰC HÀNH 45 CHƢƠNG 3 MƠ HÌNH HĨA TRƢỜNG HỢP SỬ DỤNG 47 3.1 PHÂN TÍCH TRƢỜNG HỢP SỬ DỤNG (USE CASE – UC) 47 3.1.1 - UC là gì? 47 3.1.2 - Xây dựng UC để làm gì? 47 3.1.3 - Tìm kiếm UC như thế nào ? 48 3.1.4 - Luồng sự kiện trong UC 51 3.2 BIỂU ĐỒ TRƢỜNG HỢP SỬ DỤNG 53 3.3 THỰC HÀNH 57 3.3.1 - Sử dụng Rational Rose 57 3.3.2 - Thí dụ: hệ thống bán hàng 63 CHƢƠNG 4 MƠ HÌNH HĨA TƢƠNG TÁC ĐỐI TƢỢNG 66 4.1 ĐỐI TƢỢNG VÀ TÌM KIẾM ĐỐI TƢỢNG 66 4.2 BIỂU ĐỒ TƢƠNG TÁC 66 4.2.1 - Biểu đồ trình tự 67 4.2.2 - Biểu đồ cộng tác 73 4.3 KỸ THUẬT XÂY DỰNG BIỂU ĐỒ TƢƠNG TÁC 74 Phát triển phần mềm bằng UML trang | 5
7. 4.4 THỰC HÀNH 77 4.4.1 - Sử dụng Rational Rose 77 4.4.2 - Thí dụ: hệ thống bán hàng (tiếp theo) 84 CHƢƠNG 5 BIỂU ĐỒ LỚP VÀ GĨI 93 5.1 LỚP VÀ TIỀM KIẾM LỚP 93 5.2 BIỂU ĐỒ LỚP 95 5.2.1 - Các loại lớp trong biểu đồ 95 5.2.2 - Stereotype của lớp 96 5.3 GĨI 98 5.4 THUỘC TÍNH LỚP 99 5.4.1 - Tìm kiếm thuộc tính 99 5.4.2 - Đặc tả thuộc tính 99 5.5 THAO TÁC CỦA LỚP 102 5.6 QUAN HỆ 103 5.6.1 - Quan hệ kết hợp 103 5.6.2 - Quan hệ phụ thuộc 105 5.6.3 - Phụ thuộc tụ hợp 107 5.6.4 - Quan hệ khái quát hĩa 108 5.6.5 - Gán đặc tính cho quan hệ 110 5.7 CƠ CHẾ DUY TRÌ ĐỐI TƢỢNG 114 5.8 THỰC HÀNH 118 5.8.1 - Sử dụng Rational Rose 118 5.8.2 - Thí dụ: Hệ thống bán hàng (tiếp theo) 128 CHƢƠNG 6 BIỂU ĐỒ CHUYỂN TRẠNG THÁI VÀ BIỂU ĐỒ HOẠT ĐỘNG139 6.1 BIỂU ĐỒ CHUYỂN TRẠNG THÁI 139 6.1.1 - Trạng thái 141 6.1.2 - Quá độ 143 6.1.3 - Trạng thái ẩn 144 6.1.4 - Lớp và biểu đồ trạng thái 146 6.2 BIỂU ĐỒ HOẠT ĐỘNG 146 6.2.1 - Trạng thái hành động và trạng thái hoạt động 146 6.2.2 - Quá độ 146 6.2.3 - Rẽ nhánh 147 6.2.4 - Đường dẫn tương tranh 147 6.2.5 - Đường bơi 149 6.2.6 - Luồng đối tượng 149 6.2.7 - Gửi và nhận tín hiệu 150 6.3 THỰC HÀNH 151 6.3.1 - Sử dụng Rational Rose 151 6.3.2 - Thí dụ: Hệ thống bán hàng (tiếp theo) 153 CHƢƠNG 7 BIỂU ĐỒ KIẾN TRÚC VẬT LÝ VÀ PHÁT SINH MÃ TRÌNH 156 7.1 BIỂU ĐỒ THÀNH PHẦN 156 7.1.1 - Thành phần là gì? 156 7.1.2 - Biểu tượng thành phần trong Rational Rose 157 Phát triển phần mềm bằng UML trang | 6
8. 7.1.3 - Phụ thuộc thành phần 158 7.1.4 - Biểu đồ thành phần 159 7.2 BIỂU ĐỒ TRIỂN KHAI 160 7.2.1 - Phần tử mơ hình của biểu đồ 161 7.2.2 - Tiến trình 161 7.3 THỰC HÀNH 162 7.3.1 - Sử dụng Rational Rose 162 7.3.2 - Phát sinh mã trình bằng Rose 165 7.3.3 - Rational Rose và Visual C++ 170 7.3.4 - Thí dụ: Hệ thống bán hàng (tiếp theo) 172 CHƢƠNG 8 VÍ DỤ ÁP DỤNG 183 8.1 KHẢO SÁT TIẾN TRÌNH TÁC NGHIỆP 183 8.2 PHÂN TÍCH LĨNH VỰC 189 8.3 PHÂN TÍCH HỆ THỐNG 193 8.3.1 - Xây dựng biểu đồ trường hợp sử dụng (Use Case-UC) 193 8.4 BIỂU ĐỒ TƢƠNG TÁC 203 8.4.1 - Tiến trình đặt trước sách để mượn 203 8.4.2 - Tiến trình mượn sách , tạp chí 205 8.5 BIỂU ĐỒ LỚP 207 8.6 BIỂU ĐỒ TRIỂN KHAI 208 8.7 THIẾT KẾ GIAO DIỆN 210 CHƢƠNG 9 MÃ TRÌNH PHÁT SINH TRONG ROSE 213 9.1 PHÁT SINH MÃ TRÌNH C++ 213 9.1.1 - Các lớp 213 9.1.2 - Quan hệ kết hợp 216 9.1.3 - Quan hệ phụ thuộc tập hợp 220 9.1.4 - Quan hệ kế thừa 223 9.2 PHÁT SINH MÃ TRÌNH JAVA 224 9.2.1 - Các lớp 224 9.2.2 - Quan hệ kết hợp 225 9.2.3 - Quan hệ phụ thuộc tập hợp 227 9.2.4 - Quan hệ kế thừa 228 9.3 PHÁT SINH MÃ TRÌNH VISUAL BASIC 229 9.3.1 - Các lớp 229 9.3.2 - Quan hệ kết hợp 231 9.3.3 - Quan hệ kế thừa đơn 232 9.4 PHÁT SINH MÃ TRÌNH SQL 233 9.4.1 - Các lớp 233 9.4.2 - Quan hệ kết hợp 233 9.4.3 - Quan hệ kế thừa 235 Phát triển phần mềm bằng UML trang | 7
9. CHƢƠNG 1 MỞ ĐẦU Phát triển phần mềm ngày càng trở nên phức tạp. Thay đổi giao diện từ các xâu ký tự sang giao diện đồ họa xu thế sự kiện; kiến trúc hệ thống đa tầng khách/chủ; cơ sở dữ liệu (CSDL) phân tán; Internet làm tăng độ phức tạp của hệ thống phần mềm. Thách thức trong hai mƣơi năm tới của xây dựng hệ thống phần mềm khơng phải là tốc độ thực hiện chƣơng trình, kinh phí hay sức mạnh của nĩ mà vấn đề sẽ là độ phức tạp (Sun Microsystem). Kẻ thù của chúng ta là độ phức tạp, ta phải loại bỏ chúng (Jan Bean). Vậy, loại bỏ độ phức tạp bằng cách nào? Các phƣơng pháp tiếp cận hƣớng cấu trúc, tiệm cận hƣớng logic, tiếp cận hƣớng hƣớng đối tƣợng và tiếp cận hƣớng tác tử để cĩ thể giải quyết vấn đề này nhƣng ở mức độ khác nhau. Tổng quát thì việc xây dựng phần mềm phải quan tâm đến tổ chức, các quan hệ và cấu trúc để hình thành đƣợc các hành vi phức tạp của hệ thống. Mọi việc khảo sát hệ thống phải đƣợc thực hiện với mức độ trừu tƣợng khác nhau, từ các chi tiết đến tổ chức tổng thể. Do vậy, xây dựng phần mềm là thực hiện dãy tƣơng tác chia nhỏ và hợp nhất. Chia nhỏ để hiểu rõ vấn đề và hợp nhất để xây dựng hệ thống. Tiến trình chia nhỏ (tách) đã cĩ truyền thống và tuân thủ các tiêu chí chức năng. Các chức năng của hệ thống đƣợc nhận diện, sau đĩ chúng đƣợc tách thành các chức năng con. Tiến trình này đƣợc thực hiện lặp đi lặp lại cho đến khi cĩ đƣợc các thành phần đơn giản đến mức chúng đƣợc biểu diễn trực tiếp bằng các hàm hay thủ tục của ngơn ngữ lập trình (hình 1.1). Cách tiếp cận này đƣợc gọi là tiếp cận hƣớng chức năng (hay cịn gọi là thủ tục, truyền thống). Ngƣời phát triển phần mềm sẽ tập trung vào các nhiệm vụ điều khiển và tách thuật tốn lớn thành các thuật tốn nhỏ. Khối chính để hình thành phần mềm ở đây là các hàm hay thủ tục. Chức năng chính Chức năng con 1 Chức năng con 2 Chức Chức Chức Chức năng năng con năng con năng con con 1.1 1.2 2.1 2.2 Hình 1.1 Tiếp cận hướng chức năng Kiến trúc phần mềm đƣợc cài đặt theo cách tiếp cận vừa mơ tả trên sẽ phản ảnh các chức năng hệ thống. Tiếp cận trên cơ sở chức năng và cơ chế phân cấp chỉ cho lại kết quả mong muốn khi các chức năng đƣợc nhận biết đầy đủ và nĩ khơng đƣợc thay đổi theo thời gian. Thực tế lại khơng đúng nhƣ vậy vì trong rất nhiều trƣờng hợp, phát triển phần mềm khơng bao giờ kết thúc hồn tồn, luơn cĩ cái gì đĩ phải sửa đổi, nâng cấp. Sửa đổi hay mở rộng hệ thống quá nhiều làm cho chƣơng trình khác xa quan niệm ban đầu. Do đĩ cần phải cĩ phƣơng pháp mới cho khả năng làm chủ đƣợc độ phức tạp, giúp quản lý đƣợc chất lƣợng, độ tin cậy phần mềm ngày cả khi cấu trúc bị tách ra hay tiến hĩa. Phát triển phần mềm bằng UML trang | 8
10. Mở C ử a Pho ng thang ma y Lên t ầng 2 Bậ t đ e n Đ èn Cơng t ắ c Hình 1.2 Tiếp cận hướng đối tượng Quan điểm hƣớng đối tƣợng hình thành trên cơ sở tiếp cận hƣớng hệ thống, nĩ coi hệ thống nhƣ thực thể đƣợc tổ chức từ các thành phần mà chỉ đƣợc xác định khi nĩ thừa nhận và cĩ quan hệ với các thành phần khác. Phƣơng pháp tách vần đề đang giải quyết để hiểu chúng ở đây khơng chỉ dựa trên cơ sở cái hệ thống làm mà cịn dựa trên việc tích hợp hệ thống là cái gì với hệ thống làm gì. Thí dụ trên hình 1.2 mơ tả các đối tƣợng và các quan hệ giữa các đối tƣợng của hệ thống thang máy. Theo cách tiếp cận này thì các chức năng hệ thống đƣợc biểu diễn thơng qua cộng tác của các đối tƣợng; việc thay đổi, tiến hĩa chức năng sẽ khơng ảnh hƣởng đến cấu trúc tĩnh của phần mềm. Sức mạnh của tiếp cận hƣớng đối tƣợng là việc tách (chia) và nhập (thống nhất) đƣợc thực hiện nhờ tập phong phú các cơ chế tích hợp của chúng; khả năng thống nhất cao những cái nĩ đã đƣợc tách ra để xây dựng các thực thể phức tạp từ các thực thể đơn giản. Tiếp cận hƣớng đối tƣợng đã tỏ rõ lợi thế khi lập trình các hệ thống phức tạp. Những ngƣời phát triển phần mềm nhận thấy rằng phát triển phần mềm hƣớng đối tƣợng sẽ cho lại phần mềm thƣơng mại chất lƣợng cao: tin cậy, dễ mở rộng và dễ sử dụng lại, chạy trơn tru, phù hợp với yêu cầu ngƣời dùng đang mong đợi. Chúng cịn cho khả năng hồn thành phần mềm đúng kỳ hạn và khơng vƣợt quá khinh phí dự kiến ban đầu. Ngồi phƣơng pháp cấu trúc và phƣơng pháp hƣớng đối tƣợng vừa đề cập trên đây, ngƣời ta cịn thấy một số phƣơng pháp khác đƣợc các nhà tin học đề xuất cho cơng nghệ phần mềm nhƣ tiếp cận hƣớng logic, tiếp cận hƣớng tác tử (agent) Phƣơng pháp tiếp cận hƣớng logic mơ tả quan hệ “logic” giữa tính chất và thuộc tính của các sự kiện nhờ các cơ sở lập luận và luật suy diễn biểu diễn bởi những gợi ý trƣớc. Tiếp cận này hình thành trên cơ sở ngơn ngữ lập trình Prolog. Phƣơng pháp tiếp cận tác tử là kiểu mở rộng của tiếp cận hƣớng đối tƣợng. Gần đây nĩ đƣợc giới cơng nghiệp rất quan tâm. Các đơn vị cơ sở để phát triển hệ thống ở đây là các tác tử, nĩ là modun phần mềm. Đối tƣợng đƣợc khởi động khi nhận thơng điệp từ bên ngồi và tác tử tích cực làm việc hay khơng phụ thuộc vào mơi trƣờng chứa nĩ. Tuy nhiên, phƣơng pháp hƣớng đối tƣợng đang ngày cành đƣợc nhiều ngƣời sử dụng hơn cả. Phát triển phần mềm bằng UML trang | 9
11. 1.1 LỊCH SỬ HƢỚNG ĐỐI TƢỢNG Khái niệm hƣớng đối tƣợng hình thành từ ngơn ngữ lập trình Simula, nhƣng nĩ chỉ trở nên quen thuộc khi xuất hiện ngơn ngữ C++ và SmallTalk vào cuối những năm 80 của thế kỳ XX. Sơ đồ trong hình 1.3 chỉ ra thời gian xuất hiện và quan hện của các ngơn ngữ lập trình [OES00]. Trong hình vuơng với gĩc trịn là tên các ngơn ngữ lập trình hƣớng đối tƣợng. Hình 1.3 Các ngơn ngữ lập trình Khi các ngơn ngữ hƣớng đối tƣợng đƣợc sử dụng rộng rãi thì nhu cầu cĩ phƣơng pháp phát triển phần mềm hƣớng đối tƣợng trở nên cấp bách. Vào đầu những năm 90 của thế kỷ XX đã xuất hiện các phƣơng pháp hƣớng đối tƣợng sau đây: Phƣơng pháp Booch, OMT (Object Modeling Technique), OOSE (Object Oriented Software Engineering)/Objectory, Fusion và Coad/Yourdon. Mỗi phƣơng pháp cĩ ký pháp, tiến trình và cơng cụ hỗ trợ riêng. Chúng đều cĩ ƣu điểm và nhƣợc điểm riêng. Ngƣời sử dụng rất khĩ khăn để chọn cho mình một phƣơng pháp phù hợp. Do nhận biết đƣơc các vấn đề này, vào năm 1994 các tác giả của các phƣơng pháp này đã hợp tác nhằm Phát triển phần mềm bằng UML trang | 10
12. tạo ra phƣơng pháp mới. Bắt đầu là sự thống nhất phƣơng pháp Booch với OMT-2 của Rumbagh để hình thành Unified Method 0.8 tại Rational Rose Corporation. Tháng 6 năm 1995, Ivar Jacobson (tác giả của OOSE/Objectory) gia nhập với họ. Từ thời điểm này, nhĩm phát triển phƣơng pháp hƣớng đối tƣợng nĩi trên cho rằng nhiệm vụ của họ là tạo ra ngơn ngữ mơ hình hĩa thống nhất cho cộng đồng hƣớng đối tƣợng. Do vậy, họ đã đổi tên cơng việc của mình thành Unified Modeling Language – UML (Ngơn ngữ mơ hình hĩa thơng nhất). Booch, Rumbaugh và Jacobson đã đƣa ra nhiều phiên bản UML, trong đĩ phiên bản UML 0.9 xuất hiện năm 1995, UML xuất hiện vào năm 1997. Phần lớn UML đƣợc xây dựng trên nền tảng của các phƣơng pháp Booch, OMT và OOSE, nhƣng UML cịn bao gồm cả các khái niệm cĩ nguồn gốc từ các phƣơng pháp khác nhƣ David Harel, Gamma – Helm – Johnson – Vlissides và Fusion. UML cịn là kết quả của sự đĩng gĩp từ các hãng lớn nhƣ Digital Equipment Corporation (DEC), Hewlett – Packard (HP), I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software Corporation, Texas Instrument, Taskon, ObjectTime và Unisys. Phiên bản UML 1.1 đã đƣợc đệ trình lên OMG (Object Management tháng 11-1997. Phiên bản UML 1.3 xuất hiện vào năm 1999. Phiên bản UML 1.4 xuất hiện vào tháng 2-2000. 1.2 MỘT SỐ KHÁI NIỆM CƠ BẢN Phần này trình bày một số khái niệm cơ bản áp dụng trong phân tích và thiết kế hƣớng đối tƣợng. Phƣơng pháp (method). Phƣơng pháp (hay phƣơng thức) là cách thức cấu trúc các suy nghĩ và hành động của con ngƣời. Nĩ cho biết chúng ta phải làm cái gì, làm nhƣ thế nào, làm khi nào và tại sao phải làm nhƣ vậy để hình thành hệ thơng phần mềm. Đối thƣơng (object). Theo nghĩa thơng thƣờng thì đối tƣợng là ngƣời, vật hay hiện tƣợng mà con ngƣời nhằm vào trong suy nghĩ, trong hành động [PHE96]; là bất kỳ cái gì nhìn thầy và sờ mĩ đƣợc. Trong phƣơng pháp hƣớng đối tƣợng thì đối tƣợng là trừu tƣợng cái gì đĩ trong lĩnh vực vấn đề hay trong cài đặt của nĩ; phản ảnh khả năng hệ thống lƣu giữ thơng tin về nĩ và tƣơng tác với nĩ; gĩi các giá trị thuộc tính và các dịch vụ (phƣơng thức, phƣơng pháp) [OCAD91]. Lớp (class). Theo nghĩa thơng thƣờng thì lớp là nhĩm của nhiều ngƣời hay vật cĩ tính tƣơng tự nhất định hay đặc điểm chung (từ điển Webster‟s). Trong phƣơng pháp hƣớng đối tƣợng thì lớp là mơ tả một hay nhiều đối tƣợng, mơ tả tập thống nhất các thuộc tính và phƣơng thức. Nĩ cịn cĩ thể mơ tả cách tạo đối tƣợng mới trong lớp nhƣ thế nào [COAD91]. Trừu tƣợng (abstract). Trừu tƣợng là nguyên lý bỏ qua những khía cạnh của chủ thể (subject) khơng liên quan đến mục đích hiện tại để tập trung đầy đủ hơn vào các khía cạnh cịn lại. Nhƣ vậy cĩ thể nĩi rằng trừu tượng là đơn giản hĩa thế giới thực một cách thơng minh. Trừu tƣợng cho khả năng tổng quát hĩa và ý tƣởng hĩa vấn đề đang xem xét. Chúng loại bỏ đi các chi tiết dƣ thừa mà chỉ tập chung và các điểm chính, cơ bản [LIBE98]. Mơ hình (model). Nếu phải xây ngơi nhà thì chắc chắn khơng làm đơn giản là cứ mua gạch, sắt thép về lắp dần đến khi hình thành nhà ở, mà phải cĩ kế hoạch chi tiết và thiết kế trƣớc. Nĩi cách khác là phải xây dựng mơ hình. Tƣơng tự nhƣ vậy, trong Phát triển phần mềm bằng UML trang | 11
13. lĩnh vực phần mềm, mơ hình là kế hoạch chi tiết của hệ thống, nĩ giúp ta lập kế hoạch trƣớc khi xây dựng hệ thống. Mơ hình giúp ta khẳng định tính đúng đắn của thiết kế, phù hợp yêu cầu, hệ thống vẫn giữ vững khi yêu cầu ngƣời dùng thay đổi. Phƣơng pháp hƣớng đối tƣợng xem một phần của thế giới thực nhƣ các đối tƣợng. Máy điện thoại, xe ơ tơ, con ngƣời là các đối tƣợng. Các đối tƣợng này lại bao gồm nhiều đối tƣợng khác nhƣ xe ơ tơ cĩ tay lái, bánh xe, con ngƣời cĩ tay, chân, mắt, mũi Đối tƣợng thế giới thực cĩ thế cĩ cấu trúc rất phức tạp, làm cho con ngƣời khĩ nhận thức đƣợc chúng. Trong cuộc sống hàng ngày ta đơn giản hĩa đối tƣợng khi suy nghĩ, hay nĩi cách khác ta làm việc với mơ hình. Thí dụ, quả địa cầu là mơ hình của trái đất. Mơ hình chỉ lựa chọn một vài khía cạnh cĩ ý nghĩa cho việc thực hiện cơng việc cụ thể nào đĩ. Chúng cho phép dự đốn, hiểu các khía cạnh của vấn đề đang quan tâm. Thí dụ khi làm việc với đối tƣợng con ngƣời: trong sổ lƣơng cĩ tên, số bảo hiểm xã hội và tiền lƣơng. Nhƣng trong sổ điện thoại lại chỉ cĩ tên, số điện thoại và địa chỉ. Vậy, mơ hình là bức tranh hay mơ tả của vấn đề đang đƣợc cố gắng giải quyết hay biểu diễn. Mơ hình cịn cĩ thể là mơ tả chính giải pháp. Trong phát triển phần mềm, thay cho đối tƣợng thực, ta sẽ làm việc với biểu tƣợng (hình 1.4). Tiến trình phát triển phần mềm là làm giảm một số đặc trƣng của đối tƣợng để hình thành mơ hình: làm giảm độ phức tạp bằng mơ hình trừu tƣợng. Hình 1.4 Mơ hình thế giời thực Phƣơng pháp luận (methodology). Phƣơng pháp luận mơ tả cách thức suy nghĩ về phần mềm và phát triển phần mềm. Nĩ bao gồm ngơn ngữ mơ hình hĩa metamodel (mơ hình của mơ hình) và tiến trình. Phƣơng pháp luận khác với phƣơng pháp. Phƣơng pháp luận là nghiên cứu phƣơng pháp. Metamodel mơ tả hình thức các phần tử mơ hình, cú pháp và ngữ nghĩa của các ký pháp trong mơ hình. Lĩnh vực vấn đề (domain problem). Mục tiêu của tiếp cận hƣớng đối tƣợng là mơ hình hĩa các đặc tính tĩnh và động của mơi trƣờng, nơi xác định yêu cầu phần mềm. Mơi trƣờng này đƣợc gọi là lĩnh vực vấn đề. Vấn đề là câu hỏi đặt ra để giải quyết hoặc xem xét. Lĩnh vực là khơng gian (vùng) của các hoạt động hoặc ảnh hƣởng. Nĩ là vùng tác nghiệp hay kinh nghiệm của con ngƣời trong đĩ phần mềm đƣợc sử dụng. Vậy, lĩnh vực vấn đề là vùng mà ta đang cố gắng xem xét. Thí dụ của lĩnh vực vấn đề cĩ thể là tài chính, giáo dục, Phân tích. Phân tích là tách, chia nhỏ tổng thể thành các phần để tìm ra đặc tính, chức năng, quan hệ của chúng (từ điển Webster‟s). Khái niệm phân tích trong tiếp Phát triển phần mềm bằng UML trang | 12
14. cận hƣớng đối tƣợng là thực hiện nghiên cứu lĩnh vực vấn đề, dẫn tới đặc tả hành vi quan sát từ ngồi và các thơng báo nhất quán, hồn chỉnh, khả thi của những cái cần [COAD91]. Phân tích hƣớng đối tƣợng tập trung vào tìm kiếm, mơ tả các đối tƣợng (khái niệm) trong lĩnh vực vấn đề. Thí dụ hệ thống thƣ viện cĩ khái niệm Sách, Thƣ viện Thiết kế. Là tập tài liệu kỹ thuật tồn bộ, gồm cĩ bản tính tốn, bản vẽ để cĩ thể theo đĩ mà xây dựng cơng trình, sản xuất thiết bị, làm sản phẩm [PHE96]. Khái niệm phân tích trong tiếp cận hƣớng đối tƣợng là thực hiện đặc tả các hành vi bên ngồi, bổ sung chi tiết nếu cần thiết để cài đặt hệ thống trên máy tính, bao gồm tƣơng tác ngƣời - máy, quản lý nhiệm vụ, quản lý dữ liệu [COAD91]. Thiết kế hƣớng đối tƣợng tập trung vào xác định đối tƣợng phần mềm logic sẽ đƣợc cài đặt bằng ngơn ngữ hƣớng đối tƣợng. Xây dựng (lập trình) hƣớng đối tƣợng: là thiết kết các modun sẽ đƣợc cài đặt. Thí dụ lớp Book sẽ đƣợc cài đặt bằng C++, Java nhƣ thế nào. Mơ hình hĩa (modeling). Khái niệm mơ hình hĩa thƣờng đƣợc sử dụng đồng nghĩa với phân tích, đĩ là việc thực hiện tách hệ thống thành các phần tử đơn giản để dễ hiểu. Trong khoa học máy tính, mơ hình hĩa bắt đầu từ mơ tả vấn đề, sau đĩ là mơ tả giải pháp vấn đề. Các hoạt động này cịn đƣợc gọi là phân tích và thiết kế. Khi thu thập yêu cầu cho hệ thơng, ta phải tìm ra nhu cầu tác nghiệp của ngƣời dùng và ánh xạ chúng thành yêu cầu phần mềm sao cho đội ngũ phát triển phần mềm hiểu và sử dụng đƣợc chúng. Tiếp theo là khả năng phát sinh mã trình từ các yêu cầu này, đồng thời đảm bảo rằng các yêu cầu phải phù hợp với mã trình vừa phát sinh và dễ dàng chuyển đổi mã trình ngƣợc lại thành yêu cầu. Tiến trình này đƣợc gọi là mơ hình hĩa. Mơ hình hĩa trực quan. Mơ hình hĩa trực quan là tiến trình lấy thơng tin từ mơ hình và hiển thị đồ họa bằng tập các phần từ đồ họa chuẩn. Tiêu chuẩn là cốt lõi để thực hiện một trong các lợi thế của mộ hình trực quan, đĩ là vấn đề giao tiếp. Giao tiếp giữa ngƣời dùng, ngƣời phát triển, phân tích viên, kiểm tra viên, ngƣời quản lý và những ngƣời khác tham gia dự án là mục tiêu quan trọng nhất của mơ hình hĩa trực quan. Tƣơng tác này cĩ thể đƣợc thực hiện bằng văn bản. Nhờ mơ hình trực quan mà ta cĩ thể chỉ ra các tầng mà hệ thống làm việc, bao gồm tƣơng tác giữa ngƣời dùng với hệ thống, tƣơng tác giữa các đối tƣợng trong hệ thống hay giữa các hệ thơng với nhau. Sau khi tạo mơ hình, ta cĩ thể chỉ ra từng phần quan tâm. Thí dụ, ngƣời dùng cĩ thể quan sát tƣơng tác giữa họ với hệ thơng từ mơ hình, phân tích viên quan sát tƣơng tác các đối tƣợng từ mơ hình, ngƣời phát triển sẽ quan sát đƣợc đối tƣợng mà họ sẽ phát triển Các nhà tin học đã rất cố gắng để hình thành ký pháp mơ hình hĩa trực quan. Một số ký pháp quen thuộc là của Booch, OMT và UML. Phần mềm cơng cụ Rational Rose 2000 trợ giúp các ký pháp này. Tĩm lại, lý do cơ bản để mơ hình hĩa là: xây dựng mơ hình để hiểu sâu sắc hơn về hệ thống đang đƣợc xây dựng. Chúng ta xây dƣng mơ hình cho các hệ thống phức tạp vi ta khơng thể hiểu nĩ nhƣ tổng thể. Nhờ mơ hình hĩa ta sẽ đạt đƣợc các mục tiêu sau: Mơ hình giúp ta hiển thị hệ thống nhƣ chính nĩ hay nhƣ cách mà ta muốn nĩ hiển thị. Mơ hình cho phép ta đặc tả cấu trúc hay hành vi hệ thống. Mơ hình cho ta mấu để hƣớng đẫn trong việc xây dựng hệ thống. Phát triển phần mềm bằng UML trang | 13
15. Mơ hình giúp ta làm tài liệu cho các quyết định khi phân tích thiết kế hệ thống. 1.3 NGUYÊN TẮC QUẢN LÝ ĐỘ PHỨC TẠP Nhƣ đã trình bày trên thì nhiệm vụ quan trọng nhất của ngƣời xậy dựng hệ thống phần mềm ngày nay là quản lý đƣợc độ phức tạp. Theo Coad và Yourdon [COAD91] thì các nguyên tắc quản lý độ phức tạp của hệ thống trong phân tích và thiết kế hƣớng đối tƣợng bao gồm các vấn đề mơ tả dƣới đây. Trừu tƣợng hĩa. Sử dụng nguyên tắc trừu tƣợng hĩa cĩ nghĩa là thừa nhận thế giới thực là phức tạp; thay vì cố gắng hiểu biết tồn bộ bằng lựa chọn một phần của vấn đề. Trừu tƣợng bao gồm hai loại chính: trừu tƣợng thủ tục (procedural) và trừu tƣợng dữ liệu (data). Trừu tƣợng thủ tục thƣờng đƣợc đặc trƣng bởi trừu tƣợng chức năng/chức năng con. Chia nhỏ tiến trình xử lý thành các bƣớc là phƣơng pháp cơ bản để quản lý độ phức tạp. Tuy nhiên việc chia nhỏ để tổ chức thiết kế là khá tùy tiện và khơng ổn định. Trừu tƣợng thủ tục khơng phải là hình thức trừu tƣợng của phƣơng pháp hƣớng đối tƣợng. Trừu tƣợng dữ liệu là cơ chế mạnh, dựa trên cơ sở tổ chức suy nghĩ và đặc tả về các nhiệm vụ của hệ thống. Trừu tƣợng dữ liệu là nguyên tắc xác định kiểu dữ liệu cho các thao tác áp dụng cho đối tƣợng, với ràng buộc là các giá trị lƣu trữ trong đối tƣợng chỉ đƣợc sửa đổi hay quan sát thơng qua các thao tác đĩ. Ngƣời thiết kế áp dụng trừu tƣợng dữ liệu đễ xác định thuộc tính và phƣơng thức xử lý thuộc tính xâm nhập thuộc tính thơng qua phƣơng thức. Bao bọc (encapsulation). Cịn gọi là dấu thơng tin. Nguyên tắc này dựa trên nền tảng là mỗi thành phần của chƣơng trình đƣợc bao bọc hay dấu quyết định thiết kế đơn lẻ. Giao diện tời mỗi mođun đƣợc hình thành sao cho ít nhìn thấy các cơng việc bên trong. Bao bọc làm tăng tính sử dụng lại khi phát triển hệ thống mới. Bao bọc các nội dung liên quan với nhau làm giảm lƣu lƣợng giữa các phần của hệ thơng khi hoạt đơng. Kế thừa (inheritance). Cơ chế biểu diễn tính tƣơng tự của các lớp, đơn giản hĩa định nghĩa những lớp tƣơng tự từ các lớp khác đã định nghĩa trƣớc. Nĩ miêu tả tổng quát hĩa và đặc biệt hĩa, tạo ra các thuộc tính và phƣơng thức chung cho các lớp phân cấp. Nguyên tắc này hình thành nền tảng của kỹ thuật biển diễn những cái chung của các lớp. Kết hợp (association). Là hợp nhất hay liên kết các ý tƣởng (từ điển Webster‟s). Sử dụng kết hợp để gắn một vài phần tử xảy ra vào thời điểm cụ thể hay dƣới điều kiện tƣơng tự nhau. Thí dụ, gắn xe cộ vào chủ xe Giao tiếp bằng thơng điệp. Thơng điệp là giao tiếp (viết nĩi) đƣợc trao đổi giữa ngƣời với ngƣời (từ điển Webster‟s). Giao tiếp bằng thơng điệp liên quan đến tính bao bọc trong đĩ các chi tiết của hành động sẽ thực hiện đƣợc bao bọc trong nơi nhận thơng điệp. Đa hình (polymorphism). Đa hình là các thơng điệp đồng âm đƣợc gứi đến các đối tƣợng của lớp khác nhau để khởi sự những hành vị khác nhau [OEST00]. Ảnh hƣởng của phƣơng pháp tổ chức. Bách khoa tồn thƣ Britannica cho rằng để hiểu thế giới thực, con ngƣời sử dụng ba phƣơng pháp tổ chức suy nghĩ nhƣ sau: (1) Phân biệt đối tƣợng cụ thể với các thuộc tính của nĩ; thí dụ, phân biệt cây với kích thƣớc của nĩ hoặc quan hệ khơng gian với các đối tƣợng khác. (2) Phân biệt giữa tồn Phát triển phần mềm bằng UML trang | 14
16. bộ đối tƣợng với thành phần của nĩ; thí dụ, phân biệt cây với cành cây.(3) Phân biệt giữa các lớp đối tƣợng với nhau; thí dụ, phân biệt lớp cây với lớp đất đá. Cả ba phƣơng pháp tổ chức này đƣợc áp dụng và chúng cho cái nhìn rõ ràng hơn trong lĩnh vực vấn đề và trách nhiệm của hệ thống khi tiếp cận hƣớng đối tƣợng. Quy mơ (scale). Nguyên tắc áp dụng qui tắc tổng thể-thành phần để quan sát cái gì đĩ rất lớn đƣợc gọi là qui mơ. Phân lớp hành vi. Sau khi đã tìm ra ảnh hƣởng tổ chức suy nghĩ, ta phải hiểu rõ các hành vi của đối tƣợng. Hành vi là những phản ứng, cách cƣ xử biểu hiện ra ngồi. Phân lớp hành vi bao gồm ba loại sau: (a) trên cơ sở tạo ra kết quả tức thì; (b) sự tƣơng tự của lịch sử tiến hĩa (thay đổi theo thời gian) và (c) sự tƣơng tự của các chức năng. Mẫu (pattern). Năm 1977 Christopher Alexander [MULL97] đã đề xuất khái niệm mẫu khi thiết kế hệ thống theo quan điểm hƣớng đối tƣợng. Mẫu là tổ hợp đối tƣợng và lớp. Lợi thế của thiết kế theo mẫu cho phép xử lý các quan niệm về kiến trúc ở mức cao hơn đối tƣợng vì chúng là cụ thể trong lĩnh vực ứng dụng. Cĩ thể xem mối tƣơng ứng giữa mẫu và các đối tƣợng nhƣ mối tƣơng ứng giữa chƣơng trình con và các dịng lệnh chƣơng trình. Mẫu là đơn vị sử dụng lại trong thiết kế hƣớng đối tƣợng. 1.4 NGUYÊN TẮC MƠ HÌNH HĨA Khả năng của con ngƣời là cĩ giới hạn khi khảo sát các vấn đề phức tạp nhƣ tổng thể. Thơng qua mơ hình hĩa ta sẽ giới hạn vấn đề nghên cứu bằng cách chỉ tập trung vào một khía cạnh của vấn đề vào một thời điểm. Đĩ là quan điểm chia để trị và Edsger Dijkstra đã phát biểu từ vài năm trƣớc đây: Tấn cơng vào vấn đề khĩ bằng cách chia nhỏ nĩ thành dãy các vấn đề nhỏ hơn mà ta cĩ thể giải quyết được. Mơ hình hĩa sẽ làm tăng tri thức của con ngƣời. Việc chọn mơ hình đúng cho khả năng mơ hình làm việc ở mức trừu tƣợng cao. Mơ hình hĩa đã cĩ lịch sử lâu đời trong mọi lĩnh vực kỹ nghệ. Ngƣời ta đã rút ra bốn nguyên tắc cơ bản sau [BRJ99]: 1. Việc chọn mơ hình nào để tạo lập cĩ ảnh hưởng sâu sắc đến cách giải quyết vấn đề và cách hình thành các giải pháp. Các mơ hình đúng sẽ làm sáng tỏ vấn đề phát triển phức tạp nhất, cho cái nhìn thấu đáo vấn đề cần giải quyết. Mặt khác, mơ hình tồi sẽ làm ta lạc lối, làm cho ta chỉ tập trung vào các nhiệm vụ khơng thích hợp. Việc chọn mơ hình cho hệ thống phần mềm tác động mạnh đến cách quan sát thế giới. Nếu xây dựng hệ thống theo cách nhìn của ngƣời phát triển CSDL thì họ sẽ tập trung vào mơ hình quan hệ thực thể, đẩy hành vi vào trigger (khởi sự hành động) và thủ tục lƣu trữ. Dƣới con mắt của ngƣời phân tích cấu trúc, mơ hình tập trung vào thuật tốn và luồng dữ liệu từ tiến trình này sang tiến trình khác. Dƣới con mắt của ngƣời phát triển hƣớng đối tƣợng, hệ thống cĩ kiến trúc tập trung vào vơ số lớp và các mẩu thử tƣơng tác giữa các đối tƣợng lớp. Một cách tiếp cận trên cĩ thể phù hợp cho mỗi lớp ứng dụng hay thĩi quen phát triển hệ thống. Tuy nhiên kinh nghiệm cho thấy rằng tiếp cận hƣớng đối tƣợng là ƣu việt nhất cho mọi kiến trúc. Mỗi cách nhìn thế giới sẽ dẫn đến sự khác nhau về giá cả và lợi nhuận của hệ thống đƣợc xây dựng. 2. Mỗi mơ hình biểu diễn hệ thống với mức độ chính xác khác nhau. Khi xây dựng nhà cao tầng, đơi khi ta phải đứng xa hàng trăm mét để quan sát tổng thể. Tƣơng tự với các mơ hình phát triển phần mềm, đơi khi ta chỉ cần cĩ mơ hình Phát triển phần mềm bằng UML trang | 15
17. nhanh, đơn giản về giao diện ngƣời dùng; đơi khi lại phải quan sát sâu hơn đến mức các bit khi giải quyết vấn đề tắc nghẽn đƣờng truyền hệ thống. Trong mọi trƣờng hợp nĩi trên thì các loại mơ hình tốt nhất là mơ hình cho phép ta lựa chọn mức độ chi tiết khác nhau, phụ thuộc vào ai sẽ là ngƣời quan sát và tại sao họ lại cần quan sát nĩ. Ngƣời phân tích và ngƣời sử dụng cuối cùng muốn tập trung vào câu hỏi cái gì?, ngƣời phát triển sẽ tập trung trả lời câu hỏi như thế nào?. Cả hai muốn biểu diễn hệ thống ở mức độ chi tiết khác nhau và vào thời điểm khác nhau. 3. Mơ hình tốt nhất phải là mơ hinh phù hợp với thế giới thực. Mơ hình càng gần với cách suy nghĩ của ta về thế giới thực thì càng dễ dàng quản lý độ phức tạp. Nếu mơ hình vật lý của ngơi nhà mà khơng đáp ứng cách sử dụng của các vật liệu cĩ trên thị trƣờng thì giá trị của mơ hình đĩ chỉ cĩ hạn. Nếu giả thiết của mơ hình tốn học của con tàu vũ trụ là điều kiện lý tƣởng và cơng nghệ hồn hảo thì sẽ loại bỏ các đặc điểm nguy hiểm tiềm tàng của tàu vũ trụ thực. Tốt nhất là phải cĩ mơ hình kết nối rõ ràng với thế giới thực. Mọi mơ hình đều đơn giản hĩa thế giới thực, do vậy phải đảm bảo tiến trình đơn giản hĩa sẽ khơng loại bỏ đi các chi tiết quan trọng. Với phần mềm, trong các kỹ thuật phân tích cấu trúc thì mơ hình phân tích và mơ hình thiết kế hệ thống sẽ đƣợc tách biệt nhau. Thiếu cầu nối giữa hại loại mơ hình này, dẫn tới hệ thống sẽ đƣợc hiểu và xây dựng khác nhau vào các thời điểm khác nhau. Trong hệ thống hƣớng đối tƣợng, cĩ khả năng liên kết mọi quan sát tƣơng đối độc lập vào tồn thể. 4. Khơng mơ hình nào là đầy dủ. Mỗi hệ thống thường được tiếp cận thơng qua tập mơ hình gần như độc lập nhau. Khi xây dựng tịa nhà, khơng cĩ một bản thiết kế nào cĩ thể bộc lộ tồn bộ chi tiết của nĩ. Ít nhất thì ta phải cĩ thiết kế các tầng, thiết kế cầu thang, thiết kế hệ thơng điện, nƣớc, thiết kế hệ thống cứu hỏa, Khái niệm gần như độc lập nhau ở đây cĩ nghĩa rằng các mơ hình này đƣợc hình thành và nghiên cứu tách biệt nhƣng nĩ vẫn cĩ quan hệ với nhau. Thí dụ, ta cĩ thể thiết kế hệ thơng điện, nƣớc một cách độc lập, nhƣng trong quá trình thiết kế này thì phải quan tâm đến thiết kế của các tầng nhà cho nĩ phù hợp. Tƣơng tự trong hệ thống phần mềm hƣớng đối tƣợng, để hiểu kiến trúc hệ thống phần mềm ta cần một vài quan sát bổ trợ nhau: quan sát trường hợp sử dụng diễn tả yêu cầu hệ thống, quan sát thiết kế (thu thập từ vựng của khơng gian vấn đề và khơng gian giải pháp), quan sát tiến trình (mơ hình hĩa phân bổ tiến trình và luồng của hệ thống), quan sát cài đặt (tập trung vào hiện thực vật lý của hệ thống), quan sát triển khai (tập trung vào các nhiệm vụ kỹ nghệ của hệ thống). Mỗi quan sát đều cĩ khía cạnh kiến trúc hay hành vi riêng. Tập hợp lại các quan sát này cĩ khả năng biểu diễn đƣợc kế hoạch chi tiết của phát triển phần mềm. Phục thuộc vào bản chất của hệ thống mà mỗi mơ hình cĩ tầm quan trọng khác nhau. Thí dụ, với hệ thống quản lý nhiều dữ liệu thì các mơ hình quan sát thiết kế tĩnh sẽ quan trọng hơn. Nếu hệ thống phải cĩ nhiều giao diện ngƣời dùng thì các quan sát trường hợp sử dụng tĩnh và động đều rất quan trọng. Hệ thống thời gian thực coi trọng quan sát tiến trình động. Cuối cùng, hệ thống phân tán (các ứng dụng Web) coi mơ hình triển khai và cài đặt là quan trọng nhất. Phát triển phần mềm bằng UML trang | 16
18. 1.5 KHÁI QUÁT VỀ TIẾN TRÌNH PHÁT TRIỂN PHẦN MỀM Hệ thống là tổ hợp phần cứng, phần mềm cung cấp giải pháp cho vấn đề cần giải quyết. Ngày nay, trong khi hệ thống quá phức tạp mà tri thức lại quá chuyên ngành cho nên một ngƣời khơng thể biết mọi khía cạnh tác nghiệp. Một ngƣời khơng thể hiểu đồng thời mọi vấn đề của hệ thống: từ thiết kế giải pháp, viết mã trình, triển khai trên nền phần cứng đến đảm bảo chắc chắn mọi thành phần phần cứng đều làm việc tốt với nhau. Tiến trình phát triển phần mềm phức tạp phải đƣợc nhiều ngƣời thực hiện. Trƣớc hết là khách hàng, đĩ là ngƣời đƣa ra vấn đề cần giải quyết. Phân tích viên làm tài liệu vấn đề của khách hàng và chuyển nĩ tới ngƣời phát triển, đĩ là những lập trình viên xây dựng phần mềm để giải quyết, kiểm tra và triển khai nĩ trên các phần cứng. Phát triển phần mềm cĩ thể đƣợc thực hiện bằng nhiều con đƣờng khác nhau. Các dự án cĩ thể tuân thủ một trong các loại tiến trình lặp và tăng dần. Mỗi loại cĩ ƣu và nhƣợc điểm riêng. 1.5.1 - Các phƣơng pháp mơ hình hĩa hệ thống 1.5.1.1 - Mơ hình thác nước Từ đã lâu, hệ thống phần mềm thƣờng đƣợc mơ hình hĩa theo phƣơng pháp thác nước (waterfall). Phƣơng pháp này đƣợc Royce mơ tả từ năm 1970 (hình 1.5). Trong mơ hình này phát triển phần mềm là dãy các pha liên tiếp từ phân tích yêu cầu, thiết kế hệ thống, phát triển hệ thống đến thử nghiệm và triển khai hệ thống. Pha sau chỉ đƣợc bắt đầu khi pha trƣớc đã hồn thành. Phân tích Thi ết k ế Vi ế t ch ƣơ ng trình Th ử nghi ệ m Hình 1.5 Mơ hình thác nước Để xây dựng đƣợc hệ thống phần mềm ta phải mơ tả đƣợc vấn đề (problem) và yêu cầu (requirement) của khách hàng bằng trả lời các câu hỏi nhƣ vấn đề của hệ thống là gì? và hệ thống cần phải làm gì?. Pha phân tích của tiến trình tập trung vào việc điều tra vấn đề thay cho việc tìm ra giải pháp. Thí dụ, khi xây dựng hệ thống quản lý thƣ viện thì phân tích cĩ nghĩa là tìm kiếm tiến trình tác nghiệp nào liên quan đến việc sử dụng nĩ. Để cĩ tài liệu phân tích đầy đủ và đúng đắn thì phải phân tích lĩnh vực vấn đề. Lĩnh vực vấn đề là khu vực tác nghiệp của con ngƣời, trong đĩ phần mềm đƣợc xây dựng. Thí dụ, hệ thống phần mềm thƣ viện trong trƣờng học lĩnh vực là giáo dục, sinh viên Pha thiết kế tập trung vào giải pháp logic, thí dụ phải trả lời câu hỏi hệ thống đang xây dựng thực hiện các yêu cầu và các ràng buộc như thế nào?. Trong hệ thống quản lý thƣ viện thì pha này thực hiện trả lời câu hỏi thu thập, ghi chép việc mượn, trả sách hay tạp chí như thế nào?. Pha cài đặt (viết trƣơng trình) tập trung vào mà hĩa trƣơng trình. Phát triển phần mềm bằng UML trang | 17
19. Phân tích Ki ể m tra ch ứ c n ăng Thi ết kế Ki ể m tra tích h ợ p Vi ết ch ƣơ ng trình Ki ể m tra mơ đ un Ch ƣơ ng trình ứ ng d ụ ng Hình 1.6 Mơ hình chữ “V” Những ngƣời tham gia vào xây dựng hệ thống phần mềm nhƣ khách hàng, phân tích viên, lập trình viên theo phƣơng pháp thác nước rất ít khi cùng làm việc với nhau để chia sẽ các hiểu biết sâu sắc vấn đề đang giải quyết. Do vậy họ mất rất nhiều thời gian để xây dựng đƣợc hệ thống phần mềm. Chu kỳ thác nước cịn đƣợc biểu diễn dƣới dạng chữ V (hình 1.6), trong đĩ pha kiểm tra đƣợc thực hiện đồng thời với các pha phát triển khác. Thí dụ, kiểm tra chức năng đƣợc thực hiện trong quá trình phân tích, kiểm tra tích hợp trong pha thiết kế, kiểm tra mođun trong pha mã hĩa chƣơng trình. 1.5.1.2 - Mơ hình lặp và tăng dần Mơ hình thác nước khơng cho ta đi ngƣợc lại chuỗi trình tự phát triển phần mềm nhƣ trình bày trên. Bắt đầu dự án, theo mơ hình này thì ta phải xác định tồn bộ yêu cầu, nĩ đƣợc thực hiện thơng qua bàn bạc với ngƣời sử dụng hệ thống và khảo sát chi tiết các tiến trình tác nghiệp. Thực tế thì khi kết thúc cơng việc, may mắn lắm chỉ 80% nhu cầu hệ thống là đƣợc thu thập trong pha phân tích. Tiếp theo là pha thiết kế, nơi kiến trúc hệ thống sẽ đƣợc xác định. Pha này tập trung vào những nhiệm vụ nhƣ đặt chƣơng trình ở đâu, cần phần cứng nào Trong khi thực hiện cơng việc này, ta cĩ thể tìm ra một số nhiệm vụ mới (nhu cầu mới) của hệ thống. Do đĩ, xuất hiện nhu cầu đi trở lại ngƣời sử dụng để trao đổi, bàn bạc về nĩ; cĩ nghĩa rằng chúng ta phải trở lại pha phân tích. Sau khi đi lại vài lần nhƣ vậy ta mới chuyển đến pha phát triển để bắt đầu lập trình hệ thống. Khi mã hĩa chƣơng trình, ta phát hiện ra rằng một vài quyết định khi thiết kế là khơng thể cài đặt. Vậy ta lại phải trở lại pha thiết kế xem xét lại các nhiệm vụ. Sau khi mã hĩa xong, pha kiểm tra bắt đầu. Trong khi kiểm tra ta nhận thấy rằng một vài yêu cầu chƣa đủ chi tiết, giải thích nhầm lẫn cĩ thể xảy ra. Vậy ta phải quay trở lại pha phân tích để xem xét lại yêu cầu. Sau vài lần lặp ta mới cĩ đƣợc hệ thống hồn chỉnh và phân phát cho ngƣời sử dụng. Tác nghiệp cĩ thể thay đổi theo thời gian khi xây dựng hệ thống. Ngƣời sử dụng cĩ thể phàn nàn về sản phẩm ta làm ra khơng hồn tồn nhƣ họ mong đợi. Nguyên nhân cĩ thể là: vấn đề tác nghiêp (bussiness) thay đổi quá nhanh; ngƣời sử dụng khơng truyền đạt đúng cái họ muốn; đội ngũ dự án khơng tuân thủ tiến trình Đội ngũ phát triển thƣờng lập ra các biểu đồ và vơ số tài liệu, văn bản, nhƣng ngƣời dùng khơng phải lúc nào cũng hiểu cái mà đội ngũ phát triển cung cấp cho họ. Giải pháp nào để tránh các vấn đề này? Câu trả lời là mơ hình hĩa trực quan cĩ thể giúp họ. Phát triển phần mềm bằng UML trang | 18
20. Phát triển phần mềm là tiến trình phức tạp. Nếu bỏ qua khả năng quay trở lại các bƣớc thực hiện trƣớc đĩ thì thiết kế hệ thống cĩ thể sai làm và thiếu sĩt nhu cầu. Để cĩ thể đi ngƣợc lại các bƣớc phát triển hệ thống phần mềm ta cĩ phƣơng pháp mới, phƣơng pháp phát triển lặp (iterative). Phát triển lặp là làm đi làm lại việc gì đĩ. Trong phƣơng pháp này ta sẽ đi qua các bƣớc phân tích, thiết kế, phát triển, kiểm tra và triển khai phần mềm theo từng bƣớc nhỏ nhiều lần. Cần nhớ rằng khơng cĩ khả năng thu thập đầy đủ mọi yêu cầu vào cơng đoạn đầu tiên của dự án. Các vấn đề cĩ thể nảy sinh, vậy ta phải lập kế hoạch lặp trong dự án. Theo quan niệm này thì dự án đƣợc coi là dãy các thác nƣớc nhỏ. Mỗi thác nƣớc đƣợc thiết kế sao cho đủ lớn để hồn thành thiện từng bộ phận quan trọng của dự án và đủ nhỏ để tối thiểu nhu cầu đi trở lại. Hình 1.7 [MULL97] cho thấy mỗi chu kỳ lặp là một vịng đời thác nƣớc nhỏ. Vịng lặp sau đƣợc hình thành trên cơ sở tiến hĩa của vịng lặp trƣớc đĩ. Nhƣ vậy, các pha truyền thống đƣợc lặp đi lặp lại và tăng dần. Trong phƣơng pháp này, phân tích viên, ngƣời thiết kế, ngƣời lập trình hợp tác làm việc để hiểu biết sâu sắc hệ thống, chi sẻ các ý tƣởng mới dẫn tời xây dựng đƣợc hệ thơng mạnh, phức tạp hơn. Phân tích Thi ết k ế Mã hĩa Tích h ợ p Hình 1.7 Mơ hình lặp và tăng dần Cĩ nhiều biết thể của chu kỳ lặp. Các chu kỳ lặp này đƣợc hình thành trên cơ sở phạm vi của dự án, độ phức tạp của vấn đề và các lựa chọn kiến trúc. Thí dụ, chu kỳ lặp hình chữ b của Birrel N.D và Ould M.A. (1985) tập trung vào pha bảo trì hệ thống, đƣợc áp dụng cho các dự án trung bình; chu kỳ lặp hình chữ O của Boehm B.M (1988) bao gồm lặp cơng việc phân tích và thiết kế. Mơ hình này cho khả năng các nhĩm thực hiện song song dự án. 1.5.2 - Các pha phát triển phần mềm Khơng cĩ tiến trình phát triển phần mềm nào là phù hợp cho mọi dự án, mọi lĩnh vực ứng dụng [MULL97]. Phần này mơ tả tiến trình phát triển phần mềm tổng quát, mỗi dự án phải thích nghi chúng với các ràng buộc riêng. Phát triển phần mềm đƣợc quan sát từ hai gĩc độ bổ trợ nhau. Đĩ là, gĩc độ hỗ trợ bao gồm các khía cạnh tài chính, chiến lƣợc, thị trƣờng và con ngƣời và gĩc độ kỹ thuật bao gồm kỹ nghệ, kiểm tra chất lƣợng và phƣơng pháp mơ hình hĩa. 1.5.2.1 - Khía cạnh kỹ thuật trong tiến trình phát triển phần mềm Gĩc nhìn kỹ thuật tập trung vào triển khai và tổ chức các hoạt động kỹ thuật để dẫn tời sản sinh các thế hệ phần mềm khác nhau. Nhƣ trình bày trên, chu kỳ phát triển đƣợc xem nhƣ trình tự các lặp, thơng qua nĩ mà phần mềm tiến triển dần. Kết quả của mỗi vịng lặp là chƣơng trình cĩ thể chạy đƣợc (khả thực). Nội dung của lặp phải cĩ Phát triển phần mềm bằng UML trang | 19
21. ích cho tiến trình phát triển và cho ngƣời sử dụng. Một số kết quả của lặp chỉ đƣợc sử dụng nội bộ tiến trình phát triển, một số khác đƣợc sử dụng để thể hiện trạng thái tiến triển. Từ lặp này đến lặp khác, chƣơng trình sẽ đƣợc bổ sung các chức năng mới và chất lƣợng của nĩ đƣơc nâng cao cho đến một vịng lặp nào đĩ sẽ sản sinh ra thế hệ thứ nhất của phần mềm. L ặ p K ết qu ả Pha L ặ p Kh ả o sát kh ở i đầ u Makét khả thi L ặ p ki ế n trúc Bả n mẫ u ki ế n trúc Chi ti ết L ặ p ki ế n trúc Bả n mẫ u ki ế n trúc L ặ p phát tri ể n B ả n mẫ u phát tri ể n L ặ p Xây d ự ng phát tri ể n B ả n mẫ u phát tri ể n L ặ p phát tri ể n Bả n beta L ặ p chuy ển giao Bả n beta Chuyể n giao L ặ p chuy ển giao Th ế h ệ phầ n mề m Hình 1.8 Tiến trình phát phần mềm Các hoạt động truyền thống khơng đƣợc thực hiện trình tự nhƣ trong chu kỳ phát triển thác nước, nĩ đƣợc phân bổ vào các lặp khác nhau. Mỗi lặp bao gồm lập kế hoạch, phân tích, thiết kế, cài đặt, thử nghiệm và tích hợp. Chƣơng trình khả thực là kết quả của các bƣớc lặp đƣợc gọi là bản mẫu (prototype). Bản mẫu là tập con của một ứng dụng, nĩ đƣợc sử dụng để hình thành các yêu cầu hay đánh giá hiệu quả của cơng nghệ lựa chọn. Bản mẫu ngày càng phong phú thơng qua mỗi bƣớc lặp. Thơng thƣờng, bản mẫu thứ nhất chỉ cĩ một mục đích là chƣng minh quan niệm ứng dụng. Nĩ đƣợc hình thành càng nhanh càng tốt, đơi khi bỏ qua tiêu chuẩn chất lƣợng thơng thƣờng. Bản mẫu này thƣờng đƣợc gọi là mơ hình hay maket. Các bƣớc lặp áp chĩt sẽ phát sinh các phiên bản beta, nĩ đƣợc gửi đến nhĩm ngƣời sử dụng thử nghiệm. Phiên bản chính thức cũng là bản mẫu nhƣ các bản mẫu khác (hình 1.8) [MULL97]. Nĩ đƣợc xem nhƣ bản mẫu cuối cùng của thế hệ phần mềm đang phát triển và là bản mẫu đầu tiên của thế hệ phần mềm tiếp theo. 1.5.2.2 - Quản lý rủi ro trong tiến trình phát triển lặp Nhƣ trong mọi hoạt động khác của con ngƣời, phát triển phần mềm phải tuân thủ luật chia sẻ rủi ro. Phân tích rủi ro bao gồm đánh giá dự án, cơng nghệ và tài nguyên để xác định, hiểu rõ bản chất của rủi ro và quan hệ giữa chúng phải đƣợc mơ tả vắn tắt để mọi thành viên trong dự án biết chúng. Rủi ro phải đƣợc lƣợng hĩa và phải biết rằng nĩ cĩ thể hay khơng cĩ thể loại bỏ. Khơng đƣợc mơ tả thiếu rõ ràng trong tài liệu Phát triển phần mềm bằng UML trang | 20
22. nhƣ “Hệ thống cần đủ nhanh” hay “Bộ nhớ cần đủ lớn” Rủi ro của dự án đƣợc chia thành bốn nhĩm nhƣ sau đây: Rùi ro về thương mại: Cĩ thể thu thập đầy đủ thơng tin cạnh tranh của sản phẩm trên thị trƣờng? Rủi ro về tài chính: Nhà đầu tƣ phát triển phần mềm cĩ đủ kinh phí để hồn thành dự án? Rủi ro về kỹ thuật: Nền tảng cơng nghệ vững chắc và đã đƣợc thử thách? Rủi ro về phát triển: Đội ngũ phát triển cĩ đủ kinh nghiệm? Họ cĩ làm chủ hồn tồn cơng nghệ đang sử dụng? Tuy nhiên, luơn nhớ rằng cái rủi ro lớn nhất là khơng biết đƣợc rủi ro xảy ra ở đâu. Nhiệm vụ quản lý rủi ro là phải lập kế hoạch làm giảm rủi ro, sau đĩ là thực hiện kế hoạch này. 1.5.2.3 - Khía cạnh hỗ trợ tiến trình phát triển phần mềm Từ gĩc nhìn hỗ trợ, phát triển phần mềm đƣợc thực hiện trong bố pha: Khảo sát khả thi hay khởi đâu (inception), chi tiết (elaboration), xây dựng (construction) và chuyển giao (transition). Chu kỳ phát triển phần mềm từ gĩc độ này đƣợc mơ tả trên hình 1.8. Hình này cịn cho thấy quan hệ giữa hai gĩc nhìn khác nhau: gĩc nhìn hỗ trợ và gĩc nhìn kỹ thuật. Dƣới đây là mơ tả các pha phát triển phần mềm từu gĩc nhìn hỗ trợ. Pha khởi đầu (hay khảo sát khả thi). Pha này bao gồm khảo sát thị trƣờng, đặc tả sản phẩm cuối cùng, xác định phạm vi dự án. Khởi đầu là bắt đầu dự án, từ khi ai đĩ cho rằng nếu cĩ hệ thống phần mềm mới để giúp đỡ cơng việc của họ thì tốt hơn. Tiếp theo là ai đĩ nghiên cứu ý tƣởng. Ngƣời quản lý (khách hàng) hỏi bao lâu thì cĩ phần mềm? Kinh phí là phần mềm là bao nhiêu? Tính khả thi của dự án thế nào? Tiến trình tìm ra các câu trả lời cho các câu hỏi này thuộc pha khởi đầu. Khảo sát thị trƣờng khơng phải là cơng việc của các kỹ sƣ phần mềm mà là cơng việc của chuyên gia khảo sát thị trƣờng và phân tích cạnh tranh. Họ cố gắng đánh giá việc xây dựng hệ thống phần mềm mới hay nâng cấp phần mềm cĩ sẵn cĩ kinh tế khơng, giúp các cơng ty xác định các ƣu, nhƣợc điểm. Cơng việc đầu tiên ở đây là hình dung bức tranh tổng quát của sản phẩm để dễ dàng nhận ra và tách các thành phần cho pha chi tiết. Theo E. Morel thì bức tranh này đƣợc mơ tả nhƣ sau: Bức tranh sản phẩm = Cái gì + Cho ai + Giá bao nhiêu trong đĩ, Cái gì muốn đề cập đến các đặc trƣng tơng thể về sản phẩm; Cho ai xác định khách hàng sử dụng sản phẩm và Giá bao nhiêu dự báo giá của mỗi sản phẩm mà ngƣời sử dụng cĩ thể chấp nhận. Thơng thƣờng phải xây dựng bản mẫu khái niệm cho pha khảo sát khả thi để đánh giá tính rủi ro của các chức năng phần mềm, sức mạnh và độ phức tạp của hệ thống, cơng nghệ mới sẽ áp dụng. Từ đĩ mà các quyết định về quan niệm sản phẩm đƣợc hình thành. Loại bản mẫu này khơng cần tuân thủ các quy luật phát triển phần mềm thơng thƣờng nhƣ độ tin cậy cao hay tốc độ xử lý phải nhanh. Đĩ chỉ là maket hệ thống, mã trình của nĩ sẽ khơng đĩng vai trị gì trong sản phẩm cuối cùng. Từ đây, tính rủi ro của dự án đƣợc nhận biết và pha khảo sát thì sẽ tiếp tục cố gắng đánh giá kinh phí cho dự án và lợi nhuận sẽ đem lại. Dự báo kinh phí luơn là cơng việc khĩ Phát triển phần mềm bằng UML trang | 21
23. khăn. Số liệu của dự báo ban đầu sẽ khơng bao giờ đúng, chỉ cĩ đƣợc số liệu đúng khi kết thúc phát triển hệ thống. Do vậy, việc dự báo này thƣờng đƣợc hiệu chỉnh dần dần trong nhiều bƣớc khác. Độ tin c ậ y c ủ a d ự báo Kinh phí th ự c t ế Độ chính xác c ủ a d ự báo Th ờ i gian Kh ỏ a sát Chi ti ết Xây d ựng Chuyể n giao khả thi Hình 1.9 Độ tin cậy của dự báo kinh phí dự án Với các dự án nhỏ, khảo sát khả thi thƣờng chỉ giới hạn bởi danh sách yêu cầu phần mềm. Với các dự án trung bình (thực hiện khoảng một năm) thì pha khảo sát khả thi sẽ thực hiện trong khoảng một tháng, bao gồm cả việc xây dựng maket. Với các dự án lớn, việc xây dựng maket cĩ thể là một dự án con và nĩ cũng cĩ các bƣớc thực hiện nhƣ mơ tả trên. Pha chi tiết. Pha chi tiết bắt đầu bằng phân tích yêu cầu và mơ hình hĩa lĩnh vực. Nĩ cĩ nhiệm vụ lựa chọn kiến trúc, làm giảm mức độ rủi ro của dự án, cuối cùng là xác định đƣợc kế hoạch đầy đủ cho các nhiệm vụ phát triển hệ thống phần mềm. Tham gia vào pha này bao gồm kiến trúc sƣ hệ thống, chuyên gia lĩnh vực, ngƣời sử dụng, đại diện của nhĩm kiểm tra chất lƣợng và thử nghiệm, ngƣời viết tài liệu, chuyên gia về các cơng cụ phát triển phần mềm. Phân tích yêu cầu đƣợc thực hiện trên cơ sở khảo sát các trƣờng hợp sử dụng. Các trƣờng hợp sử dụng đƣợc mơ tả theo khái niệm khách hàng, cĩ thể khác xa với hình thức mơ tả của kỹ nghệ phần mềm. Các phân tích viên cĩ nhiệm vụ chuyển đổi chúng sang hình thức gần máy tính hơn, thí dụ, chuyển đổi trƣờng hợp sử dụng sang cộng tác của các đối tƣợng trong lĩnh vực ứng dụng. Đĩ là các đối tƣợng trong thế giới thực, cơng tác với nhau để hình thành các chức năng trong trƣờng hợp sử dụng. Ngƣời sử dụng vẫn cĩ thể hiểu rõ trên hình thức biểu diễn này. Hình 1.10 là thí dụ về cài đặt trƣờng hợp sử dụng Bán hàng bằng ba đối tƣợng hợp tác là khách hàng, ngƣời bán hàng và xe ơ tơ. Phát triển phần mềm bằng UML trang | 22
24. Hình 1.10 Cài đặt trường hợp sử dụng Pha chi tiết cho lại các sản phẩm sau đây: Mơ tả hành vi hệ thống dƣới hình thức trường hợp sử dụng (use case), ngữ cảnh hệ thống, các tác nhân (ngƣời sử dụng hệ thống), các kịch bản ứng dụng và mơ hình các lớp ứng dụng. Với dự án trung bình thì cĩ thể bao gồm hàng chục trƣờng hợp sử dụng, khoảng 100 kịch bản chính, vài trăm kịch bản phụ và khoảng từ 50 đến 100 lớp lĩnh vực. Kiến trúc, tài liệu mơ tả kiến trúc, mơ tả rủi ro. Kế hoạch đầy đủ cho phát triển trong dự án. Kế hoạch chi tiết cho các vịng lặp, tiêu chí đánh giá, danh sách yêu cầu cho mỗi vịng lặp và kết quả cảu kiểm tra chất lƣợng. Cĩ thể bao gồm các bản thảo của tài liệu hƣớng dẫn sử dụng. Thời gian thực hiện pha chi tiết rất khác nhau trong từng dự án, nĩ phụ thuộc vào loại ứng dụng và cơ sở hạ tầng lựa chọn cho nĩ. Thí dụ, nếu dự án thực hiện trong một năm thì pha này sẽ kéo dài từ hai đến bốn tháng. Khơng nên đánh giá quá nhiều thời gian để cĩ đƣợc phân tích hồn hảo. Nên chuyển dần sang giai đoạn tiếp theo khi đã khảo sát khoảng 80% kịch bản chính. Khơng nên đi quá chi tiết khi khảo sát kịch bản để tránh việc mất đi tính trừu tƣợng trong giải pháp. Pha xây dựng. Pha xây dựng đề cập đến tiến trình phát triển và kiểm tra phần mềm. Pha xây dựng tƣơng ứng với triển khai các vịng lặp. Mỗi vịng lặp ở đây cho lại một mẫu khả thực ổn định, đầy đủ. Đĩ là những phiên bản đầu tiên của phần mềm. Việc cài đặt lặp bao gồm các hoạt động nhƣ sau: Nhận ra các kịch bản hồn chỉnh hay sử dụng lại trong vịng lặp trên cơ sở khảo sát các rủi ro và kết quả của vịng lặp trƣớc đĩ; giao nhiệm vụ cụ thể cho đội ngũ phát triển để hồn thiện vịng lặp; xác định tiêu chí đánh giá, vị trí kiểm tra và hạn định; tập hợp lại tài liệu ngƣời sử dụng và tài liệu triển khai. Pha xây dựng kết thúc khi hồn thiện phần mềm và đƣợc kiểm nghiệm. Phải đảm bảo rằng phần mềm đồng bộ với mơ hình. Với dự án nhỏ, pha xây dựng kéo dài từ hai đến ba tháng. Trong các nƣớc phát triển, dự án hƣớng đối tƣợng trung bình đƣợc thực hiện trong khoảng một năm với năm hay sáu nhân viên thì pha xây dựng chiếm từ sáu đến chín tháng. Với dự án lớn thì mỗi tiểu hệ đƣợc xem nhƣ dự án con và chúng cũng cĩ các vịng lặp riêng. Phát triển phần mềm bằng UML trang | 23
25. Pha chuyển giao. Pha chuyển giao bắt đầu khi sản phẩm phần mềm hồn thiện đƣợc chuyển đến cộng đồng ngƣời sử dụng. Mức độ phức tạp của pha này phụ thuộc vào các ứng dụng cụ thể. Pha chuyển giao bao gồm sản xuất hàng loại, vận chuyển, cài đặt, huấn luyện, hỗ trợ kỹ thuật và bảo trì. Tham gia vào pha này bao gồm một vài ngƣời từ đội ngũ phát triển và thử nghiệm chƣơng trình, kiến trúc sƣ hệ thống làm việc bán thời gian và ngƣời cĩ trách nhiệm cập nhật tài liệu. Nhân viên hỗ trợ kỹ thuật, nhân viên bán hàng, quảng cáo sẽ thực hiện việc kiểm tra. Trong pha chuyển giao, cơng việc phát triển phần mềm hầu nhƣ đã hồn thành. Mọi sản phẩm đều đạt tời mức chín muồi để cung cấp rộng rãi đến ngƣời quản lý dự án và ngƣời sử dụng. Ngƣời sử dụng sẽ đƣợc cung cấp: phiên bản beta và phiên bản cuối cùng của chƣơng trình khả thực; tài liệu hƣớng dẫn sử dụng, tài liệu triển khai và cài đặt. Ngƣời quản lý dự án đƣợc cung cấp: cĩ mơ hình hệ thống cuối cùng; tiêu chí đánh giá cho mỗi vịng lặp; mơ tả việc phân phối sản phẩm; kết quả của kiểm tra chất lƣợng và các kinh nghiệm rút rra từ thực hiện dự án. 1.5.2.4 - Phân bổ hoạt động trong các pha phát triển phần mềm Mỗi hoạt động phát triển phần mềm là khác nhau trong các pha phát triển. Khơng cĩ sự tƣơng ứng một – một giữa các pha dƣới gĩc nhìn hỗ trợ với các pha cổ điển của chu kỳ thác nước. Các hoạt động nhƣ phân tích, triển khai trải dài trên nhiều pha từ gĩc nhìn hỗ trợ. Các hoạt động dƣợc phân bổ giữa các chu kỳ, điểm bắt đầu và kết thúc của chúng khơng tƣơng ứng với các giới hạn các pha từ gĩc nhìn hỗ trợ (hình 1.11). Lập kế hoạch Phân tích Kiến trúc Lập trình Phát triển phần mềm bằng UML trang | 24
26. Bảo trì Thử nghiệm Hình 1.11 Sơ đồ các pha phát triển phần mềm Sơ đồ trên hình 1.11 cho ta thấy: Kế hoạch thực hiện trong các pha phát triển. Cơng việc phân tích đƣợc thực hiện chủ yếu trong pha chi tiết, một phần của nĩ đƣợc thực hiện trong pha khảo sát khả thi và pha xây dựng. Phần lớn kiến trúc đƣợc xác định trong pha chi tiết. Việc viết mã trình (bao gồm cả thử nghiệm các modun) bắt đầu từ pha chi tiết và đƣợc thực hiện trong tồn bộ pha cài đặt. Việc bảo trì đƣợc xác định ngay từ phiên bản đầu tiên của phân mềm, thơng thƣờng nĩ bắt đầu trong pha chi tiết. Thử nghiệm và kiểm tra chất lƣợng trả dài suốt tồn bộ các pha và áp dụng cho mọi bản mẫu chƣơng trình. Quản lý sự thay đổi (phiên bản và cấu hình) lƣu trữ lịch sử tồn bộ dự án. Dãy số bên phải hình 1.11 thể hiện phân bổ cơng sức thực hiện các hoạt động của một dự án phát triển phần mềm hƣớng đối tƣợng do năm nhân viên thực hiện trong khoảng một năm. Các hoạt động đĩ bao gồm: Lập kế hoạch: bao gồm các hoạt động thí điểm dự án, kế hoạch phát triển quản lý các tài nguyên dự án. Phân tích: Bao gồm phát triển mơ hình đối tƣợng và mơ hình ngƣời sử dụng, đặc tả tổng thể về dự án, mơ tả các tiêu chí đánh giá. Kiến trúc: bao gồm viết mã trình cơ sở, thiết kế tổng quan về ứng dụng và xây dựng cơ chế chung Cài đặt: Nhĩm tồn bộ thiết kế chi tiết, viết mã trình và kiểm tra các mođun chƣơng trình. Thử nghiệm và đánh giá: Bao gồm các hoạt động chứng minh rằng phần mềm phù hợp với mục tiêu ban đầu và các tiều chí đánh giá. Quản lý thay đổi: Lƣu trữ trạng thái kết quả của các giai đoạn phát triển. Các dãy số phía dƣới hình 1.11 chỉ ra phân bố cơng sức và thời gian cho các pha phát triển phần mềm của một dự án cỡ trung bình. Chính bản thân Ngơn ngữ mơ hình hĩa trực quan UML khơng định nghĩa tiến trình phát triển phần mềm, nhƣng UML và phần mềm cơng cụ Rational Rose (cịn gọi tắt là Rose) đƣợc sử dụng cĩ hiệu quả trong một số cơng đoạn của tiến trình phát triển phần mềm. Khi bắt đầu dự án, trong pha khảo sát khả thi, Rose đƣợc sử dụng để phát sinh mơ hình trƣờng hợp sử dụng. Trong pha chi tiết, Rose đƣợc sử dụng đễ xây dựng biểu đồ trình tự và biểu đồ cộng tác, chỉ ra các đối tƣợng tƣơng tác với nhau nhƣ thế nào. Biểu đồ lớp đƣợc xây dựng trong Rose để thấy sự phụ thuộc vào nhau của các đối tƣợng. Trong giai đoạn đầu của pha xây dựng, biểu đổ thành phần đƣợc hình thành Phát triển phần mềm bằng UML trang | 25
27. nhờ Rose để chỉ ra sự phụ thuộc của các thành phần trong hệ thống và cho ta khả năng phát sinh mã trình cơ bản. Trong suốt pha xây dựng, Rose cho ta khả năng chuyển đổi ngƣợc mã trình thành mơ hình để tích hợp mọi sự thay đổi trong quá trình phát triển. Trong pha chuyển giao, Rose đƣợc sử dụng để cập nhật các mơ hình đƣợc tạo lập ra cho dự án. Phát triển phần mềm bằng UML trang | 26
28. CHƢƠNG 2 KHÁI QUÁT VỀ UML UML là ngơn ngữ mơ hình hĩa, trƣớc hết nĩ là mơ tả ký pháp thống nhất, ngữ nghĩa và các định nghĩa về metamodel (mơ tả định nghĩa chính ngơn ngữ mơ hình hĩa), nĩ khơng mơ tả về phƣơng pháp phát triển. UML đƣợc sử dụng để hiển thị, đặc tả, xây dựng và làm tài liệu các vật phẩm (artifacts) của phân tích quá trình xây dựng hệ thống phần mềm theo hƣớng đối tƣợng. UML đƣợc sử dụng cho mọi tiến trình phát triển phần mềm, xuyên suốt vịng đời phát triển và độc lập với các cơng nghệ cài đặt hệ thống. 2.1 GIỚI THIỆU UML UML là ngơn ngữ chuẩn để viết kế hoạch chi tiết phần mềm. Nĩ phù hợp cho việc mơ hình hĩa các hệ thống nhƣ hệ thơng tin doanh nghiệp, các ứng dụng phân tán trên nền Web, hệ thơng nhúng thời gian thực Các khung nhìn của ngơn ngữ đƣợc quan sát từ gĩc độ phát triển và triển khai hệ thống, nĩ khơng khĩ hiểu và dễ sử dụng. UML là ngơn ngữ mơ hình đƣợc cả con ngƣời và máy sử dụng. Nhớ lại rằng phƣơng pháp là cách cấu trúc rõ ràng suy nghĩ và hành động của ai đĩ. Phƣơng pháp cho ngƣời sử dụng biết làm cái gì, làm nhƣ thế nào, khi nào làm việc đĩ và tại sao lại làm nhƣ vậy. Phƣơng pháp chứa mơ hình và các mơ hình này đƣơc sử dụng để mơ tả cái gì đĩ. Sự khác nhau chủ yếu của phƣơng pháp và ngơn ngữ mơ hình hĩa là ngơn ngữ mơ hình hĩa thiếu tiến trình cho biết làm cái gì, làm nhƣ thế nào, khi nào làm việc đĩ và tại sao lại làm nhu vậy. Nhƣ mọi ngơn ngữ mơ hình hĩa khác, UML cĩ ký pháp (các biểu tƣợng sử dụng trong mơ hình) và tập các luật sử dụng nĩ. Các luật bao gồm cú pháp, ngữ nghĩa và pragmatic (luật hình thành câu cĩ nghĩa). Cần chú ý rằng ngay cả khi nắm chắc ngơn ngữ UML, khơng cĩ gì đảm bảo sẽ cĩ mơ hình tốt. Tƣơng tự nhà văn viết tiểu thuyết bằng ngơn ngữ tự nhiên, ngơn ngữ chỉ là cơng cụ, cịn tiểu thuyết cĩ hay hay khơng là phục thuộc hồn tồn vào nhà văn. Để sử dụng UML cĩ hiệu quả, địi hỏi phải hiểu đƣợc ba vấn đề chính sau [BRJ99] Các phần tử cơ bản của mơ hình UML Các qui định liên kết các phần tử mơ hình Một số cơ chế chung áp dụng cho ngơn ngữ này. UML là ngơn ngữ và nĩ chỉ là một phần của tiến trình phát triển phần mềm, độc lập với tiến trình. Tuy nhiên UML rất phù hợp với các tiến trình hƣớng trường hợp sử dụng (Use case – UC), lấy kiến trúc làm trung tâm, tƣơng tác tăng dần. 2.1.1.1 - UML là ngơn ngữ Ngơn ngữ phải cĩ từ vựng và qui tắc tổ hợp các từ trong từ vựng để giao tiếp. Ngơn ngức mơ hình là ngơn ngữ cĩ từ vựng và qui tắc tập trung vào biểu diễn về mặt vật lý và khái niệm của hệ thống. UML là ngơn ngữ chuẩn cơng nghiệp để lập kế hoạch chi tiết phần mềm. Nhƣ đã trình bày trong chƣơng trƣớc, khơng cĩ mơ hình nào là thỏa mãn cho tồn bộ hệ thống. Thơng thƣờng ta phải xây dựng nhiều mơ hình cho một hệ thống, do vậy ngơn ngữ phải cho phép biểu diễn nhiều khung nhìn (views) khác nhau của một kiến trúc hệ thống trong suốt quá trình phát triển phần mềm. Từ vựng và qui tắc ngơn ngữ UML cho ta cách thức xây dựng mơ hình và đọc mơ hình, nhƣng khơng cho biết mơ hình nào cần phải đƣợc lập và khi nào lập chúng. Nhiệm vụ đĩ Phát triển phần mềm bằng UML trang | 27
29. đƣợc xác định nhờ qui trình phát triển phần mềm. Qui trình phát triển phần mềm sẽ giúp chúng ta đƣa ra quyết định hình thành vật phẩm nào, hoạt động nào và nhân viên nào sẽ tạo ra, sử dụng và quản lý chúng. Đồng thời chúng đƣợc sử dụng nhƣ thế nào vào việc quản lý tồn bộ dự án. 2.1.1.2 - UML là ngơn ngữ để hiển thị Với nhiều lập trình viên, khơng cĩ khoảng cách từ ý tƣởng đến cài đặt mã trình. Họ suy nghĩ vấn đề và viết ngay mã trình cho nĩ. Thực tế là cĩ thể trực tiếp viết mã trình cho một số việc, trực tiếp mơ tả thuật tốn và biểu thức bằng văn bản. Tuy nhiên, việc giao tiếp giữa mơ hình khái niệm với những cái khác trong vịng đời phát triển phần mềm sẽ khĩ khăn khi mọi ngƣời khơng sử dụng chung một ngơn ngữ cho dự án. Nếu dự án hay tổ chức nào đĩ đƣa ra ngơn ngữ riêng của họ thì ngƣời mới tham gia dự án sẽ gặp rất nhiều khĩ khăn. Hơn nữa, một số vấn đề của hệ thống phần mềm sẽ đƣợc hiểu rõ ràng hơn thơng qua mơ hình thay cho ngơn ngữ lập trình văn bản. Thí dụ, cĩ thể suy luận ra ý nghĩa phân cấp lớp nhƣng khơng thể hiểu thấu đáo nếu bắt đầu trực tiếp bằng mã trình của lớp trong phân cấp. Tƣơng tự, ta khơng thể hiểu rõ hệ thống trên nền Web nếu khơng cĩ mơ hình. UML giúp xây dựng mơ hình để dễ dàng giao tiếp. Một số cơng việc phù hợp với mơ hình hĩa băng văn bản, một số cơng việc khác lại phù hợp hơn với mơ hình hĩa bằng đồ họa. UML là ngơn ngữ đồ họa. Với nhiều hệ thống, mơ hình trong ngơn ngữ đồ họa dễ hiểu hơn so với ngơn ngữ lập trình. Sau mỗi biểu tƣợng đồ họa của ngơn ngữ UML là ngữ nghĩa. Vậy, khi xây dựng mơ hình trong UML thì ngƣời phát triển khác hay các cơng cụ hỗ trợ mơ hình hĩa cĩ thể hiểu mơ hình một cách rỗ ràng. 2.1.1.3 - UML làn ngơn ngữ đặc tả Đặc tả là mơ tả rõ ràng những điểm mấu chốt của vấn đề. UML cho phép mơ tả mơ hình chính xác, khơng nhập nhằng và hồn thiện. UML hƣớng tới đặc tả thiết kế, phân tích và quyết dịnh cái đặt trong quá trình phát triển và triển khai hệ thống phần mềm. 2.1.1.4 - UML là ngơn ngữ đễ xây dựng UML là khơng phải là ngơn ngữ lập trình trực quan, nhƣng mơ hình của nĩ cĩ thể kết nối trực tiếp tới các ngơn ngữ lập trình khác nhau. Cĩ nghĩa rằng cĩ thể ánh xạ mơ hình trong UML tới các ngơn ngữ lập trình khác nhau nhƣ Java, C++ hay các bảng CSDL quan hệ, CSDL hƣớng đối tƣợng. Ánh xạ này cho khả năng biến đổi thuận từ mơ hình UML sang ngơn ngữ lập trình. Đồng thời, cho khả năng biến đổi ngƣợc lại từ cài đặt về mơ hình UML; cĩ nghĩa rằng nĩ cho khả năng làm việc với văn bản hay đồ họa một cách nhất quán. 2.1.1.5 - UML là ngơn ngữ tài liêu UML hƣớng tới làm tài liệu kiến trúc hệ thống và các chi tiết của nĩ. UML cho khả năng biểu diễn yêu cầu, thử nghiệm, mơ hình hĩa các hoạt động lập kế hoạch và quản lý sản phẩm. UML cho biết giới hạn của hệ thống và các chức năng chính của nĩ thơng qua UC và tác nhân. Trong UML, các UC đƣợc mơ tả bằng biểu đồ logic Biểu diễn cấu trúc tĩnh của hệ thống nhờ biểu đồ lớp Phát triển phần mềm bằng UML trang | 28
30. Mơ hình hĩa các hành vi đối tƣợng bằng biểu đồ chuyển trạng thái Phản ảnh kiến trúc cài đặt vật lý bằng biểu đồ thành phần và biểu đồ triển khai Mở rộng các chức năng bằng stereotypes 2.2 MƠ HÌNH KHÁI NIỆM CỦA UML Để hiểu đƣợc UML ta phải hình dung đƣợc mơ hình khái niệm của ngơn ngữ. Nĩ địi hỏi nắm đƣợc ba vấn đề chính, bao gồm các phần tử cơ bản để xây dựng mơ hình, quy tắc liên kết các phần tử mơ hình và một số cơ chế chung sử dụng cho ngơn ngữ. Khi nắm vững đƣợc các vấn đề này thì ta cĩ thể đọc đƣợc mơ hình UML và tạo ra một vài mơ hình cơ bản. 2.2.1 - Phần tử mơ hình trong UML Các khối hình thành mơ hình UML gồm ba loại nhƣ sau: phần từ, quan hệ và biểu đồ. Phần tử là trừu tƣợng căn bản trong mơ hình, các quan hệ gắn các phần tử này lại với nhau; cịn biểu đị nhĩm tập hợp các phần tử. Trong UML cĩ bốn loại phần tử mơ hình, đĩ là cấu trúc, hành vi, nhĩm và chú thích. Các phần tử này là các khối để xây dựng hƣớng đối tƣợng cơ bản của UML. 2.2.1.1 - Phần tử cấu trúc Phần từ cấu trúc là các danh từ trong mơ hình UML. Chúng là bộ phận tĩnh của mơ hình để biểu diễn các thành phần khái niệm hay vật lý. Cĩ bảy loại phẩn tử cấu trúc nhƣ mơ tả sau đây: Lớp. Lớp mơ tả tập các đối tƣợng cùng chung thuộc tinh, thao tác, quan hệ và ngữ nghĩa. Một lớp cài đặt một hay nhiều ghép nối. Hình 2.1 biểu diễn đồ họa lớp bằng hình chữ nhật, thơng thƣờng chú cĩ tên, thuộc tính và thao tác. Giao diện. Giao diện là tập hợp các thao tác làm dịch vụ của lớp hay thành phần. Giao diện mơ tả hành vi thấy đƣợc từ ngồi của thành phần. Giao diện biểu diễn tồn bộ hay một phần hành vi của lớp. Giao diện định nghĩa tập đặc tả thao tác chứ khơng định nghĩa cài đặt của chúng. Ký pháp đồ họa của nĩ đƣợc mơ tả trên hình 2.2. Giao diện thƣờng khơng đứng một mình mà đƣợc gắn vào lớp hay thành phần thực hiện giao diện. Window Origin Open() Close() Interface Hình 2.1 Lớp Hình 2.2 Giao diện Phát triển phần mềm bằng UML trang | 29
31. Phần tử cộng tác. Phần tử cộng tác là mơ tả ngữ cảnh của tƣơng tác. Ký pháp đồ họa của nĩ là hình elíp với đƣờng vẽ nét đứt, kèm theo tên nhƣ trên hình 2.3. Phần tử cộng tác thể hiện một giải pháp thi hành bên trong hệ thống, bao gồm các lớp, quan hệ và tƣơng tác giữa chúng để đạt đƣợc một chức năng mong đợi của UC. Hình 2.3 Cộng tác Hình 2.4 Use case Trƣờng hợp sử dụng (Use case). Mơ tả chình tự các hành động mà hệ thống sẽ thực hiện để đạt đƣợc một kết quả cho tác nhân nào đĩ. Tác nhân là những gì bên ngồi tƣơng tác với hệ thống. Tập hợp các UC của hệ thống sẽ hình thành các trƣờng hợp mà hệ thống đƣợc sử dụng. Sử dụng UC để cấu trúc các phần tử cĩ tính hành vi trong mơ hình. Nĩ đƣợc hiện thực hĩa bởi phần tử cộng tác nhƣ vừa mơ tả trên. Hình 2.4 là ký pháp đồ họa của UC. Lớp tích cực (active class). Lớp tích cực là lớp cĩ đối tƣợng làm chủ một hay nhiều lớp tiến trình hay luồng. Lớp tích cực đƣợc xem nhƣ lớp thơng thƣờng nhƣng đối tƣợng của nĩ biểu diễn các thành phần cĩ hành vi đang tƣơng tranh với các thành phần khác. Ký pháp đồ họa của nĩ tƣơng tự lớp thơng thƣờng nhƣng biên chữ nhật đƣợc tơ đậm. Thơng thƣờng chúng cũng cĩ tên, thuộc tính và thao tác. Thành phần. Thành phần biểu diễn vật lý mã nguồn, các tệp nhị phân trong quá trình phát triển hệ thống. Ký pháp đồ họa của nĩ đƣơc biểu diễn trên hình 2.5 Nút (node). Nút là thể hiện thành phần vật lý, tồn tại khi chƣơng trình chạy và biểu diễn các tài nguyên tính tốn. Cĩ thể đặt tập các thành phần trên nút chuyển từ nút này sang nút khác. Nút cĩ thể là máy tính, thiết bị phần cứng. Ký pháp đồ họa của chúng đƣợc mơ tả trên hình 2.6. Ma y chu Myfile .cpp Hình 2.5 Cộng tác Hình 2.6 Use case 2.2.1.2 - Phần tử hành vi Phần tử hành vi là bộ phận động của mơ hình UML. Chúng là các động từ của mơ hình, biểu diễn hành vi theo thời gian và khơng gian. Cĩ hai loại chính là tƣơng tác và trạng thái. Tƣơng tác. Tƣơng tác là hành vi bao gồm tập các thơng điệp trao đổi giữa các đối tƣợng trong ngữ cảnh cụ thể để thực hiện mục đích cụ thể. Hành vi của nhĩm đối tƣợng hay của mỗi thao tác cĩ thể đƣợc chỉ ra bằng tƣơng tác. Biểu diễ đồ họa của thơng điệp đƣợc thể hiện nhƣ trên hình 2.7, bao gồm mũi tên và tên thao tác của nĩ. Phát triển phần mềm bằng UML trang | 30
32. Ch ờ Hiển thị Hình 2.7 Thơng điệp Hình 2.8 Trạng thái Máy trạng thái. Máy trạng thái là hành vi chỉ ra trật tự các trạng thái mà đối tƣợng hay tƣơng tác sẽ đi qua để đáp ứng sự kiện. Hành vi của lớp hay cộng tác của lớp cĩ thể đƣợc xác định bằng máy trạng thái. Máy trạng thái kích hoạt nhiều phần tử, bao gồm trạng thái, chuyển tiếp (từ trạng thái này sang trạng thái khác), sự kiện và các hoạt động (đáp ứng sự kiện). Ký pháp đồ họa của trạng thái đƣợc thể hiện trên hình 2.8, nĩ chứa tên và trạng thái con nếu cĩ. 2.2.1.3 - Phần tử nhĩm Phần tử nhĩm là bộ phận tổ chức của mơ hình UML. Chỉ cĩ một phần tử thuộc nhĩm này cĩ tên là gĩi (package). Gĩi là cơ chế đa năng để tổ chức các phần tử vào nhĩm. Các phần tử cấu trúc, hành vi và ngay cả phần tử nhĩm cĩ thể cho vào gĩi. Khơng giống thành phần (component), phần tử nhĩm hồn tồn là khái niệm, cĩ nghĩa rằng chúng chỉ tồn tại vào thời điểm phát triển hệ thống chứ khơng tồn tại vào thời gian chạy chƣơng trình. Ký pháp đồ họa của nhĩm đƣợc biểu diễn trên hình 2.9. gĩi giúp ta quan sát hệ thống ở mức tổng quan hơn. Chú thích (annotaitonal) Phần tử chú thích là bộ phận chú giải của mơ hình UML. Đĩ là lời giải thích áp dụng để mơ tả các phần tử khác trong mơ hình. Phần tử chú thích đƣợc gọi là ghi chú (note). Ký pháp đồ họa của chúng thể hiện trên hình 2.9 Các lu ậ t th ƣơ ng mạ i Đây là chú thích Hình 2.9 Nhĩm và lời ghi chú 2.2.2 - Các quan hệ trong UML Cĩ bốn loại quan hệ trong UML, bao gồm quan hệ phụ thuộc, kết hợp, khai quát và hiện thực hĩa. Chúng là cơ sở đễ xây dựng mọi quan hệ trong UML. Phụ thuộc (dependency). Phục thuộc là quan hệ ngữ nghĩa hai phần tử trong đĩ thay đổi phần tử độc lập sẽ tác động đến ngữ nghĩa của phần tử phục thuộc. Ký pháp đồ họa của nĩ đƣợc thể hiện trên hình 2.10. 0 1 . Ơng chủ Nhân viên Hình 2.10 Cộng tác Hình 2.11 Use case Phát triển phần mềm bằng UML trang | 31
33. Kết hợp (association). Kết hợp là quan hệ cấu trúc để mơ tả tập liên kết (một liên kết là kết nối giữa các đối tƣợng). Khi đối tƣợng của lớp này gửi/nhận thơng điệp đến/từ đối tƣợng của lớp kia thì ta gọi chúng là cĩ quan hệ kết hợp. Ký pháp đồ họa của kết hợp đƣợc mơ tả trên hình 2.11 chúng cĩ thể chứa tên nhiệm vụ và tính nhiều (multiplicity). Tụ hợp (aggregation) là dạng đặc biệt của kết hợp, nĩ biểu diễn quan hệ cấu trúc giữa tồn thể và bộ phận. Ký pháp đồ họa của nĩ trên hình 2.12. một dạng dặc biệt của tập hợp là quan hệ hợp thành (composition), trong đĩ nếu nhƣ đối tƣợng tồn thể bị hủy bỏ thì các đối tƣợng bộ phận của nĩ cũng bị hủy bỏ theo. Biểu diễn đồ họa của tập hợp nhƣ trên hình 2.13. Hình 2.12 Tụ hợp Hình 2.13 Use case Khái quát hĩa (generalization). Khái quát hĩa là quan hệ đặc biệt hĩa/ khái quát hĩa mà trong đĩ đối tƣợng cụ thể sẽ kế thừa các thuộc tính và phƣơng pháp của đối tƣợng tổng quát. Ký pháp đồ họa của khái quát hĩa đƣợc mơ tả trên hình 2.14. Hình 2.14 Khái quát hĩa Hình 2.4 Hiện thực Hiện thực hĩa (realization). Hiện thực hĩa là quan hệ ngữ nghĩa giữa giao diện và lớp (hay thành phần) hiện thực lớp; giữa UC và hợp tác hiện thực UC. Biểu diễn đồ họa của nĩ dƣợc mơ tả trên hình 2.15. 2.2.3 - Kiểu dữ liệu Kiểu dữ liệu khơng phải là phần tử mơ hình trong UML. Kiểu dữ liệu cơ sở là kiểu dữ liệu khơng cĩ cấu trúc. UML cĩ các kiểu dữ liệu sau: Boolean: là kiểu đếm với hai giá trị True và False Biểu thức (Expression): là xâu ký tự cĩ cú pháp Tính nhiều (Multiplicity): là tập khơng rỗng của các số nguyên dƣơng và ký tự * (để biểu thị tính nhiều vơ hạn). Tên (Name): là xâu ký tự cho khả năng đặc tả phẩn tử. Số nguyên (Integer): là kiểu cơ bản và là phần tử của tập vơ hạn các sơ nguyên âm và dƣơng. Xâu (String): là trật tự cảu các ký tự, đƣợc sử dụng là tên. Thời gian (Time): xâu ký tự biểu dirn giá trị tuyệt đối hay khoảng tƣơng tƣơng đối. Khơng lý giải (Uninterpreted): là „cái gì đĩ‟ mà ý nghĩa của nĩ phụ thuộc và lĩnh vực. 2.2.4 - Biểu đồ UML Biểu đồ là biểu diễn đồ họa tập hợp các phần tử mơ hình. Vẽ biểu đồ để biểu diễn hệ thống đang xây dựng dƣới các gĩc độ quan sát khác nhau. Cĩ thể hiểu biểu đồ là ánh xạ của hệ thống. Một phần tử cĩ thể xuất hiện trong một hay nhiều biểu đồ. Về lý Phát triển phần mềm bằng UML trang | 32
34. thuyết thì biểu đồ cĩ thể bao gồm tổ hợp vơ số phần từ đồ họa và quan hệ vừa mơ tả trên. UML cho khả năng xây dựng một vài kiểu biểu đồ trực quan để biểu diễn các khía cạnh khác nhau của hệ thống, bao gồm biểu đồ trƣờng hợp sử dụng (use case diagram), biểu đồ trình tự (sequence diagram), biểu đồ cộng tác (collaboration diagram), biểu đồ lớp (class diagram), biểu đồ biến đổi trạng thái (state transition diagram), biểu đồ thành phần (component diagram) và biểu đồ triển khai (deployment diagram). Các loại biểu đồ nay sẽ đƣợc giới thiệu tĩm tắt dƣới đây thơng qua ví dụ về xây dựng phần mềm cho hệ thống máy rút tiền tự động (Automated Teller Machine – ATM). Giả sử rằng ta cĩ các máy rút tiền tự động ATM đặt tại các đƣờng phố khác nhau trong thành phố. Chúng đƣợc nối với máy tính trung tâm tại trụ sở ngân hàng thơng qua hệ thống mạng máy tính. Máy tính trung tâm lƣu trữ và quản trị CSDL khách hàng, xử lý một số cơng việc chuyên ngành và yêu cầu ATM trả tiền. Máy rút tiền tự động bao gồm máy đọc thẻ từ, màn hình và bàn phím để tƣơng tác với ngƣời sử dụng. 2.2.4.1 - Biểu đồ trường hợp sử dụng (Use case – UC) Biểu đồ này chỉ ra tƣơng tác giữa các UC và tác nhân. UC biểu diễn các chức năng hệ thống. Tác nhân là con ngƣời hay hệ thống khác cung cấp hay thu nhận thơng tin từ hệ thống đang đƣợc xây dựng. Biểu đồ UC tập trung vào quan sát trạng thái tĩnh của các UC trong hệ thống. Vì UC biểu diễn yêu cầu hệ thống từ gĩc độ ngƣời dùng, cho nên UC là chức năng mà hệ thống phải cĩ. Biểu đồ loại này chi ra tác nhân nào khởi động UC và khi nào tác nhân nhận thơng tin từ hệ thống. Biểu đồ trên hình 2.16 chỉ ra tƣơng tác giữa các UC và tác nhân của hệ thống rút tiền tự động ATM. Khách hàng (là tác nhân) cĩ khả năng khởi động một số UC nhƣ Rút tiền, Gửi tiền, Chuyển tiền, Xem số dư tài khoản, Thay đổi số căn cước cá nhân (PIN) và Thanh tốn. Nhân viên ngân hàng (là tác nhân khác) cĩ khả năng khởi động UC với Thay đổi số căn cước cá nhân. Trƣờng hợp sử dụng Thanh tốn cĩ mũi tên đi đến Hệ thống tín dụng. Hệ thống ngồi cĩ thể là tác nhân, thí dụ Hệ thống tín dụng là hệ thống ở bên ngồi hệ thống ATM, do vậy nĩ là tác nhân. Mũi tên đi từ UC đến tác nhân cho biết UC phát sinh thơng tin để tác nhân sử dụng (UC trả lại thơng tin cho tác nhân). Chuyển tiền Gửi tiền Thay đổi PIN Nhân viên ngân hàng Khách hàng Rút tiền Thanh toán Hệ thống tín dụng Xem số dư Hình 2.16 Biểu đồ UC của ATM Phát triển phần mềm bằng UML trang | 33
35. Biểu đồ UC chỉ ra chức năng tổng thể của hệ thống đang phát triển. Khách hàng, quản lý dự án, phân tích viên, lập trình viên, kỹ sƣ kiểm tra chất lƣợng và những ai quan tâm tổng thể đến hệ thống đều cĩ thể biết đƣợc hệ thống sẽ hỗ trợ gì thơng qua biểu đồ này. Máy đọc thẻ Màn hình Tài khoản Máy trả tiền Văn : Khách ATM ông Văn mặt hàng 1: Chấp nhận thẻ 2: Đọc số thẻ 3: Khởi động màn hình 4: Mở tài khoản 5: Yêu cầu vào PIN 6: Nhập PIN (1234) 7: Kiểm tra PIN 8: Yêu cầu giao dịch 9: Chọn giao dịch rút tiền 10: Yêu cầu nhập số tiền 11: Nhập số tiền (100000đ) 12: Rút tiền (100000đ) 13: Kiểm tra tài khoản (100000đ) 14: Giảm tài khoản (100000đ) 15: Trả tiền (100000đ) 16: Trả biên nhận 17: Đẩy thẻ ra Hình 2.17 Biểu đồ trình tự của hệ thơng ATM 2.2.4.2 - Biểu đồ trình tự (sequence) Biểu đồ trình tự chỉ ra luồng chức năng xuyên qua các UC, nĩ là biểu đồ mơ tả tƣơng tác giữa các đối tƣợng và tập trung vào mơ tả trật tự các thơng điệp theo thời gian. Thí dụ trƣờng hợp sử dụng Rút tiền cĩ thể cĩ nhiều trình tự nhƣ khách hàng yêu cầu rút tiền khi đã hết tiền trong tài khoản, khi khách hàng nhập nhầm PIN hay trƣờng hợp hoạt động bình thƣờng. Hình 2.17 là thí dụ kịch bản bình thƣờng (nhập dúng PIN, số tiền trong tài khoản đủ số lƣợng yêu cầu rút). Tác nhân tác động UC này đƣợc hiển thị trên đỉnh biểu đồ, thí dụ tác nhân khách hàng trên hình 2.16. Các đối tƣợng mà hệ thống cần để thực hiện UC Rút tiền cũng đƣợc đặt trên đỉnh biểu đồ. Mỗi mũi tên trong biểu đồ thể hiện thơng điệp truyền giữa tác nhân và đối tƣợng hay đối tƣợng với đối tƣợng để thực hiện chức năng cụ thể. Chú ý rằng biểu đồ Phát triển phần mềm bằng UML trang | 34
36. trình tự hiển thị phần tử mơ hình đối tƣợng chứ khơng phải lớp. Thí dụ, biểu đồ này hiển thị tên khách hàng cụ thể (ơng Văn) thay cho hiển thị lớp Khách hàng. UC rút tiền bắt đầu khi khách hàng bỏ thẻ tín dụng vào máy đọc thẻ. Máy đọc thẻ là đối tƣợng đƣợc chỉ ra trong hình chữ nhật trên đỉnh biểu đồ. Sau đĩ máy đọc thẻ sẽ đọc số thẻ tín dụng, mở đối tƣợng tài khoản của ơng Văn và khởi động màn hình của hệ thống ATM. Màn hình hiển thị dấu nhắc để nhập số hiệu khách hàng (PIN). Thí dụ, khách hàng nhập số PIN 1234. Màn hình kiểm tra PIN với đối tƣợng tài khoản và thấy phù hợp. Màn hình hiển thị các chức năng để ơng Văn lựa chọn. Ơng ta chọn chức năng Rút tiền. Màn hình hiển thị dấu nhắc để ơng Văn nhập số tiền sẽ rút. Ơng ta nhập số tiền rút 100000đ. Màn hình thực hiện rút tiền từ tài khoản cĩ đủ 100000đ? Giảm số dƣ trong tài khoản đi 100000đ. Yêu cầu máy trả tiền chi trả 100000đ tiền mặt và in ra biên nhân. Cuối cùng yêu cầu máy đọc thẻ trả lại thẻ tín dụng cho ơng Văn. Biểu đồ trình tự trên đây mơ tả tồn bộ luồng sử lý cho UC rút tiền thơng qua thí dụ trƣờng hợp ơng Văn rút 100000đ. Khách hàng cĩ thể thấy đƣợc tiến trình tác nghiệp cụ thể của họ thơng qua biểu đồ. Phân tích viên thấy đƣợc luồng tiến trình, ngƣời phát triển thấy đƣợc các đối tƣợng cần xây dựng và các thao tác cho các đối tƣợng này, kỹ sƣ kiểm tra chất lƣợng cĩ thể thấy chi tiết của tiến trình đễ xây dựng qui trình thử nghiệm, kiểm tra. Biểu đồ trình tự cĩ ích cho mọi ngƣời tham gia dự án. 2.2.4.3 - Biểu đồ cộng tác (Collabaration) Biểu đồ cộng tác chỉ ra các thơng tin nhƣ biểu đồ trình tự theo cách khác, nĩ tập trung vào tổ chức cấu trúc của các đối tƣợng gửi và nhận thơng điệp. Hình 2.18 là thí dụ biểu đồ cộng tác của biểu đồ trình tự tƣơng ứng mơ tả trên hình 2.17. Biểu đồ cộng tác và biểu đồ trình tự thuộc loại biểu đồ tƣơng tác và chúng cĩ thể biến đổi qua lại. Trong biểu đồ cộng tác, đối tƣợng đặt trong chữ nhật, tác nhân là ngƣời hình cây nhƣ trong biểu đồ trình tự. Trong khi biểu đồ trình tự biểu diễn tƣơng tác đối tƣợng và tác nhân theo thời gian thì biểu đồ cộng tác lại khơng quan tâm đến thời gian. Thí dụ trên hình 2.18 cho thấy máy đọc thẻ ra lệnh mở tài khoản ơng Văn, đối tƣợng tài khoản của ơng Văn ra lệnh máy đọc trả lại thẻ tín dụng. Các đối tƣợng giao tiếp trực tiếp với nhau đƣợc thể hiện bằng đƣờng nối. Phát triển phần mềm bằng UML trang | 35
37. 6: Nhập PIN 9: Chọn giao dịch (Rút tiền) 11: Nhập tổng tiền (100000đ) Màn hinh ATM 5: Yêu câu nhập PIN Văn : Khách 8: Yêu câu giao dịch 7: Kiểm tra PIN hàng 10: Yêu câu nhập số tiền 12: Rút tiền (100000đ) 1: Chấp nhận thẻ 13: Kiểm tra tài khoản 14: Giảm tài khoản 2: Đọc số thẻ 3: Khởi dộng màn hinh 4: Mở tài khoản Tài khoản Máy đọc ông Văn thẻ 17: Trả thẻ tín dụng 15: Trả tiền (100000đ) 16: Trả biên nhận Máy trả tiền Hình 2.18 Sơ đồ cộng tác ơng Văn rút 100000đ Tuy rằng biểu đồ cộng tác cùng chỉ ra các thơng tin nhƣ biểu đồ trình tự, nhƣng biểu đồ cộng tác đƣợc sử dụng vì lý do khác. Kỹ sƣ kiểm tra chất lƣợng và kiến trúc sƣ hệ thống thấy đƣợc việc phân bổ tiến trình giữa các đối tƣợng thơng qua biểu đồ loại này. Thí dụ, nếu biểu đồ cộng tác cĩ hình dạng nhƣ ngơi sao, với nhiều đối tƣợng giao tiếp với đối tƣợng trung tâm thì kiến trúc sƣ cĩ thể kết luận rằng hệ thống quá phục thuộc vào một đối tƣợng và họ sẽ đi thiết kế lại phân bổ tiến trình để nâng cao hiệu suất hệ thống. 2.2.4.4 - Biểu đồ lớp (class) Biểu đồ lớp chỉ ra tƣơng tác giữa các lớp trong hệ thống. Các lớp đƣợc xem nhƣ kế hoạch chi tiết của các đối tƣợng. Tài khoản ơng Văn là đối tƣợng; Tài khoản là lớp. Lớp Tài khoản chứa PIN khách hàng và hành vi Kiểm tra PIN. Mỗi lớp trong biểu đồ lớp đƣợc tạo ra cho mỗi loại đối tƣợng trong biểu đồ trình tự và cộng tác. Thí dụ biểu đồ lớp cho UC Rút tiền đƣợc mơ tả trên hình 2.19 Phát triển phần mềm bằng UML trang | 36
38. Máy đọc thẻ Màn hinh ATM Số thẻ Chấp nhận thẻ() Nhận đầu vào() Trả thẻ() Dấu nhắc() Đọc thẻ() Tài khoản Số tài khoản PIN Máy trả tiền Số dư Số dư tài khoản Mở() Trả tiền() Rút tiền() Trừ số dư() Kiểm tra số dư() Hình 2.19 Biểu đồ lớp của UC Rút tiền Biểu đồ lớp trên hình 2.19 chỉ ra quan hệ giữa các lớp hình thành nên UC Rút tiền. Biểu đồ này bao gồm bốn lớp, đĩ là Máy đọc thẻ, Tài khoản, Màn hình ATM, và Máy trả tiền. Mỗi lớp trong biểu đồ đƣợc biểu diễn bằng hình chữ nhật chia làm ba phần: tên lớp (thí dụ tên lớp Tài khoản), thuộc tính (thí dụ lớp Tài khoản chứa ba thuộc tính: Số tài khoản, Số căn cước cá nhân – PIN và Cân đối tài khoản) và thao tác (thí dụ lớp Account cĩ bốn thao tác: Mở tài khoản, Rút tiền, Trừ tiền trong tài khoản và Kiểm tra số tiền trong tài khoản. Đƣờng nối giữa các phần tử biểu đồ lớp là quan hệ giao tiếp giữa chúng. Phía trái của một số thuộc tính và thao tác cĩ gắn biểu tƣợng khĩa; cĩ nghĩa rằng đĩ là các thuộc tính và thao tác riêng. Ngƣời phát triển sử dụng biểu đồ lớp để xây dựng các lớp. Các cơng cụ phần mềm nhƣ Rose phát sinh mã trình xƣơng sống cho các lớp, sau đĩ ngƣời phát triển phải chi tiết hĩa nĩ bằng ngơn ngữ lập trình. Kiến trúc sƣ quan sát thiết kế hệ thống thơng qua biểu đồ lớp. Nếu trên biểu đồ thấy một lớp chứa quá nhiều chức năng thì phải chia chúng ra nhiều lớp khác nhau. Kiến trúc sƣ cũng dễ phát hiện ra nếu giữa các lớp thiếu giao tiếp. 2.2.4.5 - Biểu đồ chuyển trạng thái (state transition) Biểu đồ chuyển trạng thái mơ tả vịng đời của đối tƣợng, từ khi nĩ đƣợc sinh ra đến khi bi phá hủy. Biểu đồ chuyển trạng thái cung cấp cách thức mơ hình hĩa các trạng thái khác nhau của đối tƣợng. Trong khi biểu đồ lớp cung cấp bức tranh tĩnh về các lớp và quan hệ của chúng thì biểu đồ chuyển trạng thái đƣợc sử dụng để mơ hình hĩa các hành vi động của hệ thống. Phát triển phần mềm bằng UML trang | 37
39. Mở Rút tiền[ Số dư 30 ngày ] Đóng Hình 2.20 Biểu đồ biến đổi trạng thái của lớp tài khoản Biểu đồ chuyển trạng thái chỉ ra hành vi của đối tƣợng. Thí dụ, đối tƣợng Tài khoản trong ngân hàng cĩ thể ở trong một vài trạng thái nhƣ mở, đĩng hay rút quá mức. Tài khoản sẽ ứng xử khác nhau với mỗi trạng thái khác nhau. Hình 2.20 là thí dụ biểu đồ chuyển trạng thái của lớp Tài khoản. Biểu đồ trên cho thấy các trạng thái và quá trình chuyển trạng thái của Tài khoản. Thí dụ, khi Tài khoản đang mở và Khách hàng yêu cầu đĩng Tài khoản thì nĩ chuyển sang trạng thái đĩng. Yêu cầu của Khách hàng đƣợc gọi là sự kiện. Sự kiện là cái gây ra biến đổi từ trạng thái này sang trạng thái khác. Nếu Tài khoản mở và khách hàng rút tiền thì cĩ thể dẫn tới trạng thái rút quá. Trạng thái này xảy ra khi khách hàng con nợ ngân hàng hay Tài khoản < 0. Điều kiện này cĩ thể đƣợc nêu trên biểu đồ trong đấu ngoặc vuơng và đƣợc gọi là điều kiện giác. Điều kiện gác điều khiển việc xảy ra hay khơng xảy ra biến đổi trạng thái. Biểu đồ biến đổi trạng thái cĩ hai trạng thái đặc biệt, đĩ là Khởi đầu (Start) và Dừng (Stop). Trên biểu đồ trạng thái chỉ cĩ duy nhất một trạng thái Start và cĩ thể cĩ nhiều hay khơng cĩ trạng thái Dừng. Các tiến trình xảy ra khi đối tƣợng đang trong trạng thái nào đĩ thì đƣợc gọi là hành động (action). Thí dụ, khi Tài khoản bị rút quá thì thơng báo đƣợc gửi tới khách hàng; việc gửi thơng báo là hành động. Thơng thƣờng, khơng tạo lập biểu đồ chuyển trạng thái cho mọi lớp mà chỉ sử dụng cho các lớp phức tạp. Nếu đối tƣợng của lớp tồn tại trong nhiều trạng thái và cĩ ứng xử khác nhau trong mỗi trạng thái thì nên xây dựng biểu đồ chuyển trạng thái cho chúng. Nhiều dự án khơng quan tâm đến loại biểu đồ này. Biểu đồ chuyển trạng thái chỉ dành cho việc làm tài liệu Rose khơng phát sinh mã trình từ biểu đồ này. 2.2.4.6 - Biểu đồ thành phần (component) Biểu đồ thành phần cho ta cái nhìn vật lý của mơ hình. Biểu đồ thành phần cho ta thấy đƣợc các thành phần phần mềm trong hệ thống và quan hệ giữa chúng. Hai loại Phát triển phần mềm bằng UML trang | 38
40. thành phần trong biểu đồ, đĩ là thành phần khả thực và thành phần thƣ viện. Trong Rose, mỗi lớp mơ hình đƣợc ánh xạ đến một thành phần mã nguồn. Hình 2.21 mơ tả biểu đồ thành phần của hệ thơng ATM. Biểu đồ trên hình 2.21 là các thành phần phía máy trạm trong hệ thống ATM. Nếu quyết định cài đặt hệ thống bằng ngơn ngữ C++ thì trong mỗi lớp sẽ cĩ tiệp .cpp và tiệp .h riêng biệt, vậy mỗi lớp đƣợc ánh xạ đến hai thành phần riêng trong biểu đồ. Thí dụ, lớp Màn hình ATM ánh xạ đến hai thành phần để thể hiện tiệp .h (header) và tiệp .cpp (thân lớp) của lớp. Thành phần tơ đen là đặc tả cảu gĩi (package specification); biểu diễn tệp cpp của lớp Màn hình ATM. Thành phần khơng tơ đen cũng đƣợc gọi là đặc tả gĩi, biểu diễn tiệp .h của lớp. Thành phân ATM.exe trên biểu dồ là đặc tả nhiệm vụ và biểu diễn luồng (thread) xử lý. Các thành phần nối với nhau bằng đƣờng gạch – gạch để cho biết chúng cĩ quan hệ phụ thuộc. Thí dụ, lớp Máy đọc thẻ phụ thuộc vào lớp Màn hình ATM. Cĩ nghĩa rằng phải cĩ lớp Màn hình ATM thì lớp Máy đọc thẻ mới dịch đƣợc. Khi tồn bộ các lớp dịch đƣợc thì ta mới cĩ thành phần ATMClient.exe. ATM.exe Máy đọc thẻ Máy trả tiền Màn hình ATM Máy trả tiền Máy đọc thẻ *.h Màn hình ATM *.cpp Hình 2.21 Biểu đồ thành phần của ATM client Thí dụ máy rút tiền tự động ATM cĩ hai luồng xử lý cho nên chúng cĩ hai trình khả thực. Một trình là Máy trạm ATM, bao gồm các thành phần Máy trả tiền, Máy đọc thẻ và Màn hình ATM. Trình thứ hai là Máy chủ ATM, nĩ chỉ cĩ thành phần Tài khoản. Biểu đồ thành phần của Máy chủ ATM trên hình 2.22. Phát triển phần mềm bằng UML trang | 39
41. Tài khoản Tài khoản Hình 2.22 Biểu đồ thành phần của máy chủ ATM Cĩ thể cĩ nhiều biểu đồ thành phần cho một hệ thống, số lƣợng này phụ thuộc vào các hệ thống con của chúng. Mỗi hệ thống con là gĩi thành phần. Tổng quát, gĩi là tập hợp các đối tƣợng. Thí dụ này cĩ hai gĩi, đĩ là gĩi Máy trạm ATM và gĩi Máy chủ ATM. Bất kỳ ai cĩ trách nhiệm dịch chƣơng trình đều quan tâm đến biểu đồ loại này. Biểu đồ cho ta thấy trình tự dịch của các mođun trong hệ thống. Đồng thời nĩ cũng cho biết rõ thành phần nào đƣợc tạo ra khi chạy chƣơng trình. Biểu đồ thành phần chỉ ra ánh xạ của lớp và các thành phần cài đặt. 2.2.4.7 - Biểu đồ triển khai (deployment) Biểu đồ triển khai chỉ ra bố trí vật lý của mạng và các thành phần hệ thống sẽ đặt ở đâu. Trong thí dụ hệ thống ATM thì ATM bao gồm nhiều hệ thống con chạy tách biệt trên các thiết bị vật lý khác nhau hay cịn gọi là nút. Biểu đồ triển khai của hệ ATM đƣợc thể hiện trên hình 2.23. Biểu đồ trên hình này cho thấy Máy trạm ATM sẽ chạy trên nhiều địa điểm khác nhau. Chúng giao tiếp với Máy chủ ATM qua mạng riêng. Máy chủ ATM sẽ giao tiếp với các Máy chủ CSDL thơng qua mạng LAN. Nhƣ vậy, hệ thống ATM này cĩ kiến trúc ba tầng: một tầng là CSDL, một tầng là máy chủ, tầng cịn lại là máy trạm. CSDL Ngân hàng > Máy chủ Máy in ATM vùng > > Số 1 Số 2 Tràng Tiền Đội Cấn Hình 2.23 Biểu đồ triển khai của hệ thống ATM Phát triển phần mềm bằng UML trang | 40
42. Thơng qua biểu đồ triển khai mà ngƣời quản lý dự án, ngƣời sử dụng, kiến trúc sƣ và đội ngũ triển khai hiểu phân bổ vật lý của hệ thống và các hệ thống con sẽ đƣợc đặt ở đâu. 2.3 KIẾN TRÚC HỆ THỐNG Kiến trúc là trừu tƣợng hĩa các khía cạnh quan trọng nhất của hệ thống. Nĩ cung cấp khung trong đĩ thiết kế sẽ đƣợc xây dựng. Nĩ mơ tả tầm cỡ, sức mạnh của hệ thống, thu thập các UC quan trọng nhất và các yêu cầu ứng dụng. Nĩ thể hiện phần mềm sẽ đƣợc tổ chức nhƣ thế nào và cung cấp các giao thức trao đổi dữ liệu và giao tiếp giữa các mođun. Việc hiển thị, đặc tả, xây dựng và làm tài liệu hệ thống phần mềm địi hỏi hệ thống phải đƣợc xem xét từ nhiều khía cạnh khác nhau. Ngƣời sử dụng khác nhau (ngƣời sử dụng cuối cùng, nhà phân tích, ngƣời phát triển, ngƣời tích hợp hệ thống, kiểm tra viên, ngƣời quản lý dự án ) cĩ cách quan sát hệ thống khác nhau vào các thời điểm khác nhau. Kiến trúc hệ thống là vật phẩm quan trọng nhất, đƣợc sử dụng để quản lý các điểm nhìn khác nhau để điều khiển phát triển hệ thống tăng dần và lặp trong suốt chu kỳ sống. Kiến trúc là tập các quyết định về: Tổ chức của hệ thống phần mềm Lựa chọn các phần tử cấu trúc và giao diện cho hệ thống Hành vi của chúng thể hiện trong hợp tác giữa các phần tử Tổ hợp các phần tử cấu trúc và hành vị vaị hệ thống con lớn hơn Kiến trúc phần mềm khơng chỉ liên quan đến cấu trúc và hành vi mà cả chức năng, tính sử dụng lại, dễ hiểu, ràng buộc cơng nghệ Design view Implementation view Use case view Process view Deployment view Hình 2.24 Mơ hình hĩa kiến trúc hệ thống Kiến trúc hệ thống phần mềm đƣợc mơ tả bằng các khung nhìn. Các khung nhìn ánh xạ vào tổ chức và cấu trúc hệ thống, mỗi khung nhìn tập trung vào khía cạnh cụ thể của hệ thống (hình 2.24). Theo biểu đồ của Philippe Krutchen [LIBE98] ta cĩ năm khung nhìn nhƣ sau: khung nhìn trƣờng hợp sử dụng (Use case view), khung nhìn logic (Logical view), khung nhìn cài đặt (Implementation view), khung nhìn triển khai (Deployment view) và khung nhìn tiến trình (Process view). Mỗi khung nhìn phục vụ mục đích riêng. 2.3.1 - Khung nhìn UC Khung nhìn này đứng trƣớc mọi khung nhìn khác (hình 2.24). Nĩ đƣợc hình thành từ giai đoạn phân tích yêu cầu và đƣợc sử dụng để điều khiển và thúc đẩy phần việc cịn lại của thiết kế. Nĩ mơ tả các hành vi hệ thống theo cách nhìn của khách Phát triển phần mềm bằng UML trang | 41
43. hàng, phân tích viên và kỹ sƣ kiểm tra, thử nghiệm. Khung nhìn UC chứa các tác nhân, UC, biểu đồ UC (khía cạnh tĩnh của khung nhìn) trong hệ thống. Chúng cũng cĩ thể bao gồm vài biểu đồ trình tự, biểu đồ cộng tác (khía cạnh động của khung nhìn) và gĩi. Khung nhìn UC tập trung vào mức độ cao của cái hệ thơng sẽ làm, khơng quan tâm đến hệ thống làm nhƣ thế nào. Chúng khơng xác định tổ chức của hệ thống. Khi dự án bắt đầu, khách hàng, phân tích viên và ngƣời quản lý dự án làm việc với UC, biểu đồ UC và tài liệu UC để thống nhất về hệ thống. Một khi khách hàng đã nhất trí về các UC và tác nhân thì họ sẽ nhất trí về phạm vi hệ thống. Hệ thống đƣợc tiếp tục phát triển băng khung nhìn logic. 2.3.2 - Khung nhìn thiết kế Rose gọi khung nhìn này là khung nhìn logic (logical view). Khung nhìn logic biểu diễn tổ chức của các lớp cĩ ý nghĩa nhất và các quan hệ của chúng với nhau. Khung nhìn logic tập trung vào hệ thống cài đặt hành vi trong UC nhƣ thế nào. Nĩ bao gồm các lớp, biểu đồ lớp, biểu đồ đối tƣợng (khía cạnh tĩnh của khung nhìn), biểu đồ tƣơng tác, biểu đồ biến đổi trạng thái (khía cạnh động của khung nhìn) và các gĩi. Hầu hết mọi ngƣời trong dự án đều quan tâm đến khung nhìn logic. Thơng thƣờng đội ngũ phát triển phần mềm tiệm cận khung nhìn logic theo hai bƣớc. Bƣớc thứ nhất là nhận ra các lớp phân tích (analysis class). Các lớp này độc lập với ngơn ngữ. Trong UML các lớp này đƣợc biểu diễn bằng các biểu tƣợng sau: Lớp phân tích cĩ thể xuất hiện cả ở trong biểu đồ tƣơng tác của khung nhìn UC. Một khi đã nhận ra các lớp phân tích thì đội ngũ phát triển phần mềm chuyển chúng sang lớp thiết kế (design class). Đĩ là những lớp phụ thuộc ngơn ngữ. Khung nhìn logic tập trung vào cấu trúc logic của hệ thống. Trong khung nhìn này ta sẽ nhận ra các bộ phận hệ thống, khảo sát thơng tin và hành vi, khảo sát quan hệ giữa các bộ phận. Cần cẩn thận khi gán thơng tin và hành vi cho lớp, nhĩm các lớp, khảo sát quan hệ giữa các lớp và gĩi để đảm bảo khả năng sử dụng lại. 2.3.3 - Khung nhìn cài đặt Rose gọi khung nhìn này là khung nhìn thành phần (component view). Thành phần là mođun vật lý hay tiệp mã trình để lắp ráp thành hệ thống vật lý. Khung nhìn thành phần bao gồm: thành phần, biểu đồ thành phần và gĩi. Ngƣời quan tâm nhất đến khung nhìn thành phần là ngƣời cĩ trách nhiệm quản lý mã trình, dích chƣơng trình và triển khai ứng dụng. Một vài thành phần là thƣ viện, một số khác là mã trình khả thực (exe) và thƣ viện (dll). 2.3.4 - Khung nhìn triển khai Khung nhìn này tập trung vào phân bổ vật lý của tài nguyên và phân bổ nhiệm vụ giữa các tài nguyên. Khung nhìn triển khai liên quan đến triển khai vật lý của hệ thống, khác với kiến trục logic. Thí dụ, hệ thống cĩ kiến trúc ba tầng logic, bao gồm giao diện, logic và tác nghiệp và logic CSDL tách biệt nhau. Nhƣng triển khai cĩ thể Phát triển phần mềm bằng UML trang | 42
44. chỉ cĩ hai tầng, trong đĩ logic tác nghiệp và logic CSDL trên cùng một máy. Khung nhìn triển khai bao gồm tiến trình (luơng thực hiện trong vùng nhớ riêng), bộ xử lý và thiết bị. Khung nhìn triển khai chỉ ra các tiến trình và thiết bị trên mạng và các kết nối vật lý giữa chúng. Biểu đồ triển khai cũng hiển thị tiến trình và chỉ ra tiến trình nào chạy trên máy nào. 2.3.5 - Khung nhìn tiến trình Khung nhìn tiến trình biểu diễn phân tách các luồng thực hiện chƣơng trình (tiến trình – process, luồng – thread, nhiệm vụ – task, ), đồng bộ giữa các luồng, phân bổ các đối tƣợng và lớp cho các luồng thực hiện khác nhau. Khung nhìn tiến trình tập trung vào các nhiệm vụ tƣơng tranh tƣơng tác với nhau nhƣ thế nào trong hệ thơng đa nhiệm. Trong biểu đồ cảu phần mềm cơng cụ Rose 2000 khơng cĩ khung này. 2.3.6 - Cần bao nhiêu khung nhìn Khơng phải tất cả các hệ thống đều địi hỏi đầy đủ các khung nhìn mơ tả trên. Hệ thống trên máy riêng lẻ cĩ thể bỏ khung nhìn triển khai, nếu hệ đơn xử lý thì bỏ khung nhìn tiến trình, nếu chƣơng trình nhỏ thì bỏ khung nhìn cài đặt. 2.4 RATIONAL ROSE LÀ GÌ? Rational Rose là phần mềm cơng cụ mạnh hỗ trợ phân tích, thiết kế hệ thống phần mềm theo hƣớng đối tƣợng. Nĩ giúp ta mơ hình hĩa hệ thống trƣớc khi viết mã trình, nĩ đảm bảo tính đúng đắn, hợp lý của kiến trúc hệ thống từ khi khởi đầu dự án. Mơ hình Rose là bức tranh hệ thống, nĩ bao gồm tồn bộ biểu đồ UML, tác nhân, trƣờng hợp sử dụng, đối tƣợng, lớp, thành phần và các nút triển khai trong hệ thống. Nĩ mơ tả chi tiết hệ thống bao gồm cài gì và chúng làm việc ra sao để ngƣời phát triển hệ thống cĩ thể sử dụng mơ hình nhƣ kế hoạch chi tiết cho việc xây dựng hệ thống. Rose hỗ trợ giải quyết vấn đề muơn thủa là đội ngũ dự án giao tiếp với khách hàng và làm tài liệu yêu cầu. Theo phong cách lập trình truyền thống thì sau khi đã xác định yêu cầu hệ thống, ngƣời phát triển sẽ lấy một vài yêu cầu, quyết định thiết kế và viết mã trình. Một số ngƣời phát triển khác cũng làm nhƣ vậy với yêu cầu khác, thiết kế khác. Cách làm này dẫn tời nhiều khĩ khăn cho ai muốn hiểu và quản trị tồn bộ hệ thống, họ khĩ thấy đƣợc quyết định thiết kế đã đƣợc làm trƣớc đĩ. Nếu khơng cĩ tài liệu thiết kế thì khĩ đảm bảo rằng hệ thống đƣợc xây dựng đúng là hệ thống mà ngƣời sử dụng nghĩ tới. Tuy rằng các yêu cầu đƣợc làm tài liệu đầy đủ, nhƣng thiết kế chỉ tồn tại trong đầu ngƣời phát triển nào đĩ, ngƣời khác sẽ khơng cĩ ý tƣởng gì về cấu trúc hệ thống. Nếu ngƣời phát triển chuyển đi nơi khác thì dự án sẽ gặp khĩ khăn. Phong cách khác phát triển hệ thống là sau khi xác định yêu cầu, các thiết kế phải đƣợc làm tài liệu chi tiết. Mọi ngƣời tham gia phát triển cùng trao đổi quyết định thiết kế trƣớc khi viết mã trình. Do vậy, dự án khơng cịn phải lo lắng khi ai đĩ rời bỏ dự án. Ngồi ngƣời phát triển hệ thơng quan tâm đến mơ hình, ta cịn thấy mọi thành viên khác của dự án đều cĩ thể thu nhận các thơng tin cần thiết từ mơ hình. Khách hàng và quản lý dự án sử dụng các biểu đồ UC để cĩ cài nhìn bao quát về hệ thống và thống nhất với nhau về phạm vi dự án. Phát triển phần mềm bằng UML trang | 43
45. Quản lý dự án sử dụng biểu đồ UC và tài liệu để chia nhỏ dự án thành tiểu dự án cĩ thể quản lý đƣợc. Thơng qua tài liệu UC, các phân tích viên và khách hàng thấy đƣợc các chức năng hệ thống sẽ cung cấp Các phân tích viên và ngƣời phát triển, thơng qua các biểu đồ trình tự và biểu đồ cơng tác, thấy đƣợc logic mà hệ thống tuân thủ, các đối tƣợng trong hệ thống và các thơng điệp giữa các đối tƣợng. Đội ngũ kiểm tra chất lƣợng thu thập thơng tin thơng qua tài liệu UC và các biểu đồ tƣơng tác để viết mơ tả kiểm tra hệ thống. Ngƣời phát triển sử dụng biểu đồ lớp, biểu đồ biến đổi trạng thái để cĩ cái nhìn chi tiết về các phần hệ thống và chúng cĩ quan hệ với nhau nhƣ thế nào. Đội ngũ triển khai sử dụng các biểu đồ thành phần và biểu đồ triển khai để thấy đƣợc các tệp khả thực (exe) nào, tệp DLL nào và các thành phần khác cần đƣợc tạo lập; các thành phần này đƣợc triển khai trên mạng nhƣ thế nào. Tồn bộ đội ngũ dự án sử dụng mơ hình để đảm bảo rằng các yêu cầu cĩ thể đƣợc chuyển sang mã trình và ngƣợc lại, mã trình cĩ thể đƣợc chuyển trở lại yêu cầu hệ thống. Hơn nữa, Rational Rose cịn hỗ trợ phát sinh mã khung chƣơng trình trong nhiều ngơn ngữ khác nhau nhƣ C++, Java, Visual Basic, Oracle8 2.5 KHẢ NĂNG SỬ DỤNG UML Mục tiêu của UML là để mơ tả bất kỳ loại hệ thống nào bằng biểu đồ hƣớng đối tƣợng. Đặc tính của hệ thống đĩ đƣợc tĩm tắt nhƣ sau: Các hệ thống thơng tin: Lƣu trữ, truy vấn, biểu diễn thơng tin. Quản lý số lƣợng thơng tin lớn cĩ quan hệ phức tạp trong CSDL quan hệ hay CSDL hƣớng đối tƣợng. Các hệ thống ký thuật: Quản lý và điểu khiển các thiết bị kỹ thuật nhƣ truyền tin, hệ thống quân sự, dây chuyền cơng nghiệp. Thơng thƣờng phải quản lý các giao diện ngƣời sử dụng đặc biệt, khơng cĩ phần mềm chuẩn. Các hệ thống này phần lớn là hệ thống thời gian thực. Các hệ thống nhúng thời gian thực: Thực hiện trên phần cứng đơn giản nhúng trong các thiết bị khác nhƣ điện thoại di động, xe ơ tơ, các dụng cụ gia đình Các hệ thống này thƣờng thiếu thiết bị nhƣ màn hình, ổ đĩa Các hệ thơng phân tán: Phân tán trên nhiều máy. Địi hỏi cơ chế giao tiếp đồng bộ để đảm bảo tồn vẹ dự liệu. Thƣờng đƣợc xây dựng trên cơ chế đối tƣợng nhƣ CORBA, COM/DCOM Các phần mềm hệ thống: Xác dịnh hạ tầng kỹ thuật để phần mềm khác sử dụng nhƣ hệ điều hành, CSDL Các hệ thống thương mại: Mơ tả mục tiêu, tài nguyên (con ngƣời, máy tính ) và các quy luật (chiến lƣợc thƣơng mại, luật ) và qui trình thƣơng mại. Tuy nhiên ngày nay một hệ thống thƣờng thuộc nhiều loại hoặc tổ hợp của các loại hệ thống kể trên, nhƣng ta vẫn cĩ khả năng sử dụng UML để mơ hinh hĩa chúng. Phát triển phần mềm bằng UML trang | 44
46. 2.6 THỰC HÀNH Phần mềm Rose cĩ nhiều phiên bản khác nhau. Độc giả cĩ thể sử dụng phần mềm Rose 98, Rose 2000, Rose v2002 hay các phiên bản thử nghiệm để thực hành các bài tập trong tài liệu này. Độc giả cĩ thể tìm kiếm các phiên bản thử nghiệm hay phiên bản hạn chế (dành cho huấn luyện, đào tạo) của Rose trên trang Web sau: Mục tiêu của bài thực hành này là làm quen với các màn hình của phần mềm cơng cụ Rose 2000, một phiên bản của phần mềm cơng cụ Rational Rose. Hãy thự hiện theo các bƣớc nhƣ mơ tả dƣới đầy để làm quen với Rose: 1. Khởi động Rose 2000. Trên màn hình cĩ các thành phần nhƣ hình 2.25. 2. Cĩ thể tắt/mở các cửa sổ duyệt (Brower Window) và cửa sổ tài liệu (Document Window) bằng cách chọn thực đơn View>Brower. Nơ i đặt l ại thuộ c tính c ủ a Rose Browser C ửa s ổ bi ể u đồ C ử a s ổ tài liệ u Hình 2.25 Giao diện của Rational Rose 3. Cửa sổ duyệt chứa danh sách tồn bộ phần tử mơ hình trong mơ hình hiện hành. Browser cĩ thể trơi nổi hay bám dính (docked) bằng cách nhấp đúp chuột trên biên cửa sổ. Các phần tử mơ hình hiển thì trong Browser dƣới dạng cây. Các thơng tin nén đƣơc thể hiện bằng dấu +. Nếu nhấn chuột trên dấu + ta sẽ cĩ thơng tín khơng nén. Phát triển phần mềm bằng UML trang | 45
47. Thự hành: tạo lập tệp mơ hình mới bằng cách chọn thực đơn File>New, File>Save as với tên tutorial.mdl 4. Cửa sổ tài liệu là nơi tạo lập, sửa đổi văn bản để gắn vào phần tử mơ hình (tác nhân, UC, quan hệ, thuộc tính, thao tác, thành phần và nút). Để tạo tài liệu cho phần tử mơ hình ta làm nhƣ sau: chọn phần tử (nhấn chuột lên phần tử), nhập tài liệu vào cửa sổ tài liệu. Cửa sổ tài liệu cũng cĩ thể tắt/mở, trơi nổi hay bám dính nhƣ cửa sổ Browse. Thự hành: Nhập tài liệu cho Use case View, Logical View và Component View. Use Case View chứa thơng tin về tác nhân và UC cho hệ thống đang phát triển. Logical View chứa thơng tin về lớp và quan hệ giữa chúng Component View chứa thơng tin về phần mềm và các phần tử khả thực và thƣ viện. 5. Lƣu trữ mơ hình vào đĩa từ 6. Cửa sổ biểu đồ là nơi cho phép ta tạo lập và sử đổi khung nhìn đồ họa mơ hình hiện hành. Mỗi biểu tƣợng trong biểu đồ biểu diễn một thành phần mơ hình hĩa. Mỗi phần tử mơ hình cĩ thể hiển thị trong nhiều biểu đồ mơ hình khác nhau. Cửa sổ biểu đồ xuất hiện khi nhấn đúp chuột trên cửa sổ biểu đồ trong cửa sổ duyệt. Phát triển phần mềm bằng UML trang | 46