Software Architecture and Design - Kiến Trúc & Thiết Kế Phần Mềm

Trong kiến trúc phần mềm, một subsystem (tạm dịch: mô-đun phụ) là một nhóm các mô-đun logic được nhóm lại để thực hiện một chức năng cụ thể. Nó là một phần quan trọng trong kiến trúc phần mềm, giúp phân chia và quản lý các chức năng phức tạp. Mô-đun phụ thường được thiết kế để có thể hoạt động độc lập, nhưng vẫn có thể giao tiếp với các mô-đun khác trong hệ thống. Điều này giúp tăng cường tính linh hoạt, dễ bảo trì và mở rộng hệ thống. Ví dụ, trong một hệ thống quản lý bán hàng, mô-đun phụ có thể bao gồm các chức năng như quản lý hàng hóa, quản lý đơn hàng, quản lý khách hàng, v.v. Mỗi mô-đun phụ sẽ được thiết kế để thực hiện một chức năng cụ thể, nhưng vẫn có thể giao tiếp với các mô-đun khác để thực hiện các chức năng phức tạp hơn.

Khi áp dụng nguyên tắc tách biệt mối quan tâm (Separation of Concerns) trong thiết kế mô-đun, mục tiêu chính là đảm bảo mỗi mô-đun chỉ tập trung vào một mối quan tâm cụ thể. Điều này giúp giảm thiểu sự phức tạp và tăng cường tính linh hoạt trong thiết kế hệ thống. Mỗi mô-đun sẽ có chức năng riêng biệt, dễ dàng hiểu và sửa chữa, từ đó cải thiện hiệu suất và độ tin cậy của hệ thống. Việc tách biệt mối quan tâm cũng giúp giảm thiểu sự phụ thuộc giữa các mô-đun, giúp hệ thống trở nên linh hoạt và dễ dàng mở rộng.

Khi áp dụng mô hình thiết kế Observer, vai trò chịu trách nhiệm thông báo cho tất cả các đối tượng phụ thuộc về một thay đổi trạng thái là Subject. Subject là đối tượng chịu trách nhiệm lưu trữ trạng thái và thông báo cho các đối tượng khác khi trạng thái thay đổi. Các đối tượng khác, được gọi là Observer, sẽ đăng ký để nhận thông báo từ Subject. Khi trạng thái thay đổi, Subject sẽ thông báo cho tất cả các Observer đã đăng ký, giúp chúng cập nhật trạng thái của mình. Mô hình này cho phép các đối tượng tách biệt và độc lập, nhưng vẫn có thể tương tác với nhau thông qua việc đăng ký và thông báo.

Cấu trúc tổng thể của một hệ thống phần mềm được gọi là kiến trúc phần mềm. Kiến trúc phần mềm là một mô hình tổng quan về các thành phần, mối quan hệ và giao tiếp giữa chúng trong một hệ thống phần mềm. Nó mô tả cách các thành phần khác nhau trong hệ thống được tổ chức và liên kết với nhau để đạt được mục tiêu chung. Kiến trúc phần mềm giúp đảm bảo rằng hệ thống phần mềm được thiết kế và xây dựng một cách hợp lý, hiệu quả và dễ bảo trì. Nó cũng giúp các nhà phát triển phần mềm hiểu rõ về hệ thống và có thể thực hiện các thay đổi và cải tiến một cách dễ dàng.

Trong thiết kế kiến trúc phần mềm, các đặc trưng chất lượng phần mềm đóng vai trò quan trọng. Chúng đại diện cho các yêu cầu không chức năng (non-functional requirements) có ảnh hưởng đến các quyết định kiến trúc. Ví dụ, hiệu suất, độ tin cậy, bảo mật và khả năng mở rộng là các đặc trưng chất lượng phần mềm thường được xem xét trong thiết kế kiến trúc. Mục đích của chúng là đảm bảo rằng hệ thống phần mềm đáp ứng được các yêu cầu không chức năng và cung cấp trải nghiệm người dùng tốt nhất. Vì vậy, các đặc trưng chất lượng phần mềm không chỉ là các yêu cầu kỹ thuật mà còn là yếu tố quan trọng trong việc định hình kiến trúc phần mềm.

