[SU25] Đề Luyện Tập FE

COMET (Component-Oriented Methodology for Engineering and Technology) là một phương pháp thiết kế kiến trúc phần mềm tập trung vào việc sử dụng các phương pháp hướng đối tượng để đạt được mô-đun hóa. Phương pháp này giúp các nhà phát triển tạo ra các thành phần phần mềm độc lập, dễ dàng tích hợp và bảo trì. COMET tập trung vào việc phân chia hệ thống thành các thành phần nhỏ, mỗi thành phần có trách nhiệm riêng biệt, giúp giảm thiểu sự phức tạp và tăng cường khả năng mở rộng của hệ thống. Điều này giúp các nhà phát triển dễ dàng thêm hoặc thay thế các thành phần mới mà không ảnh hưởng đến các thành phần khác.

Mục đích chính của mô hình hóa phần mềm trong quá trình phát triển phần mềm là để tạo ra một mô hình chi tiết và chính xác về hệ thống phần mềm. Điều này giúp các nhà phát triển phần mềm hiểu rõ về yêu cầu của hệ thống, xác định các yêu cầu chức năng và không chức năng, và thiết kế hệ thống phần mềm một cách hiệu quả. Mô hình hóa phần mềm cũng giúp các nhà phát triển phần mềm xác định các mối quan hệ giữa các thành phần của hệ thống, từ đó có thể tạo ra một hệ thống phần mềm ổn định và dễ bảo trì.

Trong mô hình Waterfall, các giai đoạn được thực hiện theo một trình tự cố định. Giai đoạn đầu tiên là thu thập yêu cầu (Requirements), sau đó là thiết kế (Design), tiếp theo là triển khai (Implementation), kiểm thử (Testing), triển khai (Deployment) và cuối cùng là bảo trì (Maintenance). Mô hình này được gọi là mô hình thác nước vì các giai đoạn được thực hiện theo một trình tự tuyến tính, không có sự lặp lại hoặc điều chỉnh giữa các giai đoạn. Mỗi giai đoạn phải được hoàn thành trước khi chuyển sang giai đoạn tiếp theo.

White box testing là một phương pháp kiểm thử phần mềm trong đó người kiểm thử có kiến thức chi tiết về cấu trúc và chức năng của phần mềm. Điều này cho phép họ tạo ra các trường hợp kiểm thử cụ thể và hiệu quả để kiểm tra các phần quan trọng của phần mềm. Trong white box testing, người kiểm thử thường sử dụng các kỹ thuật như phân tích mã nguồn, tạo ra các trường hợp kiểm thử dựa trên các yêu cầu chức năng và tạo ra các bản đồ kiểm thử để đảm bảo rằng tất cả các phần của phần mềm đều được kiểm tra. White box testing giúp phát hiện các lỗi và vấn đề trong phần mềm một cách hiệu quả và nhanh chóng.

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 sơ đồ trường hợp sử dụng, diễn viên được thể hiện bằng hình dạng đặc biệt để phân biệt với các đối tượng khác. Hình dạng này thường là một hình dạng đơn giản, chẳng hạn như một hình oval hoặc một hình dạng khác. Tuy nhiên, trong trường hợp này, diễn viên được thể hiện bằng một hình dạng đặc biệt khác, đó là một hình dạng giống như một người, thường được gọi là một 'stick figure' hoặc 'hình người'. Hình dạng này được sử dụng để thể hiện diễn viên trong quá trình tương tác với hệ thống.

Các tiêu chí cấu trúc phần mềm là các nguyên tắc, phương pháp giúp phân chia và tổ chức hệ thống phần mềm thành các thành phần, mô-đun riêng biệt. Chúng cung cấp hướng dẫn cụ thể để giúp các nhà phát triển phần mềm tạo ra một hệ thống phần mềm có cấu trúc rõ ràng, dễ dàng bảo trì và mở rộng. Các tiêu chí cấu trúc phần mềm giúp đảm bảo rằng hệ thống phần mềm được thiết kế một cách hệ thống và có thể đáp ứng được các yêu cầu của người dùng. Chúng cũng giúp giảm thiểu sự phức tạp của hệ thống phần mềm và tăng cường khả năng bảo trì, sửa lỗi và nâng cấp.

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.

