Ngân hàng câu hỏi của chương

Câu hỏi: CSI106 - Phần 12: Ngôn ngữ lập trình và kỹ nghệ phần mềm

49 câu trắc nghiệm kèm lời giải của môn Introduction to Computer Science - CSI106, xếp theo thứ tự nhập vào ngân hàng.

Danh sách câu hỏi

20/49 câuCòn 29
ADividing a project into small parts that are easier to manage.
BWriting code without documentation as whole but focus on documentation of small parts of the project.
CTesting the whole system at once.
DCombining all code into one large file.
Lời giải
Đáp án đúng: "Dividing a project into small parts that are easier to manage." Module hoá là nguyên tắc chia một hệ thống lớn thành nhiều phần nhỏ, mỗi phần đảm nhiệm một nhiệm vụ rõ ràng và giao tiếp với nhau qua giao diện hẹp, nhờ đó lượng chi tiết người lập trình phải nắm cùng lúc giảm xuống, công việc chia được cho nhiều người và mỗi phần sửa hay thay thế riêng được. Cách hiểu "Writing code without documentation as whole but focus on documentation of small parts of the project." lẫn sang chính sách viết tài liệu, trong khi module hoá nói về cấu trúc chương trình, và bỏ tài liệu mức tổng thể còn làm mất bức tranh kiến trúc. "Testing the whole system at once." đi ngược tinh thần module hoá, vì module hoá cho phép kiểm thử từng đơn vị trước khi ghép. "Combining all code into one large file." chính là thứ module hoá tránh: một khối mã khổng lồ không tách được trách nhiệm và rất khó bảo trì.
Mở trang câu hỏi này →
AFlexibility
BAccuracy
CEfficiency
DReliability
Lời giải
Đáp án đúng: "Flexibility". Khả năng vận hành của phần mềm được đo bằng những thuộc tính nhìn thấy khi chương trình đang chạy, còn tính linh hoạt là khả năng sửa đổi chương trình cho mục đích mới nên nó thuộc nhóm khả năng bảo trì chứ không thuộc nhóm vận hành. Tiêu chí "Accuracy" thuộc nhóm vận hành vì nó đo mức kết quả chương trình trả về đúng với yêu cầu. Tiêu chí "Efficiency" cũng là tiêu chí vận hành, đo lượng tài nguyên như thời gian xử lý và bộ nhớ mà chương trình tiêu tốn khi chạy. Tiêu chí "Reliability" là tiêu chí vận hành đo mức chương trình chạy ổn định, không sụp và không cho kết quả sai trong suốt thời gian sử dụng.
Mở trang câu hỏi này →
ATesting
BDesign
CAnalysis
DImplementation
Lời giải
Đáp án đúng: "Testing". Vòng đời phần mềm theo lối thác nước gồm bốn pha nối tiếp là phân tích, thiết kế, hiện thực và kiểm thử; kiểm thử đứng cuối vì chỉ khi đã có mã chạy được người ta mới kiểm được rằng sản phẩm đúng với yêu cầu đã phân tích và đúng với thiết kế. Pha "Design" là pha thứ hai, nơi hệ thống được chia thành module và định rõ giao diện giữa chúng, nhưng lúc đó chưa có gì chạy được để kiểm. Pha "Analysis" là pha mở đầu, làm rõ bài toán và yêu cầu của người dùng. Pha "Implementation" là pha thứ ba, viết mã theo thiết kế, và nó sinh ra chính thứ mà pha cuối sẽ đem kiểm.
Mở trang câu hỏi này →
A2
B3
C4
D5
Lời giải
Đáp án đúng: "4". Các ngôn ngữ máy tính được xếp vào bốn mô thức: thủ tục, hướng đối tượng, hướng hàm và khai báo theo logic. Mỗi mô thức là một cách nhìn khác nhau về việc chương trình là gì: dãy lệnh tác động lên dữ liệu, tập đối tượng tương tác với nhau, phép hợp của các hàm, hay tập sự kiện cùng luật suy diễn. Con số "2" chỉ phản ánh cách gộp thô thành nhóm ra lệnh và nhóm khai báo, không phải cách phân loại đang được hỏi. Con số "3" là đếm thiếu, bỏ sót một trong bốn nhóm kể trên. Con số "5" là đếm dư, vì các ngôn ngữ chuyên dụng như ngôn ngữ đánh dấu hay ngôn ngữ truy vấn được xét riêng chứ không được coi là một mô thức độc lập.
Mở trang câu hỏi này →
AIt structures programs as a sequence of instructions acting on passive data
BIt focuses on objects and their interactions
CIt defines functions based on mathematical logic
DIt allows programs to make decisions based on logical rules and focuses on objects
Lời giải
Đáp án đúng: "It structures programs as a sequence of instructions acting on passive data". Trong mô thức thủ tục, chương trình là một dãy lệnh mà máy thi hành lần lượt, còn dữ liệu nằm riêng và thụ động chờ các lệnh hay thủ tục tác động lên; người viết phải mô tả từng bước cần làm nên đây là lối lập trình ra lệnh. Mô tả "It focuses on objects and their interactions" là của mô thức hướng đối tượng, nơi dữ liệu và các phép toán trên nó được gói chung trong đối tượng. Mô tả "It defines functions based on mathematical logic" là của mô thức hướng hàm, nơi chương trình là phép hợp của các hàm. Mô tả "It allows programs to make decisions based on logical rules and focuses on objects" trộn đặc trưng của mô thức khai báo logic với đặc trưng hướng đối tượng nên không ứng với mô thức nào.
Mở trang câu hỏi này →
6Java is a(n) _____ language.4 lựa chọn
Aprocedural
Bfunctional
Cdeclarative
Dobject-oriented
Lời giải
Đáp án đúng: "object-oriented". Trong Java mọi đoạn mã đều phải nằm trong một lớp, chương trình được dựng từ các đối tượng có trạng thái riêng và phương thức riêng, và ngôn ngữ hỗ trợ sẵn kế thừa, đóng gói cùng đa hình, đó đúng là bộ đặc trưng của mô thức hướng đối tượng. Nhãn "procedural" ứng với những ngôn ngữ như C hay Pascal, nơi đơn vị tổ chức là hàm và thủ tục chứ không phải lớp. Nhãn "functional" ứng với các ngôn ngữ coi chương trình là phép hợp của các hàm không trạng thái; Java chỉ vay một ít cú pháp hàm chứ không dựa trên nền ấy. Nhãn "declarative" ứng với kiểu ngôn ngữ chỉ khai báo sự kiện và luật rồi để máy suy diễn, còn Java buộc người viết chỉ rõ từng bước thi hành.
Mở trang câu hỏi này →
AIts value is copied to the subprogram
BIt is shared with the subprogram
CIt is modified by the subprogram
DIt is destroyed after the subprogram call
Lời giải
Đáp án đúng: "Its value is copied to the subprogram". Khi truyền theo giá trị, hệ thống sao giá trị của biến thực tế vào tham số hình thức của chương trình con, nên chương trình con làm việc trên một bản sao nằm ở ô nhớ khác và mọi thay đổi bên trong chỉ tác động lên bản sao đó. Khả năng "It is shared with the subprogram" là đặc điểm của truyền theo tham chiếu, khi chương trình con nhận địa chỉ của biến gốc. Khả năng "It is modified by the subprogram" không xảy ra, vì sau khi chương trình con kết thúc thì biến ở chương trình chính vẫn giữ giá trị cũ. Khả năng "It is destroyed after the subprogram call" cũng không đúng, thứ bị giải phóng khi kết thúc lời gọi là bản sao cục bộ chứ không phải biến gốc.
Mở trang câu hỏi này →
AA class deriving properties from another class.
BProcedures calling other procedures in a program.
CA program interpreting each line of source code.
DUsing functions without side effects.
Lời giải
Đáp án đúng: "A class deriving properties from another class." Kế thừa là cơ chế cho một lớp con nhận lại thuộc tính và phương thức của lớp cha rồi bổ sung hoặc định nghĩa lại phần riêng, nhờ đó phần mô tả chung chỉ viết một lần và các lớp xếp được thành cây phân loại từ tổng quát đến cụ thể. Mô tả "Procedures calling other procedures in a program." chỉ là lời gọi thủ tục, chuyện thường ngày của lập trình thủ tục và không tạo ra quan hệ cha con giữa các kiểu. Mô tả "A program interpreting each line of source code." nói về cách thông dịch mã nguồn, thuộc chuyện dịch chương trình. Mô tả "Using functions without side effects." là đặc trưng của hàm thuần trong lập trình hàm, không liên quan tới quan hệ giữa các lớp.
Mở trang câu hỏi này →
ALexical analyzer
BSyntax analyzer
CSemantic analyzer
DCode generator
Lời giải
Đáp án đúng: "Lexical analyzer". Đây là pha đầu tiên của trình biên dịch: nó quét mã nguồn theo từng ký hiệu rồi gom các ký hiệu đó thành những đơn vị có nghĩa gọi là token, chẳng hạn từ khoá, tên biến, hằng số, dấu phép toán. Mục "Syntax analyzer" làm việc sau đó, nhận danh sách token đã có và dựng cây phân tích theo văn phạm của ngôn ngữ, nó không đọc từng ký tự thô. Mục "Semantic analyzer" kiểm tra ý nghĩa trên cây cú pháp, ví dụ biến đã khai báo chưa, kiểu dữ liệu có khớp nhau không. Mục "Code generator" nằm ở pha cuối, dịch dạng biểu diễn trung gian thành mã đích cho máy, hoàn toàn không liên quan đến việc tách token.
Mở trang câu hỏi này →
AThe completed code for the software.
BA specification document outlining what the software will do, not how
CA detailed architecture diagram of the system
DA plan for software testing and deployment
Lời giải
Đáp án đúng: "A specification document outlining what the software will do, not how". Pha phân tích trả lời câu hỏi hệ thống phải làm gì, kết quả là tài liệu đặc tả mô tả chức năng, dữ liệu vào ra và yêu cầu của người dùng, cố ý chưa chạm tới cách hiện thực. Mục "The completed code for the software." là sản phẩm của pha cài đặt, nằm sau hai pha nữa. Mục "A detailed architecture diagram of the system" trả lời câu hỏi làm thế nào, đó là đầu ra của pha thiết kế, nơi mới chia mô-đun và chọn cấu trúc. Mục "A plan for software testing and deployment" thuộc công việc kiểm thử và triển khai về sau; nếu để pha phân tích lo chuyện đó thì đặc tả chưa xong đã phải chốt cách làm, trái với trình tự của vòng đời phần mềm.
Mở trang câu hỏi này →
AThe degree of dependency between modules.
BThe number of lines of code in a module.
CThe speed of program execution.
DThe total number of coupled modules in a system.
Lời giải
Đáp án đúng: "The degree of dependency between modules." Coupling đo mức ràng buộc giữa các mô-đun: hai mô-đun càng phải biết nhiều về nhau, càng dùng chung nhiều dữ liệu hay gọi sâu vào nhau thì càng khó sửa và khó dùng lại, nên thiết kế tốt hướng tới coupling thấp đi kèm cohesion cao. Mục "The number of lines of code in a module." chỉ là thước đo kích thước, một mô-đun ngắn vẫn có thể bị ràng buộc chặt. Mục "The speed of program execution." nói về hiệu năng khi chạy, không phải tính chất của cấu trúc thiết kế. Mục "The total number of coupled modules in a system." chỉ đếm số lượng, trong khi coupling là mức độ phụ thuộc của từng liên kết, hai hệ thống có cùng số mô-đun liên quan vẫn có thể khác nhau rất xa về mức ràng buộc.
Mở trang câu hỏi này →
A2 phases: implementation and testing
B3 phases: design, implementation and testing
C4 phases: analysis, design, implementation and testing
D5 phases: planning, analysis, design, implementation and testing
Lời giải
Đáp án đúng: "4 phases: analysis, design, implementation and testing". Quá trình phát triển trong vòng đời phần mềm gồm bốn pha nối tiếp: phân tích để xác định phần mềm phải làm gì, thiết kế để quyết định làm thế nào và chia mô-đun, cài đặt để viết mã, kiểm thử để tìm lỗi so với đặc tả. Mục "2 phases: implementation and testing" bỏ mất cả phân tích và thiết kế, tức viết mã khi chưa biết yêu cầu. Mục "3 phases: design, implementation and testing" thiếu pha phân tích, trong khi chính pha này sinh ra tài liệu đặc tả làm căn cứ cho thiết kế và cho việc kiểm thử sau cùng. Mục "5 phases: planning, analysis, design, implementation and testing" thêm việc lập kế hoạch, thứ thuộc quản lý dự án và nằm trước quá trình phát triển, không phải một pha của nó.
Mở trang câu hỏi này →
AAssembly language
BHigh-level language
CMachine language
DObject-oriented language
Lời giải
Đáp án đúng: "Machine language". Thời kỳ đầu, muốn máy chạy thì phải nạp trực tiếp các mẫu bit mà bộ xử lý hiểu được, nghĩa là viết bằng chính ngôn ngữ máy của phần cứng đó, không có lớp dịch nào ở giữa. Mục "Assembly language" ra đời sau để thay mẫu bit bằng các từ gợi nhớ, nhưng vẫn cần một chương trình dịch hợp ngữ chuyển về mã máy, nên nó không thể có trước. Mục "High-level language" xuất hiện muộn hơn nữa, dùng câu lệnh gần ngôn ngữ tự nhiên và cần trình biên dịch. Mục "Object-oriented language" là một dòng của ngôn ngữ bậc cao, ra đời sau cùng trong bốn lựa chọn, khi người ta đã cần tổ chức chương trình lớn theo lớp và đối tượng.
Mở trang câu hỏi này →
AHigh-level languages
BSymbolic languages
CMachine language using binary patterns
DObject-oriented languages
Lời giải
Đáp án đúng: "Machine language using binary patterns". Ở buổi đầu của máy tính, mọi lệnh phải nạp trực tiếp dưới dạng các mẫu bit mà phần cứng giải mã được, người lập trình làm việc đúng theo tập lệnh của riêng chiếc máy đó. Mục "High-level languages" ra đời từ giữa thập niên 1950 trở đi, chúng cần trình biên dịch nên không thể có khi chưa có công cụ dịch nào. Mục "Symbolic languages" tức hợp ngữ, thay mẫu bit bằng các từ gợi nhớ, nhưng vẫn phải nhờ chương trình dịch hợp ngữ nên cũng xuất hiện sau. Mục "Object-oriented languages" là một dòng của ngôn ngữ bậc cao, ra đời muộn nhất khi người ta cần tổ chức chương trình lớn theo lớp và đối tượng.
Mở trang câu hỏi này →
15Which is not a high-level language?4 lựa chọn
ARuby
BC
CAssembly
DPascal
Lời giải
Đáp án đúng: "Assembly". Hợp ngữ là ngôn ngữ bậc thấp: mỗi câu lệnh gần như tương ứng một lệnh máy, người viết phải biết thanh ghi và tập lệnh của bộ xử lý, và mã viết cho kiến trúc này không chạy trên kiến trúc khác. Mục "Ruby" là ngôn ngữ bậc cao, cú pháp gần ngôn ngữ tự nhiên và che hết chi tiết phần cứng. Mục ghi tên ngôn ngữ «C» cũng là ngôn ngữ bậc cao, có kiểu dữ liệu, hàm và cấu trúc điều khiển; nó cho phép làm việc sát hệ thống hơn nhiều ngôn ngữ khác nhưng vẫn độc lập với kiến trúc máy và cần trình biên dịch. Mục "Pascal" là ngôn ngữ bậc cao có cấu trúc, lâu nay dùng để dạy lập trình. Dấu hiệu chung của ba mục đó là một câu lệnh sinh ra nhiều lệnh máy.
Mở trang câu hỏi này →
ABlack-box testing
BIntegration testing
CWhite-box testing
DUser acceptance testing
Lời giải
Đáp án đúng: "White-box testing". Kỹ thuật kiểm thử này mở mã nguồn ra để xem, dựa vào cấu trúc bên trong và luồng điều khiển để chọn ca kiểm thử, mục tiêu là đi qua hết câu lệnh, hết nhánh rẽ và hết các đường thực thi đáng kể. Mục "Black-box testing" làm ngược lại, nó chỉ dựa vào đặc tả và quan sát cặp dữ liệu vào ra, coi phần bên trong là kín. Mục "Integration testing" là một mức kiểm thử, lo việc ghép các mô-đun lại xem giao diện giữa chúng có khớp không, và mức này có thể thực hiện theo cả hai kỹ thuật nói trên. Mục "User acceptance testing" do người dùng tiến hành để nghiệm thu theo yêu cầu nghiệp vụ, càng không nhìn vào mã.
Mở trang câu hỏi này →
ARewriting code from scratch to improve performance
BAdding new features to existing software without changing its external behavior
COptimizing code to reduce memory usage
DRestructuring existing code to improve readability, maintainability, and efficiency
Lời giải
Đáp án đúng: "Restructuring existing code to improve readability, maintainability, and efficiency". Refactoring là việc sắp xếp lại cấu trúc bên trong của mã đã có — tách hàm, đổi tên định danh, gỡ đoạn trùng lặp — sao cho mã dễ đọc và dễ bảo trì hơn, trong khi hành vi quan sát được từ bên ngoài vẫn y nguyên. "Rewriting code from scratch to improve performance" là viết lại từ đầu, tức bỏ mã cũ chứ không cải tổ nó, và chỉ nhắm vào hiệu năng. "Adding new features to existing software without changing its external behavior" tự mâu thuẫn, bởi thêm tính năng chính là làm đổi hành vi bên ngoài, còn refactoring thì không thêm chức năng nào. "Optimizing code to reduce memory usage" chỉ tối ưu một chỉ số tài nguyên và nhiều khi làm mã khó đọc hơn, nên không phải mục đích của refactoring.
Mở trang câu hỏi này →
AWaterfall
BSpiral
CAgile
DPrototype
Lời giải
Đáp án đúng: "Waterfall". Mô hình thác nước chạy một chiều: phân tích xong mới sang thiết kế, thiết kế xong mới cài đặt, mỗi pha chỉ bắt đầu khi pha trước đã kết thúc trọn vẹn và không quay lui. "Spiral" lặp lại cả chuỗi pha qua nhiều vòng, mỗi vòng mở rộng sản phẩm và đánh giá rủi ro, nên các pha được làm lại nhiều lần. "Agile" chia việc thành nhiều chu kỳ ngắn, trong một chu kỳ vẫn vừa phân tích vừa viết mã vừa kiểm thử và chấp nhận yêu cầu thay đổi giữa đường. "Prototype" cố ý dựng bản mẫu nhanh cho người dùng xem rồi dựa vào phản hồi mà làm lại, tức quay về pha trước thay vì khoá pha đó lại.
Mở trang câu hỏi này →
Aanalysis
Bdesign
Cimplementation
Dtesting
Lời giải
Đáp án đúng: "design". Pha thiết kế là nơi trả lời câu hỏi làm thế nào: hệ thống được chia thành các module, từng thành phần được xác định rõ cùng giao diện giữa chúng và cấu trúc dữ liệu kèm theo, thường diễn đạt bằng sơ đồ cấu trúc và lưu đồ dữ liệu. "analysis" đi trước và chỉ xác định hệ thống phải làm gì — yêu cầu của người dùng, dữ liệu vào và ra — chứ chưa chỉ ra những thành phần nào tạo nên hệ thống. "implementation" nhận bản thiết kế đã có rồi viết mã cho từng thành phần, nên các thành phần buộc phải được định nghĩa từ trước. "testing" chỉ kiểm chứng rằng những thành phần đã dựng hoạt động đúng, không phải nơi khai sinh ra chúng.
Mở trang câu hỏi này →
AThe internal logical structure of a module
BThe reusability of a module in different projects.
CThe dependency between different modules, which should be minimized
DThe efficiency of a module's execution.
Lời giải
Đáp án đúng: "The dependency between different modules, which should be minimized". Coupling đo mức ràng buộc giữa các module với nhau: càng phụ thuộc nhiều thì sửa một chỗ càng dễ làm vỡ chỗ khác, vì vậy thiết kế tốt hướng tới coupling thấp đi kèm cohesion cao. "The internal logical structure of a module" nói về bên trong một module, đó là phạm vi của cohesion chứ không phải quan hệ giữa các module. "The reusability of a module in different projects." là kết quả thu được khi coupling đã thấp, không phải định nghĩa của chính coupling. "The efficiency of a module's execution." thuộc về hiệu năng lúc chạy, một chỉ số hoàn toàn khác với mức lệ thuộc trong thiết kế.
Mở trang câu hỏi này →