Nguồn từ  http://www.ibm.com/developerworks/vn/library/bell/index.html
Cơ sở của UML: Sơ đồ lớp

Tôi cũng muốn nhắc nhở bạn đọc rằng loạt bài viết này là về các yếu tố ký pháp của UML, và rằng các bài viết này không có nghĩa là để cung cấp các hướng dẫn về cách tiếp cận tốt nhất để mô hình hoá, hoặc cách làm thế nào để xác định những điều cần được mô hình hoá trước tiên. Thay vào đó, mục đích của bài viết này và của loạt bài viết này nói chung là giúp cho bạn đọc có một sự hiểu biết cơ bản về các yếu tố ký pháp - cú pháp và ý nghĩa của chúng.Với kiến thức này, bạn sẽ có thể đọc được sơ đồ và tạo sơ đồ của riêng bạn bằng cách sử dụng các yếu tố ký pháp thích hợp.

Bài viết này giả sử rằng bạn có một sự hiểu biết sơ đẳng về thiết kế hướng đối tượng. Đối với những bạn cần một chút hỗ trợ về các khái niệm “hướng đối tượng”, có thể tham khảo bài hướng dẫn nhanh về lập trình hướng đối tượng tại địa chỉ: http://java.sun.com/docs/books/tutorial/java/concepts/. Việc đọc các phần "Lớp là gì?" và "Thừa kế là gì?" sẽ mang lại cho bạn đủ hiểu biết để làm cho bài viết này có ích. Ngoài ra, cuốn sách Các công nghệ hướng đối tượng: Hướng dẫn cho các nhà quản lý của David Taylor, sẽ cung cấp cho bạn những giảng giải tuyệt vời ở mức cao về thiết kế theo hướng đối tượng mà không đòi hỏi cần phải có một sự hiểu biết sâu về lập trình máy tính.

Tính đối lập âm dương của UML 2

Trong UML 2 có hai loại sơ đồ cơ sở: sơ đồ cấu trúc và sơ đồ hành vi. Mỗi sơ đồ UML thuộc về một trong hai loại sơ đồ này. Mục đích của sơ đồ cấu trúc là để cho thấy cấu trúc tĩnh của hệ thống đang được mô hình hoá. Chúng bao gồm các sơ đồ lớp, sơ đồ thành phần và sơ đồ đối tượng. Mặt khác, sơ đồ hành vi cho biết các hành vi động giữa các đối tượng trong hệ thống, bao gồm những hành vi như: phương thức, sự hợp tác và các hoạt động của chúng. Ví dụ về các sơ đồ hành vi là các sơ đồ hoạt động, sơ đồ ca sử dụng và sơ đồ tuần tự.

Về đầu trang

Sơ đồ cấu trúc nói chung

Như tôi đã nói, sơ đồ cấu trúc cho biết cấu trúc tĩnh của hệ thống được mô hình hoá, tập trung vào các phần tử của một hệ thống, không quan tâm đến thời gian. Cấu trúc tĩnh được chuyển tải bằng cách cho biết các kiểu và cá thể của chúng trong hệ thống. Bên cạnh việc cho thấy các kiểu hệ thống và các cá thể của chúng, sơ đồ cấu trúc cũng cho thấy ít nhất một số trong những mối quan hệ trong và giữa các phần tử này và thậm chí có khả năng cho thấy ngay cả cấu trúc nội bộ của chúng.

Sơ đồ cấu trúc rất có ích đối với các thành viên trong nhóm phát triển trong suốt vòng đời của phần mềm. Nói chung, các sơ đồ này cho việc xác nhận hợp lệ của thiết kế và việc trao đổi thông tin về thiết kế giữa các cá nhân và giữa các nhóm phát triển. Lấy ví dụ: Các nhà phân tích nghiệp vụ có thể sử dụng sơ đồ lớp hoặc các sơ đồ đối tượng để mô hình hoá tài sản và nguồn lực hiện tại của doanh nghiệp, chẳng hạn như sổ cái tài khoản, sản phẩm, hoặc phân cấp theo địa lý. Các nhà kiến trúc có thể sử dụng các sơ đồ thành phần và sơ đồ triển khai để kiểm thử/xác minh xem thiết kế của họ có đúng đắn không. Các nhà phát triển có thể sử dụng sơ đồ lớp để thiết kế và làm tài liệu chỉ dẫn cho các lớp được mã hóa (hoặc sẽ sớm được mã hóa) của hệ thống.

Sơ đồ lớp nói riêng

UML 2 coi sơ đồ cấu trúc như là một sự phân loại, không có sơ đồ mà bản thân nó được gọi là " Sơ đồ cấu trúc". Tuy nhiên, các sơ đồ lớp cung cấp cho ta một ví dụ hoàn hảo về kiểu sơ đồ cấu trúc, và cung cấp cho ta tập hợp các phần tử ký pháp ban đầu mà tất cả các sơ đồ cấu trúc khác sử dụng. Và vì rằng các sơ đồ lớp có ý nghĩa nền tảng như vậy, nên phần còn lại của bài viết này sẽ tập trung vào tập hợp các ký pháp của sơ đồ lớp. Ở cuối bài viết này, bạn sẽ biết cách làm thế nào để vẽ được một sơ đồ lớp UML 2 và có một cơ sở vững chắc để hiểu biết về các sơ đồ cấu trúc khác khi chúng ta bàn về chúng trong bài viết sau.

Về đầu trang

Các thành phần cơ sở