Quá trình thiết kế phần mềm thường bắt đầu bằng việc phân tích yêu cầu. Điều này bao gồm việc thu thập thông tin về yêu cầu của khách hàng, xác định các yêu cầu chính và thứ tự ưu tiên của chúng. Quá trình này giúp đảm bảo rằng phần mềm được thiết kế đáp ứng được nhu cầu và kỳ vọng của người dùng. Sau khi phân tích yêu cầu, các nhà thiết kế phần mềm sẽ tiếp tục với việc thiết kế kiến trúc, lập kế hoạch và thực hiện. Vì vậy, phân tích yêu cầu là bước đầu tiên và quan trọng trong quá trình thiết kế phần mềm.

Interface của một lớp trong lập trình là tập hợp các phương thức và thuộc tính được định nghĩa để cung cấp cho người sử dụng. Nó mô tả các chức năng và hành vi mà lớp đó có thể thực hiện. Interface giúp định nghĩa rõ ràng các yêu cầu và giới hạn của lớp, từ đó giúp các nhà phát triển khác hiểu rõ cách sử dụng và tương tác với lớp đó. Ví dụ, nếu một lớp có interface là 'Lớp có thể tạo ra một đối tượng mới', thì lớp đó phải cung cấp phương thức tạo ra đối tượng mới. Interface giúp tăng cường tính linh hoạt và tái sử dụng của mã nguồn, đồng thời giúp giảm thiểu sự phức tạp và lỗi trong quá trình phát triển phần mềm.

Trong lập trình hướng đối tượng, từ khóa thường được sử dụng để thực hiện ẩn thông tin bên trong một lớp là Private. Khi sử dụng từ khóa Private, các thuộc tính hoặc phương thức của lớp sẽ không thể truy cập được từ bên ngoài lớp, giúp bảo vệ thông tin và ngăn chặn việc truy cập không hợp lệ. Điều này giúp tăng cường tính bảo mật và giảm thiểu khả năng xảy ra lỗi do truy cập không đúng. Ngoài ra, thông tin được ẩn cũng giúp giảm thiểu khả năng xảy ra xung đột giữa các lớp, vì các lớp không thể truy cập trực tiếp vào thông tin của nhau.

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.

Trong quá trình phân tích mô hình hóa, các nhà phát triển phần mềm sẽ tiến hành xây dựng các mô hình tĩnh và động. Mô hình tĩnh bao gồm các yếu tố như lớp, đối tượng, phương thức, trong khi mô hình động mô tả các tương tác giữa các đối tượng và các quy trình. Việc xây dựng các mô hình này giúp xác định rõ yêu cầu của hệ thống, xác định các mối quan hệ giữa các thành phần và tạo cơ sở cho việc thiết kế hệ thống. Mô hình tĩnh và động đóng vai trò quan trọng trong việc đảm bảo hệ thống được thiết kế một cách hợp lý và hiệu quả.

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.

Trong quá trình thiết kế mô hình, người ta thực hiện các bước sau: Phát triển mô hình trường hợp sử dụng, Phát triển sơ đồ lưu chuyển dữ liệu và mối quan hệ thực thể, Phát triển mô hình tĩnh và động, Phát triển kiến trúc phần mềm. Mỗi bước này đều đóng vai trò quan trọng trong việc xây dựng mô hình thiết kế chính xác và hiệu quả. Tuy nhiên, trong số các lựa chọn trên, Phát triển kiến trúc phần mềm là bước được thực hiện trong thiết kế mô hình.

Hoạt động trong sơ đồ hoạt động có thể được sử dụng để cung cấp mô tả chính xác hơn về trường hợp sử dụng, vì nó cho thấy chính xác ở đâu trong chuỗi và điều kiện gì cho chuỗi thay thế phân nhánh khỏi chuỗi chính. Sơ đồ hoạt động giúp xác định rõ hơn các bước trong một quy trình và điều kiện để chuyển sang bước khác. Điều này giúp cho việc phân tích và thiết kế hệ thống trở nên dễ dàng hơn. Ngoài ra, sơ đồ hoạt động cũng giúp xác định rõ hơn các điểm phân nhánh và kết hợp trong quy trình, giúp cho việc thực hiện quy trình trở nên hiệu quả hơn.

