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

Một hệ thống kiểm soát (control subsystem) được yêu cầu khi một hệ thống cần kiểm soát nhiều đối tượng nội bộ. Điều này có nghĩa là hệ thống cần có khả năng quản lý và điều khiển các hoạt động của các đối tượng này để đạt được mục tiêu hoặc chức năng mong muốn. Ví dụ, một hệ thống điều khiển nhiệt độ trong một tòa nhà có thể cần kiểm soát nhiều thiết bị như quạt, máy sưởi, máy điều hòa nhiệt độ,... để duy trì nhiệt độ ổn định. Trong trường hợp này, hệ thống kiểm soát sẽ cần phải kiểm soát các thiết bị này để đảm bảo rằng nhiệt độ trong tòa nhà luôn ở mức mong muốn.

COMET (Component-based Object-Oriented Modeling and Engineering Technique) là một phương pháp phát triển phần mềm tập trung vào các mô hình và các thành phần. Trong vòng đời của COMET, các thành phần được sử dụng để mô hình hóa các yêu cầu của hệ thống và các giao tiếp giữa chúng. Vì vậy, vòng đời của COMET chủ yếu dựa trên các trường hợp sử dụng (Use cases). Các trường hợp sử dụng giúp xác định các yêu cầu chức năng của hệ thống và các giao tiếp giữa các thành phần. Điều này cho phép các nhà phát triển xây dựng một hệ thống có khả năng tương tác và đáp ứng được các yêu cầu của người dùng.

Cấu trúc phần mềm được định nghĩa bởi Bass, Clements và Kazman là mô hình phần mềm của một chương trình hoặc hệ thống tính toán, bao gồm cấu trúc hoặc cấu trúc của hệ thống, bao gồm các phần tử phần mềm, các tính chất có thể nhìn thấy bên ngoài của các phần tử đó và mối quan hệ giữa chúng. Điều này bao gồm các thành phần phần mềm, các thuộc tính có thể nhìn thấy bên ngoài và mối quan hệ giữa chúng. Cấu trúc phần mềm này là nền tảng để xây dựng và phát triển các hệ thống phần mềm phức tạp. Nó giúp các nhà phát triển hiểu rõ về các phần tử và mối quan hệ giữa chúng, từ đó có thể thiết kế và xây dựng các hệ thống phần mềm hiệu quả và đáng tin cậy.

Một thông điệp đầu vào đến với một đối tượng kiểm soát phụ thuộc vào trạng thái tương ứng với một sự kiện trên máy trạng thái nội bộ. Điều này có nghĩa là thông điệp đầu vào sẽ kích hoạt một sự kiện nào đó trên máy trạng thái nội bộ, từ đó dẫn đến việc thay đổi trạng thái của đối tượng kiểm soát. Ví dụ, khi một người nhấn nút trên một thiết bị điện tử, nút đó sẽ gửi một thông điệp đầu vào đến với máy trạng thái nội bộ của thiết bị, và thông điệp này sẽ tương ứng với một sự kiện nào đó trên máy trạng thái nội bộ.

Một máy trạng thái hữu hạn (Finite State Machine - FSM) là một mô hình toán học được sử dụng để mô tả và phân tích các hệ thống có trạng thái. Nó được đặc trưng bởi một tập hợp hữu hạn các trạng thái và một tập hợp hữu hạn các chuyển tiếp giữa các trạng thái. Máy trạng thái hữu hạn có thể được sử dụng để mô hình hóa các hệ thống như máy tính, các hệ thống tự động hóa, và các hệ thống giao tiếp. Trong một máy trạng thái hữu hạn, mỗi trạng thái được xác định bởi một tập hợp các biến trạng thái và mỗi chuyển tiếp được xác định bởi một tập hợp các biến trạng thái và một tập hợp các hành động. Máy trạng thái hữu hạn có thể được sử dụng để mô hình hóa các hệ thống có trạng thái và để phân tích các hệ thống này.

Khi nói đến phân loại các đối tượng dựa trên vị trí địa lý khác nhau, chúng ta cần xem xét cách tổ chức và quản lý các hệ thống. Trong hệ thống phân cấp, các đối tượng được tổ chức theo cấp độ hoặc lớp, giúp dễ dàng quản lý và bảo trì. Tuy nhiên, đối với các đối tượng ở vị trí địa lý khác nhau, chúng thường không nằm trong cùng một cấp độ hoặc lớp. Thay vào đó, chúng nên được phân loại thành các hệ thống khác nhau, giúp dễ dàng quản lý và bảo trì từng hệ thống riêng lẻ. Điều này giúp đảm bảo hiệu suất và độ tin cậy của hệ thống.

