Class Diagram là một trong những bản vẽ quan trọng nhất của thiết kế phần mềm, nó cho thấy cấu trúc và quan hệ giữa các thành phần tạo nên phần mềm. Trong quá trình xây dựng Class Diagram chúng ta sẽ phải quyết định rất nhiều yếu tố về thiết kế nên nó là bản vẽ khó xây dựng nhất. Bản vẽ này sẽ cho thấy cấu trúc tĩnh của phần mềm, tương tự như bản vẽ mặt bằng trong thiết kế của ngành xây dựng.

Trong bài này, chúng ta sẽ tìm hiểu các thành phần tạo nên bản vẽ, cách xây dựng và sử dụng class diagram để giúp các bạn hiểu và áp dụng bản vẽ này trong thiết kế. Ở đây, mặc định các bạn đã có kiến thức về lập trình hướng đối tượng và không nhắc lại các khái niệm trong lập trình hướng đối tượng.

1. Các thành phần trong bản vẽ Class

Trước tiên, chúng ta xem một bản vẽ Class.

Hình 1. Ví dụ về Class Diagram của ATM

Ví dụ trên là Class Diagram của ứng dụng ATM. Tiếp theo chúng ta sẽ bàn kỹ về các thành phần của bản vẽ này và lấy ứng dụng về ATM ở trên để minh họa.

Classes (Các lớp)

Class là thành phần chính của bản vẽ Class Diagram. Class mô tả về một nhóm đối tượng có cùng tính chất, hành động trong hệ thống. Ví dụ mô tả về khách hàng chúng ta dùng lớp “Customer”. Class được mô tả gồm  tên Class, thuộc tính và phương thức.

 

Hình 2. Ký hiệu về Class

Trong đó,

–          Class Name: là tên của lớp.

–          Attributes (thuộc tính): mô tả tính chất của các đối tượng. Ví dụ như khách hàng có Mã khách hàng, Tên khách hàng, Địa chỉ, Ngày sinh v.v…

–          Method (Phương thức): chỉ các hành động mà đối tượng này có thể thực hiện trong hệ thống. Nó thể hiện hành vi của các đối tượng do lớp này tạo ra.

 

 

 

 

 

 

Hình 3. Ví dụ về một Class

Một số loại Class đặc biệt như Abstract Class (lớp không tạo ra đối tượng), Interface (lớp khai báo mà không cài đặt) v.v.. chúng ta xem thêm các tài liệu về lập trình hướng đối tượng để hiểu rõ hơn các vấn đề này.

2. Relationship (Quan hệ)

Relationship thể hiện mối quan hệ giữa các Class với nhau. Trong UML 2.0 có các quan hệ thường sử dụng như sau:

–          Association

–          Aggregation

–          Composition

–          Generalization

Chúng ta sẽ lần lượt tìm hiểu về chúng.

+ Association

Association là quan hệ giữa hai lớp với nhau, thể hiện chúng có liên quan với nhau. Association thể hiện qua các quan hệ như “has: có”, “Own: sở hữu” v.v…

 

 

Hình 4. Ví dụ về Association

Ví dụ quan hệ trên thể hiện Khách hàng nắm giữ Tài khoản và Tài khoản được sở hữu bởi Khách hàng.

+ Aggregation

Aggregation là một loại của quan hệ Association nhưng mạnh hơn. Nó có thể cùng thời gian sống (cùng sinh ra hoặc cùng chết đi)

Hình 5. Ví dụ về Aggregation

Ví dụ quan hệ trên thể hiện lớp Window(cửa sổ) được lắp trên Khung cửa hình chữ nhật. Nó có thể cùng sinh ra cùng lúc.

+ Composition

Composition là một loại mạnh hơn của Aggregation thể hiện quan hệ class này là một phần của class kia nên dẫn đến cùng tạo ra hoặc cùng chết đi.

 

Hình 5. Ví dụ về Composition

Ví dụ trên class Mailing Address là một phần của class Customer nên chỉ khi nào có đối tượng Customer thì mới phát sinh đối tượng Mailing Address.

+Generalization

Generalization là quan hệ thừa kế được sử dụng rộng rãi trong lập trình hướng đối tượng.

Hình 6. Ví dụ về Genelization

Các lớp ở cuối cùng như Short Term, Long Term, Curent a/c, Savings a/c gọi là các lớp cụ thể (concrete Class). Chúng có thể tạo ra đối tượng và các đối tượng này thừa kế toàn bộ các thuộc tính, phương thức của các lớp trên.

Các lớp trên như Account, Term Based, Transaction Based là những lớp trừu tượng (Abstract Class), những lớp này không tạo ra đối tượng.

Ngoài ra, còn một số quan hệ như khác như dependence, realization nhưng ít được sử dụng nên chúng ta  không bàn ở đây.

3. Cách xây dựng bản vẽ Class

Class Diagram là bản vẽ khó xây dựng nhất so với các bản vẽ khác trong OOAD và UML. Bạn phải hiểu được hệ thống một cách rõ ràng và có kinh nghiệm về lập trình hướng đối tượng mới có thể xây dựng thành công bản vẽ này.

Thực hiện theo các bước sau đây để xây dựng Class Diagram.