Hoạt động biểu đồ (Activity Diagram) là một công cụ quan trọng trong mô hình hóa các trường hợp sử dụng (Use Case). Nó được sử dụng để mô tả các hoạt động chính và các hoạt động thay thế trong một trường hợp sử dụng. Hoạt động biểu đồ giúp xác định các bước thực hiện trong một trường hợp sử dụng, bao gồm cả các hoạt động chính và các hoạt động thay thế. Điều này giúp các nhà phát triển hiểu rõ hơn về các yêu cầu của hệ thống và thiết kế các giải pháp phù hợp.

Một use case là một mô tả chi tiết về một trường hợp sử dụng cụ thể của một hệ thống, bao gồm cả các tương tác giữa người dùng và các đối tượng trong hệ thống. Nó mô tả một cách cụ thể về các yêu cầu của người dùng, các hành động mà người dùng sẽ thực hiện và các phản hồi mà hệ thống sẽ cung cấp. Mục đích của một use case là để xác định các yêu cầu chức năng của hệ thống và đảm bảo rằng hệ thống đáp ứng được các yêu cầu của người dùng.

Một hiệp hội tổng/specialization (hay còn gọi là hiệp hội tổng hóa) là một cấu trúc tổ chức các lớp trong đó một lớp được tạo ra từ một lớp khác. Lớp được tạo ra được gọi là lớp con (specialized class) và lớp khác được gọi là lớp cha (generalized class). Trong một hiệp hội tổng/specialization, lớp con kế thừa các thuộc tính và hành vi của lớp cha và có thể thêm hoặc thay đổi chúng. Điều này giúp giảm thiểu sự lặp lại và tăng cường tính linh hoạt trong thiết kế hệ thống. Ví dụ, nếu chúng ta có một lớp 'Động vật' và một lớp 'Mèo', thì 'Mèo' có thể được tạo ra từ 'Động vật' và kế thừa các thuộc tính như 'sống', 'ăn' v.v. từ lớp cha.

Một cấu trúc tổ chức gọi là hiệp hội cấu trúc (composition hierarchy) mô tả mối quan hệ giữa một đối tượng và các thành phần của nó. Trong một hiệp hội cấu trúc, các thành phần được coi là một phần không thể tách rời của đối tượng. Ví dụ, một chiếc xe có thể được xem là một hiệp hội cấu trúc bao gồm các thành phần như khung xe, động cơ, bánh xe, v.v. Mỗi thành phần trong hiệp hội cấu trúc đều đóng vai trò quan trọng và không thể thiếu trong cấu trúc tổng thể của đối tượng. Điều này khác với mối quan hệ tổng thể và bộ phận, trong đó các bộ phận có thể được thêm hoặc loại bỏ mà không ảnh hưởng đến cấu trúc tổng thể của đối tượng.

Một hiệp hội cấp bậc (aggregation hierarchy) là một loại quan hệ giữa các đối tượng trong cơ sở dữ liệu, mô tả mối quan hệ giữa một đối tượng và các đối tượng con của nó. Trong một hiệp hội cấp bậc, một đối tượng được gọi là 'phần' (part) và các đối tượng khác được gọi là 'tập hợp' (collection) của nó. Mối quan hệ giữa phần và tập hợp là một mối quan hệ 'tập hợp/phần' (whole/part), trong đó tập hợp bao gồm tất cả các phần. Ví dụ, một trường học có thể được xem là một tập hợp của các lớp học, và mỗi lớp học là một phần của trường học. Một hiệp hội cấp bậc thường được biểu diễn bằng một mối quan hệ một-đa nhiều (one-to-many), trong đó một phần có thể thuộc về nhiều tập hợp khác nhau.

Một đối tượng kiểm soát phụ thuộc vào trạng thái là một đối tượng có thể thay đổi hành vi của nó dựa trên trạng thái hiện tại của nó. Nó không chỉ đơn giản là thực thi một trạng thái máy mà còn có thể thay đổi trạng thái của nó dựa trên các điều kiện cụ thể. Ví dụ, một đối tượng kiểm soát có thể thay đổi hành vi của nó khi nó chuyển từ trạng thái "chưa hoạt động" sang trạng thái "hoạt động". Đối tượng kiểm soát này có thể thực thi một số hành động khác nhau dựa trên trạng thái hiện tại của nó, chẳng hạn như gửi tín hiệu đến một máy trạng thái khác hoặc thực thi một số hành động cụ thể.

