UML - Bản vẽ thi công dành cho kỹ sư lập trình

Ntech_Developers · June 26, 2021, 7:08am

Bài viết trước mình có đề cập đến một trong kỹ năng thể hiện thiết kế kiến trúc phần mềm cho anh em thi công. Bạn đọc có thể xem lại tại đây

Có thể thấy bản vẽ được vẽ nên được tạo ra để cho người nhận nhiệm vụ thi công xây dựng nên có thể đọc được và hiểu được. Cũng như bản vẽ xây dựng thì trong thiết kế phần mềm cũng có loại bản vẽ mà để mọi người có thể cùng chung một ý hiểu đó chính là UML (Unified Modeling Language). Và để ai cũng hiểu được bản vẽ này cần có những quy ước chung nhằm người tạo ra nó (SA, TA, TL) và những anh em thi công xây dựng (SE, Dev) thống nhất với nhau và có thể lưu lại làm tài liệu chuyển giao giữa các đội thiết kế trước và sau. Bài viết dưới đây sẽ nói rõ hơn về những quy tắc chung đó mà bạn cần biết khi bước chân vào công cuộc thiết kế phần mềm.

Để nắm được tổng quan về UML thì bạn cần lưu ý những điểm như sau :

UML là một ngôn ngữ mô hình gồm các ký hiệu đồ họa mà các phương pháp hướng đối tượng sử dụng để thiết kế các hệ thống thông tin một cách nhanh chóng
UML phù hợp mô tả các hệ thống thông tin cả về cấu trúc cũng như hoạt động
UML phục vụ từ giai đoạn phân tích đến việc thiết kế, thẩm định và kiểm tra sản phẩm ứng dụng công nghệ thông tin
UML không phụ thuộc vào bất cứ ngôn ngữ lập trình nào, nó đơn giản chỉ là mô hình hoá những cấu trúc thành phần để giúp cho việc thi công xây dựng, còn xây dựng và thi công bằng ngôn ngữ nào và cách thức cụ thể ra sao UML chỉ khái quát và trừu tượng hoá mà thôi

Ok , giờ thì cùng mình điểm qua những mốc lịch sử quan trọng phát triển nên các phiên bản UML nhé.

Trong khoảng những năm 1989 đến 1994, số lượng các phương pháp luận hướng đối tượng gia tăng từ dưới 10 đến 50 do đó nảy sinh vấn đề là làm cho người phát triển khó tìm thấy một phương pháp luận duy nhất thoả mãn đầy đủ nhu cầu của họ.
Vào tháng mười năm 1994, Rumbaugh đã liên kết với công ty Booch (Rational Sofware Corporation) để kết hợp phương pháp Booch và phương pháp OMT. Và cho ra một bản phác thảo về phương pháp có tên là Unified Process vào tháng mười năm 1995.
Năm 1995, Jacobson đã nỗ lực tích hợp phương pháp này với OOSE. Và những tài liệu đầu tiên về UML đã được trình làng vào trong năm 1996.
Phiên bản 1.0 của UML đã được công bố vào tháng 1 năm 1997
UML phiên bản 1.5 đã được tạo vào tháng ba năm 2003.
Phiên bản UML 2.0 được tạo vào 2004.

….

Và phiên bản hiện tại là 2.5.1 được công bố vào tháng 12 năm 2017.

Bạn thấy đó, để có được một quy ước chung thống nhất giữa các lập trình viên với nhau phải trải qua cả một quá trình dài và phát triển, mình nghĩ nó vẫn đang tiếp tục tiến hoá lên không chỉ dừng lại ở UML 2.5 đâu. Và lâu lâu thì các anh em dev thế hệ trước và sau có dùng nhầm lẫn một hai ký hiệu do quá trình phát triển thì mọi người nên châm chước nhé, miễn sao có thể hiểu nhau và thi công xây dựng đúng như mong đợi là được rồi.

Bài viết này mình sẽ tập trung vào phiên bản 2.0 mà mình vẫn hay dùng, nó sẽ là khái niệm cơ bản để bạn có thể tiếp tục tìm hiểu sâu hơn về sau này. Còn giờ với những cái cơ bản sau đây bạn có thể đọc được đa số các bản vẽ nhé.

Có các loại sơ đồ UML chủ yếu sau:

Sơ đồ lớp (Class Diagram)
Sơ đồ đối tượng (Object Diagram)
Sơ đồ tình huống sử dụng (Use Cases Diagram)
Sơ đồ trình tự (Sequence Diagram)
Sơ đồ cộng tác (Collaboration Diagram hay là Composite Structure Diagram)
Sơ đồ trạng thái (State Machine Diagram)
Sơ đồ thành phần (Component Diagram)
Sơ đồ hoạt động (Activity Diagram)
Sơ đồ triển khai (Deployment Diagram)
Sơ đồ gói (Package Diagram)
Sơ đồ liên lạc (Communication Diagram)
Sơ đồ tương tác (Interaction Overview Diagram - UML 2.0)
Sơ đồ phối hợp thời gian (Timing Diagram - UML 2.0)

