Đo lường kết cấu kiến trúc phần mềm

Bài viết được sự cho phép của tác giả Edward Thien Hoang

Mục tiêu của thiết kế làm làm sao để hệ thống xây dựng lên nhanh chóng, dễ dàng thích nghi với các thay đổi về nghiệp vụ và công nghệ, dễ dàng bảo trì về sau. Để làm được điều đó, thiết kế cần đảm bảo tính low coupling, high cohesion và encapsulation. Tuy nhiên trong quá trình phát triển, làm sao để biết được là chúng ta đã đi đúng hướng, các class, component, … tạo ra đã đáp ứng được yêu cầu về mặt thiết kế hay chưa? Vì vậy chúng ta cần một số công cụ, phương thức nhằm đo lường (measure) các số liệu (metric) về thiết kế trong suốt quá trình thiết kế và phát triển để đảm bảo mọi thứ đang được đi đúng hướng.

Xem thêm các Việc làm Software Architect lương cao hấp dẫn trên TopDev

Robert C. Martin, tác giả của SOLID, Clean Code, Agile Software Development, Principles, Patterns, and Practices và gần đây nhất là cuốn Clean Architecture: A Craftsman’s Guide to Software Structure and Design.. Ông đã đưa ra một nhóm các metric tập trung vào việc phân tích mối quan hệ giữa các component.

Các metric bao gồm:

• Efferent Coupling (Ce)
• Afferent Coupling (Ca)
• Instability (I)
• Abstractness (A)
• Normalized Distance from Main Sequence (D)

EFFERENT COUPLING (CE)

Metric này được sử dụng để đo mối tương quan giữa các component. Theo định nghĩa, nó là một số class trong một component phụ thuộc vào các class trong các component khác, trả lời cho câu hỏi mật độ một component phải thay đổi khi có sự thay đổi ở các component khác như thế nào.

Hình 1 – Outgoing dependencies

Trong Hình 1 cho thấy rằng component A có sự phụ thuộc đến (outgoing dependency) 3 component khác, đó là lý do tại sao chỉ số Ce cho component này là 3.

Khi chỉ số Ce > 20 cho thấy sự không ổn định của một component, thay đổi trong bất kỳ component bên ngoài có thể gây ra sự cần thiết phải thay đổi bên trong component này. Chỉ số Ce nên nằm trong khoảng từ 0 đến 20, giá trị cao hơn gây ra vấn đề với việc phát triển và bảo trì.

AFFERENT COUPLING (CA)

Metric này là phần bổ sung cho Metric Ce và được sử dụng để đo lường một loại phụ thuộc khác giữa các component. Nó cho phép chúng ta đo độ nhạy của các component còn lại với những thay đổi trong component phân tích, trả lời cho câu hỏi liệu những thay đổi trong component này sẽ ảnh hưởng đến những chỗ khác như thế nào.

Hình 2 – Incoming dependencies

Trong Hình 2 có thể thấy rằng component A chỉ có 1 sự phụ thuộc vào (incoming dependency) component X, đó là lý do tại sao giá trị của chỉ số Ca bằng 1.

Giá trị của Ca càng cao nghĩa là độ ổn định (stability) của component sẽ cao. Điều này cho thấy có rất nhiều component đang depend trên component này. Vì vậy, nó không thể được sửa đổi đáng kể bởi vì xác suất lây lan những thay đổi như vậy sẽ tăng lên.
Giá trị khuyến nghị của Ca vào khoảng 0 đến 500.

INSTABILITY (I)

Metric này được sử dụng để đo độ nhạy tương đối của component với những thay đổi. Theo công thức dưới đây:

Trong đó: Ce – phụ thuộc đến, Ca – phụ thuộc vào

Hình 3 – Instability

Trong Hình 3 có thể thấy rằng component A phụ thuộc đến 3 component và có 1 component phụ thuộc vào nó, do đó theo công thức ta có I = 0,75.

Trên cơ sở giá trị của chỉ số I chúng ta có thể phân biệt hai loại thành phần:
Những component có nhiều phụ thuộc đến và không nhiều phụ thuộc vào (giá trị I tiến gần tới 1), điều này không ổn định bởi vì các component này có khả năng bị thay đổi rất cao;