Stereotype trong cấu trúc lớp là một khái niệm quan trọng trong lập trình hướng đối tượng. Nó giúp xác định đặc điểm chung của một lớp, bao gồm cả thuộc tính và hành vi. Mục đích chính của một stereotype là để dán nhãn một lớp theo tiêu chí cấu trúc lớp. Điều này cho phép các nhà phát triển xác định rõ ràng đặc điểm của lớp và tạo điều kiện thuận lợi cho việc thiết kế và triển khai hệ thống. Stereotype cũng giúp giảm thiểu sự nhầm lẫn và tăng cường tính nhất quán trong cấu trúc lớp.

Mô hình tương tác động là một khái niệm quan trọng trong thiết kế phần mềm. Mục đích chính của mô hình này là mô tả hành vi và tương tác giữa các đối tượng hoặc thành phần trong hệ thống. Nó giúp các nhà thiết kế phần mềm hiểu rõ cách các phần tử khác nhau trong hệ thống tương tác với nhau, tạo ra một hình ảnh tổng thể về hoạt động của hệ thống. Mô hình này thường được sử dụng để mô tả các giao tiếp giữa các lớp, các đối tượng và các thành phần khác nhau trong hệ thống. Nó giúp các nhà thiết kế phần mềm xác định các yêu cầu chức năng và giao tiếp của hệ thống, từ đó tạo ra một thiết kế phần mềm hiệu quả và dễ bảo trì.

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ả.

Đi đến phần Interaction Diagram trong các loại sơ đồ UML, chúng ta sẽ thấy có bốn loại chính. Trong đó có Sequence Diagram (Sơ đồ Chuỗi), Collaboration Diagram (Sơ đồ Hợp tác), Communication Diagram (Sơ đồ Liên lạc) và Activity Diagram (Sơ đồ Hoạt động). Tuy nhiên, Activity Diagram không phải là một loại Interaction Diagram. Thay vào đó, nó thuộc về loại Dynamic Model trong UML. Activity Diagram được sử dụng để mô tả các hoạt động và quy trình trong một hệ thống, trong khi Interaction Diagram được sử dụng để mô tả các tương tác giữa các đối tượng.

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.

Trong mô hình trạng thái, một hành động nhập (entry action) là một hành động được thực hiện khi trạng thái được vào. Nó thường được sử dụng để thực hiện các tác vụ cần thiết khi trạng thái được vào, chẳng hạn như khởi tạo dữ liệu, thiết lập trạng thái ban đầu, hoặc thực hiện các hành động khác cần thiết khi trạng thái được vào. Ví dụ, khi một người dùng đăng nhập vào ứng dụng, hành động nhập có thể được sử dụng để tải dữ liệu người dùng và thiết lập trạng thái đăng nhập. Hành động nhập thường được thực hiện một lần khi trạng thái được vào, và nó không được thực hiện lại khi trạng thái được rời.

Trong chiến lược mô hình hóa tương tác động lực tùy thuộc vào trạng thái, mục đích chính của việc xác định đối tượng biên (boundary object) là để xác định các đối tượng nhận đầu vào từ môi trường bên ngoài. Điều này giúp mô hình hóa các tương tác giữa các đối tượng phần mềm và môi trường bên ngoài, từ đó có thể xây dựng các mô hình phức tạp hơn. Việc xác định đối tượng biên cũng giúp phân biệt giữa các đối tượng phần mềm và môi trường bên ngoài, từ đó có thể thiết kế và phát triển các hệ thống phần mềm hiệu quả hơn.

Một tương tác phụ thuộc vào trạng thái là một khái niệm trong thiết kế người dùng, mô tả cách một đối tượng điều khiển (control object) thay đổi hành vi của nó dựa trên trạng thái hiện tại của người dùng hoặc hệ thống. Ví dụ, một nút bấm có thể thay đổi màu sắc hoặc kích thước khi người dùng di chuyển chuột qua nó. Điều này giúp người dùng hiểu rõ hơn về cách hệ thống phản ứng với các hành động của họ. Trong thiết kế người dùng, tương tác phụ thuộc vào trạng thái giúp tạo ra trải nghiệm người dùng thân thiện và dễ sử dụng hơn.

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ô hình kiến trúc phần mềm đóng vai trò quan trọng trong quá trình phát triển ứng dụng. Chúng cung cấp khung xương hoặc mẫu tổng thể cho kiến trúc phần mềm, giúp các nhà phát triển tạo ra một cấu trúc logic và tổ chức cho ứng dụng. Mô hình kiến trúc phần mềm giúp giảm thiểu sự phức tạp và tăng cường khả năng mở rộng, bảo trì và sửa lỗi. Chúng cũng giúp đảm bảo tính nhất quán và dễ dàng tích hợp với các thành phần khác trong hệ thống. Vì vậy, mô hình kiến trúc phần mềm đóng vai trò như một bản thiết kế tổng thể cho ứng dụng, giúp các nhà phát triển tạo ra một sản phẩm chất lượng cao và hiệu quả.