Như tôi đã đề cập ở phần trước, mục đích của sơ đồ lớp là để cho thấy các kiểu thành phần được mô hình hoá trong hệ thống. Trong hầu hết các mô hình UML, các thành phần này gồm có:

• lớp
  
   
• giao diện
  
   
• kiểu dữ liệu
  
   
• thành phần.

UML sử dụng một tên đặc biệt cho những thành phần này: các “phân loại" (classifier). Nói chung, bạn có thể coi một phân loại giống như một lớp, nhưng về mặt kỹ thuật, phân loại là một thuật ngữ tổng quát hơn, nói đến ba kiểu thành phần khác nêu trên.

Tên của lớp

Hình thức biểu diễn của UML của một lớp là một hình chữ nhật gồm ba ngăn chồng lên nhau theo chiều dọc, như trong hình 1. Ngăn trên cùng cho thấy tên của lớp. Ngăn ở giữa liệt kê những phần cơ sở của UML: Các thuộc tính lớp của sơ đồ lớp. Ngăn dưới cùng liệt kê các hoạt động của lớp. Khi vẽ một phần tử lớp trong một sơ đồ lớp, bạn phải sử dụng ngăn trên cùng, hai ngăn phía dưới là tùy chọn. (Hai ngăn ở dưới có thể không cần thiết trên một sơ đồ mức cao, ở đó mục đích là chỉ để cho thấy các mối quan hệ giữa các phân loại). Hình 1 cho thấy một chuyến bay của một hãng hàng không được mô hình hoá như là một lớp UML. Như chúng ta có thể thấy, tên của lớp là Flight (chuyến bay), và tại ngăn ở giữa chúng ta thấy rằng lớp Flight có ba thuộc tính: flightNumber (số hiệu chuyến bay), departureTime (thời gian khởi hành) và flightDuration (thời gian bay). Tại ngăn dưới cùng, chúng ta thấy rằng lớp Flight có hai hoạt động: delayFlight (lùi chuyến bay) và getArrivalTime (tính thời gian đến).

Hình 1: Sơ đồ lớp cho lớp Flight

Danh sách các thuộc tính của lớp

Phần thuộc tính của một lớp (ngăn ở giữa) liệt kê mỗi thuộc tính của các thuộc tính của trên một dòng riêng biệt. Phần thuộc tính là tùy chọn, nhưng khi được sử dụng nó chứa mỗi thuộc tính của lớp được hiển thị dưới dạng danh sách. Mỗi dòng sử dụng định dạng sau:

name : attribute type

flightNumber : Integer

Tiếp tục với ví dụ lớp Flight, chúng ta có thể mô tả các thuộc tính của lớp với thông tin về kiểu thuộc tính, như trong bảng 1.

Trong các sơ đồ lớp nghiệp vụ, các kiểu thuộc tính thường tương ứng với các đơn vị có ý nghĩa đối với những người đọc sơ đồ (chẳng hạn: phút, đô la, vv). Tuy nhiên, một sơ đồ lớp, sẽ được sử dụng để tạo ra mã, cần phải có các lớp mà kiểu thuộc tính của nó chỉ hạn chế trong các kiểu thuộc tính do các ngôn ngữ lập trình cung cấp, hoặc các kiểu có trong mô hình sẽ được thực hiện trong hệ thống.

Đôi khi ta cần cho thấy trên một sơ đồ lớp rằng một thuộc tính cụ thể có giá trị mặc định. (Ví dụ: trong một ứng dụng tài khoản ngân hàng, một tài khoản ngân hàng mới sẽ bắt đầu với số dư bằng không). Đặc tả của UML cho phép xác định các giá trị mặc định trong danh sách các thuộc tính bằng cách sử dụng ký pháp sau đây:

tên : kiểu thuộc tính = giá trị mặc định

Ví dụ:

balance : Dollars = 0

Việc hiển thị một giá trị mặc định cho các thuộc tính là tùy chọn; Hình 2 cho thấy một lớp Bank Account (tài khoản ngân hàng) với một thuộc tính được gọi là balance (số dư), thuộc tính này có giá trị mặc định là 0.

Hình 2: Một sơ đồ lớp Bank Account hiển thị giá trị của thuộc tính số dư được mặc định là 0 đô la.

Danh sách các hoạt động của lớp

Tư liệu về các hoạt động của lớp được cung cấp tại ngăn thứ ba (ngăn dưới cùng) của hình chữ nhật sơ đồ lớp, ngăn này cũng là tùy chọn. Giống như các thuộc tính, các hoạt động của một lớp được hiển thị dưới dạng danh sách, mỗi hoạt động nằm trên một dòng riêng của nó. Các hoạt động được cung cấp tư liệu bằng cách sử dụng ký pháp sau đây:

Tên (danh sách tham số) : kiểu giá trị trả về

Các hoạt động của lớp Flight được ánh xạ vào bảng 2 dưới đây.

Hình 3 cho thấy hoạt động delayFlight có một tham số đầu vào - numberOfMinutes – có kiểu “phút”. Tuy nhiên, hoạt động delayFlight không có giá trị trả về ¹. Khi một hoạt động có các tham số, thì chúng được đặt trong dấu ngoặc đơn của hoạt động; từng tham số sử dụng định dạng "tên tham số : kiểu tham số".

Hình 3: Các tham số của các hoạt động của lớp Flight bao gồm cả tùy chọn đánh dấu "in".