Những component có nhiều phụ thuộc vào và không nhiều phụ thuộc đến (giá trị I gần về 0), do đó chúng sẽ có khả năng ít bị thay đổi, tuy nhiên, sự thay đổi từ chúng sẽ có ảnh hưởng rất lớn.

Các giá trị ưu tiên cho chỉ số I phải nằm trong phạm vi từ 0 đến 0.3 hoặc 0.7 đến 1. Các component phải rất ổn định hoặc rất không ổn định, và nên tránh các component có độ ổn định trung bình.

ABSTRACTNESS (A)

Metric này được sử dụng để đo mức độ trừu tượng của component được tính theo công thức:

Trong đó: Tabstract là số lớp trừu tượng, interface trong một component, T concrete là số lớp cụ thể trong một component

Các giá trị khuyến nghị cho chỉ số A phải có các giá trị cực trị gần 0 hoặc 1. Các component có độ ổn định (I gần bằng 0), nghĩa là chúng phụ thuộc ở mức rất thấp trên các component khác, cũng nên được trừu tượng (chỉ số A cũng gần bằng 1). Ngược lại, các component không ổn định (I gần với 1) nên bao gồm các lớp cụ thể (A cũng gần bằng 0).

Thêm vào đó, cần lưu ý rằng việc kết hợp tính trừu tượng và tính ổn định cho phép Martin hình thành luận văn về sự tồn tại của luồng chính (Main sequence) (Hình 4).

Hình 4 – Main sequence

Trong trường hợp tối ưu, tính không ổn định của lớp được bù đắp bởi tính trừu tượng của nó, có một phương trình I + A = 1. Các class được thiết kế tốt nên tập trung xung quanh điểm kết thúc của đồ thị này theo luồng chính.

Trong đó: A- tính trừu tượng, I – tính bất ổn

Giá trị của chỉ số D có thể được giải thích theo cách sau: nếu chúng ta đặt một lớp cho một đồ thị của luồng chính (Hình 5) thì khoảng cách của nó từ luồng chính sẽ tỉ lệ thuận với giá trị của D.

Hình 5 – Khoảng cách được chuẩn hóa từ luồng chính

Giá trị của D phải càng thấp càng tốt để các thành phần được đặt gần với luồng chính.

Ngoài ra, hai trường hợp cực kỳ bất lợi được xem xét:

• A = 0 và I = 0, một component rất ổn định (stable) và cụ thể (concrete), tình huống không được mong muốn bởi vì chúng rất khó hoặc không thể mở rộng;
• A = 1 và I = 1, hoàn toàn không thể vì một component hoàn toàn trừu tượng phải có một số kết nối với bên ngoài, do đó có thể tạo ra cá instance để implement các chức năng được định nghĩa trong các lớp trừu tượng trong component này.

SUMMARY

Sử dụng các số liệu của Martin, chúng ta có thể dễ dàng đánh giá các mối quan hệ giữa các component trong dự án và xác định liệu có cần phải thực hiện các thay đổi để tránh những vấn đề có thể xảy ra trong tương lai hay không. Tất cả các số liệu được thảo luận trong bài viết này có thể được đo cho các dự án trong .NET sử dụng công cụ NDepend hoặc JDepend đối với Java.

Đây là bài viết trong loạt bài viết về “Tổng quan về sự phát triển của kiến trúc phần mềm“. Đây là loạt bài viết chủ yếu giới thiệu về một số mô hình kiến trúc phần mềm hay nói đúng hơn là sự phát triển của chúng qua từng giai đoạn, qua đó giúp chúng ta có cái nhìn tổng quát, up-to-date và là roadmap để bắt đầu hành trình chinh phục (đào sâu) thế giới của những bản thiết kế với vai trò là những kỹ sư và kiến trúc sư phần mềm đam mê với nghề.

Bài viết được tham khảo từ:

https://www.future-processing.pl/blog/object-oriented-metrics-by-robert-martin/

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

• UX là gì? UX Designer thì làm những gì?
• Tại sao Test Coverage là một phần quan trọng của Kiểm thử phần mềm?
• 32 cuốn sách học lập trình bạn nhất định phải đọc

Xem thêm Việc làm IT hấp dẫn trên TopDev