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

Các lớp giao diện người dùng đồ họa thường bao gồm các thành phần như menu, cửa sổ, nút bấm, v.v. Tuy nhiên, 'A pin' không phải là một thành phần giao diện người dùng đồ họa điển hình. Một 'A pin' thường được hiểu là một vật thể nhỏ được sử dụng để giữ hoặc cố định một vật thể khác, chẳng hạn như một bản đồ hoặc một bức ảnh. Vì vậy, 'A pin' không phải là một lớp giao diện người dùng đồ họa.

Đáp án đúng: B. Mô hình use case mô tả hành vi chức năng của hệ thống nhìn từ bên ngoài: các tác nhân là ai, họ cần hệ thống làm gì, và mỗi chức năng đem lại giá trị gì cho họ. Đây là mô hình của pha đặc tả yêu cầu, cố tình không nói tới cách hiện thực. A sai vì bố cục đối tượng thuộc mô hình tĩnh (sơ đồ lớp). C sai vì cấu trúc cơ sở dữ liệu là quyết định ở pha thiết kế, xuất hiện sau và không thuộc mô hình use case. D sai vì phụ thuộc giữa các thành phần được thể hiện bằng sơ đồ thành phần.

Mô hình thác nước (Waterfall model) là một phương pháp phát triển phần mềm truyền thống. Nó nhấn mạnh vào việc thực hiện các giai đoạn phát triển theo thứ tự tuần tự, mỗi giai đoạn phải hoàn thành trước khi chuyển sang giai đoạn tiếp theo. Điều này có nghĩa là các giai đoạn như lập kế hoạch, thiết kế, triển khai, kiểm thử và bảo trì sẽ được thực hiện theo thứ tự này. Mô hình thác nước không cho phép các thay đổi trong các giai đoạn đã hoàn thành, vì vậy nó đòi hỏi sự chính xác và hoàn hảo trong từng giai đoạn. Mặc dù mô hình thác nước đã lỗi thời, nhưng nó vẫn được sử dụng trong một số trường hợp cụ thể, chẳng hạn như các dự án phần mềm có yêu cầu nghiêm ngặt về bảo mật và tính ổn đị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.

Để xác định một lớp biên (boundary class) từ sơ đồ ngữ cảnh, bạn cần xem xét các lớp giao tiếp với các lớp bên ngoài. Các lớp biên thường là các lớp giao tiếp với các lớp bên ngoài, chẳng hạn như các lớp giao tiếp với người dùng, các lớp giao tiếp với cơ sở dữ liệu, v.v. Khi xem xét sơ đồ ngữ cảnh, bạn cần tìm kiếm các lớp giao tiếp với các lớp bên ngoài và xác định chúng là các lớp biên. Điều này giúp bạn hiểu rõ hơn về các lớp giao tiếp và các mối quan hệ giữa chúng.

Deployment Diagrams trong kiến trúc phần mềm là một công cụ quan trọng để mô tả và minh họa cấu trúc phân phối vật lý của các thành phần phần mềm. Mục đích chính của Deployment Diagrams là thể hiện cách các thành phần phần mềm được triển khai và phân phối trên các hệ thống và thiết bị khác nhau. Điều này giúp các nhà phát triển phần mềm hiểu rõ hơn về cấu trúc và tổ chức của hệ thống phần mềm, từ đó có thể dễ dàng quản lý và bảo trì hệ thống. Deployment Diagrams cũng giúp các nhà phát triển phần mềm xác định và giải quyết các vấn đề liên quan đến phân phối và triển khai phần mềm, chẳng hạn như vấn đề về hiệu suất, bảo mật và khả năng mở rộng.

Incremental software construction là một phương pháp xây dựng phần mềm, trong đó phần mềm được xây dựng theo từng bước nhỏ, từng phần. Mỗi bước nhỏ này được gọi là một "increment". Trong mỗi increment, các nhà phát triển sẽ thực hiện các công việc sau: thiết kế chi tiết, viết mã nguồn (coding) và kiểm tra đơn vị (unit testing) cho một phần nhỏ của hệ thống. Điều này giúp đảm bảo rằng mỗi phần nhỏ của hệ thống đều hoạt động đúng và có thể được tích hợp vào hệ thống lớn hơn một cách dễ dàng. Incremental software construction giúp giảm thiểu rủi ro và tăng cường hiệu suất trong quá trình phát triển 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.

Polymorphism và động kết hợp (dynamic binding) cho phép một đối tượng thực hiện các hành động khác nhau dựa trên loại của nó. Điều này có nghĩa là một đối tượng có thể thực hiện các phương thức khác nhau mặc dù nó được gọi bằng cùng một tên. Ví dụ, nếu bạn có một lớp Animal và một lớp Dog kế thừa từ Animal, bạn có thể tạo một đối tượng Dog và gọi phương thức bark() mà không cần phải biết rằng đối tượng đó là một Dog. Điều này cho phép bạn viết mã linh hoạt hơn và dễ dàng thêm mới các lớp con mà không cần phải thay đổi mã hiện có.

Một lớp thực thể (entity class) là lớp có chứa dữ liệu và phương thức liên quan đến dữ liệu đó. Nó là một phần quan trọng trong lập trình hướng đối tượng, giúp cô lập dữ liệu và phương thức, tạo điều kiện thuận lợi cho việc tái sử dụng và mở rộng mã nguồn. Ví dụ, lớp 'Khách hàng' có thể có các thuộc tính như 'tên', 'địa chỉ', 'số điện thoại' và các phương thức như 'thêm khách hàng', 'xóa khách hàng', 'cập nhật thông tin khách hàng'.

