Class Diagram là một static diagram, đại diện cho chế độ static view của một ứng dụng. Class diagram không chỉ được sử dụng để trực quan hóa, mô tả và ghi lại các khía cạnh khác nhau của hệ thống mà còn để xây dựng mã thực thi của ứng dụng phần mềm.
Class Diagram mô tả các attribute và operation của một class cũng như các contraint áp đặt lên hệ thống. Class Diagram được sử dụng rộng rãi trong việc mô hình hóa các hệ thống hướng đối tượng vì chúng là các sơ đồ UML, có thể được ánh xạ trực tiếp bằng các ngôn ngữ hướng đối tượng.
Class Diagram hiển thị một tập hợp các class, interface, liên kết, association và ràng buộc. Class Diagram còn được gọi là sơ đồ cấu trúc.
Mục đích của Class Diagram có thể được tóm tắt:
- Phân tích và thiết kế chế độ xem tĩnh của một ứng dụng.
- Mô tả trách nhiệm của một hệ thống.
- Cơ sở cho các sơ đồ thành phần và triển khai.
- Forward và reverse engineering. Forward engineering là một phương pháp mà chúng ta có thể tạo một ứng dụng theo các yêu cầu nhất định. Reverse engineering có thể trích xuất thông tin thiết kế từ mã nguồn, nhưng mức độ trừu tượng
Class là gì?
Class là bản thiết kế (blueprint) cho object. Object và class đi đôi với nhau. Chúng ta không thể nói về cái này mà không nói về cái kia. Và toàn bộ quan điểm của Thiết kế hướng đối tượng không phải là về các object, mà là về các class, bởi vì chúng ta sử dụng các class để tạo các đối tượng.
Vì vậy, một class mô tả object sẽ là gì, nhưng bản thân nó không phải là object.
Trên thực tế, class mô tả loại object, trong khi các object là các thể hiện có thể sử dụng được của các class. Mỗi object được xây dựng từ cùng một bản thiết kế (blueprint) và do đó chứa các thành phần giống nhau (properties và methods). Ý nghĩa tiêu chuẩn là một object là một thể hiện của một class và object - Các object có state và behavior
Ví dụ: Một con chó có các trạng thái - màu sắc, tên, giống cũng như các hành vi - vẫy, sủa, ăn. Một đối tượng là một thể hiện của một lớp.
Ký hiệu UML Class
Một class là một khái niệm bao hàm trạng thái (attribute) và hành vi (operation). Mỗi attribute đều có kiểu dữ liệu. Mỗi operation đều có method signature (return type, parameter type, số lượng parameter, thứ tự parameter)
Ở hình trên, một class được chia ra thành 3 phần:
- Class name
- Attribute
- Operation
Class visibility
Các ký hiệu +, - và # trước tên attribute và operation trong một class biểu thị phạm vi truy cập của attribute và operation.
- Private ( - ): Chỉ mình các đối tượng được tạo từ class này có thể sử dụng.
- Public ( + ): Mọi đối tượng đều có thể sử dụng.
- Protected ( # ): Chỉ các đối tượng được tạo từ class này và class kế thừa từ class này có thể sử dụng.
Xác định hướng truy cập tham số
Mỗi tham số trong một operation (phương thức) có thể được ký hiệu là in, out hoặc inout xác định hướng của nó đối với người gọi. Hướng này được hiển thị trước tên tham số.
Thông thường trong lập trình thì ký hiệu inout được loại bỏ và ngầm hiểu dựa trên Reference Type và Value Type
Quan điểm của sơ đồ lớp (Perspectives of Class Diagram)
Ví dụ, trong quá trình xây dựng một domain model, bạn sẽ hiếm khi vượt qua quan điểm khái niệm (conceptual perspective). Các mô hình phân tích thường sẽ có sự kết hợp giữa các quan điểm khái niệm và đặc điểm kỹ thuật (specification perspectives). Việc phát triển mô hình thiết kế thường sẽ bắt đầu với sự nhấn mạnh vào quan điểm đặc tả và phát triển thành quan điểm triển khai.
Một sơ đồ có thể được giải thích từ nhiều quan điểm khác nhau:
- Khái niệm (Conceptual): đại diện cho các khái niệm trong domain
- Đặc tả (Specification): tập trung vào giao diện của Abstract Data Type (ADT) trong phần mềm
- Thực hiện (Implementation): mô tả cách các class sẽ thực hiện các giao diện của chúng
Quan hệ giữa các class
Nếu bạn chưa thể nhận ra chúng, không vấn đề gì, phần này nhằm giúp bạn hiểu các mối quan hệ của lớp UML. Một lớp có thể tham gia vào một hoặc nhiều mối quan hệ với các lớp khác. Một mối quan hệ có thể là một trong các loại sau:
Association
Sự liên kết giữa 2 lớp khi mà không ai sở hữu ai.
The lifetime of the instances of the two classes are independent of each other and there is no ownership between two classes.
Associations là mối quan hệ giữa các class trong Sơ đồ class UML. Chúng được thể hiện bằng một đường liền nét giữa các class. Associations thường được đặt tên bằng cách sử dụng một động từ hoặc cụm động từ phản ánh miền vấn đề trong thế giới thực
Problem domain: đây là khái niệm chỉ miền vấn đề. Một miền vấn đề là lĩnh vực chuyên môn hoặc ứng dụng cần được kiểm tra để giải quyết vấn đề. Tập trung vào một miền vấn đề chỉ đơn giản là chi xem xét các chủ đề mà một cá nhân quan tâm và loại trừ mọi thứ khác
class Child {}
class Mother {
List<Child> children;
}- one to one
- one to many
- many to many
Quay lại ví dụ trên, chúng ta có:
Xử lý các liên hệ không cần thiết:
Cần chú ý phân biệt giữa hành động và mối liên hệ. Người ta thường có xu hướng miêu tả hành động như là liên hệ, bởi cả liên hệ lẫn hành động đều được dẫn xuất từ những cụm từ mang tính động từ trong bản miêu tả yêu cầu. Các hành động đã được thể hiện sai thành liên hệ cũng cần phải được loại bỏ. Khi làm việc này, có thể áp dụng một nguyên tắc: liên hệ là nối kết mang tính tĩnh giữa các đối tượng, trong khi hành động chỉ là thao tác xảy ra một lần. Hành động vì vậy nên được coi là Phương thức đối với một đối tượng chứ không phải quan hệ giữa các lớp.
Ví dụ với "Ban quản trị nhà băng đuổi việc một nhân viên", động từ “đuổi việc” thể hiện hành động. Trong khi đó với “Một nhân viên làm việc cho hãng" thì động từ “làm việc" miêu tả liên hệ giữa hai lớp nhân viên và hãng.
Trong khi cố gắng loại bỏ các liên hệ dư thừa, bạn sẽ thấy có một số liên hệ dư thừa đã "lẻn vào" mô hình của chúng ta trong giai đoạn thiết kế.
Quan hệ Inheritance (tên khác là Generalization)
Còn có tên khác là:
- Quan hệ tổng quát hóa
- Quan hệ khái quát hóa
- Quan hệ kế thừa
Khái quát hóa (Generalization) là mối quan hệ phân loại giữa một bộ phân tổng quát hơn và một bộ phân loại cụ thể hơn. Mỗi thể hiện của bộ phân loại cụ thể cũng là một thể hiện gián tiếp của bộ phân loại chung. Do đó, bộ phân loại cụ thể kế thừa các tính năng của bộ phân loại tổng quát hơn.
Hiểu đơn giản hơn là mối quan hệ giữa lớp cơ sở (base class) được đặt tên là “lớp cha” (superclass) hoặc “cha mẹ” (parent) và lớp cụ thể được đặt tên là “lớp con” (subclass) hoặc “lớp con” (child).
Đối tượng cụ thể (concrete) sẽ kế thừa các thuộc tính và phương thức của đối tượng tổng quát (general)
Ký hiệu: A is-a B
Đọc là:
- A là tổng quát của B, B là chi tiết của A
- B là trường hợp đặc biệt của A
- A là cha của B, B là con của A
Aggregation (thu nạp)
- Class1 và Class2 có quan hệ Association với nhau
- Class 2 là 1 phần của Class 1
- Nhiều instance (ký hiệu là * ) của class 2 có thể được liên kết với class 1
- Đối tượng Class 1 và Class 2 tồn tại độc lập. Nghĩa là đối tượng 1 bị hủy thì đối tượng 2 vẫn tồn tại.
Hình bên dưới cho ví dụ về aggregation. Mối quan hệ được hiển thị dưới dạng một đường liền nét với hình thoi không được lấp đầy ở đầu association, được kết nối với class, đại diện cho aggregation.
Ví dụ: Giả sử có một chiếc xe hơi và bánh xe của nó. Chúng ta có thể tháo bánh xe ra và chúng vẫn tồn tại. Chúng ta có thể lắp các bánh xe khác (có sẵn) hoặc lắp chúng vào một chiếc xe khác và mọi thứ vẫn sẽ hoạt động tốt. Tất nhiên, một chiếc xe hơi không bánh hoặc bánh xe rời sẽ không hữu dụng bằng ô tô có bánh. Nhưng đó là lý do tại sao mối quan hệ này tồn tại ngay từ đầu: lắp ráp các bộ phận thành một vật lớn hơn, có khả năng làm được nhiều thứ hơn các bộ phận của nó.
class Wheel {}
class Car {
List<Wheel> wheels;
}Composition (hợp thành)
Là một loại quan hệ đặc biệt của Aggregation
The objects' lifecycles are tied. It means that if we destroy the owner object, its members also will be destroyed with it
- ClassA và ClassB có quan hệ Association với nhau
- Còn gọi là Whole A – Part B. Nghĩa là A được tạo từ nhiều B kết hợp lại , nhưng B không thể đứng 1 mình được , B chỉ là thuộc A mà thôi không thể cùng thuộc Whole khác được.
- Object của Class A có chứa object của ClassB. Nếu A bị hủy thì B sẽ không tồn tại. ngược lại, B bị hủy thì se không ảnh hưởng đến A
class Building {
class Room {}
}Dependency
Một đối tượng của một classA có thể sử dụng một đối tượng của một classB khác trong một phương thức của classA. Nếu đối tượng (classA) không được lưu trữ trong bất kỳ trường nào (của classB), thì điều này được mô hình hóa như một mối quan hệ phụ thuộc. Ta nói classA phụ thuộc vào classB.
- Trong ClassA có sử dụng biến toàn cục (kiểu B), hoặc sử dụng phương thức/thuộc tính static của ClassB
- Ký hiệu: A use-a B, bằng mũi tên 1 chiều nét đứt, từ bên phụ thuộc sang bên độc lập
- ClassA “phụ thuộc” vào ClassB
- Client –> Supplier (phần tử phục thuộc –> phần tử độc lập)
Dependency còn có một số biểu hiện khác , thường dùng các stereotype sau:
- <use>> : chỉ rằng ngữ nghĩa của lớp gốc (mũi tên) phụ thuộc vào lớp ngọn (mũi tên) . Đặc biệt trong trường hợp lớp gốc dùng lớp ngọn làm tham số trong 1 số method của nó
- <<permit>> : chỉ rằng lớp gốc được quyền truy cập 1 cách đặc biệt vào lớp ngọn (chẳng hạn truy cập các thao tác riêng tư). Tương ứng với khái niệm friend trong C++
- <<refine>> : chỉ rằng lớp gốc ở 1 mức độ tinh chế cao hơn từ lớp ngọn . Chẳng hạn 1 lớp lập ở giai đoạn thiết kế nhằn tinh chế cùng lớp đó lập ở giai đoạn phân tích
- Association là quan hệ cấu trúc
- Dependency là qua hệ phi cấu trúc
QUAN HỆ REALIZATION (HIỆN THỰC HÓA):
Là quan hệ giữa một classifier đóng vai trò là hợp đồng và một classifier đóng vai trò thực hiện. Hay nói cách khác:
Mối quan hệ giữa 1 class implement 1 interface được gọi là quan hệ realization, được biểu diễn bởi đường đứt nét có hình mũi tên tam giác chỉ vào interface.
https://devhints.io/plantuml
Trả lờiXóa