Tổ chức Baccalaureate Quốc tế · IB Diploma · Computer Science · SL

Trọng tâm SL được hỗ trợ. Mục tiêu đánh giá đầu tiên 2027; PDF chính thức trả về 403; tài liệu ngắn thu thập trước đó là bài đánh giá cuối cùng 2026. Hướng dẫn còn lại, yêu cầu đánh giá và thực hành giữ nguyên các bản ghi đã lưu.

Yêu cầu tiên quyết: đọc các đại lượng và đơn vị được nêu, sử dụng phép tính toán và các điều kiện mô hình dưới đây. Mỗi bài học sẽ phát triển phương pháp riêng trước khi chuyển giao độc lập.

Đây là các ví dụ giảng dạy gốc hoặc được ghi rõ là hư cấu, không phải là các phép đo thực tế hay các nghiên cứu đánh giá học viên đã hoàn tất.

Giải thích hiện tượng này là gì?

• Một hệ thống đặt phòng của trường học có thể tính toán chính xác nhưng vẫn thất bại nếu người dùng mất quyền truy cập hoặc hồ sơ bị tiết lộ. Thành công bao gồm cả bối cảnh của hệ thống.
• Bắt đầu bằng một dự đoán. Nêu rõ các đại lượng hoặc đặc điểm bạn sẽ so sánh, sau đó quyết định bằng chứng nào có thể phân biệt hai lời giải thích.

Xây dựng mô hình

• Một hệ thống máy tính kết hợp phần cứng, phần mềm, dữ liệu và con người. Một mạng cho phép giao tiếp thông qua các giao thức. Yêu cầu nên phân biệt chức năng khỏi các ràng buộc như khả năng sẵn sàng, bảo mật và khả năng truy cập.
• Xác thực (authentication): Kiểm tra danh tính được tuyên bố; Phân quyền (authorization): Xác định các hành động được phép thực hiện.

Chọn bằng chứng để kiểm định mô hình

• Tách biệt xác thực và phân quyền. Xác thực kiểm tra danh tính; phân quyền xác định các hành động được phép. Mô hình mối đe dọa kết nối một tài sản có giá trị, một cuộc tấn công có thể xảy ra và một biện pháp kiểm soát phù hợp.
• Sử dụng tập dữ liệu trường học giả định để xác định người dùng và quyền hạn. Vẽ luồng dữ liệu, so sánh validation (kiểm chứng) và verification (xác nhận), và chỉ định các bài kiểm tra cho đầu vào bình thường, biên và không hợp lệ. Không sử dụng thông tin đăng nhập thật hay hồ sơ học sinh trong bài tập.

Bắt đầu từ các đại lượng đã biết

• Nêu các giá trị đã biết và đơn vị của chúng. Chọn công thức vì các giả thiết của nó phù hợp với trường hợp này, sau đó biến đổi trước khi thay số.
• Đã biết: một tệp chứa 12 megabytes, trong ví dụ này một megabyte được định nghĩa là một triệu byte. Số bit = số byte × 8 = 12 × 1,000,000 × 8 = 96,000,000 bit. Ở tốc độ 8,000,000 bit mỗi giây, thời gian lý tưởng = kích thước/tốc độ = 12 giây, trừ đi phần chi phí vận hành (overhead).

Ví dụ:

Một tệp 40 triệu bit được truyền ở tốc độ 5 triệu bit mỗi giây. Tìm thời gian lý tưởng. Sử dụng cùng trình tự: đại lượng đã biết → mô hình → mối liên hệ → thay thế → đơn vị và giải thích.

Kiểm tra kết luận và giới hạn của nó

• Bandwidth không phải là throughput (tốc độ truyền tải) thực tế cuối đến cuối. Mã hóa không tự nó đảm bảo phân quyền đúng đắn hay loại bỏ mọi rủi ro bảo mật.
• Quay trở lại quan sát ban đầu. Giải thích kết quả hỗ trợ điều gì, những điều kiện nào mà nó giả định, và một cách để kiểm chứng một giải thích cạnh tranh.

Cảnh báo:

Mã hóa đảm bảo rằng mọi người dùng đều có quyền truy cập phù hợp. Tuyên bố này là sai: Bandwidth không phải là throughput thực tế cuối đến cuối. Mã hóa không tự nó đảm bảo phân quyền đúng đắn hay loại bỏ mọi rủi ro bảo mật.

Tóm tắt:

Hệ thống máy tính, mạng và yêu cầu: Tách biệt xác thực và phân quyền. Xác thực kiểm tra danh tính; phân quyền xác định các hành động được phép. Mô hình mối đe dọa kết nối một tài sản có giá trị, một cuộc tấn công có thể xảy ra và một biện pháp kiểm soát phù hợp.

Chuỗi thực thi chạy được và ranh giới

size_MB, rate_Mbps = 20, 10
bits = size_MB * 1_000_000 * 8
if rate_Mbps <= 0:
    raise ValueError("Rate must be positive")
seconds = bits / (rate_Mbps * 1_000_000)
print(seconds)
print(0 / (rate_Mbps * 1_000_000))