Khi cung cấp tư liệu cho một tham số của hoạt động, bạn có thể sử dụng một chỉ báo tùy chọn để cho biết tham số là đầu vào hay đầu ra của hoạt động. Chỉ báo tùy chọn này xuất hiện dưới dạng chỉ báo "in" hay "out" trong ngăn của các hoạt động trong hình 3. Thông thường thì những chỉ báo này là không cần thiết trừ khi ta sử dụng ngôn ngữ lập trình cũ như Fortran, trong trường hợp này thì thông tin này có thể hữu ích. Tuy nhiên, trong các ngôn ngữ C++ và Java, thì tất cả các tham số đều là tham số "in" và vì rằng "in" là kiểu mặc định của tham số theo các đặc tả của UML, nên hầu hết mọi người sẽ bỏ qua các chỉ báo đầu vào/đầu ra.

Sự kế thừa

Một khái niệm rất quan trọng trong thiết kế hướng đối tượng là sự kế thừa, nói về khả năng của một lớp (lớp con) kế thừa các chức năng giống nhau của một lớp khác (lớp cấp trên), và sau đó thêm các chức năng mới của riêng nó. (Theo ý nghĩa hoàn toàn không mang tính kỹ thuật, bạn hãy tưởng tượng rằng tôi thừa hưởng khả năng chung về âm nhạc từ mẹ tôi, nhưng trong gia đình tôi là người duy nhất chơi guitar điện). Để mô hình hoá sự thừa kế trên một sơ đồ lớp, một đường thẳng liền mạch được kẻ từ lớp con (lớp kế thừa hành vi) với một hình đầu mũi tên (hoặc hình tam giác) rỗng, khép kín chỉ tới lớp cấp trên. Ta hãy xem xét các kiểu tài khoản ngân hàng: Hình 4 cho thấy cách cả hai lớp CheckingAccount và SavingsAccount kế thừa từ lớp BankAccount như thế nào.

Hình 4: Sự thừa kế được biểu thị bằng một đường thẳng liền mạch với với một hình đầu mũi tên rỗng, khép kín trỏ đến lớp trên.

Trong hình 4, mối quan hệ thừa kế được vẽ bằng các đường riêng biệt cho từng lớp con, đây là phương pháp được sử dụng trong IBM Rational Rose và IBM Rational XDE. Tuy nhiên, có một cách khác để vẽ thừa kế được gọi là ký pháp hình cây. Bạn có thể sử dụng ký pháp hình cây khi có hai hoặc nhiều lớp con, như trong hình 4, ngoại trừ các đường thừa kế hợp nhất với nhau như một nhánh cây. Hình 5 là hình vẽ lại chính các quan hệ thừa kế của hình 4, nhưng lần này bằng cách sử dụng ký pháp hình cây.

Hình 5: Một ví dụ về thừa kế, sử dụng ký pháp hình cây

Các lớp trừu tượng và các hoạt động trừu tượng
Một độc giả quan sát tinh ý sẽ thấy rằng các sơ đồ trong hình 4 và 5 sử dụng các dòng chữ nghiêng cho tên của lớp BankAccount và hoạt động withdrawal (rút tiền từ tài khoản). Điều này biểu thị rằng lớp BankAccount là một lớp trừu tượng và phương thức withdrawal là một hoạt động trừu tượng. Nói cách khác, lớp BankAccount cung cấp chữ ký của hoạt động trừu tượng rút tiền và hai lớp con CheckingAccount và SavingsAccount mỗi lớp thực hiện phiên bản của hoạt động đó theo kiểu riêng của chúng.

Tuy nhiên, các lớp cấp trên (lớp cha) không buộc phải là lớp trừu tượng. Hoàn toàn bình thường khi một lớp tiêu chuẩn thông thường là lớp cấp trên.

Các quan hệ kết hợp
Khi bạn mô hình hoá một hệ thống, một số đối tượng sẽ có liên quan với nhau, và bản thân các mối quan hệ đó cần phải được mô hình hoá để làm rõ. Có năm kiểu kết hợp. Tại phần này tôi sẽ thảo luận hai trong năm kiểu kết hợp – kết hợp hai hướng và kết hợp theo một hướng duy nhất, và sẽ thảo luận về ba kiểu kết hợp còn lại tại phần Bên ngoài các phần cơ sở. Xin lưu ý rằng việc thảo luận chi tiết về khi nào thì sử dụng từng kiểu kết hợp ấy là không nằm trong phạm vi của bài viết này. Thay vào đó, tôi sẽ tập trung vào mục đích của từng kiểu kết hợp và chỉ ra cách quan hệ kết hợp đó được vẽ trên một sơ đồ lớp như thế nào.

Kết hợp hai hướng (kết hợp tiêu chuẩn)
Mối kết hợp là sự kết nối giữa hai lớp. Các kết hợp luôn được coi là hai hướng; điều đó có nghĩa là cả hai lớp đều nhận biết về nhau và nhận biết được mối quan hệ của chúng, trừ khi bạn định rõ mối kết hợp đó là một kiểu kết hợp khác. Trở lại ví dụ Fight ở trên, hình 6 cho ta thấy một loại kết hợp tiêu chuẩn giữa lớp Flight và lớp Plane (Máy bay).

Hình 6: Ví dụ về kết hợp hai hướng giữa lớp Flight và lớp Plane