Khi mô hình hóa các kịch bản tương tác phụ thuộc vào trạng thái, điều cần thiết là phải đảm bảo sự nhất quán giữa sơ đồ giao tiếp và sơ đồ trạng thái. Điều này có thể đạt được bằng cách sử dụng cùng một thứ tự số liệu cho các tin nhắn và sự kiện trên cả hai sơ đồ. Việc này giúp đảm bảo rằng các sự kiện và tin nhắn được gửi và nhận theo cùng một thứ tự, từ đó giúp duy trì sự nhất quán trong mô hình. Điều này đặc biệt quan trọng khi mô hình hóa các kịch bản phức tạp, nơi mà sự kiện và tin nhắn được gửi và nhận trong một thứ tự cụ thể.

Một quan điểm cấu trúc về kiến trúc phần mềm là cách nhìn tổng quan về cấu trúc và tổ chức của các thành phần và kết nối giữa chúng trong hệ thống phần mềm. Quan điểm này tập trung vào việc mô tả các thành phần và mối quan hệ giữa chúng, giúp người lập trình viên hiểu rõ về cấu trúc và chức năng của hệ thống. Quan điểm này thường được biểu diễn dưới dạng các mô hình hoặc sơ đồ, giúp người lập trình viên dễ dàng theo dõi và hiểu rõ về cấu trúc của hệ thống.

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ột hệ thống giao diện người dùng (User Interface Subsystem) là một loại hệ thống phụ trách việc tương tác giữa người dùng và máy tính. Nó bao gồm các thành phần như giao diện đồ họa, nhập liệu và xuất liệu. Hệ thống này giúp người dùng tương tác với máy tính một cách dễ dàng và hiệu quả. Nó giống như một trung gian giữa người dùng và máy tính, giúp người dùng đưa ra yêu cầu và máy tính thực hiện yêu cầu đó. Ví dụ, khi người dùng nhập một lệnh vào giao diện đồ họa, hệ thống giao diện người dùng sẽ chuyển lệnh đó sang máy tính và máy tính sẽ thực hiện lệnh đó. Hệ thống giao diện người dùng rất quan trọng trong việc tạo ra một trải nghiệm người dùng tốt.

Khi phân chia hệ thống thành các phân hệ (subsystem), chúng ta cần xem xét các đối tượng có liên quan đến nhau và có thể được quản lý một cách hiệu quả trong cùng một phân hệ. Đối tượng có liên quan đến nhau có thể bao gồm các thành phần của một đối tượng phức hợp, các đối tượng có mối quan hệ chặt chẽ với nhau hoặc các đối tượng có cùng mục đích sử dụng. Ví dụ, trong một hệ thống bán hàng trực tuyến, các đối tượng như sản phẩm, giỏ hàng và hóa đơn có thể được quản lý trong cùng một phân hệ vì chúng đều liên quan đến quá trình mua bán. Ngược lại, các đối tượng như máy chủ, mạng và thiết bị đầu cuối có thể được quản lý trong các phân hệ khác nhau vì chúng phục vụ các mục đích khác nhau.

Khi nói về thừa kế trong lập trình, chúng ta biết rằng một lớp con (subclass) có thể thừa hưởng các thuộc tính và phương thức từ lớp cha (superclass). Tuy nhiên, có một số điều không được phép trong thừa kế. Trong các lựa chọn trên, câu trả lời đúng là "Subclass redefines attributes inherited from superclass.". Điều này có nghĩa là lớp con không được phép định nghĩa lại các thuộc tính đã được thừa hưởng từ lớp cha. Thay vào đó, lớp con có thể thêm mới các thuộc tính hoặc phương thức mới, hoặc sử dụng các thuộc tính và phương thức đã được thừa hưởng từ lớp cha mà không làm thay đổi chúng. Điều này giúp duy trì tính nhất quán và tính bảo mật trong mã nguồn.

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.

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.