Kết quả mong đợi:

16.0
0.0

Decimal MB nghĩa là một triệu byte; nhân với tám trước khi chia cho bit mỗi giây. Dữ liệu bằng không có thời gian truyền tải lý tưởng bằng không. Tốc độ không dương bị từ chối; chi phí vận hành thực tế nằm ngoài mô hình toán học này.

Trọng tâm SL được hỗ trợ. Mục tiêu đánh giá đầu tiên 2027; PDF chính thức trả về 403; tài liệu ngắn thu thập trước đó là bài đánh giá cuối cùng 2026. Hướng dẫn còn lại, yêu cầu đánh giá và thực hành giữ nguyên các bản ghi đã lưu.

Yêu cầu tiên quyết: đọc các đại lượng và đơn vị được nêu, sử dụng phép tính toán và các điều kiện mô hình dưới đây. Mỗi bài học sẽ phát triển phương pháp riêng trước khi chuyển giao độc lập.

Đây là các ví dụ giảng dạy gốc hoặc được ghi rõ là hư cấu, không phải là các phép đo thực tế hay các nghiên cứu đánh giá học viên đã hoàn tất.

Giải thích hiện tượng này là gì?

• Một tin nhắn nhỏ có thể đến trễ trên đường truyền có băng thông cao. Dung lượng và độ trễ đo lường các thuộc tính khác nhau.
• Bắt đầu bằng một dự đoán. Nêu rõ các đại lượng hoặc đặc điểm bạn sẽ so sánh, sau đó quyết định bằng chứng nào có thể phân biệt hai lời giải thích.

Xây dựng mô hình

• Các gói tin mang dữ liệu có địa chỉ đi qua mạng. Mô hình phân lớp tách biệt các trách nhiệm như ý nghĩa ứng dụng, giao vận vận chuyển và định tuyến mạng. Bandwidth mô tả dung lượng; throughput là tốc độ dữ liệu đạt được; latency là độ trễ.
• Throughput: Tốc độ truyền dữ liệu có ích đạt được; Latency: Độ trễ cảm nhận được trong quá trình giao tiếp.

Chọn bằng chứng để kiểm định mô hình

• Thời gian truyền phụ thuộc vào kích thước dữ liệu và tốc độ. Độ trễ tổng cộng cũng có thể bao gồm lan truyền, xử lý và xếp hàng. Mã hóa bảo vệ nội dung theo các giả định của nó nhưng không loại bỏ tình trạng tắc nghẽn hay mọi sự lộ thông tin metadata.
• Theo dõi tuyến đường tin nhắn bằng cách sử dụng mô hình địa phương đã được tài liệu hóa. Ghi lại kích thước payload, đơn vị và thời gian đo được. Sử dụng mạng do nhà trường phê duyệt và tin nhắn tổng hợp; không quét hoặc chặn lưu lượng người dùng khác.

Bắt đầu từ các đại lượng đã biết

• Nêu các giá trị đã biết và đơn vị của chúng. Chọn công thức vì các giả thiết của nó phù hợp với trường hợp này, sau đó biến đổi trước khi thay số.
• Đã biết: một tệp 8 megabit đi qua liên kết 2 megabit/s. Thời gian truyền lý tưởng = kích thước/tốc độ = 8/2 = 4 s. Chi phí giao thức, người dùng khác và độ trễ có thể khiến thời gian hoàn thành quan sát được chậm hơn.

Ví dụ:

Một tệp 12 megabit đi qua liên kết 3 megabit/s. Tính thời gian truyền lý tưởng. Sử dụng cùng trình tự: đại lượng đã biết → mô hình → mối quan hệ → thay thế → đơn vị và diễn giải.

Kiểm tra kết luận và giới hạn của nó

• Một megabyte là tám megabits trước khi tính đến chi phí giao thức. Một liên kết có tốc độ định danh cao hơn không đảm bảo độ trễ thấp hoặc điểm cuối an toàn.
• Quay trở lại quan sát ban đầu. Giải thích kết quả hỗ trợ điều gì, những điều kiện nào mà nó giả định, và một cách để kiểm chứng một giải thích cạnh tranh.

Cảnh báo:

Kết nối băng thông rộng đảm bảo độ trễ bằng không. Tuyên bố này là sai: Một megabyte là tám megabits trước khi tính đến chi phí giao thức. Một liên kết có tốc độ định danh cao hơn không đảm bảo độ trễ thấp hoặc điểm cuối an toàn.

Tóm tắt:

Mạng: độ trễ, băng thông và giao nhận theo lớp: Thời gian truyền phụ thuộc vào kích thước dữ liệu và tốc độ. Độ trễ tổng cộng cũng có thể bao gồm lan truyền, xử lý và xếp hàng. Mã hóa bảo vệ nội dung theo các giả định của nó nhưng không loại bỏ tình trạng tắc nghẽn hay mọi sự lộ thông tin metadata.

Chuỗi thực thi chạy được và ranh giới