Mối kết hợp hai hướng được biểu thị bằng một đường thẳng liền mạch giữa hai lớp. Ở hai đầu của đường thẳng, bạn đặt tên của vai trò và giá trị của bội số (multiplicity). Hình 6 cho thấy các chuyến bay được kết hợp với một máy bay cụ thể, và lớp Flight biết về kết hợp này. Lớp Plane đóng vai trò của "assignedPlane" trong kết hợp này bởi vì tên của vai trò ở bên cạnh lớp Flight qui định như vậy. Giá trị bội số của kết hợp ở bên cạnh lớp Plane là 0 .. 1 có nghĩa là khi một cá thể chuyến bay tồn tại, nó có thể có một cá thể máy bay được kết hợp với nó hoặc không có máy bay nào được kết hợp với nó (tức là chưa có máy bay nào được phân bổ). Hình 6 cũng cho thấy rằng lớp Plane biết mối kết hợp của mình với lớp Flight. Trong mối kết hợp này, các chuyến bay sẽ đóng vai trò của "assignedFlights"; sơ đồ trong hình 6 cho chúng ta thấy rằng cá thể máy bay có thể không được kết hợp với chuyến bay nào (ví dụ đó là một máy bay mới tinh) hoặc với một số lượng vô hạn các chuyến bay (ví dụ: máy bay đã được sử dụng trong 5 năm qua).

Đối với những người muốn biết các giá trị bội số có thể sử dụng ở mỗi đầu của quan hệ kết hợp là những gì, bảng 3 dưới đây liệt kê một số ví dụ về các giá trị bội số kèm theo ý nghĩa của chúng.

Kết hợp đơn hướng
Trong một kết hợp đơn hướng, hai lớp có liên quan với nhau, nhưng chỉ có một lớp biết rằng mối quan hệ đó tồn tại. Hình 7 là một ví dụ về báo cáo tài khoản bị rút quá số tiền với một kết hợp đơn hướng.

Hình 7: Ví dụ về một kết hợp đơn hướng : Lớp OverdrawnAccountsReport biết lớp BankAccount, nhưng lớp BankAccount không biết mối kết hợp này.

Một kết hợp đơn hướng được vẽ bằng một đường thẳng liền mạch với một hình đầu mũi tên mở (không phải là hình đầu mũi tên khép kín, hay tam giác, được sử dụng để biểu thị sự thừa kế) chỉ tới lớp được biết đến. Giống như các kết hợp tiêu chuẩn, kết hợp đơn hướng bao gồm một tên vai trò và giá trị bội số, nhưng không giống như các kết hợp hai hướng tiêu chuẩn, các kết hợp đơn hướng chỉ chứa tên của vai trò và giá trị bội số cho lớp được biết đến. Trong ví dụ tại hình 7, lớp OverdrawnAccountsReport biết về lớp BankAccount, và lớp BankAccount đóng vai trò của "overdrawnAccounts." Tuy nhiên, không giống như một kết hợp tiêu chuẩn, lớp BankAccount không biết rằng nó được kết hợp với lớp OverdrawnAccountsReport.²

Các gói
Nếu bạn đang mô hình hóa một hệ thống lớn hoặc một lĩnh vực nghiệp vụ lớn, thì không thể tránh khỏi, sẽ có nhiều phân loại khác nhau trong mô hình của bạn. Việc quản lý tất cả các lớp có thể là một nhiệm vụ khó khăn, do vậy UML cung cấp một phần tử tổ chức được gọi là gói. Các gói cho phép các nhà tạo mô hình tổ chức các phân loại của mô hình thành các vùng tên, là một kiểu giống như các thư mục trong một hệ thống tệp. Việc phân chia một hệ thống thành nhiều gói làm cho hệ thống trở nên dễ hiểu, đặc biệt là nếu từng gói đại diện cho một phần cụ thể của hệ thống.³

Có hai cách để vẽ các gói trên sơ đồ. Không có quy tắc để xác định xem ký pháp nào sẽ được sử dụng, ngoại trừ việc tuân theo phán xét riêng của bạn về việc ký pháp nào là dễ đọc các sơ đồ lớp mà bạn đang vẽ nhất. Cả hai cách sẽ bắt đầu bằng một hình chữ nhật lớn với một hình chữ nhật nhỏ hơn (phiếu) nằm ở phía trên cùng bên trái nó, như trong hình 8. Nhưng nhà tạo mô hình phải quyết định cách thể hiện các thành viên của gói như thế nào, ví dụ như sau:

• Nếu nhà tạo mô hình quyết định hiển thị các thành viên của gói bên trong hình chữ nhật lớn, thì tất cả các thành viên⁴ sẽ phải được đặt trong hình chữ nhật đó. Cũng vậy, tên của gói cần được đặt trong hình chữ nhật nhỏ hơn của gói (như trong hình 8).
  
   
• Nếu nhà tạo mô hình quyết định hiển thị các thành viên của gói bên ngoài hình chữ nhật lớn, thì tất cả các thành viên sẽ được hiển thị trên sơ đồ cần phải được đặt ở bên ngoài hình chữ nhật ấy. Để cho thấy phân loại nào thuộc về gói, thì một đường thẳng sẽ được vẽ từ từng phân loại đến một vòng tròn có dấu cộng (+) bên trong vòng tròn gắn liền với gói đó (Hình 9).

Hình 8: Một ví dụ về phần tử gói cho thấy các thành viên của gói đó nằm bên trong ranh giới hình chữ nhật của gói

Hình 9: Một ví dụ về phần tử gói hiển thị các thành viên của gói thông qua các đường nối

Tầm quan trọng của việc hiểu biết các thành phần cơ sở

Điều quan trọng hơn bao giờ hết trong UML 2 là phải hiểu được những thành phần cơ sở của sơ đồ lớp. Đó là do các sơ đồ lớp đồ cung cấp các khối xây dựng cơ bản cho tất cả các sơ đồ cấu trúc khác, chẳng hạn như các sơ đồ thành phần hoặc các sơ đồ đối tượng (chỉ nêu ví dụ như vậy).