Sơ đồ truyền thông tích hợp là một loại sơ đồ truyền thông được tạo ra bằng cách kết hợp các đối tượng, nhưng nó không chỉ đơn giản là một sơ đồ truyền thông được tạo ra bằng cách kết hợp các đối tượng. Thay vào đó, nó là một tổng hợp của tất cả các sơ đồ truyền thông được phát triển để hỗ trợ các trường hợp sử dụng. Sơ đồ truyền thông tích hợp cung cấp một cái nhìn tổng quan về các đối tượng và mối quan hệ giữa chúng trong hệ thống, giúp các nhà phát triển hiểu rõ hơn về cách các đối tượng tương tác với nhau để đạt được các trường hợp sử dụng.

Câu hỏi này hỏi về kiểu kiến trúc nào tổ chức hệ thống thành các lớp trình bày, logic kinh doanh và dữ liệu. Kiểu kiến trúc được đề cập trong câu hỏi là Layered Architecture. Kiểu kiến trúc này chia hệ thống thành các lớp riêng biệt, mỗi lớp có một chức năng cụ thể. Lớp trình bày chịu trách nhiệm xử lý các yêu cầu từ người dùng, lớp logic kinh doanh thực hiện các quy trình kinh doanh và lớp dữ liệu quản lý dữ liệu của hệ thống. Kiểu kiến trúc này giúp hệ thống trở nên linh hoạt, dễ dàng bảo trì và mở rộng.

Một trạng thái máy là một mô hình toán học được sử dụng để mô tả các trạng thái và hành vi của một hệ thống. Để thực hiện một trạng thái máy, chúng ta cần một đối tượng có khả năng thay đổi trạng thái và thực hiện hành vi tương ứng. Đối tượng này được gọi là đối tượng phụ thuộc vào trạng thái. Đối tượng này có thể là một lớp, một đối tượng hoặc một module trong một chương trình. Nó có khả năng lưu trữ trạng thái hiện tại và thực hiện hành vi dựa trên trạng thái đó. Ví dụ, trong một trò chơi video, đối tượng phụ thuộc vào trạng thái có thể là một nhân vật, nó có thể thay đổi trạng thái từ "đang chạy" sang "đang dừng" và thực hiện hành vi tương ứng.

Trong hệ thống máy tính, các subsystem được phân loại thành hai loại chính: client và server. Subsystem client là phần mềm hoặc phần cứng chịu trách nhiệm yêu cầu dịch vụ từ subsystem server. Dưới đây là một số ví dụ về subsystem client và server: - Subsystem client: User interaction subsystem (phần mềm tương tác với người dùng), I/O subsystem (phần cứng hoặc phần mềm xử lý nhập/xuất dữ liệu). - Subsystem server: Service subsystem (phần mềm cung cấp dịch vụ cho subsystem khác). Vậy, subsystem nào không phải là subsystem client? Câu trả lời đúng là Service subsystem. Bởi vì Service subsystem cung cấp dịch vụ cho subsystem khác, chứ không phải là subsystem client.

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ục đích chính của việc ẩn thông tin trong thiết kế đối tượng là cho phép các nhà phát triển quyết định những thông tin nào nên được hiển thị và những thông tin nào nên được ẩn. Điều này giúp giảm thiểu sự phụ thuộc giữa các phần của đối tượng và tăng cường tính bảo mật. Thông qua việc ẩn thông tin, các nhà phát triển có thể kiểm soát cách thức mà các phần của đối tượng tương tác với nhau, từ đó tạo ra các đối tượng linh hoạt và dễ dàng bảo trì. Điều này cũng giúp giảm thiểu sự phức tạp của mã và tăng cường tính bảo mật của hệ thống.

Trong một sơ đồ lớp, tính riêng tư (ký hiệu bằng dấu trừ) chỉ ra rằng một thành phần chỉ có thể truy cập được từ bên trong lớp đó. Điều này có nghĩa là các lớp khác không thể truy cập trực tiếp vào thành phần đó, trừ khi nó được thừa kế hoặc sử dụng qua phương thức công cộng. Tính riêng tư giúp bảo vệ dữ liệu và ngăn chặn việc truy cập không mong muốn. Nó cũng giúp phân chia trách nhiệm và giảm thiểu sự phụ thuộc giữa các lớp. Trong thực tế, việc sử dụng tính riêng tư là một kỹ thuật quan trọng trong thiết kế lớp và giúp tạo ra các lớp dễ bảo trì, dễ hiểu và dễ sử dụng hơn.

Mô hình đàm phán (Negotiation pattern) cho phép hai bên trao đổi và thỏa thuận về một dịch vụ. Trong mô hình này, bên yêu cầu (client agent) có thể đề xuất một dịch vụ, và bên cung cấp (service agent) có thể đáp ứng yêu cầu đó bằng cách cung cấp dịch vụ. Tuy nhiên, bên cung cấp không thể tự động đề xuất dịch vụ cho bên yêu cầu mà không có yêu cầu trước đó. Vì vậy, câu trả lời đúng là "The service agent can offer a service in response to a client agent request."

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.