size_Mb, rate_Mbps, propagation_s = 12, 3, 0.10
for rate in [rate_Mbps, 2 * rate_Mbps]:
    transmission_s = size_Mb / rate
    print(round(transmission_s + propagation_s, 2))

Kết quả mong đợi:

4.1
2.1

Đo từ thời điểm bắt đầu truyền đến lúc bit cuối cùng đến nơi. Thời gian truyền serial và độ trễ lan truyền cộng lại dưới mô hình lý tưởng này. Tăng băng thông chỉ thay đổi số hạng đầu tiên; các bước lưu-truyền và hàng chờ sẽ thêm các số hạng nữa.

Trọng tâm SL được hỗ trợ. Mục tiêu đánh giá đầu tiên 2027; PDF chính thức trả về 403; tài liệu ngắn thu thập trước đó là bài đánh giá cuối cùng 2026. Hướng dẫn còn lại, yêu cầu đánh giá và thực hành giữ nguyên các bản ghi đã lưu.

Yêu cầu tiên quyết: đọc các đại lượng và đơn vị được nêu, sử dụng phép tính toán và các điều kiện mô hình dưới đây. Mỗi bài học sẽ phát triển phương pháp riêng trước khi chuyển giao độc lập.

Đây là các ví dụ giảng dạy gốc hoặc được ghi rõ là hư cấu, không phải là các phép đo thực tế hay các nghiên cứu đánh giá học viên đã hoàn tất.

Giải thích hiện tượng này là gì?

• sao chép địa chỉ người dùng trong mỗi đơn hàng có thể tạo ra hồ sơ mâu thuẫn khi địa chỉ thay đổi.
• Bắt đầu bằng một dự đoán. Nêu rõ các đại lượng hoặc đặc điểm bạn sẽ so sánh, sau đó quyết định bằng chứng nào có thể phân biệt hai lời giải thích.

Xây dựng mô hình

• Một bảng quan hệ chứa các hàng và thuộc tính. Khóa chính xác định một hàng; khóa ngoại liên kết đến khóa được tham chiếu trong bảng khác. Chuẩn hóa có thể giảm thiểu trùng lặp không cần thiết và bất thường cập nhật trong khi vẫn giữ được các mối quan hệ có ý nghĩa.
• Khóa chính: Tập thuộc tính xác định duy nhất một hàng trong bảng; Khóa ngoại: Tập thuộc tính tham chiếu đến khóa trong bảng khác.

Chọn bằng chứng để kiểm định mô hình

• Một phép join (nối) kết hợp các hàng theo điều kiện đã chỉ định. Số lượng kết quả phụ thuộc vào tính đơn cardinality của mối quan hệ và bộ lọc. Ràng buộc khóa ngoại áp đặt quy tắc mối quan hệ; nó không tự động mã hóa dữ liệu cá nhân.
• Thiết kế một tập dữ liệu đơn giản tổng hợp người dùng-đơn hàng không chứa thông tin cá nhân thật. Khai báo khóa, kiểm tra chèn trùng lặp và thiếu tham chiếu, sau đó đối chiếu kết quả truy vấn với bảng dự kiến đã tính tay.

Bắt đầu từ các đại lượng đã biết

• Nêu các giá trị đã biết và đơn vị của chúng. Chọn công thức vì các giả thiết của nó phù hợp với trường hợp này, sau đó biến đổi trước khi thay số.
• Đã biết: bốn khách hàng có tương ứng 2, 0, 3 và 1 đơn hàng. Phép inner join từ khách hàng sang đơn hàng trả về 2+0+3+1 = 6 hàng. Phép left join cũng giữ lại khách hàng không có đơn hàng như một hàng khớp null, cho ra 7 ở đây.

Ví dụ:

Ba khách hàng có 1, 3 và 2 đơn hàng. Phép inner join giữa khách hàng và đơn hàng sẽ trả về bao nhiêu hàng? Sử dụng cùng trình tự: đại lượng đã biết → mô hình → mối quan hệ → thay thế → đơn vị và diễn giải.

Kiểm tra kết luận và giới hạn của nó

• Khóa chính không nhất thiết phải là tên người. Một phép join không phải là sự nối đơn giản của các bảng. Sử dụng truy vấn tham số hóa cho đầu vào không đáng tin cậy thay vì xây dựng SQL từ chuỗi thô.
• Quay trở lại quan sát ban đầu. Giải thích kết quả hỗ trợ điều gì, những điều kiện nào mà nó giả định, và một cách để kiểm chứng một giải thích cạnh tranh.

Cảnh báo:

Khóa ngoại tự động mã hóa mọi hàng. Tuyên bố này là sai: Khóa chính không nhất thiết phải là tên người. Một phép join không phải là sự nối đơn giản của các bảng. Sử dụng truy vấn tham số hóa cho đầu vào không đáng tin cậy thay vì xây dựng SQL từ chuỗi thô.

Tóm tắt:

Cơ sở dữ liệu quan hệ: khóa và mối quan hệ: Một phép join (nối) kết hợp các hàng theo điều kiện đã chỉ định. Số lượng kết quả phụ thuộc vào tính đơn cardinality của mối quan hệ và bộ lọc. Ràng buộc khóa ngoại áp đặt quy tắc mối quan hệ; nó không tự động mã hóa dữ liệu cá nhân.

Chuỗi thực thi chạy được và ranh giới

import sqlite3
db = sqlite3.connect(":memory:")
db.executescript("""CREATE TABLE c(id INTEGER PRIMARY KEY);
CREATE TABLE o(id INTEGER PRIMARY KEY, cid INTEGER);
INSERT INTO c VALUES(1),(2),(3);
INSERT INTO o VALUES(10,1),(11,1),(12,3);""")
for kind in ["INNER", "LEFT"]:
    sql = f"SELECT COUNT(*),COUNT(o.id) FROM c {kind} JOIN o ON c.id=o.cid"
    print(kind, db.execute(sql).fetchone())
db.close()

Kết quả mong đợi:

INNER (3, 3)
LEFT (4, 3)

Left join giữ lại customer 2 với các trường order là null. COUNT(*) bao gồm dòng đó, trong khi COUNT(o.id) loại bỏ null. Khóa chính phân biệt các bản ghi; số lượng khách hàng không phải là số lượng đơn hàng. Từ khóa join được nội suy đến từ một danh sách cố định bên trong, không phải từ đầu vào người dùng.

Trọng tâm SL được hỗ trợ. Mục tiêu đánh giá đầu tiên 2027; PDF chính thức trả về 403; tài liệu ngắn thu thập trước đó là bài đánh giá cuối cùng 2026. Hướng dẫn còn lại, yêu cầu đánh giá và thực hành giữ nguyên các bản ghi đã lưu.

Yêu cầu tiên quyết: đọc các đại lượng và đơn vị được nêu, sử dụng phép tính toán và các điều kiện mô hình dưới đây. Mỗi bài học sẽ phát triển phương pháp riêng trước khi chuyển giao độc lập.

Đây là các ví dụ giảng dạy gốc hoặc được ghi rõ là hư cấu, không phải là các phép đo thực tế hay các nghiên cứu đánh giá học viên đã hoàn tất.

Giải thích hiện tượng này là gì?

• Một mô hình có thể đạt điểm cao bằng cách học một lối tắt trong dữ liệu huấn luyện. Đánh giá phải kiểm tra nhiệm vụ mong muốn trên các ví dụ chưa thấy phù hợp.
• Bắt đầu bằng một dự đoán. Nêu rõ các đại lượng hoặc đặc điểm bạn sẽ so sánh, sau đó quyết định bằng chứng nào có thể phân biệt hai lời giải thích.

Xây dựng mô hình

• Cơ sở dữ liệu quan hệ sử dụng bảng, khóa và mối quan hệ để tổ chức dữ liệu. Học máy ước lượng các mẫu từ dữ liệu. Dữ liệu huấn luyện và đánh giá phục vụ các vai trò khác nhau.
• Khóa chính: Tập thuộc tính xác định duy nhất một bản ghi; Rò rỉ dữ liệu: Sử dụng thông tin không khả dụng ở thời điểm dự kiến ban đầu.

Chọn bằng chứng để kiểm định mô hình

• Khóa chính xác định duy nhất một bản ghi; khóa ngoại liên kết các bản ghi. Trong dự đoán, rò rỉ có thể tiết lộ thông tin không khả dụng tại thời điểm ra quyết định thực tế. Độ chính xác đơn thuần có thể che giấu sự phân bố mục tiêu mất cân bằng.
• Sử dụng các bản đặt phòng giả để xác định các thực thể, thuộc tính và mối quan hệ. Đối với bài tập học tập, hãy sử dụng tập dữ liệu công khai không nhạy cảm, tách biệt dữ liệu huấn luyện và kiểm tra, đồng thời mô tả những ai có thể bị ảnh hưởng bởi lỗi sai. Phạm vi mục tiêu CS 2027 hiện tại đang chờ hướng dẫn đã thu thập.

Bắt đầu từ các đại lượng đã biết

• Nêu các giá trị đã biết và đơn vị của chúng. Chọn công thức vì các giả thiết của nó phù hợp với trường hợp này, sau đó biến đổi trước khi thay số.
• Đã biết: một bộ phân loại đưa ra 90 dự đoán đúng trong số 100 trường hợp. Độ chính xác = đúng/tổng × 100 = 90%. Nếu 90 trường hợp thuộc về một lớp, việc luôn dự đoán lớp đó sẽ cho cùng độ chính xác nhưng vẫn có thể thất bại ở mọi trường hợp của lớp thiểu số.

Ví dụ:

Một mô hình đưa ra 72 dự đoán đúng từ tổng số 80. Tìm phần trăm độ chính xác. Sử dụng cùng trình tự: đại lượng đã biết → mô hình → mối quan hệ → thay thế → đơn vị và diễn giải.

Kiểm tra kết luận và giới hạn của nó