Về đầu trang

Bên ngoài những thành phần cơ sở

Đến thời điểm này, tôi đã bàn về những thành phần cơ sở của sơ đồ lớp, nhưng bạn hãy đọc tiếp nhé! Trong các phần sau, tôi sẽ đề cập đến các khía cạnh quan trọng hơn của sơ đồ lớp mà bạn cần biết để vận dụng tốt. Chúng bao gồm các giao diện, ba kiểu kết hợp còn lại, tầm nhìn thấy và các bổ sung khác trong đặc tả của UML 2.

Các giao diện
Trong phần trước của bài viết, tôi đã đề nghị bạn xem các phân loại đơn giản như là các lớp. Trên thực tế, phân loại là một khái niệm tổng quát hơn, bao gồm các kiểu dữ liệu và các giao diện.

Việc thảo luận đầy đủ về khi nào và làm thế nào để sử dụng các kiểu dữ liệu và các giao diện một cách hiệu quả trong sơ đồ cấu trúc của một hệ thống nằm ngoài phạm vi của bài viết này. Thế thì tại sao tôi phải đề cập đến kiểu dữ liệu và các giao diện ở đây? Đôi khi bạn muốn mô hình hoá các kiểu phân loại này trong một sơ đồ cấu trúc, và điều quan trọng là phải sử dụng các ký pháp thích hợp khi làm việc này, hoặc ít nhất là ta phải nhận thức được các kiểu phân loại đó. Việc vẽ các phân loại không chính xác sẽ có nhiều khả năng gây nhầm lẫn cho những người đọc sơ đồ cấu trúc của bạn, và làm cho hệ thống có thể sẽ không đáp ứng các yêu cầu.

Lớp khác với giao diện: Lớp có thể có một cá thể thực sự của nó, trong khi một giao diện phải có ít nhất một lớp để thực hiện nó. Trong UML 2, một giao diện được coi là một sự chuyên biệt hoá của một phần tử mô hình hóa lớp. Vì vậy, một giao diện được vẽ giống như một lớp, ngoại trừ trong ngăn ở phía trên cùng của hình chữ nhật có chữ "«interface»" (giao diện), như trong hình 10.⁵

Hình 10: Một ví dụ về sơ đồ lớp, trong đó các lớp Professor (Giáo sư) và Student (Sinh viên) thực hiện giao diện Person (Người).

Trong sơ đồ tại hình 10, cả hai lớp Giáo sư và Sinh viên đều thực hiện giao diện Người và không kế thừa từ nó. Chúng ta biết điều này vì hai lý do: 1) Các đối tượng Người được định nghĩa là một giao diện - nó có chữ "«interface»" trong vùng tên của đối tượng, và chúng ta thấy rằng các đối tượng Giáo sư và Sinh viên là các đối tượng lớp vì chúng được dán nhãn theo các quy tắc để vẽ một đối tượng lớp (không có thêm chữ biểu thị phân loại trong vùng tên của chúng). 2) Chúng ta biết rằng thừa kế không được hiển thị ở đây, bởi vì đường nối có đầu mũi tên có dạng chấm chấm và không liền mạch. Như trong hình 10, đường nối chấm chấm có đầu mũi tên khép kín, rỗng có nghĩa là nhận biết (hoặc thực hiện); vì chúng ta đã thấy trong hình 4, một đường nối liền mạch có mũi tên khép kín, rỗng có nghĩa là sự thừa kế.

Các quan hệ kết hợp khác
Ở trên, tôi đã thảo luận về các kết hợp hai hướng và đơn hướng. Bây giờ tôi sẽ thảo luận về ba loại kết hợp còn lại.

Lớp kết hợp
Khi mô hình hoá một quan hệ kết hợp, có những lúc bạn đưa vào thêm một lớp khác vì nó chứa các thông tin có giá trị về mối quan hệ. Để làm điều này bạn sẽ sử dụng một lớp kết hợp mà bạn buộc với quan hệ kết hợp ban đầu. Lớp kết hợp được biểu diễn như một lớp bình thường. Sự khác biệt là đường kết hợp giữa các lớp ban đầu cắt ngang đường chấm chấm nối với các thành phần UML cơ sở của kết hợp đó: Các lớp trong sơ đồ lớp. Hình 11 là một lớp kết hợp trong ví dụ về ngành hàng không của chúng ta.

Hình 11: Thêm lớp kết hợp MileageCredit

Trong sơ đồ lớp tại hình 11, sự kết hợp giữa lớp Flight và lớp FrequentFlyer dẫn đến kết quả là một lớp kết hợp được gọi là lớp MileageCredit. Điều này có nghĩa là khi một cá thể của lớp Flight được kết hợp với một cá thể của lớp FrequentFlyer, thì cũng sẽ có một cá thể của lớp MileageCredit.

Kết tập
Kết tập là một kiểu kết hợp đặc biệt được sử dụng để mô hình hóa mối quan hệ “tổng thể - các thành phần của nó”. Trong các quan hệ kết tập cơ sở, vòng đời của một lớp thành phần độc lập với vòng đời của lớp tổng thể.