Tính khả dụng (availability) là một trong những hệ thống vấn đề mà nó giải quyết. Tính khả dụng đề cập đến khả năng truy cập và sử dụng hệ thống một cách liên tục mà không bị gián đoạn. Trong các lựa chọn trên, tính khả dụng giải quyết vấn đề về điểm yếu duy nhất (single point of failure). Điểm yếu duy nhất là điểm yếu trong hệ thống mà nếu nó bị lỗi hoặc bị phá hủy, toàn bộ hệ thống sẽ bị ảnh hưởng. Ví dụ, nếu hệ thống sử dụng một thiết bị duy nhất để lưu trữ dữ liệu, thì khi thiết bị đó bị lỗi, toàn bộ dữ liệu sẽ bị mất. Tính khả dụng giúp đảm bảo rằng hệ thống luôn sẵn sàng và có thể truy cập được, ngay cả khi có điểm yếu duy nhất.

Trong thiết kế hệ thống dựa trên COMET, tính chất chất lượng của khả năng kiểm thử được hỗ trợ chủ yếu bằng cách cấu trúc hệ thống với các giao diện được định nghĩa rõ ràng và các thành phần được tách rời. Điều này cho phép dễ dàng kiểm thử và bảo trì hệ thống mà không ảnh hưởng đến các thành phần khác. Việc sử dụng các giao diện rõ ràng và các thành phần tách rời giúp giảm thiểu sự phụ thuộc giữa các mô-đun, từ đó tăng cường khả năng kiểm thử và bảo trì hệ thống. Điều này cũng giúp cho việc phát triển và bảo trì hệ thống trở nên dễ dàng hơn, giảm thiểu thời gian và chi phí.

Một giao diện cần thiết của một thành phần bao gồm những gì? Giao diện cần thiết của một thành phần là tập hợp các phương thức mà thành phần đó phải cung cấp hoặc thực hiện. Nó là một phần quan trọng của giao diện của thành phần và được sử dụng để xác định các yêu cầu của thành phần đối với các thành phần khác. Giao diện cần thiết của một thành phần thường bao gồm các phương thức như khởi tạo, hủy, cập nhật trạng thái, v.v. Những phương thức này được định nghĩa trong giao diện của thành phần và phải được thực hiện bởi thành phần đó. Việc xác định giao diện cần thiết của một thành phần giúp đảm bảo rằng thành phần đó có thể tương tác một cách hiệu quả với các thành phần khác trong hệ thống.

Một dịch vụ đồng thời được thiết kế như thế nào? Dịch vụ đồng thời là một mô hình thiết kế phần mềm giúp các dịch vụ có thể hoạt động cùng lúc mà không ảnh hưởng đến nhau. Để thiết kế một dịch vụ đồng thời, chúng ta cần tạo ra nhiều đối tượng (object) khác nhau, mỗi đối tượng sẽ chịu trách nhiệm xử lý một loại yêu cầu từ khách hàng (client). Ví dụ, nếu chúng ta đang thiết kế một dịch vụ đồng thời để quản lý các đơn hàng, mỗi đối tượng sẽ chịu trách nhiệm xử lý một loại yêu cầu khác nhau như tạo đơn hàng, cập nhật trạng thái đơn hàng, v.v. Điều này giúp tăng hiệu suất và giảm thiểu thời gian chờ đợi khi xử lý các yêu cầu từ khách hàng.

