Tài liệu Nghiên cứu mẫu thiết kế kiến trúc phần mềm trong java

ĐẠI HỌC THÁI NGUYÊN KHOA CÔNG NGHỆ THÔNG TIN NGUYỄN QUANG HUY NGHIÊN CỨU MẪU THIẾT KẾ KIẾN TRÚC PHẦN MỀM TRONG JAVA LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH Thái Nguyên - 2010 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn ĐẠI HỌC THÁI NGUYÊN KHOA CÔNG NGHỆ THÔNG TIN NGUYỄN QUANG HUY NGHIÊN CỨU MẪU THIẾT KẾ KIẾN TRÚC PHẦN MỀM TRONG JAVA Chuyên ngành: Khoa học máy tính Mã số: 60.48.01 LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH NGƯỜI HƯỚNG DẪN KHOA HỌC PGS. TS. Đặng Văn Đức Thái Nguyên - 2010 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -i- LỜI CAM ĐOAN Tôi xin cam đoan bản luận văn “Nghiên cứu mẫu thiết kế kiến trúc phần mềm trong Java” là công trình nghiên cứu của tôi dưới sự hướng dẫn khoa học của PGS.TS. Đặng Văn Đức, tham khảo các nguồn tài liệu đã được chỉ rõ trong trích dẫn và danh mục tài liệu tham khảo. Các nội dung công bố và kết quả trình bày trong luận văn này là trung thực và chưa từng được ai công bố trong bất cứ công trình nào. Thái Nguyên, tháng 10 năm 2010 Nguyễn Quang Huy Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn - ii - Lời cảm ơn Tôi xin gửi lời cảm ơn sâu sắc tới PGS.TS. Đặng Văn Đức – Viện Công nghệ thông tin, người đã tận tình có những chỉ bảo cần thiết để giúp đỡ tôi trong suốt quá trình nghiên cứu và phát triển luận văn. Xin chân thành cảm ơn quý Thầy cô trong khoa Sau đại học trường Đại học Thái Nguyên đã nhiệt tình giảng dạy, trang bị cho tôi những kiến thức quý báu trong suốt thời gian học tập tại trường. Xin chân thành cảm ơn các bạn cùng lớp, đồng nghiệp và đơn vị nơi tôi công tác đã tạo điều kiện cho tôi hoàn thành luận văn này. Xin gửi lời cảm ơn tới gia đình tôi đã động viên tôi trong suốt quá trình học và hoàn thành luận văn. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn - iii - MỤC LỤC LỜI CAM ĐOAN ...................................................................................................... i MỤC LỤC............................................................................................................... iii DANH MỤC CÁC TỪ VIẾT TẮT ............................................................................. v MỞ ĐẦU ................................................................................................................. 1 CHƢƠNG I. TỔNG QUAN VỀ MẪU THIẾT KẾ VÀ NGÔN NGỮ........................... 3 MÔ HÌNH HÓA THỐNG NHẤT UML ...................................................................... 3 1.1. Tổng quan về mẫu thiết kế........................................................................... 3 1.1.1 Vấn đề trong thiết kế phần mềm hướng đối tượng ............................................ 3 1.1.2 Lịch sử Mẫu thiết kế ........................................................................................ 3 1.1.3 Mẫu thiết kế là gì ? .......................................................................................... 5 1.1.4 Một số vấn đề về mẫu thiết kế.......................................................................... 5 1.2 Ngôn ngữ mô hình hóa thống nhất UML ....................................................... 7 1.2.1 Khái quát về UML ........................................................................................... 7 1.2.2 Biểu đồ lớp (Class Diagrams) .......................................................................... 8 1.2.3 Lược đồ trình tự (Sequence Diagrams)........................................................... 14 Chƣơng II. CÁC MẪU THIẾT KẾ KIẾN TRÚC PHẦN MỀM TRONG JAVA ....... 16 2.1 Mẫu khởi tạo ............................................................................................... 16 2.1.1 Factory Method ............................................................................................. 16 2.1.2 Singleton ....................................................................................................... 17 2.1.3 Abstract Factory ............................................................................................ 18 2.1.4 Prototype ....................................................................................................... 20 2.1.5 Builder........................................................................................................... 20 2.2 Mẫu cấu trúc ............................................................................................... 22 2.2.1 Decorator ....................................................................................................... 22 2.2.2 Adapter .......................................................................................................... 23 2.2.3 Façade ........................................................................................................... 24 2.2.4 Proxy ............................................................................................................. 25 2.2.5 Bridge............................................................................................................ 26 2.2.6 Composite ..................................................................................................... 28 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn - iv - 2.2.7 Flyweight ...................................................................................................... 30 2.3 Mẫu hành vi ................................................................................................ 31 2.3.1 Mẫu Chain of Responsibility ......................................................................... 32 2.3.2 Command ...................................................................................................... 35 2.3.3 Interperter ...................................................................................................... 37 2.3.4 Iterator ........................................................................................................... 38 2.3.5 Mediator ........................................................................................................ 39 2.3.6 Memento ....................................................................................................... 40 2.3.7 Observer ........................................................................................................ 41 2.3.8 Sate ............................................................................................................... 42 2.3.9 Strategy ......................................................................................................... 43 2.3.10 Template Method ......................................................................................... 44 2.3.11 Visitor ......................................................................................................... 45 2.4 Mẫu tương tranh ......................................................................................... 46 2.4.1. Critical Section ............................................................................................. 46 2.4.2 Consistent Lock Order ................................................................................... 49 2.4.3 Guarded Suspension ...................................................................................... 51 2.4.4 Read-Write Lock ........................................................................................... 52 Chƣơng III. PHÁT TRIỂN CHƢƠNG TRÌNH THỬ NGHIỆM ............................... 55 3.1 Cơ sở lý thuyết............................................................................................ 55 3.1.1 Giao dịch phân tán ......................................................................................... 55 3.1.2 Các vấn đề về xung đột dữ liệu và một số giải thuật điều khiển ...................... 56 3.2 Xây dựng chương trình thử nghiệm............................................................ 60 3.2.1 Sơ đồ UML.................................................................................................... 60 3.2.2 Lập trình mođun demo ................................................................................... 62 3.2.3 Đánh giá kết quả thu được ............................................................................. 64 KẾT LUẬN ............................................................................................................ 65 HƢỚNG PHÁT TRIỂN.......................................................................................... 66 TÀI LIỆU THAM KHẢO ........................................................................................ 67 Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -v- DANH MỤC CÁC TỪ VIẾT TẮT UML Unified Modeling Language CSDL Cơ sở dữ liệu DBMS Database Management System (Hệ quản trị CSDL) V Validation (Thẩm tra) R Read (Đọc) C Computation (Tính toán) W Write (Ghi) Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -1- MỞ ĐẦU Ngôn ngữ lập trình Java được Sun Microsystems giới thiệu vào tháng 6 năm 1995. Từ đó, nó đã trở thành một công cụ lập trình của các lập trình viên chuyên nghiệp. Java được sử dụng rộng rãi để viết chương trình chạy trên Internet. Nó là ngôn ngữ lập trình hướng đối tượng độc lập thiết bị, không phụ thuộc vào hệ điều hành. Nó không chỉ dùng để viết các ứng dụng chạy đơn lẻ hay trong mạng mà còn để xây dựng các trình điều khiển thiết bị cho điện thoại di động, PDA, … Các phương pháp phân tích thiết kế hướng đối tượng đã phát triển rất mạnh mẽ và góp phần đáng kể vào việc cải tiến chất lượng của phần mềm nhờ vào khả năng xây dựng các lớp đối tượng có tính tái sử dụng cao, dễ bảo trì và mở rộng. Ngôn ngữ UML (Unified Modeling Language) được đề xuất để sử dụng như một ngôn ngữ chuẩn để mô hình hóa các thành tố phần mềm trong quá trình phân tích thiết kế hướng đối tượng. Tuy nhiên, các phương pháp hướng đối tượng tập trung chủ yếu vào các hoạt động tổng thể trong tiến trình phát triển phần mềm hướng đối tượng. Những phương pháp này thường không giải quyết các vấn đề chi tiết nảy sinh trong quá trình thiết kế phần mềm. Để bổ sung cho phương pháp hướng đối tượng, các mẫu thiết hướng đối tượng là một tiếp cận độc đáo, được đề xuất để giải quyết các vấn đề nảy sinh trong quá trình thiết kế phần mềm hướng đối tượng. Các mẫu GoF có tầm quan trọng và ảnh hưởng rất lớn đối với giới nghiên cứu cũng như giới công nghiệp phần mềm. Rất nhiều công trình đặc sắc khác về mẫu thiết kế hướng đối tượng được đề xuất để giải nhiều vấn đề đặc thù cho từng lĩnh vực ứng dụng phần mềm. Trong đó, tôi quan tâm đến việc nghiên cứu các mẫu thiết kế để áp dụng trong quá trình phát triển phần mềm hướng đối tượng, đặc biệt là giải quyết các vấn đề về cài đặt giao diện người dùng và các vấn đề liên quan đến các ứng dụng trong Java. Vì thế, tôi đã thực hiện đề tài luận văn: “Nghiên cứu mẫu thiết kế kiến trúc phần mềm trong Java”. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -2- Mục tiêu đề tài là nghiên cứu, nắm vững được phương pháp phân tích thiết kế hướng đối tượng bằng ngôn ngữ mô hình hóa thống nhất UML (Unified Modeling Language). Đồng thời sử dụng được một số mẫu thiết kế vào công đoạn xây dựng kiến trúc phần mềm bằng ngôn ngữ Java. Bố cục của luận văn bao gồm phần mở đầu, phần kết luận và ba chương nội dung được tổ chức như sau: Chương I. Tổng quan về mẫu thiết kế và ngôn ngữ mô hình hóa thống nhất UML Chương này trình bày tổng quan về mẫu thiết kế kiến trúc phần mềm hướng đối tượng, lịch sử phát triển, định nghĩa mẫu thiết kế và một số vấn đề về mẫu. Khái quát về ngôn ngữ mô hình hóa thống nhất UML, các biểu đồ cấu trúc, biểu đồ hành vi, biểu đồ quản lý mô hình, các ký pháp của UML… Chương II. Các mẫu thiết kế kiến trúc phần mềm trong Java Trong chương này tập trung vào trình bày các mẫu thiết kế kiến trúc phần mềm trong Java bao gồm các mẫu khởi tạo, mẫu cấu trúc, mẫu hành vi, mẫu tương tranh. Các mẫu được mô tả, định nghĩa đưa ra mô hình UML và sau đó là ví dụ áp dụng. Chương III. Phát triển chương trình thử nghiệm Trong chương này phát triển ứng dụng sử dụng mẫu thiết kế, chủ yếu tập trung minh họa việc sử dụng các mẫu tương tranh để giải quyết xung đột trong môi trường mạng, môi trường đa tiến trình. Chương trình được phân tích và thiết kế bằng UML lập trình mô-đun demo bằng Java. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -3- CHƢƠNG I. TỔNG QUAN VỀ MẪU THIẾT KẾ VÀ NGÔN NGỮ MÔ HÌNH HÓA THỐNG NHẤT UML 1.1. Tổng quan về mẫu thiết kế 1.1.1 Vấn đề trong thiết kế phần mềm hướng đối tượng Việc thiết kế một phần mềm hướng đối tượng là một công việc khó, và việc thiết kế một một phần mềm hướng đối tượng phục vụ cho mục đích dùng lại còn khó hơn. Chúng ta phải tìm ra những đối tượng phù hợp, đại diện cho một lớp các đối tượng. Sau đó thiết kế giao diện và cây kế thừa cho chúng, thiết lập mối quan hệ giữa chúng. Thiết kế của chúng ta phải đảm bảo là giải quyết được các vấn đề hiện tại, có thể tiến hành mở rộng trong tương lai mà tránh phải thiết kế lại phần mềm. Và một tiêu trí quan trọng là phải nhỏ gọn. Thiết kế một phần mềm hướng đối tượng phục vụ cho mục đích dùng lại là một công việc khó, phức tạp vì vậy chúng ta không thể mong chờ thiết kế của mình sẽ là đúng, và đảm bảo các tiêu trí trên ngay được. Thực tế là nó cần phải được thử nghiệm sau vài lần và sau đó nó sẽ được sửa chữa lại. Đứng trước một vấn đề, một người phân tích thiết kế tốt có thể đưa ra nhiều phương án giải quyết, anh ta phải duyệt qua tất cả các phương án và rồi chọn ra cho mình một phương án tốt nhất. Phương án tốt nhất này sẽ được anh ta dùng đi dùng lại nhiều lần, và dùng mỗi khi gặp vấn đề tương tự. Mà trong phân tích thiết kế phần mềm hướng đối tượng ta luôn gặp lại những vấn đề tương tự như nhau. 1.1.2 Lịch sử Mẫu thiết kế Ý tưởng dùng mẫu xuất phát từ ngành kiến trúc, Alexander, Ishikawa, Silverstein, Jacobson, Fiksdahl-King và Angel (1977) lần đầu tiên đưa ra ý tưởng dùng các mẫu chuẩn trong thiết kế xây dựng và truyền thông. Họ đã xác định và lập sưu liệu các mẫu có liên quan để có thể dùng để giải quyết các vấn đề thường xảy ra trong thiết kế các cao ốc. Mỗi mẫu này là một cách thiết kế, chúng đã được phát triển hàng trăm năm như là các giải pháp cho các vấn đề mà người ta làm trong lĩnh vực xây dựng thường gặp. Các giải pháp tốt nhất có được ngày hôm nay là qua một quá trình sàng lọc tự nhiên. Mặc dù nghành công nghệ phần mềm không có lịch sử Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -4- phát triển lâu dài như nghành kiến trúc, xây dựng nhưng Công nghệ phần mềm là một nghành công nghiệp tiên tiến, tiếp thu tất cả những gì tốt đẹp nhất từ các nghành khác. Mẫu được xem là giải pháp tốt để giải quyết vấn đề xây dựng hệ thống phần mềm. Suốt những năm đầu 1990, thiết kế mẫu được thảo luận ở các hội thảo workshop, sau đó người ta nỗ lực để đưa ra danh sách các mẫu và lập sưu liệu về chúng. Những người tham gia bị dồn vào việc cần thiết phải cung cấp một số kiểu cấu trúc ở một mức quan niệm cao hơn đối tượng và lớp để cấu trúc này có thể được dùng để tổ chức các lớp. Đây là kết quả của sự nhận thức được rằng việc dùng các kỹ thuật hướng đối tượng độc lập sẽ không mang lại những cải tiến đáng kể đối với chất lượng cũng như hiệu quả của công việc phát triển phần mềm. Mẫu được xem là cách tổ chức việc phát triển hướng đối tượng, cách đóng gói các kinh nghiệm của những ngưòi đi trước và rất hiệu quả trong thực hành. Năm 1994 tại hội nghị PloP (Pattern Language of Programming Design) đã được tổ chức. Cũng trong năm này quyển sách Design Patterns: Elements of Reusable Object Oriented Software (Gamma, Johnson, Helm và Vhissdes, 1995) đã được xuất bản đúng vào thời điểm diễn ra hội nghị OOPSLA‟94. Đây là một tài liệu còn phôi thai trong việc làm nỗi bật ảnh hưởng của mẫu đối với việc phát triển phần mềm, sự đóng góp của nó là xây dựng các mẫu thành các danh mục (catalogue) với định dạng chuẩn được dùng làm tài liệu cho mỗi mẫu và nổi tiếng với tên Gang of Four (bộ tứ), và các mẫu nó thường được gọi là các mẫu Gang of Four. Còn rất nhiều các cuốn sách khác xuất hiện trong hai năm sau, và các định dạng chuẩn khác được đưa ra. Năm 2000 Evitts có tổng kết về cách các mẫu xâm nhập vào thế giới phần mềm (sách của ông lúc bấy giờ chỉ nói về những mẫu có thể được sử dụng trong UML chứ chưa đưa ra khái niệm những mẫu thiết kế một cách tổng quát). Ông công nhận Kent Beck và Ward Cunningham là những người phát triển những mẫu đầu tiên với SmallTalk trong công việc của họ được báo cáo tại hội nghị OOPSLA‟87. Có 5 mẫu mà Kent Beck và Ward Cunningham đã tìm ra trong việc kết hợp các Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -5- người dùng của một hệ thống mà họ đang thiết kế. Năm mẫu này đều được áp dụng để thiết kế giao diện người dùng trong môi trường Windows. 1.1.3 Mẫu thiết kế là gì ? Mẫu thiết kế mô tả một giải pháp chung đối với một vấn đề nào đó trong thiết kế thường được “lặp lại” trong nhiều dự án. Nói một cách khác, một Pattern có thể được xem như một “khuôn mẫu” có sẵn áp dụng được cho nhiều tình huống khác nhau để giải quyết một vấn đề cụ thể. Trong bất kỳ hệ thống phần mềm hướng đối tượng nào chúng ta cũng có thể bắt gặp các vấn đề lặp lại. + Là những thiết kế đã được sử dụng và được đánh giá tốt. + Giúp giải quyết những vấn đề thiết kế thường gặp. + Chú trọng đến việc giúp cho bản thiết kế có tính uyển chuyển, dễ nâng cấp thay đổi. Christopher Alexander nói rằng: “Mỗi một mẫu mô tả một vấn đề xảy ra lặp đi lặp lại trong môi trường và mô tả cái cốt lõi của giải pháp để cho vấn đề đó. Bằng cách nào đó bạn đã dùng nó cả triệu lần mà không làm giống nhau hai lần”. 1.1.4 Một số vấn đề về mẫu thiết kế Mẫu thiết kế là khái niệm rộng và bao quát trong công đoạn thiết kế phần mềm. Giống như các yêu cầu của thiết kế và phân tích hướng đối tượng (nhằm đạt được khả năng tái sử dụng), việc sử dụng các mẫu cũng cần đạt được khả năng tái sử dụng các giải pháp chuẩn đối với các vấn đề thường xuyên xảy ra. Mẫu thiết kế giúp đỡ thúc đẩy sử dụng lại trong pha thiết kế vì chúng cung cấp từ vựng chung cho thiết kế, chúng cung cấp những phương tiện để hiểu thiết kế, và chúng được tạo thành khối hợp nhất từ đó xây dựng những ứng dụng phức tạp hơn. Mẫu thiết kế không đơn thuần là một bước nào đó trong giai đoạn phát triển phần mềm mà nó đóng vai trò là sáng kiến để giải quyết một bài toán thông dụng nào đó. Các giai đoạn phần mềm vẫn hoàn chỉnh mà không có mẫu thiết kế, nhưng sự góp mặt của mẫu thiết kế sẽ giúp cho việc xác định bài toán cần giải quyết nhanh gọn hơn, từ đó đưa ra cách giải quyết hợp lý. Mẫu thiết kế không chỉ được sử dụng để xác định bài toán và cách giải quyết Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -6- mà mẫu thiết kế còn được sử dụng nhằm cô lập các thay đổi trong mã nguồn, từ đó làm cho hệ thống có khả năng tái sử dụng cao. Điều này là tất yếu vì mẫu tuân thủ rất nghiêm ngặt các nguyên lý thiết kế hướng đối tượng. Cũng giống như mẫu trong phần mềm nói chung, mẫu thiết kế là sự hình thức hóa của các cách tiếp cận một vấn đề thường gặp trong một ngữ cảnh cụ thể. Mỗi mẫu thiết kế là một giải pháp cho một vấn đề thiết kế cụ thể trong một ngữ cảnh xác định. Giải pháp được đưa ra đã được kiểm nghiệm, được sử dụng nhiều lần đem lại kết quả tốt và do đó được trìu tượng hóa thành một mẫu. mẫu thiết kế chính là kinh nghiệm thiết kế được đúc kết lại thành mẫu chuẩn mực. Sử dụng mẫu thiết kế người thiết kế không phải thiết kế hệ thống từ đầu, không phải giải quyết lại những bài toán đã được giải quyết mà sử dụng các kinh nghiệm, tri thức và kết quả đã có từ trước. Điều này làm cho chất lượng thiết kế tốt hơn, tăng tính sử dụng của bản thiết kế và tạo điều kiện cho người thiết kế tập trung vào sáng tạo những cái mới. Khung (Frameworks) cũng có đặc tính tương tự như mẫu thiết kế và dễ gây ra nhầm lẫn với mẫu thiết kế (Design Patterns). Bảng sau phân biệt khung với mẫu thiết kế. Design Patterns Frameworks Những mẫu thiết kế là những giải pháp có định kỳ cho những vấn đề xuất hiện trong thời gian sống của một ứng dụng phần mềm trong một ngữ cảnh đặc biệt. Các mục tiêu chính là: Một khung là nhóm những thành phần mà hợp tác với nhau để cung cấp một kiến trúc dùng lại được cho những ứng dụng với lĩnh vực đã cho. Các mục tiêu chính là:  Giúp cải thiện chất lượng phần  Giúp đỡ cải thiện chất lượng phần mềm dưới dạng phần mềm dùng mềm dưới dạng phần mềm dùng lại lại được, có thể duy trì được, dễ được, có thể duy trì được, dễ mở mở rộng... rộng...  Giảm bớt thời gian phát triển  Giảm bớt thời gian phát triển Mẫu là lôgíc. Khung là về vật lý hơn, trong khi chúng tồn tại trong các mẫu của phần mềm. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -7- Thông thường, mẫu thường được mô tả độc lập với ngôn ngữ lập trình hoặc được thực hiện chi tiết. Mẫu chung hơn và có thể được sử dụng trong gần như bất kỳ loại ứng dụng nào. Một mẫu thiết kế không tự ý tồn tại trong mẫu của một thành phần phần mềm. Nó cần thực hiện rõ ràng mỗi thời điểm nó được sử dụng. Mẫu cung cấp một cách để làm “tốt” thiết kế và được sử dụng để giúp thiết kế khung. Vì khung tồn tại trong mẫu của phần mềm nào đó, chúng được thực hiện cụ thể. Khung cung cấp chức năng trong lĩnh vực cụ thể Khung tự nó thì không phải là ứng dụng đầy đủ. Những ứng dụng đầy đủ trực tiếp có thể được xây dựng bởi hoặc thừa kế những thành phần không đổi. Mẫu thiết kế có thể được sử dụng trong thiết kế và thi hành của một khung. Khung tiêu biểu gồm vài mẫu thiết kế. 1.2 Ngôn ngữ mô hình hóa thống nhất UML 1.2.1 Khái quát về UML UML đưa ra mười hai biểu đồ nhằm trình bày về việc phân tích yêu cầu của ứng dụng và thiết kế các giải pháp. Trong mười hai biểu đồ có thể phân chia thành ba nhóm như sau: - Biểu đồ cấu trúc (Structure Diagrams) UML cung cấp bốn biểu đồ cấu trúc sau đây có thể dùng để biểu diễn cấu trúc tĩnh của ứng dụng. 1. Biểu đồ lớp (Class diagrams) 2. Biểu đồ đối tượng (Object diagrams) 3. Biểu đồ thành phần (Component diagrams) 4. Biểu đồ triển khai (Deployment diagrams) - Biểu đồ hành vi (Behavior Diagrams) UML cung cấp năm biểu đồ hành vi sau đây dùng để biểu diễn hành vi động bên ngoài của ứng dụng. 1 . Biểu đồ trường hợp sử dụng (Use Case diagrams) 2. Biểu đồ trình tự (Sequence diagrams) 3. Biểu đồ hoạt động (Activity diagrams) Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -8- 4. Biểu đồ cộng tác (Collaboration diagrams) 5. Biểu đồ trạng thái (Statechart diagram) - Biểu đồ quản lý mô hình (Model Management Diagrams) UML cung cấp ba biểu đồ quản lý mô hình sau đây miêu tả làm thế nào để tổ chức và quản lý các mô-đun ứng dụng khác nhau. 1. Gói (Packages) 2. Hệ thống con (Subsystems) 3. Mô hình (Models) 1.2.2 Biểu đồ lớp (Class Diagrams) Biểu đồ lớp là biểu đồ quan trọng nhất trong hầu hết các phương pháp hướng đối tượng. Biểu đồ lớp cho ta cái nhìn tổng quan về hệ thống bằng cách biểu diễn các lớp và các mối quan hệ giữa chúng. Nó thể hiện mặt tĩnh của hệ thống. - Lớp (Class) Một lớp biểu diễn cho sự mô tả trừu tượng một tập các đối tượng có cùng tính chất, thao tác và ngữ nghĩa. Lớp có thể được xem là một kiểu dữ liệu. Trong UML, lớp được biểu diễn bằng một hình chữ nhật và gồm ba phần: tên lớp, các thuộc tính và các thao tác. Trong đó, phần dành cho các thuộc tính và các thao tác có thể không được hiển thị. Ký hiệu lớp - Lớp nội (Inner Class) Lớp nội là lớp được định nghĩa bên trong lớp khác. Các khái niệm về lớp nội được tồn tại trong các ngôn ngữ hướng đối tượng như Java, C++ (thông qua struct và enum) và C# (với các lớp thực sự bên trong) nhưng không phải là một khái niệm hướng đối tượng chuẩn. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn -9- UML không cung cấp cách biểu diễn lớp nội. Các ký hiệu sau đây được sử dụng để thể hiện lớp nội, vị trí của lớp nội được đặt trong phần khai báo phương thức của lớp mà nó được định nghĩa bên trong. A_Class An_Inner_Class Biểu diễn lớp nội - Các từ khóa định mức truy xuất (Access Specifiers) Trong Java, để có thể thấy được các thành phần khác nhau của đối tượng và khả năng truy cập vào chúng bằng các đối tượng khác nhau được điều khiển bằng cách sử dụng từ khóa định mức truy xuất. Quyền truy cập các phương thức và thuộc tính có thể được xác định bằng cách sử dụng ký hiệu trong bảng. Bảng liệt kê quyền truy cập và phạm vi của chúng Specifier Các lớp trong Các lớp trong các Các lớp con trong Các lớp con trong cùng một gói gói khác cùng một gói các gói khác Public Có thể truy cập Có thể truy cập Có thể truy cập Có thể truy cập Protected Có thể truy cập Không thể truy cập Có thể truy cập Có thể truy cập Friendly Có thể truy cập Không thể truy cập Có thể truy cập Không thể truy cập Private Không thể truy cập Không thể truy cập Không thể truy cập Không thể truy cập Static Đường gạch dưới một biến hoặc một phương thức của lớp chỉ ra nó là tĩnh. Trong ví dụ, phương thức getInstance là phương thức tĩnh của lớp FileLogger. Các đối tượng khách có thể gọi phương thức getInstance trong lớp FileLogger mà không cần tạo ra thể hiện của nó. Bảng ký hiệu truy cập Symbol Scope + Public # Protected - Private Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn - 10 - Biểu diễn phương thức tĩnh - Lớp trừu tượng / Phương thức trừu tượng (Abstract Class / Method) Một phương thức mà không có khai báo bên trong gọi là phương thức trừu tượng. Một lớp với ít nhất một phương thức trừu tượng được coi là lớp trừu tượng. Các đối tượng khác không thể tạo ra thể hiện của lớp trừu tượng. Một lớp con của lớp trừu tượng phải thực hiện cài đặt tất cả các phương thức trừu tượng của lớp trừu tượng hay được khai báo chính nó là một lớp trừu tượng. Lớp hay phương thức thể hiện bằng tên được in nghiêng là lớp hay phương thức trừu tượng. Lớp Creator trong hình là một lớp trừu tượng với một phương thức trừu tượng là factoryMethod. Biểu diễn lớp / phương thức trừu tượng - Ngoại lệ (Exception) Một mũi tên vẽ bằng nét đứt với một nhãn đặc trưng “throws” được sử dụng để cho biết cụ thể phương pháp ném một ngoại lệ. Các mũi tên chỉ từ phương thức tới lớp ngoại lệ. Cả hai phương pháp isValid và save trong hình biểu thị (có thể) ném ra một ngoại lệ kiểu java.rmi.RemoteException. Biểu diễn phương thức ném ra một ngoại lệ - Ghi chú (Note) Ghi chú đi kèm theo lược đồ UML cung cấp thông tin bổ sung cho một biểu tượng chẳng hạn như lời dẫn giải, các ràng buộc hoặc mã trình. Nói chung, ghi chú có thể gán với bất kỳ thành phần nào của lược đồ trong bất kỳ lược đồ UML nào. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn - 11 - Chi chú biểu diễn bằng hình chữ nhật gấp góc và được gắn vào bất kỳ thành phần nào của lược đồ UML bằng một đường nét đứt. Ví dụ sau đây cho thấy ghi chú được gắn với thuộc tính của một lớp. Ghi chú cung cấp bổ sung thêm thông tin - Khái quát hóa (Generalization) Khái quát hóa được sử dụng để miêu tả khái niệm thừa kế trong hướng đối tượng khi có một lớp cơ sở với hành vi thông thường và mỗi lớp có nguồn gốc của nó có chứa hành vi / chi tiết cụ thể. Trong hình, mũi tên rỗng đầu chỉ từ lớp con Shark/Whale đến lớp cha Fish thể hiện quan hệ khái quát hóa. Fish Shark Whale - Giao diện (Interface) Giao diện là tập hợp các thao tác được sử dụng để chỉ ra các dịch vụ của một lớp hay một thành phần. Mỗi giao diện thường mô tả một phần hành vi của lớp mà thấy được từ bên ngoài. Giao diện chỉ định nghĩa đặc tả cấu trúc bên trong mà không có cài đặt chúng. 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. Giao diện có thể được biểu diễn bằng hình chữ nhật giống như thiết lập lớp với dòng “interface” trên tên của giao diện. Hình sau thể hiện giao diện với tên là VisitorInterface Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn - 12 - - Hiện thực hóa (Realization) Hiện thực hóa là quan hệ giữa hai sự mô tả của cùng một phần tử mô hình – giữa đặc tả và cài đặt của nó, nhưng tại những mức trừu tượng khác nhau. Hiện thực hóa được sử dụng để biểu diễn cho sự cài đặt của một giao diện. Trong cả hai hình sau, lớp OrderVisitor thực hiện cài đặt giao diện đã được khai báo bởi VisitorInterface (Java) interface. - Phụ thuộc (Dependency) Quan hệ phụ thuộc biểu diễn mối quan hệ ngữ nghĩa giữa hai hoặc nhiều phần tử mô hình, trong đó việc thay đổi của thành phần đích có thể đòi hỏi sự thay đổi của thành phần nguồn. Lớp Order trong hình thực hiện phương thức execute của lớp DBUtil để thực hiện truy vấn SQL và do đó phụ thuộc vào nó. - Lớp kết hợp (Class Association) Lớp kết hợp quy định các mối liên hệ cấu trúc giữa các lớp. Khái niệm về tính nhiều trình bày sau đây có quan hệ rất chặt chẽ với lớp kết hợp.  Tính nhiều (Multiplicity) Khái niệm tính nhiều được sử dụng để chỉ ra số lượng thể hiện của một lớp có quan hệ với thể hiện của lớp khác. Bảng sau liệt kê các giá trị khác nhau có thể được sử dụng để cho biết tính nhiều. Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn - 13 - Ý nghĩa Tính nhiều 1 Không nhiều hơn một 0..1 Không hoặc một * Nhiều 0..* Không hoặc nhiều 1..* Một hoặc nhiều  Điều khiển được (Navigability) Khi lớp A chứa thông tin cần thiết thuộc phạm vi của lớp B, khi đó điều khiển là từ lớp A tới lớp B. Nói cách khác, lớp A biết lớp B nhưng không phải ngược lại. Trong hình, một thể hiện của lớp LogAbstraction chứa đối tượng LoggerBridge và có thể đạt được quyền điều khiển nó trực tiếp. Do đó đối tượng LoggerBridge chịu điều khiển từ thể hiện LogAbstraction.  Hợp thành (Composition) Lớp A chứa lớp B. Phát biểu này thể hiện quyền sở hữu mạnh của lớp A lớp toàn thể và lớp B - lớp bộ phận. Nói cách khác, lớp bộ phận không có ý nghĩa tồn tại nếu không có lớp toàn thể. Trong hình: - Một chi tiết đơn hàng là một phần của một đơn đặt hàng. - Một chi tiết đơn hàng không thể tồn tại mà không có một đơn đặt hàng. Consists of Order Part of 1 LineItem 1..*  Kết tập (Aggregation) Quan hệ này thấp hơn quan hệ hợp thành. Lớp toàn thể có vai trò quan trọng hơn lớp bộ phận nhưng không giống như trường hợp của quan hệ hợp thành, lớp bộ phận có thể tồn tại mà không cần có lớp toàn thể. Trong hình: Số hóa bởi Trung tâm Học liệu - Đại học Thái Nguyên http://www.lrc-tnu.edu.vn