Giáo trình Phân tích thiết kế hướng đối tượng với UML (Phần 2) - Nghề: Lập trình máy tính - Trình độ: Bậc cao

Nội dung text: Giáo trình Phân tích thiết kế hướng đối tượng với UML (Phần 2) - Nghề: Lập trình máy tính - Trình độ: Bậc cao

1. BÀI 5 Tên bài : HỆ THỐNG VÀ HÀNH VI ĐỐI TƯỢNG Mã bài : ITPRG3_16.5 Giới thiệu : Các thao tác và các thuộc tính của đối tựơng, phân tích hoạt động hệ thống, phân tích hành vi đối tượng, kiểm tra mô hình sẽ được trình bày trong bài này Mục tiêu thực hiện: Học xong bài này học viên có khả năng : - Phân tích các thao tác và các thuộc tính các lớp - Mô tả mục đích của các biểu đồ trạng thái và biểu đồ hoạt động - Đọc và giải thích các biểu đồ trạng thái - Đọc và giải thích các biểu đồ hoạt động trong UML - Phân tích tính bền vững và chất lượng của mô hình. Nội dung chính: I. Quan hệ kết tập (Aggregation) 1- Khái niệm kết tập: Kết tập là một trường hợp đặc biệt của liên hệ. Kết tập biểu thị rằng quan hệ giữa các lớp dựa trên nền tảng của nguyên tắc "một tổng thể được tạo thành bởi các bộ phận". Nó được sử dụng khi chúng ta muốn tạo nên một thực thể mới bằng cách tập hợp các thực thể tồn tại với nhau. Một ví dụ tiêu biểu của kết tập là chiếc xe ô tô gồm có bốn bánh xe, một động cơ, một khung gầm, một hộp số, v.v Quá trình ghép các bộ phận lại với nhau để tạo nên thực thể cần thiết được gọi là sự kết tập. Trong quá trình tìm lớp, kết tập sẽ được chú ý tới khi gặp các loại động từ “được tạo bởi", "gồm có", . Quan hệ kết tập không có tên riêng. Tên ngầm chứa trong nó là "bao gồm các thành phần". 2- Kí hiệu kết tập: Kí hiệu UML cho kết tập là đường thẳng với hình thoi (diamond) đặt sát lớp biểu thị sự kết tập (tổng thể). Một lớp tài khoản được tạo bởi các lớp chi tiết về khách hàng, các lệnh giao dịch đối với tài khoản cũng như các quy định của nhà băng. Quan hệ trên có thể được trình bày như sau: 94
2. Hình 5.1 - Quan hệ kết tập (1) Mỗi thành phần tạo nên kết tập (tổng thể) được gọi là một bộ phận (aggregates). Mỗi bộ phận về phần nó lại có thể được tạo bởi các bộ phận khác. Hình 5.2 - Quan hệ kết tập (2) Trong trường hợp tài khoản kể trên, một trong các bộ phận của nó là các chi tiết về khách hàng. Các chi tiết về khách hàng lại bao gồm danh sách chủ tài khoản, danh sách địa chỉ, các quy định về kỳ hạn cũng như các chi tiết khác khi mở tài khoản. 3- Kết tập và liên hệ: Khái niệm kết tập nảy sinh trong tình huống một thực thể bao gồm nhiều thành phần khác nhau. Liên hệ giữa các lớp mặt khác là mối quan hệ giữa các thực thể. Quan sát hình sau: 95
3. Hình 5.3 - Kết tập và liên hệ Một tài khoản được tạo bởi các chi tiết về khách hàng, các lệnh giao dịch đối với tài khoản cũng như các quy định của nhà băng. Khách hàng không phải là là bộ phận của tài khoản, nhưng có quan hệ với tài khoản. Nhìn chung, nếu các lớp được nối kết với nhau một cách chặt chẽ qua quan hệ "toàn thể – bộ phận" thì người ta có thể coi quan hệ là kết tập. Không có lời hướng dẫn chắc chắn và rõ ràng cho việc bao giờ nên dùng kết tập và bao giờ nên dùng liên hệ. Một lối tiệm cận nhất quán đi kèm với những kiến thức sâu sắc về phạm vi vấn đề sẽ giúp nhà phân tích chọn giải pháp đúng đắn. II. Khái quát hóa và chuyên biệt hóa (Generalization & Specialization) Hãy quan sát cấu trúc lớp trong biểu đồ sau: Hình 5.4- Chuyên biệt hoá (Specialization) Trong hình trên, tài khoản là khái niệm chung của các loại tài khoản khác nhau và chứa những đặc tả cần thiết cho tất cả các loại tài khoản. Ví dụ như nó có thể chứa số tài khoản và tên chủ tài khoản. Ta có thể có hai loại tài khoản đặc biệt suy ra từ dạng tài khoản chung 96
4. này, một loại mang tính kỳ hạn và một loại mang tính giao dịch. Yếu tố chia cách hai lớp này với nhau là các quy định chuyên ngành hay đúng hơn là phương thức hoạt động của hai loại tài khoản. Tương tự như vậy, tài khoản đầu tư trung hạn và dài hạn lại là những khái niệm chuyên biệt của khái niệm tài khoản có kỳ hạn. Mặt khác, tài khoản bình thường và tài khoản tiết kiệm là những trường hợp đặc biệt của loại tài khoản giao dịch. Loại cấu trúc lớp như thế được gọi là một cấu trúc hình cây hoặc cấu trúc phân cấp. Khi chúng ta dịch chuyển từ điểm xuất phát của cây xuống dưới, chúng ta sẽ gặp các khái niệm càng ngày càng được chuyên biệt hóa nhiều hơn. Theo con đường đi từ tài khoản đến tài khoản tiết kiệm, ta sẽ phải đi qua lớp tài khoản giao dịch. Lớp này tiếp tục phân loại các lớp chuyên biệt hóa cao hơn, tùy thuộc vào chức năng của chúng. 1- Kí hiệu khái quát hóa và chuyên biệt hóa Trong biểu đồ trên, các lớp trong một cấu trúc cây được nối với nhau bằng một mũi tên rỗng, chỉ từ lớp chuyên biệt hơn tới lớp khái quát hơn. Hình 5.5- Khái quát hóa Quá trình bắt đầu với một lớp khái quát để sản xuất ra các lớp mang tính chuyên biệt cao hơn được gọi là quá trình chuyên biệt hoá (Specialization) Chuyên biệt hóa: là quá trình tinh chế một lớp thành những lớp chuyên biệt hơn. Chuyên biệt hóa bổ sung thêm chi tiết và đặc tả cho lớp kết quả. Lớp mang tính khái quát được gọi là lớp cha (superclass), kết quả chuyên biệt hóa là việc tạo ra các lớp con (Subclass). Mặt khác, nếu chúng ta đi dọc cấu trúc cây từ dưới lên, ta sẽ gặp các lớp ngày càng mang tính khái quát cao hơn - Ví dụ từ lớp tài khoản tiết kiệm lên tới lớp tài khoản. Con đường bắt đầu từ một lớp chuyên biệt và khiến nó ngày càng mang tính khái quát cao hơn được gọi là quá trình khái quát hóa (Generalization). Lớp chuyên biệt ở đây được gọi là lớp con, trong ví dụ trên là tài khoản tiết kiệm, trong khi lớp khái quát kết quả được gọi là lớp cha. Chuyên biệt hóa và khái quát hóa là hai con đường khác nhau để xem xét cùng một mối quan hệ. Một lớp là lớp con của một lớp này có thể đóng vài trò là một lớp cha của lớp khác. 97
5. 2- Yếu tố phân biệt (Discriminatior) Để tạo một cấu trúc phân cấp, cần phải có một số thuộc tính làm nền tảng cho quá trình chuyên biệt hóa. Thuộc tính đó được gọi là yếu tố phân biệt (Discriminator). Với mỗi giá trị có thể gán cho yếu tố phân biệt trong lớp cha, ta sẽ có một lớp con tương ứng. Hình 5.6 - Yếu tố phân biệt (Discriminatior) Trong hình trên, yếu tố phân biệt trong lớp tài khoản là "loại tài khoản". Chúng ta giả thiết rằng chỉ có hai loại tài khoản, một mang tính kỳ hạn và một mang tính giao dịch. Theo đó, ta phải tạo ra hai lớp con, một cho các tài khoản mang tính kỳ hạn và một cho các tài khoản mang tính giao dịch. Trong mô hình đối tượng, không nhất thiết phải nêu bật yếu tố phân biệt. Yếu tố phân biệt luôn có mặt trong một cấu trúc phân cấp lớp cha/ con, dù có được nhấn mạnh trong mô hình đối tượng hay không. Mặc dầu vậy, để đảm bảo cho một mô hình được định nghĩa rõ ràng, trình bày yếu tố phân biệt vẫn luôn là công việc nên thực hiện. 2.1- Lớp trừu tượng Quan sát cấu trúc trong hình trên, ta thấy lớp tài khoản sẽ không bao giờ được thực thể hóa, có nghĩa là hệ thống sẽ không bao giờ tạo ra các đối tượng thuộc lớp này. Nguyên nhân là vì lớp tài khoản mang tính khái quát cao đến mức độ việc khởi tạo lớp này sẽ không có một ý nghĩa nào đáng kể. Lớp tài khoản mặc dù vậy vẫn đóng một vai trò quan trọng trong việc khái quát hóa các thuộc tính sẽ được cần đến trong các lớp dẫn xuất từ nó. Những loại lớp như thế được dùng để cung cấp một cây cấu trúc lớp và không có sự tồn tại đầy đủ ý nghĩa trong một mô hình thật sự ngoài đời, chúng được gọi là lớp trừu trượng (abstract class). 98
6. 2.2- Tạo lớp trừu tượng Các lớp trừu trượng là kết quả của quá trình khái quát hóa. Hãy quan sát ví dụ cấu trúc lớp sau đây. Lớp tài khoản đứng đầu cây cấu trúc và được gọi là lớp căn bản. Lớp căn bản của một cây cấu trúc chứa những thuộc tính đã được khái quát hóa và có thể được áp dụng cho mọi lớp dẫn xuất từ nó. Trong quá trình khái quát hóa, các thuộc tính được dùng chung trong các lớp chuyên biệt được đưa lên lớp cha. Lớp cha về cuối được tạo bởi các thuộc tính chung của tất cả các lớp dẫn xuất từ nó. Những lớp cha dạng như vậy trong rất nhiều trường hợp sẽ mang tính khái quát tuyệt đối và sẽ không theo đuổi mục đích khởi tạo, chúng có lối ứng xử giống như một thùng chứa (container) cho tất cả các thuộc tính chung của các lớp dẫn xuất. Những lớp như thế trong trường hợp chung thường là kết quả ánh xạ của những danh từ trừu tượng, là hệ quả của phương pháp sử dụng các danh từ để nhận diện lớp. Hình 5.7 - Tạo lớp trừu tượng Biểu đồ trên cho ta một ví dụ về khái quát hóa và các thuộc tính chung, nó chỉ ra nhiều lớp chuyên biệt. Chú ý rằng cứ theo mỗi mức chuyên biệt hóa lại có thêm các thuộc tính được bổ sung thêm cho các lớp, khiến chúng mang tính chuyên biệt cao hơn so với các lớp cha ở mức trừu tượng bên trên. Ví dụ lớp tài khoản có thuộc tính là số tài khoản và tên khách hàng. Đây là những thuộc tính hết sức chung chung. Tất cả các lớp dẫn xuất từ nó, dù là trực tiếp hay gián tiếp (ở các mức độ trừu tượng thấp hơn nữa), đều có quyền sử dụng các thuộc tính đó của lớp tài khoản. Các lớp tài khoản có kỳ hạn và tài khoản giao dịch là hai lớp chuyên biệt dẫn xuất từ lớp tài khoản. Chúng có những thuộc tính chuyên biệt riêng của chúng - ví dụ mức thời gian (duration) đối với lớp tài khoản có kỳ hạn và mức tiền tối thiểu đối với lớp tài khoản giao dịch – bên cạnh hai thuộc tính số tài khoản và tên khách hàng mà chúng thừa kế từ lớp tài khoản. Cũng tương tự như thế với tài khoản đầu tư ngắn hạn và tài 99
7. khoản đầu tư trung hạn là các loại lớp thuộc tài khoản có kỳ hạn, tài khoản tiết kiệm và tài khoản bình thường là các loại lớp thuộc lớp tài khoản giao dịch. 2.3- Lớp cụ thể (concrete class) Lớp cụ thể là những lớp có thể thực thể hóa. Như đã nói từ trước, các lớp cụ thể khi thực thể hóa được gọi là các đối tượng. Trong ví dụ trên, các lớp tài khoản đầu tư ngắn hạn và tài khoản đầu tư dài hạn có thể được thực thể hóa thành đối tượng. Tương tự đối với tài khoản tiết kiệm và tài khoản bình thường. 2.4- Tổng kết về phát triển cây cấu trúc Cơ chế dùng chung thuộc tính và thủ tục sử dụng nguyên tắc khái quát hóa được gọi là tính thừa kế (inheritance). Sử dụng tính thừa kế để tinh chế (refine) các lớp sẽ dẫn tới việc phát triển một cây cấu trúc. Nên phát hiện những ứng xử (behaviour) chung trong một loạt lớp rồi thể hiện nó thành một lớp cha. Sự khác biệt trong ứng xử của cùng một lớp sẽ dẫn tới việc tạo ra các lớp con. Khi phát triển cây cấu trúc, hãy quan sát ứng xử của các lớp. Trong trường hợp có một liên hệ tồn tại từ một lớp cụ thể đến tất cả các lớp con của một lớp cha, nên dịch chuyển liên hệ này lên lớp cha. Nếu tồn tại một liên hệ giữa một lớp nào đó và một lớp cha, hãy chuyên biệt hóa và nâng cao cấu trúc để xác định xem liệu liên hệ này có được áp dụng cho tất cả các lớp con của lớp cha nọ hay không. Nếu có thì gán nó vào lớp cha, nếu không thì dịch xuống cho những lớp con phù hợp. Trong khi tiến hành khái quát hóa, trọng tâm công việc là xác định các ứng xử chung trong một nhóm nhiều lớp chuyên biệt bậc trung. Khi đã xây dựng được một thủ tục hoặc một thuộc tính chung, nên kiểm tra lại xem chúng có thật sự là yếu tố chung của tất cả các lớp chuyên biệt trong phạm vi này. Khái quát hóa được áp dụng chỉ khi chúng ta có một tập hợp các lớp định nghĩa một loại đối tượng riêng biệt và có một số lượng lớn các ứng xử chung. Trọng tâm ở đây là tạo nên lớp cha chứa các ứng xử chung đó. Khi chuyên biệt hóa, ta đi tìm các sự khác biệt trong ứng xử để tạo các lớp con thích ứng. Có nghĩa là ta xem xét một lớp tồn tại, kiểm tra xem có phải tất cả các ứng xử của nó đều có khả năng áp dụng cho mọi đối tượng. Nếu không, ta lọc ra ứng xử không phải lúc nào cũng cần thiết và chia trường hợp nó ra thành các lớp con. Trọng tâm của chuyên biệt hóa là tạo các lớp con. Với cơ chế thừa kế, một lớp con sẽ kế thừa mọi thuộc tính à thủ tục của tất cả các lớp cha của nó. Hình sau làm rõ việc tạo cấu trúc lớp sử dụng tính khái quát. 100
8. Hình 5.8 - Phát triển hệ thống lớp (1) Thường xảy ra trường hợp tất cả các lớp con cùng tham gia vào một liên hệ hoặc kết tập. Trong trường hợp này nên tạo lớp cha định nghĩa liên hệ /kết tập đó. Hình sau giải thích thêm điểm này: Hình - Phát triển hệ thống lớp (2) III. Quan hệ phụ thuộc và nâng cấp (Dependency & Refinement) Bên cạnh liên hệ và khái quát hóa, UML còn định nghĩa hai loại quan hệ khác. Quan hệ phụ thuộc (Dependency) là một sự liên quan ngữ nghĩa giữa hai phần tử mô hình, một mang tính độc lập và một mang tính phụ thuộc. Mọi sự thay đổi trong phần tử độc lập sẽ ảnh hưởng đến phần tử phụ thuộc. Phần tử mô hình ở đây có thể là một lớp, một gói (package), một trường hợp sử dụng,.v.v Có thể nêu một vài cí dụ cho sự phụ thuộc như: một lớp lấy tham số là đối tượng của một lớp khác, một lớp truy nhập một đối tượng toàn cục của một 101
9. lớp khác, một lớp gọi một thủ tục thuộc thuộc một lớp khác. Trong tất cả các trường hợp trên đều có một sự phụ thuộc của một lớp này vào một lớp kia, mặc dù chúng không có liên hệ rõ ràng với nhau. Quan hệ phụ thuộc được thể hiện bằng đường thẳng gạch rời (dashed line) với mũi tên (và có thể thêm một nhãn) giữa các phần tử mô hình. Nếu sử dụng nhãn thì nó sẽ là một khuôn mẫu (stereotype), xác định loại phụ thuộc. Hình sau chỉ ra một sự phụ thuộc dạng "friend", có nghĩa rằng một phần tử mô hình nhận được quyền truy cập đặc biệt tới cấu trúc nội bộ của phần tử thứ hai (thậm chí tới cả những phần mang tính nhìn thấy là private). Hình 5.9- Một quan hệ phụ thuộc giữa các lớp Nâng cấp (Refinement) là một quan hệ giữa hai lời miêu tả của cùng một sự vật, nhưng ở những mức độ trừu tượng hóa khác nhau. Nâng cấp có thể là mối quan hệ giữa một loại đối tượng và lớp thực hiện nó. Các nâng cấp thường gặp khác là quan hệ giữa một lớp phân tích (trong mô hình phân tích) và một lớp thiết kế (trong mô hình thiết kế) đều mô hình hóa cùng một thứ, quan hệ giữa một lời miêu tả có mức trừu tượng hóa cao và một lời miêu tả có mức trừu tượng hóa thấp (ví dụ một bức tranh khái quát của một sự cộng tác động và một biểu đồ chi tiết của cũng cộng tác đó). Quan hệ nâng cấp còn được sử dụng để mô hình hóa nhiều mức thực thi của cùng một thứ (một thực thi đơn giản và một thực thi phức tạp hơn, hiệu quả hơn). Quan hệ nâng cấp được thể hiện bằng đường thẳng gạch rời (dashed line) với mũi tên rỗng. Hình 5.10 - Quan hệ nâng cấp Quan hệ nâng cấp được sử dụng trong việc phối hợp mô hình. Trong các dự án lớn, mọi mô hình đều cần phải được phối hợp với nhau. Phối hợp mô hình được sử dụng nhằm mục đích: . Chỉ ra mối liên quan giữa các mô hình ở nhiều mức độ trừu tượng khác nhau. . Chỉ ra mối liên quan giữa các mô hình ở nhiều giai đoạn khác nhau (phân tích yêu cầu, phân tích, thiết kế, thực thi, ). . Hỗ trợ việc quản trị cấu hình. 102
10. . Hỗ trợ việc theo dõi trong mô hình. IV. Nâng cấp mô hình qua các vòng lặp kế tiếp Cho tới thời điểm này, chúng ta đi qua các bước công việc phân tích căn bản và tạo nên phiên bản đầu tiên của mô hình đối tượng. Mô hình này cần phải được lấy làm mục tiêu cho các vòng lặp nâng cấp tiếp theo. Công việc nâng cấp có thể được thực hiện bằng cách đưa mô hình qua tất cả các giai đoạn phát triển mô hình đối tượng một lần nữa. Lần này, những kiến thức thu được trong vòng phát triển đầu sẽ tỏ ra rất hữu dụng. Khi nâng cấp mô hình cần chú ý đến các bước sau: a) Nghiên cứu các lớp để tìm các thuộc tính và thủ tục không đồng dạng (dissimilar). Nếu có, xẻ lớp thành các thành phần để tạo tính đồng nhất (harmony) trong lớp. Ví dụ với một lớp đảm nhận hai vai trò khác nhau, hãy xẻ lớp thành các lớp kết quả với những thủ tục được xác định rõ ràng. b) Nếu phát hiện thấy một chức năng không hướng tới một lớp đích nào thì đó là triệu chứng thiếu lớp. Hãy bổ sung lớp thiếu và đưa thủ tục kể trên vào lớp đó. c) Khái quát hóa là còn chưa đủ độ nếu có các liên hệ trùng lặp (nhiều liên hệ cùng định nghĩa một quan hệ). Trong trường hợp này, cần tạo lớp cha để kết hợp các mối liên hệ đó. d) Nếu một vai trò mang một ý nghĩa đặc biệt quan trọng đối với hệ thống thì thường nó cần một lớp riêng. Một lựa chọn khác là biến liên hệ định nghĩa vai trò này thành một lớp liên hệ. e) Nếu một lớp thiếu cả thuộc tính lẫn thủ tục và / hoặc liên hệ thì rất có thể đây là một lớp không cần thiết. Hãy loại bỏ những lớp đó nếu có thể. f) Hãy rà sát toàn bộ hệ thống để tìm những vai trò giữa các lớp còn chưa được thể hiện. Nếu có, đây là triệu chứng thiếu liên hệ. g) Nếu có một liên hệ giữa các đối tượng nhưng lại chẳng được thủ tục nào sử dụng tới thì rất có thể đây là một liên hệ không cần thiết. Ví dụ ta đã xác định một liên hệ giữa nhân viên thu ngân và khách hàng nhưng lại không có thủ tục nào được định nghĩa giữa hai người. Trong trường hợp này, rất có thể liên hệ đó là không cần thiết. Một số mách bảo thực tế: Nghiên cứu để hiểu thấu đáo vấn đề cần giải quyết: Khi xây dựng mô hình đối tượng, không nên bắt đầu bằng cách viết ra các cấu trúc lớp, các mối liên hệ cũng như những mối quan hệ thừa kế lộ rõ trên bề mặt và đập thẳng vào mắt chúng ta. Hãy dành thời gian nghiên cứu kỹ bản chất vấn đề. Mô hình đối tượng phải được thiết kế để phù hợp với giải pháp cho vấn đề mà chúng ta nhắm tới. Cẩn thận khi chọn tên: Tên cần được chọn một cách cẩn thận bởi nó chứng nhận sự tồn tại các thực thể. Tên cần phải chính xác, ngắn gọn, tránh gây bàn cãi. Tên phải thể hiện tổng thể đối tượng chứ không chỉ nhắm tới một khía cạnh nào đó của đối tượng. 103
11. Bất cứ nơi nào có thể, hãy chọn những tên nào bao chứa các danh từ chuyên ngành quen thuộc đối với người sử dụng. Những tên tạo ra những hình xa vời đối với người sử dụng, hoặc các thực thể được đặt tên một cách tồi tệ rất dễ gây ra nhầm lẫn. Cần giữ cho mô hình đối tượng được đơn giản: Hãy kháng cự lại xu hướng tạo ra các mô hình phức tạp, chúng chỉ mang lại sự nhầm lẫn, bối rối. Trong vòng đầu của quy trình mô hình hóa đối tượng, hãy xác định các mối liên hệ căn bản và gạt ra ngoài các chi tiết, việc xem xét tới các số lượng thành phần tham gia (Cardinality) trong quan hệ được để dành cho giai đoạn sau; rất có thể là ở vòng thứ hai. Tốt nhất là các chi tiết phản ánh số lượng các thành phần tham gian trong quan hệ chỉ được bổ sung thêm vào trong vòng thứ hai hoặc vòng thứ ba của công việc mô hình hóa đối tượng. Thường thường, người ta thấy những phiên bản đầu tiên của mô hình thường chỉ chứa các mối liên hệ với số lượng là từ 0-tới-0; 0-tới-1, 1- tới-1; 1-tới-nhiều. Nên sử dụng các mối liên hệ hạn định bất cứ khi nào có thể. Tránh khái quát hóa quá nhiều. Thường chỉ nên hạn chế ở ba tầng khái quát. Hãy nghiên cứu thật kỹ các mối liên hệ 1-tới-nhiều. Chúng thường có thể được chuyển thành các quan hệ 1-tới-0 hoặc 1-tới-1. Tất cả các mô hình cần phải được lấy làm đối tượng cho việc tiếp tục nâng cấp. Nếu không thực hiện những vòng nâng cấp sau đó, rất có thể mô hình của chúng ta sẽ thiếu hoàn chỉnh. Động tác để cho những người khác xem xét lại mô hình là rất quan trọng. Thường sự liên quan quá cận kề với mô hình sẽ khiến chúng ta mù lòa, không nhận những ra khiếm khuyết của nó. Một cái nhìn vô tư trong trường hợp này là rất cần thiết. Không nên mô hình hóa các mối liên hệ thành thuộc tính. Nếu điều này xảy ra, ta thường có thể nhận thấy qua triệu chứng là mô hình thiếu liên hệ. Thêm vào đó, đã có lúc ta bỏ qua sự cần thiết của một yếu tố hạn định. Việc viết tài liệu cho mô hình là vô cùng quan trọng. Các tài liệu cần phải nắm bắt thấu đáo những nguyên nhân nằm đằng sau mô hình và trình bày chúng chính xác như có thể. V. Chất lượng mô hình Làm sao để biết được mô hình là tốt hay chưa tốt? Một ngôn ngữ mô hình hóa có thể cung cấp ngữ pháp và ngữ nghĩa cho ta làm việc, nhưng nó không cho ta biết liệu một mô hình vừa được tạo dựng nên là tốt hay không. Yếu tố này mở ra một vấn đề quan trọng trong việc xác định chất lượng mô hình. Điều chủ chốt khi chúng ta thiết kế mô hình là thứ chúng ta muốn nói về hiện thực. Mô hình mang lại sự diễn giải cho những gì mà chúng ta nghiên cứu (hiện thực, một viễn cảnh ). Trong một mô hình, yếu tố quan trọng bật nhất là phải nắm bắt được bản chất của vấn đề. Trong một hệ thống tài chính, chúng ta thường mô hình hóa các hóa đơn chứ không phải các món nợ. Trong đa phần doanh nghiệp, bản thân hóa đơn không thật sự có tầm quan 104
12. trọng đến như vậy, yếu tố quan trọng ở đây là các món nợ. Một hóa đơn chỉ là một sự thể hiện của một món nợ, nhưng ta cần phải mô hình hóa làm sao để phản ánh điều đó. Một khái niệm khác là một tài khoản ở nhà băng. Trong những năm 70 và 80 đã có rất nhiều mô hình thể hiện tài khoản nhà băng. Khách hàng (chủ nhân của tài khoản tại nhà băng) được coi là một thành phần của tài khoản này (một tài khoản nhà băng được mô hình hóa như là một lớp hoặc là một thực thể và một khách hàng là một thuộc tính). Khó khăn đầu tiên xảy ra là nhà băng không thể xử lý tài khoản có nhiều chủ. Vấn đề thứ hai là nhà băng không thể tạo ra các chiến lược maketing nhắm tới những khách hàng không có tài khoản trong nhà băng chỉ bởi vì họ không có địa chỉ. Vì vậy, một trong những khía cạnh của chất lượng mô hình là tính thích hợp của mô hình đó. Một mô hình thích hợp phải nắm bắt các khía cạnh quan trọng của đối tượng nghiên cứu. Những khía cạnh khác trong việc đánh giá chất lượng là mô hình phải dễ giao tiếp, phải có một mục tiêu cụ thể, dễ bảo quản, mang tính vững bền và có khả năng tích hợp. Nhiều mô hình của cùng một hệ thống nhưng có các mục đích khác nhau (hoặc là hướng nhìn khác nhau) phải có khả năng tích hợp được với nhau. Dù là sử dụng phương pháp nào hoặc ngôn ngữ mô hình hóa nào, ta vẫn còn phải đối mặt với các vấn đề khác. Khi tạo dựng mô hình, chúng ta trở thành một phần của doanh nghịêp, có nghĩa là chúng ta cần phải quan sát hiệu ứng sự can thiệp của chúng ta vào doanh nghiệp. Yếu tố quan trọng là cần phải xử lý tất cả các khía cạnh của sự can thiệp đó ví dụ như về chính sách, văn hóa, cấu trúc xã hội và năng suất. Nếu không làm được điều này, rất có thể ta không có khả năng phát hiện và nắm bắt tất cả những đòi hỏi cần thiết từ phía khách hàng (cần chú ý rằng những phát biểu yêu cầu được đưa ra không phải bao giờ cũng chính xác là những gì khách hàng thực sự cần). Hãy đặc biệt chú ý đến các vấn đề với chính sách nội bộ, các mẫu hình xã hội, các cấu trúc không chính thức và các thế lực bao quanh khách hàng. 1- Thế nào là một mô hình tốt? Một mô hình sẽ là một mô hình tốt nếu ta có khả năng giao tiếp với nó, nếu nó phù hợp với các mục đích của nó và nếu chúng ta đã nắm bắt được những điểm cốt yếu của vấn đề. Một mô hình tốt đòi hỏi thời gian xây dựng; bình thường ra nó được tạo bởi một nhóm phát triển, được thành lập với một mục đích cụ thể. Một trong những mục đích này có thể là huy động toàn bộ lực lượng để phát hiện ra các yêu cầu của một cơ quan. Một mục đích khác rất có thể là mô hình hóa một đặc tả yêu cầu, thực hiện một giai đoạn phân tích, hay vẽ một bản thiết kế kỹ thuật cho một hệ thống thông tin. Khi các cá nhân khác nhau được tập hợp thành nhóm, động tác này cần phải được thực hiện tập trung vào mục tiêu định trước. Các nhóm để mô hình hóa một doanh nghịêp hoặc là một hệ thống thông tin rất có thể được tạo bởi khách hàng, chuyên gia mô hình hóa và chuyên gia ứng dụng. 2- Ta có thể giao tiếp với mô hình? Tại sao mô hình lại phải là thứ dễ giao tiếp? Tất cả các dự án, dù lớn hay nhỏ, đều cần phải được giao tiếp. Con người ta nói chuyện với nhau. Họ đọc các tài liệu của nhau và thảo luận các nội dung của chúng. Sáng kiến khởi thủy nằm đằng sau bất kỳ một mô hình nào cũng là 105
13. để tạo ra khả năng giao tiếp với chúng. Nếu chúng ta tạo ra các mô hình mà không ai đọc nổi, hiểu nổi, thì đó là việc làm vô ý nghĩa. Mô hình chẳng phải được tạo ra bởi người dẫn đầu một phương pháp hoặc người dẫn đầu một dự án ra lệnh. Mô hình được tạo ra để phục vụ cho việc giao tiếp và tập hợp các cố gắng của chúng ta để đạt đến năng suất, hiệu quả và chất lượng cao như có thể. 3- Mô hình có phù hợp với mục đích của nó không? Một mô hình hình cần phải có một mục đích rõ ràng, sao cho ai dùng nó cũng nhận được ra. Tất cả các mô hình đều có mục đích, nhưng thường mục đích này là ngầm ẩn, và điều này khiến cho việc sử dụng và hiểu nó trở nên khó khăn. Các mô hình phân tích và mô hình thiết kế có thể là mô hình của cùng một hệ thống, nhưng chúng vẫn là những mô hình khác nhau và tập trung vào các chủ đề khác nhau (hay là chi tiết khác nhau). Cần phải xác định rõ ràng mục đích cho mỗi mô hình để có thể kiểm tra và phê duyệt nó. Nếu không có mục đích rõ ràng, chúng ta ví dụ rất có thể sẽ thẩm tra một mô hình hình phân tích như thể nó là một mô hình thiết kế. 4- Nắm bắt những điểm trọng yếu Nhiều mô hình chỉ bao gồm các tài liệu của doanh nghiệp – ví dụ như các hóa đơn, những thông tin nhận được, các hợp đồng bảo hiểm. Nếu mô hình chỉ là sự bao gồm các tài liệu thì điều gì sẽ xảy ra nếu doanh nghiệp thay đổi? Đây là một vấn đề rất quan trọng trong thực tế. Chúng ta cần thiết phải nắm bắt bản chất của doanh nghiệp (tạo nên phần nhân) và mô hình xoay quanh các khái niệm thiết yếu đó để có khả năng xử lý các thay đổi một cách thích hợp. Hãy mô hình hóa phần nhân của doanh nghiệp và sau đó mới đến một mô hình diễn giải phần nhân đó. Một khi phần nhân đã được mô hình hóa, những thay đổi nho nhỏ trong doanh nghiệp có thể được xử lý qua việc sửa đổi các lớp diễn giải các loại đối tượng thuộc phần nhân (ví dụ như các hóa đơn là một sự diễn giải của các món nợ). 5- Phối hợp các mô hình Các mô hình khác nhau của cùng một hệ thống phải có khả năng được kết hợp và liên quan đến nhau. Một trong các khía cạnh của phối hợp mô hình là sự tích hợp. Tích hợp có nghĩa là một nhóm các mô hình cùng chung mục đích và thể hiện cùng một thứ (mặc dù chúng có thể có nhiều hướng nhìn khác nhau, ví dụ như mô hình động, mô hình chức năng, mô hình tĩnh), thì chúng phải có khả năng được ráp lại với nhau mà không làm nảy sinh mâu thuẫn. Quan hệ giữa các mô hình ở những mức độ trừu tượng khác nhau là một khía cạnh quan trọng khác. Nó là một trong những chìa khóa dẫn đến khả năng có thể theo dõi bước phát triển của các phần tử khác nhau, phục vụ cho công nghệ lập trình. Quan hệ giữa các mức độ trừu tượng khác nhau có thể được thể hiện bằng quan hệ nâng cấp trong UML. Điều đó có nghĩa là các mô hình sẽ được phối hợp tại mỗi một mức độ trừu tượng cũng như được phối hợp giữa các mức độ trừu tượng khác nhau. 106
14. 6- Độ phức tạp của mô hình Ngay cả khi các mô hình của chúng ta dễ dàng giao tiếp, có một mục đích rõ ràng, nắm bắt được những điểm trọng yếu trong phạm vi vấn đề và có thể được phối hợp với nhau, ta vẫn có thể gặp khó khăn nếu mô hình quá phức tạp. Những mô hình cực kỳ phức tạp sẽ khó nghiên cứu, khó thẩm tra, khó phê duyệt và khó bảo trì. Sáng kiến tốt là hãy bắt đầu với một mô hình đơn giản, và sau đó chi tiết hóa nhiều hơn bằng cách sử dụng việc phối hợp mô hình. Nếu bản chất phạm vi vấn đề của chúng ta là phức tạp, hãy xẻ mô hình thành nhiều mô hình khác nhau (sử dụng các tiểu mô hình – tức là các gói) và cố gắng để qui trình này có thể kiểm soát được tình huống. VI. Tóm tắt về mô hình đối tượng Khi tạo mô hình là chúng ta diễn giải các chi tiết về những gì mà chúng ta nghiên cứu, thế nhưng một yếu tố rất quan trọng là mô hình phải nắm bắt được những điểm trọng yếu của đối tượng nghiên cứu. Một đối tượng là một thứ gì đó mà chúng ta có thể nói về và có thể xử lý trong một số phương thức nào đó. Một đối tượng tồn tại trong thế giới thực (hoặc nói cho chính xác hơn là trong sự hiểu biết của chúng ta về thế giới thực). Một đối tượng có thể là một thành phần của một hệ thống nào đó trong thế giới – một chiếc máy, một tổ chức, một doanh nghịêp. Một lớp là lời miêu tả từ 0, 1 hoặc nhiều đối tượng với cùng lối ứng xử. Lớp và đối tượng được sử dụng để bàn luận về các hệ thống. Khi chúng ta mô hình hóa, chúng ta sử dụng một ngôn ngữ mô hình hóa ví dụ như UML, cung cấp cho chúng ta ngữ pháp và ngữ nghĩa để tạo dựng mô hình. Ngôn ngữ mô hình hóa mặc dù vậy không thể cho chúng ta biết liệu chúng ta đã tạo ra một mô hình tốt hay không. Chất lượng mô hình cần phải được chú ý riêng biệt, điều đó có nghĩa là tất cả các mô hình cần phải có một mục đích rõ ràng và chính xác và chúng phải nắm bắt được bản chất của đối tượng nghiên cứu. Tất cả các mô hình cần phải được làm sao để dễ giao tiếp, dễ thẩm tra, phê duyệt và bảo trì. UML cung cấp mô hình tĩnh, động và theo chức năng. Mô hình tĩnh được thể hiện qua các biểu đồ lớp, bao gồm các lớp và mối quan hệ giữa chúng. Quan hệ có thể là liên hệ, khái quát hoá, phụ thuộc hoặc là nâng cấp. Một mối quan hệ liên hệ là một sự nối kết giữa các lớp, có nghĩa là sự nối kết giữa các đối tượng của các lớp này. Khái quát hóa là quan hệ giữa một phần tử mang tính khái quát hơn và một phần tử mang tính chuyên biệt hơn. Phần tử mang tính chuyên biệt hơn có thể chỉ chứa các thông tin bổ sung. Một thực thể (một đối tượng là một thực thể của một lớp) của phần tử chuyên biệt hơn có thể được sử dụng bất cứ nơi nào mà thực thể của phần tử khái quát hơn được cho phép. Phụ thuộc là mối quan hệ giữa hai phần tử, một mang tính độc lập và một mang tính phụ thuộc. Mỗi thay đổi trong phần tử độc lập sẽ gây tác động đến phần tử phụ thuộc. Một quan hệ nâng cấp là một quan hệ giữa hai lời miêu tả của cùng một thứ nhưng ở những mức độ trừu tượng khác nhau. Câu hỏi và bài tập: 1. Kết tập biểu thị rằng quan hệ giữa các lớp dựa trên nền tảng của nguyên tắc "một tổng thể được tạo thành bởi các bộ phận" 107
15. 2. Khái quát hoá được sử dụng để tạo các lớp con? 3. Chuyên biệt hoá bổ sung thêm chi tiết và đặc tả cho lớp kết quả? Bài tập thực hành : xem phần nội dung thực hành trang 160 108
16. BÀI 6 Tên bài : THIẾT KẾ HỆ THỐNG Mã bài : ITPRG3_16.6 Giới thiệu : Nội dung bài trình bày kiến trúc phần mềm, thiết kế một kiến trúc hệ thống, các cơ chế chính Mục tiêu thực hiện: Học xong bài này học viên có khả năng : - Hiểu biết về kiến trúc hệ thống. - Liệt kê các phần tử của kiến trúc mẫu 4+1. - Sử dụng các biểu đồ thành phần và triển khai. - Hiểu biết về các cơ chế chính. - Nội dung chính: I. Kiến trúc phần mềm Sự cần thiết có mô hình động (Dynamic model) Mô hình đối tượng và quá trình phát triển nó là trọng tâm của những cuộc thảo luận trong chương trước. Mô hình đối tượng định nghĩa hệ thống theo khái niệm các thành phần tĩnh. Mô hình đối tượng miêu tả ứng xử mang tính cấu trúc và chức năng của các lớp. Mặc dầu vậy, để mô hình hóa sự hoạt động thật sự của một hệ thống và trình bày một hướng nhìn đối với hệ thống trong thời gian hệ thống hoạt động, chúng ta cần tới mô hình động (dynamic model). Trong UML, mô hình động đề cập tới các trạng thái khác nhau trong vòng đời của một đối tượng thuộc hệ thống. Phương thức ứng xử của một hệ thống tại một thời điểm cụ thể sẽ được miêu tả bằng các điều kiện khác nhau ấn định cho sự hoạt động của nó. Một yếu tố hết sức quan trọng là cần phải hiểu cho được hệ thống sẽ đáp lại những kích thích từ phía bên ngoài ra sao, có nghĩa là chúng ta cần phải xác định và nghiên cứu những chuỗi các thủ tục sẽ là hệ quả của một sự kích thích từ ngoài. Cho việc này, ta cần tới mô hình động bởi trọng tâm của mô hình này là lối ứng xử phụ thuộc vào thời gian của các đối tượng trong hệ thống. Chúng ta cần tới mô hình động bởi chúng ta cần thể hiện sự thay đổi xảy ra trong hệ thống dọc theo thời gian chạy. Công cụ miêu tả mô hình động là không thể thiếu ví dụ trong trường hợp các đối tượng trải qua nhiều giai đoạn khác nhau trong thời gian hệ thống hoạt động. Điều đó có nghĩa là mặc dù đối tượng được tạo ra một lần, nhưng các thuộc tính của chúng chỉ dần dần từng bước nhận được giá trị. Ví dụ như một tài khoản đầu tư có kỳ hạn được tạo ra, nhưng tổng số tiền lãi cộng dồn của nó chỉ được tăng lên dần dần theo thời gian. Các mô hình động cũng là yếu tố hết sức cần thiết để miêu tả ứng xử của một đối tượng khi đưa ra các yêu cầu hoặc thực thi các tác vụ. Cả tác vụ lẫn dịch vụ, theo định nghĩa, đều là các hoạt động động và vì thế mà chỉ có thể được biểu diễn qua một mô hình động. II. Thiết kế kiến trúc Các thành phần của mô hình động 109
17. Đối tượng trong các hệ thống giao tiếp với nhau, chúng gửi thông điệp (message) đến nhau. Ví dụ một đối tượng khách hàng là John gửi một thông điệp mua hàng đến người bán hàng là Bill để làm một việc gì đó. Một thông điệp thường là một lệnh gọi thủ tục mà một đối tượng này gọi qua một đối tượng kia. Các đối tượng giao tiếp với nhau ra sao và hiệu ứng của sự giao tiếp như thế được gọi là khía cạnh động của một hệ thống, ý nghĩa của khái niệm này là câu hỏi: các đối tượng cộng tác với nhau qua giao tiếp như thế nào và các đối tượng trong một hệ thống thay đổi trạng thái ra sao trong thời gian hệ thống hoạt động. Sự giao tiếp trong một nhóm các đối tượng nhằm tạo ra một số các lệnh gọi hàm được gọi là tương tác (interaction), tương tác có thể được thể hiện qua ba loại biểu đồ: biểu đồ tuần tự (sequence Diagram), biểu đồ cộng tác (collaboration Diagram) và biểu đồ hoạt động (activity Diagram). Trong chương này, chúng ta sẽ đề cập tới bốn loại biểu đồ động của UML: . Biểu đồ trạng thái: miêu tả một đối tượng có thể có những trạng thái nào trong vòng đời của nó, ứng xử trong các trạng thái đó cũng như các sự kiện nào gây ra sự chuyển đổi trạng thái, ví dụ, một tờ hóa đơn có thể được trả tiền (trạng thái đã trả tiền) hoặc là chưa được trả tiền (trạng thái chưa trả tiền). . Biểu đồ tuần tự: miêu tả các đối tượng tương tác và giao tiếp với nhau ra sao. Tiêu điểm trong các biểu đồ tuần tự là thời gian. Các biểu đồ tuần tự chỉ ra chuỗi của các thông điệp được gửi và nhận giữa một nhóm các đối tượng, nhằm mục đích thực hiện một số chức năng. . Biểu đồ cộng tác: cũng miêu tả các đối tượng tương tác với nhau ra sao, nhưng trọng điểm trong một biểu đồ cộng tác là sự kiện. Tập trung vào sự kiện có nghĩa là chú ý đặc biệt đến mối quan hệ (nối kết) giữa các đối tượng, và vì thế mà phải thể hiện chúng một cách rõ ràng trong biểu đồ. . Biểu đồ hoạt động: là một con đường khác để chỉ ra tương tác, nhưng chúng tập trung vào công việc. Khi các đối tượng tương tác với nhau, các đối tượng cũng thực hiện các tác vụ, tức là các hoạt động. Những hoạt động này cùng thứ tự của chúng được miêu tả trong biểu đồ hoạt động. Vì biểu đồ tuần tự, biểu đồ cộng tác lẫn biểu đồ hoạt động đều chỉ ra tương tác nên thường bạn sẽ phải chọn nên sử dụng biểu đồ nào khi lập tài liệu cho một tương tác. Quyết định của bạn sẽ phụ thuộc vào việc khía cạnh nào được coi là quan trọng nhất. Ngoài cấu trúc tĩnh và ứng xử động, hướng nhìn chức năng cũng có thể được sử dụng để miêu tả hệ thống. Hướng nhìn chức năng thể hiện các chức năng mà hệ thống sẽ cung cấp. Trường hợp sử dụng chính là các lời miêu tả hệ thống theo chức năng; chúng miêu tả các tác nhân có thể sử dụng hệ thống ra sao. Như đã đề cập từ trước, trường hợp sử dụng bình thường ra được mô hình hóa trong những giai đoạn đầu tiên của quá trình phân tích, nhằm mục đích miêu tả xem tác nhân có thể muốn sử dụng hệ thống như thế nào. Mô hình trường hợp sử dụng chỉ nên nắm bắt duy nhất khía cạnh tác nhân sử dụng hệ thống, không nên đề cập khía cạnh hệ thống được xây dựng bên trong ra sao. Lớp và các tương tác trong hệ thống thực hiện trường hợp sử dụng. Tương tác được miêu tả bởi các biểu đồ tuần tự, biểu đồ cộng tác và hoặc/và biểu đồ hoạt động, tức là có một sự nối kết giữa hướng nhìn chức năng và hướng nhìn động của hệ thống. Các lớp được sử dụng trong việc thực thi các trường hợp sử dụng được mô hình hóa và miêu tả qua các biểu đồ lớp và biểu đồ trạng thái (một biểu đồ trạng thái sẽ được đính kèm cho một lớp, một hệ thống con hoặc là một hệ thống). Trường hợp sử dụng và các mối quan hệ của chúng đến tương tác đã được miêu tả trong chương 3 (trường hợp sử dụng). Nhìn chung, một mô hình động miêu tả năm khía cạnh căn bản khác nhau: 110
18. Hình 6.1- Các thành phần của mô hình động Các thành phần kể trên sẽ được đề cập chi tiết hơn trong các phần sau. Ngoài ra, một mô hình động cũng còn được sử dụng để xác định các nguyên tắc chuyên ngành (business rule) cần phải được áp dụng trong mô hình. Nó cũng được sử dụng để ấn định xem các nguyên tắc đó được đưa vào những vị trí nào trong mô hình. Một vài ví dụ cho những nguyên tắc chuyên ngành cần phải được thể hiện trong mô hình động: . Một khách hàng không được quyền rút tiền ra nếu không có đủ mức tiền trong tài khoản. . Những món tiền đầu tư có kỳ hạn không thể chuyển sang một tên khác trước khi đáo hạn. . Giới hạn cao nhất trong một lần rút tiền ra bằng thẻ ATM là 500 USD. III. Các cơ chế chính 1. Ưu điểm chính của mô hình động: Bất cứ khi nào có những ứng xử động cần phải được nghiên cứu hoặc thể hiện, chúng ta sẽ phải dùng đến mô hình động. Mô hình động đóng một vai trò vô cùng quan trọng trong những trường hợp như: . Các hệ thống mang tính tương tác cao . Hệ thống có sử dụng các trang thiết bị ngoại vi có thể gọi nên các ứng xử của hệ thống. Mô hình động không tỏ ra thật sự hữu hiệu trong trường hợp của các hệ thống tĩnh. Ví dụ một hệ thống chỉ nhằm mục đích nhập dữ liệu để lưu trữ vào một ngân hàng dữ liệu. Một mô hình động tập trung vào các chuỗi tương tác (biểu đồ cộng tác) và vào yếu tố thời gian của các sự kiện (biểu đồ tuần tự). Một mô hình động có thể được sử dụng cho mục đích thể hiện rõ ràng theo thời gian hoạt động của hệ thống nếu trong thời gian này có những đối tượng: 111
19. . Được tạo ra . Bị xóa đi . Được lưu trữ . Bị hủy Hãy quan sát trường hợp rút tiền mặt và tương tác của khách hàng đối với nhà băng: . Khách hàng điền tất cả các chi tiết cần thiết vào giấy yêu cầu rút tiền mặt. . Khách hàng đưa giấy yêu cầu đó cho một nhân viên phát thẻ xếp hàng. . Nhân viên phát thẻ ghi số của giấy yêu cầu rút tiền vào danh sách. . Động tác ghi số của giấy yêu cầu rút tiền được thực hiện tuần tự, tương ứng với những số thẻ tuần tự được phát ra. . Một tấm thẻ xếp hàng (token) được trao cho khách hàng. . Khách hàng đi vào hàng xếp, chờ nhân viên bên casse gọi đúng số thẻ của mình. . Song song với quá trình chờ của khách hàng, giấy yêu cầu rút tiền của anh ta trải qua nhiều giai đoạn trong nội bộ nhà băng. . Chữ ký của khách hàng trên giấy yêu cầu rút tiền được thẩm tra. . Giấy yêu cầu được xem xét về phương diện số tài khoản và mức tiền trong tài khoản. . Nếu một trong hai điều kiện trên không được thỏa mãn, quá trình rút tiền mặt sẽ bị chặn lại hoặc là được sửa đổi và tiếp tục. . Khi cả hai điều kiện nêu trên được thỏa mãn, giấy yêu cầu rút tiền mặt sẽ được đưa đến cho nhân viên ngồi bên casse, nơi khách hàng sẽ được gọi tới tuần tự dưạ theo số thẻ xếp hàng. . Nhân viên bên casse đưa tiền mặt cho khách hàng. Lối ứng xử trong việc rút tiền mặt là mang tính động. Suốt quá trình rút tiền mặt, tương tác và trình tự của quá trình phụ thuộc vào một số các điều kiện xác định. Loại ứng xử này không thể được thể hiện qua mô hình đối tượng, đây là trường hợp ta cần đến mô hình động. Mô hình động cũng tỏ ra hữu dụng trong trường hợp có những trang thiết bị trải qua tuần tự các bước trong một vòng lặp và tiến trình phụ thuộc vào một số điều kiện nhất định. Ví dụ một đối tượng mô hình hóa lối ứng xử của một máy rút tiền mặt tự động (ATM). Máy ATM lần lượt đi qua các bước của một vòng lặp mang tính thủ tục (chức năng), bắt đầu từ việc một thẻ ATM được đút vào trong máy, xử lý các yêu cầu do khách hàng đưa ra, dừng lại và chờ yêu cầu giao dịch khác, rồi sau đó quay trở lại trạng thái ban đầu (đứng yên) sau khi thẻ ATM đã được rút ra ngoài. 112
20. Hình 6.2- Mô hình động của máy rút tiền ATM 2. Sự kiện và thông điệp (Event & Message) a- Sự kiện (Event): Một trong những thành phần quan trọng bậc nhất của một đối tượng là sự kiện. Một sự kiện là một sư kích thích được gửi từ đối tượng này sang đối tượng khác. Một sự kiện là một việc sẽ xảy ra và có thể gây ra một hành động nào đó. Ví dụ như khi bạn bấm lên nút Play trên máy CD-Player, nó sẽ bắt đầu chơi nhạc (giả sử rằng CD-Player có điện, trong máy có đĩa CD và nói chung là dàn CD-Player hoạt động tốt). Sự kiện ở đây là bạn nhấn lên nút Play, và hành động ở đây là bắt đầu chơi nhạc. Nếu có một sự nối kết được định nghĩa rõ ràng giữa sự kiện và hành động, người ta gọi nó là quan hệ nhân quả (Causality). Trong công nghệ phần mềm, chúng ta thường chỉ mô hình hóa các hệ thống mang tính nhân quả, nơi sự kiện và hành động được nối kết với nhau. Một phản ví dụ của quan hệ nhân quả: bạn lái xe trên xa lộ với tốc độ quá nhanh, cảnh sát ngăn xe lại. Đây không phải là nhân quả bởi hành động ngăn bạn lại của cảnh sát không chắc chắn bao giờ cũng xảy ra; vì thế mà không có một sự nối kết được định nghĩa rõ ràng giữa sự kiện (lái xe quá nhanh) và hành động (ngăn xe). Trong mô hình hóa, vậy là ta quan tâm đến sự kiện theo nghĩa là bất kỳ hành động nào khiến hệ thống phản ứng theo một cách nào đó. Quan sát ví dụ một nhà băng lẻ, ta có một vài ví dụ về sự kiện như sau: . Điền một tờ giấy yêu cầu rút tiền. . Sự đáo hạn một tài khoản đầu tư có kỳ hạn. . Kết thúc một hợp đồng trước kỳ hạn. . Điền một giấy yêu cầu mở tài khoản. UML biết đến tất cả bốn loại sự kiện: . Một điều kiện trở thành được thỏa mãn (trở thành đúng) . Nhận được một tín hiệu ngoại từ một đối tượng khác . Nhận được một lời gọi thủ tục từ một đối tượng khác (hay từ chính đối tượng đó). . Một khoảng thời gian xác định trước trôi qua. Xin chú ý rằng cả các lỗi xảy ra cũng là sự kiện và có thể mang tính hữu dụng rất lớn đối với mô hình. Sự kiện độc lập và sự kiện phụ thuộc Các sự kiện có thể mang tính độc lập hay liên quan đến nhau. Có một số sự kiện, theo bản chất, phải đi trước hoặc là xảy ra sau các sự kiện khác. Ví dụ: . Điền các chi tiết trong một tờ yêu cầu rút tiền mặt sẽ dẫn tới việc nhận được một số thẻ xếp hàng. . Sự đáo hạn của một tài khoản đầu tư có kỳ hạn sẽ dẫn đến động tác gia hạn hoặc rút tiền mặt. . Điền các chi tiết trong một giấy yêu cầu mở tài khoản sẽ dẫn tới việc phải nộp một khoản tiền tối thiểu (theo quy định) vào tài khoản. 113
21. Các sự kiện độc lập là những sự kiện không được nối kết với nhau trong bất kỳ một phương diện nào. Ví dụ: . Rút tiền mặt và đưa tiền vào tài khoản là các sự kiện độc lập với nhau. . Mở một tài khoản đầu tư có kỳ hạn và mở một tài khoản giao dịch là độc lập với nhau. . Kết thúc trước kỳ hạn một tài khoản đầu tư và việc mở một tài khoản đầu tư có kỳ hạn khác là độc lập với nhau. Các sự kiện độc lập còn có thể được gọi là các sự kiện song song hay đồng thời. Bởi chúng không phụ thuộc vào nhau, nên các sự kiện này có thể xảy ra tại cùng một thời điểm. Trong nhiều trường hợp, một sự kiện riêng lẻ trong phạm vi vấn đề sẽ được chuyển tải thành nhiều sự kiện trong hệ thống. Ví dụ: đưa giấy yêu cầu rút tiền mặt cho nhân viên phát thẻ xếp hàng sẽ có kết quả là một loạt các sự kiện nối tiếp. Có những tình huống nơi một sự kiện riêng lẻ sẽ được nhận bởi nhiều đối tượng khác nhau và khiến cho chúng phản ứng thích hợp. Ví dụ như một lời đề nghị ngăn một tờ séc có thể đồng thời được gửi đến cho nhân viên thu ngân và nhân viên kiểm tra séc. Sự kiện nội (internal) và sự kiện ngoại (external): Sự kiện nội là các sự kiện xảy ra trong nội bộ hệ thống. Đây là các sự kiện do một đối tượng này gây ra đối với đối tượng khác. Ví dụ, tính toán tiền lãi cho một tài khoản đầu tư có kỳ hạn sẽ được nội bộ hệ thống thực hiện, tuân theo một đối tượng quan sát ngày tháng. Sự kiện ngoại là những sự kiện được kích nên từ phía bên ngoài biên giới của hệ thống, ví dụ như sự kết thúc trước kỳ hạn một tài khoản đầu tư. Sự kiện và lớp sự kiện: Lớp sự kiện đối với sự kiện cũng như lớp đối với đối tượng bình thường. Lời định nghĩa xác định một loại sự kiện được gọi là một lớp sự kiện. Lớp sự kiện ngoài ra còn có thể được phân loại: . Các tín hiệu đơn giản: Lớp sự kiện trong trường hợp này sẽ được thực thể hóa để chỉ ra một sự kiện hoặc là một tín hiệu của một sự kiện. . Các sự kiện chuyển tải dữ liệu: thường thì một sự kiện có khả năng và chuyển tải dữ liệu. Tất cả các sự kiện cần phải "biết đến” các đối tượng sẽ nhận được sự kiện này. Thông tin về người nhận sự kiện được gọi là thông tin nhận diện. Nói một cách khác, yếu tố nhận diện xác định các đối tượng sẽ nhận sự kiện. Bên cạnh đó, còn có thể có các dữ liệu bổ sung thuộc về các đối tượng khác, không nhất thiết phải là đối tượng gửi hay nhận sự kiện. Về mặt nguyên tắc, các sự kiện thuộc dạng phát tin (Broadcast) sẽ được truyền đến cho tất cả các đối tượng. Nếu sự kiện này là không quan trọng đối với đối tượng nào đó trong trạng thái hiện thời của nó thì đối tượng sẽ bỏ qua sự kiện. b- Thông điệp (Message): Trong lập trình hướng đối tượng, một tương tác giữa hai đối tượng được thực thi dưới dạng thông điệp được gửi từ đối tượng này sang đối tượng khác. Trong ngữ cảnh này, yếu tố 114
22. quan trọng là không nên hiểu danh từ "thông điệp” quá chính xác theo nghĩa văn học bình thường. Một thông điệp ở đây thường được thực hiện qua một lệnh gọi thủ tục đơn giản (một đối tượng này gọi một thủ tục của một đối tượng khác); khi thủ tục đã được thực hiện xong, quyền điều khiển được trao trở về cho đối tượng gọi thủ tục cùng với giá trị trả về. Một thông điệp mặt khác cũng có thể là một thông điệp thực thụ được gửi qua một số cơ chế giao tiếp nào đó, hoặc là qua mạng hoặc là nội bộ trong một máy tính, đây là điều thường xảy ra trong các hệ thống thời gian thực. Thông điệp được thể hiện trong tất cả các loại biểu đồ động (tuần tự, cộng tác, hoạt động và trạng thái) theo ý nghĩa là sự giao tiếp giữa các đối tượng. Một thông điệp được vẽ là một được thẳng với mũi tên nối giữa đối tượng gửi và đối tượng nhận thông điệp. Loại mũi tên sẽ chỉ rõ loại thông điệp. Hình 6.3 chỉ rõ các loại thông điệp được sử dụng trong UML. Hình 6.3- Các ký hiệu của các kiểu thông điệp . Thông điệp đơn giản (simple): Chỉ miêu tả đơn giản chiều điều khiển. Nó chỉ ra quyền điều khiển được trao từ đối tượng này sang cho đối tượng khác mà không kèm thêm lời miêu tả bất kỳ một chi tiết nào về sự giao tiếp đó. Loại thông điệp này được sử dụng khi người ta không biết các chi tiết về giao tiếp hoặc coi chúng là không quan trọng đối với biểu đồ. . Thông điệp đồng bộ (synchronous): thường được thực thi là một lệnh gọi thủ tục. Thủ tục xử lý thông điệp này phải được hoàn tất (bao gồm bất kỳ những thông điệp nào được lồng vào trong, được gửi như là một thành phần của sự xử lý) trước khi đối tượng gọi tiếp tục thực thi. Quá trình trở về có thể được chỉ ra dưới dạng thông điệp đơn giản. . Thông điệp không đồng bộ (asynchronous): đây là dạng điều khiển trình tự không đồng bộ, nơi không có một sự trở về đối với đối tượng gọi và nơi đối tượng gửi thông điệp tiếp tục quá trình thực thi của mình sau khi đã gửi thông điệp đi, không chờ cho tới khi nó được xử lý xong. Loại thông điệp này thường được sử dụng trong các hệ thống thời gian thực, nơi các đối tượng thực thi đồng thời. Thông điệp đơn giản và thông điệp đồng bộ có thể được kết hợp với nhau trong chỉ một đường thẳng chỉ thông điệp với mũi tên chỉ thông điệp đồng bộ ở một phía và mũi tên chỉ thông điệp đơn giản ở phía kia. Điều này chỉ rõ rằng sự trả về được xảy ra hầu như ngay lập tức sau lệnh gọi hàm. Câu hỏi và bài tập: 1. Các thành phần chính của mô hình động? 2. Ưu điểm chính của mô hình động Bài tập thực hành : xem phần nội dung thực hành trang 170 115
23. BÀI 7 Tên bài : CÁC VẤN ĐỀ VỀ THIẾT KẾ VÀ THI HÀNH Mã bài : ITPRG3_16.7 Giới thiệu : Cơ bản về thiết kế và thi hành lớp, thiết kế các giao diện lớp, các kiểu và các tham số, một số khái niệm về thiết kế, các thao tác, các thuộc tính và UML, thiết kế sự thừa kế, thiết kế các mối liên kết và các kết hợp Mục tiêu thực hiện: Học xong bài này học viên có khả năng : - Liệt kê các đặc trưng của một lớp - Hiểu biết về các vấn đề liên quan đến thiết kế - Các quan hệ, các thuộc tính, thao tác, và sự thừa kế - Định rõ các chi tiết thiết kế thuộc tính và thao tác trong UML - Định hướng thiết kế cho các liên kết lớp. Nội dung chính: I- BIỂU ĐỒ TUẦN TỰ (SEQUENCE DIAGRAM) Biểu đồ tuần tự minh họa các đối tượng tương tác với nhau ra sao. Chúng tập trung vào các chuỗi thông điệp, có nghĩa là các thông điệp được gửi và nhận giữa một loạt các đối tượng như thế nào. Biểu đồ tuần tự có hai trục: trục nằm dọc chỉ thời gian, trục nằm ngang chỉ ra một tập hợp các đối tượng. Một biểu đồ tuần tự cũng nêu bật sự tương tác trong một cảnh kịch (scenario) – một sự tương tác sẽ xảy ra tại một thời điểm nào đó trong quá trình thực thi của hệ thống. Từ các hình chữ nhật biểu diễn đối tượng có các đường gạch rời (dashed line) thẳng đứng biểu thị đường đời đối tượng, tức là sự tồn tại của đối tượng trong chuỗi tương tác. Trong khoảng thời gian này, đối tượng được thực thể hóa, sẵn sàng để gửi và nhận thông điệp. Quá trình giao tiếp giữa các đối tượng được thể hiện bằng các đường thẳng thông điệp nằm ngang nối các đường đời đối tượng. Mỗi tên ở đầu đường thẳng sẽ chỉ ra loại thông điệp này mang tính đồng bộ, không đồng bộ hay đơn giản. Để đọc biểu đồ tuần tự, hãy bắt đầu từ phía bên trên của biểu đồ rồi chạy dọc xuống và quan sát sự trao đổi thông điệp giữa các đối tượng xảy ra dọc theo tiến trình thời gian. Ví dụ hãy quan sát một cảnh kịch rút tiền mặt tại một máy ATM của một nhà băng lẻ: 116
24. Hình 7.1- Biểu đồ cảnh kịch rút tiền mặt tại máy ATM Biểu đồ trên có thể được diễn giải theo trình tự thời gian như sau: . Có ba lớp tham gia cảnh kịch này: khách hàng, máy ATM và tài khoản. . Khách hàng đưa yêu cầu rút tiền vào máy ATM . Đối tượng máy ATM yêu cầu khách hàng cung cấp mã số . Mã số được gửi cho hệ thống để kiểm tra tài khoản . Đối tượng tài khoản kiểm tra mã số và báo kết quả kiểm tra đến cho ATM . ATM gửi kết quả kiểm tra này đến khách hàng . Khách hàng nhập số tiền cần rút. . ATM gửi số tiền cần rút đến cho tài khoản . Đối tượng tài khoản trừ số tiền đó vào mức tiền trong tài khoản. Tại thời điểm này, chúng ta thấy có một mũi tên quay trở lại chỉ vào đối tượng tài khoản. Ý nghĩa của nó là đối tượng tài khoản xử lý yêu cầu này trong nội bộ đối tượng và không gửi sự kiện đó ra ngoài. . Đối tượng tài khoản trả về mức tiền mới trong tài khoản cho máy ATM. . Đối tượng ATM trả về mức tiền mới trong tài khoản cho khách hàng và dĩ nhiên, cả lượng tiền khách hàng đã yêu cầu được rút. Đối tượng tài khoản chỉ bắt đầu được sinh ra khi đối tượng ATM cần tới nó để kiểm tra mã số và đối tượng tài khoản tiếp tục sống cho tới khi giao dịch được hoàn tất. Sau đó, nó chết đi. Bởi khách hàng có thể muốn tiếp tục thực hiện các giao dịch khác nên đối tượng khách 117
25. hàng và đối tượng máy ATM vẫn tiếp tục tồn tại, điều này được chỉ ra qua việc các đường đời đối tượng được kéo vượt quá đường thẳng thể hiện sự kiện cuối cùng trong chuỗi tương tác. Loại tương tác này là rất hữu dụng trong một hệ thống có một số lượng nhỏ các đối tượng với một số lượng lớn các sự kiện xảy ra giữa chúng. Mặc dù vậy, khi số lượng các đối tượng trong một hệ thống tăng lên thì mô hình này sẽ không còn mấy thích hợp. Để có thể vẽ biểu đồ tuần tự, đầu tiên hãy xác định các đối tượng liên quan và thể hiện các sự kiện xảy ra giữa chúng. Khi vẽ biểu đồ tuần tự, cần chú ý: . Sự kiện được biểu diễn bằng các đường thẳng nằm ngang. . Đối tượng bằng các đường nằm dọc. . Thời gian được thể hiện bằng đường thẳng nằm dọc bắt đầu từ trên biểu đồ. Điều đó có nghĩa là các sự kiện cần phải được thể hiện theo đúng thứ tự mà chúng xảy ra, vẽ từ trên xuống dưới. II- BIỂU ĐỒ CỘNG TÁC (COLLABORATION DIAGRAM) Một biểu đồ cộng tác miêu tả tương tác giữa các đối tượng cũng giống như biểu đồ tuần tự, nhưng nó tập trung trước hết vào các sự kiện, tức là tập trung chủ yếu vào sự tương tác giữa các đối tượng. Trong một biểu đồ cộng tác, các đối tượng được biểu diễn bằng kí hiệu lớp. Thứ tự trong biểu đồ cộng tác được thể hiện bằng cách đánh số các thông điệp. Kỹ thuật đánh số được coi là hơi có phần khó hiểu hơn so với kỹ thuật mũi tên sử dụng trong biểu đồ tuần tự. Nhưng ưu điểm của biểu đồ cộng tác là nó có thể chỉ ra các chi tiết về các lệnh gọi hàm (thủ tục), yếu tố được né tránh trong biểu đồ tuần tự. Biểu đồ sau đây là một ví dụ cho một biểu đồ cộng tác, được chuẩn bị cũng cho một cảnh kịch rút tiền mặt như trong biểu đồ tuần tự của phần trước. Hãy quan sát các thứ tự số trong biểu đồ. Đầu tiên thủ tục WithdrawalReq() được gọi từ lớp khách hàng. Đó là lệnh gọi số 1. Bước tiếp theo trong tuần tự là hàm AskForPin(), số 1.1, được gọi từ lớp ATM. Thông điệp trong biểu đồ được viết dưới dạng pin:= AskForPin(), thể hiện rằng "giá trị trả về" của hàm này chính là mã số mà lớp khách hàng sẽ cung cấp. Hình cung bên lớp tài khoản biểu thị rằng hàm ComputeNetBalance() được gọi trong nội bộ lớp tài khoản và nó xử lý cục bộ. Thường thì nó sẽ là một thủ tục riêng (private) của lớp. 118
26. Hình 7.2- Một biểu đồ cộng tác của kích cảnh rút tiền ở máy ATM III- BIỂU ĐỒ TRẠNG THÁI (STATE DIAGRAM) Biểu đồ trạng thái nắm bắt vòng đời của các đối tượng, các hệ thống con (Subsystem) và các hệ thống. Chúng cho ta biết các trạng thái mà một đối tượng có thể có và các sự kiện (các thông điệp nhận được, các khoảng thời gian đã qua đi, các lỗi xảy ra, các điều kiện được thỏa mãn) sẽ ảnh hưởng đến những trạng thái đó như thế nào dọc theo tiến trình thời gian. Biểu đồ trạng thái có thể đính kèm với tất cả các lớp có những trạng thái được nhận diện rõ ràng và có lối ứng xử phức tạp. Biểu đồ trạng thái xác định ứng xử và miêu tả nó sẽ khác biệt ra sao phụ thuộc vào trạng thái, ngoài ra nó cũng còn miêu tả rõ những sự kiện nào sẽ thay đổi trạng thái của các đối tượng của một lớp. 1- Trạng thái và sự biến đổi trạng thái (State transition) Tất cả các đối tượng đều có trạng thái; trạng thái là một kết quả của các hoạt động trước đó đã được đối tượng thực hiện và nó thường được xác định qua giá trị của các thuộc tính cũng như các nối kết của đối tượng với các đối tượng khác. Một lớp có thể có một thuộc tính đặc biệt xác định trạng thái, hoặc trạng thái cũng có thể được xác định qua giá trị của các thuộc tính “bình thường" trong đối tượng. Ví dụ về các trạng thái của đối tượng: . Hóa đơn (đối tượng) đã được trả tiền (trạng thái). . Chiếc xe ô tô (đối tượng) đang đứng yên (trạng thái). . Động cơ (đối tượng) đang chạy (trạng thái). . Jen (đối tượng) đang đóng vai trò người bán hàng (trạng thái). . Kate (đối tượng) đã lấy chồng (trạng thái). Một đối tượng sẽ thay đổi trạng thái khi có một việc nào đó xảy ra, thứ được gọi là sự kiện; ví dụ có ai đó trả tiền cho hóa đơn, bật động cơ xe ô tô hay là lấy chồng lấy vợ. Khía cạnh động có hai chiều không gian: tương tác và sự biến đổi trạng thái nội bộ. Tương tác miêu tả lối ứng xử đối ngoại của các đối tượng và chỉ ra đối tượng này sẽ tương tác với các đối tượng khác ra sao (qua việc gửi thông điệp, nối kết hoặc chấm dứt nối kết). Sự biến đổi trạng thái nội bộ miêu tả một đối tượng sẽ thay đổi các trạng thái ra sao – ví dụ giá trị các 119
27. thuộc tính nội bộ của nó sẽ thay đổi như thế nào. Biểu đồ trạng thái được sử dụng để miêu tả việc bản thân đối tượng phản ứng ra sao trước các sự kiện và chúng thay đổi các trạng thái nội bộ của chúng như thế nào, ví dụ, một hóa đơn sẽ chuyển từ trạng thái chưa trả tiền sang trạng thái đã trả tiền khi có ai đó trả tiền cho nó. Khi một hóa đơn được tạo ra, đầu tiên nó bước vào trạng thái chưa được trả tiền. 2- Biểu đồ trạng thái Biểu đồ trạng thái thể hiện những khía cạnh mà ta quan tâm tới khi xem xét trạng thái của một đối tượng: . Trạng thái ban đầu . Một số trạng thái ở giữa . Một hoặc nhiều trạng thái kết thúc . Sự biến đổi giữa các trạng thái . Những sự kiện gây nên sự biến đổi từ một trạng thái này sang trạng thái khác Hình sau sẽ chỉ ra các kí hiệu UML thể hiện trạng thái bắt đầu và trạng thái kết thúc, sự kiện cũng như các trạng thái của một đối tượng. Hình 7.3- Các ký hiệu UML thể hiện bắt đầu, kết thúc, sự kiện và trạng thái của một đối tượng. Hình 7.3- Biểu đồ trạng thái thực hiện hoá đơn. Một trạng thái có thể có ba thành phần, như được chỉ trong hình sau : Hình 7.4- Các ngăn Tên, Biến trạng thái và hành động 120
28. Phần thứ nhất chỉ ra tên của trạng thái, ví dụ như chờ, đã được trả tiền hay đang chuyển động. Phần thứ hai (không bắt buộc) dành cho các biến trạng thái. Đây là những thuộc tính của lớp được thể hiện qua biểu đồ trạng thái; nhiều khi các biến tạm thời cũng tỏ ra rất hữu dụng trong trạng thái, ví dụ như các loại biến đếm (counter). Phần thứ ba (không bắt buộc) là phần dành cho hoạt động, nơi các sự kiện và các hành động có thể được liệt kê. Có ba loại sự kiện chuẩn hóa có thể được sử dụng cho phần hành động: entry (đi vào), exit (đi ra), và do (thực hiện). Loại sự kiện đi vào được sử dụng để xác định các hành động khởi nhập trạng thái, ví dụ gán giá trị cho một thuộc tính hoặc gửi đi một thông điệp. Sự kiện đi ra có thể được sử dụng để xác định hành động khi rời bỏ trạng thái. Sự kiện thực hiện được sử dụng để xác định hành động cần phải được thực hiện trong trạng thái, ví dụ như gửi một thông điệp, chờ, hay tính toán. Ba loại sự kiện chuẩn này không thể được sử dụng cho các mục đích khác. Một sự biến đổi trạng thái thường có một sự kiện đi kèm với nó, nhưng không bắt buộc. Nếu có một sự kiện đi kèm, sự thay đổi trạng thái sẽ được thực hiện khi sự kiện kia xảy ra. Một hành động loại thực hiện trong trạng thái có thể là một quá trình đang tiếp diễn (ví dụ chờ, điều khiển các thủ tục, ) phải được thực hiện trong khi đối tượng vẫn ở nguyên trong trạng thái này. Một hành động thực hiện có thể bị ngắt bởi các sự kiện từ ngoài, có nghĩa là một sự kiện kiện gây nên một sự biến đổi trạng thái có thể ngưng ngắt một hành động thực hiện mang tính nội bộ đang tiếp diễn. Trong trường hợp một sự biến đổi trạng thái không có sự kiện đi kèm thì trạng thái sẽ thay đổi khi hành động nội bộ trong trạng thái đã được thực hiện xong (hành động nội bộ kiểu đi vào, đi ra, thực hiện hay các hành động do người sử dụng định nghĩa). Theo đó, khi tất cả các hành động thuộc trạng thái đã được thực hiện xong, một sự thay đổi trạng thái sẽ tự động xảy ra mà không cần sự kiện từ ngoài. Hình 7.5- Biến đổi trạng thái không có sự kiện từ ngoài. Sự thay đổi trạng thái xảy ra khi các hoạt động trong mỗi trạng thái được thực hiện xong. 3- Nhận biết trạng thái và sự kiện Quá trình phát hiện sự kiện và trạng thái về mặt bản chất bao gồm việc hỏi một số các câu hỏi thích hợp: . Một đối tượng có thể có những trạng thái nào?: Hãy liệt kê ra tất cả những trạng thái mà một đối tượng có thể có trong vòng đời của nó. . Những sự kiện nào có thể xảy ra?: Bởi sự kiện gây ra việc thay đổi trạng thái nên nhận ra các sự kiện là một bước quan trọng để nhận diện trạng thái. . Trạng thái mới sẽ là gì?: Sau khi nhận diện sự kiện, hãy xác định trạng thái khi sự kiện này xảy ra và trạng thái sau khi sự kiện này xảy ra. . Có những thủ tục nào sẽ được thực thi?: Hãy để ý đến các thủ tục ảnh hưởng đến trạng thái của một đối tượng. . Chuỗi tương tác giữa các đối tượng là gì?: Tương tác giữa các đối tượng cũng có thể ảnh hưởng đến trạng thái của đối tượng. 121
29. . Qui định nào sẽ được áp dụng cho các phản ứng của các đối tượng với nhau?: Các qui định kiềm tỏa phản ứng đối với một sự kiện sẽ xác định rõ hơn các trạng thái. . Những sự kiện và sự chuyển tải nào là không thể xảy ra?: Nhiều khi có một số sự kiện hoặc sự thay đổi trạng thái không thể xảy ra. Ví dụ như bán một chiếc ô tô đã được bán rồi. . Cái gì khiến cho một đối tượng được tạo ra?: Đối tượng được tạo ra để trả lời cho một sự kiện. Ví dụ như một sinh viên ghi danh cho một khóa học. . Cái gì khiến cho một đối tượng bị hủy?: Đối tượng sẽ bị hủy đi khi chúng không được cần tới nữa. Ví dụ khi một sinh viên kết thúc một khóa học. . Cái gì khiến cho đối tượng cần phải được tái phân loại (reclassfied)?: Những loại sự kiện như một nhân viên được tăng chức thành nhà quản trị sẽ khiến cho động tác tái phân loại của nhân viên đó được thực hiện. 4- Một số lời mách bảo cho việc tạo dựng biểu đồ trạng thái . Chuyển biểu đồ tuần tự thành biểu đồ trạng thái. . Xác định các vòng lặp (loop) . Bổ sung thêm các điều kiện biên và các điều kiện đặc biệt . Trộn lẫn các cảnh kịch khác vào trong biểu đồ trạng thái. Một khi mô hình đã được tạo nên, hãy nêu ra các câu hỏi và kiểm tra xem mô hình có khả năng cung cấp tất cả các câu trả lời. Qui trình sau đây cần phải được nhắc lại cho mỗi đối tượng. 4.1- Chuyển biểu đồ tuần tự thành biểu đồ trạng thái Hãy dõi theo một chuỗi các sự kiện được miêu tả trong biểu đồ, chuỗi này phải mang tính tiêu biểu cho các tương tác trong hệ thống. Hãy quan sát các sự kiện ảnh hưởng đến đối tượng mà ta đang nghiên cứu. Hãy sắp xếp các sự kiện thành một đường dẫn, dán nhãn input (hoặc entry) và output (exit) cho các sự kiện. Khoảng cách giữa hai sự kiện này sẽ là một trạng thái. Nếu cảnh kịch có thể được nhắc đi nhắc lại rất nhiều lần (vô giới hạn), hãy nối đường dẫn từ trạng thái cuối cùng đến trạng thái đầu tiên. Biểu đồ sau đây chỉ ra biểu đồ trạng thái của một lớp máy ATM, được chiết suất từ biểu đồ tuần tự hoặc biểu đồ cộng tác đã được trình bày trong các phần trước. 122
30. Hình 7.6- Chuyển một biểu đồ tuần tự sang biểu đồ trạng thái 4.2- Nhận ra các vòng lặp (loop) Một chuỗi sự kiện có thể được nhắc đi nhắc lại vô số lần được gọi là vòng lặp (loop). Hình 7.7- Biểu đồ lặp Chú ý: Trong một vòng lặp, chuỗi các sự kiện được nhắc đi nhắc lại cần phải đồng nhất với nhau. Nếu có một chuỗi các sự kiện khác chuỗi khác thì trường hợp đó không có vòng lặp. Lý tưởng nhất là một trạng thái trong vòng lặp sẽ có sự kiện kết thúc. Đây là yếu tố quan trọng, nếu không thì vòng lặp sẽ không bao giờ kết thúc. 4.3- Bổ sung thêm các điều kiện biên và các điều kiện đặc biệt Sau khi đã hoàn tất biểu đồ trạng thái cho mọi đối tượng cần thiết trong hệ thống, đã đến lúc chúng ta cần kiểm tra, đối chứng chúng với điều kiện biên và các điều kiện đặc biệt khác, những điều kiện rất có thể đã chưa được quan tâm đủ độ trong thời gian tạo dựng biểu đồ trạng thái. Điều kiện biên là những điều kiện thao tác trên giá trị, đây là những giá trị nằm bên ranh giới của một điều kiện để quyết định về trạng thái của đối tượng, ví dụ như quy định về kỳ hạn của một tài khoản là 30 ngày thì ngày thứ 31 đối với tài khoản này sẽ là một điều kiện biên. Các điều kiện đặc biệt là những điều kiện ngoại lệ, ví dụ ngày thứ 30 của tháng 2 năm 2000 (nếu có một điều kiện thật sự như vậy tồn tại ngoài đời thực). 4.4- Trộn lẫn các cảnh kịch khác vào trong biểu đồ trạng thái Một khi biểu đồ trạng thái cho một đối tượng đã sẵn sàng, chúng ta cần phải trộn những chuỗi sự kiện có ảnh hưởng đến đối tượng này vào trong biểu đồ trạng thái. Điều này có nghĩa là chúng ta cần phải quan sát các hiệu ứng gián tiếp của các sự kiện khác đối với đối tượng đang là chủ đề chính của biểu đồ trạng thái. Đây là việc quan trọng, bởi các đối tượng trong một hệ thống tương tác với nhau và vì các đối tượng khác cũng có khả năng gây nên sự kiện cho một đối tượng định trước, nên lối ứng xử này cũng cần phải được thể hiện trong biểu đồ trạng thái. Điểm bắt đầu cho công việc này là: 123
31. . Ấn định một điểm bắt đầu chung cho tất cả các chuỗi sự kiện bổ sung. . Xác định điểm nơi các ứng xử bắt đầu khác biệt với những ứng xử đã được mô hình hóa trong biểu đồ trạng thái. Bổ sung thêm sự các biến đổi mới từ trạng thái này, trong tư cách một đường dẫn thay thế. Cần để ý đến những đường dẫn có vẻ ngoài đồng nhất nhưng thật ra có khác biệt trong một tình huống nhất định nào đó. Hãy chú ý đến các sự kiện xảy ra trong những tình huống bất tiện. Mỗi sự kiện do khách hàng hay người sử dụng gây nên đều có thể sa vào trạng thái của các sự kiện bất tiện. Hệ thống không nắm quyền điều khiển đối với người sử dụng và người sử dụng có thể quyết định để làm nảy ra một sự kiện tại một thời điểm tiện lợi đối với anh ta. Ví dụ như khách hàng có thể quyết định kết thúc trước kỳ hạn một tài khoản đầu tư. Một trường hợp khác cũng cần phải được xử lý là sự kiện do người sử dụng gây nên không thể xảy ra. Có một loạt các lý do (người sử dụng thiếu tập trung, buồn nản, lơ đãng ) khiến cho sự kiện loại này không xảy ra. Cả trường hợp này cũng phải được xử lý thấu đáo. Ví dụ một khách hàng thất bại trong việc báo cho nhà băng biết những mệnh lệnh của anh ta về kỳ hạn của tài khoản, một tấm séc được viết ra nhưng lại không có khả năng giải tỏa mức tiền cần thiết. Nhìn theo phương diện các biểu đồ trạng thái như là một thành phần của mô hình động, cần chú ý những điểm sau: . Biểu đồ trạng thái chỉ cần được tạo dựng nên cho các lớp đối tượng có ứng xử động quan trọng. . Hãy thẩm tra biểu đồ trạng thái theo khía cạnh tính nhất quán đối với những sự kiện dùng chung để cho toàn bộ mô hình động được đúng đắn. . Dùng các trường hợp sử dụng để hỗ trợ cho quá trình tạo dựng biểu đồ trạng thái. . Khi định nghĩa một trạng thái, hãy chỉ để ý đến những thuộc tính liên quan. IV- BIỂU ĐỒ HOẠT ĐỘNG (ACTIVITY DIAGRAM) Biểu đồ hoạt động nắm bắt hành động và các kết quả của chúng. Biểu đồ hoạt động tập trung vào công việc được thực hiện trong khi thực thi một thủ tục (hàm), các hoạt động trong một lần thực thi một trường hợp sử dụng hoặc trong một đối tượng. Biểu đồ hoạt động là một biến thể của biểu đồ trạng thái và có một mục tiêu tương đối khác, đó là nắm bắt hành động (công việc và những hoạt động phải được thực hiện) cũng như kết quả của chúng theo sự biến đổi trạng thái. Các trạng thái trong biểu đồ hoạt động (được gọi là các trạng thái hành động) sẽ chuyển sang giai đoạn kế tiếp khi hành động trong trạng thái này đã được thực hiện xong (mà không xác định bất kỳ một sự kiện nào theo như nội dung của biểu đồ trạng thái). Một sự điểm phân biệt khác giữa biểu đồ hoạt động và biểu đồ trạng thái là các hành động của nó được định vị trong các luồng (swimlane). Một luồng sẽ gom nhóm các hoạt động, chú ý tới khái niệm người chịu trách nhiệm cho chúng hoặc chúng nằm ở đâu trong một tổ chức. Một biểu đồ hoạt động là một phương pháp bổ sung cho việc miêu tả tương tác, đi kèm với trách nhiệm thể hiện rõ các hành động xảy ra như thế nào, chúng làm gì (thay đổi trạng thái đối tượng), chúng xảy ra khi nào (chuỗi hành động), và chúng xảy ra ở đâu (luồng hành động). Biểu đồ hoạt động có thể được sử dụng cho nhiều mục đích khác nhau, ví dụ như: 124
32. . Để nắm bắt công việc (hành động) sẽ phải được thực thi khi một thủ tục được thực hiện. Đây là tác dụng thường gặp nhất và quan trọng nhất của biểu đồ hoạt động. . Để nắm bắt công việc nội bộ trong một đối tượng. . Để chỉ ra một nhóm hành động liên quan có thể được thực thi ra sao, và chúng sẽ ảnh hưởng đến những đối tượng nằm xung quanh chúng như thế nào. . Để chỉ ra một trường hợp sử dụng có thể được thực thể hóa như thế nào, theo khái niệm hành động và các sự biến đổi trạng thái của đối tượng. . Để chỉ ra một doanh nghiệp hoạt động như thế nào theo các khái niệm công nhân (tác nhân), qui trình nghiệp vụ (workflow), hoặc tổ chức và đối tượng (các khía cạnh vật lý cũng như tri thức được sử dụng trong doanh nghiệp). Biểu đồ hoạt động có thể được coi là một loại Flow chart. Điểm khác biệt là Flow Chart bình thường ra chỉ được áp dụng đối với các qui trình tuần tự, biểu đồ hoạt động có thể xử lý cả các các qui trình song song. . Hành động và sự thay đổi trạng thái Một hành động được thực hiện để sản sinh ra một kết quả. Việc thực thi của thủ tục có thể được miêu tả dưới dạng một tập hợp của các hành động liên quan, sau này chúng sẽ được chuyển thành các dòng code thật sự. Theo như định nghĩa ở phần trước, một biểu đồ hoạt động chỉ ra các hành động cùng mối quan hệ giữa chúng và có thể có một điểm bắt đầu và một điểm kết thúc. Biểu đồ hoạt động sử dụng cũng cùng những ký hiệu như trong biểu đồ trạng thái bình thường. Hình 7.8- Khi một người gọi tác vụ PrintAllCustomer (trong lớp CustomerWindow), các hành động khởi động. hành động đầu tiên là hiện một hộp thông báo lên màn hình; hành động thứ hai là tạo một tập tin postscript; hành động thứ ba là gởi file postscript đến máy in; và hành động thứ tư là xóa hộp thông báo trên màn hình. Các hành động được chuyển tiếp tự động; chúng xảy ra ngay khi hành động trong giai đoạn nguồn được thực hiện. Các sự thay đổi có thể được bảo vệ bởi các điều kiện canh giữ (Guard-condition), các điều kiện này phải được thỏa mãn thì sự thay đổi mới nổ ra. Một ký hiệu hình thoi được sử dụng để thể hiện một quyết định. Ký hiệu quyết định có thể có một hoặc nhiều sự thay đổi đi vào và một hoặc nhiều sự thay đổi đi ra được dán nhãn đi kèm các điều kiện bảo vệ. Bình thường ra, một trong số các sự thay đổi đi ra bao giờ cũng được thỏa mãn (là đúng). 125
33. Một sự thay đổi được chia thành hai hay nhiều sự thay đổi khác sẽ dẫn đến các hành động xảy ra song song. Các hành động được thực hiện đồng thời, mặc dù chúng cũng có thể được thực hiện lần lượt từng cái một. Yếu tố quan trọng ở đây là tất cả các thay đổi đồng thời phải được thực hiện trước khi chúng được thống nhất lại với nhau (nếu có). Một đường thẳng nằm ngang kẻ đậm (còn được gọi là thanh đồng hộ hóa – Synchronisation Bar) chỉ rằng một sự thay đổi được chia thành nhiều nhánh khác nhau và chỉ ra một sự chia sẻ thành các hành động song song. Cũng đường thẳng đó được sử dụng để chỉ ra sự thống nhất các nhánh. Kí hiệu UML cho các thành phần căn bản của biểu đồ hoạt động: . Hoạt động (Activity): là một qui trình được định nghĩa rõ ràng, có thể được thực thi qua một hàm hoặc một nhóm đối tượng. Hoạt động được thể hiện bằng hình chữ nhật bo tròn cạnh. . Thanh đồng bộ hóa (Synchronisation bar): chúng cho phép ta mở ra hoặc là đóng lại các nhánh chạy song song nội bộ trong tiến trình. Hình 7.9- Thanh đồng bộ hóa . Điều kiện canh giữ (Guard Condition): các biểu thức logic có giá trị hoặc đúng hoặc sai. Điều kiện canh giữ được thể hiện trong ngoặc vuông, ví dụ: [Customer existing]. . Điểm quyết định (Decision Point): được sử dụng để chỉ ra các sự thay đổi khả thi. Kí hiệu là hình thoi. Hình sau đây miêu tả một đoạn biểu đồ hoạt động của máy ATM. Sau khi thẻ được đưa vào máy, ta thấy có ba hoạt động song song: . Xác nhận thẻ . Xác nhận mã số PIN . Xác nhận số tiền yêu cầu được rút Chỉ khi sử dụng biểu đồ hoạt động, các hoạt động song song như vậy mới có thể được miêu tả. Mỗi một hoạt động xác nhận bản thân nó cũng đã có thể là một quá trình riêng biệt. 126
34. Hình 7.10- Biểu đồ hoạt động của máy ATM V- VÒNG ĐỜI ĐỐI TƯỢNG (OBJECT LIFECYCLE) Vòng đời mà một đối tượng đi qua phụ thuộc vào loại đối tượng. Có hai loại vòng đời khác nhau đối với một đối tượng: vòng đời sinh ra rồi chết đi; và vòng đời vòng lặp. 1- Vòng đời sinh ra và chết đi: Trong một vòng đời sinh ra rồi chết đi: . Sẽ có một hay nhiều trạng thái nơi đối tượng bắt đầu tồn tại. Những trạng thái này được gọi là trạng thái tạo ra đối tượng. . Sẽ có một hay nhiều trạng thái đóng tư cách là điểm kết thúc cho vòng đời của một đối tượng. Những trạng thái này được gọi là trạng thái kết thúc. Có hai loại trạng thái kết thúc. Một dạng trạng thái kết thúc là loại nơi đối tượng bị hủy và không tiếp tục tồn tại nữa. Loại thứ hai là dạng trạng thái kết thúc mà sau đó đối tượng sẽ được lưu trữ lại hoặc chuyển sang trạng thái im lặng. Đối tượng tiếp tục tồn tại nhưng không tiếp tục thể hiện ứng xử động. Sau trạng thái khởi tạo và trước trạng thái kết thúc, đối tượng có thể đi qua một hoặc là nhiều trạng thái trung gian. Tại mỗi một thời điểm, đối tượng phải ở một trạng thái hiện thời. Không có một điểm nào sau trạng thái khởi tạo và trước trạng thái kết thúc mà đối tượng lại không có trạng thái. 127
35. Ví dụ cho đối tượng có vòng đời sinh ra và chết đi: khách hàng, tài khoản. 2- Vòng đời lặp Khác với trường hợp sinh ra và chết đi, trong vòng đời vòng lặp: . Đối tượng được coi là đã luôn luôn tồn tại ở đây và sẽ còn mãi mãi tiếp tục tồn tại. . Không có trạng thái khởi tạo cũng không có trạng thái kết thúc. Mặc dù thật ra đối tượng đã được tạo ra tại một thời điểm nào đó và cũng sẽ thật sự bị hủy diệt tại một thời điểm nào đó, nhưng nó vẫn được coi là luôn luôn tồn tại và có mặt. Thường thì những đối tượng tỏ ra có một vòng đời vòng lặp sẽ được tạo ra tại thời điểm cài đặt hệ thống và sẽ chết đi khi hệ thống kết thúc. Một đối tượng với vòng đời vòng lặp sẽ có một hoặc là nhiều trạng thái "ngủ yên". Đó là những trạng thái nơi đối tượng nằm chờ một sự kiện xảy ra. Bên cạnh đó, đối tượng cũng luôn luôn ở trạng thái hiện thời. Ví dụ cho đối tượng có vòng đời lặp lại: máy rút tiền tự động (ATM), nhân viên thu ngân. VI- XEM XÉT LẠI MÔ HÌNH ĐỘNG 1- Thẩm vấn biểu đồ trạng thái Sau khi đã hoàn tất các thành phần căn bản của mô hình động như các biểu đồ tuần tự, biểu đồ cộng tác, biểu đồ trạng thái và biểu đồ hoạt động, nhóm phát triển có thể phác thảo biểu đồ thành phần và biểu đồ triển khai. Biểu đồ triển khai có thể được coi là biểu đồ cuối cùng trong mô hình động. Tới thời điểm này, có thể coi là ta đã hoàn tất một phiên bản của mô hình động. Phần quan trọng nhất trong mô hình này là biểu đồ trạng thái. Hãy tìm câu trả lời cho một loạt các câu hỏi để xác định xem biểu đồ trạng thái đã đúng đắn và có một mức độ chi tiết thích hợp hay chưa. Công việc này cần nhắm tới hai mục đích: . Kiểm tra tính trọn vẹn của mô hình . Đảm bảo mọi điều kiện gây lỗi đã được xử lý Trong giai đoạn này, có thể sẽ có các cảnh kịch (scenario) mới xuất hiện và gia nhập phạm vi quan sát của chúng ta, nếu trước đó có một số trạng thái chưa được xử lý. Những tình huống loại này là loại vấn đề có thể được giải quyết, song có thể né tránh qua việc xác định thật đầy đủ các sự kiện và trạng thái. 2- Phối hợp sự kiện Bước cuối cùng là một vòng kiểm tra bổ sung nhằm đảm bảo tính đúng đắn của mô hình động: . Kiểm tra để đảm bảo mỗi thông điệp đều có đối tượng gửi và đối tượng nhận. Trong một số trường hợp, số liệu chính xác của những đối tượng nhận sự kiện có thể không được biết tới, nhưng chúng ta phải đảm bảo rằng chúng ta biết những lớp nào sẽ xử lý những sự kiện này. 128
36. . Hãy nghiên cứu mô hình theo khía cạnh trạng thái, tìm ra những trạng thái không có trạng thái dẫn trước và không có trạng thái tiếp theo. Những trạng thái thái này rất có thể là trạng thái khởi đầu hoặc trạng thái kết thúc. Mặc dù vậy, nếu trạng thái đó không thuộc về một trong hai loại trạng thái kia, rất có thể đây là một triệu chứng cho thấy mô hình còn thiếu điều gì đó. . Nhìn chung, tất cả các trạng thái thường đều có trạng thái dẫn trước và trạng thái tiếp sau. . Hãy lần theo hịêu ứng của các sự kiện đi vào (entry) để đảm bảo là chúng tương thích với các trường hợp sử dụng nơi chúng xuất phát. Để làm điều này, hãy lần theo một sự kiện từ một đối tượng này đến đối tượng khác, kiểm tra xem mỗi sự kiện có phù hợp với trường hợp sử dụng hay không. Trong trường hợp có mâu thuẫn, hãy sửa lại biểu đồ trạng thái hoặc trường hợp sử dụng để đảm bảo sự nhất quán. . Kiểm tra lại những lỗi đồng bộ, có thể chúng là kết quả của một sự kiện không chờ đợi. 3- Bao giờ thì sử dụng biểu đồ nào Không cần phải vẽ tất cả các loại biểu đồ động cho tất cả các loại hệ thống. Mặc dù vậy, trong một số trường hợp khác nhau chúng ta nhất thiết phải cần đến một số loại biểu đồ động nhất định. Sau đây là một vài lời mách bảo có thể giúp giải thích một vài điều còn chưa thông tỏ về việc sử dụng các loại biểu đồ động. Biểu đồ tuần tự và biểu đồ cộng tác được vẽ khi chúng ta muốn xem xét ứng xử động của nhiều đối tượng/ lớp trong nội bộ một cảnh kịch của một trường hợp sử dụng. Biểu đồ tuần tự và biểu đồ cộng tác rất hữu dụng trong việc chỉ ra sự cộng tác giữa các đối tượng, nhưng chúng lại không hữu dụng khi muốn miêu tả ứng xử chính xác của một đối tượng. Biểu đồ trạng thái được sử dụng để thể hiện ứng xử chính xác của một đối tượng. Biểu đồ hoạt động được sử dụng để thể hiện lối ứng xử xuyên suốt nhiều trường hợp sử dụng hoặc các tiểu trình xảy ra song song của một lần thực thi. Biểu đồ thành phần và biểu đồ triển khai được sử dụng để chỉ ra mối quan hệ vật lý giữa phần mềm và các thành phần phần cứng trong hệ thống. 4- Lớp con và biểu đồ trạng thái Tất cả các lớp con đều thừa kế cả thuộc tính cũng như các thủ tục của lớp cha. Vì vậy, một lớp con cũng sẽ thừa kế cả mô hình động của lớp cha. Ngoài biểu đồ trạng thái được thừa kế, lớp con cũng có biểu đồ trạng thái riêng của nó. Biểu đồ trạng thái của một lớp cha sẽ được mở rộng để bao chứa lối ứng xử chuyên biệt của lớp con. Biểu đồ trạng thái của lớp con và biểu đồ trạng thái của lớp cha phải được bảo trì riêng biệt và độc lập. Biểu đồ trạng thái của lớp con cần phải được định nghĩa sử dụng các thuộc tính của lớp con chứ không phải chỉ bằng các thuộc tính của lớp cha. Mặt khác, vẫn có một sự móc nối ngoài ý muốn của lớp cha đến với lớp con thông qua các thuộc tính mà chúng sử dụng chung, ví dụ chỉ nên xem xét biểu đồ trạng thái cho các tài khoản có kỳ hạn theo phương diện sự thay đổi của chính các thuộc tính của chúng, chứ không phải là thuộc tính của lớp cha. Ta phải thực hiện như vậy để né tránh trường hợp trộn lẫn thuộc tính của lớp con và lớp cha. 129
37. Việc tuân thủ quy tắc kể trên trong quá trình vẽ biểu đồ trạng thái cho một lớp con sẽ đảm bảo tính môđun cho động tác mở rộng của bạn. VII- PHỐI HỢP MÔ HÌNH ĐỐI TƯỢNG VÀ MÔ HÌNH ĐỘNG Khi kết hợp giữa các mô hình đối tượng và mô hình động, mỗi sự kiện trong mô hình động cần phải tương thích với một thủ tục trong mô hình đối tượng. Từ đó suy ra, mỗi sự thay đổi về mặt trạng thái trong mô hình động cần phải phù hợp với một thủ tục của đối tượng. Hành động phụ thuộc vào trạng thái của đối tượng và vào sự kiện. Mối quan hệ giữa mô hình đối tượng và mô hình động có thể được miêu tả như sau: . Mô hình đối tượng là cơ cấu (framework) cho mô hình động. . Mô hình động xác định các chuỗi thay đổi được phép xảy ra đối với các đối tượng trong mô hình đối tượng. . Mô hình động bị hạn chế chỉ trong những đối tượng có mặt trong mô hình đối tượng cũng như cấu trúc của chúng. . Không thể có một mô hình động cho một đối tượng không tồn tại trong mô hình đối tượng. Có một mối quan hệ 1-1 giữa mô hình đối tượng và mô hình động. . Mô hình động chính là mô hình đối tượng cộng thêm với phần ứng xử "sống". . Mô hình đối tượng miêu tả sự khác biệt giữa các đối tượng như là sự khác biệt giữa các lớp. Khi một đối tượng ứng xử khác một đối tượng khác thì mỗi đối tượng trong số đó sẽ có một lớp riêng. . Mặc dù vậy, trong mô hình động, sự khác biệt trong ứng xử động sẽ được mô hình hóa thành các trạng thái khác nhau của cùng một lớp. . VIII- TÓM TẮT VỀ MÔ HÌNH ĐỘNG Tất cả các hệ thống đều có cấu trúc tĩnh và có ứng xử động. Cấu trúc có thể được miêu tả qua các phần tử mô hình tĩnh, ví dụ như lớp, quan hệ giữa các lớp, nút mạng và thành phần. Khái niệm ứng xử miêu tả các phần tử mô hình trong nội bộ cấu trúc sẽ tương tác với nhau dọc theo tiến trình thời gian ra sao. Đó thường là những tương tác được xác định trước và có thể được mô hình hóa. Mô hình hóa ứng xử động của một hệ thống gọi là mô hình động, được UML hỗ trợ. Có tất cả bốn loại biểu đồ khác nhau, mỗi loại với một mục đích khác nhau: biểu đồ trạng thái , biểu đồ tuần tự, biểu đồ cộng tác và biểu đồ hoạt động. Biểu đồ trạng thái được sử dụng để miêu tả lối ứng xử cũng như các trạng thái nội bộ trong một lớp (nó cũng có thể được sử dụng cho các hệ thống con hoặc cho toàn bộ hệ thống). Nó tập trung vào khía cạnh các đối tượng theo tiến trình thời gian sẽ thay đổi các trạng thái của chúng ra sao tùy theo những sự kiện xảy ra, lối ứng xử cũng như các hành động được thực hiện trong các trạng thái, và bao giờ thì sự thay đổi trạng thái xảy ra. Một sự kiện có thể nổ ra khi một điều kiện trở thành được thỏa mãn, khi nhận một tín hiệu hoặc lệnh gọi thủ tục, hoặc là khi một khoảng thời gian định trước qua đi. Biểu đồ tuần tự được sử dụng để miêu tả một nhóm các đối tượng sẽ tương tác với nhau trong một cảnh kịch riêng biệt như thế nào. Nó tập trung vào chuỗi thông điệp, tức là câu hỏi các thông điệp được gửi và nhận giữa một nhóm các đối tượng như thế nào. Biểu đồ tuần tự có hai trục; trục dọc chỉ thời gian và trục nằm ngang chỉ ra các đối tượng tham gia cảnh kịch. Khía cạnh quan trọng nhất của một biểu đồ tuần tự là thời gian. Biểu đồ cộng tác được sử dụng để miêu tả các đối tượng tương tác với nhau trong không gian bộ nhớ (space), có nghĩa là bên cạnh các tương tác động, nó còn miêu tả rõ ràng các 130
38. đối tượng được nối kết với nhau như thế nào. Trong biểu đồ cộng tác không có trục cho thời gian; thay vào đó, các thông điệp sẽ được đánh số để tạo chuỗi. Biểu đồ hoạt động được sử dụng để miêu tả sự việc xảy ra ra sao, công việc được thực hiện như thế nào. Biểu đồ hoạt động cũng có thể được sử dụng cho các thủ tục, các lớp, các trường hợp sử dụng, và cũng có thể được sử dụng để chỉ ra các quy trình nghiệp vụ (workflow). Câu hỏi và bài tập: 1. Thế nào là một vòng lặp? 2. Mô hình động chính là mô hình đối tượng cộng thêm phần ứng xử động của hệ thống 3. Các sự kiện độc lập cũng có thể là các sự kiện song song 4. Một đối tượng không nhất thiết phải có trạng thái. 5. Một lớp có thể có trạng thái ban đầu và trạng thái kết thúc. 6. Một vòng đời (chu trình) vòng lặp của đối tượng không có trạng thái khởi tạo cũng không có trạng thái kết thúc Bài tập thực hành : xem phần nội dung thực hành trang 170 131
39. BÀI 8 Tên bài : GIỚI THIỆU VỀ RATIONAL ROSE Mã bài : ITPRG3_16.8 Giới thiệu : Giới thiệu về Rational Rose, các lớp và các gói, các thao tác và các thuộc tính, các biểu đồ tương tác, các biểu đồ chuyển tiếp trạng thái, các biểu đồ thành phần và triển khai, phát triển nhóm, RoseScript và phát sinh mã Mục tiêu thực hiện: Học xong bài này học viên có khả năng : - Liệt kê các đặc tính chính của các công cụ của Rational Rose - Sử dụng giao diện người dùng và thiết lập các tùy chọn - Tạo, cập nhật, và lưu trữ các biểu đồ use case, các biểu đồ lớp. - Bổ sung các chi tiết thao tác và thuộc tính vào các biểu đồ lớp - Tạo, cập nhật, và lưu trữ các biểu đồ tương tác, các biểu đồ chuyển tiếp trạng thái - Thao tác với các gói - Tạo, cập nhật, và lưu trữ các biểu đồ thành phần và triển khai - Hiểu biết các nguyên tắc của sự phát triển nhóm trong Rational Rose - Liệt kê và mô tả một số đặc tính tăng cường của Rational Rose. Nội dung chính: I. Rational Rose Rational Rose là một phần mềm của công ty IBM, nó cho phép đặc tả các đối tượng, thiết kế các biểu đồ một cách trực quan và trên cơ sở đó sẽ phát sinh tự động mã nguồn chương trình theo ngôn ngữ lập trình được chọn như C/C++, Visual, DB2, Foxpro, Dành cho các hệ quản trị cơ sở dữ liệu, chúng ta có thể sử dụng Rotional Rose để mô tả các đối tượng, các tác nhân, thiết kế các biểu đồ và trên cơ sở đó sẽ phát sinh tự động một hệ thống các cơ sở dữ liệu quan hệ, các đơn vị chương trình quản lý cho từng mô-đun. 132
40. Hình 8.1: các gói trong Rational Rose Có 3 gói được tạo tự động. Đó là java, javax, và org. Gói Java chứa các lớp java căn bản, javax thì chứa các lớp mở rộng như là swing, servlet, Gói org thì chứa các thành phần của CORBA. 133
41. Hình 8.2: cửa sổ hai khung nhìn của ROSE Đây là cửa sổ hai khung nhìn của ROSE. Được thể hiện trong hình 2 Hình 8.3: tạo actors Đầu tiên chúng ta tạo actors. Từ vùng Brower, click “Use Case View” -> “Main”. Tạo Actors, click Actors trong Diagram Toolbox và vẽ vào trong Diagram Window 134
42. Hình 8.4: tên actor Đánh vào tên của actor hoặc chọn lựa từ combo box 135
43. Hình 8.5: tạo actor Thực hiện tương tự cho các actor: professor, student và hệ thống billing Sau đó, click “Use Case” trên Diagram Toolbox và vẽ vào Diagram Window 136
44. Hình 8.6: sau khi tạo actor Click “Unidirectional Association” trên Diagram Toolbox và vẽ vào cửa sổ Diagram Hình 8.7: Sau khi tạo “Unidirectional Association” 137
45. Some use cases can be reused for other use cases. For example, “logon validation” can be used for both “register for courses” and “maintain schedule”. Therefore, a “generalization” (uses) relation can be modeled. Click “Generalization” on the Diagram Toolbox and draw it from “register for courses” to “logon validation” and from “maintain schedule” to “logon validation”. Một số use case này có thể bị từ chối bởi một số use case khác. Ví dụ “logon validation” có thể bị từ chối bởi hai use case “register for courses” và “maintain schedule”. Tuy nhiên, có thể đưa về mô hình quan hệ họ hàng cho use cáe đó, Click “Generalization” trên Diagram Toolbox và vẽ nó từ “register for courses” đến “logon validation” và từ“maintain schedule” đến “logon validation”. Hình 8.8: Thể hiện của use case The use case is documented in each oval. Double click on “Logon Validation” and key in the use case document. Các use case được biểu diền bởi hình oval. Click đôi chôụt trên “Logon Validation” và khoá trong tài liệu use case 138
46. Hình 8.9 tạo lược đồ Tiếp theo chúng ta tạo dòng biểu đồ cho mỗi thể hiện của các đối tượng tuong tác đã được sắp xếp theo thời gian. Từ Menu chọn select “Browse” -> “Interactio n Diagrams ” -> “Use Case View” -> -> Ok. Chọn tiêu đè cho tên của dòng, “addCourse”, và chọn “Sequence” và click Ok. 139
47. Hình 8.10 tạo AddCourse Check chọn vùng Browser, biểu tượng của AddCourse xuất hiện ở vùng Use Case View, Hơn nữa, tất cả các actor chúng ta tạo ra đều có ở đây. Click chọn Student và vẽ vào của sổ Diagram, Click phải chuột trên cửa sổ Diagram và chọn “Class Wizard ” để tạo lớp “registration form”. Thực hiện tương tự cho các thủ tục “registration manager”, “math 101”, và “math 101 section 1”. 140
48. Hình 8.11Thông báo của đối tượng Điền thông báo cho đối tượng. Click “Object Message” và vẽ vào trong cửa sổ Diagram Hình 8.12: Điền thông báo cho đối tượng 141
49. Tiết theo chúng ta tạo các biểu đồ cộng tác mà các đối tượng hiển thị được sắp xếp và có sự tương tác lẫn nhau và chúng liên kết đến một đối tượng khác. Từ top menu chọn “Browse” -> “Interactio n Diagrams ” -> “Use Case View” -> -> Ok. Nhập tiêu đề cho biều đồ cộng tác, “SetCourseInfo”, và chọn “Collaboration” và click OK. Biều đồ cộng tác có tên “SetCourseInfo” xuất hiện dưới “Use Case View”. Hình 8.13: Liên kết đối tượng Click “Object Link” từ Diagram Toolbox và vẽ nó vào cửa sổ Diagram 142
50. Hình 8.14: thực hiện liên kết đối tượng Click “Link Message” từ Diagram Toolbox và vẽ nó vào của sổ Diagram. Đánh vào tên thích hợp 143
51. Hình 8.15: tên liên kết của đối tượng Trong vùng Browser, click “Logical View” -> “Package Hierarchy” để nhìn Class Diagram. Hình 8.16: dòng lược đồ addCourse Từ dòng lược đồ addCourse, chúng ta biết được lớp RegistrationManager có addCourse(). Click đôi chuột trên lớp RegistrationManager và click “Operations”. Click phải chuột trên “addCourse” với kiểu trả về là Boolean. 144
52. Hình 8.17: thêm các sự hoạt đọng thích hợp Thêm các sự hoạt đọng thích hợp Click đôi chuột trên Student từ vùng Browser chọn các thuột tính. Click phải chuột chèn tên và các thuộc tính chính 145
53. Hình 8.18: biểu đồ tương tác Từ biểu đồ tương tác, quan hệ giữa các lớp được tìm thấy. Ví dụ: RegiatraionManager thì phụ thuộc vào ScheduleAlgorithm và RegistrationForm kết hợp với RegistrationManager. Vô số các kết hợp được định nghĩa bởi liên kết kết hợp 146
54. Hình 8.19: Logic View Ở “Logic View ” -> “RegistrationManager”-> “addCourse”, click phải chuột trên “addCourse” - > New -> StateChart Diagram để tạo lược đồ trạng thái cho addCourse. 147
55. Hình 8.20: trạng thái Vẽ trạng thái, thay đổi, thiết lập sự kiện, hoạt động, điều kiện phù hợp 148
56. II. HƯỚNG DẪN VẼ MÔ HÌNH BUSINESS USECASE 1. Một số khái niệm và kí hiệu có liên quan: Trong bước xây dựng mô hình use case nghiệp vụ này, chúng ta sẽ sử dụng đến các khái niệm và các kí hiệu sau: Khái niệm Ý nghĩa Kí hiệu Tác nhân nghiệp vụ Một người hay vật bên ngoài quy (Business actor) trình nghiệp vụ tương tác với nghiệp vụ đó. Trường hợp sử dụng Một business use case xác định phía nghiệp vụ một tập hợp các thể hiện (Business Usecase) business use-case. Mỗi thể hiện là một chuỗi các hành động tuần tự mà nghiệp vụ thực hiện để đem lại một kết quả rõ ràng cho một business actor cụ thể. Một lớp business use-case chứa tất cả các luồng công việc chính và phụ có liên quan để tạo ra kết quả trên. Mô hình nghiệp vụ Là mô hình mô tả các hoạt động (Business Model) của nghiệp vụ, bao gồm mô hình usecase nghiệp vụ và mô hình đối tượng nghiệp vụ Mô hình usecase Đây là một mô hình của các nghiệp vụ (Business chức năng nghiệp vụ. Nó được Usecase Model) dùng làm đầu vào chủ yếu để xác định các vai trò trong tổ chức. 149
57. Quan hệ mở rộng Là mối quan hệ giữa 2 usecase , (Extend Relationship) trong đó 1 usecase là trường > hợp mở rộng của usecase còn lại, tức là nó có thể được thực hiện hoặc không được thực hiện trong usecase còn lại này. Quan hệ bao gồm Là mối quan hệ giữa 2 usecase (Include Relationship) trong đó 1 usecase sẽ sử dụng chức năng của usecase kia. Quan hệ tổng quát hóa Là mối quan hệ tổng quát hóa giữa các tác nhân (generalization) Lưu ý: Trong mô hình business usecase, giữa các business actor thường không có quan hệ với nhau ngoài mối quan hệ tổng quát hóa. Cách xác định business actor và business usecase A. Business actor Business actor là bất kỳ đối tượng nào bên ngòai tổ chức nghiệp vụ. Ví dụ a. khách hàng, nhà cung cấp, đối tác, đồng nghiệp ở những nghiệp vụ không được mô hình hóa, b. Một hệ thống hay một tổ chức khác B. Business usecase Use-case là một chuỗi các hành động được thực hiện trong nghiệp vụ và tạo ra một giá trị kết quả có thể quan sát được cho một tác nhân riêng lẻ của nghiệp vụ. Mô tả business usecase Giới thiệu về use case Các dòng cơ bản (basic flow): bao gồm các hoạt động chính và thứ tự mô tả nội dung chính của use case Các thay thế (alternative flow): mô tả các nhánh hoạt động bất thường để xử lý ngoại lệ 150
58. ngoài các dòng chính Cách vẽ Business usecase bằng Rational Rose Bước 1: Tạo 1 project mới trong Rational Rose Hình 8.21: Tạo 1 project mới trong Rational Rose Bước 2: Đặt tên cho project 151
59. Hình 8.22: Đặt tên cho project Bước 3: Tạo Actor Hình 8.23: Tạo Actor 152
60. Bước 4: Tạo Business Actor Hình 8.24: Tạo Business Actor Bước 5: Tạo Use case Hình 8.25: Tạo Use case 153
61. Bước 6: Tạo Business usecase Bước 7: Tạo Business Usecase Diagram Hình 8.26: Tạo Business usecase 154
62. Hình 8.27: Tạo Business Usecase Diagram NỘI DUNG THỰC HÀNH: Nội dung xuyên suốt cho các buổi thực hành đều dựa trên một bài tập. Nội dung thực hành được phân chia như sau: Thời gian Nội dung Phổ biến cách thực hành và đồ án thực hành. Tuần 1 Khởi tạo hệ thống. Xác định yêu cầu hệ thống. Sinh viên nộp: . Đặc tả hệ thống cần phát triển. . Biên bản (theo mẫu) có liên quan đến giai đoạn khởi tạo và xác định yêu cầu của hệ thống. Tuần 2 Phân tích nghiệp vụ hệ thống: . Đánh giá hiện trạng tổ chức. . Xác định các thuật ngữ nghiệp vụ. . Xác định business actor và business use case. . Mô tả ràng buộc toàn vẹn. Hướng dẫn vẽ business use case diagram bằng Rational Rose. 155
63. Thiết kế nghiệp vụ hệ thống: . Đặc tả use case nghiệp vụ. Tuần 3 . Xác định thừa tác viên và thực thể nghiệp vụ. . Đặc tả thừa tác viên và thực thể nghiệp vụ. Hướng dẫn vẽ activity diagram bằng Rational Rose. Thiết kế nghiệp vụ hệ thống (tt): . Hiện thực hóa use case nghiệp vụ bằng interaction diagram. . Lập cấu trúc mô hình đối tượng nghiệp vụ Tuần 4 . Xác định yêu cầu tự động hóa. Hướng dẫn vẽ: . Interaction diagram (sequence diagram, collaboration diagram). . Class diagram. Trong đó hướng dẫn về cách xác định các mối kết hợp. Tuần 5 Seminar báo cáo kết quả của quá trình phân tích, thiết kế nghiệp vụ Phân tích và thiết kế hệ thống: . Thiết kế lớp đối tượng: tinh chế thuộc tính, mối kết hợp và Tuần 6 phương thức. Xác định các lớp đối tượng cần thiết theo mô hình kiến trúc 3 tầng (tầng nghiệp vụ, tầng truy cập dữ liệu, tầng giao diện). Thiết kế hệ thống (tt): Tuần 7 . Mô tả hiện thực hóa nội dung thiết kế một use case. . Thiết kế dữ liệu. Tuần 8 Thiết kế hệ thống (tt): . Thiết kế giao diện. Tuần 9 Sinh viên nộp báo cáo và seminar trình bày kết quả của giai đoạn thiết kế hệ thống. Tuần 10 Thiết kế dữ liệu – Thiết kế giao diện. Triển khai cài đặt chương trình. Ghi chú: . Điểm thực hành (5/10) chia thành 3 phần sau: o Phân tích, thiết kế nghiệp vụ hệ thống. o Thiết kế hệ thống. o Chương trình cài đặt. 156
64. . Các báo cáo cho giai đoạn phân tích và thiết kế được in ra và nộp cho giáo viên thực hành theo đúng thời gian quy định. Chỉ phải in những kết quả chính trong quá trình phân tích thiết kế. Phần lớn sưu liệu có thể nộp bằng đĩa CD kèm theo. Tuy nhiên, cả báo cáo in và lưu trong đĩa CD đều phải trình bày đẹp, rõ ràng để tiện theo dõi. . Dự kiến chương trình cài đặt sẽ được nộp sớm nhất là vào ngày thi lý thuyết. Thời gian, địa điểm và hình thức nộp cụ thể sẽ được giáo viên lựa chọn. Bài tập thực hành Bài 1:Cài đặt Rational Rose. Bài 2:Sử dụng Rational Rose các nội dung lí thuyết trong bài toán. 157
65. TRẢ LỜI CÁC CÂU HỎI VÀ BÀI TẬP Bài 1: 1. Đúng 2. Đúng 3. Đúng Bài 2: 1. Ngôn ngữ mô hình hóa thống nhất – UML là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng. 2. Điểm khác nhau cơ bản giữa một phương pháp và một ngôn ngữ mô hình hoá là ngôn ngữ mô hình hoá không có một tiến trình (process) hay các câu lệnh (instruction) mô tả những công việc người sử dụng cần làm mà nó bao gồm các ký hiệu – những biểu tượng được dùng trong mô hình – và một tập các quy tắc chỉ cách sử dụng chúng. 3. Use Case 4. Sai, một hướng nhìn bao gồm một loại các biểu đồ khác nhau 5. Hướng nhìn( View), Biểu đồ (Diagram), Phần tử mô hình, Cơ chế chung. 6. Biểu đồ lớp và đặc tả lớp 7. Use case Diagram 8. Đúng 9. Sai, tác nhân là một người hoặc một vật nào đó tương tác với hệ thống. 10. Đúng 11Sai 12. Đúng Bài 4: 1. Đúng 2. sai, các lớp không phải chỉ thể hiện cấu trúc thông tin mà còn mô tả cả hành vi. 3. Đúng 4. Đúng 5. Đúng, ví dụ một mối quan hệ kết hợp là một sự nối kết giữa các lớp, có nghĩa là sự nối kết giữa các đối tượng của các lớp này. Bài 5: 1. Đúng, nó được sử dụng khi chúng ta muốn tạo nên một thực thể mới bằng cách tập hợp các thực thể tồn tại với nhau 2. Sai, khái quát hoá là quá trình bắt đầu từ một lớp chuyên biệt và khiến nó ngày càng mang tính khái quát cao hơn (lớp cha) 158
66. 3. Đúng, chuyên biệt hoá là quá trình tinh chế một lớp thành những lớp chuyên biệt hơn (lớp con) Bài 7: 1. Một chuổi sự kiện có thể được nhắc đi, nhắc lại vô số lần được gọi là vòng lặp (loop). 2. Đúng 3. Đúng 4. Sai, mọi đối tượng đều có trạng thái 5. Sai, một đối tượng có thể có trạng thái ban đầu và trạng thái kết thúc. 6. Đúng, đối tượng được coi là đã luôn luôn tồn tại ở đây và sẽ còn mãi mãi tiếp tục tồn tại. 159
67. THUẬT NGỮ CHUYÊN MÔN Unifield Modeling Language – UML: Ngôn ngữ mô hình hóa thống nhất Object Oriented Analysis – OOA: . Phân tích hướng đối tượng Object Oriented Design – OOD: Thiết kế hướng đối tượng Object Oriented Programming – OOP: Lập trình hướng đối tượng Objectory: Tiến trình Preliminary Investigation hay còn gọi là Feasibility Study:Nghiên cứu sơ bộ Analysis: Phân tích yêu cầu Design of the System: Thiết kế hệ thống Software Construction: Xây dựng phần mềm System Testing: Thử nghiệm hệ thống System Implementation: Thực hiện, triển khai System Maintenance: Bảo trì, nâng cấp Requirements Specifications: Đặc Tả Yêu Cầu Design Specifications: là Đặc Tả Thiết Kế White Box Testing: Thử hộp trắng Accurate: Chính xác Consistent: Đồng nhất Understandable: Có thể hiểu được Changeable: Dễ thay đổi Unifield Modeling Language – UML:Ngôn ngữ mô hình hóa thống nhất Method: Phương pháp hay phương thức modeling language: ngôn ngữ mô hình hoá Syntactic: Cú pháp Semantic: Ngữ nghĩa Information System: Hệ thống thống tin Technical System: Hệ thống kỹ thuật Embeded System: Hệ thống nhúng Distributed System: Hệ thống phân bố Business System: Hệ thống Giao dịch System Software: Phần mềm hệ thống dynamic models: mô hình động class diagram: biểu đồ lớp component diagram: biểu đồ thành phần collaboration diagram: biểu đồ cộng tác graphic element: phần tử đồ họa model element: Phần tử mô hình hóa deployment view: Hướng nhìn triển khai Concurrency View: Hướng nhìn song song model element: Phần tử mô hình Association: Nối kết Generalization: Khái quát hóa Dependency: Sự phụ thuộc Aggregation: Kết tập Message: thông điệp Action: hành động General Mechanism: Cơ chế cung Adornment: Trang trí Tagged Value: Giá trị đính kèm Constraint: Hạn chế Repository: Hoạt động như một nhà kho Navigation: Hỗ trợ định hướng multiuser support: Hỗ trợ nhiều người sử dụng 160
68. code generate: Tự động tạo code Reserve engineer: Tái tạo mô hình Primary Actor: tác nhân chính secondary actor: tác nhân phụ active actor: tác nhân chủ động Basic Course: hành động chính Alternative: hành động thay thế Normal Alternative: Thay thế bình thường Error Condidtions: Điều kiện gây lỗi Package: Gói Iterative: vòng lặp boundary objects: đối tượng biên (control objects: đối tượng chỉ huy (entity objects: tượng thực thể state: Trạng thái Behaviour: Ứng xử Operation: Phương thức Class diagram: Biểu đồ lớp Candidate class: lớp ứng cử vi Organisation Unit: Đơn vị tổ chức Implementation constructs: công cụ xây dựng data abstraction: trừu tượng hóa dữ liệu methods: Phương thức Association: Liên hệ Generalization: Khái quát hóa Dependency: Phụ thuộc Refinement: Nâng cấp Roles: vai trò Uni-Directional Association: Liên hệ một chiều Cardinality: thành phần tham gia Qualification: Sự hạn định Qualifier: tố hạn định OR Association: Liên hệ HOẶC Ordered Association: - Liên hệ được sắp xếp Ternary Association: - Liên hệ tam nguyên Recursive Association: Liên hệ đệ quy Aggregation: Quan hệ kết tập Diamond: hình thoi Generalization & Specialization: Khái quát hóa và chuyên biệt hóa Specialization: Chuyên biệt hoá Superclass: lớp cha Subclass: lớp con Discriminatior: Yếu tố phân biệt abstract class: lớp trừu trượng concrete class: Lớp cụ thể inheritance: ltính thừa kế Dependency & Refinement: Quan hệ phụ thuộc và nâng cấp dashed line: đường thẳng gạch rời Dynamic model: mô hình động Internal: Sự kiện nội External: sự kiện ngoại Object lifecycle: Vòng đời đối tượng State Diagram: biểu đồ trạng thái 161
69. TÀI LIỆU THAM KHẢO Giáo trình nhập môn UML/ Huỳnh Văn Đức, Đoàn Thiện Ngân.- Tp.HCM:. Lao động Xã hội Kỹ thuật và ứng dụng UML với Rational Rose 2002/ Nguyễn Tiến, Ngô Quốc Việt.- Tp. HCM:.Thống kê An Introduction to the Unified Modeling Language UMLtm "An Introduction to the Unified Modeling Language (UML)" is suitable for anyone who is interested in learning about the UML. No knowledge of object orientation is assumed; however, the instructor can customize the course as needed to make it more suitable for students who do have that knowledge. The flavor of the course that involves work with Rose assumes no experience working with visual modeling tools. *UML is a trademark of Object Management Group, Inc. in the U.S. and other countries. ICONIX Software Engineering, Inc./2800 28th Street, Suite 320/Santa Monica, CA 90405/Tel (310)458-0092/Fax (310)396-3454/email: marketing@iconixsw.com Please note that this site is no longer being updated. Please click here to return to www.omg.org. 162