• Độ chính xác cao không phải là bằng chứng về sự công bằng hay hiểu biết nguyên nhân. Một khóa chính cơ sở dữ liệu không đơn giản chỉ là bất kỳ trường nào trông có vẻ quan trọng.
• Quay trở lại quan sát ban đầu. Giải thích kết quả hỗ trợ điều gì, những điều kiện nào mà nó giả định, và một cách để kiểm chứng một giải thích cạnh tranh.

Cảnh báo:

Một bộ phân loại có độ chính xác 90% phải xử lý tốt tất cả các lớp như nhau. Tuyên bố này là sai: Độ chính xác cao không phải là bằng chứng về sự công bằng hay hiểu biết nguyên nhân. Một khóa chính cơ sở dữ liệu không đơn giản chỉ là bất kỳ trường nào trông có vẻ quan trọng.

Tóm tắt:

Mô hình dữ liệu và học máy có trách nhiệm: Một khóa chính xác định duy nhất một bản ghi; khóa ngoại liên kết các bản ghi. Trong dự đoán, rò rỉ có thể tiết lộ thông tin không khả dụng tại thời điểm ra quyết định thực tế. Độ chính xác đơn thuần có thể che giấu sự phân bố mục tiêu mất cân bằng.

Chuỗi thực thi chạy được và ranh giới

tp, fn, fp, tn = 4, 1, 10, 85
total = tp + fn + fp + tn
accuracy = (tp + tn) / total
recall = tp / (tp + fn) if tp + fn else None
print(accuracy, recall)
positives = 0
print(0 / positives if positives else "UNDEFINED")

Kết quả mong đợi:

0.89 0.8
UNDEFINED

Độ chính xác chia số dự đoán đúng cho tất cả các trường hợp; recall dương chia số true positives cho tổng số thực tế là dương. Với không có trường hợp dương nào, recall là vô định chứ không phải bằng không. Tập dữ liệu là giả định, không có mô hình đã huấn luyện hay dữ liệu cá nhân nào.

Trọng tâm SL được hỗ trợ. Mục tiêu đánh giá đầu tiên 2027; PDF chính thức trả về 403; tài liệu ngắn thu thập trước đó là bài đánh giá cuối cùng 2026. Hướng dẫn còn lại, yêu cầu đánh giá và thực hành giữ nguyên các bản ghi đã lưu.

Yêu cầu tiên quyết: đọc các đại lượng và đơn vị được nêu, sử dụng phép tính toán và các điều kiện mô hình dưới đây. Mỗi bài học sẽ phát triển phương pháp riêng trước khi chuyển giao độc lập.

Đây là các ví dụ giảng dạy gốc hoặc được ghi rõ là hư cấu, không phải là các phép đo thực tế hay các nghiên cứu đánh giá học viên đã hoàn tất.

Giải thích hiện tượng này là gì?

• Một thuật toán có thể hoạt động tốt với một ví dụ nhưng thất bại ở biên. Việc thử nghiệm nên được thiết kế dựa trên yêu cầu, không chỉ dựa trên đường dẫn thành công (happy path).
• Bắt đầu bằng một dự đoán. Nêu rõ các đại lượng hoặc đặc điểm bạn sẽ so sánh, sau đó quyết định bằng chứng nào có thể phân biệt hai lời giải thích.

Xây dựng mô hình

• Một thuật toán là một thủ tục hữu hạn, không mơ hồ cho một tác vụ. Một bản theo dõi (trace) ghi lại các thay đổi trạng thái. Một bất biến vòng lặp mô tả một đặc tính được bảo toàn qua mỗi lần lặp và giúp chứng minh tính đúng đắn.
• Thuật toán: Một quy trình hữu hạn giải quyết một nhiệm vụ được nêu rõ; Kiểm tra biên: Một bài kiểm tra tại giới hạn của phạm vi đầu vào được cho phép.

Chọn bằng chứng để kiểm định mô hình

• Nêu điều kiện đầu vào và đầu ra mong đợi. Sử dụng các trường hợp biên, tập rỗng khi được phép, các giá trị trùng lặp và không hợp lệ. Phân biệt thuật toán sai với việc triển khai sai hoặc yêu cầu chưa đầy đủ.
• Theo dõi quá trình tìm kiếm trên một danh sách sắp xếp giả nhỏ. Nêu quy ước đánh chỉ số. Đối với tìm kiếm nhị phân, cập nhật các cận sao cho khoảng còn lại thu hẹp lại và từ chối đầu vào không sắp xếp trừ khi việc sắp xếp là một phần của tác vụ.

Bắt đầu từ các đại lượng đã biết

• Nêu các giá trị đã biết và đơn vị của chúng. Chọn công thức vì các giả thiết của nó phù hợp với trường hợp này, sau đó biến đổi trước khi thay số.
• Đã biết: tìm kiếm tuyến tính trên danh sách tám phần tử có thể yêu cầu tám phép so sánh khi phần tử cần tìm nằm ở cuối hoặc không tồn tại. Nhân đôi độ dài danh sách sẽ làm tăng gấp đôi số phép so sánh trong trường hợp xấu nhất theo mô hình này. Tìm kiếm nhị phân giảm khoảng cách đi khoảng một nửa mỗi bước nhưng yêu cầu cấu trúc thứ tự phù hợp.