Câu hỏi này yêu cầu bạn xác định phát biểu nào không đúng về kiến trúc phần mềm máy chủ. Các lựa chọn bao gồm: máy chủ là người yêu cầu dịch vụ, máy chủ là người cung cấp dịch vụ, một hệ thống phần mềm cung cấp một hoặc nhiều dịch vụ cho nhiều khách hàng, một hệ thống phần cứng cung cấp một hoặc nhiều dịch vụ cho nhiều khách hàng. Câu trả lời đúng là 'Máy chủ là người yêu cầu dịch vụ'. Vì máy chủ thực sự là người cung cấp dịch vụ cho các khách hàng, trong khi người yêu cầu dịch vụ là người sử dụng dịch vụ mà máy chủ cung cấp.

Mô hình kiến trúc cơ bản của một khách hàng/dịch vụ đơn (Client/Single Service) mô tả một hệ thống trong đó có nhiều khách hàng yêu cầu dịch vụ từ một dịch vụ duy nhất. Trong mô hình này, một dịch vụ cung cấp các dịch vụ cho nhiều khách hàng khác nhau. Điều này cho phép khách hàng truy cập vào các dịch vụ mà không cần phải tạo ra nhiều dịch vụ riêng biệt. Mô hình này thường được sử dụng trong các hệ thống có số lượng khách hàng lớn và cần cung cấp các dịch vụ giống nhau.

Một wrapper cơ sở dữ liệu (database wrapper) đóng vai trò quan trọng trong kiến trúc khách/hозяин (client/server). Nó là một lớp giao diện giữa ứng dụng khách (client) và cơ sở dữ liệu (database). Vai trò chính của một wrapper cơ sở dữ liệu là cung cấp một giao diện thống nhất để ứng dụng khách tương tác với cơ sở dữ liệu. Điều này giúp giảm thiểu sự phức tạp và tăng cường khả năng mở rộng của hệ thống. Wrapper cơ sở dữ liệu cũng có thể cung cấp các tính năng như kiểm tra lỗi, quản lý kết nối và tối ưu hóa truy vấn dữ liệu.

Một giao dịch phức hợp (compound transaction) là một chuỗi các hoạt động được thực hiện cùng một lúc. Để hiểu rõ hơn về giao dịch phức hợp, chúng ta cần biết rằng giao dịch phức hợp có thể được chia thành các giao dịch nguyên tử (atomic transaction). Mỗi giao dịch nguyên tử là một đơn vị nhỏ nhất của giao dịch phức hợp, và nó phải được thực hiện hoàn toàn hoặc không được thực hiện. Điều này đảm bảo rằng giao dịch phức hợp luôn được thực hiện một cách nhất quán và không bị ảnh hưởng bởi các sự cố ngoài ý muốn. Ví dụ, khi thực hiện giao dịch phức hợp, chẳng hạn như chuyển tiền từ tài khoản này sang tài khoản khác, giao dịch phức hợp có thể được chia thành hai giao dịch nguyên tử: giao dịch rút tiền từ tài khoản nguồn và giao dịch chuyển tiền vào tài khoản đích. Nếu bất kỳ giao dịch nguyên tử nào bị lỗi, giao dịch phức hợp sẽ được hủy bỏ để đảm bảo tính toàn vẹn của hệ thống.

Yellow pages brokering là một phương pháp hữu ích khi người yêu cầu dịch vụ biết loại dịch vụ cần thiết nhưng không biết dịch vụ cụ thể nào. Trong trường hợp này, người yêu cầu dịch vụ sẽ gửi yêu cầu đến một trung gian (broker) và trung gian sẽ tìm kiếm dịch vụ phù hợp để cung cấp cho người yêu cầu. Yellow pages brokering giúp người yêu cầu dịch vụ tiết kiệm thời gian và công sức trong việc tìm kiếm dịch vụ phù hợp.

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.