Mục tiêu chính của việc xác minh phần mềm (software validation) là đảm bảo rằng hệ thống phần mềm được xây dựng đúng và đáp ứng được các yêu cầu chức năng và yêu cầu kỹ thuật. Điều này có nghĩa là hệ thống phần mềm cần phải hoạt động chính xác và hiệu quả trong môi trường thực tế. Xác minh phần mềm giúp đảm bảo rằng hệ thống phần mềm không chỉ được xây dựng đúng (có thể hoạt động) mà còn đáp ứng được các yêu cầu chức năng và kỹ thuật của người dùng. Điều này đòi hỏi phải có một quá trình xác minh kỹ lưỡng và chi tiết để đảm bảo rằng hệ thống phần mềm đáp ứng được các yêu cầu của người dùng.

Câu hỏi này yêu cầu bạn xác định yếu tố không liên quan đến hiệu suất của hệ thống. Hệ thống có thể được đo bằng nhiều chỉ số khác nhau, bao gồm thời gian phản hồi (system response time), khả năng xử lý (system throughput), khả năng sẵn sàng (system availability) và khả năng chứa (system capacity). Trong số các yếu tố này, khả năng sẵn sàng (system availability) không phải là một chỉ số hiệu suất. Khả năng sẵn sàng được đo bằng tỷ lệ thời gian hệ thống hoạt động bình thường và sẵn sàng phục vụ người dùng. Mặc dù khả năng sẵn sàng là một yếu tố quan trọng, nhưng nó không phải là một chỉ số hiệu suất như thời gian phản hồi, khả năng xử lý và khả năng chứa.

Deployment view của kiến trúc phần mềm là một cách nhìn tổng quan về cấu hình vật lý của hệ thống, bao gồm các nút (node) và các liên kết (interconnections) giữa chúng. Nó cho phép người thiết kế và phát triển phần mềm hiểu rõ về cấu trúc và tổ chức của hệ thống, bao gồm vị trí của các thành phần và cách chúng tương tác với nhau. Deployment view thường được sử dụng để mô hình hóa và thiết kế hệ thống phân tán, nơi mà các thành phần được triển khai trên nhiều nút khác nhau. Nó cũng giúp xác định các yêu cầu về kết nối mạng, lưu trữ và phân phối dữ liệu.

Một thông điệp đầu ra từ một đối tượng kiểm soát phụ thuộc vào trạng thái tương ứng với một hành động trên máy trạng thái nội bộ. Điều này có nghĩa là thông điệp đầu ra được tạo ra bởi một hành động cụ thể được thực hiện bởi máy trạng thái nội bộ. Ví dụ, trong một hệ thống kiểm soát nhiệt độ, một thông điệp đầu ra có thể được tạo ra khi máy trạng thái nội bộ chuyển sang trạng thái 'nhiệt độ cao' và hành động được thực hiện là bật quạt gió để làm mát. Trong trường hợp này, thông điệp đầu ra tương ứng với hành động 'bật quạt gió' trên máy trạng thái nội bộ.

Các quy trình trong USDP bao gồm các bước sau: Thu thập yêu cầu, phân tích, thiết kế, triển khai và kiểm tra. USDP là một phương pháp phát triển phần mềm được sử dụng rộng rãi trong các công ty và tổ chức. Mục tiêu của USDP là đảm bảo rằng các sản phẩm phần mềm được phát triển đáp ứng được yêu cầu của khách hàng và đáp ứng được các tiêu chuẩn chất lượng cao. Các bước trong USDP được thiết kế để giúp các nhà phát triển phần mềm thực hiện các nhiệm vụ một cách có hệ thống và hiệu quả.

Trong thiết kế hệ thống phân chia, 'Tách biệt mối quan hệ' (Separation of Concerns) nhằm đạt được mục tiêu giảm thiểu sự liên kết (coupling) và tăng cường sự gắn kết (cohesion) giữa các phần tử trong hệ thống. Điều này có nghĩa là mỗi phần tử sẽ có một chức năng riêng biệt và độc lập, giúp giảm thiểu sự phụ thuộc lẫn nhau và tăng cường khả năng linh hoạt trong việc phát triển và bảo trì hệ thống.

Đáp án đúng: B. Ở pha phân tích, yêu cầu chức năng được mô hình hoá bằng sơ đồ use case: nó chỉ ra tác nhân nào tương tác với hệ thống và hệ thống cung cấp những chức năng gì, ở mức nhìn từ bên ngoài, không lệ thuộc vào cách hiện thực. A sai vì sơ đồ lớp mô tả cấu trúc tĩnh, thuộc mô hình tĩnh chứ không phải mô tả yêu cầu chức năng. C sai vì sơ đồ triển khai nói về việc phần mềm nằm trên phần cứng nào, thuộc pha thiết kế. D sai vì sơ đồ máy trạng thái mô tả hành vi phụ thuộc trạng thái của một đối tượng cụ thể, chi tiết hơn nhiều so với mức yêu cầu chức năng.