Gần đây với sự phát triển của Microservice và Cloud thì có thêm Cloud Diagram nữa. Các loại sơ đồ trên thì sẽ chia thành 2 nhóm chính đó là nhóm cấu trúc và nhóm hành vi (định nghĩa thì đúng như cái tên của nó thôi).

UML được thể hiện với ba yếu tố chính sau:

Khối xây dựng UML
Các quy tắc để kết nối các khối xây dựng đó
Các cơ chế chung của UML

UML gắn liền với hướng đối tượng

Để thể hiện được các khối xây dựng bên trên thì cần hiểu được về đối tượng và sự trừu tượng hoá.

Ví dụ bạn cần vẽ một tạo nên một con mèo thì trên bản vẽ bạn cần đối tượng hoá nó thể hiện qua các lớp, đối tượng, thuộc tính, phương thức. Tất cả những thứ đó đều gắn liền với hướng đối tượng. Vậy nên UML có thể được mô tả như là sự kế thừa của việc phân tích và thiết kế hướng đối tượng (OO).

Mà hướng đối tượng thì sẽ có một số khái niệm cơ bản của thế giới hướng đối tượng

Đối tượng - Đối tượng đại diện cho một thực thể và khối xây dựng cơ bản.
Lớp - Class là bản in của một đối tượng.
Trừ tượng – Trừu tượng đại diện cho hành vi của một thực thể thế giới thực.
Đóng gói - Tóm lược là cơ chế ràng buộc dữ liệu với nhau và giấu chúng khỏi thế giới bên ngoài.
Thừa kế - Thừa kế là cơ chế tạo ra các lớp mới từ những lớp hiện có.
Đa hình - Nó xác định cơ chế tồn tại dưới các hình thức khác nhau.

Để vẽ được UML thì chúng ta cần phải phân tích đối tượng với các bước tổng quát như sau:

OO Analysis → OO Design → OO implementation using OO languages

Xác định các đối tượng của một hệ thống.
Xác định mối quan hệ của họ.
Làm một thiết kế, có thể được chuyển đổi sang các file thực thi sử dụng các ngôn ngữ OO.

Được rồi giờ thì mình có thể bắt đầu với các ký hiệu giúp bạn hiểu bản vẽ trước đã, còn để thiết kế ra nó thì có thể mình sẽ hẹn vào bài viết kế tiếp vì nó liên quan đến việc bạn phân tích đối tượng như mình đề cập ở trên.

Bắt đầu từ các đối tượng thành phần trước nhé.

Class - Class đại diện cho một tập hợp các đối tượng có trách nhiệm tương tự.

Class gồm 4 thành phần

Phần trên cùng được sử dụng để đặt tên cho lớp.
Phần thứ hai được sử dụng để hiển thị các thuộc tính của lớp.
Phần thứ ba được sử dụng để mô tả các hoạt động được thực hiện bởi lớp.
Phần thứ tư là tùy chọn để hiển thị bất kỳ thành phần bổ sung.

Nhớ chú ý các ký hiệu +/-/#, kiểu dữ liệu (datatype), methods (Operations) để thi công cho chính xác nhé. Thường chỉ khi nào vẽ bản vẽ chi tiết thì người vẽ với liệt kê hết đầy đủ, còn không thì chỉ vẽ tên class tượng trưng thôi.

Giao diện - Interface xác định một tập hợp các hoạt động, trong đó xác định trách nhiệm của một lớp.

Trường hợp sử dụng - Use case sử dụng đại diện cho một tập hợp các hành động được thực hiện bởi một hệ thống cho một mục đích cụ thể. Nó có thể chứa những trách nhiệm bổ sung và được sử dụng để nắm bắt chức năng cấp cao của một hệ thống.

Đối tượng thực thể - Actor có thể được định nghĩa là một số thực thể bên trong hoặc bên ngoài có tương tác với hệ thống. Nó được sử dụng trong một sơ đồ trường hợp sử dụng để mô tả các thực thể bên trong hoặc bên ngoài.

Trạng thái - State bao gồm trạng thái bắt đầu và kết thúc biểu thị cho một quá trình nào đó

Thành phần - Component mô tả phần vật lý của một hệ thống. Các yếu tố bổ sung có thể được thêm vào bất cứ nơi nào yêu cầu.