Ví dụ:

Một tìm kiếm tuyến tính quét hết tất cả 14 phần tử mà không tìm thấy khớp. Có bao nhiêu phép so sánh phần tử xảy ra? Sử dụng cùng trình tự: đại lượng đã biết → mô hình → mối quan hệ → thay thế → đơn vị và diễn giải.

Kiểm tra kết luận và giới hạn của nó

• Một thử nghiệm mẫu thành công không chứng minh tính đúng đắn đối với tất cả các đầu vào hợp lệ. Không đưa cú pháp giả mã cụ thể của Cambridge vào chương trình IB nếu không có nguồn gốc từ khóa học.
• Quay trở lại quan sát ban đầu. Giải thích kết quả hỗ trợ điều gì, những điều kiện nào mà nó giả định, và một cách để kiểm chứng một giải thích cạnh tranh.

Cảnh báo:

Một thử nghiệm mẫu thành công chứng minh thuật toán đúng đắn đối với mọi đầu vào hợp lệ. Tuyên bố này là sai: Một thử nghiệm mẫu thành công không chứng minh tính đúng đắn đối với tất cả các đầu vào hợp lệ. Không đưa cú pháp giả mã cụ thể của Cambridge vào chương trình IB nếu không có nguồn gốc từ khóa học.

Tóm tắt:

Thuật toán, bản theo dõi và bằng chứng về tính đúng đắn: Nêu điều kiện đầu vào và đầu ra mong đợi. Sử dụng các trường hợp biên, tập rỗng khi được phép, các giá trị trùng lặp và không hợp lệ. Phân biệt thuật toán sai với việc triển khai sai hoặc yêu cầu chưa đầy đủ.

Chuỗi thực thi chạy được và ranh giới

def first_index(values, target):
    for index, value in enumerate(values):
        if value == target:
            return index
    return -1
print(first_index([4, 7, 4], 4))
print(first_index([4, 7, 4], 9))
print(first_index([], 4))

Kết quả mong đợi:

0
-1
-1

Vòng lặp kiểm tra index 0 trước, dừng lại khi tìm thấy matches, và chỉ trả về −1 sau khi duyệt hết danh sách. Do đó, các bản sao trùng sẽ trả về index đầu tiên. Danh sách rỗng sẽ không thực thi thân vòng lặp.

Trọng tâm SL được hỗ trợ. Mục tiêu đánh giá đầu tiên 2027; PDF chính thức trả về 403; tài liệu ngắn thu thập trước đó là bài đánh giá cuối cùng 2026. Hướng dẫn còn lại, yêu cầu đánh giá và thực hành giữ nguyên các bản ghi đã lưu.

Yêu cầu tiên quyết: đọc các đại lượng và đơn vị được nêu, sử dụng phép tính toán và các điều kiện mô hình dưới đây. Mỗi bài học sẽ phát triển phương pháp riêng trước khi chuyển giao độc lập.

Đây là các ví dụ giảng dạy gốc hoặc được ghi rõ là hư cấu, không phải là các phép đo thực tế hay các nghiên cứu đánh giá học viên đã hoàn tất.

Giải thích hiện tượng này là gì?

• Hai đối tượng mô hình tài khoản ngân hàng có thể phản hồi cùng một thao tác gửi tiền trong khi vẫn giữ các số dư khác nhau.
• Bắt đầu bằng một dự đoán. Nêu rõ các đại lượng hoặc đặc điểm bạn sẽ so sánh, sau đó quyết định bằng chứng nào có thể phân biệt hai lời giải thích.

Xây dựng mô hình

• Một lớp (class) định nghĩa một kiểu với trạng thái và hành vi. Một đối tượng là một thực thể. Đóng gói kiểm soát quyền truy cập thông qua giao diện để các thao tác có thể bảo toàn các bất biến. Kế thừa mô hình hóa mối quan hệ kiểu thích hợp; tổ hợp mô hình hóa một đối tượng chứa hoặc sử dụng một đối tượng khác.
• bao封装 (encapsulation): Kiểm soát truy cập vào trạng thái thông qua giao diện; đối tượng thành viên (instance): Một đối tượng cụ thể của một lớp.

Chọn bằng chứng để kiểm định mô hình

• Một lời gọi phương thức tác động lên một thực thể cụ thể. Sự thay đổi trạng thái phải thỏa mãn điều kiện tiên决 và hậu điều kiện. Đa hình cho phép mã sử dụng một giao diện chung với các triển khai khác nhau khi hợp đồng được tuân thủ.
• Triển khai một mô hình tài khoản hoặc tồn kho tổng hợp nhỏ. Kiểm tra hai thực thể độc lập, từ chối các thao tác không hợp lệ và các giá trị biên. Giữ mô hình tránh xa các tài khoản tài chính thật và thông tin xác thực.