Trong quan hệ cơ sở dữ liệu, phân biệt (discriminator) được đại diện bằng một thuộc tính riêng biệt của bảng cha (superclass). Nó thường được sử dụng để xác định loại đối tượng cụ thể trong một quan hệ cơ sở dữ liệu có nhiều loại đối tượng khác nhau. Ví dụ, trong một bảng có thể có nhiều loại sản phẩm khác nhau, và phân biệt sẽ được sử dụng để xác định loại sản phẩm cụ thể. Điều này giúp cho việc truy vấn và xử lý dữ liệu trở nên dễ dàng hơn.

Trong cơ sở dữ liệu, một ràng buộc duy nhất (unique constraint) đảm bảo rằng mỗi bản ghi đều có một giá trị duy nhất. Trong các lựa chọn trên, khóa chính (primary key) là ràng buộc duy nhất. Khóa ngoại (foreign key) liên kết các bảng với nhau, chỉ mục (index) giúp tăng tốc độ truy vấn dữ liệu, và trigger là một hàm được thực hiện khi một sự kiện xảy ra. Do đó, khóa chính là lựa chọn đúng.

Subroutine là khái niệm của lập trình thủ tục (procedural). Class, inheritance, polymorphism đều là trụ cột của hướng đối tượng.

Đáp án đúng: C. State Pattern sinh ra đúng cho tình huống này: hành vi của đối tượng thay đổi theo trạng thái nội tại, mỗi trạng thái được tách thành một lớp riêng, và đối tượng ngữ cảnh uỷ quyền lời gọi cho đối tượng trạng thái hiện hành — nên khi trạng thái đổi thì hành vi đổi theo ngay lúc chạy. B sai vì Strategy cũng hoán đổi hành vi lúc chạy nhưng do bên ngoài chọn thuật toán, không do trạng thái nội tại của đối tượng quyết định. A sai vì Observer giải quyết việc thông báo thay đổi cho nhiều bên quan tâm. D sai vì Singleton chỉ kiểm soát số lượng thể hiện của lớp, không liên quan tới hành vi thay đổi theo trạng thái.

Đáp án đúng: B. Các mẫu kiến trúc được chia hai nhóm: mẫu CẤU TRÚC (architectural structure pattern) mô tả cách tổ chức các thành phần, và mẫu GIAO TIẾP (architectural communication pattern) mô tả cách các thành phần trao đổi thông điệp. Layers of Abstraction là mẫu cấu trúc — nó quy định hệ thống được tổ chức thành các tầng, tầng trên chỉ dùng dịch vụ của tầng dưới. A, C, D đều thuộc nhóm mẫu GIAO TIẾP: Call/Return là gọi hàm đồng bộ trong tiến trình, Asynchronous Message Communication là gửi thông điệp bất đồng bộ không chờ, Synchronous Message Communication with Reply là gửi thông điệp rồi chờ hồi đáp. Chúng nói về cách nói chuyện, không nói về cách xếp đặt cấu trúc.

Đáp án đúng: C. Trong phân loại đối tượng của COMET, đối tượng logic ứng dụng (application logic object) gồm ba nhánh: đối tượng logic nghiệp vụ, đối tượng thuật toán và đối tượng dịch vụ. Đối tượng logic nghiệp vụ tồn tại chính là để gói riêng các quy tắc nghiệp vụ, tách khỏi dữ liệu và khỏi giao diện, để khi quy tắc nghiệp vụ đổi thì chỉ sửa một chỗ. A sai vì đối tượng điều khiển lo việc điều phối trình tự và trạng thái, không phải nơi chứa quy tắc nghiệp vụ. B sai vì đối tượng biên chỉ lo giao tiếp với môi trường bên ngoài. D sai vì đối tượng thực thể chỉ lưu trữ dữ liệu bền vững; nhét quy tắc nghiệp vụ vào đó là làm mất tính độc lập mà câu hỏi đang nhắm tới.

