Étude de cas
Baccalauréat international · IB Diploma · Computer Science · SL Sujet 8 4:41 Narration en anglais · Sous-titres anglais + 中文 incrustés
Chapitres
Transcript
A proposed school booking system looks efficient, but its recommendation depends on users, constraints and evidence.
一个拟议的学校预订系统看似高效，但其推荐结果取决于用户、约束条件和证据。
A plausible technical term alone is not a justified decision.
仅凭一个看似合理的术语，并不构成正当的决策依据。
A case study places computational choices within a stated scenario.
案例研究将计算选择置于既定场景中。
Identify stakeholders, requirements, available evidence and constraints before recommending an architecture or algorithm.
在推荐架构或算法之前，需识别利益相关者、需求、可用证据及约束条件。
Distinguish a scenario fact from an assumption and a prediction.
区分场景事实与假设和预测。
Trade-offs can involve performance, reliability, accessibility, privacy, maintenance and cost.
权衡因素可能涉及性能、可靠性、可访问性、隐私、维护及成本。
Throughput is completed work per unit time under a stated workload.
吞吐量指在特定工作负载下单位时间内完成的工作量。
Acceptance test is a test of whether a specified user requirement is met.
验收测试是检验是否满足指定用户需求的测试。
A recommendation should connect a requirement to a mechanism and an observable test.
建议应将需求与机制及可观测测试相连接。
For example, a concurrency problem requires a strategy that prevents conflicting updates, plus tests demonstrating the invariant.
例如，并发问题需要一种防止冲突更新的策略，以及展示不变量的测试。
A claim about faster response requires comparable workload measurements rather than only a complexity label.
关于响应更快的声明需要可比较的工作负载测量，而不仅仅是复杂度标签。
Evaluate alternatives under the same stated conditions.
在相同陈述条件下评估替代方案。
In the lab: Use an original school-approved scenario and synthetic data.
在实验室中，使用学校批准的原创场景和合成数据。
Build a matrix of claim, supporting scenario evidence, technical explanation, limitation and acceptance test.
构建一个包含主张、支持性场景证据、技术解释、局限性和验收测试的矩阵。
Mark missing facts explicitly and show how the recommendation would change if an assumption failed.
明确标出缺失的事实，并展示如果某个假设不成立，建议将如何变化。
This prepares case-based reasoning without reproducing an unavailable IB assessment case study or inventing its examination rubric.
这有助于培养基于案例的推理能力，同时无需复制无法获取的IB评估案例研究，也无需虚构其考试评分标准。
Known: a fictional prototype processes one hundred twenty successful requests during a thirty-second observation.
已知：一个虚构的原型在30秒的观察期内处理了120个成功请求。
Throughput is one hundred twenty divided by thirty, which equals four successful requests per second.
吞吐量为120除以30，等于每秒4个成功请求。
A second prototype processes one hundred fifty in thirty seconds, or five per second.
第二个原型在30秒内处理了150个请求，即每秒5个。
The second has twenty-five percent greater recorded throughput, but no conclusion about latency, failure rate, or performance under a larger workload follows without those measurements.
第二个原型的记录吞吐量高出25%，但如果没有这些测量数据，就无法得出关于延迟、失败率或更大负载下性能的结论。
Your turn: A fictional system successfully processes 210 requests in 30 s.
轮到你了。 一个虚构系统成功处理了210个请求，耗时30秒。
Calculate throughput.
请计算吞吐量。
Throughput is not response time.
吞吐量不等于响应时间。
A strong recommendation states the conditions in which it is expected to work and the evidence that could disconfirm it.
强推荐陈述了预期生效的条件以及可能证伪它的证据。
Current official case study requirements must be checked against the applicable assessment version.
当前的官方案例研究要求必须与适用的评估版本进行核对。
Not true: Higher observed throughput automatically proves lower response time for every request.
不正确。 更高的观测吞吐量并不能自动证明每个请求的响应时间都更低。
Throughput counts completions per second; response time is how long each request takes.
吞吐量统计的是每秒完成数，而响应时间是每个请求所花费的时间。
A system can batch work for high throughput while individual requests wait - so one metric cannot prove the other.
系统可以通过批量处理工作来实现高吞吐量，但单个请求可能仍需等待，因此一个指标无法证明另一个指标。
A case study places computational choices within a stated scenario.
案例研究将计算选择置于既定场景中。
A recommendation should connect a requirement to a mechanism and an observable test.
建议应将需求与机制及可观测测试相联系。
Watch for: throughput is not response time.
请注意：吞吐量不等于响应时间。
Prototype B completes five successful requests a second and prototype A four, so B has twenty-five percent more throughput.
原型B每秒完成五个成功请求，原型A为四个，所以B的吞吐量高出百分之二十五。
Throughput alone does not show how long each request takes.
仅凭吞吐量看不出每个请求需要多长时间。
Fictional prototypes complete 240 of 300 and 270 of 300 requests in 30 seconds.
虚构的原型在 30 秒内分别完成了 300 个请求中的 240 个和 270 个。
Compare success throughput and failure fractions.
请比较成功吞吐量和失败比例。
What else is needed for a purchase decision?
做出采购决策还需要哪些信息？
Throughputs are 8 and 9 per second; failure fractions are 20 percent and 10 percent.
吞吐量分别为每秒 8 和每秒 9；失败比例分别为 20% 和 10%。
Compare latency distributions, workload, cost, reliability and user criteria; one workload does not prove all performance.
要比较延迟分布、工作负载、成本、可靠性和用户标准；单一工作负载无法证明全部性能。
Success throughput and failure fraction use different denominators.
成功率与失败率的分母不同。
Zero time or zero attempts cannot support those rates.
零时间或零尝试次数无法支持这些比率。
These fictional summaries do not supply latency, cost or representative-load evidence.
这些虚构的摘要未提供延迟、成本或代表性负载证据。
Retrieve the technical meanings, then vary one input in the original transfer and justify the model condition.
回顾相关技术术语，然后在原始迁移中改变一个输入变量，并为模型条件提供依据。