Chuyển đến nội dung chính

UML: Class diagram

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)

Việc lựa chọn quan điểm phụ thuộc vào việc bạn tiến xa đến đâu trong quá trình phát triển.

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 điểm ảnh hưởng đến số lượng chi tiết được cung cấp và các loại mối quan hệ đáng để trình bày. Như chúng tôi đã đề cập ở trên, class name là thông tin bắt buộc duy nhất.


Quan hệ giữa các class

UML không chỉ là những hình ảnh đẹp. Nếu được sử dụng đúng cách, UML sẽ truyền đạt chính xác triển khai code từ sơ đồ. Nếu được giải thích chính xác, code được triển khai sẽ phản ánh chính xác ý định của designer. Bạn có thể mô tả ý nghĩa của từng mối quan hệ so với ngôn ngữ lập trình mục tiêu của bạn được hiển thị trong Hình bên dưới không?

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

Ví dụ: Người mẹ và đứa con trong UML
class Child {}

class Mother {
    List<Child> children;
}
Số lượng (Cardinality) trong Association
  • 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: 

Sau khi tìm các mối liên hệ, bước tiếp theo đó là phân biệc các liên hệ cần thiết ra khỏi các liên hệ không cần thiết. Liên hệ không cần thiết có thể bao gồm những liên hệ bao chứa các lớp ứng cử viên đã bị loại trừ hoặc các liên hệ không liên quan đến hệ thống. Có những liên hệ được tạo ra nhằm mục đích tăng hiệu quả. Những liên hệ như thế là ví dụ tiêu tiểu của các chi tiết thực thi và không liên quan tới giai đoạn này. 

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


VD:

Aggregation (thu nạp)

Là một loại đặc biệt của association
  • 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.
Aggregation còn được gọi là mối quan hệ “Has-a”.

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
Ví dụ: Một tòa nhà có nhiều phòng
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
Lưu ý : Phân biệt giữa Dependency và Association
  • 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.

Ký hiệu: có 2 loại ký hiệu
hoặc

Tham khảo

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

[ASP.NET MVC] Authentication và Authorize

Một trong những vấn đề bảo mật cơ bản nhất là đảm bảo những người dùng hợp lệ truy cập vào hệ thống. ASP.NET đưa ra 2 khái niệm: Authentication và Authorize Authentication xác nhận bạn là ai. Ví dụ: Bạn có thể đăng nhập vào hệ thống bằng username và password hoặc bằng ssh. Authorization xác nhận những gì bạn có thể làm. Ví dụ: Bạn được phép truy cập vào website, đăng thông tin lên diễn đàn nhưng bạn không được phép truy cập vào trang mod và admin.

ASP.NET MVC: Cơ bản về Validation

Validation (chứng thực) là một tính năng quan trọng trong ASP.NET MVC và được phát triển trong một thời gian dài. Validation vắng mặt trong phiên bản đầu tiên của asp.net mvc và thật khó để tích hợp 1 framework validation của một bên thứ 3 vì không có khả năng mở rộng. ASP.NET MVC2 đã hỗ trợ framework validation do Microsoft phát triển, tên là Data Annotations. Và trong phiên bản 3, framework validation đã hỗ trợ tốt hơn việc xác thực phía máy khách, và đây là một xu hướng của việc phát triển ứng dụng web ngày nay.

Tổng hợp một số kiến thức lập trình về Amibroker

Giới thiệu về Amibroker Amibroker theo developer Tomasz Janeczko được xây dựng dựa trên ngôn ngữ C. Vì vậy bộ code Amibroker Formula Language sử dụng có syntax khá tương đồng với C, ví dụ như câu lệnh #include để import hay cách gói các object, hàm trong các block {} và kết thúc câu lệnh bằng dấu “;”. AFL trong Amibroker là ngôn ngữ xử lý mảng (an array processing language). Nó hoạt động dựa trên các mảng (các dòng/vector) số liệu, khá giống với cách hoạt động của spreadsheet trên excel.