Đáp án đúng: B. Với quan hệ toàn thể/bộ phận (whole/part), bộ phận phụ thuộc sự tồn tại vào toàn thể. Khi ánh xạ sang cơ sở dữ liệu quan hệ, khoá chính của bảng toàn thể được đưa vào bảng bộ phận và trở thành một phần của khoá chính bảng bộ phận — tạo ra khoá chính ghép (concatenated primary key), thể hiện đúng rằng bộ phận không tự định danh được nếu không có toàn thể. A sai vì đảo ngược chiều phụ thuộc: khoá ngoại nằm ở phía bộ phận, không nằm ở phía toàn thể. C nói đúng một nửa (bộ phận thường có bảng riêng) nhưng không trả lời được câu hỏi cốt lõi là quan hệ được biểu diễn thế nào. D sai vì mô hình quan hệ vẫn giữ dạng phẳng — phân cấp được diễn đạt bằng khoá, không phải bằng việc phá vỡ chuẩn phẳng.

Đáp án đúng: C. Sơ đồ tuần tự (sequence diagram) mô tả tương tác theo thời gian giữa các đối tượng, gồm đường đời (lifeline), thông điệp (message) và thanh kích hoạt (activation bar). "Entities" không phải một phần tử ký pháp của sơ đồ tuần tự — thực thể là một loại đối tượng (stereotype), và trên sơ đồ nó vẫn xuất hiện dưới dạng một đường đời như mọi đối tượng khác. A, B, D đều là phần tử chuẩn của sơ đồ tuần tự: lifeline là trục dọc biểu diễn đối tượng theo thời gian, message là mũi tên trao đổi giữa các lifeline, activation bar là khối chữ nhật mảnh cho biết đối tượng đang thực thi.

Đáp án đúng: B. Khi hệ thống tiến hoá, mô hình phân tích, mô hình thiết kế và mô hình kiến trúc phải được tinh chỉnh đồng bộ với nhau. Chỉ khi mọi tinh chỉnh được đồng bộ chéo thì các mô hình mới còn nói cùng một câu chuyện về hệ thống. A sai vì tinh chỉnh từng mô hình độc lập, không đối chiếu chéo, chính là nguyên nhân sinh ra mâu thuẫn giữa các mô hình. C sai vì hoãn cập nhật mô hình tới sau khi hiện thực xong biến mô hình thành tài liệu chết, không còn phản ánh hệ thống thật. D sai vì kiểm thử mức thành phần chỉ bắt lỗi hiện thực, không phát hiện được mâu thuẫn giữa các mô hình.

Đáp án đúng: A. Singleton Pattern bảo đảm một lớp chỉ có duy nhất một thể hiện trong toàn chương trình và cung cấp một điểm truy cập toàn cục tới thể hiện đó — đúng nguyên văn yêu cầu của câu hỏi. B sai vì Factory lo việc tạo đối tượng mà không lộ lớp cụ thể, không giới hạn số lượng thể hiện. C sai vì MVC là mẫu kiến trúc tách giao diện, dữ liệu và điều khiển. D sai vì Observer lo việc thông báo thay đổi tới nhiều đối tượng theo dõi.

Đáp án đúng: B. Một use case gồm chuỗi chính (main sequence) và các chuỗi thay thế (alternative sequence). Sơ đồ tương tác phải phủ cả chuỗi chính lẫn từng chuỗi thay thế, vì mỗi chuỗi thay thế là một đường đi khác nhau qua hệ thống với tập thông điệp khác nhau — bỏ sót chuỗi nào là bỏ sót đúng phần hành vi đó khi thiết kế. A và D đều sai vì chỉ phủ được một nửa: chỉ chuỗi chính thì mất hết nhánh ngoại lệ, chỉ chuỗi thay thế thì mất luôn luồng nghiệp vụ chính. C sai vì lấy "một chuỗi thay thế đại diện" là lấy mẫu — các chuỗi thay thế khác nhau về bản chất (lỗi nhập liệu, hết hàng, hết hạn…), không có chuỗi nào đại diện được cho các chuỗi còn lại.