Bắt đầu từ các đại lượng đã biết

• Nêu các giá trị đã biết và đơn vị của chúng. Chọn công thức vì các giả thiết của nó phù hợp với trường hợp này, sau đó biến đổi trước khi thay số.
• Đã biết: đối tượng A bắt đầu ở 40 đơn vị và nhận được 15; đối tượng B bắt đầu ở 20 và nhận được 5. Số dư cuối cùng là 55 và 25. Tổng của chúng là 80, nhưng số dư của từng đối tượng riêng lẻ không phải là 80.

Ví dụ:

Một thực thể bắt đầu ở 12 đơn vị, thêm 8 và loại bỏ 3. Tìm giá trị cuối cùng của nó. Sử dụng cùng quy trình: các đại lượng đã biết → mô hình → mối liên hệ → thay thế → đơn vị và diễn giải.

Kiểm tra kết luận và giới hạn của nó

• Một lớp không giống như một thực thể. Kế thừa không tự động tốt hơn tổ hợp. Chỉ ẩn đi một trường dữ liệu không chứng minh được rằng tất cả các thao tác đều bảo toàn trạng thái hợp lệ.
• Quay trở lại quan sát ban đầu. Giải thích kết quả hỗ trợ điều gì, những điều kiện nào mà nó giả định, và một cách để kiểm chứng một giải thích cạnh tranh.

Cảnh báo:

Hai thực thể của một lớp luôn phải chia sẻ chung một số dư. Tuyên bố này là sai: Một lớp không giống như một thực thể. Kế thừa không tự động tốt hơn tổ hợp. Chỉ ẩn đi một trường dữ liệu không chứng minh được rằng tất cả các thao tác đều bảo toàn trạng thái hợp lệ.

Tóm tắt:

Đối tượng: trạng thái, hành vi và giao diện: Một lời gọi phương thức tác động lên một thực thể cụ thể. Sự thay đổi trạng thái phải thỏa mãn điều kiện tiên决 và hậu điều kiện. Đa hình cho phép mã sử dụng một giao diện chung với các triển khai khác nhau khi hợp đồng được tuân thủ.

Chuỗi thực thi chạy được và ranh giới

class Account:
    def __init__(self, balance):
        self.balance = balance
    def withdraw(self, amount):
        if amount < 0 or amount > self.balance:
            return False
        self.balance -= amount
        return True
a, b = Account(15), Account(20)
print(a.withdraw(30), a.balance, b.balance)
print(a.withdraw(15), a.balance, b.balance)

Kết quả mong đợi:

False 15 20
True 0 20

Từ chối xảy ra trước khi đột biến. Với số dư ban đầu không âm, các giao dịch rút tiền đã xác thực bảo toàn balance≥0. Lớp học nhỏ này tiết lộ các thuộc tính; thiết kế sản xuất phải kiểm soát mọi đường đột biến, không chỉ dựa vào việc phương pháp duy nhất đảm bảo bao封装.

Trọng tâm SL được hỗ trợ. Mục tiêu đánh giá đầu tiên 2027; PDF chính thức trả về 403; tài liệu ngắn thu thập trước đó là bài đánh giá cuối cùng 2026. Hướng dẫn còn lại, yêu cầu đánh giá và thực hành giữ nguyên các bản ghi đã lưu.

Yêu cầu tiên quyết: đọc các đại lượng và đơn vị được nêu, sử dụng phép tính toán và các điều kiện mô hình dưới đây. Mỗi bài học sẽ phát triển phương pháp riêng trước khi chuyển giao độc lập.

Đây là các ví dụ giảng dạy gốc hoặc được ghi rõ là hư cấu, không phải là các phép đo thực tế hay các nghiên cứu đánh giá học viên đã hoàn tất.

Giải thích hiện tượng này là gì?

• Một hệ thống đặt phòng trường học được đề xuất có vẻ hiệu quả, nhưng khuyến nghị dựa trên đó phụ thuộc vào người dùng, ràng buộc và bằng chứng. Chỉ riêng một thuật ngữ kỹ thuật khả thi thì chưa đủ để đưa ra quyết định hợp lý.
• Bắt đầu bằng một dự đoán. Nêu rõ các đại lượng hoặc đặc điểm bạn sẽ so sánh, sau đó quyết định bằng chứng nào có thể phân biệt hai lời giải thích.

Xây dựng mô hình

• Một nghiên cứu tình huống đặt các lựa chọn tính toán trong một bối cảnh đã nêu rõ. Hãy xác định các bên liên quan, yêu cầu, bằng chứng có sẵn và các ràng buộc trước khi đề xuất kiến trúc hoặc thuật toán. Phân biệt giữa sự thật của bối cảnh với giả định và dự đoán. Các sự đánh đổi có thể liên quan đến hiệu suất, độ tin cậy, khả năng truy cập, quyền riêng tư, bảo trì và chi phí.
• tỷ lệ xử lý (throughput): Lượng công việc hoàn thành trong một đơn vị thời gian dưới tải công việc đã nêu; kiểm thử chấp nhận (acceptance test): Kiểm tra xem yêu cầu người dùng cụ thể có được đáp ứng hay không.