Một điểm biến đổi trong trường hợp sử dụng (use case variation point) là một vị trí trong trường hợp sử dụng nơi có thể xảy ra sự thay đổi. Nó đại diện cho một điểm trong trường hợp sử dụng nơi có thể có nhiều cách giải quyết khác nhau. Ví dụ, trong trường hợp sử dụng 'Mua hàng trực tuyến', điểm biến đổi có thể là 'Xác nhận đơn hàng', nơi có thể có nhiều cách giải quyết khác nhau như gửi email xác nhận, gửi tin nhắn xác nhận hoặc hiển thị thông báo xác nhận trên màn hình.

Trong bối cảnh một trường hợp sử dụng, một đối tượng điều khiển (control object) tương tự như một người chỉ huy dàn nhạc. Họ đều có vai trò là người điều khiển và chỉ đạo các hoạt động của các thành viên khác. Trong một dàn nhạc, người chỉ huy dàn nhạc sẽ chỉ đạo các nhạc sĩ khác về cách chơi nhạc và thời gian thực hiện. Tương tự, trong một trường hợp sử dụng, đối tượng điều khiển sẽ chỉ đạo các đối tượng khác về cách thực hiện các hành động và giao dịch. Họ sẽ xác định các yêu cầu và quy trình cần thực hiện để đạt được mục tiêu của trường hợp sử dụng.

Một sơ đồ giao tiếp (communication diagram) là một loại mô hình tương tác trong thiết kế phần mềm, được sử dụng để minh họa các giao tiếp giữa các đối tượng phần mềm. Nó cho thấy các đối tượng phần mềm tương tác với nhau theo một trình tự nhất định. Trong sơ đồ giao tiếp, các đối tượng phần mềm được biểu diễn dưới dạng các hộp, và các giao tiếp giữa chúng được biểu diễn dưới dạng các đường thẳng. Mỗi giao tiếp được biểu diễn bằng một dòng, và dòng đó thể hiện thông tin được truyền giữa các đối tượng. Sơ đồ giao tiếp giúp các nhà phát triển phần mềm hiểu rõ về các tương tác giữa các đối tượng phần mềm và thiết kế các giao tiếp một cách hiệu quả.

Trong quá trình chuẩn hóa cơ sở dữ liệu, mục tiêu của Normal Form thứ hai (2NF) là loại bỏ sự phụ thuộc phần tử trên một khóa hợp phần. Normal Form thứ hai (2NF) đảm bảo rằng mỗi trường không thuộc khóa chính phải phụ thuộc vào toàn bộ khóa chính, không phụ thuộc vào một phần của khóa hợp phần. Điều này giúp giảm thiểu sự trùng lặp dữ liệu và cải thiện độ tin cậy của cơ sở dữ liệu. Ví dụ, nếu chúng ta có một bảng có khóa hợp phần gồm hai trường 'Mã khách hàng' và 'Tên khách hàng', thì Normal Form thứ hai (2NF) sẽ loại bỏ trường 'Tên khách hàng' nếu nó chỉ phụ thuộc vào 'Mã khách hàng', không phụ thuộc vào cả hai trường trong khóa hợp phần.

Trong sơ đồ trạng thái, điều kiện bảo vệ (guard condition) là một điều kiện phải thỏa mãn để chuyển trạng thái xảy ra. Điều kiện bảo vệ thường được sử dụng để kiểm tra xem một trạng thái có thể chuyển sang trạng thái khác hay không. Nó giống như một bộ lọc giúp đảm bảo rằng trạng thái chuyển tiếp chỉ xảy ra khi điều kiện cụ thể được đáp ứng. Ví dụ, trong một hệ thống thanh toán, điều kiện bảo vệ có thể là "số tiền lớn hơn 0" để chỉ cho phép chuyển trạng thái sang trạng thái "đã thanh toán" khi số tiền lớn hơn 0. Điều kiện bảo vệ giúp hệ thống trở nên linh hoạt và dễ dàng mở rộng.

Trong sơ đồ lớp, một lớp được thể hiện bằng một hộp có thể có một, hai hoặc ba phần. Phần đầu tiên là tên lớp, phần thứ hai là các thuộc tính và phần thứ ba là các phương thức. Điều này giúp dễ dàng phân biệt và hiểu rõ về các lớp và mối quan hệ giữa chúng.

Mô hình kiến trúc monolithic và microservices là hai phương pháp khác nhau trong thiết kế phần mềm. Mô hình monolithic là một ứng dụng lớn được xây dựng như một đơn vị duy nhất, trong khi mô hình microservices là một hệ thống lớn được chia nhỏ thành nhiều dịch vụ độc lập. Mô hình monolithic thường khó mở rộng và sửa chữa hơn, trong khi mô hình microservices cho phép dễ dàng mở rộng và sửa chữa từng dịch vụ riêng lẻ. Điều này làm cho mô hình microservices trở nên linh hoạt và dễ dàng thích nghi với sự thay đổi của nhu cầu.