Các khái niệm đối tượng hướng lập trình bao gồm: Tính kế thừa, Tính đóng gói thông tin và Lớp. Trong khi đó, SubTitle không phải là một khái niệm đối tượng hướng lập trình. Nó thường được sử dụng để chỉ một tiêu đề phụ, không liên quan đến các khái niệm cơ bản của lập trình đối tượng. Vì vậy, SubTitle là lựa chọn không đúng trong danh sách các khái niệm đối tượng hướng lập trình.

Một lớp logic kinh doanh thường chứa các quy tắc kinh doanh và các phương thức liên quan đến nghiệp vụ kinh doanh. Trong các lựa chọn trên, "Một hộp thoại" không phải là một quy tắc kinh doanh hoặc một phương thức nghiệp vụ kinh doanh. Thay vào đó, nó là một thành phần giao diện người dùng (UI) và thường được chứa trong các lớp tương tác người dùng. Do đó, "Một hộp thoại" là lựa chọn không có khả năng được bao gồm trong một lớp logic kinh doanh.

Khi sử dụng mô hình phần mềm, có nhiều lợi ích mà chúng ta có thể tận dụng. Một trong số đó là việc cải thiện giao tiếp giữa các bên liên quan. Mô hình phần mềm giúp các bên hiểu rõ hơn về yêu cầu và mục tiêu của dự án, từ đó có thể trao đổi thông tin một cách hiệu quả hơn. Ngoài ra, mô hình phần mềm còn giúp dễ dàng bảo trì mã nguồn, giảm thiểu thời gian và chi phí cho việc sửa lỗi. Tuy nhiên, một số người có thể nghĩ rằng mô hình phần mềm có thể giúp tăng cường hiệu suất của phần cứng, nhưng thực tế thì không phải vậy. Mô hình phần mềm không liên quan trực tiếp đến hiệu suất của phần cứng. Vì vậy, lựa chọn không đúng là "Tăng cường hiệu suất của phần cứng".

Trong mô hình SOA (Service-Oriented Architecture), một đại lý (broker) đóng vai trò quan trọng là trung gian giữa các khách hàng (client) và các dịch vụ (service). Đại lý giúp khách hàng tìm kiếm và liên kết với các dịch vụ cần thiết, đồng thời đảm bảo rằng các giao dịch giữa khách hàng và dịch vụ được thực hiện một cách an toàn và hiệu quả. Đại lý cũng có thể cung cấp các chức năng như kiểm tra tính khả dụng của dịch vụ, quản lý phiên bản của dịch vụ và đảm bảo rằng các giao dịch được thực hiện theo các quy tắc và chính sách đã được định nghĩa.

Sơ đồ trường hợp sử dụng (Use Case Diagram) là một loại sơ đồ được sử dụng trong thiết kế phần mềm để mô tả các tương tác giữa người dùng và hệ thống. Nó giúp xác định các yêu cầu chức năng của hệ thống và các trường hợp sử dụng mà người dùng có thể thực hiện. Sơ đồ trường hợp sử dụng thường bao gồm các thành phần như người dùng, hệ thống và các trường hợp sử dụng. Mỗi trường hợp sử dụng được mô tả bằng một hình oval và bao gồm các hành động mà người dùng có thể thực hiện với hệ thống. Sơ đồ này giúp các nhà phát triển phần mềm hiểu rõ về các yêu cầu chức năng của hệ thống và thiết kế hệ thống một cách phù hợp.

Trong lập trình hướng đối tượng, Encapsulation, Class và Subclass là những khái niệm quan trọng. Encapsulation giúp cô lập dữ liệu và phương thức, Class là một mẫu thiết kế mô tả một loại đối tượng, Subclass là một lớp con kế thừa tính chất của lớp cha. Tuy nhiên, Subroutine không phải là một khái niệm liên quan đến lập trình hướng đối tượng. Subroutine thường được sử dụng trong lập trình thủ tục, nơi mà một đoạn mã được gọi nhiều lần trong chương trình. Vì vậy, trong bối cảnh lập trình hướng đối tượng, Subroutine không phải là một khái niệm liên quan.

Một hệ thống an toàn thường bao gồm các yếu tố như bảo mật truy cập (authorization), ngăn chặn xâm nhập (penetration), ngăn chặn dịch vụ (denial of service). Tuy nhiên, hệ thống khả năng mở rộng (system scalability) không phải là một yếu tố được giải quyết bởi một hệ thống an toàn. Khả năng mở rộng là một khía cạnh quan trọng của thiết kế hệ thống, nhưng nó không liên quan trực tiếp đến bảo mật. Vì vậy, trong danh sách các lựa chọn, "System scalability" là không được giải quyết bởi một hệ thống an toàn.

Một trong những đặc điểm chính của lớp máy trạng thái được mô tả trong ngữ cảnh này là sự đóng gói thông tin trạng thái chart và ẩn bảng chuyển trạng thái. Điều này có nghĩa là lớp máy trạng thái sẽ chứa tất cả thông tin về trạng thái và chuyển trạng thái, nhưng không cung cấp quyền truy cập trực tiếp vào bảng chuyển trạng thái. Thay vào đó, lớp máy trạng thái sẽ cung cấp các phương thức để xử lý các sự kiện nhập vào và thực hiện các chuyển trạng thái phù hợp. Điều này giúp bảo vệ bảng chuyển trạng thái khỏi việc truy cập không mong muốn và đảm bảo rằng trạng thái của hệ thống được quản lý một cách hợp lý.

Thông tin ẩn là một khái niệm liên quan đến khái niệm đóng gói trong kỹ thuật phần mềm. Nói cách khác, thông tin ẩn là một phần của khái niệm đóng gói, tập trung vào việc ẩn các chi tiết nội bộ. Khi một lớp thực hiện thông tin ẩn, nó sẽ chỉ cung cấp một giao diện cho người dùng, đồng thời ẩn đi các chi tiết nội bộ của lớp đó. Điều này giúp giảm thiểu sự phụ thuộc vào lớp và tăng cường tính linh hoạt của hệ thống. Thông tin ẩn cũng giúp bảo vệ lớp khỏi việc truy cập trực tiếp vào các thành phần nội bộ, từ đó giảm thiểu khả năng xảy ra lỗi và tăng cường tính bảo mật của hệ thống.

Khi một trạng thái máy trạng thái (state machine) chuyển sang một trạng thái hợp thành (composite state), điều này tương đương với việc chuyển sang một trong các trạng thái con (substates) của trạng thái hợp thành đó. Trạng thái hợp thành có thể bao gồm một hoặc nhiều trạng thái con, và việc chuyển sang trạng thái hợp thành có thể được xem như là một cách để mô tả một chuỗi các trạng thái con.

Khi thiết kế kiến trúc dịch vụ hướng chức năng (SOA), một mối quan tâm chính là sự kết nối lỏng lẻo giữa các thành phần để tăng tính linh hoạt. Điều này có nghĩa là các thành phần có thể được thiết kế và triển khai độc lập mà không ảnh hưởng đến các thành phần khác. Sự kết nối lỏng lẻo giúp tăng cường khả năng mở rộng, giảm thiểu rủi ro và cải thiện khả năng bảo trì. Ngoài ra, nó cũng giúp tăng cường khả năng thích nghi với các thay đổi trong yêu cầu của hệ thống. Vì vậy, sự kết nối lỏng lẻo giữa các thành phần là một yếu tố quan trọng khi thiết kế kiến trúc dịch vụ hướng chức năng.

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.