Chọn bằng chứng để kiểm định mô hình

• Một khuyến nghị cần kết nối yêu cầu với cơ chế và kiểm thử có thể quan sát được. Ví dụ, vấn đề đồng thời đòi hỏi chiến lược ngăn chặn cập nhật xung đột, cộng thêm các kiểm thử minh họa cho bất biến. Một tuyên bố về tốc độ phản hồi nhanh hơn đòi hỏi đo lường tải công việc tương đương thay vì chỉ một nhãn độ phức tạp. Hãy đánh giá các phương án thay thế trong cùng điều kiện đã nêu.
• Sử dụng bối cảnh do nhà trường phê duyệt và dữ liệu tổng hợp. Xây dựng ma trận gồm: tuyên bố, bằng chứng bối cảnh hỗ trợ, giải thích kỹ thuật, hạn chế và kiểm thử chấp nhận. Đánh dấu rõ ràng các sự thật bị thiếu và minh họa cách khuyến nghị sẽ thay đổi nếu một giả định không còn đúng. Điều này chuẩn bị cho suy luận dựa trên tình huống mà không sao chép lại nghiên cứu tình huống đánh giá của IB không có sẵn hay tự sáng tạo bảng điểm kiểm tra.

Bắt đầu từ các đại lượng đã biết

• Nêu các giá trị đã biết và đơn vị của chúng. Chọn công thức vì các giả thiết của nó phù hợp với trường hợp này, sau đó biến đổi trước khi thay số.
• Đã biết: một mẫu thử giả tưởng xử lý 120 yêu cầu thành công trong khoảng thời gian quan sát 30 giây. Băng thông là 120/30=4 yêu cầu thành công/giây. Mẫu thử thứ hai xử lý 150 trong 30 giây, hay 5/s. Mẫu thứ hai có 25% băng thông được ghi nhận cao hơn, nhưng không có kết luận nào về độ trễ, tỷ lệ lỗi hoặc hiệu suất dưới tải lớn hơn mà không có những phép đo đó.

Ví dụ:

Một hệ thống giả tưởng đã xử lý thành công 210 yêu cầu trong 30 giây. Hãy tính tỷ lệ xử lý. Sử dụng cùng trình tự: các đại lượng đã biết → mô hình → mối quan hệ → thay số → đơn vị và diễn giải.

Kiểm tra kết luận và giới hạn của nó

• Tỷ lệ xử lý không phải là thời gian phản hồi. Một khuyến nghị mạnh mẽ phải nêu rõ điều kiện mà nó dự kiến hoạt động và bằng chứng có thể bác bỏ nó. Các yêu cầu chính thức hiện tại về nghiên cứu tình huống Tin học cần được đối chiếu với phiên bản đánh giá áp dụng.
• Quay trở lại quan sát ban đầu. Giải thích kết quả hỗ trợ điều gì, những điều kiện nào mà nó giả định, và một cách để kiểm chứng một giải thích cạnh tranh.

Cảnh báo:

Tỷ lệ xử lý quan sát được cao hơn tự động chứng minh thời gian phản hồi thấp hơn cho mọi yêu cầu. Tuyên bố này là sai: Tỷ lệ xử lý không phải thời gian phản hồi. Một khuyến nghị mạnh mẽ phải nêu rõ điều kiện mà nó dự kiến hoạt động và bằng chứng có thể bác bỏ nó. Các yêu cầu chính thức hiện tại về nghiên cứu tình huống Tin học cần được đối chiếu với phiên bản đánh giá áp dụng.

Tóm tắt:

Phân tích tình huống Tin học: Đánh giá hệ thống được đề xuất: Một khuyến nghị cần kết nối yêu cầu với cơ chế và kiểm thử có thể quan sát được. Ví dụ, vấn đề đồng thời đòi hỏi chiến lược ngăn chặn cập nhật xung đột, cộng thêm các kiểm thử minh họa cho bất biến. Một tuyên bố về tốc độ phản hồi nhanh hơn đòi hỏi đo lường tải công việc tương đương thay vì chỉ một nhãn độ phức tạp. Hãy đánh giá các phương án thay thế trong cùng điều kiện đã nêu.

Chuỗi thực thi chạy được và ranh giới

for successful, attempted, seconds in [(240, 300, 30), (270, 300, 30)]:
    if seconds <= 0 or attempted <= 0:
        raise ValueError("Positive exposure required")
    throughput = successful / seconds
    failure_fraction = (attempted - successful) / attempted
    print(throughput, failure_fraction)

Kết quả mong đợi:

8.0 0.2
9.0 0.1

Tốc độ thành công và tỷ lệ thất bại sử dụng mẫu số khác nhau. Thời gian bằng không hoặc số lần thử bằng không không thể hỗ trợ các tốc độ này. Các tóm tắt giả định này không cung cấp bằng chứng về độ trễ, chi phí hay tải trọng đại diện.