Bước 1: Tìm các Classes dự kiến

Entity Classes(các lớp thực thể) là các thực thể có thật và hoạt động trong hệ thống, bạn dựa vào các nguồn sau để xác định chúng.

Hình 7. Các nguồn thông tin có thể tìm Class dự kiến

–          Requirement statement:  Các yêu cầu. Chúng ta phân tích các danh từ trong các yêu cầu để tìm ra các thực thể.

–          Use Cases: Phân tích các Use Case sẽ cung cấp thêm các Classes dự kiến.

–          Previous và Similar System:  có thể sẽ cung cấp thêm cho bạn các lớp dự kiến.

–          Application Experts: các chuyên gia ứng dụng cũng có thể giúp bạn.

Xem xét,  ví dụ ATM ở trên chúng ta có thể thấy các đối tượng là Entity Class như sau:

–          Customers: khách hàng giao dịch là một thực thể có thật và quản lý trong hệ thống.

–          Accounts:  Tài khoản của khách hàng cũng là một đối tượng thực tế.

–          ATM Cards: Thẻ dùng để truy cập ATM cũng được quản lý trong hệ thống.

–          ATM Transactions: Các giao dịch được lưu giữ lại, nó cũng là một đối tượng có thật.

–          Banks: Thông tin ngân hàng bạn đang giao dịch, nếu có nhiều nhà Bank tham gia vào hệ thống bạn phải quản lý nó. Lúc đó Bank trở thành đối tượng bạn phải quản lý.

–          ATM: Thông tin ATM bạn sẽ giao dịch. Nó cũng được quản lý tương tự như Banks.

Lưu ý: Chỉ các thực thể bên trong hệ thống được xem xét, các thực thế bên ngoài hệ thống không được xem xét. Ví dụ Customers là những người khách hàng được quản lý trong hệ thống chứ không phải người dùng máy ATM bên ngoài. Bạn phải lưu ý điều này để phân biệt Class và Actor.

Bước 2: Tìm các thuộc tính và phương thức cho lớp

–          Tìm thuộc tính: phân tích thông tin từ các form mẫu có sẵn, bạn sẽ tìm ra thuộc tính cho các đối tượng của lớp. Ví dụ các thuộc tính của lớp Customer sẽ thể hiện trên Form đăng ký thông tin khách hàng.

–          Tìm phương thức: phương thức là các hoạt động mà các đối tượng của lớp này có thể thực hiện. Chúng ta sẽ bổ sung phương thức đầy đủ cho các lớp khi phân tích Sequence Diagram sau này.

Bước 3: Xây dựng các quan hệ giữa các lớp và phát hiện các lớp phát sinh

–          Phân tích các quan hệ giữa các lớp và định nghĩa các lớp phát sinh do các quan hệ sinh ra. Chúng ta phân tích các thực thể ở trên và nhận thấy.

• Lớp Accounts có thể chia thành nhiều loại tài khoản như Current Accounts và Saving Accounts và có quan hệ thừa kế với nhau.
• Lớp ATM Transactions cũng có thể chia thành nhiều loại giao dịch như Deposit, Withdraw, Transfer v.v.. và chúng cũng có quan hệ thừa kế với nhau.

–          Tách chúng ta và vẽ chúng lên bản vẽ chúng ta sẽ có Class Diagram cho hệ thống ATM như sau:

Hình 8. Ví dụ về Class Diagram cho hệ thống ATM

4. Đặc tả Class

Nhìn vào Class Diagram chúng ta có thể thấy cấu trúc của hệ thống gồm những lớp nào nhưng để cài đặt chúng, chúng ta phải đặc tả chi tiết hơn nữa. Trong đó, cần mô tả:

–          Các thuộc tính: Tên, kiểu dữ liệu, kích thước

–          Các phương thức:

+ Tên

+ Mô tả

+ Tham số đầu vào: Tên, kiểu dữ liệu, kích thươcs

+ Kết quả đầu ra: Tên, kiểu dữ liệu, kích thước

+ Luồng xử lý

+ Điều kiện bắt đầu

+ Điều kiện kết thúc

Tuy nhiên, việc này cũng mất khá nhiều thời gian. Nếu phát triển theo mô hình Agile thì bạn không phải làm việc này mà các thành viên phát triển phải nắm điều này để cài đặt.

5. Sử dụng bản vẽ Class

Có thể tóm tắt một số ứng dụng của bản vẽ Class Diagram như sau:

–          Hiểu cấu trúc của hệ thống

–          Thiết kế hệ thống

–          Sử dụng để phân tích chi tiết các chức năng (Sequence Diagram, State Diagram v.v…)

–          Sử dụng để cài đặt (coding)

6. Kết luận

Như vậy, chúng ta đã tìm hiểu xong về Class Diagram, các bạn cần thực hành nhiều để hiểu về bản vẽ quan trọng này.

Để giúp các bạn nắm rõ hơn về Class Diagram, trong bài tiếp theo chúng ta sẽ thực hành xây dựng Class Diagram cho hệ thống eCommerce đã mô tả trong Case Study ở bài 3.

Bài tiếp:  Thực hành xây dựng Class Diagram

Bài trước:  Thực hành xây dựng bản vẽ Use Case