Một kết nối (connector) trong mô hình kiến trúc phần mềm là một thành phần quan trọng giúp liên kết các mô-đun hoặc thành phần khác nhau trong hệ thống. Nó đảm bảo rằng các mô-đun này có thể giao tiếp với nhau một cách hiệu quả. Khi nói đến việc kết nối, chúng ta thường nói đến việc liên kết các cổng (port) của các mô-đun khác nhau. Một cổng có thể được định nghĩa là một điểm giao tiếp giữa mô-đun và bên ngoài. Có hai loại cổng: cổng yêu cầu (required port) và cổng cung cấp (provided port). Cổng yêu cầu là cổng mà mô-đun yêu cầu để giao tiếp với bên ngoài, trong khi cổng cung cấp là cổng mà mô-đun cung cấp để giao tiếp với bên ngoài. Một kết nối sẽ liên kết cổng yêu cầu của một mô-đun với cổng cung cấp của mô-đun khác. Điều này giúp đảm bảo rằng các mô-đun có thể giao tiếp với nhau một cách hiệu quả và đúng đắn.

Tính chất giao tiếp của đăng ký/Thông báo là một thông điệp được gửi đến những người đã tham gia vào một nhóm. Điều này có nghĩa là thông điệp sẽ được gửi đến tất cả những người đã đăng ký hoặc tham gia vào nhóm đó, bất kể số lượng người nhận. Ví dụ, trong một hệ thống thông báo, khi có một sự kiện mới xảy ra, thông báo sẽ được gửi đến tất cả những người đã đăng ký nhận thông báo về sự kiện đó. Điều này giúp đảm bảo rằng thông tin được truyền đạt một cách nhanh chóng và hiệu quả đến những người cần biết.

Trong kiến trúc phần mềm dựa trên thành phần, một thành phần (component) được định nghĩa là một phần mềm tái sử dụng có thể được kết hợp lại để tạo thành các hệ thống phần mềm phức tạp. Thành phần là một đơn vị độc lập, có thể được phát triển, thử nghiệm và bảo trì riêng biệt. Nó có thể được sử dụng nhiều lần trong nhiều hệ thống khác nhau, giúp giảm thiểu thời gian và chi phí phát triển phần mềm. Thành phần thường được mô tả bằng các lớp (class) hoặc các hàm (function) trong ngôn ngữ lập trình, nhưng nó không chỉ giới hạn ở đó. Thành phần có thể bao gồm cả dữ liệu và các dịch vụ, và nó có thể được kết hợp lại để tạo thành các hệ thống phần mềm phức tạp.

Một nhiệm vụ kiểm soát (control task) là một phần mềm thực hiện một trạng thái cụ thể theo một sơ đồ trạng thái (statechart). Nó có thể được sử dụng để mô hình hóa các hành vi của một hệ thống, chẳng hạn như một thiết bị điện tử. Trong một hệ thống phân tán, một nhiệm vụ kiểm soát có thể được thực hiện bởi một module riêng biệt, chịu trách nhiệm quản lý các trạng thái của hệ thống. Điều này giúp tăng cường tính linh hoạt và dễ dàng mở rộng hệ thống. Ví dụ, một nhiệm vụ kiểm soát có thể được sử dụng để quản lý trạng thái của một hệ thống điều khiển nhiệt độ, nơi nó sẽ thực hiện các hành động khác nhau dựa trên các giá trị nhiệt độ khác nhau.

Mô hình kiến trúc Centralized Control là một trong những mô hình kiến trúc phổ biến trong lập trình. Trong mô hình này, tất cả các hoạt động kiểm soát và điều khiển của hệ thống được tập trung vào một điểm duy nhất. Điều này có nghĩa là hệ thống có một bộ phận kiểm soát trung tâm chịu trách nhiệm điều khiển và sắp xếp các hoạt động của hệ thống. Bộ phận kiểm soát trung tâm này sẽ quyết định khi nào và làm gì, và nó sẽ đảm bảo rằng tất cả các hoạt động của hệ thống được thực hiện theo đúng kế hoạch. Mô hình này thường được sử dụng trong các hệ thống có yêu cầu kiểm soát và điều khiển cao, chẳng hạn như hệ thống tự động hóa, hệ thống điều khiển nhiệt độ, v.v.