Nút - Node có thể được định nghĩa như một phần tử vật lý tồn tại trong thời gian chạy.

Hợp tác - Collaboration được xác định sự tương tác giữa các yếu tố và thể hiện trách nhiệm. Nói chung, trách nhiệm là trong một nhóm.

Gói - Package là nhóm chỉ có một nhóm để thu thập các vấn đề cấu trúc và hành vi.

Về cơ bản sẽ có những đối tượng thành phần như vậy, tuy nhiên còn tuỳ vào loại sơ đồ nào mà có những ký hiệu đặc thù riêng cho loại sơ đồ đó. Như Object, container, cloud…

Tiếp theo là ký hiệu liên kết, cái này quan trọng mà rất hay nhầm lẫn

Association là sự liên kết giữa 2 class khi mà không cái nào sở hữu cái nào. Vòng đời các thể hiện của 2 class thì độc lập nhau và không có mối quan hệ sở hữu nào trong biểu diễn này. Ký hiệu này đôi khi còn có mũi tên chỉ chiều liên kết nữa.
Inheritance (or Generalization). Đúng với cái tên thì nó biểu hiện cho sự kế thừa, class A mà kế thừa class B muốn sử dụng override hay mở rộng thuộc tính thì dùng liên kết này.
Realization là một mối quan hệ giữa lớp kế hoạch chi tiết và đối tượng chứa các chi tiết mức độ thực hiện tương ứng của nó. Đối tượng này được cho là nhận ra lớp kế hoạch chi tiết. Với liên kết này thì sẽ dùng cho interface và class, vì đơn giản interface chỉ là cái vỏ khai báo các thuộc tính và phương thức thôi, nó phải cần một class thực hiện hoá xử lý những thuộc tính và phương thức đó.
Dependency. Cái này hay nhầm lẫn với Association mà có mũi tên. Nó được sử dụng để biểu diễn sự phụ thuộc giữa hai yếu tố của một hệ thống. Đầu mũi tên tượng trưng cho phần tử độc lập và đầu kia đại diện cho phần tử phụ thuộc. Thật chú ý khi đánh giá 2 class A và B phụ thuộc nhau với 2 class A và B liên kết với nhau. Sự liên kết (Association) có thể thể hiện tính đa hình trong hướng đối tượng nhưng sự phụ thuộc thì không, nó chỉ đơn giản là thể hiện rằng trong bạn có tôi, tôi sống nhờ đồng lương của bạn😄
Aggregation đây là quan hệ thu nạp hay chia sẻ tài nguyên. Class A được tạo từ một hoặc nhiều Class B kết hợp lại và class B thì hoàn toàn độc lập mà không cần phải tạo class A. Chính vì class B độc lập nên nó có thể nằm trong một class A khởi tạo khác hoặc class C bất kỳ nào khác. Và khi class A hay C bị huỷ thì class B vẫn sống nhăn răng. Mày chết mặc mày tao vẫn sống, việc mày sử dụng tao thì là quyền lợi của mày mà thôi😄
Composition đây là quan hệ hợp thành, quan hệ này gần giống quan hệ Aggregation bên trên chỉ khác là class B không hề độc lập không thể đứng một mình, nó là một bộ phận của A và khi class A bị huỷ thì class B bị huỷ theo. Về quan hệ này thì class A có thể có nhiều class B nhưng hãy nhớ 1 điều là tao chết thì tất cả các thằng ăn bám ký sinh theo tao sẽ chết nha mày😄

Ngoài các liên kết trên thì sẽ có những chú thích <<_>> ở trên đầu mũi tên để chú giải nếu liên kết đó quá khó hiểu hay những ký hiệu *-1, - để chỉ quan hệ một nhiều hay nhiều nhiều giữa 2 đối tượng thành phần.

Các ký hiệu này thì thường dùng trong loại UML class diagrams là chủ yếu, các loại diagrams khác thì cũng biến thể và có một vài ký hiệu khác nữa mình sẽ đề cập dần dần do bài viết cũng dài và đầu tiếp thu cũng kha khá rùi.

Đây là cái class diagrams ví dụ có thể hiện các liên kết trên bạn thử tham khảo đọc thử xem có hiểu không nhé!

Trên đây là bài viết tuy không phải là tất cả của thế giới thiết kế UML nhưng hi vọng có thể giúp bạn hiểu được phần nào thứ bạn sẽ phải đối mặt khi chọn ngành culi này .

Chúc các bạn thành công trên con đường gian nan này!

#ntechdevelopers

Bài viết được tham khảo và trích dẫn của một số nguồn sau:

http://hoc-uml.blogspot.com/
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
https://en.wikipedia.org/wiki/Unified_Modeling_Language