Lấy ví dụ: Chúng ta có thể coi Car (Xe hơi) như một thực thể tổng thể và Car Wheel (Bánh xe) là một phần của toàn bộ xe. Bánh xe có thể được chế tạo một vài tuần trước, và nó có thể được cất giữ trong kho trước khi được đặt vào chiếc xe khi lắp ráp. Trong ví dụ này, cá thể của lớp Wheel (bánh xe) rõ ràng tồn tại một cách độc lập với cá thể lớp Car. Tuy nhiên, có trường hợp vòng đời của lớp thành phần không độc lập với lớp tổng thể – điều này được gọi là kết tập cấu thành (composition aggregation). Ví dụ, ta hãy xem xét mối quan hệ của một công ty với các phòng ban của nó. Cả Công ty lẫn các phòng ban được mô hình hoá như các lớp, và một phòng ban không thể tồn tại trước khi một công ty tồn tại. Ở đây cá thể lớp Phòng ban phụ thuộc vào sự tồn tại của cá thể của lớp Công ty.

Ta hãy khảo sát thêm về kết tập cơ sở và kết tập cấu thành.

Kết tập cơ sở
Một kết hợp bằng quan hệ kết tập chỉ ra rằng một lớp là một phần của lớp khác. Trong mối quan hệ kết tập, cá thể của lớp con có thể tồn tại lâu hơn lớp cha của nó. Để biểu diễn mối quan hệ kết tập, bạn vẽ một đường liền mạch từ lớp cha đến lớp thành phần, và vẽ một hình thoi rỗng tại đầu phía lớp cha của quan hệ kết hợp này. Hình 12 là một ví dụ của mối quan hệ kết tập giữa Xe và Bánh xe.

Hình 12: Ví dụ về một quan hệ kết tập

Kết tập cấu thành
Các mối quan hệ kết tập cấu thành chỉ là một hình thức khác của mối quan hệ kết tập, nhưng vòng đời của cá thể của lớp con phụ thuộc vào vòng đời của cá thể của lớp cha. Trong hình 13, cho thấy mối quan hệ cấu thành giữa lớp Công ty và lớp Phòng ban, bạn hãy lưu ý các thành phần UML cơ sở: Mối quan hệ cấu thành trong sơ đồ lớp được vẽ giống như mối quan hệ kết tập, nhưng lần này, hình thoi được tô đặc.

Hình 13: Ví dụ về một mối quan hệ cấu thành

Trong mối quan hệ được mô hình hoá trong hình 13, một cá thể của lớp Công ty sẽ luôn luôn có ít nhất một cá thể của lớp Phòng ban. Vì mối quan hệ này là một mối quan hệ cấu thành, khi một cá thể công ty bị loại bỏ/phá vỡ, thì cá thể Phòng ban cũng bị tự động loại bỏ/phá vỡ. Một đặc tính quan trọng khác của kết tập cấu thành là lớp thành phần chỉ có thể liên quan đến chỉ một cá thể của lớp cha (ví dụ như lớp Công ty trong ví dụ của chúng ta).

Các kết hợp phản thân
Bây giờ chúng ta đã thảo luận về tất cả các loại kết hợp. Như bạn có thể nhận thấy, tất cả các ví dụ của chúng ta đã cho thấy mối quan hệ giữa hai lớp khác nhau. Tuy nhiên, một lớp cũng có thể được kết hợp với chính nó, bằng cách sử dụng một kết hợp phản thân. Thoạt đầu, điều này có thể không có ý nghĩa, nhưng bạn hãy nhớ rằng các lớp là trừu tượng. Hình 14 cho thấy, lớp Employee (nhân viên) có thể liên hệ đến chính nó thông qua vai trò người quản lý/người bị quản lý. Khi lớp được kết hợp với chính nó, thì điều đó không có nghĩa là một cá thể lớp được kết hợp đến chính nó, mà là cá thể của một lớp được liên hệ đến một cá thể khác của lớp.

Hình 14: Ví dụ về một mối quan hệ kết hợp phản thân

Mối quan hệ được vẽ trong hình 14 có nghĩa là một cá thể của lớp Employee có thể là người quản lý của một cá thể nhân viên. Tuy nhiên, do vai trò của "người bị quản lý" trong mối quan hệ này có bội số là 0 ..*; nên một nhân viên có thể không có bất kỳ nhân viên nào khác để quản lý.

Tầm nhìn thấy
Trong thiết kế hướng đối tượng, có một ký pháp về tầm nhìn thấy của các thuộc tính và các hoạt động. UML xác định bốn kiểu tầm nhìn thấy: công cộng, được bảo vệ, riêng tư và gói.

Đặc tả kỹ thuật của UML không yêu cầu phải hiển thị tầm nhìn thấy của các thuộc tính và hoạt động trên sơ đồ lớp, nhưng nó đòi hỏi rằng tầm nhìn thấy này phải được định nghĩa cho mỗi thuộc tính hoặc hoạt động. Để hiển thị tầm nhìn thấy trên một sơ đồ lớp, bạn đặt một dấu hiệu về tầm nhìn thấy ở ngay trước tên thuộc tính hoặc tên hoạt động. Mặc dù UML xác định bốn loại tầm nhìn thấy, nhưng một ngôn ngữ lập trình thực tế có thể bổ sung thêm các tầm nhìn thấy khác, hoặc nó có thể không hỗ trợ các tầm nhìn thấy mà UML định nghĩa. Bảng 4 hiển thị các dấu hiệu khác nhau của các tầm nhìn thấy được UML hỗ trợ.

Bây giờ, chúng ta hãy nhìn vào một lớp, có hiển thị các kiểu tầm nhìn thấy đã xác định cho các thuộc tính và hoạt động của nó. Trong hình 15, tất cả các thuộc tính và các hoạt động là công cộng, ngoại trừ hoạt động updateBalance. Hoạt động updateBalance được bảo vệ.