Một nhiệm vụ tương tác người dùng (user interaction task) là một loại nhiệm vụ trong hệ thống máy tính mà nó tương tác với người dùng. Nhiệm vụ này thường được sử dụng để thực hiện các hành động như nhập dữ liệu, hiển thị thông tin, hoặc yêu cầu người dùng thực hiện một hành động cụ thể. Trong hệ thống máy tính, nhiệm vụ tương tác người dùng thường được thực hiện bởi các phần mềm ứng dụng hoặc giao diện người dùng (GUI). Mục đích của nhiệm vụ tương tác người dùng là để cung cấp cho người dùng một cách tương tác trực tiếp với hệ thống máy tính, giúp họ dễ dàng sử dụng và quản lý hệ thống.

Một hệ thống nhân (kernel system) trong mô hình phân rã linh hoạt (SPL) là một thành phần quan trọng. Nó được định nghĩa là một thành viên của SPL chỉ bao gồm các lớp nhân (kernel classes). Các lớp nhân là các lớp cơ bản, không thể thiếu và không thể thay thế trong SPL. Chúng thường chứa các phương thức và thuộc tính cơ bản, cung cấp chức năng cơ bản cho SPL. Ngoài ra, một hệ thống nhân trong SPL cũng có thể bao gồm một số lớp mặc định (default classes), nhưng không thể bao gồm các lớp tùy chọn (optional classes) hoặc các lớp thực thể (entity classes). Vì vậy, đáp án đúng là: "Một thành viên của SPL được cấu tạo bởi các lớp nhân và có thể bao gồm một số lớp mặc định".

SPL (Software Product Line) là một phương pháp phát triển phần mềm cho phép tạo ra nhiều sản phẩm khác nhau dựa trên một tập hợp các thành phần chung. Một tính năng SPL (SPL feature) là một yêu cầu hoặc đặc điểm được cung cấp bởi một hoặc nhiều thành viên của SPL. Nó đại diện cho một tính năng hoặc khả năng cụ thể của sản phẩm, có thể được sử dụng để tạo ra các sản phẩm khác nhau. Ví dụ, trong một SPL cho các hệ thống quản lý thời tiết, một tính năng SPL có thể là khả năng dự báo thời tiết chính xác. Tính năng này có thể được cung cấp bởi một hoặc nhiều thành viên của SPL, chẳng hạn như một mô hình dự báo thời tiết hoặc một hệ thống cảnh báo thời tiết. Tính năng SPL giúp tạo ra sự linh hoạt và đa dạng trong sản phẩm, đồng thời giảm thiểu thời gian và chi phí phát triển.

Một trường hợp sử dụng tùy chọn trong SPL là trường hợp sử dụng có một số bước tùy chọn. Trong SPL, một trường hợp sử dụng tùy chọn là trường hợp sử dụng có một số bước có thể bỏ qua mà không ảnh hưởng đến chức năng chung của sản phẩm. Điều này cho phép các thành viên của dòng sản phẩm chọn bỏ qua các bước không cần thiết, từ đó giảm thiểu sự phức tạp và tăng cường linh hoạt trong việc phát triển sản phẩm. Ví dụ, một trường hợp sử dụng tùy chọn có thể là việc thêm chức năng nâng cao cho một sản phẩm cơ bản, nơi mà chức năng nâng cao chỉ cần thiết cho một số thành viên của dòng sản phẩm.

Testability là mức độ khả năng kiểm tra và đánh giá chất lượng của phần mềm trước khi triển khai. Nó đo lường khả năng của phần mềm trong việc được kiểm tra và xác minh trước khi được đưa vào sử dụng. Điều này bao gồm việc xác minh các yêu cầu chức năng, hiệu suất và bảo mật của phần mềm. Testability giúp đảm bảo rằng phần mềm hoạt động đúng và đáp ứng được yêu cầu của người dùng.

Tính chất Scalability trong phần mềm chất lượng là mức độ mà hệ thống có thể mở rộng sau khi được triển khai ban đầu. Điều này có nghĩa là hệ thống có thể đáp ứng được nhu cầu tăng trưởng của người dùng mà không cần phải thay đổi cơ bản. Ví dụ, một hệ thống có thể được thiết kế để xử lý 1000 người dùng và sau đó có thể mở rộng lên 10.000 người dùng mà không cần phải thay đổi cơ bản. Tính chất Scalability rất quan trọng trong phần mềm chất lượng vì nó giúp hệ thống trở nên linh hoạt và có thể đáp ứng được nhu cầu của người dùng.

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.