Hình 15: Lớp BankAccount cho thấy tầm nhìn thấy của các thuộc tính và hoạt động của nó

Về đầu trang

Các bổ sung của UML 2

Bây giờ khi chúng ta đã thảo luận về các cơ sở và các chủ đề nâng cao, chúng ta sẽ thảo luận về các ký pháp mới được bổ sung vào sơ đồ lớp kể từ UML phiên bản 1.x.

Các cá thể
Khi mô hình hóa cấu trúc của một hệ thống, đôi khi cần phải hiển thị các cá thể mẫu của các lớp. Để mô hình hoá điều này, UML 2 cung cấp phần tử đặc tả cá thể, phần tử này cho thấy các thông tin đáng quan tâm bằng cách sử dụng các cá thể mẫu (hoặc có thực) trong hệ thống.

Ký pháp biểu diễn một cá thể cũng giống như một lớp, nhưng thay cho ngăn ở phía trên chỉ có tên của lớp, thì bây giờ ở đó là ghép nối của tên cá thể và tên lớp và được gạch chân.

Instance Name : Class Name

Ví dụ:

Donald : Person

Bởi vì mục đích của việc hiển thị các cá thể là để hiển thị các thông tin đáng chú ý hoặc có liên quan, nên không nhất thiết phải bao gồm trong mô hình của bạn toàn bộ các thuộc tính và hoạt động của cá thể. Thay vào đó, chỉ hiển thị các thuộc tính và giá trị đáng quan tâm của chúng như được mô tả trong hình 16 là hoàn toàn thích đáng.

Hình 16: Một ví dụ về một cá thể của lớp Plane (chỉ có các giá trị thuộc tính đáng quan tâm được hiển thị)

Tuy nhiên, chỉ hiển thị một số cá thể không có mối quan hệ của chúng thì không hữu ích lắm, cho nên UML 2 cũng cho phép mô hình hóa các mối quan hệ/các kết hợp ở mức độ cá thể. Các quy tắc để vẽ các kết hợp cũng giống như các quy tắc đối với các mối quan hệ của lớp bình thường, mặc dù có một yêu cầu bổ sung khi mô hình hóa các kết hợp. Hạn chế bổ sung là mối quan hệ kết hợp phải phù hợp với các quan hệ của sơ đồ lớp và do đó các tên vai trò của kết hợp cũng phải phù hợp với sơ đồ lớp. Ví dụ về điều này được thể hiện trong hình 17. Trong ví dụ này các cá thể là các cá thể ví dụ của các sơ đồ lớp trong hình 6.

Hình 17: Ví dụ của hình 6, khi sử dụng các cá thể thay vì các lớp

Hình 17 có hai cá thể của lớp Flight vì sơ đồ lớp đã chỉ ra rằng mối quan hệ giữa lớp Plane và lớp Flight là từ 0 tới nhiều (zero-to-many). Do đó, ví dụ của chúng ta cho thấy rằng có hai cá thể chuyến bay mà máy bay có số hiệu NX0337 liên quan tới.

Các vai trò
Việc mô hình hóa các cá thể của các lớp đôi khi chi tiết hơn điều mà ta muốn. Đôi khi, bạn chỉ muốn mô hình hóa mối quan hệ của lớp ở mức chung, tổng quát hơn. Trong các trường hợp như vậy, bạn nên sử dụng ký pháp vai trò. Ký pháp vai trò rất giống với ký pháp các cá thể. Để mô hình hoá vai trò của một lớp, bạn vẽ một hộp và đặt tên vai trò của lớp và tên lớp ở bên trong giống như ký pháp các cá thể, nhưng lần này bạn không gạch chân các từ. Hình 18 cho thấy một ví dụ về các vai trò của lớp nhân viên, được mô tả bằng sơ đồ ở hình 14. Trong hình 18, chúng ta có thể nói rằng, mặc dù các lớp nhân viên được kết hợp tới chính bản thân nó, mối quan hệ thực sự là giữa cá thể nhân viên Employee, đóng vai trò là người quản lý và một cá thể nhân viên, đóng vai trò là thành viên trong nhóm.

Hình 18: Một sơ đồ lớp hiển thị lớp trong hình 14 với các vai trò khác nhau của nó

Hãy lưu ý rằng bạn không thể mô hình hoá vai trò của một lớp trên một sơ đồ lớp thuần tuý, mặc dù hình 18 cho thấy rằng bạn có thể làm điều đó. Để sử dụng ký pháp vai trò, bạn sẽ cần phải sử dụng ký pháp cấu trúc nội bộ, được thảo luận ở phần kế tiếp.

Các cấu trúc nội bộ
Một trong những đặc tính hữu dụng hơn của các sơ đồ cấu trúc của UML 2 là ký pháp mới của cấu trúc nội bộ. Nó cho phép bạn hiển thị cách mà một lớp hoặc phân loại khác được cấu thành ở bên trong như thế nào. Ta không thể làm được điều này với UML phiên bản 1.x, bởi vì tập hợp các ký pháp hạn chế bạn chỉ hiển thị được các mối quan hệ kết tập mà một lớp đã có. Bây giờ, bằng UML 2, các ký pháp của cấu trúc nội bộ cho phép bạn hiển thị rõ ràng hơn các bộ phận của lớp liên quan với nhau như thế nào.

Ta hãy xem một ví dụ. Trong hình 18 chúng ta có một sơ đồ lớp hiển thị cách lớp Plane được cấu thành từ bốn động cơ và hai đối tượng phần mềm điều khiển như thế nào. Những cái còn thiếu trong sơ đồ này là bất kỳ thông tin nào về cách thức mà các bộ phận máy bay được lắp ráp. Từ sơ đồ ở hình 18, bạn không thể nói rằng các đối tượng phần mềm điều khiển, mỗi cái sẽ điều khiển hai động cơ, hay là một đối tượng phần mềm điều khiển điều khiển ba động cơ và phần mềm còn lại điều khiển một động cơ.

Hình 19: Một sơ đồ lớp chỉ cho thấy mối quan hệ giữa các đối tượng

Việc vẽ cấu trúc nội bộ của một lớp sẽ cải thiện tình trạng này. Bạn bắt đầu bằng cách vẽ một hộp với hai ngăn. Ngăn trên cùng chứa tên lớp, và ngăn bên dưới chứa cấu trúc nội bộ của lớp, hiển thị các lớp bộ phận của lớp cha với các vai trò tương ứng của của chúng, cũng như cách từng lớp cụ thể được liên hệ đến các lớp khác trong vai trò đó. Hình 19 cho thấy cấu trúc bên trong của lớp máy bay; hãy lưu ý cấu trúc nội bộ đã xóa bỏ mọi lẫn lộn như thế nào.

Hình 20: Một ví dụ về cấu trúc nội bộ của lớp Plane.

Trong hình 20 lớp máy bay có hai đối tượng ControlSoftware và mỗi đối tượng điều khiển hai động cơ. Đối tượng ControlSoftware ở phía bên trái của sơ đồ (control1) điều khiển động cơ 1 và 2. Lớp ControlSoftware ở phía bên phải của sơ đồ (control2) điều khiển động cơ 3 và 4.

Về đầu trang

Kết luận

Có ít nhất hai lý do quan trọng để phải hiểu được sơ đồ lớp. Lý do thứ nhất là nó cho thấy cấu trúc tĩnh của các phân loại trong một hệ thống; lý do thứ hai là sơ đồ cung cấp cho các ký pháp cơ bản cho các sơ đồ cấu trúc khác theo quy định của UML. Các nhà phát triển phần mềm sẽ nghĩ là sơ đồ lớp được tạo ra chỉ dành cho họ, nhưng các thành viên nhóm khác sẽ thấy chúng cũng hữu ích. Các nhà phân tích nghiệp vụ có thể sử dụng sơ đồ lớp để mô hình hoá hệ thống từ phối cảnh nghiệp vụ. Như chúng ta sẽ thấy trong các bài khác của loạt bài viết này về cơ sở của UML, các sơ đồ khác - bao gồm sơ đồ hoạt động, sơ đồ tuần tự, và sơ đồ trạng thái (statechart) – đều tham chiếu đến các lớp đã được mô hình hoá và được cung cấp các tham số trong sơ đồ lớp.

Bài viết tiếp theo của loạt bài viêt về "Cơ sở của UML”: Sơ đồ thành phần.

Về đầu trang

Ghi chú

¹ Lớp delayFlight không có giá trị trả về vì tôi quyết định thiết kế là không có giá trị trả về. Bạn có thể đưa ra ý kiến phản đối rằng hoạt động “lùi chuyến bay” nên trả về một kết quả là thời gian đến đích mới, và nếu như thế, chữ ký của hoạt động sẽ là: delayFlight(numberOfMinutes : Minutes) : Date.

² Có vẻ lạ là lớp BankAccount không biết về lớp OverdrawnAccountsReport. Cách mô hình hóa này cho phép lớp báo cáo biết về lớp nghiệp vụ mà nó báo cáo, nhưng lớp nghiệp vụ không biết là chúng đang được báo cáo. Điều này nới lỏng việc ghép nối đối tượng và do đó làm cho hệ thống dễ thích nghi hơn với những thay đổi.

³ Các gói là điều tuyệt vời để tổ chức các lớp của mô hình của bạn, nhưng điều quan trọng cần nhớ là các sơ đồ của lớp có nhiệm vụ phải tạo điều kiện dễ dàng trao đổi thông tin về hệ thống đang được mô hình hóa. Trong trường hợp mà các gói của bạn có rất nhiều lớp, thì tốt hơn là sử dụng nhiều sơ đồ lớp với các chủ đề cụ thể thay vì chỉ tạo ra một sơ đồ lớp rất lớn.

⁴ Điều quan trọng là phải hiểu khi tôi nói "tất cả các thành viên ấy," tôi muốn nói đến chỉ các lớp mà sơ đồ hiện tại sẽ hiển thị. Một sơ đồ hiển thị một gói với nội dung không nhất thiết hiển thị tất cả nội dung của nó, nó có thể hiển thị một tập hợp con của các phần tử chứa trong đó theo một tiêu chí nào đó, mà không nhất thiết phải là tất cả các phân loại của gói.

⁵ Khi vẽ một sơ đồ lớp, thì việc đặt thêm ký hiệu «class» (lớp) trong ngăn trên cùng của hình chữ nhật, như bạn đã làm với «interface» (giao diện) là hoàn toàn nằm trong khuôn khổ của đặc tả kỹ thuật UML. Tuy nhiên, đặc tả UML nói rằng việc đặt ký hiệu "class" trong ngăn này là tùy chọn, và nên giả định rằng «class» không được viết rõ ra.

Tài nguyên

Cơ sở của UML: Phần I: Giới thiệu về Ngôn ngữ mô hình hóa thống nhất

Cơ sở của UML: Phần II: Sơ đồ hoạt động

Cơ sở của UML: Phần III: Sơ đồ lớp

Sơ đồ tuần tự của UML

Đôi nét về tác giả